decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Red Hat's Alan Cox: Tips on Writing Better Software
Sunday, October 10 2004 @ 12:11 PM EDT

Here's something nice for a lazy Sunday. Red Hat's Alan Cox, currently on leave and getting his MBA at Swansea University in Wales, spoke recently at the launch of an advanced technical computing group, run by IT Wales, part of Swansea University's computer science department, and they have been nice enough to let us enjoy a video [that's the mpg -- Real Player and DivX here] of his speech. His theme was how to write better software. If you prefer to read about it, here is the introductory article, and page two, excerpted highlights from the talk.

Gartner's Vice President Victor Wheatman gave a speech recently too and he says don't look to Microsoft to solve all your security problems. He said that there are only 500 or so software engineers in the entire world who have the skills to figure out software glitches and fix them. I'm not sure whether he means only 500 outside of Microsoft that a company could hire to help them or if he means that is the grand total on the Windows partition side of the world.

There's no shortage of manpower on the free and open source side, for sure. Companies might want to think seriously about the implications of what Gartner is here saying. Once they do, they may decide that they are using the wrong operating system.

Wheatman says the world has been beta testing Microsoft's products for them. By that he apparently means that Microsoft releases software before all the bugs are out, and they use us to find them. That wouldn't be so bad, if it was clearly labeled as a beta release, you didn't have to "upgrade" to the unstable beta unless you wanted to, and there was a process in place for feedback and addressing the bugs found. Wait. That'd almost be the open source method of bug fixing. The missing piece is that you can fix it yourself, if you know how, in FOSS and then contribute your fix to the world, so they don't have to figure out what you already fixed.

Of course, that isn't how it works in the Windows world. How it works there is you find out you have a security issue when someone takes over your computer without your awareness and sends spam to the FTC in your name or something. You realize it only when you get a response to your "offer", somebody's spam blocker rejects "your" spam, or you get an email from "yourself" to you offering you ibiblio or something else you don't need or want. Do you want your company to be that kind of beta tester? Here's a snip from the Gartner speech:

"'We've all been part of the biggest beta test the world has ever known--Windows. Microsoft will not solve all of the security problems, no matter what the richest man in the world says,' said Gartner vice president Victor Wheatman in a keynote speech at Gartner's IT Security Summit on Monday.

"Wheatman kicked off the conference saying that removing faulty software during operation was costing firms up to 5 percent more than finding flaws during quality assurance tests.

"'One of the problems is that there are maybe only 500 software engineers in the world who can burrow around in that code to find the problem. That's something the industry needs to look at,' he said."

Well, we aren't *all* part of that beta test. I finally got rid of my Windows partition, because I realized I hadn't used it in about 8 months.

Cox addresses the Microsoft beta test phenomenon and explains it:

"Another factor that's led to the current state of affairs is that of canny software companies which shi[p] bad software as quickly as possible, on the basis that once the end user has one piece of software for the job it becomes harder to switch to another one - in that context, Cox considers Microsoft's release of early versions of MS Windows as a very sound economic and business decision. . . .

"You take a WinXP machine, you plug it onto the internet, on average you have 20 minutes before it is infected with something, if it's not behind a firewall. That is considerably less time than you need just to download the updates. These are becoming economic issues, because they're starting to cost businesses all over the world astronomical amounts of money."

If you are a small company, with, say, 15 computers, and everyone uses the internet, just think of the mess you are in after 20 minutes. Think of what your company is looking at in the way of costs to take time to fix all the problems, if you even have anyone who can. Firewalls help, of course, and Cox says firewalls need to be on by default, but they are not impregnable, especially in Windows, because you can't easily see what is going on in proprietary software, and even if you take a peek, you are not allowed, legally, to change anything in Microsoft's software. You have to wait for Microsoft to fix what ails its software.

And not everyone takes the time to configure their firewall properly, sometimes because they don't know how. Anyway, the simple truth is, there's always someone more skilled than you are, unless you are Richard Stallman or Linus or someone like that. So it can happen in any operating system.

