public inbox for gentoo-server@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Kerin Millar" <kerframil@gmail.com>
To: gentoo-server@lists.gentoo.org
Subject: Re: [gentoo-server] Server Packages for Gentoo
Date: Wed, 1 Oct 2008 16:23:13 +0100	[thread overview]
Message-ID: <279fbba40810010823v34ce2ee1ta04cfe062abd280c@mail.gmail.com> (raw)
In-Reply-To: <20081001153404.5b01b1e6@robbieab.com>

2008/10/1 Robert Bridge <robert@robbieab.com>:
> Right, imagine a live server getting hit by the expat problem, or a
> major gcc/glibc change? They hurt, they seriously hurt.

Well, allow me to retort. How exactly does a glibc upgrade break
anything? I've used gentoo for a long time and have not had a glibc
upgrade break anything once. Not ever. Nor have I ever encountered
anyone that has claimed a glibc upgrade to break anything. Downgrades
are a different matter, as is well known.

As for gcc updates, the only occasion that I recall there being any
significant migration issue was the C++ ABI change between gcc-3.3 and
gcc-3.4. Allow me to point out then:

* The change was documented and a migration procedure presented
* Upgrading gcc between anything but a minor point release in gentoo
does _not_ then make it the default compiler (the user must run
gcc-config to switch and source /etc/profile to activate the new
compiler). In fact, the process of upgrading has _no_ effect
whatsoever in itself.
* Nobody is forcing you to upgrade. Hey, I still run my hardened
systems on gcc-3.4.6 and they work fine.

And, even where there are major changes in the base system and uptime
is of importance, how hard is to roll a new chroot with
FEATURES="buildpkg" then simply replace the host system based on the
generated packages? I've counselled many users over the years via IRC
(usually the kind who don't like to upgrade things for a protracted
period and are this in a self-induced quandary) with a 100% success
rate, every single time. This is not an idle boast, this is a fact.

>
> That's what the "static package" people are referring to. A server that
> can be set up, and once running should need minimal updating, for
> security reasons. You can't do that safely in Gentoo.

Which security reasons exactly? How exactly are the majority of
security bugs that are continuously found to be mitigated without
software being updated by some means?

>
> Some people are happy with regularly changing packages, restarting
> services every month because a new version of the server is in tree,
> dealing with the breakage induced by things like python upgrades, bash
> upgrades, portage upgrades, gcc upgrades, ...

Are you seriously stating that there are gcc, python, bash and portage
upgrades - all of which you say are breaking - every month or are we
verging on unsubstantiated hyperbole here? I've already touched upon
the topic of gcc. When was the last time a bash upgrade broke your
system? How about portage?

As for python, I wasn't aware that major new point releases of python
were forthcoming on a monthly basis - that's news to me. The upgrade
process turned out to be trivial for me. It's even easier if you keep
a chroot handy for testing and with which to generate binary packages
that can be immediately consumed by any system that needs migrating.
Or you could just mask python-2.5 until such time as you feel like
upgrading. Really ... it's not that bloody hard.

>
> But for a 24/7 uptime on a high load server, most people consider those
> to be unacceptable. Now Gentoo can be got to not do those, but as
> anyone will tell you, updating a Gentoo box after a year is painful,
> and when you have to update to cover a critical security hole? Now try updating a Debian box after a year?

Yes, I realise that some environments enforce such constraints.
Personally, I have absolutely no problem maintaining an acceptable
level of uptime with my servers using Gentoo. And, as I alluded to
earlier, I've managed to help people update systems that are years out
of date with ease. It's a different process, granted, and it may not
seem as intuitive to one man as it does to another. But don't tell me
that it can't be done because it's simply not true. If I wanted to run
Gentoo for a whole year without shutting down a single service or
issuing a single reboot, I would have absolutely no qualms in doing
so.

The uptime argument is particularly pertinent as far as kernel
upgrades are concerned and this is something that affects all distros.
Frankly, I'd rather have frequent kernel updates that close as many
security holes as possible than none. It's ultimately up to me as to
whether I want to consume these updates anyway.

>
> Don't mistake one awkward piece of software which is not supported in
> the other distros for the general properties of those distros. Gentoo
> is good for tweaking, it's good for doing "Your own thing", that does
> not make it automagically better than Debian or RHEL, or SLES in the
> high-stability stakes. And, sorry to say this, one nice anecdote
> doesn't either.

I'm glad you thought the anectode was nice - there are plenty more
where that came from :) Seriously though, I consider the packages in
Gentoo to exhibit much greater stability in terms of exhibiting
performant and bug-free operation and am very happy with it. I concur
that there is no single property of a given distro that makes it
automatically "better" or "worse" than another. Yet there is a lot of
unsubstantiated bullshit that gets bandied around about Gentoo, and
other systems are seldom called out on their weaknesses. If Debian,
RHEL or SLES suit anyone else's needs better than great. I still stand
by my original post and am delighted to be doing my "own thing", as
you put it. To each their own.

Cheers,

--Kerin



  parent reply	other threads:[~2008-10-01 15:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30 16:17 [gentoo-server] Server Packages for Gentoo BRM
2008-09-30 17:28 ` Robert Bridge
2008-10-01 10:55   ` Kerin Millar
2008-10-01 14:34     ` Robert Bridge
2008-10-01 14:48       ` Spahn, Daniel
2008-10-01 15:23       ` Kerin Millar [this message]
2008-10-02  9:20       ` Pavel Labushev
2008-10-03 14:35       ` kashani
  -- strict thread matches above, loose matches on Subject: below --
2008-10-01 14:51 BRM
2008-10-01 15:10 ` Arturo 'Buanzo' Busleiman
2008-10-01 13:16 BRM
2008-09-30 17:36 BRM
2008-09-30 18:10 ` Spahn, Daniel
2008-09-30 20:51 ` Ajai Khattri
2008-09-30 14:43 BRM
2008-09-30 15:05 ` Graham Murray
2008-09-29 17:48 Spahn, Daniel
2008-09-30  8:28 ` Ramon van Alteren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=279fbba40810010823v34ce2ee1ta04cfe062abd280c@mail.gmail.com \
    --to=kerframil@gmail.com \
    --cc=gentoo-server@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox