Fog Creek Software
Discussion Board

"No Defense for Linux"

"Linux is being designed into future U.S. defense system, including the Army’s Future Combat System (FCS), the Land Warrior, and the Global Information Grid, which will connect all future military systems into a single network. This spread of Linux into defense systems is cause for serious concern. Linux security is inadequate for defense use. If the systems now under development are deployed with Linux, U.S. national security will be at risk."

I'd be interested to hear some reasoned, factual rebuttal of the article.

Philo [Microsoft]

Thursday, July 29, 2004


This guy clearly has no idea how Linux kernels are released.  Just because work is done in China, doesn't mean it gets into the kernel releases. 

How does closed source prevent the trojan scenario?  If anything it makes it more possible.

To me it sounds like this guy is posing as an expert, but doesn't really understand the problem.

christopher (
Thursday, July 29, 2004

[Note: the following article can be deleted for space:]

christopher (
Thursday, July 29, 2004

So does this author really think that he is more thorough and comprehensive in his analysis than the DOD?  How else can he explain why Linux is *being used* in defense systems, as opposed to just *being considered*?

Clay Whipkey
Thursday, July 29, 2004
(hopefully that's all on one line).

Also, he's not preaching Windows v/s Linux - he's saying that his company's OS is better. This is the third time in the past year that he's released a white paper about how insecure Linux is and how it'll mean the downfall of our country if not civilization itself if the DOD uses it.

None of the three papers have hard facts or statistics to back up his claims, it's just FUD from a company that (according to friends who work with embedded systems) is losing market share - to Linux as well as to other embedded OS's.

Thursday, July 29, 2004

He's the CEO of Green Hills Software

They sell Real-Time embedded operating systems for military applications so you can see where he's coming from.

MT Heart
Thursday, July 29, 2004

Ahhh.... excellent catches, RocketJeff and MT - thanks, I wasn't aware of that.

Regarding the back door in Unix - was the Unix source code available? (I honestly don't know)

"How else can he explain why Linux is *being used* in defense systems"

Never worked in government procurement, have you?


Thursday, July 29, 2004

Sorry, but it is FUD or more precisely, wrong.  Anyone who has ever worked on a government contract can tell you the anal retentive nature makes testing so extreme that it is unlikely that anything would make it into the field with errors.

If they did, the most reasonable attack would be a trojan or back door that allows the "enemy" to control the weapon.  Sorry but most weapons systems do not allow external change of commands, plus PALs or similar security.  In addition, the weapons systems run "on" linux, meaning they have their own protocols on top of anything linux may provide.

The government could  write their own (and NSA Linux is a perfect example), or an alternative is closed source system which have the same problems without anyone seeing the code who may notice something gone astray. 

Sorry this one is a red herring.

Thursday, July 29, 2004

Nice try Philo. Linux's armor still remains clean & unblemished while MS rusts in the junk yard...

anon-y-mous cow-ard
Thursday, July 29, 2004

>>Regarding the back door in Unix - was the Unix source code available? (I honestly don't know)

Back then, most sites that had Unix has the source also - it was in the very early days of Unix. It didn't matter in this case.

The issue was that the backdoor wasn't in the source of the login program or the C compiler - it was inserted directly in the binary.

It was designed so that the C compiler would detect when the login program was being recompiled and insert the backdoor logic directly in the binary. The C compiler would also detect when it was being recompiled and insert the logic that detected/infected the login program and the C compiler directly into the C compiler.

The idea was pure genius and was only effective because he had direct control of both the source and the binary that was distributed with Unix. If there had been a 3rd party compiler (or cross compiler) in use or multiple sources of compiler binaries, he would have been able to put a backdoor in his own system but probably not too many others.

Thursday, July 29, 2004

It's misleading, with just enough truth to be disconcerting.

Sure, someone could put malicious code in the Linux kernel. But it's not like any yahoo can make a change and upload the kernel to

For most people to get their code in the official kernel, the code has to go through at least one well known, trusted person. Theoretically, that person reviews the change. The people that can get code in the kernel without review are well known, supposedly trustworthy individuals (and there's probably less than 10 of them). It's really not that much different than with other software, except that nothing is kept secret.

So, it's not as easy as he makes it sound to get a trojan in the kernel. But, if one does get in, you (as a user) have a chance to find it. Is that true with Green Hills' ThreadX operating sytem? I doubt it.

I think all of his arguments are worse for his own OS than Linux. What assurance do I have that he or one of his employees isn't a foreign agent? Or more likely, just disgruntled with a vendetta? Does anyone outside of his company look at the source code?

The US military has been using open source operating systems for a long time. Some of my work uses RTEMS ( ), and open source real-time OS developed _for_ the army in the 80s.

He's just trying to scare customers into using his OS. Wind River used to do the same thing, until very recently.

Jay Monkman
Thursday, July 29, 2004

Linux is, or is currently in the process of, FIPS certification, I believe, which includes, among other things, certifying a particular version of the source code that's been certified secure (and there are convenient digital means like MD5 hashes to verify that the code is identical to what was certified).

So, even if a Chinese hacker could slip a backdoor into the code, it would either have to get past FIPS certification or it wouldn't be in the code used by the DOD.  The FUD-spreader in the OP (not you, Philo) is implying that a foreign hacker could slip something in and there would be no review at all of it.  Ergo, he's either simply wrong or maliciously wrong.

Justin Johnson
Thursday, July 29, 2004

To be clear, FIPS certification is a requirement for secure government software.

[I'm winging all this, by the way.  The gist of it is right, but there's good odds I'm using the wrong acronyms.]

Justin Johnson
Thursday, July 29, 2004

He is either a liar or insane. The fact he wrote "[Note: the following paragraph can be deleted for space:]" probably means he was aware of the lie in that upcoming paragrah.

Unless I am painfully mistaken, Kernighan did not install the trojan as this guy libellously claimed, merely pointed out how it could happen. Based on an old Air Force critique.

Tayssir John Gabbour
Thursday, July 29, 2004

The thing that amused me most about the article in question was the idea that the only reason anyone could possibly ever want to use Linux is "to save money". How can anyone actually accuse a government of wanting to save money? Not only that, but the US DoD isn't known for beign the most badly funded government agency on the planet to start with :)

Personally, I'm quite happy with the idea that there's better operating systems than Linux or Windows, but that article strikes me as somewhat paranoid and full of questionable statistics. That doesn't inspire trust in his conclusions - if he's right, why doesn't he back up his claim with solid evidence?

I may not be an expert, but if even I can see unreliable claims and irrelevant statistics being used to back up a claim, there's got to be something wrong. "You have to be an expert to understand the problem here" may not make for such an exciting article, but it's got to be better than "I'm going to distort and simplify the issues and pretend that I've given accurate and useful information."

Here's an example: There's a discussion of the EAL/4 rating for one specific version of windows at

Here's my favourite bit:

> The Bottom Line for Windows 2000
> In the case of CAPP, an EAL4 evaluation tells you everything you need
> to know. It tells you that Microsoft spent millions of dollars producing
> documentation that shows that Windows 2000 meets an inadequate set of
> requirements, and that you can have reasonably strong confidence that
> this is the case.

The fact that the claim in the article is technically accurate doesn't necessarily mean that it's relevant. This is old news - so why would any security professional bring it up?

Here's another example: Apparantly Linux has had a greater total number of security vulnerabilities in released versions than Windows has. This statistic may be true, but it's not actually informative. You need to account for the scope and impact of a vulnerability as well as its mere existance, and it would be sensible to account for the fact that Linux developers and Microsoft have a significantly different approach to release schedules and bug tracking. Does the Microsoft statistic include all vulnerabilities found and fixed before the software was released? If not, then you should remove all vulnerabilities found in a 'development' release that were fixed for a 'stable' release of Linux as well.

Haven't we been over this time and time again?

Are there really people still abusing vulnarability statistics this badly and still being taken seriously? Sure, it's hard to objectively compare the security of different operating systems, but that's no excuse for doing so badly.

Thursday, July 29, 2004

I am going to retract my post I just made, since:
a) I have been editing audio all night and am too tired to trust my own analysis.
b) I posted way too quickly, without careful research. That was stupid.

Tayssir John Gabbour
Thursday, July 29, 2004

The NSA is doing some interesting work with Linux:

Friday, July 30, 2004

> Ahhh.... excellent catches, RocketJeff and MT - thanks, I wasn't aware of that.

And you were so careful to add [Microsoft] to your own sig.

When you saw "Author Information: O'Dowd is CEO of Green Hills Software", weren't you at all inclined to Google for "Green Hills Software"?

> I'd be interested to hear some reasoned, factual rebuttal of the article.

To rebut them, you would first need to find some statements in the article. Paragraph by paragraph:

> ... If the systems now under development are deployed with Linux, U.S. national security will be at risk.

U.S. national security is perpetually "at risk", isn't it.

> ... If the operating system is compromised, an enemy can spy on, disable, or commandeer the entire system.

If, and depending on the compromise.

> With the knowledge that Linux is going to control our most advanced defense systems, foreign intelligence agencies and terrorists can easily infiltrate the Linux community to contribute subversive software.

So, caveat emptor as usual.

> A CIA Trojan horse in the software that controlled the trans-Siberia gas pipeline caused a massive explosion.

No comment.

> It would be incredibly naïve to believe that other countries and terrorist organizations would not exploit an easy opportunity to sabotage our military or critical infrastructure systems when we have been doing the same thing to them for over twenty years!

So, to be relevent to his point the author should now show that enemies have an easy opportunity to sabotage the Linux that "is being designed into future U.S. defense system."

> If we proceed with plans to allow Linux to run these defense systems without demanding proof that it contains no subversive or dangerous code waiting to emerge after we bring it inside, then we invite the fate of Troy.

"Proof that it contains no dangerous code": that's an area of computer science that I've heard of but have never studied (I know bits about bug-hunting, but not about "proving" that they don't exist ... especially in big systems).

> The Federal Aviation Administration (FAA) requires software that runs commercial (and many military) aircraft be approved as part of a DO-178B certification.

I don't know DO-178B; one quick Google suggests that DO-178B is about documenting the development process: does that mean it's anything like the EAL/4 as ridiculed by <blank> above?

By the way, the top-most Google sponsored link when searching for DO-178B is:

"The only commercial, securely
partitioned Level A certified RTOS."

Paid for by your friends at Green Hills Software.

I read this article as an infomercial for GHS. Why would you seek a reasoned, factual rebuttal for an infomercial?

Christopher Wells
Friday, July 30, 2004

If security is one's top priority, Linux is certainly a good choice (if properly configured). I use Gentoo Linux for my personal desktop, and have went through the various security-increasing hardening processes (compiling the source-code yourself also eliminates unnecessary dependencies, thus eliminating various security exploits). Security's one of the reasons I think the Apple model for applications (every application = own directory) is retarded: imagine having many different versions of the same library floating around -- that means many more security exploits.

Linux is good for most things, as far as security is concerned.

However, if your paramount concern is security, then I don't see why you should use Linux. You should be using OpenBSD. OpenBSD is the most secure OS in the world, and goes through rigorous security testing. Of course, you'll have to sacrafice various things, like an accelerated desktop, but if your concerned about security, I doubt your using the computer as a workstation for a layman.

David Heinrich
Friday, July 30, 2004

Okay nothing "factual", but you gotta remember, the author of the article you've written hasn't exactly been doing both RTOS and Linux development for the last 5 years so he isn't exactly qualified either. Philo, you gotta remember that spies don't necessary rely on a single point of failure in the security chain. A big hole is always a nice to have from their point of view, but I doubt any worthwhile spy master would hedge large bets on any such leads (it could be an intentional false lead). In most security situations, it's still the human factor and institutional security policies that's weakest. The pros of Linux are well known and I'll keep them short:

* Code review: Once you decide what device drivers are really required and needs to be audited, the base kernel is well known and reasonably small, it can be audited. One might argue well the army needs to use every device driver so thus any Taiwanese or Chinese vendor could add a malware inside some innocent NIC card driver--well what's to say you can't do that with a Windows device driver or something written to compile with some proprietary RTOS? The argument is either: the army will have to be responsible in ensuring the linux investment is supported by a reasonable code auditting process (kind of like the one in the OpenBSD community). Although a commercial vendor can dare to claim they vouch for every line of their kernel space projects--it is still the Army's responsibility to hold up their end of the security net by ensuring all code are auditted. This sounds like a big cost, but the important thing to remember is this is just as valid for linux or non-linux OS. Army had tons of proprietary RTOS that all had to pass the same auditting process, it is only now they might benefit from having to audit just linux (or just Windows) for some common projects with a soft real time requirement.

* Linux leads many RTOS in application library support. (again, the more libraries, the more auditting required, if you want to use Perl, you have to be responsible, if you want to use GCC, more responsibility, but there are more useful programs written for Linux than most proprietary soft real time RTOS at the moment) Some of the libraries are licensed in a way to allow for auditting as well. Again, you can't ask the army to test every bloody open source language, but the task isn't so insurmountable if you reduce it to Sun Java + GCC + Mono (and maybe a scripting language, any one). The 3 mentioned provide full source and can be audited if need be (thankfully, Microsoft is also trying hard to make code auditing of their equivalent development, so the army can benefit from that as well).

The key reason for insecurity in software is 1) lack of code audits for security bugs; 2) human policy (I am the commander of the atlantic fleet but my password is god; or I am the vice president of the United States and I can't figure out how to use this smart card so please just remember my face) and genuine human error (that's what code audits and policy audits are for). There are no genuinly good reason why the open source development model makes it impossible for the Army to baby sit a truthworthy branch of Linux they can use inside and out.

Li-fan Chen
Friday, July 30, 2004

Uh, so Philo, what's your opinion on this matter? Whether they be of your employer's or strictly off the record?

Li-fan Chen
Friday, July 30, 2004

If any of the replies of this OP tried too hard to discredit the author, I think we should remember that the author has valid concerns (although maybe not very valid threat theories). Any OS used by the military must be taken very seriously. On a general note, not to diss the c/c++ crowd too much, it would be nice to reduce a whole class of security threats (like memory clobbering) by reducing the amount of c code in the field. Java and other major languages have had wonderful head start in the soft real time space and the java real time specification is a worth while endeavor (perhaps major organizations that want to depend on Linux should pour some serious resources into such projects). Another project worth nothing is the ability for Linux kernels to off load kernel-side responsibilities to user space hooks (er, many OS can do this, but I just want to point it out). You add these hooks to reliable languages where you can reduce the amount of memory-based attacks and it does make it easier for programmers not to shoot themselves in the foot.

Li-fan Chen
Friday, July 30, 2004

>> "OpenBSD is the most secure OS in the world..."

Wild claims (FUD) are rebuked by more wild claims.  Clever.  What evidence is there to support the claim that OpenBSD is more secure than any other operating system, such as OpenVMS?

Michael Jessopp
Friday, July 30, 2004

A genuine concern: ASICs now are getting really sophisticated now days and integration advances (especially at the classified level) is becoming so strong that I would ask you this question: What if you the device driver is kosher, but the chip isn't? What's to prevent a 10 meter - 100 meter triangulatable radio from being inserted into every american tank in some innocent off the shelf microcontroller by a French company that aids land mines in proper detonation. Maybe the radio randomly turns on during a few miliseconds in a reasonably discreet select time frame to report it's location to potential land mines, maybe the signal is reasonably out of band and discreet as to pass manufacturing or security inspection. This would allow a whole class of land mines that listens for parked vehicles. They would genuinely be undetectable because all mine electronics are never activated until such presented time when they really need to perk up their ears. This is a really dumb example but it's something to consider. All in one chips are very common now, what's to prevent some naughty ICs from making it in. That's pretty much undetectable. Or is it? Can someone chip in?

Li-fan Chen
Friday, July 30, 2004

I agree that the DOD will consider the security aspect very closely. I suspect that the version of Linux they use will not be an off the shelf distro and that it will be customized and the changes will not be released as they won't be selling the new software.

The "backdoor" in to UNIX story comes from an ACM Turing award lecture by either Richie or Thompson where they outlined a way a back door could be put into Unix. There was no claim in the lecure that it was actually done and released.  The approach was very clever but any compiled code that you install could could contain a backdoor. 

Friday, July 30, 2004

I completely support the use of Linux for military applications. It is a very secure system.

Chinese Open Source Contributor
Friday, July 30, 2004

The lecture on the 'backdoor' in to UNIX by Ken Thompson.

Friday, July 30, 2004

Somebody already beat me to it, but I'll say it anyway.  Clay, it's not just the DOD (and you know my props for them), but also the NSA.  Them's the serious men in black ;-)

Friday, July 30, 2004

The fact that the guy is CEO of a RTOS developer might actually mean he knows what he's talking about, unlike the Linux roolz fans.

Since accusations about a conflict of interest were predictable, he's also a very brave man.

As to his points, there have been numberous instances of bugs in Linux code. According to the many eyes mantra, this was impossible. All those open source developers viewing the code were meant to see all these bugs, but they didn't.

It would not be hard to insert dangerous code in a Linux submission in a way that evaded even quite throrough inspection, let alone the cursory inspection that probably takes place.

A commercial provider like Green Hills, on the other hand, is identifiably responsible for its products and has a chain of evaluating personnel, work and releases.

His warnings are valid and brave, and will return to bite us in a few years time.

Friday, July 30, 2004

and what's to prevent a spy from getting employeed at green hills?

oh, and considering someone brave for spewing fud about their competition. no, that's not brave. it's normal business practice.

Friday, July 30, 2004

IMVHO, the reason why TLAs, across the world, insist on using closed source commericial vendors (CSCV) are,

1) The CEO of the company making the CSCV is the person to be beheaded/hung/electrocuted/sued/sent-to-Gumatanamo-Bay, should the fertilizer hit the ceiling. For open source, free ones, e.g. Linux, who is liable for prosecutuion? The submitter of the flawed patch? Or Linus? Or the Lt. Col. who oversaw the implementation?

2) It is cheaper to pay somone to do the job. An internal development team would include extra-salary expenses such as housing, catering, etc.

3) A CSCV has a vested interest in retaining the contract. Hence it is expected of them to customise and customise and customise even more. An Open Source Vendor (OSV) has no such incentive. In addition there are no contractual obligations to provide upgrades, updates and bug-fixes, insofar as that product is used without any explicit understanding between the parties to inlcude such obligations as part of the contract. Such a contract is more likely to be signed when the OSV is hired for monies to implement such changes. In which case he becomes an Open Source Commercial Vendor.

4) Should the OSV become an OSCV, the new product that includes any changes and and improvements automatically (from what little corporate law I know) become a CSCV as such changes have been made specifically for a single customer in whose interest it is to keep such improvements secret.