But I know from my Windows experience that it happens more readily in that operating system and that you often don't realize it for a long time, if ever. Proprietary software prefers that you not worry your pretty little head about things, just sit back and let them do everything for you. That makes it convenient to use but hard to control. When there is a problem, it compounds the problem. You may be oblivious to a problem going on right under your nose, anyway, because you can't readily poke around and look to see what is happening.

But quality control in software isn't just a Windows issue. Cox suggests it's time to recognize that all humans make mistakes, so all software will have bugs, and so it makes sense to use computers to do what they are good for, using such things as computer validation tools, mathematical models, defensive interfaces, scripted debugging, and rule validation, as well as document trails and statistical analysis to keep the error count as low as possible. His most interesting point, I thought, was what he has to say about root cause analysis:

"I've got a friend who works on aeroplanes, and he has the wonderful job of, when a piece of an aeroplane falls off, cracks, or something before it was supposed to, they go to him and say 'why did it happen?'. And it's then not a case of saying 'oh, this analysis is wrong', it's saying 'how did this analysis come to be wrong? How did it make this wrong decision? Where else have we made this decision?' People are starting to do this with software.. . .

"All of this sort of analysis then leads back to things like, what tools didn't we use? Are our interfaces wrong? And because you're able to actually start digging in and get data, you can start to understand not only the 'oh, it's failed, I'll fix it', sort of the car mechanic approach to software maintenance, but actually the need do the kinds of things that should be done and which go on elsewhere, where you say 'Why did this fail? Where else have we got this? Where else will it fail? What should I do proactively? How do I change the software component involved so it can't happen again, or so that it blows up on the programmer when they make the mistake, not blows up on the user when they run the software?".

Here's SANS's Top 20 internet security vulnerabilities:

This SANS Top-20 2004 is actually two Top Ten lists: the ten most commonly exploited vulnerable services in Windows and the ten most commonly exploited vulnerable services in UNIX and Linux. Although there are thousands of security incidents each year affecting these operating systems, the overwhelming majority of successful attacks target one or more of these twenty vulnerable services.

They provide remediation instructions, too, and what better day than a lazy Sunday afternoon?


  


Red Hat's Alan Cox: Tips on Writing Better Software | 167 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections go here
Authored by: Anonymous on Sunday, October 10 2004 @ 12:16 PM EDT
No legitimate spelling mistakes found by Openoffice.

-Cyp

