Turbolinux CEO Sees A One-Distribution Future

Scooter[AMMO] was one of the first with this report: "According to Turbolinux CEO Paul Thomas, the future will see Linux boiled down to one generic distribution. Catch the scoop here. How can this claim be made? How can a system like Debian throw away all its guidelines to create a generic distribution? I won't give up apt, and I sure don't see RH accepting it. Why should Peter let the uber-stable power user-oriented Slackware head towards the bug infested hail-the-script-kiddies Red Hat? Standards are great, but aren't the ideals of different distributions what give Linux its flavour?"

Comments

Standardize on standards, not implementations!

[rdl]

If there's one thing the UNIX vs. Windows struggle
has taught over the past 20 years, it's that
when people and organizations standardize on
open standards, allowing multiple
interoperating implementations, the world ends up
a better place than when people standardize on
a given implementation.

The web would suck a lot more than it does if
instead of having HTML/HTTP they had instead said
"You must use NCSA Mosaic and CERN httpd".

Networking with TCP/IP vs. "whatever windows or
macs use at a given time"

Mail with rfc822/smtp vs. forcing everyone to
use Eudora, Exchange, etc....

Linux already HAS a common standards base, with
the LFS/LSB, a common kernel (I suppose logically
it should just be a common kernel interface, with
different people implementing kernels...mmm,
freebsd kernel under the hood...actually, an
LSB-standard which treated BSD linux emu as an
equal player would be nice!).

Major distributions should adopt that, and other
meta-standards (each of the packaging formats
is well defined, so a tool like debian's "alien"
should be able to work across them. Adding
extra data to .tgz's to allow them to be
converted to fully functional .rpms and .debs, etc. would be another step). What makes
Debian, Red Hat, etc. worthwhile as independent
entities is not just the bits on the disk as
an end product...the distinct marketing and
support focuses, their internal priorities, etc.,
allow users to benefit.

The "non-big-four" distributions are already basing themselves to a great degree on tools and
such provided by the "big four", customizing
marketing, implemntation, support to provide
additional value to users. (I must say I'm
slightly annoyed to see Caldera and TurboLinux
in the big-four, but not Debian...I think it's
because the original article was related to
an investor conference, and there's not yet
a major commercial Debian reseller, but
from a decision-making standpoint, the total
number of users is more important than value
of someone's stock)

Consistency, yes. Merging, no.

Re:Standardize on standards, not implementations!

[tytso]

Standards are important, and yes, that's what the Linux Standards Base is trying to do. The problem, though, is that a modern OS system has a huge number of standards, and trying to formally write them down on paper is a major task. It's a lot more than just writing down the C prototypes (although even looking at the number of C functions in libc alone is frightening); it's also documenting all of the behavioural details --- what happens in the corner cases, what the error returns are, etc., etc., etc.

And even that isn't enough to catch some compatibility problems. The classic problem in the libc 5.x days was one the stdio implementation was "cleaned up". Unfortunately, the rewrite caused programs that happened to fclose() a file pointer twice to core dump --- and netscape happened to be one of these programs. Now, calling fclose() twice violates the ANSI C specifications. It was clearly netscape which was in the wrong. But as far as users were concerned, when they upgraded to the latest version of libc 5.x, netscape broke, so it was obviously libc's fault. And from the point of view of an ISV, it's very uncomfortable to have to supply programs to a platform which can unpredictably change the rules of what's acceptable or not, even if you're in the wrong. Even the breaking of bug-comaptiblity has to be done during major version number bumps, under very carefully controlled circumstances.

Yes, this is hard; but if Linux is going to play in the big leagues, that's what's we're going to need if we want the likes of Intuit to make programs like TurboTax or Quicken to be available on Linux. (And I very much doubt that the Open Source community is going to ever provide an OSS version of TurboTax --- because it's more about having tax accounts and lawyers, which don't come cheap, and because tax code is constantly mutating.)

The other important thing to remember is that having 10 different distributions all tracking the same bug fixes in glibc and gcc and shellutils and textutils is a waste of engineering resources. Distributions distinguish each other by their installer, and their system administration tools, etc. They don't distinguish themselves (at least in a positive way, anyway) by which version of gawk or glibc or gcc they ship --- and happily enough, that's the sort of thing which standardizing will help the ISV compatibility problem.

So it's a win-win-win solution. The distributions win, because they can reduce their engineering costs. The ISV's win because they can only ship one version of their application, instead of one version for Red Hat, one version for Debian, one version for SuSE, etc. And the users win, because Linux remains unified, instead of getting fragmented like the other Unices did the last time the Unix wars were fought. (And remember, whenever we engage in this kind of intermural fighting, Microsoft ends up winning.)

OSSBS - Operating System Standard Base Structure

[ElvenKnight]

I've had these ideas for awhile now, and I'm sick of watching all this fragmentation happening in the market... so I give this one away for free, right here.. right now. Take notes. Contact me for further and more elebrate details.

Making a generic distro is EASY.

Why?

Because they are all based on UNIX and we have symbolic links.

Make a script file that goes thru every directory and file, taking note of them and their location.
Do that to every distro. You will then have a listing of all the files and their location within every distro. Do that for Standard, Advanced, and certain custom installations.

Do a simple "diff" with a script on those textfiles lists to filter out all the files that do have standard locations.

Have the script file account for the difference between a link and an actual file.

Fill in the gaps of difference between all distros using symbolic links. Ensuring that no matter which distro an application or .RPM or .DEB or .TGZ may be for... it will always find the files and library files and paths, etc it needs to find.

The biggest mess will be /etc. But in reality, there isn't a whole heck of alot to do there, and its directory is small. You could actually have many different /etc's if you wanted to... linking in the different directory strucutres for the rc.d scripts and switching distro-personalities on the fly with a simple setup.

Then all the slow and bloated and confused LSB has to do is just come to certain terms on what to do within the /etc to make things standard, or at least compatible with each other.

What LSB and othe organziations fail to realize is that the longer distros are fragmented, the more so they will become fragmented. A work around solution like symbolic links (which is already done anyway on all distros, just not to the extreme logical conclusion they need to be done at)... is the best thing to do TODAY.

At that point, we can then take our time to figure out where the actual PHYSICAL files should be kept and the paths that should be considered STANDARD within the see of solid and symbolic links within our UNIX system.

A map of this Standards base can then be created and files and links and then be replaced and moved on the fly with a simple script.

This map can eventually be used by 3rd party developers so that while the Distro makers squabble over who's right and wrong about how things can be done... The developers in the meantime have something they can savely work with and be sure that it'll work on Redhat, Mandrake, Debian, Corel, TurboLinux, Slackware, etc.

My plans go much deeper. I have detailed a way to create a standards base for ALL OPERATING SYSTEMS with such extreme logic, that I doubt few people would complain with the new way Operating systems and their folders and how applications and data and user data and configuration files, etc can and SHOULD be stored in relation to the root directory of ANY operating system.

I definitely invite discussion to say the least.

-Matthew
Technetos, Inc.

Why would we? Noone else does.

[Minupla]

The concept of different distributions targeted at different types of users is very commonplace in this industry, why would Linux be any different?

To look at M$, we currently have Win98, W2K, Win Millenium, NT4, and even NT 3.51 still in use in a lot of places for different sorts of users and applications. Mac is going the same way. BSD has more distros then you can shake Tiamat at. Solaris has workstation and server distributions too.

One distro is never going to be everything to everyone. So what? I've never understood distro wars myself. I think each distro offers something to a certin group of users.


----
Remove the rocks from my head to send email

Thomas: "This Has To Grow Up."

[David Hume]

I'm surprised nobody has commented on the statement by Thomas that:

"For a long time, Linux was dominated by hackers and somewhat of a less organized group. The result is a slowdown in innovation and a reluctance in enterprises to accept this solution," he said. "This has to grow up."

The fact that Linux has been "dominated" by hackers is, according to Thomas, a problem? That fact has slowed innovation?

Sorry, but without the hackers there would be no Linux as we know it, much less innovation. Who else was going to do it? Who else, in fact, did it? Not to denigrate the current contributions of IBM, et al., but they were late to the party, and came only when a large amount of value had already been created.

Since the domination by hackers has, to date, led to a "slowdown in innovation," let's see what Turbolinux has contributed back to the community. Let us consider EnFuzion 6.0. According to the EnFuzion(TM)Software LICENSE AGREEMENT:

"The EnFuzion(TM) software (the "Software") is a proprietary product of TurboLinux. * * * You may not copy (except as expressly permitted in Section 2), modify, or create derivative works of the Software."

How about TurboCluster Server 4.0. According to section 1.16 of the TurboCluster Server 4.0 FAQ:

The Advanced Traffic Manager application, turboclusterd, will be released under the TurboLinux Software License. Source code for this component will not be released and redistribution of this component is not allowed.

What "innovation" has Turbolinux contributed back to the community? My question is not rhetorical. I don't know.

And what does, "[t]his has to grow up" mean? Centralized control? Linux has a benevolent dictator. Perhaps corporate control?