5) Release Early Realease Often is NOT advisable for a Military Project.

6) Many Eyes is NOT a Good Thing (TM) for a Military project.

IOW, TLAs have two options; open source software built upon and customised internally or closed source software, paid for by the exchqeuer, with a contractual obligation for delivery of specified goods.

To repeat my comments from another thread, for a Govt. or a Commercial Organisation, it is primarily a matter of 'Who's head should roll?'. Again, I am presuming technical equivalence between CSCV and OSV.

Even if an OSV provides a technically better product, the costs of identifying the entity that is culpable and initiating mitigative procedures is, IMO, more than paying a CSCV for the improvements sought.

<The above, especially points 5 & 6, are broad 'common-sense' statements. I may stand corrected by people who know more on the subject(s)>

Friday, July 30, 2004

I'm a professional developer that programs for Windows and MacOS and I tend to avoid Linux, despite having a heavy Unix background (SunOS, Solaris, AIX, IRIX).  Also, I don't agree with the politics of the FSF.

Having said all of that, the guy who wrote this article is either dumb or just totally full of shit.

Friday, July 30, 2004

Fancypants, you are obviously a well informed and intelligent chap, going from your other posts. The guy who wrote this piece has written on the same theme previously. If you're interested, have a look for them.

If he wanted, he could achieve his commercial interests in board meetings and presentations. He doesn't need to write something in the public media. To do so in the current climate is rather brave. He doesn't sound like an idiot at all.

