1 |
2008/10/1 Robert Bridge <robert@××××××××.com>: |
2 |
> Right, imagine a live server getting hit by the expat problem, or a |
3 |
> major gcc/glibc change? They hurt, they seriously hurt. |
4 |
|
5 |
Well, allow me to retort. How exactly does a glibc upgrade break |
6 |
anything? I've used gentoo for a long time and have not had a glibc |
7 |
upgrade break anything once. Not ever. Nor have I ever encountered |
8 |
anyone that has claimed a glibc upgrade to break anything. Downgrades |
9 |
are a different matter, as is well known. |
10 |
|
11 |
As for gcc updates, the only occasion that I recall there being any |
12 |
significant migration issue was the C++ ABI change between gcc-3.3 and |
13 |
gcc-3.4. Allow me to point out then: |
14 |
|
15 |
* The change was documented and a migration procedure presented |
16 |
* Upgrading gcc between anything but a minor point release in gentoo |
17 |
does _not_ then make it the default compiler (the user must run |
18 |
gcc-config to switch and source /etc/profile to activate the new |
19 |
compiler). In fact, the process of upgrading has _no_ effect |
20 |
whatsoever in itself. |
21 |
* Nobody is forcing you to upgrade. Hey, I still run my hardened |
22 |
systems on gcc-3.4.6 and they work fine. |
23 |
|
24 |
And, even where there are major changes in the base system and uptime |
25 |
is of importance, how hard is to roll a new chroot with |
26 |
FEATURES="buildpkg" then simply replace the host system based on the |
27 |
generated packages? I've counselled many users over the years via IRC |
28 |
(usually the kind who don't like to upgrade things for a protracted |
29 |
period and are this in a self-induced quandary) with a 100% success |
30 |
rate, every single time. This is not an idle boast, this is a fact. |
31 |
|
32 |
> |
33 |
> That's what the "static package" people are referring to. A server that |
34 |
> can be set up, and once running should need minimal updating, for |
35 |
> security reasons. You can't do that safely in Gentoo. |
36 |
|
37 |
Which security reasons exactly? How exactly are the majority of |
38 |
security bugs that are continuously found to be mitigated without |
39 |
software being updated by some means? |
40 |
|
41 |
> |
42 |
> Some people are happy with regularly changing packages, restarting |
43 |
> services every month because a new version of the server is in tree, |
44 |
> dealing with the breakage induced by things like python upgrades, bash |
45 |
> upgrades, portage upgrades, gcc upgrades, ... |
46 |
|
47 |
Are you seriously stating that there are gcc, python, bash and portage |
48 |
upgrades - all of which you say are breaking - every month or are we |
49 |
verging on unsubstantiated hyperbole here? I've already touched upon |
50 |
the topic of gcc. When was the last time a bash upgrade broke your |
51 |
system? How about portage? |
52 |
|
53 |
As for python, I wasn't aware that major new point releases of python |
54 |
were forthcoming on a monthly basis - that's news to me. The upgrade |
55 |
process turned out to be trivial for me. It's even easier if you keep |
56 |
a chroot handy for testing and with which to generate binary packages |
57 |
that can be immediately consumed by any system that needs migrating. |
58 |
Or you could just mask python-2.5 until such time as you feel like |
59 |
upgrading. Really ... it's not that bloody hard. |
60 |
|
61 |
> |
62 |
> But for a 24/7 uptime on a high load server, most people consider those |
63 |
> to be unacceptable. Now Gentoo can be got to not do those, but as |
64 |
> anyone will tell you, updating a Gentoo box after a year is painful, |
65 |
> and when you have to update to cover a critical security hole? Now try updating a Debian box after a year? |
66 |
|
67 |
Yes, I realise that some environments enforce such constraints. |
68 |
Personally, I have absolutely no problem maintaining an acceptable |
69 |
level of uptime with my servers using Gentoo. And, as I alluded to |
70 |
earlier, I've managed to help people update systems that are years out |
71 |
of date with ease. It's a different process, granted, and it may not |
72 |
seem as intuitive to one man as it does to another. But don't tell me |
73 |
that it can't be done because it's simply not true. If I wanted to run |
74 |
Gentoo for a whole year without shutting down a single service or |
75 |
issuing a single reboot, I would have absolutely no qualms in doing |
76 |
so. |
77 |
|
78 |
The uptime argument is particularly pertinent as far as kernel |
79 |
upgrades are concerned and this is something that affects all distros. |
80 |
Frankly, I'd rather have frequent kernel updates that close as many |
81 |
security holes as possible than none. It's ultimately up to me as to |
82 |
whether I want to consume these updates anyway. |
83 |
|
84 |
> |
85 |
> Don't mistake one awkward piece of software which is not supported in |
86 |
> the other distros for the general properties of those distros. Gentoo |
87 |
> is good for tweaking, it's good for doing "Your own thing", that does |
88 |
> not make it automagically better than Debian or RHEL, or SLES in the |
89 |
> high-stability stakes. And, sorry to say this, one nice anecdote |
90 |
> doesn't either. |
91 |
|
92 |
I'm glad you thought the anectode was nice - there are plenty more |
93 |
where that came from :) Seriously though, I consider the packages in |
94 |
Gentoo to exhibit much greater stability in terms of exhibiting |
95 |
performant and bug-free operation and am very happy with it. I concur |
96 |
that there is no single property of a given distro that makes it |
97 |
automatically "better" or "worse" than another. Yet there is a lot of |
98 |
unsubstantiated bullshit that gets bandied around about Gentoo, and |
99 |
other systems are seldom called out on their weaknesses. If Debian, |
100 |
RHEL or SLES suit anyone else's needs better than great. I still stand |
101 |
by my original post and am delighted to be doing my "own thing", as |
102 |
you put it. To each their own. |
103 |
|
104 |
Cheers, |
105 |
|
106 |
--Kerin |