2c about the development of ubuntu

Ben Collins ben.collins at ubuntu.com
Sun Jan 1 17:59:55 GMT 2006

On Sun, 2006-01-01 at 18:31 +0100, Udo 'Robos' Puetz wrote:
> On Sun, 01.01.06, Ben Collins <ben.collins at ubuntu.com> wrote:
> Hello Ben and List.
> > On Sun, 2006-01-01 at 16:47 +0100, Udo 'Robos' Puetz wrote: 
> > > And why does ubuntu have to cater the servers? Doesn't debian do this *very*
> > > good? Why do you need 2.6.15 on a server? I think an admin should even be
> > > kicked for using this on a server! Leave debian a little breating space and
> > > the collaboration will be lots better.
> > 
> > Being a good server platform is not the same as what we are doing.
> > Debian is great for server admins because they can install just about
> > anything they want and tweak it to their hearts content.
> > 
> > Ubuntu-Server is a whole different type of server support. Our intention
> > is to get hardware certification. Something that has been hard to do for
> > Debian (through no fault of their own).
> That I don't really understand. We are talking linux here, as in kernel,
> right? I know that ubuntu, as debian, as fedora, suse and whoever, all have
> their patches that they apply to the vanilla kernel from kernel.org. I don't
> like this very much since it spreads the whole development/patch thing all
> over the place but Linus likes it and his word is law.
> But why does this certification have to be for the ubuntu kernel - instead
> of the debian kernel? Debian is sort of the foundation of a lot of distros -
> so a certified kernel there (with proper surroundings) would benefit a lot
> of distros and would make a better impact than an ubuntu certified kernel,
> wouldn't it? 

For starters, our kernel is nothing like Debian's. As for patches, we
add a lot of external drivers to help make things "work". We don't just
go changing the core of the kernel. Any patches we make against the
mainline kernel, goes right to the kernel developers.

To answer your question, no this is not about certifying the kernel.
it's about certifying the distribution as a whole. A hardware vendor
needs to be able to say "DistFoo is certified on our hardware".
Certification is a very complex issue, and I think you are over
simplifying it.

> I know few about these high end machines but I had to install oracle 9.2i
> and 10g on some small 19'' machine recently and (company decision) had used
> fedora for this. Fedora isn't "certified" and yet it is the foundation of
> redhat enterprise server and that is certified. All I had to do was
> increment some values (max threads and such) and install some packages and
> it worked.

Whether it worked or not is not the issue. The issue is, if it breaks,
who is going to fix it? If you can't, then you'll need to call someone.
Who will that someone be? If it's Oracle, they might tell you that it's
not their fault, you need to contact your OS vendor or hardware vendor.
Who do you call then? Hardware vendor wont give you support for any OS
you decide to install and Fedora has no support other than mailing lists
and such.

> > An admin that wants Debian running on the companies high dollar database
> > server is going to find it very hard to get support from the hardware
> > vendor and from the application vendor (say Oracle for example). If they
> > could install Ubuntu-Server, with full support from us, and support from
> > the hardware and application vendor, then they are happy (they get a
> > Debian based dist), the vendors are happy, and the company running the
> > system is happy (and, of course, we are happy :)
> Regarding my comment above, you will inject that oracle won't help me
> because I used a non-certified distro. But this is the real thing:
> do we want to follow the stupid game the "big companies" play and pride us
> with being "certified" - although we run the same kernel and libc as any
> other disto or do we force them - yes, linux and the distros have that power
> already in my humble opinion - to "certify" linux-2.6.15.tar.bz2 straight
> from kernel.org and libc from gnu.org? With all the standardisation going on
> with freedesktop.org, FHS and such - do we need to certify certain distros?
> I mean, to some win admin or old-school unix admin a "certified" distro
> might look sexy and might legitimate his decision to spend 1000$ on rhe, but
> we, you and - I hope - me, know that this is rubbish. 

Again, you are over simplifying. No matter what you do, each distro has
it's own subtleties. When you call for support on these issues, they
need to know exactly what you are running, so that they can help you fix
your problem. If they said "every system running kernel x.x.x and libc
y.y.y is certified", then you could homebrew your own system, and they
would have to support it, regardless of whatever else you installed.

That's an impossibility for any hardware vendor to do. It's easy for an
ethernet card manufacturer to say "Our product works with kernel 2.6.15
drivers", but that is a far cry from IBM selling you a $30k server and
saying, you can run anything you want as long as it has this kernel, and
we will support you completely.

Certification for a distro on hardware isn't an elitist game, it's about
providing consistency that the customer and vendors can count on. It
makes support easier, it makes resolving issues easier, and it makes
everyone's life better. In the end, that means cheaper. You can't force
vendors to have such blanket support. They simply wont do it, and I
personally don't blame them.

Take for example, the linux kernel itself. For starters, any binary
driver loaded causes the kernel to consider itself TAINTED. When this
happens, the kernel developers wont support it.

Consider the same is true for a hardware vendor. If you run an OS they
don't support, then the hardware is tainted, and they wont support it.

> > Ubuntu-Server isn't meant to replace Debian running on your i486 box
> > doing firewall for your home LAN (although you're welcome to use it
> > there, and we appreciate it), since you can already do that with Ubuntu.
> > It's a much more focused effort to go where Debian usually can't.
> > 
> > Disclaimer: I'm speaking as the kernel maintainer, not as someone who
> > actually makes these decisions. I could be a little off on what
> > Ubuntu-Server is all about, but I think this is the general idea.
> > 
> > Also, why wouldn't someone run 2.6.15 on a server?
> Because it hasn't been tested well enough? Why shouldn't you have run 2.4.13 
> (mind the 4) on the day of it's release? Because that would have been *sort
> of* bad...

I beg to differ. The 2.6.15 kernel has been tested during it's entire
release cycle. Plus, 2.6.15 wont be so new when Ubuntu-Server is
released (dapper release). That's not until April, and 2.6.15 should be
final any time now. That means 2.6.15 will be 3 months old when we
release with it. In fact, by that time, 2.6.16 will be almost done as
well. So you will be running a kernel that is aged just enough to be

   Ben Collins <ben.collins at ubuntu.com>
   Ubuntu Linux

More information about the ubuntu-devel mailing list