weekend
Stephane made delicious white french bread and wheatbran muffins.
Beet risotto, goat cheese, and buttered hashed Brussels sprouts.
posted Mon 30 Jun 2003 in /food | link
Mezzalira revisited
Stephane and I went to Mezzalira after my earlier good experience. It was even better this time; I heartily recommend them.
What they do really well is delicious and intellectually interesting simple dishes at a moderate price (~40/head) and in a comfortable environment. It might be described as Italian/Australian/Turkish fusion, which is a combination that seems particular to Canberra.
The signature, as much as anything, is an oven hot pide bread with salt grains, rosemary and olive oil. Think of a savoury donut.
We had the tasting menu of five small courses, served with half glasses of Canberra region wine (~$70). The Lark Hill 2001 Chardonnay stood out among the wines for a unique floral/vanilla nose. Stephane got to try a Moreton Bay bug tail for the first time.
posted Fri 27 Jun 2003 in /food/restaurants/canberra | link
distcc talk at CLUG
I gave a talk about distcc last night at Canberra LUG. I was feeling a bit tired after getting up quite early but it went pretty well. Without any previous preparation we set up distcc servers on a few laptops in the audience, connected over wireless. It did work, although because wireless is a bit slow and the laptop I was using was quite fast the results were not compelling.
posted Fri 27 Jun 2003 in /projects/distcc | link
SCO will hinder open source adoption?
There are some suggestions that SCO's FUD is going to scare customers away from adopting Linux software. It's worth remembering a few facts though.
Are IBM being sued because they're using open source software? No, not at all. SCO has standing to sue because IBM signed a proprietary licensing contract with AT&T. This contract is the only grounds for legal action at the moment, and the fact that Linux is free software is purely incidental.
If IBM were as successful with OS/2 as it now is with Linux, and SCO had dug itself into the same hole, then SCO would probably be suing IBM about OS/2. If Microsoft had not paid up earlier, SCO might be suing Microsoft.
Lawsuits are hardly a new feature of the software industry. As the Economist [subscription requried] wryly notes, getting sued is perhaps just a sign that we've really arrived:
IBM denies any wrongdoing. It insists that its contract with AT&T is "irrevocable, perpetual and fully paid up", and that its customers have nothing to worry about. Whether there is any merit in SCO's claims will become clear only when the matter comes to court. But SCO is widely assumed to be gold-digging. By casting doubt on the legality of Linux, and suing a deep-pocketed company that has championed its use, SCO seems to be trying to get IBM to buy it off. That IBM has not done so suggests that it is confident of being in the clear.
[...] So far, however, SCO's lawsuit seems to have done little to harm IBM or hamper the adoption of Linux by large firms. Indeed, the attention the case is now receiving is a vivid illustration of how important Linux has become.
Proprietary licencing exposes users to at least as much legal risk as free licences. Perhaps some people prefer the devil they know, but lawyers or consultants who can explain the implications, costs and benefits of open source are not in short supply these days.
It might be nice for users if they got some kind of meaningful indemnity or warranty from their software providers. Neither open source or proprietary software vendors do this at the moment, at least at the sub-million-dollar level. But with software being such a risky business, that insurance would come at a hefty price. Indeed, given that any nontrivial program necessarily infringes on stupid software patents, it would probably be impossible.
Seth has some further thoughts on this.
posted Wed 25 Jun 2003 in /issues/sco-vs-linux | link
Resource page for SCO vs IBM (and Red Hat, and Linus, and Apple, and BSD, and Santa and little kittens)
Don Marti reminded me that the main resource page for information on SCO vs IBM and Linux is at the IWeThey project. I'm just amusing myself here but they have a pretty comprehensive list of resources.
It's a complex case, and apparently likely to take three years to resolve in court. What a waste of human effort!
posted Wed 25 Jun 2003 in /issues/sco-vs-linux | link
Rhythmbox
Rhythmbox is working really well. The interface is clean and simple and easy to use. Far less need for audio-cock ramming technology than XMMS:
Makali wrote: Whenever a programmer thinks, "Hey, skins, what a cool idea", their computer's speakers should create some sort of cock-shaped soundwave and plunge it repeatedly through their skulls.
posted Wed 25 Jun 2003 in /software/reviews | link
For Stephane
posted Wed 25 Jun 2003 in /books/taoup | link
H. RES. 153
Recognizing the public need for fasting and prayer in order to secure the blessings and protection of Providence for the people of the United States and our Armed Forces
I am not making this up.
Personally I would like to see an ammendment requiring sacrifices, just to make sure Providence does as he's told.
If you haven't read Terry Pratchett's Small Gods go and do it now.
posted Tue 24 Jun 2003 in /issues/religion | link
Bug du jour
if ((xal->name = malloc(name_len) + 1) == NULL)
out_of_memory("allocating xattrs");
My bug. C sucks. Valgrind is an automatic barrel-fish-shooter.
posted Tue 24 Jun 2003 in /software/bugs | link
Linus speaks about SCO
eweek.com has a really candid interview with Linus.
What is your position on SCO's IP claims and its allegations that code from Unix System V like its non-uniform memory access [NUMA] technologies have been incorporated into Linux?
As far as I can tell, SCO doesn't have any IP claims. Their lawsuit isn't about IP claims; it's about some contract dispute with IBM. The only IP issues they have brought up in a verifiable way has been the RCU [Read Copy Update, a way to access data structures that may be changing on multiple CPUs with less locking than normal] work that IBM did, and that SCO doesn't have any IP rights to that I can see: the patents are all IBM, and the code was written by (and thus copyrighted by) IBM too. Well, it was Sequent at the time, but they're all IBM now.
SCO alleges that you need to focus more on getting clarification as to where the code that goes in the Linux kernel comes from. Do you have any plans to change the current Linux development model?
No. I allege that SCO is full of it, and that the Linux process is already the most transparent process in the whole industry. Let's face it, nobody else even comes close to being as good at showing the evolution and source of every single line of code out there. The only party that has had serious problems clarifying what they are talking about is SCO, and now when details start emerging like with RCU, it's clearly about IP that they had nothing to do with, and don't even own. I'm sure that they are confident that they own the collective work of Unix, but that's a separate thing entirely legally from being the actual copyright owner of any specific section of code.
posted Tue 24 Jun 2003 in /issues/sco-vs-linux | link
Conversation between SCO and AIX
On a lighter note, also from slashdot
Topic in #os: hey guyz, stop pickin on irix. <SCO> w00t! i bought unix! im gonna b so rich! <novell> /msg atnt haha. idiot. <novell> whoops. was that out loud? <atnt> rotfl <ibm> lol <SCO> why r u laffin at me? <novell> dude, unix is so 10 years ago. linux is in now. <SCO> wtf? <SCO> hey guyz, i bought caldera, I have linux now. <red_hat> haha, your linux sucks. <novell> lol <atnt> lol <ibm> lol <SCO> no wayz, i will sell more linux than u! <ibm> your linux sucks, you should look at SuSE <SuSE> Ja. Wir bilden gutes Linux fuer IBM <SCO> can we do linux with you? <SuSE> Ich bin nicht sicher... <ibm> *cough* <SuSE> Gut lassen Sie uns vereinigen. * SuSE is now SuSE[UL] * SCO is now caldera[UL] <turbolinux> can we play? <conectiva> we're bored... we'll go too. <ibm> sure! * turbolinux is now turbolinux[UL] * conectiva is now conectiva[UL] <ibm> redhat: you should join! <SuSE[UL]> Ja! Wir sind vereinigtes Linux. Widerstand ist vergeblich. <red_hat> haha. no. <red_hat> lamers. <ibm> what about you debian? <debian> we'll discuss it and let you know in 5 years. <caldera[UL]> no one wants my linux! <turbolinux[UL]> i got owned. <caldera[UL]> u all tricked me. linux is lame. * caldera[UL] is now known as SCO <SCO> i'm going back to unix. <SGI> yeah! want to do unix with me? <SCO> haha. no. lamer. <novell> lol <ibm> snap! <SGI> :~( <SCO> hey, u shut up. im gonna sue u ibm. <ibm> wtf? <SCO> yea, you stole all the good stuff from unix. <red_hat> lol <SuSE[UL]> heraus laut lachen <ibm> lol <SCO> shutup. i'm gonna email all your friends and tell them you suck. <ibm> go ahead. baby. <SCO> andandand... i revoke your unix! how do you like that? <ibm> oh no, you didn't. AIX is forever. <novell> actually, we still own unix, you can't do that. <SCO> wtf? we bought it from u. <novell> whoops. our bad. <SCO> i own u. haha <SCO> ibm: give me all your AIX now! <ibm> whatever. lamer. * ibm sets mode +b SCO!*@* * SCO has been kicked from #os (own this.)
posted Mon 23 Jun 2003 in /issues/sco-vs-linux | link
Open Source Burnout
(No, not me, at the moment.)
ites writes on slashdot
"Dead" is probably a little overstated, but open source burnout is a real problem for small teams. A product that becomes popular makes great demands on one's time, and when times are hard financially, this quickly turns into a losing situation.
Maybe I'll start a counselling centre for desperate OSS programmers...
Q. I feel inadequate, I have thousands of users asking for features, but I can't deliver _and_ keep my family fed. -- Frantic, IL
Dear Frantic,
Even the best software companies take their time adding features. Don't believe everything you hear about "internet time". Good products of any kind take years to build. Relax. Take your time.Q. I'm working all my free time on project X, but no-one seems to care. Sure, my users love it, but in job interviews, it's worth nothing. -- Pissed Off, CA
Dear Off (or should I call you Pissed?),
Don't confuse art and business, and for that matter, don't mix them either. OSS is art, you do it because it makes you feel great. Only if you are a truly great artist will people appreciate your work, and you usually have to die first. Get a day job on other merits - perhaps a nice tie - and do your art when the inspiration takes you.Q. how do I make money from my OSS project? -- Destidude, NY
Dear Destidude,
Money? Did you start it for money? Nah. You started it because you thought "hey, I can do that?" Let me remind you of a basic rules of business: if you want to make money, find a group who have money to spend and make something they want. Who are you selling to? Do they have money? Right. Now stop complaining and change your CV to include "Open Source Migration Consultant".
posted Mon 23 Jun 2003 in /software/opensource | link
Linux.conf.au Call for Papers
The linux.conf.au 2004 call for papers is out. LCA is probably one of the top few technical (rather than marketing) conferences in the world, along with Ottawa Linux Symposium and Linux Kongress. It's always more fun than a barrel of penguins.
They're now calling for paper suggestions so if you've done something cool please send mail.
Next year's conference is in Adelaide in January. I'm looking forward to perhaps visiting the wineries in the Barossa afterwards.
I need to think of something to speak about. I did distcc last year, and although it's come along a bit I'm not sure it's really new. Perhaps something about Subversion?
posted Mon 23 Jun 2003 in /projects/lca2004 | link
Python secsh-filexfer
I wrote a short implementation of secsh-filexfer in Python yesterday. It worked pretty well: it can successfully connect to the sftp server in OpenSSH, and open, read and write files. It's very nice and straighforward. Doing e.g. "futures" to support pipelined operations should also work very well in Python.
I am trying to suppress the urge to write it in C. Python is far quicker to write but I have this nagging feeling that I will need to go to C eventually to win benchmarks and so I might as well do it now. But I think I can stick with Python for a bit longer.
I think this will work out pretty well as a new rsync-like transport. The protocol needs to be extended in a few ways but there are standard extension breakouts to do that.
- Create hard links
- Get file digest
- Get file block checksums
- Get/set/list extended attributes
JW suggests that we can use "reverse rsync" for downloads so that less intelligence is required on the server.
posted Mon 23 Jun 2003 in /projects/superlifter | link
BackupPC
I just saw an announcement for BackupPC, a disk-to-disk backup system that runs on top of rsync, CIFS or scp. It seems to have a friendly web interface that ought to make backups straighforward for less-technical users.
posted Mon 23 Jun 2003 in /projects/rsync | link
New York Times and Anarchy Online
The NYT just doesn't seem to be having a good time with journalistic integrity recently. [Economist registration required] Here's an extensive complaint from a prominent AO player who was profiled by them recently. I'm not sure where the truth lies but when I first read it the NYT article seemed a bit incredible.
posted Sun 22 Jun 2003 in /computers/games | link
Szechuan Tofu
- Fried triangles of tofu
- Sauce of rice wine, tamari, mustard, corn flour, water
- Stir-fried green onions, red and green capsicum
posted Sat 21 Jun 2003 in /food/recipes | link
secsh-filexfer
I've been reading about the IETF Secure Shell working group, which is basically the standardization effort for the program/protocol we now know as "ssh".
("SSH" is a trademark of "SSH Communications Security", Tatu Ylonen's company. They've granted a licence for people to have programs called ssh, but I think the standard is trying to move away from using the trademark towards "secure shell" or "secsh".)
In particular, the draft-ietf-secsh-filexfer-04 protocol draft looks like an extremely interesting solution for an rsync successor. Rather than inventing the protocol and program from scratch, it could build on secsh-filexfer and add delta-compression operations to the protocol, plus offering some programs for doing recursive/automatic transfers.
The protocol is not exactly as I would have done it, but it is remarkably close to the design that I and other people have been converging on: a pipelined sequence of reasonably simple file operations, running over a secure channel.
Another thing I recently discovered is why SSH has the "subsystem" mechanism -- at the moment the most popular is sftp, though there are others such as skermit. On Unix this maps into the server just executing an inetd-style server, so it's more or less equivalent to the client invoking ssh /usr/sbin/sftpd, much as rsync or CVS do. So why bother having a special mechanism rather than just invoking the server?
The reason is that on some systems such as Netware it is impossible to implement a shell over SSH: some systems don't have interactive shells, and others don't have the right pty or fifo mechanisms you'd need to do it properly. (Telnet on Windows has always been pretty flaky.) But if the server is invoked as an SSH subsystem, then the server can invoke it in some system-dependent way. You could for example implement sftpd as a loadable module or even a builtin on a non-Unix sshd, and it would be transparent to clients. The subsystem design basically only requires that the operating system be able to do TCP -- process models and IPC are implementation details. Very clever indeed.
posted Sat 21 Jun 2003 in /projects/superlifter | link
Who Owns UNIX?
SCO has verbally claimed to own "all the Unix rights", and has had that claim repeated by uncritical reporters. It is in fact, not true. At least one of the Unix rights, the Unix trademark itself, is still held by The Open Group.
posted Sat 21 Jun 2003 in /issues/sco-vs-linux | link
Ian Lance Taylor's visit to SCO
Linux Journal has a report from Ian Lance Taylor who signed the SCO NDA and got to hear some more details about their case, although not to actually inspect the source.
As I previously predicted, Ian thinks it all comes down to the definition of "derivative work". I don't know of any absolutely clear legal definition of this for software. As a matter of commonsense I would not think that any software built on top of Unix counts as a derivative work of Unix. In any case the later letter amending the contract seems fairly clear that IBM's new work (such as RCU, JFS, etc) remains owned by IBM.
Here, we come to the meat of the issue: has code clearly derived from Unix been incorporated into Linux? Unfortunately, SCO was willing to show me only one example. I was shown a source file Sontag said was from SVR4, which was compared to a source file from Linux. The identical portions of the code were highlighted. There were indeed substantial similarities in the code: very similar comment text, the same variable names, the same algorithm. There also were some differences, but it seemed quite plausible that both pieces of code came from the same source.
SCO refused to show me the revision history of the Unix file. I pointed out this made it impossible to judge the order of derivation; SCO agreed, and said it was a matter of discovery for the court case. SCO said it is confident the code had not appeared in BSD and was developed internally at AT&T and successors.
IBM is a past master of the IP extortion strategy. For example, see this Forbes article about IBM's shakedown of Sun in Sun's early days. For SCO to attack IBM using IP is somewhat like trying to eat a live tiger.
I'm not really in favour of bloodsports or lawsuits, but I'd pay $100 to see Darl McBridge try to eat a live tiger.
(That Forbes article is actually quite worth reading.)
posted Sat 21 Jun 2003 in /issues/sco-vs-linux | link
nmap drops SCO support
Support for SCO operating systems has been removed from nmap, the premiere network scanner.
o SCO operating systems are no longer supported due to their recent (and absurd) attacks against Linux and IBM. Bug reports relating to UnixWare will be ignored, or possibly even laughed at derisively. Note that I have no reason to believe anyone has ever used Nmap on SCO systems. Unixware sucks.
posted Sat 21 Jun 2003 in /issues/sco-vs-linux | link
Cute as...
Credit: Maciej Stachowiak
posted Fri 20 Jun 2003 in /blogs/mjs | link
Poland as LOTR setting
Credit: Maciej Stachowiak
posted Fri 20 Jun 2003 in /blogs/mjs | link
Groggy on Byte interview with Sontag
Greg wrote a good analysis of Chris Sontag's claims in the recent Byte interview.
posted Fri 20 Jun 2003 in /issues/sco-vs-linux | link
Thomas Keller interview
Interview with Thomas Keller. (Who is, for those of you less into gastronomy than others, the Chef of The French Laundry, reputed one of the best restaurants in the world.)
Where do I want you to be after you've eaten something? I want you to be thinking, "God I wish I had a little more of that." Your memory of that taste is excellent. Also, it's more healthy - in the Japanese way - to extend the meal for a longer period of time. It helps your body digest the food instead of packing your body with so much food that you're uncomfortable for hours afterward. This way, you're able to taste better and you know when you've had enough. The law of diminishing returns is the most important part of that. [...]
[O]nce in a while you might see me at In and Out Burger; they make the best fast food hamburgers around.
posted Fri 20 Jun 2003 in /food/people | link
SCO owns the World?
LWN has an excellent article about SCO's claims, and how they show that proprietary licensing is at least as "viral" and contagious as the GPL, if not more so.
Paid registration is required to read this for the next few weeks. I recommend you register. LWN has the best editorial control and commentary of any Linux news site I know.
According to some opponents of free software, users of that software are taking grave risks. The GPL, it is said, is "viral" and can cause the loss of a company's intellectual property. And free software users are exposed to the possibility that somebody, somewhere, may have incorporated tainted code, exposing users and distributors to unexpected liabilities. The solution to these problems, of course, is to simply stick with safe, licensed, proprietary software. It costs, and you sign away a lot of rights, but the warm, fuzzy feeling that comes from signing that license agreement is worth it.
Except it's increasingly clear that things are not that way. We all owe SCO a debt of gratitude for showing us how unsafe proprietary software can be. That company is using proprietary licensing to press a truly staggering set of claims over the work of others and power to disrupt organizations worldwide.[...]
SCO, it would seem, owns everything. Compared to that claim, the allegedly "viral" nature of the GPL (if you distribute something derived from a GPL-licensed product, the derived product must also be licensed under the GPL) seems weak indeed. SCO is laying claim to decades of work done by dozens of proprietary Unix vendors, and that's just the starting point.[...]
All of those AIX customers did exactly what they are supposed to do: they signed a proprietary license, paid their fees, and went off with the idea that they had bought the right to use the system on their machines. Now it appears that Unix users, at SCO's whim, can be deprived of the software upon which they have built their businesses. Proprietary Unix, it would seem, is a foundation built upon sand. Given that Microsoft felt the need to buy a Unix license from SCO, it is not clear that Windows users are in any better shape. One might assume that SCO would not try to pull the plug on Windows, but the possibility exists regardless. We look forward to the forthcoming warning from the Gartner Group.
posted Fri 20 Jun 2003 in /issues/sco-vs-linux | link
Senator Hatch Introduces Bill to Burn People's Eyes Out
From JZip:
Sen. Orrin Hatch (R-Utah) today introduced legislation authorizing the use of high-powered microwave lasers to burn out the eyes of non-paying viewers of copyrighted material. "If we could develop technology which just burned out the parts of their brains where the illegal memories are stored, that'd be fine with me--but we can burn their eyes out right now!" said Hatch, while introducing the Hatch/Hollywood Eyeball Evisceration Act.
posted Fri 20 Jun 2003 in /issues/copyright | link
Heard around Canberra
"The university that has the most rules against cheating is the one that's teeming with it."
It disgusts me to hear of the amount that goes on. Overseas students seem particularly prone to it, though I'm sure they're not the only ones. It makes a mockery of the idea of assessment or academic integrity. Does the administration not know, or not care?
posted Fri 20 Jun 2003 in /random | link
Hans Reiser interview
Slashdot has an interview with Hans Reiser
There will always be more features that I would like to implement than I can implement. Users and sponsors for the most part want good things to be added, and it is really not so bad to first implement the features that someone is willing to pay for, and hope that in a few years someone else will pay for other features. I take a 30 year perspective on the project, and I have as my final objective the elimination of reasons to not use the filesystem as the unifying namespace of the operating system. That makes for quite a lot of features that I am willing to add.;-) [....]
It is important to be true to oneself. You should maybe understand that some years ago I put the suit my mother bought me into the fireplace along with all my ties. If a restaurant requires a suit and tie, I just don't go there, it is not for the likes of me. If you need some corporately commercial justification for our website design, then let it be that I am willing to be cool and appealing to the younger generation, etc., instead of bland. If a pedagogical justification will work for you, then let me point out that military manuals with their cartoon based approach are far more effective in engaging the reader than the pedagogical techniques employed by most college textbooks. The military is more advanced in its pedagogical technique than the university system, which is really rather amusing, and I think it is due to the greater pretentiousness of universities in this matter. [...]
I predict that in 20 years version control in filesystems will be standard and expected by all users as a basic feature. [...]
This is very interesting. I have never previous thought that version control (as such) in the filesystem was a good idea. I think having some kind of backup/rollback facility as in NetApp is a good idea, and I wrote a very sketchy prototype of that years ago. But version control is so much more that just keeping backups: it implies being able to annotate and label versions, merge them intelligently and so on. The filesystem interface is just not really rich enough to do this, so you need some external support. (So Clearcase does some things through the filesystem, primarily retrieving versions, but most modifications and queries require extra commands.)
After thinking about Hans's comments, I think I would refine that to: the *Unix* filesystem interface is not rich enough to do it. If you could create copy-on-write trees, or attach annotations, or view all edits with a single operation then it might make sense. Being able to directly edit a comment on a version *as a file* without needing to then do some kind of commit operation would be great.
However, the plain-hierarchical filesystem has been remarkably resiliant (or stubborn.) Scores of commercial, academic and hobby projects have tried to replace it with some kind of content-addressible or richly structured database and few or none have been really broadly successful. Probably some large fraction of this is due to technical conservatism, but I think it's also hard to think of a new design that is really generally useful. A plain tree is adequately useful by itself, and allows you to innovate in the application space.
Hans is probably right that making the tree more efficient and flexible is a start though.
Are you sure that it wouldn't be better to hang out in cafes and bookstores for 4 years, and at the end of it write some piece of a filesystem? Cafes, bookstores, and attending random seminars will educate you better, and writing some piece of a filesystem will employ you better.
If only one could get student loans for the purpose of hanging out in cafes and bookstores for 4 years I would have been so happy....
When something becomes stable enough for you to use it yourself without it crashing, and you don't know how to make it crash, you should release it (with lots of warnings). Fortunately, there are people who like to play with technology, and they will help you find its bugs while understanding that it is still experimental code. Each order of magnitude increase in the number of users will find as many bugs as the previous order of magnitude. After some number of years, if you are kind to your users and only do new features on a new branch, the stable branch will get to where months go by and there are no bug reports at all even though there are millions of users.[...]
Linux is an ecosystem, and in this ecosystem there is fast growth vegetation and slow growth vegetation. The fast growth vegetation are the people who took what had already been done by Unix, and without changing its design they copied it while making coding improvements.
Then there are those who look at Unix, err, Linux, and see something just barely begun that needs a complete overhaul. These are the slow growth vegetation. Namesys is slow growth vegetation that got started a long time ago.
Now it is human nature that however a human being is, he is inclined to think that is the right way to be. There are those who think that design does not matter, and one should just make incremental coding improvements. There are also those who think that just coding without introducing fundamental new ideas is unimportant. Both of these sets of persons are fools. To say that one approach is better than another is like saying that grass is better than trees, or trees are better than grass. For Linux to prosper as an ecosystem it must have both.
posted Thu 19 Jun 2003 in /software/people | link
Worth waiting for
Credit: Chris Yeoh
posted Thu 19 Jun 2003 in /personal | link
nice Python Generators example
Todd links to a good example of generators in Python. You can do things like this in many languages with varying degrees of ease. In C you probably need to explicitly store all your state; in Scheme you probably need to explicitly get your head around continuations. Python is arguably the first mainstream language to add them as a first-class feature. It will be interesting to see how much people pick them up and use them. They're probably not something you want to use very often, but when you want them they're very handy.
The "level of elegance" in providing explicit generators is very typical of Python: you certainly could factor them into smaller components and write the rest as a library, but it's perhaps easier to use them in this packaging.
def genResults(db, sql):
cursor=db.cursor()
cursor.execute(sql)
while 1:
row=cursor.fetchone()
if row is None: break
yield row
posted Wed 18 Jun 2003 in /software/languages/python | link
Linux on a Compaq Evo N800w
I'm installing Red Hat Linux 7.3 on a Compaq Evo N800w. (No, it's not mine unfortunately, it's for a colleague.)
Considering that 7.3 is much older than the hardware it does pretty well. There are a couple of traps: USB doesn't work with the default 7.3 kernel, or with the kernel on the LNX-BBC 2.1 either for that matter. Booting with the kernel parameter nousb fixes that.
Also, Red Hat's Kudzu hardware detection program locks up when scanning the machine, so you need to boot single user and disable it.
Aside from that everything seems to work. The Radeon 9000 video card is partially supported in XFree86 4.2, and reportedly has better acceleration in 4.3.
The machine looks pretty nice. The screen is enormous and crisp, and probably pretty fast with the proper drivers installed. It's less heavy than some other full-featured machines like the IBM A21, in part because HP/Compaq has finally been smart enough to drop the floppy drive. (Getting a floppy drive on a new laptop in 2003 is like getting a tail on your child....)
posted Wed 18 Jun 2003 in /computers/hardware | link
Belluci's, Dickson, Canberra
We went to Belluci's restaurant in Dickson last night. They have a new and very funky internal fitout: old diner style tables, but modern wood panels and halogen/dome lights.
Unfortunately the service was very slack and the food was mediocre. 45 minutes to serve pizza and pasta is pretty ridiculous. It's kind of a shame, they used to be quite nice.
posted Tue 17 Jun 2003 in /food/restaurants/canberra | link
Redefining Professionalism for Software Engineers
posted Tue 17 Jun 2003 in /software/aesthetics | link
IBM original licence
Something purporting to be the licence agreements between AT&T and IBM is now available from the SCO web site: Exhibit A, Exhibit B.
I am not a lawyer, but it looks to me like the key question now is whether code that IBM contributed to Linux counts as a "derivative work" from the ancient Unix codebase.
One example that SCO claims to be infringing is Read-Copy-Update locking, which is apparently in products by Sequent (now owned by IBM) and now in Linux.
RCU helps scalability in enormous (>16CPU) machines, a market that SCO has never even come close to addressing. It has certainly was not in ancient SysV or SCO UNIX.
It seems to be the case that AIX is a derivative work from ancient Unix, and so AIX as a whole needs to be distributed under a compatible licence. It cannot be open sourced.
However, if IBM invents something new (RCU) and puts it into AIX, does that make RCU a derivative work of SysV? I would think not. IBM can licence their own technology in several different ways, to match the licences of the different systems it is merged into.
I suppose SCO might argue that anything which matches the Unix design is a derivative work, but that sounds incredibly broad, and would potentially give them rights to any Unix-related kernel or userspace code.
IBM is famous for having a lot of risk-averse lawyers, and in particular open source code has to be carefully vetted before release. It is hard to believe that they didn't carefully consider the Unix licence when authorizing merges of such large modules into Linux. So it's probably safe to say that IBM believed these features were not derivative works from ancient SysV.
posted Tue 17 Jun 2003 in /issues/sco-vs-linux | link
+2 funny
sco% adventWelcome to Adventure!
> threaten linux_users You get a lot of press. A group of angry penguins can be seen gathering torches in the distance.
> examine penguins None of them are actually doing anything much that would interfere with your plan.
> threaten ibm You get a lot more press.
> threaten ibm_customers You get even more press.
> examine ibm Looks like you made a mistake. More lawyers than you can shake a stick at are headed your way.
> beat ibm lawyers That is not an option.
> kill ibm lawyers Come now, don't be ridiculous.
> xyzzy That doesn't work here.
The IBM lawyers have caught up with you. Your company is bankrupt, and sharks are considering revoking their offers of professional courtesy towards your employees.
You scored 0 of 357 possible points.
posted Tue 17 Jun 2003 in /issues/sco-vs-linux | link
GNOME distcc monitor
posted Mon 16 Jun 2003 in /projects/distcc | link
Alfa Evoluta
posted Mon 16 Jun 2003 in /cars | link
Monkey Magic
Stephane bought a couple of Monkey Magic DVDs, the cult classic dubbed Japanese Buddhist myth/action/comedy show. I think any Australian kid from the 80s would remember it fondly.
It has aged really well. We enjoyed it enormously.
I had always wondered if Tripitaka was meant to be a man or a woman. It turns out that he is a boy, but played by a female actor.
posted Fri 13 Jun 2003 in /media/video | link
indolence blog
AJ has a great new blog. I've always liked his writing style.
In particular he has some nice thoughts on Blosxom.
Updating entries does seem to be a limitation of Blosxom. I think it would be nice to be able to retroactively reply to yourself and create a thread that can be updated in both directions.
Another thing that would be nice is some kind of HTML/XML sanity check on entries before they're posted, or perhaps a preview mode.
posted Fri 13 Jun 2003 in /blogs | link
Windows, A Software Engineering Odyssey
Slide set from Mark Lucovsky. I wish there was more public information on this. The problem is fairly colossal.
posted Thu 12 Jun 2003 in /software/vc | link
seanm's silent terminal project
seanm has a page about building a silent terminal. I used to have an old Sun IPC (?) in my room in Brisbane, and it was far nicer than the four (!!) fans that my current midrange PC has.
posted Thu 12 Jun 2003 in /projects/silent | link
Linux is
It's a bunch of RVs, yurts, tepees, and geodesic domes set up in a field and organized by consensus. The people who live there are making tanks. These are not old-fashioned, cast-iron Soviet tanks; these are more like the M1 tanks of the U.S. Army, made of space-age materials and jammed with sophisticated technology from one end to the other. But they are better than Army tanks. They've been modified in such a way that they never, ever break down, are light and maneuverable enough to use on ordinary streets, and use no more fuel than a subcompact car. -- Neal Stephenson, In the Beginning was the Command Line.
I know he's flattering his audience, but at least he's doing it well.
posted Thu 12 Jun 2003 in /software/linux | link
text distcc monitor
posted Wed 11 Jun 2003 in /projects/distcc | link
Bell tolling for PNG graphics format?
News.com.exe story:
"The big issue is not whether you use GIF or PNG," said Don Marti, president of the Silicon Valley Linux Users Group and Webmaster of Burn All GIFs Web site. "The big issue is whether you let a patent holder become a censor for your communications."
"A patent on communications, or on a format or a standard for communicating, is just like a stamp act," said Marti. "As soon as you decide to use a patented format to communicate, you give the patent holder a dangerous level of power over you."
Nathaniel Smith writes:
Ah, that's right, and gzip is obsolete now too! Anyone know where I can find a copy of compress?
Be sure to read to the very bottom of the article, where Unisys explains that the whole LZW mess is an example of the patent system at its finest. You see, the purpose of patents is to foster innovation, and the LZW patent fostered the creation of the technically superior PNG format. So, it's working correctly!
I am not rightly able to apprehend the confusion of ideas that could provoke such an explanation.
posted Wed 11 Jun 2003 in /issues/patents | link
Deltup for Gentoo
Wayne pointed out Deltup, a way to get delta updates for source in Gentoo. There seem to be some unsatisfactory details though.
posted Wed 11 Jun 2003 in /software/gentoo | link
Read every year
Christopher Lee (Saruman in LotR) re-reads the epic every year. I'd like to read it again.
I'd like to read TAOCP from cover to cover some day. I've read parts.
posted Wed 11 Jun 2003 in /books | link
Bungendore ride
posted Wed 11 Jun 2003 in /motorbikes/rides | link
SCO will be sued by Polish companies
It's all about the money - says Cezary Cichocki, president of CYBER Service, Polish Linux company. Together with IT ZONE he gave a notice to SCO Group to desist from unfair competitive practicies. Polish companies demanded SCO to stop propagating information about illegal code in Linux kernel without any prove, not to consent other companies not to use Linux in their solutions and to publish a declaration saying that Linux is legal in Poland.
If SCO doesn't fulfill the request of CYBER Service in 3 days, it will be sued for unfair competitive practicies. In compliance with Polish law, SCO will have to prove that Linux is illegal and before it proves it, activities of this international company are counted as illegal.
Go Poland!
posted Tue 10 Jun 2003 in /issues/sco-vs-linux | link
First look at Gentoo
I installed Gentoo in a spare partition on the weekend. It looks interesting enough that I think I'll keep it, at least for a while, though I haven't removed Debian yet.
Gentoo Linux first came to my attention because it's such a killer app for distcc. (Or is it the other way around?)
Gentoo's big difference compared to other distributions like Debian or SuSE is that it generally doesn't distribute compiled binaries -- everything is compiled from scratch. So tools like distcc and ccache that can make compiles faster are really popular there, and some of the Gentoo user/developers like Wayne Davison have sent good patches.
Gentoo is not the first distribution to work this way. SourceMage and Lunar Linux also do this. Linux From Scratch takes the idea to the logical extreme, by having no software distribution at all but merely being a detailed description of how to build an system entirely manually.
Distributions are an interesting part of the Linux phenomenon: because they package up software that's available to everybody they're almost diaphanous, and yet they really shape the user experience and people become very attached to them. I'm not really aware of this happening to the same extent on any other system: I suppose the different BSD forks as are a little similar, and perhaps the collections of free software that people put out for OS/2 and Amiga are also related. Choice of distribution is right up there with choice of editor as an emotional/religious topic.
Gentoo made me reexamine the question: what is a distribution, and what makes one good?
Installer
The first and most obvious thing a distribution does is provide some kind of installer. There is no installer program as such: rather, the Gentoo boot disc gives you a root prompt from which you can create a partition and filesystem, untar a base image, and start installing software. It's pretty straightforward, though I think it helps to have some experience with Linux to help with any snags that turn up. I couldn't really recommend it for your first Linux install unless you had a knowledgeable friend standing by.
As it happens, I'm installing Red Hat on a colleague's machine at the moment. contrast is pretty stark: the Red Hat anaconda graphic installer is very pretty and allows a default installation with just a few clicks. Gentoo requires only about the same number of interactions, but they're command invocations rather than menu choices. I did need to carefully read the Gentoo manual despite being familiar with Linux, which is certainly not the case with Red Hat.
Because everything has to be built from source the install process goes somewhat slower than copying from a CD, although it's better than I expected. In about one day I had XFree86, GNOME, emacs and Mozilla Phoenix up and running. You can start using the machine quite early in the install -- I did some work with emacs in text mode while I was waiting for X11 to build.
Ironically enough, because I only have one working machine at home at the moment I couldn't use distcc.
Visual feel
Another point of differentiation for distributions, which the installer helps to establish, is the visual feel. BSD has a charming old-school feeling; Red Hat 9 is very slick and a little corporate; Debian is kind of quirky and spills technical detail everywhere.
Gentoo feels younger somehow; more fun and yet still polished. The GDM login screen literally made me say "wow". There's heavy use of ANSI color during the install program which really helps the eye follow vast screens of visual information, at the same time as establishing something like an IRC feeling.
Gentoo makes you feel like a participant in development, rather than just a consumer.
(I'm sure some people don't want this: many people want a computer that just works and they don't want to be part of a development team. Gentoo is not for them, at least not at the moment. That's fine: there are plenty of other distributions like SuSE or Red Hat which support that very well.)
A lot of discussions about Gentoo seem to take place on web bulletin boards rather than mailing lists. I can see that this might work pretty well but it makes me feel like an old fogey. In particular labelling new posters as "n00bs" on every post seems pretty lame. If Linus got interested in Gentoo and posted to their web site would they really want him labelled that way?
Editorial control
Distributions perform a role something like an editor or publisher in gently restricting the flow of software from developers to users. As a user I don't necessarily *want* to upgrade every bit of software as soon as it is released. It's kind of nice if somebody with a similar machine can install it first and let me know if it works, or can tell me what other packages need to be upgraded to get a proper installation.
This breaks down if the restriction is too tight: Debian has in my opinion persistently had trouble getting the right balance between stability and freshness. Perhaps there is in fact no single right balance: many users or developers are interested in tracking developement releases of some particular package but they want the rest of their system to stay stable. Using binary packages with relatively tight library dependencies means that sometimes upgrading a desired package will pull others forward. Building from source allows the dependencies to be as loose as the underlying software allows.
The main form of this in Gentoo is "masking" out packages or releases that are broken, so that they won't be installed by default. But this can be easily overridden by the user, if they want to take the risk for themselves. It seems like a nice balance to me.
Gentoo ship (optionally) a fairly heavily patched 2.4.20 kernel called gentoo-sources. In particular this contains the HZ=200 and preemption patches, which are supposed to improve interactive response. I have to say that it really does seem to work: the same machine running Gentoo is noticeably snappier than running Debian with stock 2.4.20.
Of course I could install all these patches onto Debian, but it's unlikely that I would go through all the work of finding them, worrying about their stability, and keeping them up to date. I think Gentoo performs a really useful intermediary role here by selecting patches that improve their user experience.
I'm not sure how much of the improved performance is due to the patched kernel and how much to the Athlon-specific binaries. I suspect it's more of the former.
Bogosities
People make some strange arguments for source-based distributions.
One is that they are more secure, which to me seems just crazy. No end user audits all the source that they install; they trust the upstream author to have checked it appropriately. Getting packages from a binary packager introduces one more person that you have to trust, but I've never heard of somebody wilfully corrupting their packages. Perhaps the finer control of a source distribtion allows you to exclude unwanted software, but the editorial control of a good distribution balances that out. I think building from source is pretty neutral for security.
There's also an idea that rebuilding for your specific machine will make things much faster -- using Athlon-specific opcodes rather than generic x86. It's possible, but I'm not sure I buy it. 99.9% of the code on a machine is not performance-critical, and so rebuilding it is in a sense wasteful. If people really cared about this, they'd profile crucial programs and fix the algorithms in them, rather than making a source-based distribution. On the other hand, Gentoo really does seem more responsive, so perhaps I'm wrong.
I don't think these are reasons not to use it. They're just not particularly reasons to use it.
Connection with upstream
To me one of the most important things a distribution can do is help the users communicate with the upstream authors, primarily to report bugs and suggestions.
A really good thing about the emerge system is that it seems easy for people to deal directly with the software. Updating to a new upstream version of a package looks far simpler than creating a new deb -- just copy and edit the existing ebuild.
Similarly, creating a debug-enabled build of a package is a simple matter. The lack of debug symbols on Debian has been annoying.
I really liked about Debian that it was easy to report bugs and that after being filtered by the package maintainer they'd be promptly passed on to upstream. It gives a good standard way to keep track of bugs, even if the upstream author is not responsive or doesn't have a public bug list.
I'm not convinced that Bugzilla works quite as well as debbugs for this purpose. But my impression is that Gentoo doesn't want to be a filter for bug reports in the same way that Debian does. Perhaps that's good; I've certainly had experiences of Debian maintainers ignoring bug reports that both I and the upstream maintainer thought were very serious.
Futures
One thing I'd like to see is downloads of deltas for package source. This ought to work really well, since source gives much better deltas than binaries. I guess the lack of this is my own damn fault.
posted Tue 10 Jun 2003 in /software/gentoo | link
Math Thinking
Enormous index of free computer books.
posted Tue 10 Jun 2003 in /random/web | link
CIA monitoring
What is CIA?
CIA is a bot that will take email from your CVS/Subversion repositories' commit scripts, and output it to the #commits channel on freenode, and optionally to your project's IRC channel. It means you can sit in that channel and marvel in real time at all the free software being written all over the world. CIA also collects some simple statistics.
posted Fri 6 Jun 2003 in /software/tools/ciabot | link
BSD, AUUG and SCO
Greg Lehey wrote a couple of excellent balanced and well-informed pieces about SCO and Linux:
- AUUG Inc. calls on SCO to cease its destructive actions and to work toward the constructive resolution of intellectual property issues.
- DaemonNews: The Linux wars
posted Fri 6 Jun 2003 in /issues/sco-vs-linux | link
LNUX = Linux???
Dion writes:
The news stated this morning that Steve Ballmer reported the future at MSFT is uncertain. They are having trouble luring programmers away from Linux.
And the Business news casters follow this by saying Linux is up 60% already.
Even the Business idiots who cover the stock market still think LNUX = Linux.
MORONS!!!
The part of this that is most true and that makes me most happy is that Microsoft are having trouble getting programmers away from Linux. Having plenty of independent software developers (ISVs) has always been their strength, but Linux scales up better, for a few reasons. (Heh, considering the degree of lock in they have, "dependent software vendors" would be a more accurate term. :-)
Being strong in Universities gets lots of bright programmers used to working on Linux. I'm sure MS will try (even harder) to counter by getting educational discounts and partial source access out into unis, but really they can't beat free and they can't beat full access.
Getting an ego blowjob from a Microsoft recruiter at a career fair is pretty powerful, but being at uni and getting your patches accepted by Linus (or httpd-dev, or core-team, or whatever) is a greater boost.
I remember realizing when I was in final year that if they achieved their 100% marketshare goal then the only place to do interesting work would be at Microsoft. Everybody else would just be building hokey Access databases and rebooting Exchange servers; heaps of no fun. Perhaps if they could afford to hire every good programmer then this would be alright, but they just can't. There will be people left over who want to program cool stuff but can't do it on MS's terms; Linux is now the most interesting place for those people to work.
Up until a few years ago the Microsoft platform was perhaps a better bet for people who wanted to make heaps of money, but I think that too is switching the other way. With Delphi/Kylix on Linux and good web development tools there are comfortable migration paths for proprietary or in-house developers. And ISVs are (finally!) starting to realize that Microsoft is your best friend only long enough to fatten you up for the slaughter. The best outcome is you sell out: good for your pocket, but perhaps not so satisfying. The worst, and more likely, is bitterness and death as channel partners lock you out, APIs are closed off, and your product is shipped for free in Windows.
posted Fri 6 Jun 2003 in /issues/microsoft | link
Mezzalira
I went to Mezzalira last night with Luke. Very nice eggplant fritter and black mussell antipasto, and fennel&salt crusted Tasmanian salmon main.
After dinner coffee (decaffe Mokador) was really mediocre; I almost didn't drink it. I was surprised to find they're owned by the same people who run a nearby cafe that serves excellent coffee. Maybe the machine was just on the blink.
posted Fri 6 Jun 2003 in /food/restaurants/canberra | link
Burling Blog
Wow, jasonp has a blog, and lives in NY state and is married. How time flies.
posted Fri 6 Jun 2003 in /blogs | link
Techology and Courage
Ivan Sutherland on Technology and Courage.
posted Thu 5 Jun 2003 in /projects/superlifter | link
Bram's Law
The easier a piece of software is to write, the worse it's implemented in practice.
Why? Easy software projects can be done by almost any random person, so they are. It's possible to try to nudge your way into being the standard for an easy thing based on technical merit, but that's rather like trying to become a hollywood star based on talent and hard work. You're much better off trading it all in for a good dose of luck.
This is why HTTP is a mess while transaction engines are rock solid. Almost any programmer can do a mediocre but workable job of extending HTTP, (and boy, have they,) but most people can't write a transaction engine which even functions. The result is that very few transaction engines are written, almost all of them by very good programmers, and the few which aren't up to par tend to be really bad and hardly get used. HTTP, on the other hand, has all kinds of random people hacking on it, as a result of which Python has a 'fully http 1.1 compliant' http library which raises assertion failures during normal operation.
Remember this next time you're cursing some ubiquitous but awful third party library and thinking of writing a replacement. With enough coal, even a large diamond is unlikely to be the first thing picked up. Save your efforts for more difficult problems where you can make a difference. The simple problems will continue to be dealt with incompetently. It sucks, but we'll waste a lot less time if we learn to accept this fact.
Martin's Law is
If you never used software written by dickheads, your disk would be very empty indeed.
I'm tempted to turn some words of that into hyperlinks but I'll refrain. :-)
It's worth remembering that next time an arrogant or impatient author makes you feel like not using their software. Most of the alternatives are at least sometimes just as bad.
posted Thu 5 Jun 2003 in /blogs | link
inspiration
"Superlifter" is a type of spaceship in the "Culture" series of novels by Iain M Banks:
The General System Vehicle Sanctioned Parts List appeared on the screen in the Superlifter's lounge as another point of light in the starfield. It became a silver dot and grew quickly to fill the screen, though there was no sign of detail on the shining surface.
~That'll be it.
~I suppose so.
~We've probably passed near several escort craft, though they wouldn't be making their presence so obvious. What the Navy called a High Value Unit; you never send them out alone.
~ I thought it might look a little more grand.
~They always look pretty unimposing from the outside.The Superlifter plunged into the centre of the silver surface. Within it was like looking from an aircraft inside a cloud, then there was the impression of plunging through another surface, then another, then dozens more in quick succession, flicking past like thumbed paper pages in an antique book.
They burst from the last membrane into a great hazy space lit by a yellow-white line burning high above, beyond layers of wispy cloud. They were above and aft of the craft's stern. The ship was twenty-five kilometres long and ten wide. The top surface was parkland; wooded hills and ridges separated by and studded with rivers and lakes.
Bracketed by colossal ribbed and buttressed outriggers chevroned in red and blue, the GSV's sheer sides were a golden, tawny colour, scattered with a motley confusion of foliage-covered platforms and balconies and punctured by a bewildering variety of brightly lit openings, like a glowing vertical city set into sandstone cliffs three kilometres high. The air swarmed with craft of every type Quilan had ever seen or heard of, and more besides. Some were tiny, some were the size of a Superlifter. Still smaller dots were individual people, floating in the air.
Two other giant vessels, each barely an eighth of the size of the Sanctioned Parts List, shared the envelope of the GSV's surrounding field enclosure. Riding a few kilometres off each side, plainer and more dense-looking, they were surrounded with their own little concentrations of smaller flying craft.
~It is a little more impressive on the inside, isn't it?
Hadesh Hurler remained silent.
posted Wed 4 Jun 2003 in /projects/superlifter | link
TCP/SSH transport independence
I have been thinking for a long time about a new program (working title of Superlifter) that would take some of the best ideas from rsync and leave behind the historical baggage.
There are already some old and sketchy notes about it here.
rsync follows an interesting pattern in open source projects of being quasi-transport-indepdendant by running over a plain TCP socket, or some other two-way stream provided by something like OpenSSH.
(The structure of the discussion here is based on the Pattern Form.)
forces
- We want to optionally support as-fast-as-possible (wire speed?) operation with no overhead for an anonymous, typically read-only, configuration.
- We also want the option of strong cryptographic protection on authentication, encryption, and integrity.
- Some people will not want to increase the attack surface of their machine by adding new daemons listening for connections. In particular Subversion got a lot of resistance from administrators who didn't want to run apache2 mod_svn, regardless of how well written it is. Another listening process is another body of code that might possibly have bugs, that might need to be upgraded, that needs to be allowed for in firewall and intrusion-detection rules, that needs to be configured, ...
- People developing an application don't want to worry too much about security, for similar reasons: having any security functionality potentially means needing to rush out upgrades and certainly to worry a lot more about the code.
- Authentication should ideally be done over standard mechanisms. For most Linux machines, SSH is pretty standard. SSH in turn has some plugins for Kerberos, certificates, etc.
solution
Write the application so that it only relies on a bidirectional byte stream, and then put in little mechanisms so that it can connect to the server either by opening a socket directly, or by invoking the server over ssh. (From the server's point of view this looks a lot like being started by inetd.)
known uses
CVS is the earliest program that I know of to follow this pattern. It is very common to have developers access the repository over SSH, and the rest of the world access a read-only mirror using pserver. However, some security-conscious projects (OpenBSD?) allow anonymous access over SSH so that public data is not modified in transit.
rsync also uses this pattern. Both modes are popular. In particular, TCP connections are often used for anonymous mirroring. One problem with the way this is used in rsync is that the two modes behave very differently: anonymous mode uses a "modules" virtual filesystem, allows access control, etc.
distcc borrowed this idea from rsync.
Subversion has recently added this mode of operation through the svn: URL protocol, and I think this will greatly ease adoption. Previously authenticated access required Apache2 with a special mod_svn module, which encountered some resistance from administrators.
consequences
(If it it sounds like there are a lot of negative consequences then that is mostly because familiarity with this pattern has made me look more critically. It's really quite good.)
When run in SSH mode, the application is very secure without needing to include any security or crypto code of its own. As soon as the application starts running, it knows that the user has passed the system's requirements to open an SSH connection. This is not to say that the user may not still try to get up to mischief, but the program is in the second line, not the front line.
In TCP mode connections are about as fast and simple as you can get. Very standard Unix, Stevens and all that.
Server processes run under the persona of the user who started them. They should not interfere with each other; if they want to access other system resources they do so subject to normal security mechanisms.
Ordinary users can install the server and use it over their SSH connection without needing any administrative setup, assuming they are able to install programs in their own directory. They are not exposing the system to attacks in the way that they would be by listening on a port.
sshd can be configured to allow particular users to only run particular commands.
Although the code to open SSH connections is a little complex, it can be adapted (subject to licensing restrictions) from other programs. If the code can't be used, then it is straightforward to rewrite.
The default remote username is the same as the local user, which is often reasonable. It can be easily overridden.
SSH is happiest with a separate OS-level account for all users, although you could probably set it up to allow different people to use different keys to get into the same account with different limitations.
A lot of the documentation of the program has to say "see the SSH manual for details", or just replicate it. This makes the documentation easier to write, but perhaps not easier to understand.
Normally, allowing somebody to SSH in to run the server allows them to run arbitrary commands too, though it can be tied down.
It is harder, though not impossible, to put limitations on what people connected by SSH can do, because they run an arbitrary command. This is a little different to typical FTP or HTTP servers, where root can impose limits on authenticated and anonymous users alike.
There is an asymmetry between the server directly listening on a port in TCP mode, and the server being started by sshd in SSH mode. It might be nice if instead of opening the socket ourselves, there was something like in.rshd that would allow anonymous connections to run one particular program.
The application is limited to very traditional client-server TCP applications. UDP, peers connecting back to clients, and multicast can't happen (or at least can't be secured.)
The server has no control over when it is invoked, at least in SSH mode. It can't do things like preforking or server pools that are relatively straightforward when it accepts its own connections. Apache is the most famous example of this but distcc does it to from version 2.5 and apparently gains a small benefit, and also a simple way to restrict the number of incoming connections.
SSH is slightly heavy, particularly in the latency for opening connections, compared to possible other protocols. The details will depend on the application but for example distcc is about 25% slower when run over SSH in a typical environment.
Secured connections tie together several issues that might usefully be separated: authentication, assignment to a server-side OS persona, integrity of the connection, confidentiality of the connection, etc.
implementation
For a reasonably readable implementation, see the distcc source. Some particular points to note:
- The distccd server can run either standalone, or (equivalently) from inetd or sshd. This is configured by command line parameters. For friendliness the daemon tries to guess if neither --daemon or --inetd is specified. It looks like the most reliable thing is to see whether stdin is a socket or a tty. But there are plausible situations where the server just cannot tell: one might reasonably do ssh root@fatso distccd and want it to start a daemon.
The client needs to fork a child process that will run ssh with a command line ssh $host distccd --inetd.
The "near end" of ssh needs to be connected to the client program. The best way to do this on Unix is with a socketpair, which creates an anonymous unix-domain socket. This is not available on all systems, so you may have to fall back to using a pair of pipe()s. These work fine, except that they are unidirection and therefore all the client code needs to be able to cope with having separate input and output fds. (Or you could just not support systems that don't have socketpair(), but using separate fds is not so hard if you start from the beginning.)
I have no idea how you'd do this on Windows. I would start looking at Putty and see what that supports, if anything.
It's obviously useful for the user to be able to change the name of the command used to open the connection.
Because ~/.ssh/config can contain sections switched by destination host name it is less necessary to have a way for the user to append arbitrary arguments to the command line. It can be faster/more reliable to execvp() ssh directly rather than through a shell. This goes against the user being able to specify anything other than just the first word of the command. (CVS and distcc have this behaviour; rsync does not.)
The way $PATH gets set for commands invoked over ssh can be quite confusingly different to what users see interactively for many reasons. distccd is installed by default into /usr/local/bin rather than sbin to make it more likely that it can be found on the default path. This has persistently been a problem for people with rsync installed in say /opt/freeware/rsync/bin/rsync. There must be a way for the full path to the remote server to be specified on the client to fix this kind of problem.
variations
- Use the SSH "subsystem" facility. I don't know much about it.
Leave out entirely the ability for the server to listen on sockets of its own accord, and depend on something like inetd or netcat to run it and possibly to do access control. This means the server sees almost no difference between TCP and SSH connections.
In a first cut of the client, use netcat or socket to open connections.
rsync offers a weak challenge-response authentication protocol for use over TCP. This can be useful on mostly-secure networks. It does not send cleartext passwords, but file data is sent clear, and it would be vulnerable to a man-in-the-middle attack.
alternative solutions
Sun wanted GSSAPI to do something like this: NFSv4 connections can either be weakly or strongly authenticated. But it does not seem to have become very generally popular on Linux, and therefore does not really have the "no overhead" benefit of SSH.
On a platform with a well-established secure RPC like Windows it might make sense to use it. But that is possibly less efficient than plain TCP, and it certainly constrains the application.
posted Wed 4 Jun 2003 in /projects/superlifter | link
Plastic Airplanes
Phil Greenspun is getting into an expensive hobby.
posted Wed 4 Jun 2003 in /blogs | link
Joel on Fixing VC
I've thought some of Joel Spolsky's recent writings were a bit watery, but Fixing VC is cogent enough, if not really new.
posted Wed 4 Jun 2003 in /blogs | link
Blosxom Emacs Joy
Doug Alcorn had an emacs save-buffer-same-timestamp function, useful for editing Blosxom posts.
posted Wed 4 Jun 2003 in /meta/blosxom | link
Mt Molehill
John Todd Larason has a good eclectic Blosxom installation at Mt Molehill: food, furniture, science, and some adult concepts.
posted Wed 4 Jun 2003 in /blogs | link
Backdating entries in Blosxom
Blosxom stores everything in Unix files, which is a nice simple system and makes it easy to edit. The date for each entry is just taken from the file's modification time.
The only catch is that any edited entries are moved forward to the current day.
Fortunately there is a good fix for this in the GNU touch -d command, which can set the file's time to any arbitrary point in the past or future.
The other thing I did was just put this line into the Blosxom configuration, because the noisehavoc host is not in Canberra (by a long way.)
$ENV{'TZ'} = 'Australia/Canberra';
posted Wed 4 Jun 2003 in /meta/blosxom | link
Ian Lance Taylor
Good essays by Ian Lance Taylor on debugging, stock prices and atheism.
posted Tue 3 Jun 2003 in /software/aesthetics | link
first Blosxom post
This is my first Blosxom post.
posted Tue 3 Jun 2003 in /meta/blosxom | link
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.