Red Hat's Michael Tiemann On gcc, ReiserFS & More

Mayank points to this interview at FreeOS.com with Red Hat CTO Michael Tiemann, in which Tiemann discusses why the Hat shipped a development kernel with their 7.0 distribution, journaling filesystems, the openness of ecos, and the competition (no, not that competition). It's a good read, though it would be cool to see the same questions addressed at even greater length. Guess everyone has a time limit, though;) [Updated by timothy:] I flubbed, that should read "development snapshot of gcc," of course, not "development kernel." Stop hitting me.

Comments

That makes complete sense, in context

[miniver]

The embedded marketplace is very different from your typical computer/os/software/hardware market. In the embedded market, the developer typically ends up hard-linking his application into the OS, since both pieces are going to be jammed into the same EPROM (or Flash if you've got the budget). To save space, often the developer will decide which OS services he needs, and discard the rest (ie: if you're not building a network appliance, why load the ethernet drivers?) An embedded OS is really more like a development framework -- it gives your application the tools it needs to function without the programmer having to implement those tools from scratch.

If you attempt to GPL the kernel to an embedded OS, then you're going to force developers to release all of their source code, simply because they linked their code with the OS. If you put this restriction on an embedded OS, then no embedded developers will buy your OS, no matter how good it is. On the other hand, either LGPL or MPL can be commercially viable, while still encouraging developers to contribute.

Are you moderating this down because you disagree with it,

Re:what other distributions?

[Ed Avis]

Use a development snapshot of gcc, so that C++ programs compiled on RH7 only work on RH7.

Boo hoo. So the C++ ABI has changed from one version of gcc to another - so what? It wasn't a fixed standard in the first place. If you are relying on implementation-defined details like this you will surely get bitten sooner or later.

Again change their RPM binary format (for the utterly stupid reason that it now supports bzip2 compression), so RH7 RPMs only work on RH7.

Just get RPM 3.0.5 which is forwards-compatible with 4.0.

Use a glibc2.2 development snapshot, so that again, their RPMs only work on RH7.

Red Hat have upgraded the C library in the past, what's so wrong with doing it this time? Surely you don't advocate that we should all still be on libc4 in order to keep binary compatibility?

Re:Interview

[LizardKing]

You're obviously clueless, but I'll bite. After all I am on my lunchbreak ...

Compare this with Windows, which has test periods of a year or more for new Windows releases.

Would you really trust your company to a distro that ships a broken compiler?

Read bugtraq, and learn just how stable and secure those tested versions of Windows are. Not very. As for a `broken' compiler, try Visual C++ 5.0 which was notoriously broken. RedHat's GCC snapshot was only `broken' in the respect that it was binary incompatble with preceding versions and the upcoming version 3.0. They had very good reasons to ship a snapshot, not the least of which was the fact that it produced better object code than 2.95.2. The alternative was to stick with egcs-1.1.2, which is getting exceptionally long in the tooth. If you really want to criticise a Linux distributor for shipping dodgy compilers, then turn your attention to Mandrake. They shipped the Pentium optimised `pgcc', which is known to produce incorrect assembler output.

> > [Why the broken compiler?]
This doesn't make an eachway-incompatible compiler a good idea. What it does say, however, (his words not mine) is that
(a) the current compiler is a POS
(b) we're using an incompatible, and immediately obsolete compiler.

Doesn't really encourage you to use Linux, rather than say, Windows, *bsd or Solaris, does it - the current compiler sucks

It wont encourage you unless you know how poor Microsoft or Sun's compilers are. As for BSD you clearly are clueless, as they use aging versions of gcc. Microsoft have yet to produce an ANSI C compliant compiler, let alone an ANSI C++ compliant one. As for Sun's compiler suite, they no longer ship it by default with Solaris, and many of the companies I have worked for use gcc instead out of preference. In other words, they have a Sunpro licence, but don't bother installing it.

These patches are indicative of the unstable state of Linux development ... (see Mandrake for a desktop product, not that it's a patch on Windows or Mac)

Let's see - my desktop machine has not crashed once since I installed RedHat 6.2 on it four months ago. It has all the tools that my colleague's Windows PC has, and more (ever tried grep'ing or find'ing on a PC?). In the same time the programmer to my immediate left has reinstalled Windows twice, and the Mac programmer is lucky if he get four hours of uptime.

As for your inference that Windows software is easier to use, try Visual C++ some time. Their is no source control as standard, and the API's are dreadful (dodgy socket libraries for example).
Chris