Arthur Pemberton wrote:
But every fedora version has required new patches to VMware that you have to track down,
Wasn't aware of this. And you're saying that this is intentional by the Fedora dev team?
Changes don't just happen by accident - someone has to make them.
But you are implying that this is intentional. I think that's something you should at least backup if you're going to say it.
I can't prove that it is done for no other reason than to break other people's software, but I trust that the people making the changes are bright enough to understand how this works. And it doesn't happen in RHEL, so there are also people who understand how to keep it from happening and that it makes for a better user experience.
firewire has had about 50/50 odds of working, anything that knew device names would break from one version to the next,
While some Fedora devs may be kernel hackers, I doubt they are to blame for firewire support.
Some issues were with the kernel, some with the layering of device detection when the connection is made or at boot time. Regardless, fedora doesn't have to ship a broken kernel just because it exists.
Well if the vanilla kernel has this problem, blaming Fedora seems unreasonable. The general policy is to ship the kernel as vanilla as possible.
Why shouldn't I blame fedora if they set a policy that frequently causes broken code to be shipped? The kernel developers no longer maintain a separate test version so untested changes are obviously going to be pushed out if you do that and the user consequences are equally obvious.
CIPE hasn't worked since
Are you referring to this CIPE? http://www.faqs.org/docs/Linux-mini/Cipe+Masq.html I wasn't familiar with the term.
Yes, once it was a fill-in-the-form VPN in the networking setup. Next version it was gone with no options to support existing setups.
I guess no one was interested in supporting it. I haven't heard of it before myself.
OpenVPN is actually better these days, but CIPE was the preferred and supported VPN through the earlier RH versions and FC1, then poof, gone with no trace in FC2 and no transition strategy for maintaining compatibility so you could upgrade piecemeal - and no continuing security updates for FC1 so you could continue running it.
And then there is almost no chance that you can just repeat your steps with the next version since it will have a huge number of arbitrary changes, including things that affect hardware compatibility.
I guess your choice of software has a lot of incompatibilities inherent in it. I am normally up and running on a new Fedora install for my desktop pretty quickly. I normally spend way more time customizing the look and feel of my KDE install to my perfection.
It seems that your combination of unsupported software is making things a lot tougher for you.
I expect an operating system to provide a platform that other things can run on, either proving stable interfaces so things continue to work through the fast-paced updates, or some sane way to deal with the instability.
However, I see no evidence that this is intentional on the Fedora teams part. Nor do I see how it would benefit them from exhausting energy into blocking things.
Whether it is a benefit or not depends on the user experience they want to generate. Who would it harm to provide instructions for installing common and needed vendor-provide drivers, for example? Is it necessary to be hostile to both your own users and the best hardware vendors, or the company that invented java and wants to give it away?