elliotth's blog
elliotth's blog
Checked: 1 hour 17 min ago
Updated: 11 hours 16 min ago
Update every: 2 hours
Java, C++, Linux, Mac OS, programming. Something for everygeek.
Checked: 1 hour 17 min ago
Updated: 11 hours 16 min ago
Update every: 2 hours
Java, C++, Linux, Mac OS, programming. Something for everygeek.
A History of US Communications Security
elliotth's blog - Wed, 31/12/2008 - 11:00pm
I just finished reading A History of US Communications Security [pdf], the NSA's "David G Boak lectures" from 1973. (According to the introduction, the lectures were actually given in 1966. I'm also not sure whether David G Boak should be considered the lecturer, or that this is some NSA equivalent of the BBC's Reith Lectures.)
These lectures may have been given a long time ago, but this really spoke to me across the decades:
But do not lose sight of the real world where your ultimate product must be used, and beware of security features so intricate, elaborate, complex, difficult, and expensive that our customers throw up their hands and keep on communicating in the clear...
As did this:
In retrospect, the demise of the obsolescent, inefficient, and insecure systems seems natural, easy, inevitable, and relatively painless. But the fact of the matter is that it is usually quite difficult to get the users to relinquish any equipment once it is solidly entrenched in their inventories — especially if it works well [...]; but even if it doesn't [...] The reluctance to junk old systems stems from a number of causes, I think. First of all, they represent a large investment; secondly, the users have developed a supporting logistic base for the systems, have trained personnel to operate and maintain it — they've used it. Finally, the introduction of a new system is a slow and difficult business requiring new budgetary and procurement action, new training, the establishment of a new logistics base, and – increasingly these days – a costly installation job [...].
And this remains excellent advice in every field:
I suggest that newcomers to the business not jump on board whichever side of [a] controversy your viscera may first direct. Rather, take the other side – whichever it is – and go through the exercise of building its defense. You are likely to be surprised at how elaborate and involuted the arguments become either way and might lead you to my personal conclusion that the best way to achieve a net gain in our [endeavor] is through compromise.
That said, I've often found it interesting to play at being a zealot to see where it leads, as long as you're careful to eventually move on; keeping what was useful, dropping what wasn't, and having a better understanding of the limitations and trade-offs than you would if you'd never pushed the limits to find out where the limits are.
In fact, I'd be rather perturbed to find someone in their 20s who wasn't over-zealous on at least some issues relating to their profession (my assumption otherwise being that they aren't really interested in what they do). And I'm always deeply suspicious of someone older who doesn't, as a matter of course, talk in terms of trade-offs (my assumption otherwise being that they haven't really learned anything but dogma).
The description in the lectures of the US military's repeated re-discoveries of the problem of compromising emissions is interesting in contrast with the global view in Ross Anderson's book "Security Engineering", the first edition of which said:
The first appearance of compromising emanations in warfare seems to date to 1914. Field telephone wires were laid to connect the troops with their headquarters, and these often ran for miles, parallel to enemy trenches that were only a few hundred yards away. These wires used a single-core insulated cable and earth return in order to halve the weight and bulk of the cable. It was soon discovered that earth leakage caused a lot of crosstalk, including messages from the enemy side. Listening posts were quickly established and protective measures were introduced, including the use of twisted-pair cable. By 1915, valve amplifiers had extended the earth-leakage listening range to 100 yards for telephony and 300 yards for Morse code. It was found that the tangle of abandoned telegraph wire in no-man’s land provided such a good communications channel, and leaked so much traffic to the Germans, that clearing it away become a task for which lives were spent. By 1916, earth-return circuits had been abolished within 3,000 yards of the front. When the United States joined the war, the techniques were passed on.
Passed on, maybe, but seemingly not really taken on board until rediscovered by Bell Labs during WWII in relation to the specific technology of their time, and then forgotten again until the cold war, and then... you get the idea.
There's a strikingly pragmatic tone to the lectures, and a clear understanding of the effects of economics and politics on their work, in addition to engineering and scientific limitations. Refreshing to see an understanding that, at any given time, there will be some problems you cannot solve, for one reason or another, and that you shouldn't then waste undue effort in those directions because there will be other problems that you can solve. A kind of alcoholics anonymous creed for security theater addicts.
I guess they don't give these lectures any more.
Speaking of Ross Anderson, if you didn't already know, it's worth mentioning that the second edition of Security Engineering came out mid-2008. I haven't read the second edition yet, but the first edition (which you can read free online by following that last link) was a must-read. "Security Engineering" is the best book on security ever, by far. This isn't just a CS classic, it's a non-fiction classic that everyone should read. The subject matter is sufficiently important, and the coverage sufficiently fundamental and wide-ranging it should be required reading in schools. If you're too tight/broke to buy the second edition, at least promise me you'll read the first edition?
Given how sparing I usually am with praise, you should have a fair idea of just how good Ross Anderson's "Security Engineering" is.
Anyway, if you like Anderson, you'll like "A History of US Communications Security" because it gives some interesting 1970s US military specifics that go well with Anderson's much broader picture and perspective. It would probably be easier to read Anderson's "Security Engineering" first, and reading that book might awaken an interest in security engineering you didn't even know you had. It certainly did for me.
I just finished reading A History of US Communications Security [pdf], the NSA's "David G Boak lectures" from 1973. (According to the introduction, the lectures were actually given in 1966. I'm also not sure whether David G Boak should be considered the lecturer, or that this is some NSA equivalent of the BBC's Reith Lectures.)
These lectures may have been given a long time ago, but this really spoke to me across the decades:
But do not lose sight of the real world where your ultimate product must be used, and beware of security features so intricate, elaborate, complex, difficult, and expensive that our customers throw up their hands and keep on communicating in the clear...
As did this:
In retrospect, the demise of the obsolescent, inefficient, and insecure systems seems natural, easy, inevitable, and relatively painless. But the fact of the matter is that it is usually quite difficult to get the users to relinquish any equipment once it is solidly entrenched in their inventories — especially if it works well [...]; but even if it doesn't [...] The reluctance to junk old systems stems from a number of causes, I think. First of all, they represent a large investment; secondly, the users have developed a supporting logistic base for the systems, have trained personnel to operate and maintain it — they've used it. Finally, the introduction of a new system is a slow and difficult business requiring new budgetary and procurement action, new training, the establishment of a new logistics base, and – increasingly these days – a costly installation job [...].
And this remains excellent advice in every field:
I suggest that newcomers to the business not jump on board whichever side of [a] controversy your viscera may first direct. Rather, take the other side – whichever it is – and go through the exercise of building its defense. You are likely to be surprised at how elaborate and involuted the arguments become either way and might lead you to my personal conclusion that the best way to achieve a net gain in our [endeavor] is through compromise.
That said, I've often found it interesting to play at being a zealot to see where it leads, as long as you're careful to eventually move on; keeping what was useful, dropping what wasn't, and having a better understanding of the limitations and trade-offs than you would if you'd never pushed the limits to find out where the limits are.
In fact, I'd be rather perturbed to find someone in their 20s who wasn't over-zealous on at least some issues relating to their profession (my assumption otherwise being that they aren't really interested in what they do). And I'm always deeply suspicious of someone older who doesn't, as a matter of course, talk in terms of trade-offs (my assumption otherwise being that they haven't really learned anything but dogma).
The description in the lectures of the US military's repeated re-discoveries of the problem of compromising emissions is interesting in contrast with the global view in Ross Anderson's book "Security Engineering", the first edition of which said:
The first appearance of compromising emanations in warfare seems to date to 1914. Field telephone wires were laid to connect the troops with their headquarters, and these often ran for miles, parallel to enemy trenches that were only a few hundred yards away. These wires used a single-core insulated cable and earth return in order to halve the weight and bulk of the cable. It was soon discovered that earth leakage caused a lot of crosstalk, including messages from the enemy side. Listening posts were quickly established and protective measures were introduced, including the use of twisted-pair cable. By 1915, valve amplifiers had extended the earth-leakage listening range to 100 yards for telephony and 300 yards for Morse code. It was found that the tangle of abandoned telegraph wire in no-man’s land provided such a good communications channel, and leaked so much traffic to the Germans, that clearing it away become a task for which lives were spent. By 1916, earth-return circuits had been abolished within 3,000 yards of the front. When the United States joined the war, the techniques were passed on.
Passed on, maybe, but seemingly not really taken on board until rediscovered by Bell Labs during WWII in relation to the specific technology of their time, and then forgotten again until the cold war, and then... you get the idea.
There's a strikingly pragmatic tone to the lectures, and a clear understanding of the effects of economics and politics on their work, in addition to engineering and scientific limitations. Refreshing to see an understanding that, at any given time, there will be some problems you cannot solve, for one reason or another, and that you shouldn't then waste undue effort in those directions because there will be other problems that you can solve. A kind of alcoholics anonymous creed for security theater addicts.
I guess they don't give these lectures any more.
Speaking of Ross Anderson, if you didn't already know, it's worth mentioning that the second edition of Security Engineering came out mid-2008. I haven't read the second edition yet, but the first edition (which you can read free online by following that last link) was a must-read. "Security Engineering" is the best book on security ever, by far. This isn't just a CS classic, it's a non-fiction classic that everyone should read. The subject matter is sufficiently important, and the coverage sufficiently fundamental and wide-ranging it should be required reading in schools. If you're too tight/broke to buy the second edition, at least promise me you'll read the first edition?
Given how sparing I usually am with praise, you should have a fair idea of just how good Ross Anderson's "Security Engineering" is.
Anyway, if you like Anderson, you'll like "A History of US Communications Security" because it gives some interesting 1970s US military specifics that go well with Anderson's much broader picture and perspective. It would probably be easier to read Anderson's "Security Engineering" first, and reading that book might awaken an interest in security engineering you didn't even know you had. It certainly did for me.
Will stdio outlive us?
elliotth's blog - Sat, 20/12/2008 - 4:19am
I'm reading "Advanced Programming in the Unix Environment" at the moment. I'll post a review at some point, when I've finished. Right now, I've just reached chapter 5, "Standard I/O Library", and it's reminding me how much I hate stdio.
I realize it's somewhat unfair to criticize an API that's as old as I am. I think much of Unix has the advantage that it was only ever meant to provide solid primitives, and for the most part that stuff's stood the test of time well. Higher-level stuff (by the standards of the time) like C and stdio have fared significantly less well because our expectations of "high level" have changed so much. It's the continued ubiquity of this nasty turdlet that frustrates me; the fact that not only are people still using it, but that I'm still seeing people misuse it in the same ways they were misusing it 20 years ago, when I first encountered it.
getchar
This was actually where my hatred of stdio began, despite the fact that it's not stdio's fault that so much buggy getchar(3)-calling code got written. The interface is pretty sound, in a Unixy way. The mistake people make with getchar(3) is more a reflection of the environment that surrounds stdio: C.
By various accidents, I've spent most of my life programming on platforms whose char is unsigned. If you've led a more normal life, not involving ARM or PowerPC, you may not even have been aware that C's "char" type can be signed or unsigned, at the implementation's whim.
I had to learn about signed char versus unsigned char twenty years ago, learning C on an ARM-based home computer. The trouble was that the world (especially Herb "gobshite" Schildt's world) was full of code like this:
This works fine on signed-char platforms, but not on unsigned char platforms because 255 != -1. The solution is to use int instead of char, at least until you've determined that you're not dealing with EOF. (There were other hacks, but they were bad ideas, and they're the reason why, to this day, I know what character is represented by 0xff in ISO-8895-1, even though I've never seen anyone or anything deliberately use that character.)
Could stdio have fixed this? Not convincingly; taking an int* or returning a struct are the only ideas that come to mind. C might usefully have renamed "char" to "byte" and only offered an unsigned variant. For its part, stdio could usefully have deemphasized character I/O. (More on that later.)
getchar versus getc versus fgetc
A trivial thing, but even as a kid the redundancy of getchar(3)/getc(3)/fgetc(3) and their putting counterparts bothered me. I was born a minimalist. The maybe-macro versus definitely-not-macro distinction seemed particularly unconvincing and ugly. Maybe it had made more sense to offer a maybe-macro in the 1970s, I remember thinking.
But the implicit-stdin/stdout variants bothered me too. One of the things I really liked about Unix was the way it treated the console like just another kind of file (and the convention of using the filename "-" to mean the console; I remember being surprised that fopen(3) didn't return the appropriate FILE* when given that special filename, and disappointed that all programs that wanted to support the convention had to do so manually).
Encouraging people to write code that only works for stdin/stdout seemed like a mistake, even in the years before I met more sophisticated stream abstractions.
getchar versus EOF versus error
Before we leave getchar(3) and friends, it's worth remembering that it returns "EOF" both when you're at the natural end of the file and when an error occurs. This isn't necessarily a problem if you're careful with your idiom, looping until you get EOF and then check ferror(3), but people forget that second part all the time. Or they make a mess out of trying to write something fancier.
I've come to wonder if the seductive simplicity of offering a per-character interface isn't also a mistake. There are relatively few programs whose natural unit of input is the character (rather than the line or block) and in retrospect it's starting to look as if we might be better off if the most notable of those, lexical analyzers for programming languages, weren't character-based. (Treating whitespace as insignificant doesn't seem to suit humans particularly well, and definitely leads to whitespace wars.)
And what is a character, anyway? Sadly, there's precious little support for character encodings in stdio. (Though that's not a criticism of the decisions made in the 1970s so much as a criticism of the continued use of stdio.)
fread and fwrite
Like its character-based friends, fread(3) also fails to distinguish between natural ends of files and errors, with the same consequences for correctness. Relatedly, now we're dealing with more than a single byte at a time, have you ever seen a caller of fread(3)/fwrite(3) check ferror(3) and then check errno for EINTR, assuming that having read/written zero "objects" means they've read/written zero bytes? Is it possible to retry an fwrite(3) at the application level? No. At least, not if you're writing objects larger than bytes. (So if you really must use this awful API, be sure to write n "objects" each 1 byte long, rather than 1 object n bytes long.)
ungetc
It was a few years before I was sophisticated enough to be concerned that buffering wasn't a separate concern, but the ungetc(3) function bothered me from the start. The character I push back doesn't have to be the character I read? I can't push back EOF, but I can push back a character after reading EOF? I might be able to push back more than one character, but not portably, and I can't even query the pushback depth?
FILE* fp
And did it ever bother you that the "FILE* fp" parameter always comes last (which would have been annoying in and of itself)... except where it comes first? And that you just have to remember which functions are which?
fgets
Why do I have to tell fgets(3) how big the line is, before it gives it to me? How would I know? Sadly, fixed limits are a grand old Unix tradition (see also: getcwd(3)). They didn't even really give them up the second time around: if Plan 9 hadn't been so riddled with fixed-size buffers, I wouldn't have been forced to learn Perl so I could write scripts that could cope with arbitrary-sized data. At least Plan 9 had mechanisms for doing the right thing, even if they weren't widely used; compare Brdline(3) and Brdstr(3) and ask yourself why the former even exists (and why the worse function got the better name).
Even if you're happy with fixed-size buffers, the way fgets(3) leaves the trailing newline in the buffer must annoy you. Especially given the asymmetry with fputs(3), and the lack of anything like Perl's "chomp". Close your eyes and tell me that just thinking about fgets(3) doesn't bring to mind the obligatory next line that overwrites the '\n' with a '\0'! And didn't it break your C-programming heart that you had to pay for the strlen(3)? I wince even now.
This is what happens, Larry, when you don't offer improved APIs (let alone deprecate bad ones).
I know we don't use gets(3) any more, but it's a real textbook example of convenience triumphing over quality. "Let's get rid of the FILE* parameter, because we encourage that to be stdin anyway, and while we're at it, let's get rid of the buffer length — even though we've no idea how large the buffer is, or how long the line is that we're about to copy into said buffer." Surely even in the 1970s, that sounded like a bug rather than a feature.
But hey, at least gets(3) chomped the trailing newline for you.
Why can't most people even name a stdio competitor?
The final sentence of APUE's chapter 5 – "Be aware of the buffering that takes place with this library, as this is the area that generates the most problems and confusion" – is almost funny. About the only thing the "FILE*" part of stdio got convincingly right was that the arguments to fopen(3) were simpler and more memorable than open(2), and not having an equivalent of creat(2) is less confusing than having the pair. I also think fopen(3) specifically helped distance stdio from Unix modes and flags and file descriptors, which was convenient for the small non-Unix machines of the 1980s. It meant a whole generation of us grew up with stdio but without the originally underlying layer. That and stdio's ubiquity across non-Unix platforms via the standard C library left stdio unassailable.
The immortal printf(3) family probably helped stdio too, but I'm not complaining about them. There's a (good) reason why they get emulated in every language's library, sooner or later. Some languages' versions even address most of the problems of the originals, while retaining the advantages.
I'm reading "Advanced Programming in the Unix Environment" at the moment. I'll post a review at some point, when I've finished. Right now, I've just reached chapter 5, "Standard I/O Library", and it's reminding me how much I hate stdio.
I realize it's somewhat unfair to criticize an API that's as old as I am. I think much of Unix has the advantage that it was only ever meant to provide solid primitives, and for the most part that stuff's stood the test of time well. Higher-level stuff (by the standards of the time) like C and stdio have fared significantly less well because our expectations of "high level" have changed so much. It's the continued ubiquity of this nasty turdlet that frustrates me; the fact that not only are people still using it, but that I'm still seeing people misuse it in the same ways they were misusing it 20 years ago, when I first encountered it.
getchar
This was actually where my hatred of stdio began, despite the fact that it's not stdio's fault that so much buggy getchar(3)-calling code got written. The interface is pretty sound, in a Unixy way. The mistake people make with getchar(3) is more a reflection of the environment that surrounds stdio: C.
By various accidents, I've spent most of my life programming on platforms whose char is unsigned. If you've led a more normal life, not involving ARM or PowerPC, you may not even have been aware that C's "char" type can be signed or unsigned, at the implementation's whim.
I had to learn about signed char versus unsigned char twenty years ago, learning C on an ARM-based home computer. The trouble was that the world (especially Herb "gobshite" Schildt's world) was full of code like this:
char ch;
while ((ch = getchar()) != EOF) { // BROKEN!
// ...
}
This works fine on signed-char platforms, but not on unsigned char platforms because 255 != -1. The solution is to use int instead of char, at least until you've determined that you're not dealing with EOF. (There were other hacks, but they were bad ideas, and they're the reason why, to this day, I know what character is represented by 0xff in ISO-8895-1, even though I've never seen anyone or anything deliberately use that character.)
Could stdio have fixed this? Not convincingly; taking an int* or returning a struct are the only ideas that come to mind. C might usefully have renamed "char" to "byte" and only offered an unsigned variant. For its part, stdio could usefully have deemphasized character I/O. (More on that later.)
getchar versus getc versus fgetc
A trivial thing, but even as a kid the redundancy of getchar(3)/getc(3)/fgetc(3) and their putting counterparts bothered me. I was born a minimalist. The maybe-macro versus definitely-not-macro distinction seemed particularly unconvincing and ugly. Maybe it had made more sense to offer a maybe-macro in the 1970s, I remember thinking.
But the implicit-stdin/stdout variants bothered me too. One of the things I really liked about Unix was the way it treated the console like just another kind of file (and the convention of using the filename "-" to mean the console; I remember being surprised that fopen(3) didn't return the appropriate FILE* when given that special filename, and disappointed that all programs that wanted to support the convention had to do so manually).
Encouraging people to write code that only works for stdin/stdout seemed like a mistake, even in the years before I met more sophisticated stream abstractions.
getchar versus EOF versus error
Before we leave getchar(3) and friends, it's worth remembering that it returns "EOF" both when you're at the natural end of the file and when an error occurs. This isn't necessarily a problem if you're careful with your idiom, looping until you get EOF and then check ferror(3), but people forget that second part all the time. Or they make a mess out of trying to write something fancier.
I've come to wonder if the seductive simplicity of offering a per-character interface isn't also a mistake. There are relatively few programs whose natural unit of input is the character (rather than the line or block) and in retrospect it's starting to look as if we might be better off if the most notable of those, lexical analyzers for programming languages, weren't character-based. (Treating whitespace as insignificant doesn't seem to suit humans particularly well, and definitely leads to whitespace wars.)
And what is a character, anyway? Sadly, there's precious little support for character encodings in stdio. (Though that's not a criticism of the decisions made in the 1970s so much as a criticism of the continued use of stdio.)
fread and fwrite
Like its character-based friends, fread(3) also fails to distinguish between natural ends of files and errors, with the same consequences for correctness. Relatedly, now we're dealing with more than a single byte at a time, have you ever seen a caller of fread(3)/fwrite(3) check ferror(3) and then check errno for EINTR, assuming that having read/written zero "objects" means they've read/written zero bytes? Is it possible to retry an fwrite(3) at the application level? No. At least, not if you're writing objects larger than bytes. (So if you really must use this awful API, be sure to write n "objects" each 1 byte long, rather than 1 object n bytes long.)
ungetc
It was a few years before I was sophisticated enough to be concerned that buffering wasn't a separate concern, but the ungetc(3) function bothered me from the start. The character I push back doesn't have to be the character I read? I can't push back EOF, but I can push back a character after reading EOF? I might be able to push back more than one character, but not portably, and I can't even query the pushback depth?
FILE* fp
And did it ever bother you that the "FILE* fp" parameter always comes last (which would have been annoying in and of itself)... except where it comes first? And that you just have to remember which functions are which?
fgets
Why do I have to tell fgets(3) how big the line is, before it gives it to me? How would I know? Sadly, fixed limits are a grand old Unix tradition (see also: getcwd(3)). They didn't even really give them up the second time around: if Plan 9 hadn't been so riddled with fixed-size buffers, I wouldn't have been forced to learn Perl so I could write scripts that could cope with arbitrary-sized data. At least Plan 9 had mechanisms for doing the right thing, even if they weren't widely used; compare Brdline(3) and Brdstr(3) and ask yourself why the former even exists (and why the worse function got the better name).
Even if you're happy with fixed-size buffers, the way fgets(3) leaves the trailing newline in the buffer must annoy you. Especially given the asymmetry with fputs(3), and the lack of anything like Perl's "chomp". Close your eyes and tell me that just thinking about fgets(3) doesn't bring to mind the obligatory next line that overwrites the '\n' with a '\0'! And didn't it break your C-programming heart that you had to pay for the strlen(3)? I wince even now.
This is what happens, Larry, when you don't offer improved APIs (let alone deprecate bad ones).
I know we don't use gets(3) any more, but it's a real textbook example of convenience triumphing over quality. "Let's get rid of the FILE* parameter, because we encourage that to be stdin anyway, and while we're at it, let's get rid of the buffer length — even though we've no idea how large the buffer is, or how long the line is that we're about to copy into said buffer." Surely even in the 1970s, that sounded like a bug rather than a feature.
But hey, at least gets(3) chomped the trailing newline for you.
Why can't most people even name a stdio competitor?
The final sentence of APUE's chapter 5 – "Be aware of the buffering that takes place with this library, as this is the area that generates the most problems and confusion" – is almost funny. About the only thing the "FILE*" part of stdio got convincingly right was that the arguments to fopen(3) were simpler and more memorable than open(2), and not having an equivalent of creat(2) is less confusing than having the pair. I also think fopen(3) specifically helped distance stdio from Unix modes and flags and file descriptors, which was convenient for the small non-Unix machines of the 1980s. It meant a whole generation of us grew up with stdio but without the originally underlying layer. That and stdio's ubiquity across non-Unix platforms via the standard C library left stdio unassailable.
The immortal printf(3) family probably helped stdio too, but I'm not complaining about them. There's a (good) reason why they get emulated in every language's library, sooner or later. Some languages' versions even address most of the problems of the originals, while retaining the advantages.
Python-enabled gdb(1)
elliotth's blog - Sat, 13/12/2008 - 8:25pm
I'm not a gdb(1) master myself, and usually only turn to it as a last resort, but I've used it enough to know that it's pretty limited, and that trying to extend it with "canned sequences of commands" was about as pleasant as working with make(1).
Tom Tromey's been blogging recently about forthcoming Python support. So instead of GDB's old joke of "canned sequences of commands" (at least they had the decency not to claim it was anything more than it was), you can now use Python. I haven't used it, but it seems impressive, and a huge leap forward.
Here's a handy table of contents if you're interested:
It's a shame to see the new features are Python-only. (But at least they're not Guile-only. Does anyone else remember when that was the "official" GNU scripting language? It's rare to see insanity that pure in public.)
I realize that supporting arbitrary languages is a non-trivial problem, but I'd love to see the Free world at least making an effort to solve this problem. Too often we see Python-only or Ruby-only or C-only or Java-only, where a useful aspect of genuine freedom would be "freedom to use whatever language you/your team are most comfortable with". I feel like applications are being used as battlegrounds to wage inter-language wars. Don't get me wrong: just because I'd rather use Ruby right now doesn't mean I won't need to use Python next year, or that I want to stop you using Java in the meantime.
Putting an end to this form of linguistic lock-in would be a huge leap forward for Free software, not just for GDB.
In the meantime, at the cost of learning Python, it looks like advanced GDB users just got a lot of interesting new opportunities.
I'm not a gdb(1) master myself, and usually only turn to it as a last resort, but I've used it enough to know that it's pretty limited, and that trying to extend it with "canned sequences of commands" was about as pleasant as working with make(1).
Tom Tromey's been blogging recently about forthcoming Python support. So instead of GDB's old joke of "canned sequences of commands" (at least they had the decency not to claim it was anything more than it was), you can now use Python. I haven't used it, but it seems impressive, and a huge leap forward.
Here's a handy table of contents if you're interested:
- 1. Installing a Python-enabled debugger
- 2. Writing a new gdb command
- 3. gdb convenience functions
- 4. Parameters, and extending require
- 5. The filtering backtrace
- 6. Auto-loading Python code
- 7. Pretty printing, part 1
- 8. Pretty printing, part 2
- 9. Scripting gdb
- 10. Wacky stuff
- 11. The End
It's a shame to see the new features are Python-only. (But at least they're not Guile-only. Does anyone else remember when that was the "official" GNU scripting language? It's rare to see insanity that pure in public.)
I realize that supporting arbitrary languages is a non-trivial problem, but I'd love to see the Free world at least making an effort to solve this problem. Too often we see Python-only or Ruby-only or C-only or Java-only, where a useful aspect of genuine freedom would be "freedom to use whatever language you/your team are most comfortable with". I feel like applications are being used as battlegrounds to wage inter-language wars. Don't get me wrong: just because I'd rather use Ruby right now doesn't mean I won't need to use Python next year, or that I want to stop you using Java in the meantime.
Putting an end to this form of linguistic lock-in would be a huge leap forward for Free software, not just for GDB.
In the meantime, at the cost of learning Python, it looks like advanced GDB users just got a lot of interesting new opportunities.
"New" Xbox Experience
elliotth's blog - Fri, 28/11/2008 - 11:32pm
Microsoft pushed out a major software update to the Xbox 360 recently. The "New Xbox Experience" (NXE). Basically a new UI, but some added functionality too.
The main new piece of added functionality from my point of view is access to streamed Netflix movies. This would be sweet, except Microsoft expect you to not only have a Netflix subscription but also to have a paid Xbox Live subscription. Thanks, Ballmer, but no thanks. I bought a 360, and I'm already a Netflix subscriber, and I honestly don't see why I owe you anything. Especially since you won't even let me watch crap off youtube on the 360. As far as I can tell, you want me to find some other way to watch video. Fine by me.
The most noticeable change is the new UI. Neither I nor the missus like it. We both admit that it's mainly because we were familiar with the old UI, see no advantages to the new UI, and both wish we didn't have to relearn shit just because Microsoft arbitrarily moved stuff around. We'd already learned to cope with the old UI, and the transition cost seems pretty high for no discernible gain. Personally, I've given up and reverted to the subset of the old UI that's still available via the guide button.
If you've been streaming mp3s to your 360, you'll be disappointed to find that the NXE is every bit as shit as the old experience. There's no caching of the album/artist/song lists, and it's every bit as slow at building the menus, so if you've got a music collection large enough to be worth streaming, you'll still find yourself spending too much time staring at the "please wait" screen. (Which they did waste time updating, of course.)
Tracks within an album are still "helpfully" sorted into alphabetical order, and there still doesn't seem to be any way to get the proper order, so if you were planning on listening to classical music, or anything where one track leads into another, you're still screwed.
And there's still no on-screen keyboard for iTunes-like filtering. Yeah, I know an on-screen keyboard would suck, but it would suck a lot less hard than One Big List. Seriously, dudes, you can't navigate a multi-thousand item list. Not even if it is sorted alphabetically. Given that the best^wbiggest speakers in the house are connected to the 360, I would probably splash out on the little keypad if I thought I could use it to get a sensible interface. Hell, the damn remote, which I did buy, went from dildo proportions with the original Xbox to full-on police baton proportions with the 360. I use about 13 buttons (play, pause, eject, left/right/up/down, OK, info, a/b/x/y) of the 46 buttons on that thing. By my reckoning, those Redmond bastards could have fitted every letter of my alphabet on the remote and still had room to throw in a few accents to keep the French Canadians sweet.
(The 360's "visualizations", by the way, are an interesting contrast with Apple's iTunes ones. Microsoft has some nice variations on the usual themes, their "water-splashed inky line" one being my personal favorite until it starts spinning, but overall their intent seems much harsher. There's a distinct "bad trip" vibe to some of them. I especially hate the Melting Charred Lizard Corpse and the Spinning Klingon Blade Thing and the Big Staring Eye and I'm not even going to mention the Journey Up The Brown Canyon because it scares the poop out of me. What were they thinking? And where was the adult supervision they so desperately needed?)
But the most obnoxious new feature is their crappy avatars. They're more serious than the Wii's, and less creepy-zombie-pseudo-realistic than the PS3's, but they make no sense. Why do I need to create a bloody avatar when I'm about to play a game? A game where my appearance is chosen for me anyway? (And, no, I don't think Halo 3 would be improved if Master Chief were replaced by a little cartoon white guy in glasses and the nerdiest clothes available. I think this is a rip-off of functionality that made some sense on the Wii but makes no sense in its new home.)
While I found creating an avatar a pointless chore, the missus was quite keen. She likes that kind of thing in RPGs. The NXE was a disappointment to her, though, because the choices were so limited. None of the faces look anything like her. None of the clothing looks like anything she'd wear. It's bad enough if you're male and don't dress like some generic TV "cool teenager", but if you're female you might be surprised to find that there's neither a single skirt nor a single dress to choose from, and you don't have control over the clothing's coloring. If you like a design but don't like the colors, well, screw you. Oh, and if you're female, you might assume you get some control over your avatar's body type, but you don't. You get the body of an androgynous teenage boy, which you can make skinny or fat, tall or short, but that's it. If you were planning on any curves that wouldn't look out of place on an androgynous teenage boy, we regret to inform you that won't be possible.
Doubtless you'll be able to purchase all this crap at some point, which only reinforces my personal feeling of "you bastards!".
My original intention was to be a small white ball of healing light (and, thanks to Guilty Spark, I didn't consider this an unrealistic intention). Unfortunately, Microsoft seems to think that Xbox gamers (a) are humanoid – a not unreasonable assumption – and (b) wouldn't look out of place strolling the catwalk at Milan fashion week — which sounds like more of a stretch.
Why am I bothering to mention the NXE at all? Because I think it's interesting in relation to Chen's "The Old New Thing". This, I think, is a glimpse of what Microsoft would be like if their customers weren't corporations. This is what Microsoft is like when their customers will accept any necessary shit just to play their DVDs/games.
Those who wish Microsoft weren't so tied up with backwards compatibility might want to be more careful about what they wish for, in case it should ever come to pass.
Microsoft pushed out a major software update to the Xbox 360 recently. The "New Xbox Experience" (NXE). Basically a new UI, but some added functionality too.
The main new piece of added functionality from my point of view is access to streamed Netflix movies. This would be sweet, except Microsoft expect you to not only have a Netflix subscription but also to have a paid Xbox Live subscription. Thanks, Ballmer, but no thanks. I bought a 360, and I'm already a Netflix subscriber, and I honestly don't see why I owe you anything. Especially since you won't even let me watch crap off youtube on the 360. As far as I can tell, you want me to find some other way to watch video. Fine by me.
The most noticeable change is the new UI. Neither I nor the missus like it. We both admit that it's mainly because we were familiar with the old UI, see no advantages to the new UI, and both wish we didn't have to relearn shit just because Microsoft arbitrarily moved stuff around. We'd already learned to cope with the old UI, and the transition cost seems pretty high for no discernible gain. Personally, I've given up and reverted to the subset of the old UI that's still available via the guide button.
If you've been streaming mp3s to your 360, you'll be disappointed to find that the NXE is every bit as shit as the old experience. There's no caching of the album/artist/song lists, and it's every bit as slow at building the menus, so if you've got a music collection large enough to be worth streaming, you'll still find yourself spending too much time staring at the "please wait" screen. (Which they did waste time updating, of course.)
Tracks within an album are still "helpfully" sorted into alphabetical order, and there still doesn't seem to be any way to get the proper order, so if you were planning on listening to classical music, or anything where one track leads into another, you're still screwed.
And there's still no on-screen keyboard for iTunes-like filtering. Yeah, I know an on-screen keyboard would suck, but it would suck a lot less hard than One Big List. Seriously, dudes, you can't navigate a multi-thousand item list. Not even if it is sorted alphabetically. Given that the best^wbiggest speakers in the house are connected to the 360, I would probably splash out on the little keypad if I thought I could use it to get a sensible interface. Hell, the damn remote, which I did buy, went from dildo proportions with the original Xbox to full-on police baton proportions with the 360. I use about 13 buttons (play, pause, eject, left/right/up/down, OK, info, a/b/x/y) of the 46 buttons on that thing. By my reckoning, those Redmond bastards could have fitted every letter of my alphabet on the remote and still had room to throw in a few accents to keep the French Canadians sweet.
(The 360's "visualizations", by the way, are an interesting contrast with Apple's iTunes ones. Microsoft has some nice variations on the usual themes, their "water-splashed inky line" one being my personal favorite until it starts spinning, but overall their intent seems much harsher. There's a distinct "bad trip" vibe to some of them. I especially hate the Melting Charred Lizard Corpse and the Spinning Klingon Blade Thing and the Big Staring Eye and I'm not even going to mention the Journey Up The Brown Canyon because it scares the poop out of me. What were they thinking? And where was the adult supervision they so desperately needed?)
But the most obnoxious new feature is their crappy avatars. They're more serious than the Wii's, and less creepy-zombie-pseudo-realistic than the PS3's, but they make no sense. Why do I need to create a bloody avatar when I'm about to play a game? A game where my appearance is chosen for me anyway? (And, no, I don't think Halo 3 would be improved if Master Chief were replaced by a little cartoon white guy in glasses and the nerdiest clothes available. I think this is a rip-off of functionality that made some sense on the Wii but makes no sense in its new home.)
While I found creating an avatar a pointless chore, the missus was quite keen. She likes that kind of thing in RPGs. The NXE was a disappointment to her, though, because the choices were so limited. None of the faces look anything like her. None of the clothing looks like anything she'd wear. It's bad enough if you're male and don't dress like some generic TV "cool teenager", but if you're female you might be surprised to find that there's neither a single skirt nor a single dress to choose from, and you don't have control over the clothing's coloring. If you like a design but don't like the colors, well, screw you. Oh, and if you're female, you might assume you get some control over your avatar's body type, but you don't. You get the body of an androgynous teenage boy, which you can make skinny or fat, tall or short, but that's it. If you were planning on any curves that wouldn't look out of place on an androgynous teenage boy, we regret to inform you that won't be possible.
Doubtless you'll be able to purchase all this crap at some point, which only reinforces my personal feeling of "you bastards!".
My original intention was to be a small white ball of healing light (and, thanks to Guilty Spark, I didn't consider this an unrealistic intention). Unfortunately, Microsoft seems to think that Xbox gamers (a) are humanoid – a not unreasonable assumption – and (b) wouldn't look out of place strolling the catwalk at Milan fashion week — which sounds like more of a stretch.
Why am I bothering to mention the NXE at all? Because I think it's interesting in relation to Chen's "The Old New Thing". This, I think, is a glimpse of what Microsoft would be like if their customers weren't corporations. This is what Microsoft is like when their customers will accept any necessary shit just to play their DVDs/games.
Those who wish Microsoft weren't so tied up with backwards compatibility might want to be more careful about what they wish for, in case it should ever come to pass.
tail -F
elliotth's blog - Thu, 27/11/2008 - 5:11pm
I've been a fan of Unix since I was a little kid with no access to Unix. I'd read books about Unix, borrowed from the "big city" library I'd sometimes get to visit as a treat.
I've used many Unixes since, mainly Linux these days, but I'm old enough to have grown up on commercial Unixes and Plan 9. And although for years now I've found it unbearably frustrating to be stuck on a system that uses some non-GNU variants of commands (Mac OS, mainly, but I sometimes run into undead Solaris zombies), I'll be honest: this GNU stuff is still new to me.
Unlike many of my peers, it wasn't all the fancy extra options that drew me to GNU userspace; it was the absence of fixed-sized buffers. Those old Bell Labs guys loved their fixed-size buffers, and it was a constant pain in my ass that accidentally pushed me into using Perl: I just couldn't trust pre-GNU awk(1) or sed(1) or whatever to cope with "long" lines. (And don't imagine they'd cope gracefully, either. I'm talking buffer overflows, because who could possibly have a line longer than, say, 512 characters?)
One side effect of my non-conversion is that I'm generally ignorant of GNU extensions.
POSIX tail(1) has a -f option ('f' for 'follow') that does its usual job of showing you the last few lines of the file, but then keeps running so it can show you all new content appended to the file. This, as you probably know, is really useful, especially for log files.
My problem is that I keep restarting a program that creates a new log file each time it runs, with the timestamp encoded in the filename. It helpfully creates a symbolic link to the most recent log file, but traditional tail -f opens a file descriptor and, to implement the -f part of its functionality, keeps calling fstat(2) to see if the file pointed to by the file descriptor has changed size, and if it has, it copies the new content to stdout. This, obviously, doesn't work in my case, because I care if the symbolic link changes too, and want to start following the new file.
I finally got sick of "interrupt, up-arrow, return" yesterday, and was about to write a simple script when I realized I should check GNU tail doesn't already have such functionality. And, of course, it does: tail -F. This re-opens the original path if the fstat(2) shows that the file is a different file (recognizable by an inode or device number change).
Why are both useful? Well, you want tail -f if your path might be renamed or unlinked but you still want to read it (remember that an unlinked file continues to exist as long as some process has an open file descriptor for it). And you want tail -F if your path might be renamed or unlinked or replaced by a different symbolic link and you want to switch to reading whatever file (if any) comes along to replace it.
Personally, I think I'm going to start retraining my fingers to use -F because I think that's my more usual use case. YMMV. And apologies to the youngsters who already knew all this, but I'm pretty sure I'm not the only dinosaur still wandering the earth.
I've been a fan of Unix since I was a little kid with no access to Unix. I'd read books about Unix, borrowed from the "big city" library I'd sometimes get to visit as a treat.
I've used many Unixes since, mainly Linux these days, but I'm old enough to have grown up on commercial Unixes and Plan 9. And although for years now I've found it unbearably frustrating to be stuck on a system that uses some non-GNU variants of commands (Mac OS, mainly, but I sometimes run into undead Solaris zombies), I'll be honest: this GNU stuff is still new to me.
Unlike many of my peers, it wasn't all the fancy extra options that drew me to GNU userspace; it was the absence of fixed-sized buffers. Those old Bell Labs guys loved their fixed-size buffers, and it was a constant pain in my ass that accidentally pushed me into using Perl: I just couldn't trust pre-GNU awk(1) or sed(1) or whatever to cope with "long" lines. (And don't imagine they'd cope gracefully, either. I'm talking buffer overflows, because who could possibly have a line longer than, say, 512 characters?)
One side effect of my non-conversion is that I'm generally ignorant of GNU extensions.
POSIX tail(1) has a -f option ('f' for 'follow') that does its usual job of showing you the last few lines of the file, but then keeps running so it can show you all new content appended to the file. This, as you probably know, is really useful, especially for log files.
My problem is that I keep restarting a program that creates a new log file each time it runs, with the timestamp encoded in the filename. It helpfully creates a symbolic link to the most recent log file, but traditional tail -f opens a file descriptor and, to implement the -f part of its functionality, keeps calling fstat(2) to see if the file pointed to by the file descriptor has changed size, and if it has, it copies the new content to stdout. This, obviously, doesn't work in my case, because I care if the symbolic link changes too, and want to start following the new file.
I finally got sick of "interrupt, up-arrow, return" yesterday, and was about to write a simple script when I realized I should check GNU tail doesn't already have such functionality. And, of course, it does: tail -F. This re-opens the original path if the fstat(2) shows that the file is a different file (recognizable by an inode or device number change).
Why are both useful? Well, you want tail -f if your path might be renamed or unlinked but you still want to read it (remember that an unlinked file continues to exist as long as some process has an open file descriptor for it). And you want tail -F if your path might be renamed or unlinked or replaced by a different symbolic link and you want to switch to reading whatever file (if any) comes along to replace it.
Personally, I think I'm going to start retraining my fingers to use -F because I think that's my more usual use case. YMMV. And apologies to the youngsters who already knew all this, but I'm pretty sure I'm not the only dinosaur still wandering the earth.
Review: "The Old New Thing"
elliotth's blog - Mon, 24/11/2008 - 4:39am
If you waste your time reading crap on the internet (as you clearly do), you've probably come across Raymond Chen's blog "The Old New Thing". You may also be aware that he wrote a book with the same title, and, for all I know, it's something all Windows programmers have read.
I, though, am "one of those condescending Unix computer users".
I've used Windows on and off since 1993, but I've only used Windows out of some kind of necessity. It always seemed to me to be badly designed and obscure and cluttered with legacy crap, and I might try to use that as an excuse for not liking Windows, if it weren't for the fact that you could say the same things about Unix. It may be that the real difference is just that I'm much better versed in the bad design and obscurity and clutter of Unix.
I don't actually believe that, but doesn't matter anyway: the fact is, Windows exists, and Windows is huge. One reason I've never been convinced by the argument that "Linux will win the desktop because it costs nothing, and people love not paying for stuff" is that you don't have to strike up too many conversations with strangers to find that the man on the street considers Windows (and MS Office and the like) to cost nothing either. Software either comes with the computer (and they get a new version when they get a new computer), or, if they're really keen, it comes from work or a friend.
People proudly tell me they copy Windows, which I've always found strange on many levels. But that in itself tells you something about Windows' ubiquity and how it's perceived.
Ignoring Windows is like ignoring religion. You may personally think it's a load of shite, but you can't deny its influence, and that influence alone makes it worthy of study.
Although I sometimes read posts on Chen's blog when they're linked to from places I read, and I was aware of the book's existence, I hadn't been curious enough to go out and buy "The Old New Thing", but I saw a copy on a shelf at work, borrowed it, and read it over this past weekend.
I loved it. It's full of random stuff from a perspective quite different from my own, but with an obvious shared heritage of double-frees and memory leaks and performance problems and so forth. There were whole chapters I basically skipped over (chapter 15, "How Window Messages Are Delivered and Retrieved", for example), but the range of the book is sufficiently diverse, and Windows' influence so far-reaching, that there's bound to be something of interest.
Topics range from memory allocation (and problems all the way from 16- through 32- to 64-bit), concurrency primitives, text rendering, debugging, reverse engineering, to why various Windows features/APIs are the way they are.
I liked the debugging tips slipped in here and there; the kinds of things you learn on the job rather than in class. "The poor man's way of identifying memory leaks", for example, talks about just letting a program leak away, and seeing what the heap's full of. And the fact that the caller whose allocation attempt causes your system's out of memory failure is probably responsible (despite your temptation to assume innocence unless proven guilty). And that the former can help you confirm or deny the latter. These are the kinds of things that aren't usually considered academic enough to be written down, but are still bloody useful.
Sure, you and I know that one, and probably most of the other debugging tips in the book (though there were also common Windows API mistakes, and thus fairly meaningless to me), but we also know people who still don't know this stuff, and we can probably still remember the time when we didn't know it either.
If, on the other hand, you're thinking "dude, get better tools", just wait: one of these days you'll be looking at a customer's production system, or looking at a postmortem, or a system too large or new or small to be able to afford better tools.
The Windows-specific stuff is sometimes a bit annoying, but it's only to be expected in a book like this, and it's not too hard to work out what's going on. For example, it seems like Windows uses the terms "brush" and "pen" for something like (but not exactly the same as) Java2D's Paint and Stroke respectively. It's easy enough to work out, and the (surprisingly few) sections that are obviously of no relevance outside Windows itself are easily skimmed over.
The book opens with a chapter of anecdotal examples of the kinds of lessons the Linux desktop still needs to learn. It's interesting at many points in the book, in fact, to contrast the three camps. Chen usually only talks about the Windows camp, for obvious reasons, and their position can seemingly be summarized as "we started this a long time ago, on really crappy hardware, and we know better now, and try to do new stuff in a way that shows we've learned some of these lessons, but our business is selling OS upgrades, and every incompatible change we make costs us a sale, so we go to ridiculous lengths to avoid ever breaking anything, even stuff that only ever worked by coincidence, or that deliberately went out of its way to fiddle with undocumented internals".
Mac OS is pretty much at the opposite end of the scale, with "we know that you can't make an omelet without breaking eggs, so eggs will be broken if we consider it to be in our greater good, and you get about one year of deprecation and the year after that, your code breaks; we're a hardware company, so we know people will buy the new release anyway, even if only because it comes 'free' with your next machine, but actually, they'll probably buy it anyway, because our main customers are individuals, not corporations, and they like shiny new stuff and don't have any DOS applications written in assembler in 1982 that they've long since lost the source to".
Linux? "Nothing really works very well yet, but it's free and Free, and you can fix it yourself, and it doesn't matter anyway because next week we're going to rip out all this half-working stuff and replace it with stuff that fixes a few things that currently don't work while at the same time breaking things that did work; it doesn't matter because we don't have customers, and our non-customers don't have any software they don't have the source to anyway".
Of course, you never hear these philosophies stated explicitly like that. Apple's too secretive, no-one can seriously claim to speak for "Linux", and I've no idea whether Chen is really representative of Microsoft, assuming it's any more possible to be representative (in the non-legal sense) of a company that large than it is to represent "the Linux community". But Chen has a clear voice, and it's an interesting perspective to me, especially presented through the course of a book, rather than in bits and pieces as I read occasional linked-to blog posts.
If you want just one contrast, try this, from "Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT" (someone spank the editor who changed == to = there!):
... This allowed people to write a single program that got the Windows 2000 look when running on Windows 2000 and got the classic look when running on older systems. (If you make people have to write two versions of their program, one that runs on all systems and one that runs only on the newer system and looks slightly cooler, they will usually not bother writing the second one.)
This, to me, was a revelation. By "people", he means, of course, "Windows programmers". But how interesting that, from my position outside the Windows camp, I actually did a double-take when reading his parenthetical comment. Surely, I thought, he means they won't bother writing the backwards-compatible version? Let the dead bury the dead, and all that? Isn't "looks slightly cooler" an important selling feature, even for Windows (the OS)?
Try to find a Mac application (that's still maintained) that still runs on 10.2, say, and you'll not have much luck. Try to run the latest version of a Linux app on Ubuntu 8.04 (the "long-term" release that some people will be stuck with until 2010-04) without resorting to building it yourself from source... and even then, you'll probably need to build the latest versions of umpteen different libraries it depends on.
I was well aware that Microsoft bend over backwards to keep stuff working (and I was disappointed that Chen doesn't actually go into much detail on the techniques they use, which was something I would have been particularly interested to read about), but I didn't realize the backwards-compatibility-above-all mindset extended to third-party developers too, or is at least perceived to do so.
Going back to some of the other topics, I was interested to hear both that Windows gets the old "pointer change without mouse movement" problem right, and how, and that it causes complaints (presumably from people who haven't suffered systems that get it wrong), and that no-one appreciates the effort much because the related "pointer change when a component scrolls under the mouse" problem needs to be solved per-application, and often isn't. I've always hated programming for systems that won't even let me get those details right, and it's interesting to hear a Windows programmer ("of all people!") saying how much he hates it when apps don't get those details right.
The weird part is that in the final chapter of the book he mentions several "funny stories" that are actually just annoying bugs in Microsoft software, but which he seems to see as cases of user error. It's almost like the last chapter is written by a different person, that depressing guy you always imagine works at Microsoft, cranking out shit code with a shit UI and with no interest in rising to the challenge of writing something that works well under all the awful constraints imposed on it, but who's just interested in getting all the relevant forms filled and boxes checked so he can move on to the next task he also doesn't care about.
Maybe Chen is that guy, at times, and his editor asked for an extra 20 pages Chen didn't want to write? Maybe we're all that guy at times, though most programmers I've known tend to be good at losing tasks in their to-do lists, because there's always more stuff to do than there is time to do it.
What else did I like? I liked the repeated mentions of the need for a holistic view of performance: that making one thing better at the expense of some other thing isn't necessarily a good idea. There are repeated reminders that it's bad to assume that your application is the most important application in the user's day, every day. (You'd hope this wouldn't even need mentioning, but everyone who's ever used software knows it does.)
Speaking of things that shouldn't need mentioning, I was amused to see an analog of something I first came across in a Studs Terkel interview with a Republican ex-governor of a state like Montana. This old Republican was criticizing modern politicians on both sides, complaining that they'd lost the insight of looking at any new legislation as if it had been brought up by the opposition for the opposition's own use. His point being that at some point, anything can and will be used against you. And if you don't like the look of it from the unfriendly end of the barrel, maybe you ought not be handing it out in the first place. Chen's version is more like "what could a virus writer do with this API?" or "if I was a user, how could a developer make a really annoying application with this API?".
One of Chen's code snippets had me mystified. I'll ignore the use of SIZE_T instead of size_t and assume I don't want to know, but there was a bit of C++ that contained this:
The code contains three lines that would need an explicit "std::", none of which, with the "std::" added, would be as long as the "sloppy" comment. Bizarre. And a missed opportunity to show a handy trick I learned from Martin Dorey. Don't want to keep repeating std::cout (which were two of the three uses of "std::" in Chen's code)? Do this:
This is nice even in code that's "just a quick test", but it's better still when that "quick test" turns into production code, and you need to refactor so you can pass in an arbitrary stream. Your code is already referring to just "os" (the usual name for an ostream), so all you need to do is turn the local "os" into an extra argument. Job done.
Returning one last time to things I liked, there was an explanation of why NTFS keeps a Unicode case mapping table on disk, which is something I'd wondered about, but obviously never enough to ask. And the weird code I just mentioned was actually in a section titled after the only thing I knowingly quote from a Microsoft developer, Rico Mariani: "a cache with a bad policy is another name for a memory leak".
Would I buy this book? No. It's not a classic, or a reference work I can imagine I'd keep coming back to. But it was an enjoyable read, and an interesting insight into a parallel universe. Borrow.
If you waste your time reading crap on the internet (as you clearly do), you've probably come across Raymond Chen's blog "The Old New Thing". You may also be aware that he wrote a book with the same title, and, for all I know, it's something all Windows programmers have read.
I, though, am "one of those condescending Unix computer users".
I've used Windows on and off since 1993, but I've only used Windows out of some kind of necessity. It always seemed to me to be badly designed and obscure and cluttered with legacy crap, and I might try to use that as an excuse for not liking Windows, if it weren't for the fact that you could say the same things about Unix. It may be that the real difference is just that I'm much better versed in the bad design and obscurity and clutter of Unix.
I don't actually believe that, but doesn't matter anyway: the fact is, Windows exists, and Windows is huge. One reason I've never been convinced by the argument that "Linux will win the desktop because it costs nothing, and people love not paying for stuff" is that you don't have to strike up too many conversations with strangers to find that the man on the street considers Windows (and MS Office and the like) to cost nothing either. Software either comes with the computer (and they get a new version when they get a new computer), or, if they're really keen, it comes from work or a friend.
People proudly tell me they copy Windows, which I've always found strange on many levels. But that in itself tells you something about Windows' ubiquity and how it's perceived.
Ignoring Windows is like ignoring religion. You may personally think it's a load of shite, but you can't deny its influence, and that influence alone makes it worthy of study.
Although I sometimes read posts on Chen's blog when they're linked to from places I read, and I was aware of the book's existence, I hadn't been curious enough to go out and buy "The Old New Thing", but I saw a copy on a shelf at work, borrowed it, and read it over this past weekend.
I loved it. It's full of random stuff from a perspective quite different from my own, but with an obvious shared heritage of double-frees and memory leaks and performance problems and so forth. There were whole chapters I basically skipped over (chapter 15, "How Window Messages Are Delivered and Retrieved", for example), but the range of the book is sufficiently diverse, and Windows' influence so far-reaching, that there's bound to be something of interest.
Topics range from memory allocation (and problems all the way from 16- through 32- to 64-bit), concurrency primitives, text rendering, debugging, reverse engineering, to why various Windows features/APIs are the way they are.
I liked the debugging tips slipped in here and there; the kinds of things you learn on the job rather than in class. "The poor man's way of identifying memory leaks", for example, talks about just letting a program leak away, and seeing what the heap's full of. And the fact that the caller whose allocation attempt causes your system's out of memory failure is probably responsible (despite your temptation to assume innocence unless proven guilty). And that the former can help you confirm or deny the latter. These are the kinds of things that aren't usually considered academic enough to be written down, but are still bloody useful.
Sure, you and I know that one, and probably most of the other debugging tips in the book (though there were also common Windows API mistakes, and thus fairly meaningless to me), but we also know people who still don't know this stuff, and we can probably still remember the time when we didn't know it either.
If, on the other hand, you're thinking "dude, get better tools", just wait: one of these days you'll be looking at a customer's production system, or looking at a postmortem, or a system too large or new or small to be able to afford better tools.
The Windows-specific stuff is sometimes a bit annoying, but it's only to be expected in a book like this, and it's not too hard to work out what's going on. For example, it seems like Windows uses the terms "brush" and "pen" for something like (but not exactly the same as) Java2D's Paint and Stroke respectively. It's easy enough to work out, and the (surprisingly few) sections that are obviously of no relevance outside Windows itself are easily skimmed over.
The book opens with a chapter of anecdotal examples of the kinds of lessons the Linux desktop still needs to learn. It's interesting at many points in the book, in fact, to contrast the three camps. Chen usually only talks about the Windows camp, for obvious reasons, and their position can seemingly be summarized as "we started this a long time ago, on really crappy hardware, and we know better now, and try to do new stuff in a way that shows we've learned some of these lessons, but our business is selling OS upgrades, and every incompatible change we make costs us a sale, so we go to ridiculous lengths to avoid ever breaking anything, even stuff that only ever worked by coincidence, or that deliberately went out of its way to fiddle with undocumented internals".
Mac OS is pretty much at the opposite end of the scale, with "we know that you can't make an omelet without breaking eggs, so eggs will be broken if we consider it to be in our greater good, and you get about one year of deprecation and the year after that, your code breaks; we're a hardware company, so we know people will buy the new release anyway, even if only because it comes 'free' with your next machine, but actually, they'll probably buy it anyway, because our main customers are individuals, not corporations, and they like shiny new stuff and don't have any DOS applications written in assembler in 1982 that they've long since lost the source to".
Linux? "Nothing really works very well yet, but it's free and Free, and you can fix it yourself, and it doesn't matter anyway because next week we're going to rip out all this half-working stuff and replace it with stuff that fixes a few things that currently don't work while at the same time breaking things that did work; it doesn't matter because we don't have customers, and our non-customers don't have any software they don't have the source to anyway".
Of course, you never hear these philosophies stated explicitly like that. Apple's too secretive, no-one can seriously claim to speak for "Linux", and I've no idea whether Chen is really representative of Microsoft, assuming it's any more possible to be representative (in the non-legal sense) of a company that large than it is to represent "the Linux community". But Chen has a clear voice, and it's an interesting perspective to me, especially presented through the course of a book, rather than in bits and pieces as I read occasional linked-to blog posts.
If you want just one contrast, try this, from "Why does DS_SHELLFONT = DS_FIXEDSYS | DS_SETFONT" (someone spank the editor who changed == to = there!):
... This allowed people to write a single program that got the Windows 2000 look when running on Windows 2000 and got the classic look when running on older systems. (If you make people have to write two versions of their program, one that runs on all systems and one that runs only on the newer system and looks slightly cooler, they will usually not bother writing the second one.)
This, to me, was a revelation. By "people", he means, of course, "Windows programmers". But how interesting that, from my position outside the Windows camp, I actually did a double-take when reading his parenthetical comment. Surely, I thought, he means they won't bother writing the backwards-compatible version? Let the dead bury the dead, and all that? Isn't "looks slightly cooler" an important selling feature, even for Windows (the OS)?
Try to find a Mac application (that's still maintained) that still runs on 10.2, say, and you'll not have much luck. Try to run the latest version of a Linux app on Ubuntu 8.04 (the "long-term" release that some people will be stuck with until 2010-04) without resorting to building it yourself from source... and even then, you'll probably need to build the latest versions of umpteen different libraries it depends on.
I was well aware that Microsoft bend over backwards to keep stuff working (and I was disappointed that Chen doesn't actually go into much detail on the techniques they use, which was something I would have been particularly interested to read about), but I didn't realize the backwards-compatibility-above-all mindset extended to third-party developers too, or is at least perceived to do so.
Going back to some of the other topics, I was interested to hear both that Windows gets the old "pointer change without mouse movement" problem right, and how, and that it causes complaints (presumably from people who haven't suffered systems that get it wrong), and that no-one appreciates the effort much because the related "pointer change when a component scrolls under the mouse" problem needs to be solved per-application, and often isn't. I've always hated programming for systems that won't even let me get those details right, and it's interesting to hear a Windows programmer ("of all people!") saying how much he hates it when apps don't get those details right.
The weird part is that in the final chapter of the book he mentions several "funny stories" that are actually just annoying bugs in Microsoft software, but which he seems to see as cases of user error. It's almost like the last chapter is written by a different person, that depressing guy you always imagine works at Microsoft, cranking out shit code with a shit UI and with no interest in rising to the challenge of writing something that works well under all the awful constraints imposed on it, but who's just interested in getting all the relevant forms filled and boxes checked so he can move on to the next task he also doesn't care about.
Maybe Chen is that guy, at times, and his editor asked for an extra 20 pages Chen didn't want to write? Maybe we're all that guy at times, though most programmers I've known tend to be good at losing tasks in their to-do lists, because there's always more stuff to do than there is time to do it.
What else did I like? I liked the repeated mentions of the need for a holistic view of performance: that making one thing better at the expense of some other thing isn't necessarily a good idea. There are repeated reminders that it's bad to assume that your application is the most important application in the user's day, every day. (You'd hope this wouldn't even need mentioning, but everyone who's ever used software knows it does.)
Speaking of things that shouldn't need mentioning, I was amused to see an analog of something I first came across in a Studs Terkel interview with a Republican ex-governor of a state like Montana. This old Republican was criticizing modern politicians on both sides, complaining that they'd lost the insight of looking at any new legislation as if it had been brought up by the opposition for the opposition's own use. His point being that at some point, anything can and will be used against you. And if you don't like the look of it from the unfriendly end of the barrel, maybe you ought not be handing it out in the first place. Chen's version is more like "what could a virus writer do with this API?" or "if I was a user, how could a developer make a really annoying application with this API?".
One of Chen's code snippets had me mystified. I'll ignore the use of SIZE_T instead of size_t and assume I don't want to know, but there was a bit of C++ that contained this:
// Since this is just a quick test, we're going to be sloppy
using namespace std; // sloppy
The code contains three lines that would need an explicit "std::", none of which, with the "std::" added, would be as long as the "sloppy" comment. Bizarre. And a missed opportunity to show a handy trick I learned from Martin Dorey. Don't want to keep repeating std::cout (which were two of the three uses of "std::" in Chen's code)? Do this:
std::ostream& os(std::cout);
os << blah;
This is nice even in code that's "just a quick test", but it's better still when that "quick test" turns into production code, and you need to refactor so you can pass in an arbitrary stream. Your code is already referring to just "os" (the usual name for an ostream), so all you need to do is turn the local "os" into an extra argument. Job done.
Returning one last time to things I liked, there was an explanation of why NTFS keeps a Unicode case mapping table on disk, which is something I'd wondered about, but obviously never enough to ask. And the weird code I just mentioned was actually in a section titled after the only thing I knowingly quote from a Microsoft developer, Rico Mariani: "a cache with a bad policy is another name for a memory leak".
Would I buy this book? No. It's not a classic, or a reference work I can imagine I'd keep coming back to. But it was an enjoyable read, and an interesting insight into a parallel universe. Borrow.
Nice one, Adobe!
elliotth's blog - Tue, 18/11/2008 - 5:31am
I find it interesting that, though I'm actually sincere, the title sounds like sarcasm.
I'm sure you've already heard because it was big news today: Adobe released an alpha 64-bit Flash player today, for Linux (amd64 only), and Solaris (amd64 and sparc). Here's my "added value": I was stupid enough to try it, and can tell you how I got on.
It works.
I'm watching some of the low-quality video crap that clogs up the intertubes in another window right now, even as I write this low-quality text crap which I'll bung into those very same tubes shortly.
I needed to "sudo apt-get autoremove gnash" before Adobe's player would work (the symptom being that I'd click on FlashBlock's icon, and the space reserved for the embedded Flash player would shrink to nothing), but that's fair enough. Thanks to the sheer number of non-functional Flash players I'd tried in earlier attempts, it was quite a hassle to find and remove them all, but that's not Adobe's fault.
I've never had Flash work on 64-bit Linux before. And not for want of trying. I know people who claim they have had working Flash on 64-bit Linux, but I know more who've had as little success as me, and even the "successful" ones will admit to unreliability.
Installation is as simple as a "tar zxf", a "mkdir ~/.mozilla/plugins", and a "mv" of the former file to the latter directory. If you're a Mac or Windows user, this might sound awful, and in a way it is, but the usual instructions for getting Flash working on 64-bit Linux (a) involve sacrifices of rare animals and (b) don't actually work. And you have to realize that if they'd tried anything more fancy, the users of some Linux distribution you've never even heard of would be complaining that there's no package suitable for their homebrew package manager.
As a sign of my gratitude, next time I'm strolling past their headquarters, and the missus goads me by saying "Adobe" out loud, I'll refrain from my usual response of "wankers that they are, cranking out shite".
Provided, that is, I don't encounter Acrobat Reader or any of their installers in the meantime...
I find it interesting that, though I'm actually sincere, the title sounds like sarcasm.
I'm sure you've already heard because it was big news today: Adobe released an alpha 64-bit Flash player today, for Linux (amd64 only), and Solaris (amd64 and sparc). Here's my "added value": I was stupid enough to try it, and can tell you how I got on.
It works.
I'm watching some of the low-quality video crap that clogs up the intertubes in another window right now, even as I write this low-quality text crap which I'll bung into those very same tubes shortly.
I needed to "sudo apt-get autoremove gnash" before Adobe's player would work (the symptom being that I'd click on FlashBlock's icon, and the space reserved for the embedded Flash player would shrink to nothing), but that's fair enough. Thanks to the sheer number of non-functional Flash players I'd tried in earlier attempts, it was quite a hassle to find and remove them all, but that's not Adobe's fault.
I've never had Flash work on 64-bit Linux before. And not for want of trying. I know people who claim they have had working Flash on 64-bit Linux, but I know more who've had as little success as me, and even the "successful" ones will admit to unreliability.
Installation is as simple as a "tar zxf", a "mkdir ~/.mozilla/plugins", and a "mv" of the former file to the latter directory. If you're a Mac or Windows user, this might sound awful, and in a way it is, but the usual instructions for getting Flash working on 64-bit Linux (a) involve sacrifices of rare animals and (b) don't actually work. And you have to realize that if they'd tried anything more fancy, the users of some Linux distribution you've never even heard of would be complaining that there's no package suitable for their homebrew package manager.
As a sign of my gratitude, next time I'm strolling past their headquarters, and the missus goads me by saying "Adobe" out loud, I'll refrain from my usual response of "wankers that they are, cranking out shite".
Provided, that is, I don't encounter Acrobat Reader or any of their installers in the meantime...
Watching DVDs on an Xbox 360
elliotth's blog - Mon, 03/11/2008 - 9:30pm
So I finally got an HDTV, and games look awesome...
That's not a question.
Why do DVDs look shite?
Because they're still playing at 480p. Your TV probably tells you this when it switches mode. The DVD itself is recorded at a higher resolution than that, though.
Okay, so how do I fix it?
You need the 360 to "upscale" to 1080i. The 360 (if it's new enough to have an HDMI port on the back) contains the hardware to do this, but it won't do it via the component cables you're probably using.
But games are already at 1080i; why not DVDs?
Because Microsoft hate you, and want you to buy a custom Microsoft cable for USD50.
Do I have to buy Microsoft's USD50 cable?
No. All you really need is a standard HDMI cable (which shouldn't set you back more than USD5).
HDMI's selling point is that it does audio and video through a single cable, so that's all I need, right?
No. Not unless you want your audio through the TV's crappy speakers.
But my TV has a TOSlink (optical audio) out; can't I use that?
Not necessarily. Not on a Sony Bravia, for example. Audio that came in via HDMI won't come out via TOSlink, just via the TV's crappy speakers.
Why not?
Because Sony hate you too, because they know you're a dirty thief who probably half-inched the telly off them in the first place.
Don't forget that Sony are not only the leading consumer electronics company when it comes to proprietary connectors and formats, they're a recording company as well. Twice the evil!
So what do I do?
You need to use an HDMI cable from the 360's HDMI port to the TV for the video, and also run a TOSlink connection from the usual component cable in the back of your Xbox 360 to your surround sound system, like you were already doing.
That is: you need both the old cable and the new cable plugged into your 360 at the same time. You'll use the audio from the old setup and the video from the new setup.
Can I connect an HDMI cable and the component cable at the same time?
Electrically, yes. But Microsoft hate you, remember, so they put the HDMI port so close to the port for the component cable's proprietary connector that when the component cable's plugged in,it overlaps the HDMI port.
So what do I do?
1. You give Microsoft an extra USD50 for their stupid cable. This is probably the best solution.
2. Alternatively, if you like voiding warranties and begrudge those bastards in Washington USD50 that would be better spent on booze and lottery tickets, you take a screwdriver to your component cable, lever the big gray plastic case off, and plug the cable back in to the 360. Removing the plastic means you now have room to slip the HDMI cable in while the component cable is connected. You can find pictures on the web, but note that the plastic case has changed slightly so it's not quite as easy any more, but it's still pretty easy. The hardest part is that you'll have been holding on so tight you probably flipped the SD/HD switch on the side, and you'll want to flip that back.
So I finally got an HDTV, and games look awesome...
That's not a question.
Why do DVDs look shite?
Because they're still playing at 480p. Your TV probably tells you this when it switches mode. The DVD itself is recorded at a higher resolution than that, though.
Okay, so how do I fix it?
You need the 360 to "upscale" to 1080i. The 360 (if it's new enough to have an HDMI port on the back) contains the hardware to do this, but it won't do it via the component cables you're probably using.
But games are already at 1080i; why not DVDs?
Because Microsoft hate you, and want you to buy a custom Microsoft cable for USD50.
Do I have to buy Microsoft's USD50 cable?
No. All you really need is a standard HDMI cable (which shouldn't set you back more than USD5).
HDMI's selling point is that it does audio and video through a single cable, so that's all I need, right?
No. Not unless you want your audio through the TV's crappy speakers.
But my TV has a TOSlink (optical audio) out; can't I use that?
Not necessarily. Not on a Sony Bravia, for example. Audio that came in via HDMI won't come out via TOSlink, just via the TV's crappy speakers.
Why not?
Because Sony hate you too, because they know you're a dirty thief who probably half-inched the telly off them in the first place.
Don't forget that Sony are not only the leading consumer electronics company when it comes to proprietary connectors and formats, they're a recording company as well. Twice the evil!
So what do I do?
You need to use an HDMI cable from the 360's HDMI port to the TV for the video, and also run a TOSlink connection from the usual component cable in the back of your Xbox 360 to your surround sound system, like you were already doing.
That is: you need both the old cable and the new cable plugged into your 360 at the same time. You'll use the audio from the old setup and the video from the new setup.
Can I connect an HDMI cable and the component cable at the same time?
Electrically, yes. But Microsoft hate you, remember, so they put the HDMI port so close to the port for the component cable's proprietary connector that when the component cable's plugged in,it overlaps the HDMI port.
So what do I do?
1. You give Microsoft an extra USD50 for their stupid cable. This is probably the best solution.
2. Alternatively, if you like voiding warranties and begrudge those bastards in Washington USD50 that would be better spent on booze and lottery tickets, you take a screwdriver to your component cable, lever the big gray plastic case off, and plug the cable back in to the 360. Removing the plastic means you now have room to slip the HDMI cable in while the component cable is connected. You can find pictures on the web, but note that the plastic case has changed slightly so it's not quite as easy any more, but it's still pretty easy. The hardest part is that you'll have been holding on so tight you probably flipped the SD/HD switch on the side, and you'll want to flip that back.
Long-term review: Apple Aluminum Keyboards
elliotth's blog - Mon, 20/10/2008 - 12:36am
I mentioned Apple's aluminum keyboards earlier, but having recently bought a couple more, I thought that was a fact worthy of mention. The one I had grew on me and my fingers grew lazy enough that I started to get annoyed at having to lift my fingers so high to clear the tops of the front rows of keys on my work keyboard, or the "spare" keyboard I use with the MacBook Pro if I'm planning on doing some work from home.
The day I replaced my work keyboard, someone came into the office talking about cleaning keyboards, prompting me to said that the best feature of Apple's aluminum keyboards is that (so far) they appear impossible to get dirty. They begged to differ and suggested that the keyboard's best feature is that it looks amazing.
He had a point. I probably wouldn't have bought my first one if they didn't look so damn cool.
So, after a few months of use, the aluminum keyboard's feel grew on you to where other keyboards , and the beauty of its appearance doesn't wear off.
Having two (different) keys labeled "delete", one of which is actually backspace, continues to be retarded, and the numeric keypad continues to be useless to me.
(Speaking of which, the only other keyboard-related development I have to report is Microsoft's SideWinder X6 "gaming keyboard". It's not without a numeric keypad, but it does let you detach the numeric keypad to switch sides, and it's not obvious that you have to reattach it. Unfortunately, although the "editing pad" is fine, the esc key is in the wrong place, there's an extra row and extra column of useless keys, and two enormous dials. Plus the thing's almost as deep as it is wide, very clunky-looking, and may or may not require special Windows-only drivers. Microsoft usually says their keyboards and mice work with Mac OS, but they don't with this one. That may just mean that various features you don't actually want won't work, but who knows? And if they're not interested in telling me, I'm not interested in buying one to find out.)
I mentioned Apple's aluminum keyboards earlier, but having recently bought a couple more, I thought that was a fact worthy of mention. The one I had grew on me and my fingers grew lazy enough that I started to get annoyed at having to lift my fingers so high to clear the tops of the front rows of keys on my work keyboard, or the "spare" keyboard I use with the MacBook Pro if I'm planning on doing some work from home.
The day I replaced my work keyboard, someone came into the office talking about cleaning keyboards, prompting me to said that the best feature of Apple's aluminum keyboards is that (so far) they appear impossible to get dirty. They begged to differ and suggested that the keyboard's best feature is that it looks amazing.
He had a point. I probably wouldn't have bought my first one if they didn't look so damn cool.
So, after a few months of use, the aluminum keyboard's feel grew on you to where other keyboards , and the beauty of its appearance doesn't wear off.
Having two (different) keys labeled "delete", one of which is actually backspace, continues to be retarded, and the numeric keypad continues to be useless to me.
(Speaking of which, the only other keyboard-related development I have to report is Microsoft's SideWinder X6 "gaming keyboard". It's not without a numeric keypad, but it does let you detach the numeric keypad to switch sides, and it's not obvious that you have to reattach it. Unfortunately, although the "editing pad" is fine, the esc key is in the wrong place, there's an extra row and extra column of useless keys, and two enormous dials. Plus the thing's almost as deep as it is wide, very clunky-looking, and may or may not require special Windows-only drivers. Microsoft usually says their keyboards and mice work with Mac OS, but they don't with this one. That may just mean that various features you don't actually want won't work, but who knows? And if they're not interested in telling me, I'm not interested in buying one to find out.)
CACM: no longer sucking
elliotth's blog - Sat, 11/10/2008 - 10:45pm
Communications of the ACM used to be great. When I went to university, I spent nights reading back-issues, and can honestly claim to have read every single issue. In the early days, even the letter pages were great: people were arguing about how to correctly implement semaphores and whether gotos were harmful. And in the main body of the magazine, others would be showing off their new "quick sort" algorithm, introducing a new time-sharing system called "Unix" or a new distributed packet switching system called, of all things, "Ethernet".
And then, somewhere in the 1990s, it turned to shit. All management and business and "IT" and government projects and sociology and just random, well, shit. So although I became a member of the ACM when I left university (mainly so I could get the SIGPLAN proceedings without finding a university library, and so I could avoid being one of those creepy old obviously-not-a-student guys who hangs around university libraries), for most of the past decade, I've "read" CACM in the distance between my letter box and the kitchen bin.
I still read the SIGPLAN conference proceedings, though, because I'm interested in that stuff, it's peer-reviewed (so even when it's crap, it's at least coherent crap written by people with CS degrees), and it gives me an idea of what research is being done in that sub-sub-sub-field.
CACM, though, wasn't even fit to wipe your arse on. (Glossy paper, you see.)
The past few issues, though, have picked up substantially. I didn't comment on the first one, because even a gobshite like Adam Sandler or Will Ferrell might make a good film once in their lives. But we're on the fourth non-shite issue of CACM in four months, and that's better than they managed throughout the entire 1990s. Hell, you'd have to go back to the 1970s for that kind of quality.
Sure, it's not perfect, but it's a huge leap forward. The "news" is now reminiscent of New Scientist, rather than just being a random collection of six-month-old Slashdot stories. The random articles have managed to be mostly decent overviews of mostly sufficiently technical stuff. And the "research highlights" section, well, that's the lesson they learned from Nature/Science, and it's done beautifully. They get someone who knows the subject write a one-page layman's introduction to a paper, followed by the actual paper, that you probably won't fully understand unless it's a field you know. So last month had Mark Moir (senior staff engineer at Sun) introduce/review a paper on using transactional memory in operating systems, followed by the paper; then Hagit Attiya (professor of CS at the Technion) introducing a distributed algorithm for computing the k-th smallest element, followed by the paper.
Other recent-issue articles have included Adam Leventhal's "Flash Storage Memory" on using flash as another level in the storage hierarchy (rather than a straight disk "replacement"), Mark Oskin's "The Revolution Inside the Box", reviewing the last decade of computer architecture research (not all multi-core, but, yeah, plenty of that). Plenty of papers on transactional memory (which it's been pretty hard to avoid lately anyway, but it's nice to have someone picking out just the good bits). And if human interest stories are more your thing, there's been the heartwarming two-part serial about Don Knuth and his massive organ.
This, the new CACM, is a thing of beauty. This is something you'd actually pay money for. (Which is nice, because I've been paying money for it for just over a decade now.)
What's not good? Well, there's some sloppiness; multiple (different) expansions of the acronym XML in the same issue, for example. (And seriously, if it's as mainstream as XML, does expanding the acronym help anyone? If they didn't already know what it meant, the expansion isn't going to clue them in. Typing "XML" into their favorite search engine will, and if they're incapable of doing that themselves, they're a lost cause.) Not all of the articles are of a high-enough quality, with hints of the bad old 1990s "business wank" CACM. There was some article last month from Michael Cusumano (a professor at the MIT Sloan School of Management) that was both irrelevant and factually incorrect; I gave up before coming to his point, assuming he had one.
Back on the bright side, the 2008-10 issue contains the paper "Scene Completion Using Millions of Photographs" by Hays and Efros that's exactly what I want: something interesting, accessible, and well outside my usual sphere; something I wouldn't have come across on my own.
Hopefully the future contains more of the new stuff and ever less of the old stuff.
If you're serious about CS, and interested in having some vague idea of what kinds of things people are looking at in our increasingly wide and diverse field, I can actually recommend CACM for the first time since the 1970s. I finish an issue feeling like I've learned something, rather than feeling like I'm an idiot for paying for some sociologist or MBA to gibber on about stuff that's not true, not falsifiable, or not pertinent.
The only downside to CACM being worth reading again is that it's yet another demand on my copious free time.
Communications of the ACM used to be great. When I went to university, I spent nights reading back-issues, and can honestly claim to have read every single issue. In the early days, even the letter pages were great: people were arguing about how to correctly implement semaphores and whether gotos were harmful. And in the main body of the magazine, others would be showing off their new "quick sort" algorithm, introducing a new time-sharing system called "Unix" or a new distributed packet switching system called, of all things, "Ethernet".
And then, somewhere in the 1990s, it turned to shit. All management and business and "IT" and government projects and sociology and just random, well, shit. So although I became a member of the ACM when I left university (mainly so I could get the SIGPLAN proceedings without finding a university library, and so I could avoid being one of those creepy old obviously-not-a-student guys who hangs around university libraries), for most of the past decade, I've "read" CACM in the distance between my letter box and the kitchen bin.
I still read the SIGPLAN conference proceedings, though, because I'm interested in that stuff, it's peer-reviewed (so even when it's crap, it's at least coherent crap written by people with CS degrees), and it gives me an idea of what research is being done in that sub-sub-sub-field.
CACM, though, wasn't even fit to wipe your arse on. (Glossy paper, you see.)
The past few issues, though, have picked up substantially. I didn't comment on the first one, because even a gobshite like Adam Sandler or Will Ferrell might make a good film once in their lives. But we're on the fourth non-shite issue of CACM in four months, and that's better than they managed throughout the entire 1990s. Hell, you'd have to go back to the 1970s for that kind of quality.
Sure, it's not perfect, but it's a huge leap forward. The "news" is now reminiscent of New Scientist, rather than just being a random collection of six-month-old Slashdot stories. The random articles have managed to be mostly decent overviews of mostly sufficiently technical stuff. And the "research highlights" section, well, that's the lesson they learned from Nature/Science, and it's done beautifully. They get someone who knows the subject write a one-page layman's introduction to a paper, followed by the actual paper, that you probably won't fully understand unless it's a field you know. So last month had Mark Moir (senior staff engineer at Sun) introduce/review a paper on using transactional memory in operating systems, followed by the paper; then Hagit Attiya (professor of CS at the Technion) introducing a distributed algorithm for computing the k-th smallest element, followed by the paper.
Other recent-issue articles have included Adam Leventhal's "Flash Storage Memory" on using flash as another level in the storage hierarchy (rather than a straight disk "replacement"), Mark Oskin's "The Revolution Inside the Box", reviewing the last decade of computer architecture research (not all multi-core, but, yeah, plenty of that). Plenty of papers on transactional memory (which it's been pretty hard to avoid lately anyway, but it's nice to have someone picking out just the good bits). And if human interest stories are more your thing, there's been the heartwarming two-part serial about Don Knuth and his massive organ.
This, the new CACM, is a thing of beauty. This is something you'd actually pay money for. (Which is nice, because I've been paying money for it for just over a decade now.)
What's not good? Well, there's some sloppiness; multiple (different) expansions of the acronym XML in the same issue, for example. (And seriously, if it's as mainstream as XML, does expanding the acronym help anyone? If they didn't already know what it meant, the expansion isn't going to clue them in. Typing "XML" into their favorite search engine will, and if they're incapable of doing that themselves, they're a lost cause.) Not all of the articles are of a high-enough quality, with hints of the bad old 1990s "business wank" CACM. There was some article last month from Michael Cusumano (a professor at the MIT Sloan School of Management) that was both irrelevant and factually incorrect; I gave up before coming to his point, assuming he had one.
Back on the bright side, the 2008-10 issue contains the paper "Scene Completion Using Millions of Photographs" by Hays and Efros that's exactly what I want: something interesting, accessible, and well outside my usual sphere; something I wouldn't have come across on my own.
Hopefully the future contains more of the new stuff and ever less of the old stuff.
If you're serious about CS, and interested in having some vague idea of what kinds of things people are looking at in our increasingly wide and diverse field, I can actually recommend CACM for the first time since the 1970s. I finish an issue feeling like I've learned something, rather than feeling like I'm an idiot for paying for some sociologist or MBA to gibber on about stuff that's not true, not falsifiable, or not pertinent.
The only downside to CACM being worth reading again is that it's yet another demand on my copious free time.
Review: "Effective Java", 2nd edition
elliotth's blog - Wed, 08/10/2008 - 6:19pm
One of the benefits of working at Google that I hadn't heard about until I joined is that you're both actively plied with books when you start, and given annual credit to buy books of your choice (without the hassle of filing expenses).
Any developer who wanted a copy of the second edition of "Effective Java" was offered one when it came out, and I eventually read through it, and I finally found the time to write down a few notes...
The first thing you'll notice is that the second edition is much thicker than the first edition. The last page of actual content in the first edition was page 232; it's page 315 in the second edition. That might not seem like much of an increase, and there's a way to go before it hits the "weighty tome" territory of something like "Mac OS X Internals", but for me those extra pages take "Effective Java" over the threshold from "slim volume" to "book".
In the years from 2001 to 2008, the Java language has changed a lot. Already by page 16 (item 2), we're faced with a bounded wildcard type. Those of us who've been using Java between the two editions have also changed a lot, and a lot of the advice from the first edition, even if you weren't already following it at the time the book came out, has since become the standard idiom that everyone above a basic level of competence uses. As a result, the second edition feels very repetitive.
I really wish there were two variants: "diffs" for those of us who know the first edition and have been following its advice for years, and "from scratch" for those new to Java (or who don't read much). It's not hard to imagine "Effective Java" making a better website than a book, too. Most of the items, especially if you're familiar with the first edition, are things you can grok from the title, with little to add for the expert.
This is in stark contrast to how I remember the first edition. I remember being persuaded of several idioms by the first edition. Some things like "Return zero-length arrays, not nulls" were things we'd already worked out for ourselves, and "Minimize the scope of local variables" has been something that good programmers have understood since the beginning of time, but I remember it feeling really good to hear a voice of authority say "Avoid unnecessary use of checked exceptions". We all knew there was something wrong, but you had to have a certain stature to stand up and say "the emperor has no clothes", and the guy who was the public face of the collections classes had that stature.
The interesting thing reading the second edition is that it's likely to elicit a raised eyebrow now and again, and remind you that, presumably, there are (new) beginners who need to be told of things we've all been doing since the 1990s.
As an aside, an interesting difference between "Effective Java" and "Effective C++" is that my reaction to the latter was to come up with a set of SOPs that mainly boil down to "don't use C++ feature x". Whereas "Effective Java" was more like "use idiom x when using Java feature y". An interesting consequence of which is that I'm much better able to articulate why I do things the way I do in Java than I am in C++.
Anyway, what stood out for me in the second edition of "Effective Java"?
I didn't know about @code and @literal in JavaDoc; I tend to just write as if comments are plain text, since my API documentation isn't likely to be published anyway, and is more useful to me and others if it's readable in the source form, in contrast to Bloch's "generated documentation readability trumps source code readability". When you're the public face of the collections classes, I guess you have a different perspective.
Bloch's claim that AbstractList.removeRange is "of no interest to end users of a List implementation" made me laugh. And not in a good way. I think that specific API design error has singlehandedly caused more O(n^2) behavior in code I've been exposed to than any other, as people fail to find a bulk remove and use a "for" loop instead. Even if you do know about subList().clear(), it's hard to consider that anything but ungainly. Bulk operations seem more fundamental to me than the idea of a view, I guess, and I rarely have use for views other than because I'm trying to removeRange. Personally, I think that was an attempt to introduce an non-Java idiom into Java, and it didn't really work.
Perhaps because of Bloch's background, much of the advice in the book seems overly biased towards public API. This is understandable, but even if one takes the position that all API should be designed as if it were library API, I think it's hard to argue that you should make any more public API than absolutely necessary. YAGNI, after all, and anyone who hasn't realized that it's far easier to add stuff than to take stuff out or fix stuff, well, that person's obviously not a golfer.
Another interesting contrast with C++ is that, whenever you read a book on C++ you're likely to spend most of your time thinking about how the language could be improved, but reading books like this on Java, you're more likely to think about how the libraries could be improved. It's particularly amusing that the "Effective C++" item "Make interfaces easy to use correctly and hard to use incorrectly" (advice valid for any language, and that ties in to my earlier concern about exposing too much API) has an example "pathologically bad" Date class that's not actually as bad as the real java.util.Date.
I've seen Stroustrup actually use the real Java Date and Calendar classes as examples of bad design on a slide, and I felt it was a shame he detracted from his own point by implying that it was Java's fault. As if you can't write utter crap in any language. As if even good programmers don't have days where everything they touch turns to shite.
As if bad design (like good design) isn't universal.
Java programmers have the advantage of a large and readable library. So there's no excuse for not having seen a large amount of code, much of it high-quality, but enough of it low-quality, or old enough to be using idioms that we've since learned don't work out well. So for an experienced Java programmer, "Effective Java" is a quick read, many chapters of which could be replaced with "use common sense" or "copy the good examples, ignore the bad ones". It's sad to see the number of "obvious" points from the first edition that the JDK still falls down on. "Adhere to generally accepted naming conventions" is one that's getting worse with time as more new JDK APIs arrive using the less popular naming conventions and making them more generally accepted (using "X" and "setX" instead of "getX" and "setX", say, which isn't bad in and of itself, but is just one little bit of extra trivia we have to keep around that adds no value, and is too late to retrofit to the entire JDK). "Include failure-capture information in detail messages" is my personal unfavorite, though it's something programmers in all languages get wrong. Why aren't we teaching "how to write a good bug report" and "how to write a good error message" in the schools? Can you really be a productive member of society without these skills?
The synchronization stuff's been usefully updated in the second edition, and is a lot clearer now. It's a shame that stuff like that, which I'd go so far as saying a majority of Java programmers don't properly understand, isn't visibly treated as being any more important than all the fluff about exceptions and serialization and doc comments and (I'm not joking) the performance of string concatenation.
CopyOnWriteArrayList and its suitability for listener lists was new to me (despite dating back to Java 5). I'll have to remember that. It would be nice to have a new Java tutorial, for experienced programmers, that shows the current best idioms, and explains the rationale. Listener lists are a lot harder to get right than you might hope.
Item 69 settled an argument we'd been having at work. Should you call ConcurrentHashMap.get before calling ConcurrentHashMap.putIfAbsent? Our argument was focused on how expensive the constructor for the to-be-inserted object is. The documentation led us to believe that the implementation effectively does a get straight away, which is true, but the documentation is missing the rather important fact that a lock is taken out for the duration of the call to putIfAbsent. When Bloch presents the get-then-putIfAbsent idiom, he gives this as the motivation, and checking the source shows he's right. I've filed Sun bug 6737830 for improvements to the documentation. The evaluation for that bug is interesting, as it argues back in the opposite direction.
It's nice to see CountDownLatch advertised. That's my favorite low-level primitive.
Bloch suggests using System.nanoTime in preference to System.currentTimeMillis for interval timing, because it's more accurate, more precise, and unaffected by system clock changes. I'd been using System.nanoTime in new code, but given that last advantage maybe it's time (ho ho) for a more thorough toilet-cleaning.
The book ends with a bunch of items on serialization, which was rather surprising to me. I haven't written a (deliberately, explicitly) serializable class in the last eight years. I don't know if that's because serialization isn't a mainstream thing, or because it was eight years ago that I last wrote Java (rather than C++) for a living. Maybe just behind some narrow door in all my favorite bars, Java programmers in red Pendleton shirts are getting incredible kicks from squirting serialized objects at each other. Who knows?
Every time I've touched Java serialization I've come away with the feeling that it's sufficiently broken in a sufficient number of ways that I'm better off just avoiding it. Gangrenous appendages eventually fall off of their own accord, don't they?
If you're a Java programmer, you ought to read this book. It's not going to be a life-changing experience for many. (If you find it is, you probably need to ask the best programmer you know to help mentor you.) This isn't as important a book for Java programmers as "Effective C++" is for C++ programmers. It's also not as important a book for Java programmers as are Goetz's or Wadler's recent books.
But you can't not have read it. Get work to buy a copy and hand it round as each of you finishes. You can read through it in a day, and quicker than that if you're familiar with the first edition and you've been writing (and reading) Java in the intervening years.
One of the benefits of working at Google that I hadn't heard about until I joined is that you're both actively plied with books when you start, and given annual credit to buy books of your choice (without the hassle of filing expenses).
Any developer who wanted a copy of the second edition of "Effective Java" was offered one when it came out, and I eventually read through it, and I finally found the time to write down a few notes...
The first thing you'll notice is that the second edition is much thicker than the first edition. The last page of actual content in the first edition was page 232; it's page 315 in the second edition. That might not seem like much of an increase, and there's a way to go before it hits the "weighty tome" territory of something like "Mac OS X Internals", but for me those extra pages take "Effective Java" over the threshold from "slim volume" to "book".
In the years from 2001 to 2008, the Java language has changed a lot. Already by page 16 (item 2), we're faced with a bounded wildcard type. Those of us who've been using Java between the two editions have also changed a lot, and a lot of the advice from the first edition, even if you weren't already following it at the time the book came out, has since become the standard idiom that everyone above a basic level of competence uses. As a result, the second edition feels very repetitive.
I really wish there were two variants: "diffs" for those of us who know the first edition and have been following its advice for years, and "from scratch" for those new to Java (or who don't read much). It's not hard to imagine "Effective Java" making a better website than a book, too. Most of the items, especially if you're familiar with the first edition, are things you can grok from the title, with little to add for the expert.
This is in stark contrast to how I remember the first edition. I remember being persuaded of several idioms by the first edition. Some things like "Return zero-length arrays, not nulls" were things we'd already worked out for ourselves, and "Minimize the scope of local variables" has been something that good programmers have understood since the beginning of time, but I remember it feeling really good to hear a voice of authority say "Avoid unnecessary use of checked exceptions". We all knew there was something wrong, but you had to have a certain stature to stand up and say "the emperor has no clothes", and the guy who was the public face of the collections classes had that stature.
The interesting thing reading the second edition is that it's likely to elicit a raised eyebrow now and again, and remind you that, presumably, there are (new) beginners who need to be told of things we've all been doing since the 1990s.
As an aside, an interesting difference between "Effective Java" and "Effective C++" is that my reaction to the latter was to come up with a set of SOPs that mainly boil down to "don't use C++ feature x". Whereas "Effective Java" was more like "use idiom x when using Java feature y". An interesting consequence of which is that I'm much better able to articulate why I do things the way I do in Java than I am in C++.
Anyway, what stood out for me in the second edition of "Effective Java"?
I didn't know about @code and @literal in JavaDoc; I tend to just write as if comments are plain text, since my API documentation isn't likely to be published anyway, and is more useful to me and others if it's readable in the source form, in contrast to Bloch's "generated documentation readability trumps source code readability". When you're the public face of the collections classes, I guess you have a different perspective.
Bloch's claim that AbstractList.removeRange is "of no interest to end users of a List implementation" made me laugh. And not in a good way. I think that specific API design error has singlehandedly caused more O(n^2) behavior in code I've been exposed to than any other, as people fail to find a bulk remove and use a "for" loop instead. Even if you do know about subList().clear(), it's hard to consider that anything but ungainly. Bulk operations seem more fundamental to me than the idea of a view, I guess, and I rarely have use for views other than because I'm trying to removeRange. Personally, I think that was an attempt to introduce an non-Java idiom into Java, and it didn't really work.
Perhaps because of Bloch's background, much of the advice in the book seems overly biased towards public API. This is understandable, but even if one takes the position that all API should be designed as if it were library API, I think it's hard to argue that you should make any more public API than absolutely necessary. YAGNI, after all, and anyone who hasn't realized that it's far easier to add stuff than to take stuff out or fix stuff, well, that person's obviously not a golfer.
Another interesting contrast with C++ is that, whenever you read a book on C++ you're likely to spend most of your time thinking about how the language could be improved, but reading books like this on Java, you're more likely to think about how the libraries could be improved. It's particularly amusing that the "Effective C++" item "Make interfaces easy to use correctly and hard to use incorrectly" (advice valid for any language, and that ties in to my earlier concern about exposing too much API) has an example "pathologically bad" Date class that's not actually as bad as the real java.util.Date.
I've seen Stroustrup actually use the real Java Date and Calendar classes as examples of bad design on a slide, and I felt it was a shame he detracted from his own point by implying that it was Java's fault. As if you can't write utter crap in any language. As if even good programmers don't have days where everything they touch turns to shite.
As if bad design (like good design) isn't universal.
Java programmers have the advantage of a large and readable library. So there's no excuse for not having seen a large amount of code, much of it high-quality, but enough of it low-quality, or old enough to be using idioms that we've since learned don't work out well. So for an experienced Java programmer, "Effective Java" is a quick read, many chapters of which could be replaced with "use common sense" or "copy the good examples, ignore the bad ones". It's sad to see the number of "obvious" points from the first edition that the JDK still falls down on. "Adhere to generally accepted naming conventions" is one that's getting worse with time as more new JDK APIs arrive using the less popular naming conventions and making them more generally accepted (using "X" and "setX" instead of "getX" and "setX", say, which isn't bad in and of itself, but is just one little bit of extra trivia we have to keep around that adds no value, and is too late to retrofit to the entire JDK). "Include failure-capture information in detail messages" is my personal unfavorite, though it's something programmers in all languages get wrong. Why aren't we teaching "how to write a good bug report" and "how to write a good error message" in the schools? Can you really be a productive member of society without these skills?
The synchronization stuff's been usefully updated in the second edition, and is a lot clearer now. It's a shame that stuff like that, which I'd go so far as saying a majority of Java programmers don't properly understand, isn't visibly treated as being any more important than all the fluff about exceptions and serialization and doc comments and (I'm not joking) the performance of string concatenation.
CopyOnWriteArrayList and its suitability for listener lists was new to me (despite dating back to Java 5). I'll have to remember that. It would be nice to have a new Java tutorial, for experienced programmers, that shows the current best idioms, and explains the rationale. Listener lists are a lot harder to get right than you might hope.
Item 69 settled an argument we'd been having at work. Should you call ConcurrentHashMap.get before calling ConcurrentHashMap.putIfAbsent? Our argument was focused on how expensive the constructor for the to-be-inserted object is. The documentation led us to believe that the implementation effectively does a get straight away, which is true, but the documentation is missing the rather important fact that a lock is taken out for the duration of the call to putIfAbsent. When Bloch presents the get-then-putIfAbsent idiom, he gives this as the motivation, and checking the source shows he's right. I've filed Sun bug 6737830 for improvements to the documentation. The evaluation for that bug is interesting, as it argues back in the opposite direction.
It's nice to see CountDownLatch advertised. That's my favorite low-level primitive.
Bloch suggests using System.nanoTime in preference to System.currentTimeMillis for interval timing, because it's more accurate, more precise, and unaffected by system clock changes. I'd been using System.nanoTime in new code, but given that last advantage maybe it's time (ho ho) for a more thorough toilet-cleaning.
The book ends with a bunch of items on serialization, which was rather surprising to me. I haven't written a (deliberately, explicitly) serializable class in the last eight years. I don't know if that's because serialization isn't a mainstream thing, or because it was eight years ago that I last wrote Java (rather than C++) for a living. Maybe just behind some narrow door in all my favorite bars, Java programmers in red Pendleton shirts are getting incredible kicks from squirting serialized objects at each other. Who knows?
Every time I've touched Java serialization I've come away with the feeling that it's sufficiently broken in a sufficient number of ways that I'm better off just avoiding it. Gangrenous appendages eventually fall off of their own accord, don't they?
If you're a Java programmer, you ought to read this book. It's not going to be a life-changing experience for many. (If you find it is, you probably need to ask the best programmer you know to help mentor you.) This isn't as important a book for Java programmers as "Effective C++" is for C++ programmers. It's also not as important a book for Java programmers as are Goetz's or Wadler's recent books.
But you can't not have read it. Get work to buy a copy and hand it round as each of you finishes. You can read through it in a day, and quicker than that if you're familiar with the first edition and you've been writing (and reading) Java in the intervening years.
Desktop Linux suckage: Index
elliotth's blog - Thu, 25/09/2008 - 5:26am
Blogger makes it a pain to read a series if you weren't subscribed to the feed as the posts were made, so here's an index/table of contents for use as a jumping-off point:
(Thanks to Eric Bloodworth for suggesting adding an index. I should have thought of it myself after reading Ian Lance Taylor's series on linkers. Hint: the easiest way to read that series is to increment the number in the URL.)
Blogger makes it a pain to read a series if you weren't subscribed to the feed as the posts were made, so here's an index/table of contents for use as a jumping-off point:
- Introduction
- DNS Caching
- Window Management
- Preferences^WAdministration
- The Clipboard
- Evolution
- An Interlude
- Rhythmbox
- A Quick Exercise
- A Prime Example
- 10 years
- Where's our Steve Jobs
(Thanks to Eric Bloodworth for suggesting adding an index. I should have thought of it myself after reading Ian Lance Taylor's series on linkers. Hint: the easiest way to read that series is to increment the number in the URL.)
Desktop Linux suckage: where's our Steve Jobs?
elliotth's blog - Mon, 22/09/2008 - 8:44pm
[This is a long one, but it's the end of the series. Normal service will be resumed shortly.]
The article that prompted me to write these rants, "Why Free Software has poor usability, and how to improve it", failed to mention Linux's lack of a Steve Jobs. This is an important omission. The Linux kernel has its Steve Jobs. The question we have to ask ourselves is whether it's just a coincidence that the Linux kernel is the poster child for successful Free software.
What does the Linux desktop have? The Linux desktop has nothing. No person, not even a committee. Just the GNOME HIG.
I suggest you take a look at the GNOME HIG, in all its barely-changed-since-2001 glory. In particular, compare its breadth, depth, and quality to Apple's or even Microsoft's equivalents. You might think that the Apple and Microsoft guides go too far. Microsoft's one is especially long. But you could hardly argue that developers of GNOME applications are doing such a good job they don't need at least as much help as Mac and Windows developers. At least Apple and Microsoft seem to acknowledge the extent of the problem.
At least Apple and Microsoft seem to understand that developers need help: developers need better languages than C, developers need higher-level toolkits that do ever more of the stupid work that doesn't distinguish one application from another, and developers need documentation that helps them with the stuff that the toolkit can't. (Note the order in which I mention these things. There's significance to it.)
If you hang around Bugzilla enough, you'll start to notice "need direction from the HIG" as a polite way of saying "will not fix". You may as well rely on Santa Claus to buy your wife an anniversary gift as rely on the GNOME HIG being updated to reflect modern application trends.
Ideally, the HIG would be a strong document and there would be libraries that made it easier to write good applications than to write bad ones, and we'd be using a language well-suited both to that library, and to application development in general.
What we actually have is the GNOME HIG, GTK+, and C. Oops.
For the Linux desktop developer, everything is such hard work that it's not hard to see why no-one ever gets round to the all-important polish. Or why no-one has the agility to experiment until they get their UI right, rather than slapping together the first thing they think of, getting it half working, and being too scared to touch the tower of cards lest it topple before their eyes.
Do Mac programmers have the same problem? No. Quite the opposite. Cocoa does all the stupid crap for them, so instead of everyone writing their own code to save and restore window position (et cetera) programmers and users can just take that basic stuff for granted, and spend development time on the stuff relevant to their application. Their language is their weakest link, being Objective C, but since its major problem is that, when Cocoa doesn't already offer what you need, you end up falling back to C, it's obvious that that's a net win compared to the usual GNOME situation. Objective C also recently gained garbage collection. GNOME has a weak toolkit (GTK+) and a hopeless revenant language (C).
There are GTK+ bindings to other languages, but in my experience, they're fragile, incomplete, outdated, and/or unsupported. The three serious contenders for an alternative to C, namely C++, C#, and Java, are probably all too politically contentious to succeed without causing serious upset. (The amusing part being that most of the "C++ is too complicated", "C# is too evil/case-insensitive/Microsoft-encumbered", "Java is too slow" crap is likely to come from people wholly uninvolved in, and probably incapable of, writing software). I'm hoping OpenJDK might improve matters here, but you'll forgive me if I don't risk holding my breath.
I realizing I've been ignoring KDE (based on Qt and C++), but they're just a somewhat better implementation of an orthogonally awful philosophy. "Treat your users like technology fetishists who want to piss away their lives fiddling with myriad options in an effort to tease out a half-decent combination of settings" in contrast to GNOME's "treat your users like irrelevant cretins".
I do try KDE every few years, but it just brings out some kind of visceral disgust in me, without even the morbid curiosity that, say, a dentist's book of pictures of tooth decay and gum disease can bring out.
And I still refuse to believe that "offer a preference for everything anyone can come up with" is a responsible response to the design problem. I'd rather have a bunch of alternative applications each with their own coherent philosophy than a stinking pile of compromise. Though I have to wonder whether experience isn't trying to teach us that a stinking pile of compromise is all we can hope for from a Free desktop.
The fact that the situation is so much better for developers on other platforms is a reason to take issue with the article's title: "Why Free Software has poor usability, and how to improve it". When it says "Free software" it primarily means "Free software on Linux". Free software badly ported to the Mac sucks too, but that's just Linux exporting Linux's problems, not a problem with Free per se. Free software written by Mac developers for the Mac tends to suck a whole lot less than Free software written by Linux developers.
Did the developers of Adium (a Mac IM client) ever make a change so unpopular with their users, and have the cheek to tell their users that they were wrong to want the feature, causing a fork? No. But this actually happened on Linux: Slashdot: Pidgin Controversy Triggers Fork.
Vienna, a Free RSS reader for Mac OS, has a nice UI; admittedly not quite as good as its closed-source counterpart NetNewsWire, but still better than any Linux equivalent. TeXShop is a really nice front-end to TeX. Apple gives out Apple Design Awards to the Free (or at least OSS) Mac software, and not in any kind of sarcastic way. There exist Free applications for the Mac that are good in their own right.
The fact that all Mac developers are using the same high-quality toolkit directly influences Free Mac app quality, as does the better default choice of application implementation language. The fact that Mac developers can't help but be exposed to large numbers of other apps with high-quality UIs, setting a good example ("a higher bar", in the parlance of our times) has a direct influence on Free Mac app quality.
Seriously, suppose you'd only ever used Linux. Just how high would your standards be?
Which isn't to say that all Free Linux apps suck, or all Free Mac apps rock. But it does help to explain why most Free Linux apps are way down the "suck" end.
The fact that I bring up RSS, and the awfulness of Linux desktop RSS readers, brings me to a final concern. Linux desktop applications are so bad that they push people towards web apps. Which is possibly good for the users, but it's not good for the Linux desktop. And, in a way, I don't think a world of only web apps would be good for web apps; today's web apps are as good as they are because they've been striving to compete with desktop apps on desktop apps' terms (irrespective of the locational transparency, availability/backup/disaster recovery, and other "natural" advantages of web apps).
Driving everything onto the web would be one way to claim victory in terms of Linux desktop usability, of course. All you'd need is a browser, and Firefox is already pretty good.
I'd love to believe we can see things through, but I'm not even convinced we're moving in the right direction. Or any direction. Maybe we're just going round in circles. Certainly these arguments, the points made, the examples given, all sound very familiar.
As I said at the beginning of this series, I've had a Linux desktop, on and off, since about 1997. I've had a Unix desktop, in one form or another, since 1993. I even wrote my own window manager in my youth, when I too had more free time than sense. Assuming that Mosaic was an acceptable browser for the web as it was back in 1993, have we really made any progress on the (non-Mac) Unix desktop? As much progress as Apple or Microsoft has made? You could argue that Indigo Magic (SGI's desktop in 1993) or NeXTStep weren't as Free as what we have now, which is true. Or that both of those Unix desktops were way ahead of contemporary versions of Mac OS and Windows, which is also true (if you ignore availability of applications). But still, the main way in which I feel better off in 2008 than 1993 is that I have a bigger display with more colors. And that's not exactly thanks to better software.
Maybe some day, Mark Shuttleworth will turn up to work and say "I'm sick of all this pointless ugly Compiz crap and having to pretend in interviews that I sincerely think Compiz is in any way 'better' than or even remotely related to what Apple has, or even a sensible thing to pay any attention to. I understand now that transparency or wobbliness or shadows isn't what makes a good desktop: good apps make a good desktop, and from now on we're only going to stick apps on the Ubuntu menu if I can honestly stand in front of a non-fanboy audience and say 'this app works, and works well' and not be jeered off stage; in fact, I'm going to start kicking the worst ones off the menu unless they shape up, and we'll roll up our sleeves and fix the least worst, based on the rulings of a benevolent UI dictator".
And even supposing this happens, where would Shuttleworth find himself a suitable dictator? As the Pidgin developers inadvertently demonstrated, it's hard to find a benevolent dictator in a world of anarchic zealots. Maybe as hard as it is to find an honest politician in the real world.
And even assuming we had a way to be sure we were moving in a positive direction, our tools aren't the kind that help us move fast.
Honestly, I see no end in sight. Gruber's article will be as relevant in 2012, Thomas will write the third version of his article in 2014, and I'll still need a Mac as a crutch for my Linux box on the day I retire.
[This is a long one, but it's the end of the series. Normal service will be resumed shortly.]
The article that prompted me to write these rants, "Why Free Software has poor usability, and how to improve it", failed to mention Linux's lack of a Steve Jobs. This is an important omission. The Linux kernel has its Steve Jobs. The question we have to ask ourselves is whether it's just a coincidence that the Linux kernel is the poster child for successful Free software.
What does the Linux desktop have? The Linux desktop has nothing. No person, not even a committee. Just the GNOME HIG.
I suggest you take a look at the GNOME HIG, in all its barely-changed-since-2001 glory. In particular, compare its breadth, depth, and quality to Apple's or even Microsoft's equivalents. You might think that the Apple and Microsoft guides go too far. Microsoft's one is especially long. But you could hardly argue that developers of GNOME applications are doing such a good job they don't need at least as much help as Mac and Windows developers. At least Apple and Microsoft seem to acknowledge the extent of the problem.
At least Apple and Microsoft seem to understand that developers need help: developers need better languages than C, developers need higher-level toolkits that do ever more of the stupid work that doesn't distinguish one application from another, and developers need documentation that helps them with the stuff that the toolkit can't. (Note the order in which I mention these things. There's significance to it.)
If you hang around Bugzilla enough, you'll start to notice "need direction from the HIG" as a polite way of saying "will not fix". You may as well rely on Santa Claus to buy your wife an anniversary gift as rely on the GNOME HIG being updated to reflect modern application trends.
Ideally, the HIG would be a strong document and there would be libraries that made it easier to write good applications than to write bad ones, and we'd be using a language well-suited both to that library, and to application development in general.
What we actually have is the GNOME HIG, GTK+, and C. Oops.
For the Linux desktop developer, everything is such hard work that it's not hard to see why no-one ever gets round to the all-important polish. Or why no-one has the agility to experiment until they get their UI right, rather than slapping together the first thing they think of, getting it half working, and being too scared to touch the tower of cards lest it topple before their eyes.
Do Mac programmers have the same problem? No. Quite the opposite. Cocoa does all the stupid crap for them, so instead of everyone writing their own code to save and restore window position (et cetera) programmers and users can just take that basic stuff for granted, and spend development time on the stuff relevant to their application. Their language is their weakest link, being Objective C, but since its major problem is that, when Cocoa doesn't already offer what you need, you end up falling back to C, it's obvious that that's a net win compared to the usual GNOME situation. Objective C also recently gained garbage collection. GNOME has a weak toolkit (GTK+) and a hopeless revenant language (C).
There are GTK+ bindings to other languages, but in my experience, they're fragile, incomplete, outdated, and/or unsupported. The three serious contenders for an alternative to C, namely C++, C#, and Java, are probably all too politically contentious to succeed without causing serious upset. (The amusing part being that most of the "C++ is too complicated", "C# is too evil/case-insensitive/Microsoft-encumbered", "Java is too slow" crap is likely to come from people wholly uninvolved in, and probably incapable of, writing software). I'm hoping OpenJDK might improve matters here, but you'll forgive me if I don't risk holding my breath.
I realizing I've been ignoring KDE (based on Qt and C++), but they're just a somewhat better implementation of an orthogonally awful philosophy. "Treat your users like technology fetishists who want to piss away their lives fiddling with myriad options in an effort to tease out a half-decent combination of settings" in contrast to GNOME's "treat your users like irrelevant cretins".
I do try KDE every few years, but it just brings out some kind of visceral disgust in me, without even the morbid curiosity that, say, a dentist's book of pictures of tooth decay and gum disease can bring out.
And I still refuse to believe that "offer a preference for everything anyone can come up with" is a responsible response to the design problem. I'd rather have a bunch of alternative applications each with their own coherent philosophy than a stinking pile of compromise. Though I have to wonder whether experience isn't trying to teach us that a stinking pile of compromise is all we can hope for from a Free desktop.
The fact that the situation is so much better for developers on other platforms is a reason to take issue with the article's title: "Why Free Software has poor usability, and how to improve it". When it says "Free software" it primarily means "Free software on Linux". Free software badly ported to the Mac sucks too, but that's just Linux exporting Linux's problems, not a problem with Free per se. Free software written by Mac developers for the Mac tends to suck a whole lot less than Free software written by Linux developers.
Did the developers of Adium (a Mac IM client) ever make a change so unpopular with their users, and have the cheek to tell their users that they were wrong to want the feature, causing a fork? No. But this actually happened on Linux: Slashdot: Pidgin Controversy Triggers Fork.
Vienna, a Free RSS reader for Mac OS, has a nice UI; admittedly not quite as good as its closed-source counterpart NetNewsWire, but still better than any Linux equivalent. TeXShop is a really nice front-end to TeX. Apple gives out Apple Design Awards to the Free (or at least OSS) Mac software, and not in any kind of sarcastic way. There exist Free applications for the Mac that are good in their own right.
The fact that all Mac developers are using the same high-quality toolkit directly influences Free Mac app quality, as does the better default choice of application implementation language. The fact that Mac developers can't help but be exposed to large numbers of other apps with high-quality UIs, setting a good example ("a higher bar", in the parlance of our times) has a direct influence on Free Mac app quality.
Seriously, suppose you'd only ever used Linux. Just how high would your standards be?
Which isn't to say that all Free Linux apps suck, or all Free Mac apps rock. But it does help to explain why most Free Linux apps are way down the "suck" end.
The fact that I bring up RSS, and the awfulness of Linux desktop RSS readers, brings me to a final concern. Linux desktop applications are so bad that they push people towards web apps. Which is possibly good for the users, but it's not good for the Linux desktop. And, in a way, I don't think a world of only web apps would be good for web apps; today's web apps are as good as they are because they've been striving to compete with desktop apps on desktop apps' terms (irrespective of the locational transparency, availability/backup/disaster recovery, and other "natural" advantages of web apps).
Driving everything onto the web would be one way to claim victory in terms of Linux desktop usability, of course. All you'd need is a browser, and Firefox is already pretty good.
I'd love to believe we can see things through, but I'm not even convinced we're moving in the right direction. Or any direction. Maybe we're just going round in circles. Certainly these arguments, the points made, the examples given, all sound very familiar.
As I said at the beginning of this series, I've had a Linux desktop, on and off, since about 1997. I've had a Unix desktop, in one form or another, since 1993. I even wrote my own window manager in my youth, when I too had more free time than sense. Assuming that Mosaic was an acceptable browser for the web as it was back in 1993, have we really made any progress on the (non-Mac) Unix desktop? As much progress as Apple or Microsoft has made? You could argue that Indigo Magic (SGI's desktop in 1993) or NeXTStep weren't as Free as what we have now, which is true. Or that both of those Unix desktops were way ahead of contemporary versions of Mac OS and Windows, which is also true (if you ignore availability of applications). But still, the main way in which I feel better off in 2008 than 1993 is that I have a bigger display with more colors. And that's not exactly thanks to better software.
Maybe some day, Mark Shuttleworth will turn up to work and say "I'm sick of all this pointless ugly Compiz crap and having to pretend in interviews that I sincerely think Compiz is in any way 'better' than or even remotely related to what Apple has, or even a sensible thing to pay any attention to. I understand now that transparency or wobbliness or shadows isn't what makes a good desktop: good apps make a good desktop, and from now on we're only going to stick apps on the Ubuntu menu if I can honestly stand in front of a non-fanboy audience and say 'this app works, and works well' and not be jeered off stage; in fact, I'm going to start kicking the worst ones off the menu unless they shape up, and we'll roll up our sleeves and fix the least worst, based on the rulings of a benevolent UI dictator".
And even supposing this happens, where would Shuttleworth find himself a suitable dictator? As the Pidgin developers inadvertently demonstrated, it's hard to find a benevolent dictator in a world of anarchic zealots. Maybe as hard as it is to find an honest politician in the real world.
And even assuming we had a way to be sure we were moving in a positive direction, our tools aren't the kind that help us move fast.
Honestly, I see no end in sight. Gruber's article will be as relevant in 2012, Thomas will write the third version of his article in 2014, and I'll still need a Mac as a crutch for my Linux box on the day I retire.
Desktop Linux suckage: 10 years
elliotth's blog - Sun, 21/09/2008 - 6:11am
I often mention Joel Spolsky's article Good Software Takes Ten Years. Get Used To It. It's one of the best things he's ever written. One thing Joel doesn't promise in that article (or any other) is that the ten years it takes to create good software will be ten years of fun. He doesn't promise ten years of interesting code or ten years of great new features. Quite the opposite, in fact.
Most of your ten years will be spent on problems with Danish keyboards on Mac OS 10.3, or fonts on the Thai version of Windows 98, or some bug in some IMAP server that this one guy in Kabul sometimes has to connect to, or just making your error messages clearer, more specific, and more focused on helping the user fix their problem.
One of the big things that Joel explicitly states, because he has to, is that contrary to what we leave university thinking, these "hacks" are the most important bits of code we write. They aren't nasty bits of cruft that we should be marching out into the world to do away with, in order to make the world a better place. They're nasty bits of cruft that we're marching out into the world to add, in order to make the world a better place. They make stuff "just work", even though the hardware's broken. They make stuff "just work", even though the software they have to interact with is broken. They make stuff "just work" for most users because making 80% of your users happy is better than waiting for the perfect solution to come along and making no-one happy in the meantime.
The real world is full of lossage. The very phrase "real world" is practically defined by an admission of the existence of lossage. Industrial quantities of the stuff. But the academics mislead us, wanting to reshape us in their own image, and would have us believe that what the world needs is more beautiful theories and, maybe (and only if you can do it without getting your hands dirty) a partial implementation of the beautiful theory. They can only say this with a straight face because they are, at heart, ascetics. That's why they're in universities, for dog's sake. I'm not specifically talking about desktops right now, but their idea of a desktop is probably a single copy of vi running in a single XTerm, where they're editing some 10-line Haskell program with really clever puns in all the function names.
The presence of puns and absence of side-effects is what passes for quality in their world.
By the time we realize these people were lying, or deluded, or naive, or whatever, it's usually too late. We're too busy to give people what they want or need for free any more, so the Linux world has to make do with what our younger selves thought people ought to want. A hundred half-finished flying machines and not one working toilet.
Welcome to paradise. You might want to consider getting constipated.
There's a picture in Apple's HIG, in the section Prioritizing Design Decisions. I'll describe the picture in case the link breaks, or you just can't be bothered to follow it. The picture shows three blocks stacked atop each other. The largest block, on the bottom, is "Minimum Requirements". The next block up, somewhat smaller, is "Features users expect". The top, smallest, block is "Differentiation". The idea being that you start with the big block on the bottom, and work your way up.
Again, no genius. No "rocket science". Just common sense and good engineering. (If you actually read that chapter of Apple's HIG, you'll find that what they're actually talking about is very pedestrian stuff indeed. But at least it's an ethos.)
Problem: Linux desktop apps don't care about "Features users expect" or "Minimum requirements" at all. They may offer some "Differentiation", but not necessarily. Mostly, you just get "The bits that are fun to code".
I said Joel didn't promise the 10 years would be fun. There's something else he didn't promise. He didn't promise that 10 years would be sufficient. Necessary? Yes. Sufficient? Clearly not.
I often mention Joel Spolsky's article Good Software Takes Ten Years. Get Used To It. It's one of the best things he's ever written. One thing Joel doesn't promise in that article (or any other) is that the ten years it takes to create good software will be ten years of fun. He doesn't promise ten years of interesting code or ten years of great new features. Quite the opposite, in fact.
Most of your ten years will be spent on problems with Danish keyboards on Mac OS 10.3, or fonts on the Thai version of Windows 98, or some bug in some IMAP server that this one guy in Kabul sometimes has to connect to, or just making your error messages clearer, more specific, and more focused on helping the user fix their problem.
One of the big things that Joel explicitly states, because he has to, is that contrary to what we leave university thinking, these "hacks" are the most important bits of code we write. They aren't nasty bits of cruft that we should be marching out into the world to do away with, in order to make the world a better place. They're nasty bits of cruft that we're marching out into the world to add, in order to make the world a better place. They make stuff "just work", even though the hardware's broken. They make stuff "just work", even though the software they have to interact with is broken. They make stuff "just work" for most users because making 80% of your users happy is better than waiting for the perfect solution to come along and making no-one happy in the meantime.
The real world is full of lossage. The very phrase "real world" is practically defined by an admission of the existence of lossage. Industrial quantities of the stuff. But the academics mislead us, wanting to reshape us in their own image, and would have us believe that what the world needs is more beautiful theories and, maybe (and only if you can do it without getting your hands dirty) a partial implementation of the beautiful theory. They can only say this with a straight face because they are, at heart, ascetics. That's why they're in universities, for dog's sake. I'm not specifically talking about desktops right now, but their idea of a desktop is probably a single copy of vi running in a single XTerm, where they're editing some 10-line Haskell program with really clever puns in all the function names.
The presence of puns and absence of side-effects is what passes for quality in their world.
By the time we realize these people were lying, or deluded, or naive, or whatever, it's usually too late. We're too busy to give people what they want or need for free any more, so the Linux world has to make do with what our younger selves thought people ought to want. A hundred half-finished flying machines and not one working toilet.
Welcome to paradise. You might want to consider getting constipated.
There's a picture in Apple's HIG, in the section Prioritizing Design Decisions. I'll describe the picture in case the link breaks, or you just can't be bothered to follow it. The picture shows three blocks stacked atop each other. The largest block, on the bottom, is "Minimum Requirements". The next block up, somewhat smaller, is "Features users expect". The top, smallest, block is "Differentiation". The idea being that you start with the big block on the bottom, and work your way up.
Again, no genius. No "rocket science". Just common sense and good engineering. (If you actually read that chapter of Apple's HIG, you'll find that what they're actually talking about is very pedestrian stuff indeed. But at least it's an ethos.)
Problem: Linux desktop apps don't care about "Features users expect" or "Minimum requirements" at all. They may offer some "Differentiation", but not necessarily. Mostly, you just get "The bits that are fun to code".
I said Joel didn't promise the 10 years would be fun. There's something else he didn't promise. He didn't promise that 10 years would be sufficient. Necessary? Yes. Sufficient? Clearly not.
Desktop Linux suckage: a prime example
elliotth's blog - Tue, 16/09/2008 - 4:30am
I've said before that, in my experience, filing bugs with Ubuntu seems more effective than filing them upstream, and a while back I filed a minor bug against GDebi. GDebi is a GUI .deb package installer that's pretty cool: it effectively lets you click on a link to a .deb in Firefox and install that program all without touching the command-line. The bug was "Size" field in "Details" tab should show KiB units), an I included a patch, and got it accepted and applied as quickly as any bug relating to the Linux desktop I've ever filed.
If you follow that link now, you can see that someone's just pointed out that, no, when apt-get(1) says "kB" it's not lying, it's completely serious. A quick apt-get install and check of /var/cache/apt/archives suggests they're right, at least as far as reports of download size are concerned. (It's harder to measure installed size, but I've no reason to doubt the claim.)
What I do doubt is the sanity of the person who made this design decision in the first place.
And while I accept that my patch was incorrect, and GDebi now claims file sizes are KiB rather than the kB they actually are, I also doubt the sanity of the person who actually thinks we should display file sizes in kilobytes rather than kibibytes. (Especially considering Nautilus, the GNOME "file manager" does actually use KiB, even if it calls them "KB". Especially considering the recent class-action lawsuits against the drive manufacturers. But I'm preaching to the choir here.)
Any time I try to kid myself that one day we'll have a non-crap Linux desktop, what makes me lose hope is that the Linux desktop isn't the kind of place where stupidity gets fixed or even papered over. There's no-one in charge to tell people to get their act together, and everyone has their own agenda, and half of them ought to be in a padded cell with no access to a keyboard.
At the moment, we have a situation where some applications are using kilobytes, some are using kibibytes, and what these applications appear to be claiming to use may or may not correspond to what they're actually using. And all this breakage surrounds something that's trivial in every way. The home computer operating system I was using in the late 1980s had a library call that you gave a number of bytes to, and it gave you back a string to show the user. Those old guys weren't geniuses, they were just good engineers.
The Linux desktop has neither, and it's also lacking a benevolent dictator to at least herd the monkeys. Or whatever it is one does with monkeys, other than spank them.
It's not like we're talking about something as "hard" as globally respecting a date or time format preference. That's so far in the Linux desktop's future that at this rate, I might actually have retired before it happens.
I've said before that, in my experience, filing bugs with Ubuntu seems more effective than filing them upstream, and a while back I filed a minor bug against GDebi. GDebi is a GUI .deb package installer that's pretty cool: it effectively lets you click on a link to a .deb in Firefox and install that program all without touching the command-line. The bug was "Size" field in "Details" tab should show KiB units), an I included a patch, and got it accepted and applied as quickly as any bug relating to the Linux desktop I've ever filed.
If you follow that link now, you can see that someone's just pointed out that, no, when apt-get(1) says "kB" it's not lying, it's completely serious. A quick apt-get install and check of /var/cache/apt/archives suggests they're right, at least as far as reports of download size are concerned. (It's harder to measure installed size, but I've no reason to doubt the claim.)
What I do doubt is the sanity of the person who made this design decision in the first place.
And while I accept that my patch was incorrect, and GDebi now claims file sizes are KiB rather than the kB they actually are, I also doubt the sanity of the person who actually thinks we should display file sizes in kilobytes rather than kibibytes. (Especially considering Nautilus, the GNOME "file manager" does actually use KiB, even if it calls them "KB". Especially considering the recent class-action lawsuits against the drive manufacturers. But I'm preaching to the choir here.)
Any time I try to kid myself that one day we'll have a non-crap Linux desktop, what makes me lose hope is that the Linux desktop isn't the kind of place where stupidity gets fixed or even papered over. There's no-one in charge to tell people to get their act together, and everyone has their own agenda, and half of them ought to be in a padded cell with no access to a keyboard.
At the moment, we have a situation where some applications are using kilobytes, some are using kibibytes, and what these applications appear to be claiming to use may or may not correspond to what they're actually using. And all this breakage surrounds something that's trivial in every way. The home computer operating system I was using in the late 1980s had a library call that you gave a number of bytes to, and it gave you back a string to show the user. Those old guys weren't geniuses, they were just good engineers.
The Linux desktop has neither, and it's also lacking a benevolent dictator to at least herd the monkeys. Or whatever it is one does with monkeys, other than spank them.
It's not like we're talking about something as "hard" as globally respecting a date or time format preference. That's so far in the Linux desktop's future that at this rate, I might actually have retired before it happens.
Desktop Linux suckage: a quick exercise
elliotth's blog - Fri, 12/09/2008 - 8:39pm
One claim you'll sometimes hear is that, although Mac OS or Windows are better for stuff like word processing, spreadsheets, presentations, reading mail, drawing, painting, cataloging and touching up digital photographs, games, and all those other things that only real people do, Linux is best for hard-core nerdy shit.
Coincidentally, I just so happen to have a hard-core nerdy desire, one that, by this theory, Linux ought to do way better on than Mac OS? Yeah, it's an unscientific sample size, but it still might be instructive, and it's an actual question I want answered right now...
The problem
I want to know how many DIMM slots my motherboard has, and what DIMMs I have fitted.
Apple's solution
On the Mac, I click on the little Apple icon, I click "About this Mac...", I click "More Info..." and System Profiler starts, letting me see any detail about my system's hardware and software, including a convenient detailed display what DIMMs are in which slots. It even lets me save a handy .txt summary for inclusion in bug reports and the like.
Linux's solution
On Ubuntu, on the best-avoided crock that is the "System" menu, I have both "About Ubuntu" and "About GNOME". Neither contains a single piece of useful information. System Monitor, which I always have running because I like visual feedback telling me whether my computer's actually busy, waiting for I/O, or just ignoring me, has recently grown a perfunctory summary of my hardware that's not really useful yet. Maybe it'll improve, but I'd rather see a useful "About" menu item rather than rely on a panel applet that isn't there by default. If I go to someone else's system, I don't want to have to start installing stuff to help answer their simple hardware questions.
So I start a terminal and cat /proc/meminfo, but the information there is too high-level for my present purposes. I tab-complete on "ls", thinking there might be some equivalent of lspci(1), but the promising-looking lshw(1) is another dead-end, telling me only the total amount of memory fitted. Okay, screw guessing about on the command line. I know there is a command, because I've used it before, but I can't remember it, and I was supposed to be using the desktop anyway.
I start Firefox and search the web for "dimm equivalent of lspci" and a few variations before I stumble on "lspci ram" on Yahoo (I never did find anything relevant via Google, even with the search string that works with Yahoo). This gets me a handy Gentoo page (naturally) Detecting your Hardware which suggests hardinfo(1) which, once installed, gives me a GUI which is indeed pretty similar to the Mac's System Profiler. The memory information, though, is /proc/meminfo in a GTK+ text area. The authors seem to have been more interested in benchmarking than hardware inventory. I mutter something about Gentoo users, uninstall, and go back to searching.
The only other GUI I found was sysinfo(1) which was almost like someone's joke entry in a "worst ever Linux software" competition. When it starts, the UI is animated, but doesn't actually show anything that has any meaning. There's a preference dialog, mostly taken up with a preference to turn off the pointless start-up animation. (And don't get too excited by my use of the word "animation". I use it in the loosest possible sense. Think of Windows XP's lame bouncing arrow pointing to the "Start" button.)
sysinfo's status bar constantly shows the date (in some random localized time format that I certainly never asked for). If you expectantly click on "Memory" in the list of options (decorated for some obscure reason with the icon usually reserved for copy-to-clipboard menu items), you see two sliders showing the free/used fraction of "Memory" and "Swap". There's a hopeful-looking disclosure triangle labeled "More details", but that just shows "Cached", "Active", and "Inactive", which I know by now are just the next three lines of /proc/meminfo. Looking to see who was responsible for this travesty, I noticed that the Close button in the about box doesn't work, which I thought was a particularly nice finishing touch to the encounter.
Failure
At this point, I resigned myself to either not knowing what DIMMs I have fitted, or opening the case to take a look.
I don't present this anecdote with any particular interpretation in mind, nor because the specific example is particularly representative, but it should at least serve as a warning to anyone foolish enough to think that "at least Linux is okay for the nerdy stuff". No, it's really crap there too. We have too many half-baked attempts at writing the same few things, and almost nothing that's followed through to a useful "shippable" point.
We're stuck with our 1980s XTerms and our 1970s Emacs/Vim (or our IDEs written by people paid to work on them by commercial vendors) and our compiler, which alongside the Linux kernel is one of our few real successes. Like the Linux kernel, though, many commercial vendors pay people to work full-time on it. We kid ourselves if we think that these are fruits of the "community" of bedroom hackers. Those are the people churning out the the half-baked "utilities" that had more time spent on their about box and their start-up animation than on their usefulness or usability.
On the internet, no-one knows you're 14 year old or a raccoon. Until they use your software.
One claim you'll sometimes hear is that, although Mac OS or Windows are better for stuff like word processing, spreadsheets, presentations, reading mail, drawing, painting, cataloging and touching up digital photographs, games, and all those other things that only real people do, Linux is best for hard-core nerdy shit.
Coincidentally, I just so happen to have a hard-core nerdy desire, one that, by this theory, Linux ought to do way better on than Mac OS? Yeah, it's an unscientific sample size, but it still might be instructive, and it's an actual question I want answered right now...
The problem
I want to know how many DIMM slots my motherboard has, and what DIMMs I have fitted.
Apple's solution
On the Mac, I click on the little Apple icon, I click "About this Mac...", I click "More Info..." and System Profiler starts, letting me see any detail about my system's hardware and software, including a convenient detailed display what DIMMs are in which slots. It even lets me save a handy .txt summary for inclusion in bug reports and the like.
Linux's solution
On Ubuntu, on the best-avoided crock that is the "System" menu, I have both "About Ubuntu" and "About GNOME". Neither contains a single piece of useful information. System Monitor, which I always have running because I like visual feedback telling me whether my computer's actually busy, waiting for I/O, or just ignoring me, has recently grown a perfunctory summary of my hardware that's not really useful yet. Maybe it'll improve, but I'd rather see a useful "About" menu item rather than rely on a panel applet that isn't there by default. If I go to someone else's system, I don't want to have to start installing stuff to help answer their simple hardware questions.
So I start a terminal and cat /proc/meminfo, but the information there is too high-level for my present purposes. I tab-complete on "ls", thinking there might be some equivalent of lspci(1), but the promising-looking lshw(1) is another dead-end, telling me only the total amount of memory fitted. Okay, screw guessing about on the command line. I know there is a command, because I've used it before, but I can't remember it, and I was supposed to be using the desktop anyway.
I start Firefox and search the web for "dimm equivalent of lspci" and a few variations before I stumble on "lspci ram" on Yahoo (I never did find anything relevant via Google, even with the search string that works with Yahoo). This gets me a handy Gentoo page (naturally) Detecting your Hardware which suggests hardinfo(1) which, once installed, gives me a GUI which is indeed pretty similar to the Mac's System Profiler. The memory information, though, is /proc/meminfo in a GTK+ text area. The authors seem to have been more interested in benchmarking than hardware inventory. I mutter something about Gentoo users, uninstall, and go back to searching.
The only other GUI I found was sysinfo(1) which was almost like someone's joke entry in a "worst ever Linux software" competition. When it starts, the UI is animated, but doesn't actually show anything that has any meaning. There's a preference dialog, mostly taken up with a preference to turn off the pointless start-up animation. (And don't get too excited by my use of the word "animation". I use it in the loosest possible sense. Think of Windows XP's lame bouncing arrow pointing to the "Start" button.)
sysinfo's status bar constantly shows the date (in some random localized time format that I certainly never asked for). If you expectantly click on "Memory" in the list of options (decorated for some obscure reason with the icon usually reserved for copy-to-clipboard menu items), you see two sliders showing the free/used fraction of "Memory" and "Swap". There's a hopeful-looking disclosure triangle labeled "More details", but that just shows "Cached", "Active", and "Inactive", which I know by now are just the next three lines of /proc/meminfo. Looking to see who was responsible for this travesty, I noticed that the Close button in the about box doesn't work, which I thought was a particularly nice finishing touch to the encounter.
Failure
At this point, I resigned myself to either not knowing what DIMMs I have fitted, or opening the case to take a look.
I don't present this anecdote with any particular interpretation in mind, nor because the specific example is particularly representative, but it should at least serve as a warning to anyone foolish enough to think that "at least Linux is okay for the nerdy stuff". No, it's really crap there too. We have too many half-baked attempts at writing the same few things, and almost nothing that's followed through to a useful "shippable" point.
We're stuck with our 1980s XTerms and our 1970s Emacs/Vim (or our IDEs written by people paid to work on them by commercial vendors) and our compiler, which alongside the Linux kernel is one of our few real successes. Like the Linux kernel, though, many commercial vendors pay people to work full-time on it. We kid ourselves if we think that these are fruits of the "community" of bedroom hackers. Those are the people churning out the the half-baked "utilities" that had more time spent on their about box and their start-up animation than on their usefulness or usability.
On the internet, no-one knows you're 14 year old or a raccoon. Until they use your software.
Desktop Linux suckage: Rhythmbox
elliotth's blog - Sat, 30/08/2008 - 8:31pm
Less important than a web browser, but probably next on the list of mainstream fundamentals is a music player. It's the only other thing I run daily that I haven't already mentioned. Even handy stuff like Wireshark (which gets an exemption from criticism in this series because it's by nerds for nerds) only gets run once a week.
I've said in the past that Rhythmbox is okay, but that was before I was using it as my only mp3 player, rather than as an occasional stand-in. In practice, well, it has a large number of small but annoying flaws. I'm not going to mention them all here. Just a representative sample.
Let's start near the top of the UI: Rhythmbox uses a slider to show how far through the current track you are. This has the annoying consequence that your clicks are interpreted as meaning "move one 'page' in the direction of the mouse", rather than "move to the time corresponding to the location of the mouse". This is completely useless; it might make some sense if clicking to the left of the knob meant "back 10s" and to the right meant "forward 10s", but the time skipped being proportional to the length of the track makes it useless.
I could ignore the fact that a standard slider looks wrong, but it's hard to ignore that it feels wrong. Only, this being the Linux desktop, it gets worse. For some reason, if you actually try to drag the slider, it has a habit of locking up playback. The work-around seems to be to switch to another track, and then switch back, and start playing from the beginning, having learned your lesson. Absolute positioning in the track just doesn't work, so the lesson is "don't touch the slider". Awesome. Anything that works that badly should probably just be left out of the interface until the first version where it actually works. Not having the option of spoiling playback and annoyed by a control that doesn't move how I want it to would be less distressing than just not having any pretend control at all. (GNOME bug 437987 and GNOME bug 445764 may be this.)
An alternative improvement would be to disable the slider, making it evident that it's only useful for showing how far through the track I am. (Funnily enough, I found a bug suggesting that the slider be made worse rather than better: GNOME bug 389170.)
An annoyance that's interesting for what it says about how Linux lowers one's expectations is that there's no visible suggestion that the "media keys" on the keyboard work, and I consider that a problem. The stupidly large toolbar (GNOME bug 343660) and the menu mention the more awkward keyboard equivalents; stuff like alt-space for playback (an annoying difference from iTunes' unmodified space, for no obvious reason, even though unmodified space isn't taken and would make iTunes refugees feel more at home at no cost to anyone else), but there's no suggestion of the media keys.
I realize it's deeply sad that I can't just assume they work, but this is Linux, and it wasn't many releases ago they didn't work. And it's worth bearing in mind that I had to write a custom rc.local script to get my keyboard to work at all with Ubuntu 8.04! (I actually installed KDE and tried amaroK, and note that my media keys don't work there.)
The search field is in the wrong place, too. Where do search fields go? In the top-right of your window. I've made this UI mistake myself in the past, but it's a well established convention now. Firefox uses it (for searching the web, rather than the current document), as does Safari. iTunes uses it. Ubuntu's Add/Remove Applications uses it and Ubuntu's help browser uses it. Microsoft's developer documentation for Vista explicitly says "thou shalt". But Rhythmbox just kind of hides it in the middle of a bunch of other UI clutter.
(GTK+ apps in general make very poor use of empty space; the widgets seem to enforce large amounts of arbitrarily wasted space around themselves, and developers seem, perhaps in reaction to this, to use it only rarely in ways that actually help convey meaning. Mac developers tend to be best at this, perhaps because Apple over-exaggerated in early versions of Mac OS X to get the point across. Good Mac apps tend to have far fewer controls and preferences, of course, which gives developers more room to play with.)
Did I mention that the window manager's stupid "top-left corner" behavior is exacerbated by Rhythmbox not explicitly repositioning itself where it was last? GNOME bug 502827. (Sad, of course, that individual applications need to work around systemic lameness, but remembering your last window position is a good basic feature to have anyway.)
There's advertising in the UI, too. In the latest version, two net music stores have appeared. I thought one advantage of not using iTunes would be to not suffer that crap, but I was wrong. To be fair, judging by the text that disappears before you have chance to read it (and how do you get it back?), Jamendo is actually a "store" for Free music; Magnatune not. But it's unclear, and feels like thin ice that really needs better explanation. Unlike iTunes, the "stores" aren't very store-like, either. They look just like your normal music collection, which isn't a very accessible way to browse unfamiliar music.
But what drives me mad the most (worse than even the slider) is the overall window behavior. When you start Rhythmbox, an icon appears in the top panel, which generally signifies some kind of "background" application; the kind of application whose window you can close without thereby quitting the application, because you can click the panel icon to get the window back. But no, clicking the close icon quits Rhythmbox. No more music. You can click the window's minimize button, but that still wastes space in the list of windows at the bottom of the screen.
You can get better behavior by clicking on the panel icon, funnily enough. If the window is visible, clicking the panel icon (somewhat bizarrely, and with visual feedback to emphasize the idea) minimizes the window "into" the panel. Clicking again re-opens the window, as you'd expect. But if you've just been fiddling in the window, which you probably have if the window's visible, you're focus is on the window and your pointer is in the window. Nowhere near the panel icon. So it's way more convenient to close the window, but closing the window, despite the existence of the panel icon, quits Rhythmbox and stops the music. This is GNOME bug 158168 from 2004, which the developers don't think is a bug.
It would appear from GNOME bug 523072 as if Rhythmbox is equally evil if you're ripping a CD at the time. I can imagine that's even more annoying!
I came up with a patch, ran a patched version for a few weeks, and was much happier. But what's the use of a patch when the developers think the current behavior is not just acceptable, but good? The fanboys who say "patches welcome" whenever someone complains miss the point; patching is necessary but not sufficient. Realistically, you probably have to fork, and get your distribution to package your fork instead. And that's not something you can do on a feature-by-feature basis. You could try to file the bug against your favorite distribution instead, and put the maintenance burden onto the package manager, but that really doesn't seem like a healthy way forward.
Am I really destined to end up running Gentoo? Building everything from source and applying my own little set of patches on my local machine? I think I'd rather buy a Zune.
At this point, I should be honest and point out that I simply don't know what iTunes does if you close its window. Mac OS solves the underlying problem in a more fundamental way: command-h gets any application out of my face in a single keystroke. (My complaint there is that, by default, there's no visual indication that an application is hidden, which I find confusing, especially in combination with the way Mac OS' dock shows some non-running applications too. There's a hidden preference to fix that, though, and it's about the only bit of manual configuration I have to do on a new Mac.) It would be great for Linux to have a similar system-wide fix, but this is Linux, so there's no "system" (hell, there's a whole other desktop I haven't mentioned that's the default in some distributions, and there's a third semi-popular one), and Linux has no Steve Jobs insisting that stuff is not allowed to suck.
[I am reliably informed that iTunes does the right thing. Imagine my surprise.]
So given all those Linuxy lemons, you'd be well advised to have your application know how to make tasty lemonade.
Did I mention that Rhythmbox never remembers its window location? This isn't just a problem if you quit and re-start. It's a problem if you click the panel icon twice to hide and then re-show the main window, because that resets the window position to the top-left. Seriously.
Did I mention that if you quit Rhythmbox (which, as I've said, is easier to do by accident than it ought to be) it forgets what you were playing? I'm not asking for fancy stuff like remembering scroll bar positions and search field contents and multiple selections and the like: just remember which track was playing last, please!
Did I mention that the mis-positioned search field isn't activated if you use control-f (or, if you think of it more like Firefox's "Web Search", control-k)? The former does nothing (unless focus is already in a component that has some default behavior for the keystroke), while the latter is "Play Queue as Side Pane". I'm not sure, but I don't think "Play" is a verb in that sentence.
Did I mention that canceling the search field doesn't keep the currently-playing track visible in the table? I realize the "right" behavior is pretty hard to specify if you want to cover all the special cases, but there's value in doing the right thing in the most common case.
Don't get me wrong: I actually quite like Rhythmbox. It's almost good. And I do think it's a case where a bit of "ronco spray-on usability" could make the difference. I bring this up because I don't want people to think that there isn't low-hanging fruit out there. The little panel icon? It's great. I love its little notifications when the track changes, and I love that I can turn it off if I want, and I love that I turn it off in the place where it appears. All nicely done. I want to use it more, and I want Rhythmbox to stop coming across as if it thinks it's the most important app on my desktop, when 99% of the time that little panel icon is all I need to see. If listening to music were my primary occupation, I wouldn't be running Rhythmbox on Linux; I'd be running the iPod software on an iPod.
But back to my patch. My experience has been that, contrary to what you might imagine, sending patches to the most-upstream source doesn't work well. Perhaps because most of my patches fix things so obviously broken that the only reason the patch is needed is because the developers are either actively hostile towards, or simply indifferent to, their users. The distributions tend to be a better place to go. Sure, they apply patches that make your SSH insecure (Debian) or your Perl slow (RedHat), but at least they get things done.
Anyway, I went to launchpad, Ubuntu's bug database. And I found Bug #38512 in Rhythmbox: "Window close should close, not quit". Reading that bug's comments we learn a great many things. I could summarize the thread, but really it's so educational I think everyone who's interested in the state of the Linux desktop should read the whole thread themselves.
I'll wait.
If, having read that thread, you want to see the alluded-to tantrum by one of the upstream developers, you should read the upstream bug Bug 318629 - Option to minimize to tray on close or minimize (rhythmbox). (Note that a developer calls a user a "dick" before a user calls a developer a "dick".)
Everything that's wrong with the Linux desktop is beautifully illustrated in those two bug reports.
Problem: everyone wants users until they've got them. When they've got them, they want to reshape them into their own image. When that fails, as it always will, they begin to hate their users.
Less important than a web browser, but probably next on the list of mainstream fundamentals is a music player. It's the only other thing I run daily that I haven't already mentioned. Even handy stuff like Wireshark (which gets an exemption from criticism in this series because it's by nerds for nerds) only gets run once a week.
I've said in the past that Rhythmbox is okay, but that was before I was using it as my only mp3 player, rather than as an occasional stand-in. In practice, well, it has a large number of small but annoying flaws. I'm not going to mention them all here. Just a representative sample.
Let's start near the top of the UI: Rhythmbox uses a slider to show how far through the current track you are. This has the annoying consequence that your clicks are interpreted as meaning "move one 'page' in the direction of the mouse", rather than "move to the time corresponding to the location of the mouse". This is completely useless; it might make some sense if clicking to the left of the knob meant "back 10s" and to the right meant "forward 10s", but the time skipped being proportional to the length of the track makes it useless.
I could ignore the fact that a standard slider looks wrong, but it's hard to ignore that it feels wrong. Only, this being the Linux desktop, it gets worse. For some reason, if you actually try to drag the slider, it has a habit of locking up playback. The work-around seems to be to switch to another track, and then switch back, and start playing from the beginning, having learned your lesson. Absolute positioning in the track just doesn't work, so the lesson is "don't touch the slider". Awesome. Anything that works that badly should probably just be left out of the interface until the first version where it actually works. Not having the option of spoiling playback and annoyed by a control that doesn't move how I want it to would be less distressing than just not having any pretend control at all. (GNOME bug 437987 and GNOME bug 445764 may be this.)
An alternative improvement would be to disable the slider, making it evident that it's only useful for showing how far through the track I am. (Funnily enough, I found a bug suggesting that the slider be made worse rather than better: GNOME bug 389170.)
An annoyance that's interesting for what it says about how Linux lowers one's expectations is that there's no visible suggestion that the "media keys" on the keyboard work, and I consider that a problem. The stupidly large toolbar (GNOME bug 343660) and the menu mention the more awkward keyboard equivalents; stuff like alt-space for playback (an annoying difference from iTunes' unmodified space, for no obvious reason, even though unmodified space isn't taken and would make iTunes refugees feel more at home at no cost to anyone else), but there's no suggestion of the media keys.
I realize it's deeply sad that I can't just assume they work, but this is Linux, and it wasn't many releases ago they didn't work. And it's worth bearing in mind that I had to write a custom rc.local script to get my keyboard to work at all with Ubuntu 8.04! (I actually installed KDE and tried amaroK, and note that my media keys don't work there.)
The search field is in the wrong place, too. Where do search fields go? In the top-right of your window. I've made this UI mistake myself in the past, but it's a well established convention now. Firefox uses it (for searching the web, rather than the current document), as does Safari. iTunes uses it. Ubuntu's Add/Remove Applications uses it and Ubuntu's help browser uses it. Microsoft's developer documentation for Vista explicitly says "thou shalt". But Rhythmbox just kind of hides it in the middle of a bunch of other UI clutter.
(GTK+ apps in general make very poor use of empty space; the widgets seem to enforce large amounts of arbitrarily wasted space around themselves, and developers seem, perhaps in reaction to this, to use it only rarely in ways that actually help convey meaning. Mac developers tend to be best at this, perhaps because Apple over-exaggerated in early versions of Mac OS X to get the point across. Good Mac apps tend to have far fewer controls and preferences, of course, which gives developers more room to play with.)
Did I mention that the window manager's stupid "top-left corner" behavior is exacerbated by Rhythmbox not explicitly repositioning itself where it was last? GNOME bug 502827. (Sad, of course, that individual applications need to work around systemic lameness, but remembering your last window position is a good basic feature to have anyway.)
There's advertising in the UI, too. In the latest version, two net music stores have appeared. I thought one advantage of not using iTunes would be to not suffer that crap, but I was wrong. To be fair, judging by the text that disappears before you have chance to read it (and how do you get it back?), Jamendo is actually a "store" for Free music; Magnatune not. But it's unclear, and feels like thin ice that really needs better explanation. Unlike iTunes, the "stores" aren't very store-like, either. They look just like your normal music collection, which isn't a very accessible way to browse unfamiliar music.
But what drives me mad the most (worse than even the slider) is the overall window behavior. When you start Rhythmbox, an icon appears in the top panel, which generally signifies some kind of "background" application; the kind of application whose window you can close without thereby quitting the application, because you can click the panel icon to get the window back. But no, clicking the close icon quits Rhythmbox. No more music. You can click the window's minimize button, but that still wastes space in the list of windows at the bottom of the screen.
You can get better behavior by clicking on the panel icon, funnily enough. If the window is visible, clicking the panel icon (somewhat bizarrely, and with visual feedback to emphasize the idea) minimizes the window "into" the panel. Clicking again re-opens the window, as you'd expect. But if you've just been fiddling in the window, which you probably have if the window's visible, you're focus is on the window and your pointer is in the window. Nowhere near the panel icon. So it's way more convenient to close the window, but closing the window, despite the existence of the panel icon, quits Rhythmbox and stops the music. This is GNOME bug 158168 from 2004, which the developers don't think is a bug.
It would appear from GNOME bug 523072 as if Rhythmbox is equally evil if you're ripping a CD at the time. I can imagine that's even more annoying!
I came up with a patch, ran a patched version for a few weeks, and was much happier. But what's the use of a patch when the developers think the current behavior is not just acceptable, but good? The fanboys who say "patches welcome" whenever someone complains miss the point; patching is necessary but not sufficient. Realistically, you probably have to fork, and get your distribution to package your fork instead. And that's not something you can do on a feature-by-feature basis. You could try to file the bug against your favorite distribution instead, and put the maintenance burden onto the package manager, but that really doesn't seem like a healthy way forward.
Am I really destined to end up running Gentoo? Building everything from source and applying my own little set of patches on my local machine? I think I'd rather buy a Zune.
At this point, I should be honest and point out that I simply don't know what iTunes does if you close its window. Mac OS solves the underlying problem in a more fundamental way: command-h gets any application out of my face in a single keystroke. (My complaint there is that, by default, there's no visual indication that an application is hidden, which I find confusing, especially in combination with the way Mac OS' dock shows some non-running applications too. There's a hidden preference to fix that, though, and it's about the only bit of manual configuration I have to do on a new Mac.) It would be great for Linux to have a similar system-wide fix, but this is Linux, so there's no "system" (hell, there's a whole other desktop I haven't mentioned that's the default in some distributions, and there's a third semi-popular one), and Linux has no Steve Jobs insisting that stuff is not allowed to suck.
[I am reliably informed that iTunes does the right thing. Imagine my surprise.]
So given all those Linuxy lemons, you'd be well advised to have your application know how to make tasty lemonade.
Did I mention that Rhythmbox never remembers its window location? This isn't just a problem if you quit and re-start. It's a problem if you click the panel icon twice to hide and then re-show the main window, because that resets the window position to the top-left. Seriously.
Did I mention that if you quit Rhythmbox (which, as I've said, is easier to do by accident than it ought to be) it forgets what you were playing? I'm not asking for fancy stuff like remembering scroll bar positions and search field contents and multiple selections and the like: just remember which track was playing last, please!
Did I mention that the mis-positioned search field isn't activated if you use control-f (or, if you think of it more like Firefox's "Web Search", control-k)? The former does nothing (unless focus is already in a component that has some default behavior for the keystroke), while the latter is "Play Queue as Side Pane". I'm not sure, but I don't think "Play" is a verb in that sentence.
Did I mention that canceling the search field doesn't keep the currently-playing track visible in the table? I realize the "right" behavior is pretty hard to specify if you want to cover all the special cases, but there's value in doing the right thing in the most common case.
Don't get me wrong: I actually quite like Rhythmbox. It's almost good. And I do think it's a case where a bit of "ronco spray-on usability" could make the difference. I bring this up because I don't want people to think that there isn't low-hanging fruit out there. The little panel icon? It's great. I love its little notifications when the track changes, and I love that I can turn it off if I want, and I love that I turn it off in the place where it appears. All nicely done. I want to use it more, and I want Rhythmbox to stop coming across as if it thinks it's the most important app on my desktop, when 99% of the time that little panel icon is all I need to see. If listening to music were my primary occupation, I wouldn't be running Rhythmbox on Linux; I'd be running the iPod software on an iPod.
But back to my patch. My experience has been that, contrary to what you might imagine, sending patches to the most-upstream source doesn't work well. Perhaps because most of my patches fix things so obviously broken that the only reason the patch is needed is because the developers are either actively hostile towards, or simply indifferent to, their users. The distributions tend to be a better place to go. Sure, they apply patches that make your SSH insecure (Debian) or your Perl slow (RedHat), but at least they get things done.
Anyway, I went to launchpad, Ubuntu's bug database. And I found Bug #38512 in Rhythmbox: "Window close should close, not quit". Reading that bug's comments we learn a great many things. I could summarize the thread, but really it's so educational I think everyone who's interested in the state of the Linux desktop should read the whole thread themselves.
I'll wait.
If, having read that thread, you want to see the alluded-to tantrum by one of the upstream developers, you should read the upstream bug Bug 318629 - Option to minimize to tray on close or minimize (rhythmbox). (Note that a developer calls a user a "dick" before a user calls a developer a "dick".)
Everything that's wrong with the Linux desktop is beautifully illustrated in those two bug reports.
Problem: everyone wants users until they've got them. When they've got them, they want to reshape them into their own image. When that fails, as it always will, they begin to hate their users.
Desktop Linux suckage: an interlude
elliotth's blog - Sat, 23/08/2008 - 8:18pm
Before you sink too far into despair, let me say: not everything is hopeless.
Firefox is mostly okay. I use Firefox 2 and Firefox 3 on different machines on a daily basis, and I'd be hard-pressed to tell you why you need to upgrade. I can name a few things that are different, but I don't know that they're necessarily better. But Firefox 3 isn't so much worse that I'm cursing the mother that bore it, and that's pretty good for a Linux desktop application major-version upgrade.
The GNOME System Monitor doesn't seem to change much, especially considering how often it's mentioned in the release notes ("now with extra Cairo!"), but it's every bit as "okay, I suppose" as it ever was. I think whoever writes the release notes either needs to concentrate more on stuff real people would care about, or, conversely, has an excellent feel for their audience.
The weather/calendar/date/time/world-clock applet (yes, all those things really have merged into one) is equally, well, "okay".
I use Terminator as my terminal emulator, and it's worth pointing out that it runs better on Linux than on any other platform. Fundamentally, Linux is a good platform to develop for. I use Evergreen as my editor and it, too, runs better on Linux than on any other platform. But, important though they are to me, those are two applications by developers for developers. I'm not presenting them as examples of good Linux desktop applications, suitable for the mainstream. It's okay to expect their users to understand regular expressions and know how to write scripts and all that, and their users are people for whom "Python scripting interface" or "rewritten in Objective MonkeyPoop 7.3" might actually be a feature (the kind of crap you see all too often on the web pages of Linux music players, say).
Terminal emulators and IDEs, despite what we developers might think, aren't core parts of the desktop that everyone from beginner to expert needs to be able to use, and they're not apps it's important to come to a "good enough" consensus on. They're sovereign apps that the people who use them use day-in day-out for years. These people are prepared to devote significant time and effort into learning how to best use them, because it pays off, and they know it. Everyone has their own sovereign application. Yours might be Photoshop. His might be Word. Hers might be Keynote.
I fear for all of those people, but the Linux desktop is years or decades away for them, so maybe it doesn't matter. The people we could usefully reach are the people for whom the web browser is the sovereign application.
Most people wouldn't know a terminal emulator or an IDE if it bit them, and that's as it should be. I don't know how to drive, you don't know how to spacewalk, and that guy creeping up behind you with the knife isn't a hairdresser. These are specialist skills, often requiring specialist tools, corresponding to sovereign applications. We do all know how to open doors, climb stairs, and use toilets. These are non-specialist skills requiring no specialist tools, and correspond to things like calculators and mp3 players.
Notice that it's depth rather than subject area that's important; a calculator isn't a sovereign app, but Mathematica is. An mp3 player isn't a sovereign app, but Logic Pro is.
There's another simple rule of thumb for distinguishing the two kinds of app, and it's this: if Apple or Microsoft will sell you an application separate from their OS, it's a sovereign application. If they give it to you for free (including new versions; the first iPhoto is always free, just to get you hooked), it's not a sovereign application.
Funnily enough, one of the most frequent problems with non-sovereign applications on Linux is that they think they're sovereign applications. More about that in the next post.
Before you sink too far into despair, let me say: not everything is hopeless.
Firefox is mostly okay. I use Firefox 2 and Firefox 3 on different machines on a daily basis, and I'd be hard-pressed to tell you why you need to upgrade. I can name a few things that are different, but I don't know that they're necessarily better. But Firefox 3 isn't so much worse that I'm cursing the mother that bore it, and that's pretty good for a Linux desktop application major-version upgrade.
The GNOME System Monitor doesn't seem to change much, especially considering how often it's mentioned in the release notes ("now with extra Cairo!"), but it's every bit as "okay, I suppose" as it ever was. I think whoever writes the release notes either needs to concentrate more on stuff real people would care about, or, conversely, has an excellent feel for their audience.
The weather/calendar/date/time/world-clock applet (yes, all those things really have merged into one) is equally, well, "okay".
I use Terminator as my terminal emulator, and it's worth pointing out that it runs better on Linux than on any other platform. Fundamentally, Linux is a good platform to develop for. I use Evergreen as my editor and it, too, runs better on Linux than on any other platform. But, important though they are to me, those are two applications by developers for developers. I'm not presenting them as examples of good Linux desktop applications, suitable for the mainstream. It's okay to expect their users to understand regular expressions and know how to write scripts and all that, and their users are people for whom "Python scripting interface" or "rewritten in Objective MonkeyPoop 7.3" might actually be a feature (the kind of crap you see all too often on the web pages of Linux music players, say).
Terminal emulators and IDEs, despite what we developers might think, aren't core parts of the desktop that everyone from beginner to expert needs to be able to use, and they're not apps it's important to come to a "good enough" consensus on. They're sovereign apps that the people who use them use day-in day-out for years. These people are prepared to devote significant time and effort into learning how to best use them, because it pays off, and they know it. Everyone has their own sovereign application. Yours might be Photoshop. His might be Word. Hers might be Keynote.
I fear for all of those people, but the Linux desktop is years or decades away for them, so maybe it doesn't matter. The people we could usefully reach are the people for whom the web browser is the sovereign application.
Most people wouldn't know a terminal emulator or an IDE if it bit them, and that's as it should be. I don't know how to drive, you don't know how to spacewalk, and that guy creeping up behind you with the knife isn't a hairdresser. These are specialist skills, often requiring specialist tools, corresponding to sovereign applications. We do all know how to open doors, climb stairs, and use toilets. These are non-specialist skills requiring no specialist tools, and correspond to things like calculators and mp3 players.
Notice that it's depth rather than subject area that's important; a calculator isn't a sovereign app, but Mathematica is. An mp3 player isn't a sovereign app, but Logic Pro is.
There's another simple rule of thumb for distinguishing the two kinds of app, and it's this: if Apple or Microsoft will sell you an application separate from their OS, it's a sovereign application. If they give it to you for free (including new versions; the first iPhoto is always free, just to get you hooked), it's not a sovereign application.
Funnily enough, one of the most frequent problems with non-sovereign applications on Linux is that they think they're sovereign applications. More about that in the next post.
Desktop Linux suckage: Evolution
elliotth's blog - Fri, 22/08/2008 - 8:17pm
Ah, Evolution. Humans are known for allowing hope to triumph over experience, so although I've been public about my dislike of Evolution (the crappy half-finished mailer, not the scientific theory) since the beginning of this blog, I still give it another quick go with each release of Ubuntu.
Assuming the version that shipped with each Ubuntu has been different each time, and you'd certainly be hard-pressed to tell at times, that's at least six versions I've tried. And all have sucked.
I'll gloss over the experience of trying Evolution version crap.useless to save myself the anguish. Evolution continues to be so appalling that the future for webmail would look as bright as ever amongst Linux users, even if the general public weren't webmail-mad. Despite competing in a category of applications that's practically defined by its members' lameness, Evolution is so beyond hope that I won't waste any more time or any more breath on it.
If you think I exaggerate, you don't even need to install and try Evolution. You can learn a lot from the Evolution FAQ:
Why cannot I reset word wrap setting for outgoing mails at 72 characters?
Sorry, the value is hardcoded.
Can I change/personalize the "On <date>, <person> wrote:" string when replying?
Currently you can only change this if you compile from source yourself.
In fact, you can probably get a pretty clear picture by just reading one FAQ question's title: "Does a version for Apple(R,TM,C,whatever) Mac OS(R,TM,C,whatever) exist?" There are two other FAQ entries with the same childishness surrounding "Microsoft", "Windows", "Sun", and "Solaris".
I think that tells you all you need to know.
Don't get me wrong: I think having a vision or an ethos is important, and it's a good and wise decision to not add every single feature anyone on the internet can think of. At the same time, I think it's even more important that you communicate the vision. Especially if one of your philosophical decisions has become a FAQ. That's people's way of telling you they don't understand what the hell you're trying to say. (And to be perfectly clear, though this shouldn't need to be said: that's your fault, not theirs.)
According to their web page "Evolution provides integrated mail, addressbook and calendaring functionality to users of the GNOME desktop". That sounds pretty inclusive to me. That says mainstream to me. That says "we are to the GNOME desktop what Mail.app and Outlook are to Mac OS and Windows". Not "we will give smart-arse answers to perfectly reasonable questions".
Somehow, this "fuck you" attitude manages to carry over to the UI, which would be a neat trick if that were actually useful.
There's Thunderbird, too, but that's like Evolution for people who like more knobs and switches. (Plus the handful of people who actually miss the built-in mailer from late 1990s versions of Netscape.)
I wonder how we got here? Once upon a time, not long ago, Unix was the only place you'd find sensible mailers. They were terminal-based, of course. One of them (mutt) even survives, in some of the more beard-overgrown corners of the internet. Various people had already taken us from terminals to GUIs, giving us nicer (and more) fonts, and eventually giving us HTML mail for amazon and netflix and newegg (and spam). But fast full-text search? Good local caching to cope with high latency/low availability connections? Great editors? Nope. We even took a step backwards on that last one, giving up $EDITOR. Not a problem for the mainstream user who doesn't have a favorite editor, but perhaps one reason why the people who might actually write the code have little inclination to do so. "You want me to use Emacs/Vim to write a program, the use of which would mean that I can't use Emacs/Vim as much? Yeah, sure; I'll get right on that."
Ah, Evolution. Humans are known for allowing hope to triumph over experience, so although I've been public about my dislike of Evolution (the crappy half-finished mailer, not the scientific theory) since the beginning of this blog, I still give it another quick go with each release of Ubuntu.
Assuming the version that shipped with each Ubuntu has been different each time, and you'd certainly be hard-pressed to tell at times, that's at least six versions I've tried. And all have sucked.
I'll gloss over the experience of trying Evolution version crap.useless to save myself the anguish. Evolution continues to be so appalling that the future for webmail would look as bright as ever amongst Linux users, even if the general public weren't webmail-mad. Despite competing in a category of applications that's practically defined by its members' lameness, Evolution is so beyond hope that I won't waste any more time or any more breath on it.
If you think I exaggerate, you don't even need to install and try Evolution. You can learn a lot from the Evolution FAQ:
Why cannot I reset word wrap setting for outgoing mails at 72 characters?
Sorry, the value is hardcoded.
Can I change/personalize the "On <date>, <person> wrote:" string when replying?
Currently you can only change this if you compile from source yourself.
In fact, you can probably get a pretty clear picture by just reading one FAQ question's title: "Does a version for Apple(R,TM,C,whatever) Mac OS(R,TM,C,whatever) exist?" There are two other FAQ entries with the same childishness surrounding "Microsoft", "Windows", "Sun", and "Solaris".
I think that tells you all you need to know.
Don't get me wrong: I think having a vision or an ethos is important, and it's a good and wise decision to not add every single feature anyone on the internet can think of. At the same time, I think it's even more important that you communicate the vision. Especially if one of your philosophical decisions has become a FAQ. That's people's way of telling you they don't understand what the hell you're trying to say. (And to be perfectly clear, though this shouldn't need to be said: that's your fault, not theirs.)
According to their web page "Evolution provides integrated mail, addressbook and calendaring functionality to users of the GNOME desktop". That sounds pretty inclusive to me. That says mainstream to me. That says "we are to the GNOME desktop what Mail.app and Outlook are to Mac OS and Windows". Not "we will give smart-arse answers to perfectly reasonable questions".
Somehow, this "fuck you" attitude manages to carry over to the UI, which would be a neat trick if that were actually useful.
There's Thunderbird, too, but that's like Evolution for people who like more knobs and switches. (Plus the handful of people who actually miss the built-in mailer from late 1990s versions of Netscape.)
I wonder how we got here? Once upon a time, not long ago, Unix was the only place you'd find sensible mailers. They were terminal-based, of course. One of them (mutt) even survives, in some of the more beard-overgrown corners of the internet. Various people had already taken us from terminals to GUIs, giving us nicer (and more) fonts, and eventually giving us HTML mail for amazon and netflix and newegg (and spam). But fast full-text search? Good local caching to cope with high latency/low availability connections? Great editors? Nope. We even took a step backwards on that last one, giving up $EDITOR. Not a problem for the mainstream user who doesn't have a favorite editor, but perhaps one reason why the people who might actually write the code have little inclination to do so. "You want me to use Emacs/Vim to write a program, the use of which would mean that I can't use Emacs/Vim as much? Yeah, sure; I'll get right on that."