1 |
On Wed, 2005-08-03 at 13:55 +0200, Sven Köhler wrote: |
2 |
> > In my humble opinion, Gentoo is missing too many points to be an |
3 |
> > enterprise Linux. We commit to a live tree. We don't have true QA, |
4 |
> > testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. |
5 |
> > We don't really have product lifecycles, since we don't generally |
6 |
> > backport fixes to older versions, requiring instead for people to |
7 |
> > update to a more recent release. We don't have, and probably will |
8 |
> > never be able to offer, support contracts. We support as wide a range |
9 |
> > of hardware as the upstream kernel, plus hardware that requires |
10 |
> > external drivers; we don't have access to a great deal of the hardware |
11 |
> > for which we provide drivers. We understand when real life gets in |
12 |
> > the way of bug-fixing, because all our developers are volunteers. |
13 |
> |
14 |
> QA is a problem. Bugs get fixed, but often they are only fixed in ~x86 |
15 |
> versions, not in the stable x86 series. For example baselayout: there |
16 |
> are lot of ~x86 - miles ahead of that is marked x86. Maintainers think, |
17 |
> it's sufficient to only fix the most recent version. How do they |
18 |
> legitimate that? |
19 |
|
20 |
This one is easy. A stable package's ebuild should not change. Period. |
21 |
To "fix" the stable version, means that a new revision of the latest |
22 |
stable version would need to be made, and that revision would need to be |
23 |
tested, before it would go to stable. The only real exception to this |
24 |
is security bugs. Also, in many cases, the bug in question requires |
25 |
changes that are simply not feasible easily in the current stable |
26 |
version, but quite easy in the latest version. It really boils down to |
27 |
this: If you're having an issue with a package in Gentoo and it is |
28 |
fixed in the latest ~arch version, then you should *use* the ~arch |
29 |
version (remember, it doesn't mean "unstable" it means "testing") and |
30 |
you should report back to the maintainers that this is working for you |
31 |
so that they can get it moved into stable quicker. We don't have the |
32 |
staff or the time to backport every fix to every stable version. |
33 |
Remember that in many cases the "latest stable" version varies between |
34 |
architectures. |
35 |
|
36 |
> And yes, Gentoo does not backport patches to older version. But is it |
37 |
> Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and |
38 |
> the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat |
39 |
> will backport the patches propably. They is a big reason why all the |
40 |
> distrubutions with precompiled packages do that: |
41 |
> - the updates has to be binary compatible with the old one |
42 |
|
43 |
I don't feel that this is our responsibility. While we sometimes do |
44 |
backport patches, we just don't have the manpower to make it policy. |
45 |
|
46 |
> Gentoo doesn't suffer from that limitation. Gentoo offers ways to |
47 |
> migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other |
48 |
> distributions doesn't offer that - although they could with better |
49 |
> package managers. |
50 |
|
51 |
Right. |
52 |
|
53 |
> Administrating a Gentoo system takes time - much time, but ... |
54 |
|
55 |
This is something that I think most people forget. Running Gentoo makes |
56 |
you a Linux Systems Administrator. Sure, you're only being the |
57 |
administrator for your machine, which might only have one user, but |
58 |
you're the admin. With some of the other distributions, *they* are the |
59 |
admin, and you're just a user. They make assumptions for you and limit |
60 |
what you can and cannot do (without an enormous amount of work to bypass |
61 |
their limits). This is especially apparent in the many cases where |
62 |
users expect Gentoo to do everything for them, when it doesn't. |
63 |
|
64 |
> ... writing my own packages for - let's say Redhat - takes more time |
65 |
> than writing an ebuild for Gentoo. If you have to maintain a system with |
66 |
> very special software, i would recomm Gentoo. |
67 |
|
68 |
I would agree with you. Professionally, I work on Red Hat. I have to |
69 |
build custom RPMs on a daily basis, and I can say that the simple syntax |
70 |
of ebuilds is a tremendous advantage. |
71 |
|
72 |
> Just some days ago, someone reinstalled a Server where we had PostGreSQL |
73 |
> 8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 - |
74 |
> so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to |
75 |
> use our existing database. This will become hell the more packages you |
76 |
> have to compile on you own. Any configure-make-install-like package, |
77 |
> Perl-Module, etc... can be easy installed by using an ebuild. |
78 |
|
79 |
You aren't "supposed" to compile packages on your own on Debian. You're |
80 |
supposed to make your own DEB package and install that. Otherwise, you |
81 |
are working outside the package manager. This is no different than on |
82 |
Gentoo, just for many people, an ebuild is easier to write than creating |
83 |
a DEB/RPM. |
84 |
|
85 |
> In addition Gentoo is the only distribution i know, that supports |
86 |
> installing multiple Java-version etc... |
87 |
> A must-have for every real java-developer. |
88 |
|
89 |
Agreed. This is also very true for proprietary applications that rely |
90 |
on java. |
91 |
|
92 |
> So i'd say: use Debian, if you have a relativly normal system to |
93 |
> maintain, use Gentoo if you have the time - and never ever use Redhat or |
94 |
> SuSE. |
95 |
|
96 |
Gentoo tends to be more flexible with a smaller amount of work. This |
97 |
makes it an excellent development platform, which is another reason why |
98 |
many people say that Gentoo is "for the developers" first. I also think |
99 |
that it is a wonderful end-user platform. My girlfriend runs Gentoo and |
100 |
loves it. I started her off on Red Hat, and she found lots of little |
101 |
things that bugged her, so I showed her Gentoo, and she was hooked, |
102 |
since it was so easy for her to change those little peculiarities, not |
103 |
to mention she knows a lot more about what it going on behind the scenes |
104 |
then with those little redhat-config-* apps. |
105 |
|
106 |
I personally hope that Gentoo never changes. I'd like to see quality |
107 |
improve, but that doesn't require any major changes to Gentoo itself. |
108 |
As far as enterprise support, I think a fork is honestly the best |
109 |
answer. Not a fork that becomes completely independent, but a fork |
110 |
focused on providing the enterprise features, like a slower release |
111 |
cycle and backporting fixes, and rolling what it can back into Gentoo. |
112 |
I think this sort of symbiotic relationship is really the only way to |
113 |
successfully move Gentoo into the enterprise. |
114 |
|
115 |
-- |
116 |
Chris Gianelloni |
117 |
Release Engineering - Strategic Lead/QA Manager |
118 |
Games - Developer |
119 |
Gentoo Linux |