Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

more photos

more ...

posted Tue 27 May 2003 in /personal/roc2003 | link

valgrind rocks

kcachegrind and Valgrind are just incredible: finding memory and performance problems with them is like shooting fish in a barrel. The recursive-subdivision display in kcachegrind is a minor work of art in its own right as a way of visualizing the division of the total cost of the program into smaller and smaller parts.

I think you also have to admire the audacity of Julian Seward in just writing a CPU emulator from scratch to better support debugging.

posted Tue 27 May 2003 in /software/tools/valgrind | link

Microsoft admits defeat, licenses Unix. :-)

Nice article from Bruce Perens on The Fear War against Linux.

It seems fairly clear that because SCO have given their customers an irrevocable licence to use and redistribute Linux under the GPL, they can't really sue people using it now. They might have a cause of action against anyone who copied their code, in the unlikely case that this actually occurred.

The more I think about that, the more unlikely it sounds. One of the strengths of the kernel development model is that everything that goes in is fairly extensively reviewed either by subsystem maintainers, people on mailing lists, or other developers looking at the area. Just look at the archives: anything gets in on the first try, some patches are revised over a period of months before being accepted, if at all.

If I hypothetically lifted some code from SCO and tried to put it in, surely it would be knocked back. Even if it was any good, which from my experience of SCO seems unlikely, then undoubtedly it would be written with different patterns and idioms than are common in the Linux kernel. If I submitted it, people would not only say that it was bad, but also wonder where I got it from. There'd have to be such a large rewrite that it's hard to imagine anyone would bother in the first place.

The only scenario where I *can* imagine access to proprietary Unix code being useful is in supporting an undocumented hardware interface that was known to SCO but not to the world at large. In that case, the developer would be using the code not for its own sake, but as a guide to the hardware, and you'd expect that any trade secrets being infringed would be those of the hardware manufacturer, and in any case unlikely to amount to a billion dollars. Anyhow, I doubt if SCO's hardware support is much better than Linux these days. The most interesting and most often proprietary hardware is probably graphics cards, which is hardly SCO's strong point.

It's interesting that this should come out just a little while after Microsoft admitted that their FUD strategy was not making much headway against Linux.

Everybody remember the Gandhi quote?

First they ignore you, then they laugh at you, then they fight you, then you win.

Gentlemen and ladies, this newest leaked memo from Microsoft confirms that we are advancing through GandhiCon Three.

posted Tue 20 May 2003 in /issues/sco-vs-linux | link

I hate paperwork. I have been cleaning up my big box of old bank statements, receipts, etc. It makes me grumpy.

Aside from that, a pretty good weekend.

Almost all the leaves on the deciduous trees are gone now. It's getting almost too cold to wear summer motorcycle gloves.

posted Mon 19 May 2003 in /personal | link

When good dogs go bad

Linux and Main has a well written and melancholy reflection on the history of Caldera and SCO.

Among those who know them, there are few things finer than a really good dog. And among everyone, there are few things worse than a really bad dog. When a good dog turns bad, it is a tragedy that leads invariably to the poor creature being, as they say, put to sleep.

Linux companies are like that, too. Yes, I'm talking about the SCO Group.

posted Mon 19 May 2003 in /issues/sco-vs-linux | link

programming puzzle 1

Sample problems from the DevX contest linked on Slashdot:

1. Problem 1

Problem 2

Problem 3

I did a rough solution to problem 1 in Scheme (dquads.scm). I feel like it took me a long time for the supposedly "easy" problem, though a lot of it was being unfamiliar with the tools. I still have to think a lot about how to express control structures that would come naturally in Python, Java or C. On the other hand, some of the expressions eventually turn out rather more concise than they would in those other languages.

I did a lot of these kinds of things when I was at high school for the Australian and South-East Asian Computing Competitions. It feels like a long time ago now. I think I did many of them in BASIC, which looking back seems incredibly difficult. I did some of them in C, which has the advantage of pointers and structs but really debugging pointer errors under time pressure is quite unnecessary.

