Slashdot Mirror
Interview: Alan Cox Answers
Phil-14 asks:
Do you think that non-x86 versions of Linux will forever remain on the periphery, or will Linux actually become a
force for platform independence?
Alan Answers:
The focus of developers is always going to reflect the hardware people have.
As non x86 machines become more prevalent the importance of the kernel port
will do so. PowerPC for example has gone from being a fringe BeBox project
to a major platform.
Embedded systems and palmtops are likely to increase the amount of non-x86 linux platforms. The price squeeze is also going to take its tool - there are simpler cheaper processors and in the end that pricing will begin to count big time.
Intel clearly see IA64 eventually replacing x86. It may be in time that the x86 port is viewed in the same way as the 680x0 port. It may also be that IA64 is a turkey, we all run AMD K7's and x86 lives on. Its a guessing game.
asad asks:
Do you see yourself still working on Linux 5 years from
now? What about other people on the Kernel mailing list? And
do you think the quality of the code people now write for
Linux is still up to the standards of the old days ?
Alan Answers:
I have no idea what I will be doing in five years. Somehow I suspect it will
involve Linux and Red Hat a great deal.
The code standards haven't changed much. Linus is very keen on having clean modular and maintainable code. We have ugly code in there, but its mostly in specific drivers and quite frequently coping with ugly hardware.
Linus is picky, but Linus always was picky. Linux is as good as it is because he is prepared to be a right pain about doing things properly.
aheitner asks:
Okay, there's not a Linux hacker on the face of the planet
who wouldn't kill to have your job.
- - Paid by RHADL.
- - Wake up when you want, work when you want.
- - Go to all the big trade shows.
- - Work with the likes of Linus and all the other regulars.
- - Get free toys (and I mean good toys) like PA-RISC systems from HP and Athlons from AMD.
Alan Answers:
I'm actually paid by the support side of Red Hat not RHAD labs. That
might sound strange but if you are selling high end support to people they
want to know you have someone to fix the really bizarre, and you also
need people who can. So in many ways I'm in support.
I did it because it was fun. I'd been doing other free(ish) software stuff like AberMUD before that. I got into Linux to have a better development platform for AberMUD then got side tracked somewhat into hacking the OS.
As for the toys. New toys are fun whether they are expensive or not. The important thing is new. So I had lots of cheaper strange devices I was hacking on before - like the Macintosh 68K port, and Linux 8086.
The advantage of working for Red Hat is much more time than money: So many toys so few hours.
Techno_Jesus asks:
I'm always concerned with redundancy and I think the linux
kernel development could benifit from it the same way our
servers can. If something were to happen to Linus (albeit
very tragic) would you or someone else be able to take the
weight that he bears for the kernel development process? I
fear that the community is putting all it's eggs in one
basket and perhaps you are the only viable replacement.
Alan Answers:
It used to be "what happens if Linus gets hit by a bus" now its
"What happens if Linus and Alan both get hit by busses". I guess someone
like DaveM would take over (yes next years question is "What happens if
Linus, Alan and DaveM get ...")
Kindjal asks:
How is the whole linux-on-sgi thing going? You were
originally the guy behind that....what's your opinion on the
sgi embracing linux stuff happening now?
Alan Answers:
I was hardly the guy behind it. Dave Miller did the original ground work while
at SGI. Ralf Baechle did a lot of the other work along with Miguel de Icaza.
Almost all the work I did was on fixing up userspace packages and building
install and bootstrap tools.
The SGI I had is now in the hands of some other people who are still working on it. There is a lot of work within SGI on the new x86 machines and some work on the mips boxes. Check out oss.sgi.com
Amphigory asks:
I notice here that you were involved in the creation of
the nano-x project at some point. What is your opinion on
the continued viability of X-Windows? Should the open source
community be focusing on developing something better, or is
X the best we can hope for?
Alan Answers:
Ben Pfaff wrote a library for Debian called Bogl that did basic drawing but
was very compact - ideal for non X boot disks. I had a copy of an old Minix
library called mini-X and I stuck them together. Alex Holden and others then
decided to actually clean it up and make it work usefully.
Its good enough to play minesweeper and probably doesn't need much work to be able to use it as say a Mozilla front end or to port gdk (and thus gtk/gnoem) to it.
For most things X11 is far superior. X is bad at some things - notably code size and handling fast 3D games. These are all getting fixed. X is a very flexible framework and there is little wrong with X itself as a system. XFree 4.0 should do a lot to polish up the implementation. Its rarely a good idea to throw out 15+ years of work because it has a few glitches. X is probably relevant to everything but small PDA devices or set top boxes. My interest in Nanogui is with the Psion5/Geofox Linux port where you have very tight storage constraints.
Borg[9 of 9] asks:
Alan, with the upcoming 2.4 kernel is there any work
being done to address Linux tcpip performance issues? Is
there any plans on making the IP stack multi-threaded and
what about the stack spin lock issues on SMP machines?
Alan Answers:
DaveM, Alexey Kuznetsov and others have been working on this very hard. It is
one reason the 2.3.x tcp/ip is currently a little wobbly. It is however all
happening.
John Fulmer asks:
I'm a network security person and have always been
intrigued by the concept of the 'hardened' BSD kernel (which
isn't really THAT hard), and some of the role-based and
compartmentalized systems out there.
What is the status of the security of Linux' overflows and root hacks) and what do you see as the overall direction, if any, of Linux's security beyond the standard UNIX security model?
Alan Answers:
Ok Linux 2.0 is absolutely traditional. Later 2.0 adds securelevel which gives
a little more security at a usability price. Linux 2.2 uses capability sets so
you can give processes finer grained rights. You can also revoke rights for all
processes which can be useful in higher security environments.
There are people playing with role based models on Linux, although not in the mainstream kernel tree. There are also projects like Stackguard designed to catch buffer overflow attacks. Ultimately the only real way to improve security is careful auditing of packages. On the whole this works. Almost no packages that have been audited have future security holes logged against them. The Linux security audit project is the place to get involved with this. Anyone want to audit the perl interpreter ?
emil asks:
While I realize that you might not be completely
objective about this question, what do you think of the
design of the HURD, as it compares to Linux?
I once asked Linus himself this question and he replied in rather annoyed tones that "the HURD is a great academic design that would never work in practice" (or something along those lines).
Richard Stallman has been steadfast in refusing to endorse Linux as the GNU kernel. Does he raise these objections merely for emotional reasons, or does he see the HURD as having real technical advantages to the current monolithic design?
Alan Answers:
HURD is a great concept. Like most great concepts it isnt
efficiently implementable I suspect. Hurd is a GNU vision and every
project needs some lofty probably unachievable goal.
The HURD design is more about Richard Stallman's ideas about how a system should work to promote community than about high perfomance OS design. Linux is a bit more pragmatic about things. We took ideas from the microkernel world (like loadable device drivers) but we didn't take the accompanying partitioning and performance loss.
HURD is a rich flexible environment where the user has a lot of power to say "no I don't like that, I'll write my own code and use it" - even for things like filesystems. Right now HURD is a research project. Maybe one day it will become a useful OS.
Tekmage asks:
How has the multicultural and multilingual participation
affected the development of Linux as a whole?
Have you begun to see evidence of third-world participation effecting the progress of Linux yet, or is it still in the "hope to see soon" category? What needs to be done/changed to assist in the cross-cultural adoption of Linux? (Unicode?)
When can we expect to see a Linux Universal Translator Engine? :-)
Alan Answers:
We have uf8 unicode support in the kernel for stuff like the console and file
names. We have Japanese X11 fonts. Gnome and KDE have a lot of translations
although mostly to left to right rendered Western european languages. Its
a start.
What do you call third world ? Really its a gradation, and also a lot of it is based on perception. I get code and patches from countries as culturally varied as India, and Iran. There is a noticable amount of activity in Brazil, both with the kernel and other packages. The real third world countries don't really yet have the infrastructure to support the Linux development model. Linux helps to give them the tools to create that infrastructure and I am sure in time it will come when I get kernel patches from these countries too.
Developing countries are also in a good position to benefit from the opening of the market. It doesn't matter where I am on the globe providing I have part time connectivity, electricity and computers I can do Linux development work for companies anywhere in the world - this is one of the other great things about my job. If I wanted to move country there are almost no logistical barriers to doing that and continuing to work for Red Hat.
Actually promoting cross cultural adoption of Linux is hard. It has to come from people in those countries. Maybe I can get away with putting together a French language Linux distribution in the UK, but to put together a good distribution for any significantly different culture I think you need to be part of it. I expect a lot of the growth in support for other languages, and cultural needs to come directly from people hacking the code in the countries that need it.
Linux development isnt centralised in Redmond so you can go out and do this. Most of the time we can communicate world wide. Not always. Its really hard sometimes to follow Japanese Linux projects in Europe and the USA. I guess the reverse is probably true.
Next week's interview: Tim O'Reilly
No, it's not, but unfortunately for your argument, I, like Alan, am in the UK, where it's "perk" (and "cheque" and "colour").
"The invisible and the non-existent look very much alike." -- Delos B. McKown
In public forums, you're supposed to be evaluated on the basis of your ideas - what you post. Not who you are, or whether or not you want to remain anonymous.
--
You say "Alan should have gotten the complete list". Clearly you have no respect for Alan's time. He's a busy person. The moderation system lets the slashdot regulars vote on the best questions and reduces the amount of stuff Alan needs to respond to.
An AC post has a default score of 0, which is normally considered 'no score'. You'll only see a "Score: 0" if someone has been moderated down from 1 or up from -1.
There is certainly some anti-AC prejudice. Interestingly enough, I've noticed more abuse from ACs since the moderation point system was created.
D
----
"Turboflames" that are on topic can contain interesting or insightful remarks.
What I'm talking about is utter dreck, like the fellow who posted 1,000 line copies of the previous discussion, and the people insulting each other's mothers.
D
----
As for your point that AC's are at a disadvantage. I would have to say that they should be. Credibility is not a stateless entity This is why people who have their comments moderated up frequently start posting at a higher level, they have a higher credibility than someone who has just put their two bits in here and there. This is also why people who have been moderated down frequently start posting at a lower level, they've lost their respectability. Due to the nature of AC's, there is not way of imposing this system on them.
Now to get around to your point that AC's shouldn't be forced to post at 0, because this makes it harder to get to the higher levels. I think that because of the very nature of ac's they should have to "work harder" to get moderated highly. We have no way of establishing identity of them, and therefore now way of assessing their credibility. For logged in posters you can tell who they are, and based on what you've seen of them in the past make a judgement on how skeptical you should be about their opinions. For ACs you have no idea if they even know what they're talking about, or whether they're even telling the truth. As such they should be treated with skepticism. This does actually work in their favour as well though. If I see a highly moderated AC posting I'm quite likely to read it, just because chances are it must be a good post to get moderated up that much.
Anyways, I should get back to work...
Mike Bain
If Linus were to be hit by a meteor, development resources would have to be shifted. Such high-priority tasks as porting MS-Bob to the PalmPilot would have to be tabled until the relatively unsexy items such as, oh say, clotting, could be completed.
After that, life would go on. Not to worry.
-- What you do today will cost you a day of your life.
It isn't THAT inconvenient to set up an account, and have a leg up on the AC's, is it?
I've never really been able to understand the AC thing. I'm not looking for a fight here, just curious.. Many AC posts are very worthwhile, and some of these are overlooked in moderation, so they never get seen. What keeps people from just logging in?
-- What you do today will cost you a day of your life.
having ht esource code makes up for some lacks in documentation. If you do not understand the documentation you can look at the function declaration, and hte function itself, and how it handles things. It does lack in documentation, yes, but it is often better, than trying to fiddle with a messed up API, that does not work as it is supposed to. Also something to note is that many of the M$ API's are not very well documentened either, and sometimes it is just hard to get there documentation too.
Only 'flamers' flame!
Perk is what gets the coffee ready. Perq is access to the coffee.
---------
Bill Gates Is My Evil Twin.
That's a lovely communist approach to things, but you're deceiving yourself if you think that your local LUG would rather hear your ideas about the tcp stack--no matter how valid--over Alan Cox's.
/. staff but not regular users.
Anonymous posters choose to remain anonymous and are thereby ceding a certain amount of credibility in the process. Registered posters only need to give up a small amount of their anonymity, an email address, which is available to the
Woe is me. How terribly unfair.
Exactly. I think it would benifit the community greatly were companies like Red Hat to pay people to document the more obscure parts of the kernel. This is especially important as the changes are so rapid and the systems are always evolving (for example: modules in 2.0 to modules in 2.2)
But then again:
I GOT 18 disks on a raid!
http://www.bombcar.com It's where it is at.
Fellowship 9/11
ac> Ultimately the only real way to improve
ac> security is careful auditing of packages.
There may be other, complimentary, ways of improving Linux security. For many years, people in the security research community have been working on systems whose security relies only upon the kernel, or a small part of the kernel sometimes called a reference monitor (RM). The general idea is, once you've implemented your RM properly, it will guarantee certain useful global security properties even in the presence of user-space applications with exploitable bugs. I personally believe that implementing an RM in the theoretically optimal way would probably make unreasonable and unacceptable demands on the Linux architecture. However, I suspect that a sub-optimal implementation in a Loadable Kernel Module (LKM) could provide some security benefits with zero impact to the Linux code-base. The LOMAC project is implementing an experimental prototype of such an LKM-based RM, which may be downloaded under the GPL from ftp://ftp.tislabs.com/pub/lomac . If the LOMAC experiment succeeds, LKM-based tools like it may become a useful complement to the careful auditing of packages.
- Tim Fraser, NAI Labs
Thanks for answering my questions!
Hope a few of the good 4-rated and 3-rated comments from this past round get thrown in the pot for the next edition of Ask Alan.
--The more you know, the less you know.
To a certain degree, Microsoft does provide developer contact. They just don't publish it in "mainstream" press.
The Microsoft Developer's Network is the first line of contact with the developers: "here's a huge stack of CDs of everything we think you might need to develop for our OS."
You can also get significant interaction with developers and evangelists at trade shows. When I was programming games I found that the time spent at Microsoft Meltdown was invaluable. You get to schedule time in a hotel suite with DirectX developers from Microsoft to review your code and get pointers on how the OS works. Plus, it's their front-line for input on new features to add.
I was even invited to spent a few days in Redmond at the offices to get direct interaction with DirectX developers.
However, Microsoft is a traditional company when it comes to trade secrets. You didn't get invited to Meltdown without signing NDAs. OpenSource eliminates the need for NDAs and lawyers in general.
Microsoft's position is also bound by the fact that they are in the business of creating de facto standards. Linux is based on open standards. The concept of open community interaction is there from the initial stages of development.
First off-I may loose all moderation priviledges (I am not one right now) from this point forward-but I would like to clarify that I have been a moderator several times...and not once, regarding ANY issue was I ever contacted nor asked to ignore AC comments.
/. came up with the threshold option...That is why I now use it to keep from having to look at that crap.
/. was just making it easier on him..and I think that they were good questions and it was a great interview-next time why not just log in?
I can see why you are upset that NO AC questions were used in the interview-but I can assure you that there is no conspiracy. I set my threshold to 1, and it is sometimes left there while I have been a moderator-I assume I am not alone,which would explain why a lot of them are overlooked in the first place.
With all the agony of First Post! and Meeppphhtt! etc.. that had to be accepted before
As far as any of this goes, why should Alan HAVE to weed through dozens of questions-maybe he just didn't want to. He was doing US a favor by doing the interview -
p.s. I was not a moderator at the time the questions were asked either.
Hi,
:) :)
I just read the interview and wondered what Alan ment with the PPC port starting on a BeBox? Was there not porting done to PPC before the BeBox? Does Alan have a BeBox? I am amazed at the far reaches of Be here
Can someone, even Alan, clarify?
Oliver
Right on opensource os's! FreeBSD, Linux and others!
-
ping -f 255.255.255.255 # if only
It sure didn't sound like Roblimo or whoever passed the questions along anticpated the outstanding response and was a little overwhelmed. (I didn't look at most of the questions; I thought I'd seen the cream with the answers by Alan.) So I don't think they had score criteria before they went in. That would make it hard to inform people ahead of time. They may not have even taken all the score 5 questions (I haven't taken the time to look...)
/. comments by someone professing to be Alan Cox, presumably he could go back to the forum and look at the other high scored questions (whether by an ACoward (two different AC acronyms... 8-) ) or not) and answer them if he'd like.
/. has been able to get the interview and then instead of coming up with their own lamo questions, they throw the doors open to the masses. There's always going to be some good questions that don't get answered. How are you going to decide?
Since I've seen
From what I understand about these interviews,
I don't think there's any question about this being an "open and public forum".
Except that there wasn't any reason to be anonymous for this. Unless there were well-phrased questions of the form "Why does Linux suck?" (and I don't know if that could be done), there wasn't anything political going on. Certainly in this discussion there could be unpopular views that someone doesn't want reveal an identity. But not asking a question.
Do you think Alan Cox would personally respond to a question from a random anonymous email address? If no, then this is a moot point. If yes, then you may have a point, but I still can't see what you would want to ask anonymously.
Comments ought to be scoredsoley and entirely on the basis of their content - not extraneous factors like whether you logged in or not.
We already know this isn't the case. Logged-in posters start with 1, ACs with 0. Those are the rules of this game, Don't like it, take your ball and go home. The prejudice is already there. You knew this going in.
People need anonymity for a few reasons.
Posting a message that will bring harm to them. I don't think there's ever this on /., except if insiders are posting infomation that will get themselves fired or cut off from the information.
Posting an unpopular view. If you don't want to deal with flames, you may post devil's advocate stuff. This is probably the majority of legitimate /. anonymity.
Posting a view contrary to their established positions. If someone (like a political candidate) has to be "tough on drugs", but they're a closet pot smoker, anonymity gives them some leeway between their public and private lives. (Doesn't solve the hypocrisy, but maybe that's not the battle to fight at that particular time.) I wouldn't be surprised if this happened sometimes (e.g. a Linux supporter thinks one particular thing is stupid, but doesn't want to "taint" his rep)
Someone who doesn't want to be tracked. In this case, they would also don't trust the /. maintainers to keep their real (off-Slashdot) identity secret.
Those are all legitimate reasons, but again, I can't see how they apply to asking pertinent questions to an interview subject.
The downside of anonymity, you get people who post drivel like "ALAN COX SUX" with, of course, no reasons why. (Not even a whining "he didn't answer my question"...) I'm willing to put up with that because there are times you need anonymous voices.
Like this discussion. I could totally see someone posting what you did as an AC, because it threatens the established (Taco, Hemos, et al.) authority.
Asking Alan a question wasn't one of those times though... Unless you can come up with a legitimate reason...
"...and the ability to manipulate ip packets by thought."
They can't do that now?
I keep trying to pick fights, but I can't shake this Excellent karma.
someone put a little too much crack on their cereal this morning.
The primary reason there is such a lack of documentation is because it is not nearly as much fun to write as code. Declaring that people should document their code will never work unless you made it less painful to do so.
Perhaps if you knew interested parties were going to look over your code you would comment it for the gloat factor. Usually the more ingenious the code the more proud you are of it and the harder it is to understand. If you had someone to show off to, you'd be more inclined to comment it.
--SolidGold
Everything you know is wrong. Or more accurately, inaccurate.
>Of course, you yanks have a way of bastardizing the spelling of words...
You mean "yanqs" of course...
It seems like the corporate closed-source model has several flaws, the most aggregious of which is.. no source code access!
A) I've seen the source for MFC (it's distributed with their compiler) and you don't want to look at it, believe me
B) IMHO the most egregious fault of the Free Software movement is an inability to spell. I'd still rather deal with that than MFC, of course.
There are thousands of open-source projects, some as small as a few lines of code. Who are WE? doesn't the we that is YOU work for M$?
The "we" that he's referring to is "we software developers". That's abundantly clear in his post. Yessiree Bob, them fiends -- fiends, I tell you! -- who code at MS are programmers too, much like the heavenly angels in the free software camp.
I'm going to assume that you're claming that closed-source corporate software DOES have this,
You can assume anything you like, but the point of his entire post was that MS does not have that. Here's his second sentence, which seems to have escaped your comprehension (even though you quoted it):
It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation.
Get it? I think your second "aggregious [sic]" flaw is an inability to understand simple declarative sentences in the English language.
please, don't give me any line of shit about corporate $oftware being better than OSS. It's bullshit.
He said nothing of the kind. He's developed some software and he's seen how the process works, and now he's offering some thoughts about how the process might be improved. In his opinion, his thoughts on the subject apply equally to both open and closed development. IMHO he's right, too, even though he's not suggesting anything terribly revolutionary. IIRC Knuth has been on a similar kick for years. If he did anything wrong, he may have been assuming his audence consisted of programmers. Of course there are a lot of them around Slashdot, but there are also a lot of dingbats like you.
Ok, I'm as sick and tired of everyone complaining about moderation, censorship, and those sorts of things as anyone else. But the system plain doesn't work unless people honestly and fairly moderate things. I guess I'll just e-mail Alan directly to ask him the question.
Of course, now it's up to 5 again - after the questions had been sent to Alan. gah.
Actually, in the off chance Alan's reading this article: Alan, how much of your software development is done because of a contract, and how much just for the fun of hacking?
I'll concede that two or even three people getting hit by busses is improbable; but meteors do a lot more damage, and can take out a hemisphere or more. I'd suggest to Alan that he and Linus never be in the same hemisphere at the same time, and that at least resources be devoted to a rocket that can take at least one of them to a planet far away in the event of Earth's destruction. Who knows; they may land on a planet whose sun gives them powers such as flight, x-ray vision and the ability to manipulate ip packets by thought.
While there are some definite troll elements in the original post, they do make a good point: Documentation is useful and important. And I mean, beyond the kernel source instructions themselves. There are a number of reasons for this. I thought they were well-known, perhaps not.
:-)
For one, stating the design and then implementing it has been shown to increase code quality. More importantly, it means you know what the code *should* be doing. This makes "Is this a bug?" questions much easier to solve. I've noticed a lot of patches on the linux-kernel list arise from misunderstandings due to unclear code.
Then there is the generally accepted fact that programmers of all skill levels sometimes forget things. How many here have gone back to their own code they wrote six months ago, and said to themselves, "What does this do?" I know some kernel hackers have -- that same phrase shows up in the Linux kernel source!
Linux is contributed to by tens, if not hundreds, of developers. Not *all* of them are going to be Seventh Level Hackers like Linus and Alan. For someone who is, say, just tring to implement an input device driver, it would be nice if some of the magic_kernel_functions() were explained a little clearer.
I'm not saying every function should be documented complete with purpose, arguments, return value, pre- and post-conditions. If someone wants to do that, more power to them, but I'm not saying It Must Be.
However, some things could be added, to positive effect: Top-of-file comments explaining what is contained in a file. Brief comments explaining which a function is supposed to do. A guide to where key kernel structures, macros, etc., come from.
A lot of this stuff was laid out very well in the Kernel Hacker's Guide and similar documents, but they have fallen far out of date. Documention for the 2.2 and 2.3 series kernels is very lacking.
I would try my hand at doing some of this, but frankly, I don't understand much of the kernel myself. I've been reading source lately trying to figure some stuff out, but with almost *SIXTY MEGABYTES* of kernel source, that is a lot of reading!
Just my 1/4 of a byte.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I'm a developer at M$, and I've watched the Linux community for a couple of years now too. It seems that the corporate and open-source development models have at least one flaw in common: insufficient documentation. All too often one finds a section of code that is not commented in-line worth a damn, and there is no thorough "architectural overview" of the project to even help clue you in. So to address the question, "What if so-and-so gets hit by a stampeding buffalo?", let's first address a larger issue: how can we get people up-to-speed on development projects more easily? The answer is to simply shift our philosophical viewpoint. We should place correctness, thoroughness, and efficiency of _documentation_ on the same priority level as correctness, thoroughness, and efficiency of _code_. Then you don't have to worry about a project dying just because a few key people left and took all the knowledge with them! This means commenting (in the code) the purpose and inner functioning of every function so that a newcomer can immediately see what the function does, why it gets called (and from where), and how it works inside. This means modifying your original design specs as you go along to reflect what is actually happening in the project as it takes shape, so that at the end of the project you have a complete architectural overview that one could read to easily see how the project fits together.
- "It's just a matter of opinion!" - PRIMUS
Short for "perquisite".
:-)
Of course, you yanks have a way of bastardizing the spelling of words, so it may well be "perk" in the US, but that's not where Alan is, is it?
(And the piece of paper you sign authorizing the back to give somebody your money is a cheque. A check is a pattern of alternate colo[u]r squares.)
-- Alastair
Well, I want to die quietly, peacefully, in my sleep like Grandpa did. Not screaming and crying like his passengers.
(I know -- this joke is so old it collects a pension now. I couldn't resist.)
Save the whales. Feed the hungry. Free the mallocs.
Reading this, a strange image comes to mind....
"Thank you for coming, gentlemen..."
"Cut the crap, Bill. Why did you want us here?"
The speaker glares. "No names", he replies. "As for why I called us togeather... I understand this is highly irregular. Normally we would be attempting to tear each other apart in the marketplace. And I know that means there's no love lost towards me. However, today we are seeing a bigger enemy. All our business is dependant on proprietary technology. Today, the threat to our business models is not each other... it's open source."
There is a wave of grumblings and grudging agreements. One speaker blurts out "OK... sure... but what do we do? Many of our numbers are attempting to embrace it to survive..."
The speaker frowns. "You'll notice THEY aren't here. No... there is another solution. Destroy open source. Destroy its poster child: Linux."
More grumbling. The speaker grins.
"Obviously you think I'm insane. Gentelmen, I'm not. We have a solution. Cut off the head, and the snake dies. You'll note that a year or two ago... if a bus had hit Linus Torvalds... it may have stopped this menace before it surfaced. Now it would take two, possibly three bus incidents. Gentlemen, we must act now! The plan is simple... at the next big Linux convention, we pool our collective resources togeather and charter lots and lots of busses...."
The plot thickens. And I swear to cut down on Penguin mints...