On Wed, 2005-08-03 at 13:55 +0200, Sven Köhler wrote: > > In my humble opinion, Gentoo is missing too many points to be an > > enterprise Linux. We commit to a live tree. We don't have true QA, > > testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. > > We don't really have product lifecycles, since we don't generally > > backport fixes to older versions, requiring instead for people to > > update to a more recent release. We don't have, and probably will > > never be able to offer, support contracts. We support as wide a range > > of hardware as the upstream kernel, plus hardware that requires > > external drivers; we don't have access to a great deal of the hardware > > for which we provide drivers. We understand when real life gets in > > the way of bug-fixing, because all our developers are volunteers. > > QA is a problem. Bugs get fixed, but often they are only fixed in ~x86 > versions, not in the stable x86 series. For example baselayout: there > are lot of ~x86 - miles ahead of that is marked x86. Maintainers think, > it's sufficient to only fix the most recent version. How do they > legitimate that?
This one is easy. A stable package's ebuild should not change. Period. To "fix" the stable version, means that a new revision of the latest stable version would need to be made, and that revision would need to be tested, before it would go to stable. The only real exception to this is security bugs. Also, in many cases, the bug in question requires changes that are simply not feasible easily in the current stable version, but quite easy in the latest version. It really boils down to this: If you're having an issue with a package in Gentoo and it is fixed in the latest ~arch version, then you should *use* the ~arch version (remember, it doesn't mean "unstable" it means "testing") and you should report back to the maintainers that this is working for you so that they can get it moved into stable quicker. We don't have the staff or the time to backport every fix to every stable version. Remember that in many cases the "latest stable" version varies between architectures. > And yes, Gentoo does not backport patches to older version. But is it > Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and > the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat > will backport the patches propably. They is a big reason why all the > distrubutions with precompiled packages do that: > - the updates has to be binary compatible with the old one I don't feel that this is our responsibility. While we sometimes do backport patches, we just don't have the manpower to make it policy. > Gentoo doesn't suffer from that limitation. Gentoo offers ways to > migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other > distributions doesn't offer that - although they could with better > package managers. Right. > Administrating a Gentoo system takes time - much time, but ... This is something that I think most people forget. Running Gentoo makes you a Linux Systems Administrator. Sure, you're only being the administrator for your machine, which might only have one user, but you're the admin. With some of the other distributions, *they* are the admin, and you're just a user. They make assumptions for you and limit what you can and cannot do (without an enormous amount of work to bypass their limits). This is especially apparent in the many cases where users expect Gentoo to do everything for them, when it doesn't. > ... writing my own packages for - let's say Redhat - takes more time > than writing an ebuild for Gentoo. If you have to maintain a system with > very special software, i would recomm Gentoo. I would agree with you. Professionally, I work on Red Hat. I have to build custom RPMs on a daily basis, and I can say that the simple syntax of ebuilds is a tremendous advantage. > Just some days ago, someone reinstalled a Server where we had PostGreSQL > 8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 - > so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to > use our existing database. This will become hell the more packages you > have to compile on you own. Any configure-make-install-like package, > Perl-Module, etc... can be easy installed by using an ebuild. You aren't "supposed" to compile packages on your own on Debian. You're supposed to make your own DEB package and install that. Otherwise, you are working outside the package manager. This is no different than on Gentoo, just for many people, an ebuild is easier to write than creating a DEB/RPM. > In addition Gentoo is the only distribution i know, that supports > installing multiple Java-version etc... > A must-have for every real java-developer. Agreed. This is also very true for proprietary applications that rely on java. > So i'd say: use Debian, if you have a relativly normal system to > maintain, use Gentoo if you have the time - and never ever use Redhat or > SuSE. Gentoo tends to be more flexible with a smaller amount of work. This makes it an excellent development platform, which is another reason why many people say that Gentoo is "for the developers" first. I also think that it is a wonderful end-user platform. My girlfriend runs Gentoo and loves it. I started her off on Red Hat, and she found lots of little things that bugged her, so I showed her Gentoo, and she was hooked, since it was so easy for her to change those little peculiarities, not to mention she knows a lot more about what it going on behind the scenes then with those little redhat-config-* apps. I personally hope that Gentoo never changes. I'd like to see quality improve, but that doesn't require any major changes to Gentoo itself. As far as enterprise support, I think a fork is honestly the best answer. Not a fork that becomes completely independent, but a fork focused on providing the enterprise features, like a slower release cycle and backporting fixes, and rolling what it can back into Gentoo. I think this sort of symbiotic relationship is really the only way to successfully move Gentoo into the enterprise. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part