Friday, July 30, 2004

"He doesn't sound like an idiot at all."

Does he sound like a Darl McBride?

Seriously, I first met this guy's articles in some embedded mag about a year ago.  Or maybe it was some competitior of his such as WR.

It is straightforward to question his logic because of the obvious bias.  It would be just the same if someone such as Philo got a bit published about Windows for Warships.

I've been reading articles about small gov teams making fighting systems with Linux for ages.  Actually putting standard ruggedised PCs into combat vehicles and running linux on them.  All these articles I've read in such a theme (one, IIRC, in Linux Journal) all seem grass-roots engineers decisions.

i like i
Friday, July 30, 2004

"They sell Real-Time embedded operating systems for military applications so you can see where he's coming from."

Rather like another large closed source company in the Pac_Northwest.

There is one drawback though as I see using Linux in these applications.  I follow the many eyes to spot bugs etc.  But what if one of those sets of eyes belongs to a terrorist, any bugs they find are NOT going to be made public, nor any inherent design weaknesses.  Many eyes are not going to catch ALL the problems.  Remember the good guys have to win 100% of the time, the bad guys only once.  So in this respect, I t might seem better to use closed source.  BUT.... the closed source stuff is far more vulnerable to one thing than open source.  It is vulnerable to a terrorist group making a worker give them the code either through payola or by threatening family etc.  The problem with that is then they have a copy and no one knows.

