Gentoo Archives: gentoo-server

From: Kerin Millar <kerframil@×××××.com>
To: gentoo-server@l.g.o
Subject: Re: [gentoo-server] Server Packages for Gentoo
Date: Wed, 01 Oct 2008 15:23:16
Message-Id: 279fbba40810010823v34ce2ee1ta04cfe062abd280c@mail.gmail.com
In Reply to: Re: [gentoo-server] Server Packages for Gentoo by Robert Bridge
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