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?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
