[Fwd: Wikipidia - Goodbye Red Hat and Fedora]
D. Hugh Redelmeier
hugh at mimosa.com
Sun Oct 12 21:33:13 UTC 2008
| From: Les Mikesell <lesmikesell at gmail.com>
| But the first question should be why a separate community is necessary. Why
| is it not possible for one of fedora's goals to be to provide a clean
| transition to RHEL or Centos at the end of certain development cycles
I think that this idea has some merit. I'm taking this out of context
to use as a jump-off point.
[I'm a long-term Red Hat and Fedora user. I also use Ubuntu
sometimes.]
Ubuntu 8.04 LTS has seduced me with its simultaneous promises of being
maintained and having a current code base.
RHEL/CentOS feels too old. Concrete issues:
- support for video cards
- PostgreSQL 8.3 vs 8.1
Ubuntu 8.04 will be quite stale before the next LTS comes out.
Probably more stale that RHEL/CentOS. It is all a matter of where
each stream is in the cycle. Right now, Ubuntu LTS is ahead of
RHEL/CentOS.
Ubuntu LTS is in the same series as regular Ubuntu. RHEL/CentOS are
not the same as Fedora. One could predict that the transition costs
between Ubuntus are lower that the transition costs from RHEL/CentOS
to or from Fedora. This is a disadvantage.
I find the various Fedora-targeted 3rd party repositories confusing
and even conflicting. This isn't healthy. I've not had this problem
with Ubuntu but I'm not sure why.
I like that fedora is willing to take radical steps. This is the only
way to do some important experiments.
Some changes make me (a conservative at heart) uncomfortable:
- the idea that network connectivity is part of a session just seems
bizarre to me. Network Manager may be useful but I think that this
aspect does not fit in with my UNIX world-view.
- the idea that non-X consoles will go bothers me. Just a few minutes
ago, I used a non-X console to whack on an X problem. I hit a lot
of X problems due to the way hardware gets introduced more quickly
than X versions are released (and debugged). I may stop using
Fedora when this change comes to pass.
- Documentation that I expect is not provided.
- the anatomy of the system changes more quickly than my
understanding. HAL/d-bus/etc. all seem like magic to me.
Why should a (source) package release be tied to a distro release?
For a lot of packages, the actual minimum requirements on the
environment are satisfied by earlier distro releases.
The strongest argument against is to do with testing: real
dependencies might diverge from declared dependencies and only testing
can show this. This adds a lot of testing burden to the package
maintainer.
Some packages really are not independent modules. Updating such a
package may require updating a lot of others. At least sometimes
these binary packages are all created from a single source package.
I wonder if smooth evolution (frequent uncoordinated package updates),
as opposed to punctuated equilibrium (updates tied to distro releases)
would work.
More information about the devel
mailing list