[ Reply to This | # ]

Off topic here
Authored by: Anonymous on Sunday, October 10 2004 @ 12:19 PM EDT
Trolls here too, but they should write sdrawkcab so it's possible to tell the
difference.

Links <a href="http://en.wikipedia.org/wiki/URL">look like
this</a> with post mode set to HTML formatted.

Lla liah eht ythgimla OCS!

-Cyp

[ Reply to This | # ]

It would also be less of a problem if M$ actually corrected the bugs we find.
Authored by: Anonymous on Sunday, October 10 2004 @ 12:41 PM EDT
But we know they often leave things unfixed for ages, if not indefinitely. And there are further basic design decisions that make it absolutely impossible for them to really create a solid OS, no matter how much feedback they get.

But this link says it better than I can:
http:/ /www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html

Also, I'm pretty sure the "500 programmers" thing is referring to Microshaft's own programmers. There are only about 500 people with access to M$ source code, so they're the only ones who can fix any bugs that are discovered.

[ Reply to This | # ]

Eiffel & Design by Contract a Good Start
Authored by: Anonymous on Sunday, October 10 2004 @ 01:26 PM EDT
Long ignored as an academic curiosity, the Eiffel language and attendant
methodology are probably the entry point into engineering a solution. The
solution should, of course, be subject to peer review. For all the noise, open
source methodology is nothing more or less than the scientific method -- God
bless it.

[ Reply to This | # ]

Red Hat's Alan Cox: Tips on Writing Better Software
Authored by: J.F. on Sunday, October 10 2004 @ 01:39 PM EDT
I had only been using my Windows partition as a storage partition. When I
realized I was deleting Windows files to make room for more storage, I got a
larger drive for Linux and removed the Windows drive completely. I can use it
elsewhere.

[ Reply to This | # ]

A Lazy Sunday--At Least in Florida, For a Change
Authored by: Weeble on Sunday, October 10 2004 @ 01:41 PM EDT
Last time you led into an article about it being a "lazy Sunday" or
somesuch, we were dealing with a hurricane. Glad we aren't this time. Matthew's
to the west and Nicole's to the east.

I am, however, concerned about the folks in Louisiana who are dealing with
Matthew (which I think hit land as a Tropical Storm but is now back down to a
Tropical Depression). Any Groklovians able to report on how New Orleans fared?

---
MS Windows doesn't HAVE security holes--it IS a security hole.

[ Reply to This | # ]

Is glad to see
Authored by: inode_buddha on Sunday, October 10 2004 @ 02:02 PM EDT
glad to see more ppl catching on to AC meanwhile

---
"When we speak of free software, we are referring to freedom, not price." --
Richard M. Stallman

[ Reply to This | # ]

  • AC? - Authored by: sjgibbs on Sunday, October 10 2004 @ 03:07 PM EDT
    • AC? - Authored by: Anonymous on Sunday, October 10 2004 @ 04:45 PM EDT
      • AC? - Authored by: inode_buddha on Sunday, October 10 2004 @ 10:34 PM EDT
      • AC? - Authored by: Anonymous on Monday, October 11 2004 @ 08:17 AM EDT
    • Or... - Authored by: sjgibbs on Sunday, October 10 2004 @ 04:57 PM EDT
You missed an item there Coxy..
Authored by: sjgibbs on Sunday, October 10 2004 @ 02:30 PM EDT
"These are becoming economic issues, because they're starting to cost
businesses all over the world astronomical amounts of money."

It's also an issue for user's at home, and although this may contribute to the
PC maintenance industry it also reduces the likelyhood (and alacrity) of users
sucessfully getting set up at home with the latest technology. This has a
secondary impact on business training costs, the employability of the work
force, and - where children are in the infected household - on the IT education
of the next generation.

It's also flaming irritating.

S J Gibbs
Developer, and sole PC maintainer for most of his relatives.

[ Reply to This | # ]

The Top Twenty list
Authored by: paul_cooke on Sunday, October 10 2004 @ 03:49 PM EDT
All of the microsoft ones are current with any release of
ms-windows... of the ten listed for Linux, none of them
apply to any modern release made in the past year,
especially if auto-updates were being done as a matter of
course. The number one, BIND was fixed ages ago.

---
Use Linux - Computer power for the people: Down with cybercrud...

[ Reply to This | # ]

How long does it take Microsoft to patch vulnerabilities?
Authored by: Anonymous on Sunday, October 10 2004 @ 03:59 PM EDT
(1) Does anyone have access to the url for a popular web site that tracks how
long it takes to fix vulnerabilities?

I recall seeing it some time ago - as I recollect, some Microsoft bugs were
still present, unfixed, after 120 days.

I think that there were Linux vulnerabilities that may have been several days
old.


(2) There is a Web site that shows the top 20 Microsoft and top 20 Unix
vulnerbilities - as recollect, the presentation implies equal levels of
vulnerability.

I somewhere saw a debunking showing that the Unix vulnerabilities had been
largely patched years ago, but that many of the Windows vulnerabilities were
current - that by presentation the web site was just another FUD site. But my
recollection is imperfect.

Anyone have a handle on this?


Thank you,

Epaminondas

[ Reply to This | # ]

500 Redmond programmers sitting in a tree...
Authored by: phirephly on Sunday, October 10 2004 @ 04:31 PM EDT
"'One of the problems is that there are maybe only 500 software engineers
in the world who can burrow around in that code to find the problem. That's
something the industry needs to look at,' he said."

The way I understand this is that there are only about 500 developers that have
access to the code, and can thus fix it. This meant to me the MS developers, as
such. It sounded to me like an attack on their closed source, criticizing that
there are only these few people (compared to their Linux big brothers) that even
have access to it and that these few developers are the bottleneck to MS fixing
their security woes. This, I imagine, this problem only grows when you consider
that the larger segment of them would of course be working on Longhorn (due in
2010 now) and other windows projects.

An interesting thought just hit me too... Perhaps the security team is
considerably slimmer than anyone would guess (two people?). Open source people
know their code. Backwards and forwards. I've been in IRC channels and seen them
debug in real time. Given that Windows bugs and flaws are often well-published
and a lot even have exploiting code, does it seem reasonable to anyone else that
the people maintaining the security, as it were, are not the people that wrote
the original code and have to dig around a lot more to figure out where things
are and what's going on? That could definitely slow down the development
process. There wouldn't seem to be any benefit to them leaving their OS
vulnerable when there's nothing to upgrade to yet. It must be an intentional
decision somewhere... just why?

[ Reply to This | # ]

MPEG?
Authored by: superluser on Sunday, October 10 2004 @ 05:38 PM EDT
Isn't MPEG patent-encumbered? What about Theora? Streams, too.

[ Reply to This | # ]

POLA, Sandboxing and Capabilities
Authored by: spaceturtle on Sunday, October 10 2004 @ 07:37 PM EDT
Here are some important techniques for implementing secure software, not mentioned in the article. These typically do not get the press they deserve.

POLA: The Principle Of Least Authority (POLA) - that software should only be granted the rights that it requires. If you open a (only one) document in a application, that should be the only document the application is granted access to. OS's like Windows and Linux currently grant the application the right to read, modify or delete all the users documents.

Capabilities: (not POSIX capabilities) With capabilities, resources may only be on accessed through valid unforgeable references. I.e. if you call f(x), f can only access x and objects that f can request from x. Hence, well designed object oriented programs pretty much gain good fine grained security for free under capabilities. Shapiro discusses how capabilities differ from ACLs. You can write capability based software by writing in a capability based programming language such as E, or porting your software to a capability based operating system such as EROS.

Sandboxing: Useful for restricting the rights of legacy applications. The overhead of Sandboxing need not be large, because only a handful of dangerous syscalls like open() need to be intercepted and analyzed against the security policy before being allowed . Calls like read() and write() are much more frequent and do not need to be intercepted, as they only manipulate files that are have already been opened.

[ Reply to This | # ]

500 programmers
Authored by: Anonymous on Sunday, October 10 2004 @ 08:36 PM EDT
I would believe that the 500 programmers who can fix security or other bugs in
Windows are the 500 programmers working for Microsoft who are sufficiently
familiar with the code and actually have access to it to fix it.
Which is not much compared to Windows' desktop dominance or the number of
programmers FOSS has who can fix bugs.

[ Reply to This | # ]

Completely O.T. but
Authored by: Glenn on Sunday, October 10 2004 @ 10:03 PM EDT
While trying transcribe part of the pdf from the the previous topic on
AutoZone's interrogatories, I found myself flailinf about trying to keep a copy
of the pdf side by side with the editor I was trying to use.
So I got a brainstorm and threw an old pci card in my Linux box and
configured XF86Config-4 for dual cards using information freely available on the
internet and voila, I have a dual monitor system that works very well with KDE.
It now is a simple matter to open a document on the right hand monitor and
the editor in the main monitor and mis-type away. But I did transcribe three
pages that way.
Now the only problem I have is getting another monitor to put with the
computer that my granddaughter (and sje really is grand) uses when she comes
visiting.

Glenn

[ Reply to This | # ]

Root Cause Analysis
Authored by: swmcd on Sunday, October 10 2004 @ 10:20 PM EDT
There's a little bit of root cause analysis on the Microsoft Windows FindFirst/FindNext interface in

These are a few of my favorite (Microsoft) bugs

[ Reply to This | # ]

Red Hat's Alan Cox: Tips on Writing Better Software
Authored by: Anonymous on Monday, October 11 2004 @ 06:13 AM EDT
Alan's number one tip - "Execute-only code" - came as a bit of a
surprise.

I only recently understood how the buffer-overflow attack worked, as I'd
stupidly assumed that non-executable data sections were standard computer
design, as I was taught back in the early 70's (PDP-10 'pure' code), and was
standard on all 186 and 68K-based embedded systems I worked on in the 80's and
early 90's.

So if it's true that "Cox cited recent developments in microprocessor
design", does this mean the current generation of Intel-based micros are
finally catching up with capabilities that were standard on the 186?

[ Reply to This | # ]

Red Hat's Alan Cox: Tips on Writing Better Software
Authored by: Anonymous on Monday, October 11 2004 @ 07:59 AM EDT
"There's no shortage of manpower on the free and open source side, for
sure."

There is in terms of knowledge of security; the FreeBSD committers are some of
the most dedicated people on the planet and they're still finding problems in
fairly core sections of code.

The problems with windows aren't so much that it's actually impossible to
secure, it's just that the shortcuts taken in the code _allow_ for bad security
in the first place. For example, using 'choke points' that funnel given actions
through a single location rather than pointing all over the place.

"If you are a small company, with, say, 15 computers, and everyone uses the
internet, just think of the mess you are in after 20 minutes."

A lack of firewall will mean that Linux boxes will get owned as well. You
should not be on the internet without a firewall in place, and this is something
that everyone has to get used to. And yes, I have cleaned up these problems
before now, and it's not that huge a problem once you've airgapped and started
cleaning procedures. The cute thing is that outside consultants like myself end
up charging more than a small firewall box would have in the first place.
However, the people that installed the kit without the firewall should be
liable.

"And not everyone takes the time to configure their firewall properly,
sometimes because they don't know how."

A tired argument. There's nothing more simple than turning on the XP firewall,
which works as a primary form of defense. Most routers come with firewalls that
are set to deny by default on all but the most common ports.

Even Zonealarm uses big friendly lettering and a decent website to back up the
actual firewall itself.

"because you can't easily see what is going on in proprietary software, and
even if you take a peak, you are not allowed, legally, to change anything in
Microsoft's software. You have to wait for Microsoft to fix what ails its
software."

PJ, I think it's about time that you pointed out the last patch you submitted.
The thing is that the vast majority of people using computers that become
compromised are not coders, admins or other luminaries that have jumped the gap
and moved to *nix systems, but have enough knowledge to know that alt+0169
inserts a © symbol into their word processor.

If everyone shifted to Linux overnight, then you would see vast problems trying
to get people to speed in actually installing free software and using machines
in the same way they've been used to in the past. Go check out CSR's complaints
about CUPS, or check out your orphaned packages, or try updating PHP after
they've changed the method for porting...you can spend a couple of hours
diagnosing these problems when you have a years of *nix admin under your belt.

Drac

[ Reply to This | # ]

Where do we get it wrong?
Authored by: JC_Aussie on Monday, October 11 2004 @ 09:07 AM EDT
I don't mean to stir the pot but... I agree open source is a more "scientific" method of software production as it allows peer review/testing/etc, however.. sometimes we still get it wrong.

Is the answer a more strongly typed language such as ADA or is the answer Eiffel as others have suggested above? The introduction of protected memory spaces such as "No-eXecute" (NX) suggested by Intel, seems a little like shutting the gate after the horse has bolted. I can see the value but don't see why it should have to happen in the first place.

What paradigm shift should occur in the production of software to reduce the possibilities of errors?

I ask this not to attack the long suffering but powerful C/C++ but I don't think Java is the answer or any other language that sacrifices power for safety.... it should be possible to have both. I don't really want as a response a list of obscure languages which are steps along that path but rather an objective idea of where we could go and what we could do to fix them now.

OOP has some elements which can help reduce errors, but others more knowledgeable than I, would also point to it's failures just as easily. I've only been programming for about 8yrs now and have seen some atrocious code (some of it my own) so I'm looking for some grey-headed wisdom on the matter.

[ Reply to This | # ]

OT Question for Coders
Authored by: Anonymous on Monday, October 11 2004 @ 09:48 AM EDT
[I've logged out for this for fear it is naive and flammable]

This is OT because it addresses the IP issues rather than security.

Is it possible to create a new coding language dedicated to open source with a
GPL type license so that anything written with it is open, changeable, and
distributable and is not "proprietable." It would seem that one could
order work done in this language and never have to worry about copyrights or
patents since it is a free language with its own methods. One could even get
statutory protection.

Does this make sense?

[ Reply to This | # ]

No Silver Bullet
Authored by: jseigh on Monday, October 11 2004 @ 10:45 AM EDT
Fred Brooks has written on most of this before. Nothing's changed since then and it's not likely to. Part of it's that people who get into positions of power or authority are not going to change the rules of the game that got them there, whether it be software or politics. For software, people who are good at dealing with complexity and know more about the software than anyone else will end up with architectural roles. Once there, the last thing thing these people will do is simplify the software so just anyone can be as good as they were. So you will never see simple easy to use and comprehend software. Never.

For policitians, it's knowing how to game the electoral process and get elected. They're not going to change the rules that they're so good at and give themselves less of an advantage in elections. It will never happen.

On some of the topics that Alan Cox touched upon. That thing about Boehm style garbage collection will solve all memory management problems is a bit of a myth. This has been discussed at length in several technical discussion groups. It's a mainly unsubstantiated assertion and you tend to get a lot of rote arguments such as Boehm style is good because it's the only one that can recover cyclic references. But unless you're doing graph theoretic programming this isn't really a problem and most of us never do implementation of graph theoretic algorithms.

In general Alan went over a lot of good ideas. There's no reason a lot of them shouldn't or couldn't be put into practice except that the current market rewards quick and dirty and getting your product out there first.

[ Reply to This | # ]

Red Hat's Alan Cox: Tips on Writing Better Software
Authored by: swmcd on Monday, October 11 2004 @ 02:47 PM EDT
oops...the request for a reference was me.
I forgot to log in.

[ Reply to This | # ]

Red Hat's Alan Cox: Tips on Writing Better Software
Authored by: swmcd on Monday, October 11 2004 @ 03:30 PM EDT
oops...the request for a reference was me.
I forgot to log in.

[ Reply to This | # ]

Two causes for bug-ridden software.
Authored by: n5yat on Tuesday, October 12 2004 @ 11:18 AM EDT
I've been in the software business since 1979. Yes, there have been improvments
in methodologies, tools, and languages. But bottom line, two things (which are
different sides of the same coin) always hinder development of good software.
These two things are schedule and money. As long as companies go out and promise
whatever schedule is required to win the contract, and then force fit the
software development to the schedule, you will have bad software. Virtually
everything that could be done to make code good is sacrificed when you have a
project that logically requires 8 good people to complete in 24 months, and
they've thrown 5 people at it, and promised it in 9 months. Detailed analysis,
design documents, code walkthroughs, comments in source code, extensive QA --
all get thrown out to meet the deadline. And, heaven forbid that the software
team asks the company to purchase some software tools to enhance productivity -
like tools that analyze code for common errors - No, just hide in a corner and
write code for 19 hours a day, and wait for a pat on the back when the deadline
is met...

Until schedules are defined realistically instead of by the sales staff,
software will suffer.

[ Reply to This | # ]

Red Hat's Alan Cox: Tips on Writing Better Software
Authored by: Anonymous on Thursday, October 14 2004 @ 04:06 AM EDT
Cox addresses the Microsoft beta test phenomenon and explains it:

"You take a WinXP machine, you plug it onto the internet, on average
you have 20 minutes before it is infected with something, if it's not behind a
firewall. That is considerably less time than you need just to download the
updates. These are becoming economic issues, because they're starting to cost
businesses all over the world astronomical amounts of money."

Hmm. Not sure if this is the same RedHat that just recently told the world that
Linux was not ready for the desktop, to use windows, but I just wish Redhat
would shut up. Lousy distribution, lousy PR.

If I were to take tips on how to code, it wouldn't be from anyone from RedHat or
anyone who bore the brand.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )