If McBride is to be believed, he's aiming for a future in which people keep on using and adopting Linux, but they pay a certain licence fee to SCO for every host, much as people do with commercial Unix.
Not going to happen.
Putting proprietary licensing onto the Linux kernel puts every distributor into violation of the GNU GPL, and open to suits from every copyright holder. The GPL is pretty clear: if the kernel can't be distributed (and redistributed, modified, etc) freely, it can't be distributed at all.
Not only, but also: SCO are talking about giving people licences to binary Linux kernels. But who wants that? It would be just another Unix: people would have no freedom to debug, inspect, fix or adapt it. Why would you bother? Even users who never see a compiler would not enjoy the fruits of the open source process. Linux would shrivel.
Even assuming all SCO's outlandish claims are true, they are not going to make money the way they want. There are ways for them to make money. One is by pumping up their stock price and selling the executive's and Canopy Group's stock. Another is to be bought out and shut up by IBM or someone else, but it looks like they blew that chance. Another is to scare people with unsubstantiated lawsuit threats, but I think most people with enough money to be worth suing can know bluff when they see it.
Here are the outcomes I can see as possible:
- Most likely: SCO are simply making it up. They make a lot of noise for a couple of years, then fizzle.
- There is some kind of infringement because of a nit in the IBM contract. The offending code is removed and rewritten. We return to our regular programming.
- Through some as-yet-unknown theory of code tainting, a court decides that it is impossible to excise SCO's copyrighted code from Linux. Everybody leaves. SCO is left with nothing.
There was a tight window for a lawsuit like this: it had to happen after there was enough money in Linux to attract sharks, but before people really got to understand the point of the GPL and when they could hear the idea of a binary licence fee without laughing. I think they missed it, but we shall see.
Laura DiDio has run up her colours in her latest article.
Reasonable people can differ on some aspects of the issue, and in particular on just how much caution is justified, or whether there is any likelihood that there's any common code. It's arguable. We'll know in a few years: by which time it's likely to be moot, as Linux will have rolled on regardless.
DiDio's original position was extreme caution: companies should go slow on Linux because there's a risk of SCO charging licence fees. OK: I disagree, but it's a valid opinion.
Now she goes a lot further than that. pro_coder is quoted on LWN with a nice reply to Yankee Group:
Provable, egregious factual errors first:
1. The very first line "The SCO Group lawsuit against IBM for copyright infringement"
There is no copyright violation case, it's a contractual dispute. This has been pointed out by numerous commentators on many occasions.
2. "SCO claims it comes directly from UNIX System V: the copyrights it owns"
SCO has made no such claims. SCO concedes that IBM possesses the copyrights for most of the code in question, including RCU, JFS, SMP. And SGI possesses copyrights on NUMA.
SCO has also not accused IBM of contributing the infamous "80 lines".
3. "The Yankee Group strongly urges IBM Linux licensees to contact SCO."
There are no "IBM Linux licensees". IBM does not "license" Linux. There is no "IBM Linux" to be licensed. Sam Palmisano was very insistent on this, that IBM would not create an "IBM Linux" to compete with RedHat or SuSe.
IBM installs RedHat or SuSe on some servers that it sells while IBM Services may support a Linux installation, but again, there is no IBM Linux. There are no "IBM Linux licensees".
IBM does not "license" Linux.
Next, statements made in the analysis with no evidence offered, but with much publicly-available data that points to the exact opposite conclusion."
1. "There are strong indications that the industry at large takes SCO's claims seriously."
Ms Didio does not point to a single public statement by any corporation (other than those who stand to gain directly by SCO's actions). And she ignores a mountain of evidence that shows that this assertion is plainly wrong. Corporate adoption of Linux since the whole SCO business started has been astounding, with new announcements of contract wins occuring almost daily.
2. "Wall Street sees it that way. SCO's stock soared nearly 15 percent on the news. It jumped $2.82 and was trading at $14.77"
The gold-standard test for "wall street confidence" is that options become available from brokerages. The fact that this has not happened is a good indication that "wall street" has zero confidence in SCO.
And there are many reasons to back up this reading that "Wall street" has zero confidence in SCO.
- Volumes are extremely small.
- Institional ownership in SCO has been going down.
- There is a massive amount of dumping, of run-for-the-exits from SCO insiders. Many times in the last month SCO insider selling accounted for 10% of total volume.
And a highly imprudent recommendation. "Yankee Group strongly urges IBM Linux licensees to contact SCO. It doesn't cost anything to have the conversation and determine the cost of their binary Linux license offering."
Is it Yankee Group's position that giving one's name and corporate IT information freely to a possible offensive litigant is a good thing to do?
So if SCO has absolutely no knowledge of some company, is Yankee group really recommending to such companies that they phone SCO and tell SCO "we're using Linux, take down our name and address and our patterns of Linux usage so you can pursue us in the future with more threats".
Is that really Yankee Group's position? Is that really a prudent action?
(This made me smile.)
Interesting that Ms Didio feels the need to include this statement - "Linux community to work overtime promoting their respective points of view to influence the opinions of corporate customers, the media, and analysts. Such posturing is designed to make one or the other party blink."
Does Ms Didio consider it "posturing" when people point out concrete factual errors? Does Ms Didio consider it "posturing" when people point out obviously misleading statements which have no basis in publicly available information?
And this is especially instructive. "In the interim, the case will be tried in the court of public opinion." "Would It not be in Yankee Group's interest and in the public interest that your published works be accurate? That these works add value to the debate and not make factual errors and baseless assertions?
There are a couple more inaccuracies in addition to those pro_coder noted:
Although SCO has given no indication it will file suit against any corporate customers in the near or intermediate term, registering the copyrights certainly gives the company the ability to do so.
According to a real lawyer (not some random analyst), registering a copyright in the US does not establish any ownership of the material. SCO have done some paperwork; they have not gained an ability in a meaningful way.
Big Blue is a loser at this point...
I'd be happy to bet $100 on which one of SCO and IBM will be profitable in five years.
IBM seem to be taking a slow and steady approach, rather than seeking to shut SCO up straight away. Presumably they're doing that based on good legal advice and confidence that they will prevail. Perhaps if SCO's FUD starts making customers edgy they'll change that approach. The option of offering indemnities, or a countersuit against SCO remains open.
What happens when you feed monkeys crack, then give them a copy of The Art of Unix Programming?
(That makes me think running dissociated-press acrss TAOUP might be entertaining.)
I've just been using and exploring the Management Processor (MP) on an HP rx2600 Linux Itanium server. It's really slick. I'm very impressed.
The MP is basically a daughterboard containing an ARM7 embedded processor, which has a serial and 10/100 ethernet port, and a simple VGA controller. It's tied into the main motherboard through I2C, PCI and other (?) connections, so it can see what's happening but is independent from the main processors. The board has a little bit of RAM, ROM, and NVRAM.
This is kind of similar to the debug monitor features you might have encountered on Sun machines or Macs, but putting it on a separate board has a few interesting features. One is that the MP is active whenever the machine has mains power, even if the main processors and fans are shut down, and it can bring it back up. Another is that the MP ought to be less intrusive with the operation of a machine: a debug monitor typically halts the whole machine while its active, whereas this allows the machine to keep running.
An enormously cool thing about the way the MP is implemented is that its console appears to Linux as a regular UART. Simply by booting with console=ttyS0 you can get all the Linux boot information routed through the management processor. That in turn allows a few interesting possibilities: sending them to a serial console of course, or across a telnet connection, or logging them in NVRAM so they can be inspected later. Similarly if the kernel panics, you get that information in a telnet window where it can be easily saved, not on a screen where it has to be copied down.
Other nice features:
- Turn on an attention LED, so you can find the machine in the machine room.
- View a text representation of the front panel LEDs.
- Reboot, power up or down the machine.
- Get detailed diagnostics on every part of the machine, and a record of hardware events.
- View console logs.
- Share sessions between several adminsitrators.
- Induce a kernel dump. ("Transfer of Control" in HP's language.)
One downside of the current implementation is that the network interface is not active by default, and you apparently can't get into it through the VGA console. So to enable all this functionality, as far as I can make out, you have to start out with a null modem connection, which can be a bit difficult. But there may be some way around that that I just have not discovered yet.
I was at first a bit confused about the interaction between the MP and the EFI (Extensible Firmware Interface) pre-boot system, but it looks like they're more or less separate and complementary.
I suppose these features are taken for granted by the high-end Unix audience, but this is the first time I've personally seen them in a machine that is within shouting distance of i386 bang/buck, at least for some applications. Not needing to traipse down to machine rooms to work out whats wrong, and being able to get accurate information about a problem without needing to reproduce it or suspend operation should be a boon for serious users.
All this, and it also keeps my feet toasty warm!
kfishd: an implementation of kfish in the kernel.
The "TOC" button on HP servers and workstations stands for "transfer of control", apparently in the sense of switching control of the machine from the regular OS to a debugger or monitor.
Don Marti quotes Thomas Jefferson, in reply to Matt Beland:
The reason IBM shouldn't [buy out SCO] is the exact same reason why no government should ever negotiate with terrorists, and why kidnap victims should never pay off ransom demands. That last being particularly appropriate.
From what I learn from the temper of my countrymen and their tenaciousness of their money, it will be more easy to raise ships and men to fight these pirates into reason, than money to bribe them.
Use of the term "pirates" is nicely apropos given that SCO is now apparently distributing software (the Linux kernel and others) in direct breach of its licence. (The GNU GPL forbids parties who redistribute the software from imposing additional condiitons and this is exactly what SCO are doing at the moment.)
(previous message on this topic)
A usenet search finds additional evidence.
The whole point of remove.org (a global opt-out list that people pay to join) is a bit implausible and at odds with every other antispam organization. How is somebody who paid up meant to know if remove.org actually did anything with the money?
Other patterns on the web make them look more like a sleazy referral-marketing scam than a genuine anti-spam organization, such as duplicated pages on MLM directories.
MCA is "Machine Check Architecture", which is a way for the hardware to report problems to the operating system. These can be fatal problems such as a CPU internal error, or warnings such as a corrected memory error. (Also "Machine Check Abort", which means the fatal ones in particular.)
The OS can make them available for userspace analysis tools, which can do things like statistical analysis or interpretation of vendor-specific fields. The OS might also handle errors by panicing in severe cases, or handling them in less serious cases. For example, the OS may be able to respond appropriately to failure of a particular memory line, or even failure of a processor in an SMP machine.
The implementation depends on the extensive on-board firmware including the SAL (System Abstraction Layer).
MCA information can survive reboots or power cycles so it can be recovered even if the machine suddenly aborts.
Good document on Machine Check Abort (MCA) Handling
* Applications cannot continue with bad data: they are killed when they touch an error spot in the memory.
* Applications having error spots in their valid memory regions, should be let run until they touch an error spot. There is a reasonable chance that they can run to completion.
As most of the memory is used for the applications - several (tens of) Gbytes vs. 64 Mbytes of the kernel - almost all errors happen in user space. User mode errors are recoverable by killing the application affected. Kernel mode errors are fatal because the error detection and recovery paths in Linux are not elaborated...
PAL = Processor Abstraction Layer, SAL = System Abstraction Layer.
An MCA INIT can be generated from a hardware button on some HP machines, so that you can NMI a hung machine and hopefully get some debugging information.
The zx6000 has a TOC button too, but RH AS 2.1 seems to just hang rather than going into a debug mode when it's pressed... :-/
Although many IA-64 machines have some kind of front-end processor, it looks like that is not used for the console under Linux. Instead, Linux talks directly to the serial port or VGA card. The front-end processor can also talk to the serial port, but this is apparently done at an electronic level; it doesn't mediate access.
from Slashdot: "IBM's Unix license is irrevocable, perpetual and fully paid up. It cannot be terminated. It can't be bargained with. It can't be reasoned with. It does not feel pity, remorse, or fear. And it absolutely will not stop, ever, until you are dead."
I just happened to be looking at the kgdb kernel debugger stub and saw this copyright message:
+/**************************************************************************** + * Header: remcom.c,v 1.34 91/03/09 12:29:49 glenne Exp $ + * + * Module name: remcom.c $ + * Revision: 1.34 $ + * Date: 91/03/09 12:29:49 $ + * Contributor: Lake Stevens Instrument Division$ + * + * Description: low level support for gdb debugger. $ .... + * Integrated into 2.2.5 kernel by Tigran Aivazian <email@example.com> + * thread support, + * support for multiple processors,
(I didn't go grepping for SCO; it just popped up. Probably there are many more. Of course, this was the old SCO, capable of actual engineering effort, not the sad parasite they have now become.)
This code is concerned with on-line debug support for multiprocessor machines, which is an “enterprise” feature inasmuch as that word has meaning. The term is RAS: reliability, availability, and serviceability. As you may recall, these are exactly the features that SCO thought could not possibly have got into Linux without IBM's assistance, and IBM's unauthorized use of SCO's code.
But here we see that at least some of the support in that area was intentionally contributed by SCO, and intentionally released under the GNU GPL. SCO's claims that IBM breached a contract by putting RAS and SMP functionality in are a bit hard to swallow when SCO was doing the exact same thing.
I suppose there is the outside possibility that this was an unauthorized release either by Aivazian or his managers, though that seems very unlikely. (It seems even more unlikely that if someone where going to disclose SCO proprietary information they would do it under their own name and from a SCO address.) I don't think that's true. But if it were true, surely it is a disciplinary issue within SCO, and not really any of the concern of the rest of the world. SCO has now granted a licence to the code; if they did that by accident it's not my problem and they have no grounds to suddenly ask for more money.
Perhaps, splitting hairs, SCO will say: well, we put in remcom.c but this other code over here was copied in from UnixWare by some other programmer. (As has already been extensively discussed, SCO really need to say what code was allegedly copied to be taken seriously.) But given evidence that SCO were working in this exact area, I wonder why they didn't notice their proprietary code being slipped in right next door, if that was in fact happening.
Some of the more gullible analysts keep saying, “but what if it's true?” And indeed, you can keep playing “but what if the moon landings were faked” all day without absolutely eliminating every possibility. But back on planet Earth, the story about SCO is increasingly clear. The overwhelmingly likely scenario is
- IBM didn't breach their contract, and in any case their Unix licence is irrevocable.
- Nobody copied SCO UnixWare source into Linux. Firstly UnixWare is terrible; secondly it does not have the features that are alledged to have been copied; and finally if they were copied they would not be a good fit.
- In any case, SCO's claim is estopped for various reasons, including their continuing distribution of the relevant code under the GPL.
- SCO is infringing on the kernel copyrights by selling copies in contravention of the licence.
- In five years time Linux will still be in the top five most important operating systems, and SCO will be a paragraph in Unix history.
Joe Pranevich has a good document about new features in the Linux 2.6 kernel.
Open Source Victoria filed a complaint with the Australian Competition and Consumer Commission according to a story in The Australian:
Open Source Victoria today filed a complaint with the Australian Competition and Consumer Commission, asking it to investigate SCO's activities in light of "unsubstantiated claims and extortive legal threats for money" against possibly hundreds of thousands of Australians.
OSV member Con Zymaris said "We take serious issue with The SCO Group's latest ploy, namely that of seeking licence fees from Linux users. As such, we have filed a complaint with the ACCC. We call on any Australian Linux users who feel pressured by SCO's actions to immediately contact the ACCC and file a complaint."
Zymaris said that with its latest move, SCO had crossed the line. "They're basically saying 'you owe use money'. But if someone asks 'why do I owe you money', they reply, "we can't tell you why, but you have to pay us anyway'," he said.
Another OSV member Andrew Pam said the organisation believed there may be a case to answer on the issue of "misrepresentation of need", where an organisation was suggesting that people must make payments that they were not obligated to make.
That sounds pretty accurate to me. I'm all in favour of people being able to buy proprietary licences if they want to, but demanding money with menaces is and should be illegal.
*If* (and this is if-hell-froze-over hypothetical) it turned out that SCO had some proprietary rights to Linux, *and* they had not waived their rights, then once that was all legally established it would be OK for them to start requiring users to purchase licences. However, when the claims are so tenuous, unlikely, and unsubstantiated, they seem to me to be gratuituously interfering with businesses that use or sell Linux and related products/services.
Trink Guarino, IBM spokesman quoted on GROKLAW says something similar:
IBM is not aware of any Unix System V Code in Linux. SCO needs to openly show this code before anyone can assess their claim. SCO seems to be asking customers to pay for a license based on allegations, not facts.
Australia is (at least?) the third country to have an interference with trade or deception investigation into SCO. They are subject to similar actions in Germany and Poland. In addition, there are rumours of an insider trading investigation in the US, plus an unrelated ethics charge against their head lawyer. It's good to see that there is some kind of legal mechanism to prevent people going around making random damaging untrue claims, even if it takes longer to operate than one might like.
GROKLAW has the good dope on the US case and the legal precedents behind it. And isn't laches just such a great word?
Slashdot has a story about this too. (Although, typically, they called it a lawsuit when I think in fact it is not. At this stage it is a complain to a government body, not to a court.)
"Jonathan Eunice, an analyst at Illuminata Inc. in Nashua, N.H., said... 'I think that from a legal point of view, we're in the incredibly early days' of this legal fight, Eunice said. For some users, the offer may be enticing, depending on the cost of the special Unix licenses, he said. Some may see it as a 'cheap insurance policy' to protect them against eventually being sued by SCO, he said. On the other hand, because the case isn't even yet in the courtroom, the risk for users is essentially unchanged from recent months, Eunice said.
"'I don't see it as something that should incite an enterprise Linux customer to do any more than they did last week,' he said. 'The threat level increases a bit, but mainly because of the perception that SCO is a psycho killer, not that the case has changed.'"
Imagine registration of wellsfargo.com with the first o replaced by a Greek omicron: wellsfargο.com. In proper typesetting, and in common Unicode fonts for computers, the omicron and o have the same appearance.
Since January 2003, Debian has had six security advisories relating to insecure temporary files. Most of these are not Debian-specific, but rather problems in the upstream source.
A typical problem is that a program will create a file with a predictable name in /tmp, without adequate checks for whether it already exists. Because /tmp is world-writable, a local attacker can create the file before the program runs, and either make the program write somewhere it shouldn't, or examine what is written.
Many of these are not enormous problems: in the first place, they can only be exploited by an attacker who already has an account on the machine, which is not a problem for most hosts. (Either they are single-user, or the users can be held accountable.) Secondly most of these problems have been in packages that I suspect are not used by the majority of people, such as an emacs IRC client. They're still important to fix, but not as bad as the Windows worms that seem to be currently bringing some companies to a standstill.
SuSE have an article discussing other temporary file security problems from the developer's perspective.
What really annoys me is that most of them could be systematically avoided by using per-user private temporary directories. I suppose this might cause trouble for files that really need to be shared between users but I think those cases are the exception. Of course individual users can set TMPDIR=~/tmp but it would be nice to see it made the system-wide default.
libpam-tmpdir will apparently do this, including creating the temporary directory as needed. It might be nice if it were on by default. I can't see a homepage for it aside from the Debian package page so I don't know if it would be in any other systems.
A Florida Bar grievance committee found probable cause that David Boies violated rules of misconduct by giving money to a client and improperly supervising other lawyers.
The committee's July 10 finding is similar to an indictment. The case will be heard by a judge appointed by the Florida Supreme Court.[...]
If found guilty, Boies could be barred from appearing in state courts in Florida, where he is not licensed to practice law but appears on a case-by-case basis.
Also, from the Palm Beach Post
"His ethics are appalling," Carol Lewis said.
"Everybody says Boies is a genius, but I don't see it," her husband said. "I see Goliath falling."
remove.org, who claim to be an anti-spam organization, just sent this spam to an address that was certainly not obtained legitimately. (I can guarantee that our mailer-daemon did not sign up for their messages!)
What do you suppose are the chances that anyone who signs up for their supposed opt-out list will have their address sold to spammers? For 50c I'd set up a dummy address and try it.
If I were an American I'd be pretty pissed off at having my national icons spread across the banner of such a sleazy enterprise.
From: Danielle Cushman
Subject: FWD: concerned parent Date: Tue, 22 Jul 2003 18:42:45 -0500 To: mailman(a)lists.samba.org
[-- Attachment #1 --] [-- Type: text/html, Encoding: 7bit, Size: 2.7K --]
[-- Autoview using /usr/bin/links -dump ''/tmp/mutt.html'' --] This is worth checking out... please pass it on.
----- Original Message ----- From: Danielle Cushman To: Sharron Kelly Cc: Karla Anderson; Megan_Jim_Davis@hotmail.com; EdWaldon@lycos.com; Andrea Manning; Bill Barnes; Mark and Karen Whyte-Iowa; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; Laura Clark-Glacial Sent: Tuesday, July 22, 2003 10:20 AM Subject: concerned parent
There is a large problem facing our nation that we all need to work together to fix. My children have received pornographic emails and I want it to stop. I found this site, www.remove.org that stops Spam and pornographic material in emails. We need to make sure that everyone knows there is a way to stop these emails.
Please forward this to everyone you know so that we can stop this huge problem for good.
Thanks ----------------------------------------------------------------------- > > >To have your email address added to the national opt-out directory >please click on the following link: http://www.remove.org. > > -----------------------------------------------------------------------
Notice: We honor our recipient's choice to receive information about our available products and services. To unsubscribe click here
Chris Yeoh is keeping a blosxom blog about OLS and other stuff.
If you were a company called Powergen and you had a subsidiary that operated in Italy, what would you call that company's Web site?.
Probably not http://www.powergenitalia.com
But they really did. ...
Caldera/SCO point to Linux's lack of warranty protection (as if warranty claims for software were ever feasible); says IBM avoided copyright liability by avoiding direct distribution.
I'm slightly amused by SCO's sheer nerve in criticising Linux for lack of a warranty when their shitty operating systems never had one, and neither has the Windows EULA, Mac OS, or an other system I know of. Have these supposed analysts ever *glanced* at a software licence and seen the all-capitals lack-of-warranty clause?
Another important thing to note is that SCO still have produced no evidence that there is any similar code in Linux, or that it wasn't copied from Linux into SCO, or BSD into SCO. Indeed, not only have they not produced any evidence, they haven't even described any evidence that they might have.
If anyone gives SCO money because of their mere groundless assertion then I'm going to have to bill that company for using my bridge.
I see in the referrer log that somebody from Turkey is looking for "compiled netcat SCO unix". As we say in Australia: “you poor bastard”. If SCO keep this up the chances of most free software projects having any support for Unixware, OpenServer or Caldera is pretty slender indeed.
dmullen asks of Aaron Swartz:
What, precisely, is so awful about TAOUP? Personally, I consider it to be one of the best books ever written on programming in general, let alone Unix programming. I found useful information and advice on every page.
I think TAOUP is a pretty nice book, and I will probably buy a copy when it comes out, and recommend it to my friends.
However, I don't think it is perfect, or above criticism. It might be in my top 20 books on programming but I don't think it would make my "top few".
What's wrong? Here are some complaints I prepared earlier.
I guess overall it seems to focus too heavily on "things the author thinks are interesting/funny". (I think that's a failure of later versions of the Hacker's Dictionary too.) Don't get me wrong: I'm all for authorial voice, and I know it's impossible to suppress completely. But in TAOUP's current draft, I think it is too obtrusive.
For example, a fair number of the examples are taken from esr's own projects, such as fetchmail. But I don't know anybody aside from esr, who would say fetchmail is a really prime example of Unix design! Why not pick an example that really is broadly recognized as brilliant?
Has esr been lazy in just using examples from his own home directory? Or is he suggesting that his own designs are sublime and perfect examples of Unix? The kernel hackers who make special mention that that esr's CML2 system was *not* merged might disagree. Either way it's a bit irritating.
One thing that sprang to mind is that rusty's "iprint" (apt-get install iprint) is probably more Unixy than esr's "ascii". (iprint's smaller :-)
Now certainly looking at the design of your own programs is easier, but if you're aiming to be the definitive work and explicitly comparing yourself to Knuth then I think you are obliged to go further afield. (Does The Art of Computer Programming deal mostly with code from TeX? No.)
Similarly, his discussion of the history of Unix, or of Unix compared to other operating systems, seems really skewed to his personal views. You can see his position on the open source/free software kerfuffle intruding. Of course history is shaped by the historian, but I think he does it more than is really needed or helpful.
Most of the problems seem like they could be fixed by more editing and constructive criticism before it's released. I wouldn't be surprised if a second edition, if there is one, is better. (Perhaps esr's trying for early-and-often in books?) Now it is perhaps a bit unfair to criticize it for this when it's not in print yet, but the web page gives the impression that it is nearly a final draft.
The tone and level is a bit uneven too. Sometimes it is very jokey and sometimes moderately formal. Some examples are a bit labored and some parts that I think ought to have examples are missing.
TAOUP does deal with a topic that has not been fully explored before, which makes a nice change from the two shelves of "C++.NET in 24 Hours for Complete Morons" at my local bookstore. It's not quite the only one there: The Practice of Programming, Patterns of Software, Code Complete, and Unix Network Programming
approach different parts of the topic. If TAOUP irritates Swartz enough that he's motivated to try to do better then I think that's a good thing.
Judith Brett, author of a forthcoming book on Australian Liberals, in the present issue of Arena Magazine, quoted in today's Australian:
In 1997, accusing the ABC of “too narrow a spectrum of views” on political and social issues, John Howard said: “It is one of my criticisms of the ABC that it doesn't have a right-wing Phillip Adams.” But the problem is that a right-wing Phillip Adams — someone with his capacity to talk intelligently on such a breadth of topics — is not easily imaginable in contemporary Australia.
The ABC has become a symbol to the Liberals of their loss of a constituency which was once their own. Ever since the intelligentsia defected to Labor with the coming of Whitlam, Liberals have viewed the ABC with suspicion...
The progressive middle class is now more likely to oppose the Liberal Party than support it; the commonplace people who share Howard's views are more likely to be listening to the shock jocks of talk-back radio than to the ABC. This is not necessarily an electoral problem, but it is a marked shift in the party's historical position.
Menzies would never have said, as Howard did shortly before the 2001 election: “I am scorned by the elites and held in such disdain.”
Of course the ALP seem to be doing an equally professional job of alienating the intelligentsia, and the Democrats are apparently imploding. It's a bit depressing.
According to a Microsoft-funded study reported in the Register, Linux developers are paid more than embedded Windows developers. (If I were a CS undergraduate again, I know what I'd play with on the weekends. :-) Thanks, Bill!)
John Lettice's meta-analysis is pretty interesting: Microsoft's study would like to show that Linux is more expensive and risky to choose as a platform, but it seems more likely that people choose Linux for projects that are inherently more risky (and have a higher potential return):
Windows, in all its many and varied forms, is about commoditisation. Microsoft offers tightly defined and controlled platforms together with a wealth of standard tools, Ts & Cs and support packages for developers to work with, so it's fairly cheap and easy to produce products that are pretty similar to other people's products. Microsoft also, from way back in the 80s, has pushed the industrialisation of the development process. The result as far as hardware is concerned has been that differentiation and price have been eroded, and if you want to compete - with, say, Dell and HP - in the commodity handheld computer market you need to keep your team size down and your ambitions modest.
Avoiding commoditisation while sticking in the Windows arena is however hard, and quite probably a suicide mission, so if you don't want to go on it you go somewhere else instead, check? You don't necessarily go for Linux (Krasner's Linux versus Windows focus is in this sense artificial), but whatever you go for you're likely to be spending more on development than you would by taking the Windows commoditisation route. And your developers are more likely to be more expensive, goof-off prone geeks than cheaper, downtrodden code-monkeys.[...]
High risk projects that are possibly aimed at new categories we think may exist are more expensive and fail more often, but produce higher rewards when they hit the spot. Commoditised categories result in low risk projects, but the rewards are also lowered, and there's a case for saying that, where there is an overall objective of commoditisation, innovation dies.
This fits really well with my experience of embedded Linux. Linux is strong in networking. It's reasonably easy to build commodity firewall, webserver or storage appliances on Linux, and indeed many companies do just that — and with correspondingly low margins in general. Conversely, if you wanted to produce a mass-market PDA with little engineering effort, the sane course at the moment would be to licence PalmOS or WinCE. Of course (in both cases) just slapping some existing software on a box and calling it an appliance is not generally a path to riches, unless you can produce or distribute far cheaper than everyone else.
Personally I'd rather work on projects that are innovative and exciting, even if they're more risky.
A MAMMOTH RETURN. HP's recently filed U.S. federal tax return was of world-record proportion with 18,700 pages and weighed a whopping 220 pounds[...]
Primarily due to the financial and tax complications of integrating HP and Compaq, and all their various subsidiaries and instruments. On top of everything else, the two companies previously used different financial years. I'm glad that's not my job.
Michael Crawford wrote a powerful essay about his experience with schizoaffective disorder.
Even if you don't feel the need to question your reality or make a new one, I assert it is worthwhile for you to understand this in the event you ever have to, or ever need to try to help someone make a new livable world for themselves. At the very least it will help you to understand why some people are so difficult to get along with, and help you relate to them. It's not simply that some people hold different opinions, it's that many people, not just the insane, live in a completely different world from the one you experience.
There is an objective reality, but we cannot experience it directly. It is also without significance or meaning.
Mike Johnston writes on eschewing cliché.
"Rosie," taken in the dark by infrared illumination (Sony F-707), Mike Johnston
Please notice that despite the nonstop handwaving from the Mozilla team about how maintaining seperate native interfaces for the assorted Gecko frontends was supposed to be some sort of impossible herculean task that no reasonable person could be expected to tackle, in the time that it took to produce ONE semi-functional version of Mozilla, Opera Software, a company with not even a tenth of AOLNSCP's resources, produced multiple versions of a fully functional web browser, for all of Mozilla's major target platforms. Not only did they produce, maintain and upgrade native Windows, MacOS and Linux versions of Opera, but they increased their market share, and made money doing it.
"We had no choice but to implement XUL/XPFE" is the Big Lie of the entire Netscape saga. The fact that mozilla team members are still stating it with cultish earnestness suggests not that you all came to a reasoned engineering decision, but that your project management was not merely incompetant, but downright pathological. If 1% market share and the firing of your entire development team isn't enough to convince you that somewhere, somehow, you made the wrong decision, you are simply delusional.
Hopefully, some of the core Mozilla developers and managers will use some of their newly acquired free time to read Fred Brooks' "The Mythical Man-Month." When Brooks talks about the Second-System Effect, he's talking about you.
I don't know if this is really fair for Mozilla but it's certainly true in general.
Those who do not study history are condemned to repeat it.
A couple of weeks ago you mentioned Microsoft's FreedomToInnovate.com and the availability of T-Shirts. Intrigued, I had to check them out. The shirts say "Microsoft" over the front left breast and on the back is a rather uninspired logo of an American flag with the union portion of the flag replaced with a lame sub-PowerPoint-clipart-grade computer terminal graphic....
I would like to thank Bill Gates, Bruce Kratz, and anonymous Haitian slaves, for making all this possible.
Python and Glade is quite a neat little rapid development tool. In about five minutes, without using it very much before, I could write a tiny but handy GUI utility to tweak X11 monitor settings:
#!/usr/bin/env python import sys, os import pygtk pygtk.require('2.0') import gtk import gtk.glade
fname = 'gammaknob.glade' xml = gtk.glade.XML(fname)
def gtk_main_quit(*args): gtk.main_quit()
def on_gamma_scale_value_changed(gamma_scale): os.system("xgamma -gamma %f" % gamma_scale.get_value())
It still has that Linuxy loosely-coupled feeling: you can't (?) edit Python source directly inside Glade, and you have to copy in a tiny bit of boilerplate to get it going. That's not necessarily a problem; keeping it separate has some advantages.
One very cool thing is that because the user interface description is cleanly separated from the code you can run the exact same XML file with either a Python, C, or other language implementation. So a mockup in Python can directly transform into a release in C. (Although for many things just sticking with Python might be OK.)
Winter here is not so bad, but I'd really like a pair of heated handlebar grips. I can stay warm enough either thick clothing, but I hate the clumsy feel of thick gloves.
I kind of envy BMWs with bar heaters built in. (Obviously I'm getting old to even think such a thing.) I suppose they would be available as aftermarket accessories for my Kawasaki. It's probably far enough through the winter here that I won't bother for now.
I rode and went the long way in to work. Beautiful and crisp, but not too cold (12C).
Wandering further into the neoconblogsphere, we see Eugene Volokh considering whether homosexuality is "unnatural".
In Australia, I think the word "conservative" means *both* economically conservative (in favour of lightly regulated markets and low taxes) and socially conservative (in favour of maintaining traditional moral values). So I tend to be a bit bemused by people describing themselves as (say) gay and conservative. But I think the word has different nuances, or perhaps is less strict, in the US.
Two essays from Panic software, about the good old days. Or something.
I just finished reading Guns of the South (tip of the hat to JayBees for the recommendation). The gist of the book is straight forward, yet odd... what if, during the Civil War, the South became equipped with a lot of AK-47s. Long story short, they would have won.
Stephane points to a luau on Manhatten rooftops.
aj replies to my post about the intelligence issue:
The only problem here is that it's not apparent that anyone lied (ie, deliberately uttered things they knew were untrue, and that they knew would lead others to come to a conclusion that was known to be false); it's merely alleged, and mostly by people who have a stated interest in attacking Mr Howard, Mr Bush, or Mr Blair. We have a fair degree of confidence that a number of the details were wrong, but it is far from immoral to merely be mistaken. I'm wrong quite frequently, and I don't like it, but I'm not ashamed of it — saying wrong things and getting corrected is how you learn to be right.
I'm sure making decisions based on the limited intelligence that can be gained about Iraq is difficult. (Australia presumably gets a second-hand and possibly filtered feed from the US and UK.) We might still accuse somebody being more than mistaken but in fact negligent or irresponsible in not properly using the information that is available.
But the problem for Howard goes beyond that: if one is *willfully* ignorant, then ignorance is no excuse. From a recent Lateline interview:
MAXINE McKEW: How do you see this? Dishonesty, a blunder or a storm in a tea cup?
JACK WATERFORD, EDITOR IN CHIEF, CANBERRA TIMES: No, I think it's much more important than that.
But dishonesty, not directly.
I believe John Howard when he says he wasn't told, but that's in part because 20 years ago somebody told the truth to John Howard and caused him deep shock and surprise and he's taken great care not to have it told to him ever since by insulating himself with a great stack of advisers, by insisting on oral briefings and by having layer upon layer, if you like, of plausible deniability about material.
MAXINE MCKEW: Are you saying the Prime Minister's Office is constructed in such a way so that unpalatable information doesn't get to him?
JACK WATERFORD: That's pretty well it. Nobody ever gets to surprise John Howard.
If they've got bad news to deliver, it's intercepted by members of his staff and whether or not John Howard is told, no documentary evidence will ever disclose.
MAXINE MCKEW: He's surprised now. Today he said on balance it would have been better had he been told.
JACK WATERFORD: He has conceded that, but he's busily reconstructing all the while on what his case was for going into Iraq in the first place.
True? I don't know. Certainly plausible, in a Yes Minister kind of way.
That said I think I still basically agree with AJ: if the US manages to establish some kind of functioning democracy it will have been worthwhile.
I got LZO compression working for distcc in CVS last night. The compressed:plain ration for preprocessed source is typically 25%, and about on 70% on non-debug object files. In other words the amount of network traffic is cut by a factor of nearly four, since source files are typically much larger than the output.
This should help compile times when the network is a limiting factor. That is, when there are many remote machines, or the network is quite slow because it's wireless or already loaded. It might even help in other cases because the compiler can start relatively earlier, and we need to do a few less IOs and therefore less work on the kernel. The drawback is a little more work in userspace to do compression, and we can no longer use sendfile() for transmission.
Early tests indicate that for three machines on a 100Mbps network it is roughly the same speed as uncompressed traffic. It's within experimental variation, which is about 10s for a 5 minute build of Samba or the Linux kernel. The network is not saturated, so I think the extra CPU overhead of doing compression is cancelled out by the reduced network transit time.
Compression completely dominates the CPU usage of the distcc client, although it is quite small compared to preprocessing and compiling.
Note that the version in CVS is currently not compatible with earlier releases, although it will be by the time 2.9 is out.
Given all this I think it will not be on by default, because it's not compatible with older servers. It should be good to turn it on primarily if you are on a slow or high-latency network, and in particular for wireless networks.
I'm not sure what alternatives or consequences Steph has in mind were the OFLC's power to completely censor removed. At the moment all I can think of is the snuff film at the centre of 8MM and its brethren. Do we trust the general public to sensibly view those films? Where should we draw the line?
The difference seems be so obvious that it escaped Ed completely, but let me spell it out.
8mm concerns a snuff film, which is by definition made by filming an actual murder. Fairly obviously, since murder is illegal, murdering somebody to make a film ought to be illegal too, as should be profiting from selling the film, etc.
Films which depict fictional murders are not illegal. (Surely over a third of the movies showing at a major chain theatre involve some kind of fatality or violence, whether in action, drama, fantasy or other genres.) Indeed, 8mm is not illegal, because although it is about a snuff film it is not in fact a snuff film. Ed: it's done with stage blood, dummies, CGI, etc. Nobody was killed in making it. I have to say I laughed out loud that anyone could be confused about this.
Similarly, although Ken Park is concerned with various illegal or unsavory activities, it is *not* in fact a film of an actual rape. All of the actors were of appropriate age, consenting, etc etc.
I despair for my country that most Australians arguing for or against the film are trying to weigh up whether it has "enough" artistic merit or not. That should not be the point. It is a matter of free speech, which should be protected unless there is an absolutely compelling reason to be restricted. Certainly there are some such cases, but they should be the exception.
It turns out that this whole teacup-storm occurred because of a mistake by the importer: had they applied for a classification just to show the movie for a film festival as was originally intended, it would have been granted [The Law Report, Radio National]. Hysterical comparisons to a snuff film are clearly bogus, and without shrill TV interviews it's likely prurient teenagers would never have bothered to download and watch it.
The other thing that enormously irritates me is the Orwellian name of the Office of Film and Literature Classification. In fact, they do more than "classify": if they refuse to classify a film or a book then it is effectively banned. They are censors; they should honestly be restored to their original title of the Censorship Board. Then we can have a proper discussion about whether we want censors or not.
aj talks about the trouble John Howard is in for apparently fudging the evidence about Iraq before the war.
Unlike politicians, the public has the luxury of deciding after the event whether it was a good idea or not. So far the answer is a cautious "Yes", although a final answer will depend on how soon and successfully Iraq can become a stable democracy. If it falls back into a dictatorship, or becomes a quagmire that consumes thousands of coalition troops, then we might reasonably criticize Howard for not considering the risk.
Is it ethical to lie or bend the truth, to achieve a morally desirable outcome? Is it worse for democratic politicians to do this than regular people, because they are not allowing the people to make their own decision on the facts? Stop projector, discuss film.
David P. Reed makes an interesting (though debatable) point about the necessity of patents:
Date: Sun, 27 May 2001 11:24:25 -0400
From: "David P. Reed" <email@example.com>
Subject: Re: IP: Re: Software Engineering, Dijkstra, and Hippocrates: ]
Cc: Brad Cox <firstname.lastname@example.org>
Every once in a while, the "all information must be property" fringe goes over the top in absurdity. Brad Cox's latest note that you forwarded on IP blaming open source for unreliable software engineering deserves a response before it becomes "consensus reality"...feel free to post on IP if you like.
I'd love to see any references that make the case that Civil Engineering (or its "technological maturity") is grounded in intellectual property rights. Especially since the former field is much older than the latter concepts.
As a person with a long-standing and passionate avocation in exploring the history of technological systems, I have never encountered such a claim.
Since civil engineering practice predates the invention of "copyright" and "patent" laws even in their most primitive form, this claim would seem to be absurd. Bridge, cathedral, and road designs were highly mature and scientific without the benefit of "IP protection". In fact, engineers and designers built on each others' designs just fine.
As for mechanical engineers, the same holds true - Roman catapults worked pretty darn well without patent laws, for example.
Buildings did not fall down in the 15th century because we didn't have "effective intellectual property protection".
Even modern mathematics and science were developed quite effectively without "intellectual property protection" to make them "reliable" and bug-free.
I hardly think that Open Source (whatever other problems it may have as it matures) can be blamed for unreliable software because it refuses intellectual property protection.
The most obvious objection is that the rate of progress (or change) is far greater now than it was centuries ago. Most of that I dare say is due to an autocatalyzing effect: the internet speeds medical research; mass production allows more people to go to college. There is a virtuous circle. We can still enquire what started or protected the circle.
Post hoc ergo propter hoc? The fact that the C20th boom has happened in association with a patent system does not necessarily show that patents were the cause, and dpr shows they are not a necessary cause. You might equally well point to the sudden bounty of natural resources under European colonization, or to world wars, or to the American:Soviet cold war as feeding progress.
Even if we assume we live in the best of all possible worlds, we shouldn't conclude everything that has driven us here was either necessary or desirable. And we might be even more skeptical if we hope for some improvment on the world as it is.
[Remainder of software patent argument deferred.]
David Every has a little rant about software engineering as a career:
Many can't get over the stupidity, and go job to job looking for utopia; or at least the fictitious job where complete incompetence is not the norm. Those looking for where the grass is greener are usually continually amazed that things can, and do, get worse from their previous jobs. I have people from many different companies whine about how their management sucks worse than anyone else's; then someone tells them stories about places they've worked or decisions that are made, and there's silence while they process that. Four programmers around a table can quickly devolve into a game of, "my management is more stupid than yours". The sad thing about human nature is that you cannot over-estimate how low it can go. Sadder still is this is in America, one of the most effective and productive nations in the world; many foreign countries have even more bureaucracy, hierarchy and stupidity.
Tim complained about the way that Mozilla really likes to reuse the browser process already running on your screen, even when you try to start another instance. This can be troublesome if, for example, you want to run a different version of the browser, or run one from a remote machine, or su'd to a different userid. "It's just not Unixy," he said, "to open a window in an existing process when I asked it to start a new one."
(Incidentally, using the -ProfileManager option you can get a second process running. You can't run more than one on the same profile at the same time, presumably for reasons to do with locking, although I guess it could be resolved if it was commonly desired.)
Of course from the regular user's point of view, the system works pretty well: you can just invoke browsers whenever you want and the second and later windows do run faster. I seem to recall back in Netscape 4.x and earlier you had to do something tricky with netscape-remote or you got a warning about locking.
These days, now that machines are getting big and Mozilla is getting relatively fast, I wonder if it would be feasible to just run everything in separate processes.
I did imagine how this would have worked six years ago, when Mosaic used more than half the RAM on typical machines: while you're waiting ten minutes for the machine to finish thrashing, you could get a Unix guru to explain why this is a good idea.
From the LNX-BBC startup:
echo "Welcome to init!" debug "Your PID today will be $$." debug "If your travel plans today do not include PID $$, now would be a good" debug "time to disembark."
Why do modern societies work so much? Well, the answer is mostly darwinian. The people alive today are not the descendants of the happy, sane, or self-actualized people of a hundred years ago. You are the great-great-grandchild of somebody who managed to make their mangy, lice-ridden children survive to breed.
In other words, stable systems are not necessarily the ones that make their participants most happy.
It seems fairly well established that when English colonists landed in Australia, they were much less happy and health than the indigenous people they found there. But who won? For all their malnourishment and chronic disease, the British had firearms, rough discipline, and resistance to smallpox and measles.
Maciej looks at the overall good effects of food cultivation, and I certainly won't deny them. It's also good to think about the step-by-step system effects of one tribe from a continent of hunter-gatherers experimenting with food cultivation. I suggest that a few things will tend to happen:
- The individuals become less healthy, though having a less diverse diet and being more subject to famine or nutrient deficiency.
- They can possibly support more people per unit area, and therefore more people in a single tribe.
- Food production can become a specialist task, allowing people to become specialists in government or war.
- They are better able to accumulate food storage (grain silos, smoked fish, etc), and therefore to mount expeditions.
- Fixed captial assets (fields, stock, etc) biases the group towards fight rather than flight, and encourages military development.
I think these effects tend to give the tribe a long-term competitive advantage over its neighbours. In the long term, the technology-using tribes will conquer or convert their neighbours, even if that makes everyone less happy on average. People do not generally have the choice of: “would I rather be a serf, or a nomad?”. They have the experience of being pushed off the map or enslaved by an expanding cultivation society.
If it makes you happy to turn away from modern life and live in the bush for an hour or a week or a year then it's wonderful that you have the choice. Doubtless it is better for you, spiritually and physically, than to spend a day in an office.
My friend Robin enjoys extended outdoor expeditions. At the moment I think she is on a one-month canoe trip north of the Arctic circle. On a previous trip, in the far north-west of Australia, thousands of miles from a city, in one of the most remote regions of the world, somebody was hurt and had to wait as much as 24 hours to be flown to a world-class hospital. Surely they have the best of both worlds.
I have been reading bits of Food in History (Tannahill):
In Britain in the 1830s and 1840s, a worker might earn anything from 25p to £2 (62 cents to $5) a week. In 1840-41, 25p bought neither more not less than six four-pound loaves — just enough to feed a typical family of two adults and three children. It left nothing to pay the rent, nothing for tea, nothing for that little piece of bacon which was the poor man's substitute for meat.
A “good meal” meant something hot, filling, and quickly cooked — tea and boiled potatoes more often than not, since potatoes cost only about 5p or 12.5c, for twenty pounds. The man of the house might have a piece of pie or a sausafe from a cofee stall at midday, and at the weekend the whole family sat down to a Sunday dinner of broth, stew and pudding. It was a poverty-line diet, but a great man people lived on it — and a great many iede because of it.
Vaguely apropos to this, Stephane and I were driving through western Sydney today, around Eastern Creek. I have to say all the new tract housing is a little depressing in some way. That way is possible part snobiness, but also a wonder whether the sum of happiness is really increased by just having more and more people. I'd rather see growth focus on more-per-person, or even better-per-person, than over production.
John also talks about the fact that humans seem really unable to deal with long-term consequences, and environmental impact is probably the most serious of these. I wonder if (first-world) humans gained 300-year lifespans through technology they would start worrying about what the world would be like in a hundred years? I would like to think so, but I would not bet on it. On the other hand, changing technology makes it hard to imagine what life will be like in 50 years. One might semi-seriously gamble on, say, sunbathing now in the hope that there will be a cure for melanoma in a decade. Perhaps people will blithely burn fossil fuels, assuming that some solution will turn up.
Simon Tathamn, author of putty, has a great page on magic aliases in the Bourne shell. (Spoiler omitted — go and read it!)
He also has an interesting approach to coroutines in C, which is basically what librsync (amongst other programs) needs to do. The librsync handling of that is not very good at the moment if truth be told.
Ken Arnold is quoted in The Art of Unix Programming:
I insisted SIGUSR1 and SIGUSR2 be invented for BSD. People were grabbing system signals to mean what they needed them to mean for IPC, so that (for example) some programs that segfaulted would not coredump because SIGSEGV had been hijacked.
This is a general principle — people will want to hijack any tools you build, so you have to design them to either be un-hijackable or to be hijacked cleanly. Those are your only choices. Except, of course, for being ignored — a highly reliable way to remain unsullied, but less satisfying than might at first appear.
I wondered if esr's "talmudic" concept for TAOUP was a bit wanky, but it turns out to work quite well.
Greetings, Earthlings: While he's living aboard the International Space Station, Expedition Seven NASA ISS Science Officer Ed Lu is writing about his experiences.
ISS007-E-06975 (11 June 2003) --- Backdropped by the blackness of space and Earth's horizon, an unmanned Progress supply vehicle approaches the Pirs Docking Compartment (out of frame) attached to the Zvezda Service Module on the International Space Station (ISS), completing a three-day automated flight.
For my culinary friends:
The inside of the Progress is about the size of a small moving van. The difference here is that everything must be bolted down. Unlike most moving vans, this one goes from 0 to 18,000 MPH in 9 minutes. Literally, every bit of available space is filled, so to unload it you have to start near the hatch and begin unbolting things one at a time. After a few hours you have cleared enough space to actually go inside the Progress. It is like burrowing into a cave. Inside are containers of water, boxes of food, spare parts, letters from home, and of course, the fresh fruit. We haven't unloaded everything yet, but so far we have found apples, grapefruit, tomatoes and oranges.
Last night we celebrated by making space bruschetta. First, I cut up a fresh tomato. This is easier said than done in space - I put the tomato in a plastic bag and held my hand inside the bag with the knife. I managed to keep most of the tomato inside the bag. Then we added some garlic paste and olive oil, mixed well, and served it on tortillas. Delicious! This morning I had an actual real live apple with breakfast.
I just had a quick look at Objective C today.
My initial impression is that it's very nice indeed: a far more competent addition of object-oriented stuff to C than C++. It adds just enough features to do dynamic dispatch, reference counting, and so on, without going into the enormous tarpit of complexity. It seems to give just enough features: OK, you can't do static dispatch, but you rarely really need that.
I should say though that I have not even written Hello World in ObjC, and probably there are drawbacks. In particular the syntax feels a little alien to regular C, but perhaps that's a feature.
I think the only real platform where it's been used is on the NeXT, and now on OS X's Cocoa, interface, which is an evolution of the same thing. It seems like a shame that it's not more widely used -- things like GTK+ that do OO in C idioms might more easily have been done in ObjC. It says something good about NeXT that basically the same programming interface still made sense for Apple to adopt it ten years later for their new system.
I think that all right-thinking people in this country are sick and tired of being told that ordinary decent people are fed up in this country with being sick and tired. I'm certainly not. But I'm sick and tired of being told that I am.
— Monty Python
alekd reminded me of "A Petition From the Manufacturers of Candles, Tapers, Lanterns, sticks, Street Lamps, Snuffers, and Extinguishers, and from Producers of Tallow, Oil, Resin, Alcohol, and Generally of Everything Connected with Lighting." by Frédéric Bastiat (1801-1850).
We are suffering from the ruinous competition of a rival who apparently works under conditions so far superior to our own for the production of light that he is flooding the domestic market with it at an incredibly low price; for the moment he appears, our sales cease, all the consumers turn to him, and a branch of French industry whose ramifications are innumerable is all at once reduced to complete stagnation.
Eric Raymond is writing a book called The Art of Unix Programming. It is coming out in August 2003, but a late draft (?) manuscript, version 0.86, is on his web site. In everything below, bear in mind that the book is not finished yet.
Overall, it is a pretty good book. It is interesting enough and a worthwhile contribution. There are some irritating bits where esr is too insistent on his particular view of the world, but they are outweighed by parts that can be broadly appreciated.
The momentary initial impression is of hubris. However good you think you are, should you really explicitly compare yourself to Knuth? Should something "dashed off" in a couple of years compare to somebody's life work? Too late now, I suppose. Perhaps I'm too harsh: it is after all a tip of the hat, and in scope and focus on the aesthetics it is not so far away from The Art of Computer Programming.
The Practice of Programming is quite similar in content, though more oriented towards practical tips for programmers on any platform than exaltation of Unix.
The Basics of the Unix Philosophy are nicely summarized, perhaps better than has ever been done before in one place:
- Rule of Modularity: Write simple parts connected by clean interfaces.
- Rule of Clarity: Clarity is better than cleverness.
- Rule of Composition: Design programs to be connected with other programs.
- Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
- Rule of Simplicity: Design for simplicity; add complexity only where you must.
- Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
- Rule of Transparency: Design for visibility to make inspection and debugging easier.
- Rule of Robustness: Robustness is the child of transparency and simplicity.
- Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
- Rule of Least Surprise: In interface design, always do the least surprising thing.
- Rule of Silence: When a program has nothing surprising to say, it should say nothing.
- Rule of Repair: Repair what you can ? but when you must fail, fail noisily and as soon as possible.
- Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
- Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
- Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
- Rule of Diversity: Distrust all claims for one true way.
- Rule of Extensibility: Design for the future, because it will be here sooner than you think.
Another thing that bugs me is the slightly preachy tone at times. I think if a thing is good, it enough to merely describe its good features and allow audiences to draw their own conclusions. Pounding on about it will irritate your friends and alienate neutral readers. But this is largely redeemed by this epigram:
If you have any trouble sounding condescending, find a Unix user to show you how it's done.
-- Scott Adams Dilbert newsletter 3.0, 1994
for example, in discussing Windows NT Raymond doesn't discuss NT's Domain Security model, which I think is one of their most interesting design features and one to which Linux still has no complete answer. Is he unaware of it, or is it not important to him, or is he supressing it to make Unix look better?
There are however genuinely interesting ideas behind his analysis of operating systems. There is a feedback effect on ease of "casual programming", which generates a larger developer base. (c.f. the Angry Monkey Dance)
It can be hard to argue for a particular design school. Leaving aside religious/emotional attachments, aesthetics by definition make sense only mostly on their own terms. Showing that a particular design approach has produced a good outcome in a particular example makes the reader wonder if the example was accidental or specially chosen. TAOUP is at its best when it explains the Unix philosophy with examples.
TAOUP does recognize and discuss in a useful way the tension between the desirability of small programs and the existence of desirable large programs.
Discussion of the problems with OO is also good, and as clear an explanation of the problem as I can remember.
Archives 2008: Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May
Copyright (C) 1999-2007 Martin Pool.