Obviously there are some good points to closed and open idealogy when it comes to security.

The Green Hills guy does bring up some excellent points that Linux may not be that suitable to all applications because it is not real time enough etc.  Also Linux is rather large for embedded apps etc.  I think Green Hills and the VxLinux folks make some nice kit, but the big push for Linux is because its free$$$, rather than it's the best tool for the job or the most secure.

Friday, July 30, 2004

The argument about terrorists or organised crime blackmailing or threatening staff or management are not unique to source code though. Let's face it. If someone was going to do this, they have lots of opportunities in other areas. It's called spying.

Friday, July 30, 2004

"Linux security is inadequate for defense use. If the systems now under development are deployed with Linux, U.S. national security will be at risk"

How about if you start with some facts to back up that statement.

M. Night Shammalamma
Friday, July 30, 2004

"6) Many Eyes is NOT a Good Thing (TM) for a Military project."

It depends on whose eyes. How much of Microsoft's research and development is being done in a communist country? (*cough* CHINA *cough*)

Anony Coward
Friday, July 30, 2004

Closed source software is not immune to serious defects in security. Some time ago, Borland used to sell Interbase. But there was a secret hidden backdoor account in the database product that could not be mitigated. This secret backdoor account was exposed when Interbase became open source and a fix appeared very quickly. The localsystem account has to authenticate itself to the lsas, does it use a similar backdoor as interbase? Without viewing the source, you can't tell for sure. If you revoke the certificate belonging to the localsystem account, your machine locks up and can't boot again.

