Ask Donald Becker

This is a "needs no introduction" introduction, because Donald Becker is one of the people who has been most influential in making GNU/Linux a usable operating system, and is also one of the "fathers" of Beowulf and commodity supercomputing clusters in general. Usual Slashdot interview rules apply, plus a special one for this interview only: "What if we made a Beowulf cluster of these?" is not an appropriate question.

Re:One question...

[Anonymous Coward]

He wrote most of the ethernet drivers for linux, so he might be a slightly biased.

Re:Role of GNU in GNU/Linux

[Anonymous Coward]

The kernel is the core piece of the OS, and it wasn't developed by GNU. Yes, GNU tools are used to build the kernel, but the kernel itself, the core of the OS, is not GNU produced. Each distribution may or may not include GNU tools, and if someone releases a GNU-less distribution, is it still GNU/Linux? I don't think so.

Great timing for a change also, with all the new users coming to this OS. Let's confuse them.

So why call it GNU/Linux? Just to satisfy the ravings of RMS who can't get enough attention to his political (not technical) causes by himself.

Re:Role of GNU in GNU/Linux

[dozer]

This is not a good question for Donald Becker or any kernel hacker. His answer will probably be along the lines of, "Linux? GNU/Linux? Who cares?" Of course, it would be worse if he actually had an opinion on this tired, pointless argument.

Even Linus doesn't feel strongly one way or the other. The only person who seems to be working up a lather is RMS. It's sad.

Re:Role of GNU in GNU/Linux

[fault0]

Why don't you call it BSD/GNU/Linux, since many of the GNU tools are/were based on BSD derived equivalents. Without BSD implementions of much of UNIX's tools, many GNU equivalents would not have been created. For example, gawk was based on nawk (which was essentially a BSD implemention of awk). Perhaps AT&T and Bell Labs should be credited too. Without UNIX, there would never be any GNU.

Bell/AT&T/GNU/Linux forever!

Thanks for all the Ethernet drivers, Don!

[0x0d0a]

Thanks for all the drivers. There are a *lot* of people (including me, with two cards that use your drivers) that really appreciate what you've done.

Why is it?

[Jeremiah Cornelius]

Why is is that the Slashdot crew --and the Open Source world in general-- seem largely oblivious to your acheivements as a musician, composer and arranger?

It would be nice to have an anecdote or two about your years with Steely Dan - or even the solo projects from the '80's.

Re:Message Passing vs. Single System Image

[joib]

Programming MPI (i.e. message-passing) is slow, difficult and error-prone. But I'd say making the hardware and especially the operating system for a single system image computer with thousands of processors is even more difficult. Or hey, why stop at thousands of processors? IBM is designing their Blue Gene computer, with 1 million processors. How do you make a single kernel scale on a system like that?

The traditional approach is to use fine grained locking in the kernel, but this tends to lead to unmaintainable code and low performance on lower end systems. For an example of this see Solaris, or most other big iron unix kernels.

Another approach is the OS cluster idea championed by Larry McVoy (the Bitkeeper guy). The idea is that you run many kernels on the same computer, one kernel takes care of something like 4-8 cpu:s. And then they cooperate somehow so they can give the impression of SSI.

A third approach seems to be the K42 exokernel project by IBM. They claim very good scalability without complicated lock hierarchies. The basic design idea seems to be to avoid global data whenever possible. Perhaps someone more knowledgeable might shed more light on this...

But anyway, until someone comes up with a kernel that scales to zillions of cpu:s, message passing is about the only way to go. Libraries the give you the illusion of using threads but are actually using message passing underneath might ease the pain somewhat, but for some reason they have not become popular. Perhaps there is too much overhead. And some people claim that giving the programmer the illusion that all memory access is equal speed leads to slow code. The same argument also applies to NUMA systems.

And on the system administration side of things, projects like mosix and bproc already today give you the impression of a single system image. Of course your application still has to use message passing, but administration and maintenance of a cluster is greatly simplified.

Re:What comes next?

[delta407]

a gigabit ethernet card running at full bore (wire speed) can max out many machines both on bus bandwidth and CPU utilization ... Ethernet consumes too many resources

Wait -- if gigabit maxes out the bus bandwidth and CPU of a machine, how is that consuming too many resources? If my system bus can only transmit data at, say, 100 MB/s, and that goes directly to the gigabit card, why is that a bad thing?

Isn't that a limitation of the computer, not a limitation of gigabit Ethernet?

Re:OpenMosix, really Distributed Shared Memory

[becker]

Despite (or perhaps because of) long experience with shared memory parallel processors, I don't see distributed shared memory (DSM) as a useful approach. The programmer must write or rewrite the application to very carefully use the shared memory in a way that avoids the write lock from bouncing between systems. It ends up being simpler and faster, for most applications, to just write the direct message passing code.

Mosix is almost completely unrelated to DSM. While I think Mosix is a very interesting academic project, it's the wrong model to build scalable performance clusters. Cluster applications don't want transparent process migration with forwarded paging and I/O. They want to explicitly and quickly start up processes on remote machines, and have direct control over the performance-critical I/O and communication paths.