Anybody using CentOS?


--
*===( http://www.400monkeys.com/God/
*===( http://principiadiscordia.com/
*===( http://www.slackware.com/

On Wed, 21 Oct 2009, Mike Jones wrote:

> Anybody using CentOS?

Not privatly, but at work we use CentOS on some of our Dell
servers/blades. At the moment it's quite outdated, we are waiting for
CentOS 5.4 which will bring a more up to date kernel and KVM.

CentOS ain't anything I would recommend for desktop use, you want
something which is more up to date and not as on the edge as Fedora (of
course much of the stuff you find in Fedora will one day end up in RHEL
and thous into CentOS too).


--

//Aho

On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody identifying
as J.O. Aho wrote...

> On Wed, 21 Oct 2009, Mike Jones wrote:
>
>> Anybody using CentOS?
>
> Not privatly, but at work we use CentOS on some of our Dell
> servers/blades. At the moment it's quite outdated, we are waiting for
> CentOS 5.4 which will bring a more up to date kernel and KVM.
>
> CentOS ain't anything I would recommend for desktop use, you want
> something which is more up to date and not as on the edge as Fedora
> (of course much of the stuff you find in Fedora will one day end up in
> RHEL and thous into CentOS too).

More or less the same scenario here. We're currently running CentOS 5.3
on our servers, but I'm not really a fan of it - nor of Fedora or
RedHat for that matter, due to their installer refusing to support any
other types filesystems than ext2, ext3 or ext4 for installation of the
system itself. It - i.e. the installer - doesn't allow you to create
any reiserfs, XFS or JFS partitions or mount them anywhere in the tree
if they already exist.

For a workstation installation, I would rather recommend Mandriva or any
of its spinoffs - although PCLinuxOS is rather conceived as a
typical "home desktop"-kind of system by default - or maybe (Open)SuSE
or Sabayon, which is Gentoo-based. For the more experienced user, I
would perhaps suggest Gentoo itself, Slackware - provided that you're
happy settling with a 32-bit only operating system - or Debian.

CentOS is pretty stable and reliable for server use, and that's why my
colleagues prefered it, and why I consented to using it on our servers,
but it's definitely not quite what you would want for a workstation.

--
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:
> On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
> Slackware - provided that you're happy settling with a 32-bit only
> operating system.

Slackware comes in both 32-bit and 64-bit flavour now.

Responding to trselmer:

> Aragorn wrote:
>> On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody
>> identifying as J.O. Aho wrote...
>>
>> Slackware - provided that you're happy settling with a 32-bit only
>> operating system.
>
> Slackware comes in both 32-bit and 64-bit flavour now.


I'm actually a huge fan (and user) of Slackware (note the sigline).
However, I'm just playing around with a few distros, trying to see if
there is anything easier to install'n'use than my prototype SlackMods.sh
customising package for Slackware. I think, based on my fun'n'games with
CentOS so far, and as CentOS was the last-to-check in my list of non-
Slackware OSs, I'll finish polishing up my SlackMods package.

Thanks for the info you guys. Cheers.

--
*===( http://www.400monkeys.com/God/
*===( http://principiadiscordia.com/
*===( http://www.slackware.com/

On 2009-10-21, Mike Jones <Not@Arizona.Bay> wrote:
> Responding to trselmer:
>
>> Aragorn wrote:
>>> On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody
>>> identifying as J.O. Aho wrote...
>>>
>>> Slackware - provided that you're happy settling with a 32-bit only
>>> operating system.
>>
>> Slackware comes in both 32-bit and 64-bit flavour now.
>
>
> I'm actually a huge fan (and user) of Slackware (note the sigline).
> However, I'm just playing around with a few distros, trying to see if
> there is anything easier to install'n'use than my prototype SlackMods.sh
> customising package for Slackware. I think, based on my fun'n'games with
> CentOS so far, and as CentOS was the last-to-check in my list of non-
> Slackware OSs, I'll finish polishing up my SlackMods package.
>
> Thanks for the info you guys. Cheers.

Just a note from the other point of view: I do use CentOS at home, and RHEL at
work. I *like* the shelf-life of CentOS compared to Fedora and I am running a
server at home that manages mail, dhcp, bind, web, etc for the home computers.
Because of that, I don't want to be upgrading every 6-12 months...

Kevin

On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <user@example.net>
wrote:

>On Wed, 21 Oct 2009, Mike Jones wrote:
>
>> Anybody using CentOS?
>
>Not privatly, but at work we use CentOS on some of our Dell
>servers/blades. At the moment it's quite outdated, we are waiting for
>CentOS 5.4 which will bring a more up to date kernel and KVM.
>

Wait no more!!

http://lists.centos.org/pipermail/ce...er/016195.html

dreaded wrote:
> On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <user@example.net>
> wrote:
>
>> On Wed, 21 Oct 2009, Mike Jones wrote:
>>
>>> Anybody using CentOS?
>> Not privatly, but at work we use CentOS on some of our Dell
>> servers/blades. At the moment it's quite outdated, we are waiting for
>> CentOS 5.4 which will bring a more up to date kernel and KVM.
>>
>
> Wait no more!!
>
> http://lists.centos.org/pipermail/ce...er/016195.html
>

We got really disappointed, no kernel 2.6.27 with xen dom0 support, and Xen
3.0.3... this forces us to build own RPMs to be able to run BSD based VMs.
KVM just 0.83...


--

//Aho

Responding to Kevin Collins:

> On 2009-10-21, Mike Jones <Not@Arizona.Bay> wrote:
>> Responding to trselmer:
>>
>>> Aragorn wrote:
>>>> On Wednesday 21 October 2009 14:09 in alt.os.linux, somebody
>>>> identifying as J.O. Aho wrote...
>>>>
>>>> Slackware - provided that you're happy settling with a 32-bit only
>>>> operating system.
>>>
>>> Slackware comes in both 32-bit and 64-bit flavour now.
>>
>>
>> I'm actually a huge fan (and user) of Slackware (note the sigline).
>> However, I'm just playing around with a few distros, trying to see if
>> there is anything easier to install'n'use than my prototype
>> SlackMods.sh customising package for Slackware. I think, based on my
>> fun'n'games with CentOS so far, and as CentOS was the last-to-check in
>> my list of non- Slackware OSs, I'll finish polishing up my SlackMods
>> package.
>>
>> Thanks for the info you guys. Cheers.
>
> Just a note from the other point of view: I do use CentOS at home, and
> RHEL at work. I *like* the shelf-life of CentOS compared to Fedora and I
> am running a server at home that manages mail, dhcp, bind, web, etc for
> the home computers. Because of that, I don't want to be upgrading every
> 6-12 months...
>
> Kevin


Thats one of the things I like about Slackware. You don't need to be
doing that constant upgrade thing. Just slap in the odd security patch
when they come up for critical things, which isn't often.


--
*===( http://www.400monkeys.com/God/
*===( http://principiadiscordia.com/
*===( http://www.slackware.com/

On Thursday 22 October 2009 06:27 in alt.os.linux, somebody identifying
as J.O. Aho wrote...

> dreaded wrote:
>
>> On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <user@example.net>
>> wrote:
>>
>>> On Wed, 21 Oct 2009, Mike Jones wrote:
>>>
>>>> Anybody using CentOS?
>>>
>>> Not privatly, but at work we use CentOS on some of our Dell
>>> servers/blades. At the moment it's quite outdated, we are waiting
>>> for CentOS 5.4 which will bring a more up to date kernel and KVM.
>>
>> Wait no more!!
>>
>> [long URL]
>
> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
> and Xen 3.0.3... this forces us to build own RPMs to be able to run
> BSD based VMs. KVM just 0.83...

Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also a
RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0 - so
my advice for Xen would be to wait until either the distribution
carries a 2.6.30 or later kernel, or else - which is what I recommend -
build a 2.6.30 or newer kernel with dom0 support from sources. And
while you're at it, get Xen 3.3 from xen.org directly - it comes as
either sources or as an .rpm or .deb package.

Desktop-oriented distributions typically mess up a lot by means of the
additional "enhancement" patches they apply to the vanilla kernel -
this is something you will not see with CentOS or Slackware - which may
and often do introduce instabilities in the kernel, making it less
suitable for use on a server. [1]

This is one of the reasons why I prefer building a kernel from the
vanilla sources, and in this particular case, you would have a kernel
that supports all of your hardware and that can be used as a Xen dom0 -
2.6.18 is stable but is really outdated with regard to hardware
support.

YMMV... :-)


[1] By the same token, I also hate stuff like /hald/ and the whole
automounting of storage devices. In my humble opinion - or maybe
not so humble in this particular case - that stuff is just more
Windows'ism creeping into GNU/Linux.

--
*Aragorn*
(registered GNU/Linux user #223157)

On Thu, 22 Oct 2009 12:34:08 +0200, Aragorn <aragorn@chatfactory.invalid> wrote:

....
>Desktop-oriented distributions typically mess up a lot by means of the
>additional "enhancement" patches they apply to the vanilla kernel -
>this is something you will not see with CentOS or Slackware - which may
>and often do introduce instabilities in the kernel, making it less
>suitable for use on a server. [1]
>
>This is one of the reasons why I prefer building a kernel from the
>vanilla sources, and in this particular case, you would have a kernel
>that supports all of your hardware and that can be used as a Xen dom0 -
>2.6.18 is stable but is really outdated with regard to hardware
>support.

First thing I do after an install is create the custom kernel to suit
the hardware -- been working well for me for a dozen years :)
>
>YMMV... :-)

So true -- one has to put in a little more effort to get what one
wants out of linux. I've been happy with slackware since 9.0, before
that I stayed with redhat 6.2 for some years, skipping the worsening
7, 8 and 9 series, and disappointed by fedora.
>
>
>[1] By the same token, I also hate stuff like /hald/ and the whole
> automounting of storage devices. In my humble opinion - or maybe
> not so humble in this particular case - that stuff is just more
> Windows'ism creeping into GNU/Linux.

Automounting can be turned off in custom kernel. I don't have too
many portable devices to care about anyway. Happy to see USB sticks
and my cameras as mass storage, manually mounted.

Grant.
--
http://bugsplatter.id.au

On Thursday 22 October 2009 12:50 in alt.os.linux, somebody identifying
as Grant wrote...

> On Thu, 22 Oct 2009 12:34:08 +0200, Aragorn
> <aragorn@chatfactory.invalid> wrote:
>
>> [1] By the same token, I also hate stuff like /hald/ and the whole
>> automounting of storage devices. In my humble opinion - or maybe
>> not so humble in this particular case - that stuff is just more
>> Windows'ism creeping into GNU/Linux.
>
> Automounting can be turned off in custom kernel. I don't have too
> many portable devices to care about anyway. Happy to see USB sticks
> and my cameras as mass storage, manually mounted.

Well, insofar as I know, automounting is not a kernel issue - there are
some implementations of automounting in the kernel for networked
filesystems on servers which may not always be available, but this is
generally not the approach used for removable storage devices - but
rather a /udev/ and /hald/ issue.

For my "project" - I might as well call it that, since it pertains to a
machine that still requires hardware that still needs to be delivered,
et al; long and frustrating story... - I am contemplating read-only
root filesystems - it'll be a Xen machine - and for that I would
need /udev./ However, I would be more than happy to do without /udev/
altogether if I could get away with it.

Hmm... <brain at work> Maybe I could create a minimal number of static
device nodes in the */dev* directory on the root filesystem for when
the system boots up and then have the root filesystem mounted
read-only, with an additional on-disk device filesystem mounted on
*/dev,* similar to how /udev/ does it, but without the "conditional"
nature of the existence of the device special files...

Hmm... Intriguing thought... :-)

--
*Aragorn*
(registered GNU/Linux user #223157)

On Thu, 22 Oct 2009 13:03:36 +0200, Aragorn <aragorn@chatfactory.invalid> wrote:

>On Thursday 22 October 2009 12:50 in alt.os.linux, somebody identifying
>as Grant wrote...
>
>> On Thu, 22 Oct 2009 12:34:08 +0200, Aragorn
>> <aragorn@chatfactory.invalid> wrote:
>>
>>> [1] By the same token, I also hate stuff like /hald/ and the whole
>>> automounting of storage devices. In my humble opinion - or maybe
>>> not so humble in this particular case - that stuff is just more
>>> Windows'ism creeping into GNU/Linux.
>>
>> Automounting can be turned off in custom kernel. I don't have too
>> many portable devices to care about anyway. Happy to see USB sticks
>> and my cameras as mass storage, manually mounted.
>
>Well, insofar as I know, automounting is not a kernel issue - there are
>some implementations of automounting in the kernel for networked
>filesystems on servers which may not always be available, but this is
>generally not the approach used for removable storage devices - but
>rather a /udev/ and /hald/ issue.
>
>For my "project" - I might as well call it that, since it pertains to a
>machine that still requires hardware that still needs to be delivered,
>et al; long and frustrating story... - I am contemplating read-only
>root filesystems - it'll be a Xen machine - and for that I would
>need /udev./ However, I would be more than happy to do without /udev/
>altogether if I could get away with it.

I think you still can, turn off udev and populate /dev with the nodes
you need and do the 'classic' /etc/fstab partition mount control.

You might intercept the kernel's callouts to /sbin/(i forget name of
handlers) for udev and hald too.
>
>Hmm... <brain at work> Maybe I could create a minimal number of static
>device nodes in the */dev* directory on the root filesystem for when
>the system boots up and then have the root filesystem mounted
>read-only, with an additional on-disk device filesystem mounted on
>*/dev,* similar to how /udev/ does it, but without the "conditional"
>nature of the existence of the device special files...

Yes. The older methods are still available, perhaps look at the
kernel's embedded options to turn off some of the desktop support
'smarts'?

Grant.
--
http://bugsplatter.id.au

Aragorn wrote:
> On Thursday 22 October 2009 06:27 in alt.os.linux, somebody identifying
> as J.O. Aho wrote...
>
>> dreaded wrote:
>>
>>> On Wed, 21 Oct 2009 14:09:08 +0200, "J.O. Aho" <user@example.net>
>>> wrote:
>>>
>>>> On Wed, 21 Oct 2009, Mike Jones wrote:
>>>>
>>>>> Anybody using CentOS?
>>>> Not privatly, but at work we use CentOS on some of our Dell
>>>> servers/blades. At the moment it's quite outdated, we are waiting
>>>> for CentOS 5.4 which will bring a more up to date kernel and KVM.
>>> Wait no more!!
>>>
>>> [long URL]
>> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
>> and Xen 3.0.3... this forces us to build own RPMs to be able to run
>> BSD based VMs. KVM just 0.83...
>
> Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
> the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also a
> RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0 - so
> my advice for Xen would be to wait until either the distribution

As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the 2.6.30
had been nice, but don't have time to maintain a kernel RPMs myself and I
wouldn't be surprised that RHEL/CentOS 5.x will be forever stuck with the 2.6.18.


> carries a 2.6.30 or later kernel, or else - which is what I recommend -
> build a 2.6.30 or newer kernel with dom0 support from sources. And
> while you're at it, get Xen 3.3 from xen.org directly - it comes as
> either sources or as an .rpm or .deb package.

As depending on 3rd party application to run on the dom0, can't just install
what ever I would like, or else they won't care with as much support as they
do today and I think I would have gone with 3.4 instead, better to run bsd domu.


> Desktop-oriented distributions typically mess up a lot by means of the
> additional "enhancement" patches they apply to the vanilla kernel -
> this is something you will not see with CentOS or Slackware - which may
> and often do introduce instabilities in the kernel, making it less
> suitable for use on a server. [1]

RHEL/CentOS glibc depending on gd, which in it's turn depends partly on
X-libs. There are tons of applications I don't think should be installed on a
server and CentOS does that, even starting with suggesting that you should
installed over bloated gnome2.


> This is one of the reasons why I prefer building a kernel from the
> vanilla sources, and in this particular case, you would have a kernel
> that supports all of your hardware and that can be used as a Xen dom0 -
> 2.6.18 is stable but is really outdated with regard to hardware
> support.

We experienced real instability and random crashes and reboots with Dom0 using
iscsi.


> [1] By the same token, I also hate stuff like /hald/ and the whole
> automounting of storage devices. In my humble opinion - or maybe
> not so humble in this particular case - that stuff is just more
> Windows'ism creeping into GNU/Linux.

I have to agree and hald has made device configuration far more difficult than
before, for example my desktop had just the Xorg with one section where to
configure keyboard, but with hald I have 3 different files and each of those
with a lot of crappy xml forcing to use try and error to see what works and
what don't. On my laptop I can't get the touchpad to work the same way as I
used to have it, it seems like sometimes hald do read some of my settings,
next moment it just ignores them and suddenly a double tap don't make a
middle-mouse-button anymore, but randomly teleports the cursor to another
section of the screen.

No, hald was a big step backwards, I guess we will have gnome2 style register
files everywhere in a soon future... then we will be a more true ms-windows
clone, as the gnome2 developers wishes.

--

//Aho

On Thursday 22 October 2009 17:46 in alt.os.linux, somebody identifying
as J.O. Aho wrote...

> Aragorn wrote:
>
>> On Thursday 22 October 2009 06:27 in alt.os.linux, somebody
>> identifying as J.O. Aho wrote...
>>
>>> We got really disappointed, no kernel 2.6.27 with xen dom0 support,
>>> and Xen 3.0.3... this forces us to build own RPMs to be able to run
>>> BSD based VMs. KVM just 0.83...
>>
>> Xen dom0 support is only available in vanilla Linux as of 2.6.30 on -
>> the xen.org-supplied dom0 kernel is just a 2.6.18, and there are also
>> a RedHat-patched 2.6.20 and an Ubuntu-patched 2.6.22 for use in dom0
>> - so my advice for Xen would be to wait until either the distribution
>> [...
>
> As far as I know, Suse had a 2.6.27 kernel with the Xen patches, the
> 2.6.30 had been nice, but don't have time to maintain a kernel RPMs
> myself and I wouldn't be surprised that RHEL/CentOS 5.x will be
> forever stuck with the 2.6.18.

Well, you don't /have/ to maintain any kernel RPMs. Just fetch the
vanilla sources from kernel.org, unpack the tarball, do a...

make menuconfig

.... or...

make xconfig

.... and set up the kernel for your hardware. Then all you need to do
is...

make

.... and then...

make modules_install install

.... and reboot. ;-)

Of course, you will also first need to install Xen itself (and the Xen
tools), but that's a piece of cake. ;-)

>> ...] carries a 2.6.30 or later kernel, or else - which is what I
>> recommend - build a 2.6.30 or newer kernel with dom0 support from
>> sources. And while you're at it, get Xen 3.3 from xen.org directly -
>> it comes as either sources or as an .rpm or .deb package.
>
> As depending on 3rd party application to run on the dom0, [...

That's a bad idea. dom0 should be kept as clean as possible. It should
run the bridging or routing but it shouldn't even be set up to accept
any incoming traffic except for /ssh/ - which should be allowed to come
from the local LAN or any of the domUs anyway, but never directly from
the internet.

> ...] can't just install what ever I would like, or else they won't
> care with as much support as they do today and I think I would have
> gone with 3.4 instead, better to run bsd domu.

3.4? Oops, I'd better check the website again then, because I thought
that 3.3 was the latest official version. ;-)

>> Desktop-oriented distributions typically mess up a lot by means of
>> the additional "enhancement" patches they apply to the vanilla kernel
>> - this is something you will not see with CentOS or Slackware - which
>> may and often do introduce instabilities in the kernel, making it
>> less suitable for use on a server. [1]
>
> RHEL/CentOS glibc depending on gd, which in it's turn depends partly
> on X-libs. There are tons of applications I don't think should be
> installed on a server and CentOS does that, even starting with
> suggesting that you should installed over bloated gnome2.

Yeah, that is one thing I've noticed with our CentOS servers... My
colleague wanted to install hosting software - I have forgotten which
one because we've used different hosting software over the years, but I
think it might have been /virtualmin/ or /directadmin/ - which for some
reason insisted on X11 being installed as a dependency.

>> This is one of the reasons why I prefer building a kernel from the
>> vanilla sources, and in this particular case, you would have a kernel
>> that supports all of your hardware and that can be used as a Xen dom0
>> - 2.6.18 is stable but is really outdated with regard to hardware
>> support.
>
> We experienced real instability and random crashes and reboots with
> Dom0 using iscsi.

That should be resolved now, 13 kernel versions later than 2.6.18. ;-)
Vanilla Linux is already at 2.6.31.4 today. ;-)

That said, I have no experience with iSCSI. My Xen machine has a
combination of SAS disks and SATA disks, all local to the machine.

>> [1] By the same token, I also hate stuff like /hald/ and the whole
>> automounting of storage devices. In my humble opinion - or maybe
>> not so humble in this particular case - that stuff is just more
>> Windows'ism creeping into GNU/Linux.
>
> I have to agree and hald has made device configuration far more
> difficult than before, for example my desktop had just the Xorg with
> one section where to configure keyboard, but with hald I have 3
> different files and each of those with a lot of crappy xml forcing to
> use try and error to see what works and what don't. On my laptop I
> can't get the touchpad to work the same way as I used to have it, it
> seems like sometimes hald do read some of my settings, next moment it
> just ignores them and suddenly a double tap don't make a
> middle-mouse-button anymore, but randomly teleports the cursor to
> another section of the screen.
>
> No, hald was a big step backwards, I guess we will have gnome2 style
> register files everywhere in a soon future... then we will be a more
> true ms-windows clone, as the gnome2 developers wishes.

Well, Gnome users have scolded me for saying that Gnome looks more like
Windows - and in some versions, it really did - than KDE does, and I
have noticed that even on this PCLinuxOS 2009.2 system here, the GTK
apps have a somewhat "champagne-like" color to them, similar to Windows
XP. (Of course, neither Gnome nor KDE look anything as close to
Windows as LXDE.)

I've got this feeling - actually, I've been feeling this for a few years
already - that the newer batches of GNU/Linux users are just people who
absolutely love Windows but simply don't want to pay for it or deal
with its instabilities and malware infestations. So those are the
aspects that drive them from Windows to GNU/Linux, but in their hearts
they still want Windows, or "the next best thing" in look & feel to
that.

And of course, with only the negative aspects of Windows - insofar as it
pertains to the ones that are experienced as negative, without too much
thought having been spent on the why - being the incentive for those
users to start using GNU/Linux, they will still see a computer
according to the MICROS~1 single-user paradigm. I for one do not see a
computer that way.

I see a computer as a powerful multi-user machine, and I see GNU/Linux
as a genuine UNIX client/server multi-user architecture, and thus I
consider all that "plug & pray" (or "plug & panic") stuff a security
hazard. I also don't agree with any daemons modifying */etc/fstab* on
the fly just because you happen to plug in a USB stick. I'm allowing
it here on this machine but that's just because I consider this machine
a temporary solution, given that its hardware is flawed - it regularly
crashes, and lately that goes accompanied by blinking Shift Lock and
Scroll Lock lights on the keyboard (and Num Lock being switched off
when that happens), so it's definitely a hardware issue.

For a serious server and/or workstation however, I resent the whole plug
& play thing and the "let's regularly rewrite a few system files on the
root filesystem"-attitude. I prefer my system and its configuration as
static as possible. Besides, if I'm going to have my root filesystems
mounted read-only during normal operation, then all that automated
fiddling with */etc/fstab* wouldn't work anyway. */etc/mtab* is
another matter; you can make that a symlink to */proc/mounts.*

On another note, I would also like to see the OpenVZ patches be
submitted for inclusion in the vanilla kernel tree, because the
whole /kvm/ and /lguest/ approach is just another "me too" thing in the
area of virtual machine monitors. While /kvm/ may offer a
more "native" approach to virtual machine monitoring than VirtualBox or
VMWare - which are third-party products - it still follows the "home
desktop" paradigm rather than the server/workstation paradigm.

Xen paravirtualization (and hardware virtualization) support in vanilla
Linux was definitely a step in the right direction, but most
distributions don't carry or endorse Xen and instead supply things like
VirtualBox. OpenVZ is even a totally separate distribution on its own,
because none of the distros carry an OpenVZ kernel, other than Gentoo -
but that's a metadistribution, and that's a whole other story - or
possibly Debian, which probably has the largest repository of binary
packages. Yet, if you consider that FreeBSD has its own operating
system-level virtualization technology and that Solaris carries a
similar technology by default - i.e. the Solaris Containers - then
Linux as a kernel is lagging behind in this area. The patches exist,
so it should be trivial to include them in vanilla Linux.

There, I've just contributed my share of ranting again. :p

--
*Aragorn*
(registered GNU/Linux user #223157)