The question that no one can answer is: how many other software products and operating systems have these back door accounts? With closed source software, you have to take it on faith that the person is telling the truth. When in fact they might not know the truth, or they might be lieing to you. You don't know. You can't know. If the closed source software is being offshored, you have the security issue that the CEO of greenhills is complaining about: you don't know who is putting whatever into the source tree. And the problem with EULAs (assuming they get held up as valid contracts in court) is that even if the vendor knew there were defects, you cannot recover damages.

Friday, July 30, 2004

This discussion reminds me the 1995 movie "The Net" with Sandra Bullock discovering a backdoor in a commercial "security" app.  :)

Friday, July 30, 2004

The thing is that commercial developers have to stand by their products. Their product is their future so they have a big incentive to verify it and vouch for it.

Friday, July 30, 2004

Linux is a terrorist weapon of Al Queuda.

It all started in 1991 when Linus was recruided by Osama Bin Laden to write the kernel for a subversive operating system.  AQ then positioned key operatives and cells, who specialized in grass roots promotion, throughout the world to promote Linux, initially through USENET, and eventually through the web.  This planted the seeds of dissent among young impressionable, wanna-be hackers who jumped on the band-wagon, and eventually worked their way up the ranks in business and government until AQ had acheived a successful infiltration, without the infiltrators even realizing they were doing the bidding of their dark masters.  Once in positions of influence, the Linux advocates began making recommendations for Linux solutions, which were initially scoffed at, but over time they wore down their detractors at the same time they climbed to higher and higher positions of leadership.  Industry leaders like IBM began to fall under the Al Queda/Linux spell and the damn broke.