One thing I notice is that its harder to put inline comments into Scheme, because (what seems to me to be) the idiomatic layout gets interrupted by fullline comments more than in C, which is basically one statement per line.

It seems that one pleasant thing about Scheme is that it's pretty easy to hoist code out into smaller functions. I suspect some of these cases would not have been easy enough to make it worthwhile in C because of the conceptual and visual overhead of passing a function pointer.

Performance is pretty reasonable, although I wrote it without much of a view to speed, and it potentially has to do a lot of calculation for the largest examples.

(use-modules (ice-9 slib))
(use-modules (srfi srfi-1))

;; "Flights" is (just) the input format.  It is a list with one
;; element for each node.  Each node gives a list of the numbers of
;; nodes that there are edges to.  Edges are directed and may be
;; duplicated.

;; This is transformed into a list of edges for internal use.  This is
;; simply a list of duples giving the from-node and to-node for each.
;; Again, there may be repeated edges.

;; A path is a list of edges, such that the to-node and from-nodes
;; connect up in order.

;; A quad is a path of length 4 that starts and ends at the same node.

;; Return a list of edges from FROM-NODE to each node in TO-LIST
(define (make-edge-list from-node to-list)
  (map (lambda (to) (list from-node to))
       to-list))

;; extract-edges FLIGHTS -> EDGES
;; Given a list of flights, return all the edges described.
(define (flights->edges flights)
  (let ((from-node 0)
	(edges '()))
    (for-each (lambda (to-list)
		(set! edges
		      (append (make-edge-list from-node to-list)
			      edges))
		(set! from-node (1+ from-node)))
	      flights)
    (reverse edges)))
		 

;; starts-from?
;;
(define (starts-from? node edge)
  (equal? (car edge) node))

;; Select from EDGES the ones starting from NODE
(define (edges-from node edges)
  (let ((f (lambda (e) (starts-from? node e))))
    (filter f edges)))

;; Return a list of paths that extend PATH by adding each of STEPS
(define (add-steps path steps)
  (map (lambda (s) (append path (list s)))
       steps))

;; Return a list of paths with all possible next steps chosen from
;; edges.
(define (next-steps path edges)
  (let* ((current-node (second (last path)))
	 (steps (edges-from current-node edges)))
    (add-steps path steps)))

;; Check if any element of L is equal to another element.  Dumb
;; O(n**2) algorithm.
(define (has-duplicates? l)
  (and (not (null? l))
       (or (member (car l) (cdr l))
	   (has-duplicates? (cdr l)))))

;; Check that the path does not revist any nodes.  Of course it is OK
;; for the last edge to go back to the start, since NODES doesn't list
;; it twice.
(define (revisit-ok? path)
  (not (has-duplicates? (path->nodes path))))

;; Return a list being the concatenation of lists built from FN
;; applied to each member of L.
(define (map-splicing fn l)
  (if (null? l)
      l
      (append (fn (car l)) (map-splicing fn (cdr l)))))
      

;; paths-starting-with FIRST EDGES
;;
;; Generate a list of all connected quads starting with FIRST and
;; continuing through EDGELIST.  Does not apply the diagonal test.
(define (quads-starting-with first edges)
  (let* ((generate-next (lambda (p) (next-steps p edges)))
	 (expand-steps (lambda (pathlist) (map-splicing generate-next pathlist)))
	 (init-pathlist (list (list first))))
    (filter revisit-ok?
	    (filter closed-path?
		    (expand-steps (expand-steps (expand-steps init-pathlist)))))))

;; make-paths EDGES -> PATHLIST
;;
;; Generate a list of all connected paths.  We try each edge as an
;; initial edge, and find all quads that start from there.
(define (make-quads edges)
  (if (< (length edges) 4)
      ;; Obviously no quads here
      '()
      (append
       ;; Find all paths starting with FIRST
       (quads-starting-with (car edges) (cdr edges))
       (make-quads (cdr edges)))))

;; Check that all the edges connect up, but not that this is a closed
;; loop.
(define (connections-ok? path)
  (or (null? (cdr path))
      (and (equal? (cadar path)		; goes to
		   (caadr path))	; comes from
	   (connections-ok? (cdr path)))))

;; Check that all the edges join up and the first one is the last
(define (closed-path? path)
  (equal? (caar path)
	  (cadr (last path))))

;; Return the nodes visited by a path
(define (path->nodes path)
  (map car path))

;; Check that there is no edge in either direction between the second
;; and third node in the path.
(define (diagonal-ok? path edges)
  (let* ((nodes (path->nodes path)))
    (not (any (lambda (x) (or (equal? x (list (first nodes) (third nodes)))
			      (equal? x (list (third nodes) (first nodes)))
			      (equal? x (list (second nodes) (fourth nodes)))
			      (equal? x (list (fourth nodes) (second nodes)))))
	       edges))))

(define (find-solutions flights)
  (let* ((edges (flights->edges flights))
	 (diag-check? (lambda (p) (diagonal-ok? p edges))))
    (filter diag-check? (make-quads edges))))

;; count-dquads FLIGHTS -> COUNT
(define (count-dquads flights)
  (length (find-solutions flights)))

I heard the idea recently that to keep developing as a programmer you ought to learn one new language every year. So I was wondering how I was doing against that:

2003

Scheme? (finally?)

2001

Python

2000

PHP

1998

Java

1997

Perl

There seem to be some gaps but maybe I was learning something else of similar complexity those years. I think I learnt a bit about the kernel in 1999 (when I should have been doing my Management subject homework. :-/).

Thinking back, it's hard to put an exact date on them, because for many of these languages there was a few false starts before being really confident. (Does that sound kind of lame for something as apparently simple as Python? Perhaps, though being really Pythonic is not quite trivial.) I suppose also the implementations improve over time and make them more welcoming: Java was terribly slow when I first used it on a ~100MHz machine, and I think Guile is only becoming friendly now.

posted Sun 18 May 2003 in /software/puzzles/devx/2003 | link

So many lies, so little time...

From a reply to Don Marti's nice article about SCO's suicidal tendencies:

1. "It's not against Linux, it's against IBM"

"We're not going after Linux"

"It only involves Linux a little bit, on the 'periphery'"

"We will protect our Intellectual Property."

"1,500 major companies have to 'cease and desist' using Linux!"

"We have suspended our sales of SCO Linux"

"There is SCO code everywhere in Linux"

McBride seems to be making it up as he goes along.

SCO in 1999:

Santa Cruz Operation added the ability to run Linux programs to its UnixWare operating system, declaring that the upstart operating system has helped UnixWare more than it has harmed it.

While Microsoft executives say Linux competes chiefly with Unix systems such as SCO's instead of Windows NT, SCO believes the opposite.

"So far as we've seen it's actually helped us," said Greg Schwarzer, director of small and medium business marketing at SCO. "Linux has got the word out that Unix on Intel is a viable alternative to Microsoft."

posted Fri 16 May 2003 in /issues/sco-vs-linux | link

Ducati M620ie Review

I had the pleasure of riding a Monster M620ie Dark at a ride day at Gecko Motorcycles on the weekend. I'm glad I did. It's so cute! I won't be buying one now, but in other circumstances I might.

People seem to perceive sensations by contrast to their present situation — think of stepping from a chilly winter day into a moderately warm room — and this is certainly true for something as visceral as a motorcycle. I can't help but think of the M620ie by contrast to my current ride, a ZX12-R, which has about three times the peak power output, and perhaps 60kg more weight. I'm sure my impressions would have been different had I gone to it from a 250cc learner bike, which is a much more likely progression.

The overall impression is of something small but exquisitely formed, perhaps like a seared slice of foie gras. The suspension is set up with standard Ducati firmness, so on chopped up back roads you do feel the bumps, though they're not jarring. The bike does track along the road with more determination and poise than one might expect from something so small. It's miles away from 250s and 400s which always seem to bounce around at 100km/h.

The engine has a good spread of torque. It's no rip-snorter but is never short of urge. The flatter torque curve characteristic of twins seems to allow a bit more laziness in gear changes than would be possible on a inline four of the same capacity. It is quiet and steady at idle, and has a nice hint of the Ducati engine sound, although far more subdued than the 998 superbike. The clutch gave a funny jelly-wobble sensation at one point, perhaps because I held it at the wrong point. Bringing it right out and then in again resolved the problem.

Amusingly enough a decal on the tank warns that the bike has a "energy saving CPU" that goes to sleep after a few minutes with the ignition on but the engine stopped. (Does anyone even do that? On most bikes it leaks current so I can't imagine anyone having the habit.)

We got up to about 130km/h on a brief stretch of the the Monaro Highway, at which speed the wind buffeting is noticeable but not objectionable. I did notice my jacket blowing around more than usual, but something about the shape of the bike avoids the feeling of being blown off one sometimes has with naked bikes.

When might I buy it? Well, if I lived in a built-up city, and had to deal with traffic and traffic lights more often than I do -- this is a weak spot of the ZX12-R, which gets hot and guzzles petrol in slow traffic, and is grumbly at less than 20km/h. At legal speeds the engine and suspension work together well, and the wind is fine. Oh, and if I didn't carry a passenger: the Ducati has a vestigial passenger pad, whereas the Kawasaki has absolute aplomb, feeling if anything more settled with two people than with one. At about AUD11k brand new it's practical transport, even more so since you're getting "that" name, sound, and aesthetic.

It probably fills this role as well as a Japanese 600cc 4-cylinder, which seems to be the default all-rounder in Australia. You're not paying for a big fairing and top-end performance you'll probably rarely use in the city.

I haven't ridden a Honda CB600 Hornet for a few years. I suppose it's the nearest competitor. From what I remember the Hornet has more of the rorty sportsbike engine feel, but less of the strong-yet-slender balance.

posted Wed 14 May 2003 in /motorbikes | link

Cebolla

Zach Brown and Adam Back did something pretty cool called Cebolla: a pragmatic IP anonymity system. When I spoke to Zer0Knowledge a couple of years ago it seemed like their system was far more complex than was really necessary: what should have been a few thousand lines (for a first version) involved kernel modules and who knows what else. This is much more like it: not solving every conceivable attack, but "pretty good anonymity".

Cebolla's threat model is pragmatic: it does not attempt to be secure against an all powerful passive attacker -- if the attacker is able to observe both the entry and exit points of traffic entering the network the game is over. However the entry node alone should not be able to determine the exit node; similarly the exit node should not be able to determine the entry-node (or user of the entry-node). This model means link padding is not used.[....]

The nested tunnel scheme described above allows Cebolla to provide end-to-end forward-anonymity. The means no single node can compromise forward-anonymity -- to compromise forward-anonymity, all nodes in the tunnel have to collude.

posted Sun 11 May 2003 in /software/crypto | link

jellyfish and duck

This weekend: ate jellyfish and duck salad, debated the existence of a universal aesthetic, decorated the Tiki Room, read Chick tracts and a history of them, and more. Very happy.

posted Sun 11 May 2003 in /personal | link

noncommercial software and resource horizons

Clay Shirky writes:

Commercial software has its limits, and it runs into them regularly. Any commercial developer has a "resource horizon" - some upper boundary of money or programmer time which limits how much can be done on any given project. Projects which lie over this horizon either can't be accomplished (very few companies could write a new operating system from scratch), or, once started, can't be completed because of their size or scope (as with the Denver Airport baggage handling system).

Open Source software has no such resource horizon - programmers creating Open Source software do it because they're interested in it, not because they're paid to do it. Furthermore, since there's no requirement to keep the source code secret, a much larger of number of programmers can work on any given project, and they don't have to work for the same company, or even live in the same country.

However, the lack of this resource horizon does not mean that Open Source software has no limits, it just means that the limits aren't financial. Commercial companies make software for money, so money is the limiting factor. Open Source developers make software for the love of the thing, so love becomes the limiting factor as well. Unloved software can't be built using Open Source methods.[....]

posted Thu 8 May 2003 in /software/opensource | link

Copyright (C) 1999-2007 Martin Pool.