I guess we all know what happened next.  Businesses, schools and government began adopting Linux solutions like it was a voluntary tuberculosis epidemic.  Now the damage is done; the Department of Defense of the leader of the free world has embraced the trojan horse of their enemy and we will all soon be turned into penguins and inducted into slavery under our Finnish / Al Quedist masters.

I know this is all true because I saw Linus and Osama Bin Laden huddled together at a corner table in Starbucks discussing the unprecedented progress of their plan thus far.

Friday, July 30, 2004

Osama likes latte?

Li-fan Chen
Friday, July 30, 2004

Considering the popularity and use of Linux in embedded devices like phones and popular products like Linksys routers, it seems to me that using a Linux for some of these devices makes a lot sense, and is a rather appropriate use of system that lets you choose and pick out the parts that you need.

Most of these systems simply need a file system, and a place to host some code. I see no reason to re-invent the wheel here. With something like Linux you simply cut out what you don’t need, and away you go. Linux for this makes a lot of sense.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Friday, July 30, 2004

Philo are you gonna chip in? You usually have pretty good thoughts on these sorts of issues.

Li-fan Chen
Friday, July 30, 2004

"I know this is all true because I saw Linus and Osama Bin Laden huddled together at a corner table in Starbucks discussing the unprecedented progress of their plan thus far."

Damn I new that was them sitting right across the aisle from Elvis and Salaman Rushdie.

Formerly someone else
Friday, July 30, 2004

The US military is actually using (a modified version of) NetBSD and not Linux.

Full Name
Thursday, August 12, 2004

*  Recent Topics

*  Fog Creek Home