Older blog entries for apenwarr (starting at number 45)

Multiple Intelligence

It's not exactly as if I had nothing better to do, but I was eating while browsing the web last night and randomly clicked on the (yet another statistically invalid) personality test that drheld had linked to. Now, this is perhaps the most statistically invalid psychology experiment I've ever seen, but I won't harp on that.

This test is called the "Rogers Indicator of Multiple Intelligences", ie. a mushified IQ test that everyone can feel good about taking, because you can't fail. And if you do, it's okay: the questions do nothing to test statistical validity of the answers, so just lie! Oops, sorry, I'll stop harping.

Anyway, drheld said he, "not surprisingly", ended up being in the "Logical/Mathematical" category. That sounded sensible to me, so off I went to discover that my fate was identical. Lo and behold, I was wrong: in fact, Logical/Mathematical was third, trailing "Verbal/Linguistic" and "Intrapersonal" (not "Interpersonal", that's another category) by a pretty wide margin.

In other words, I'm a communicator. An introvert communicator. Just shoot me.

Only *Almost* Crazy

I spent this week on bare inside edge of "completely out of control", jumping from project to project and person to person giving advice that, luckily, appears to have been correct more than 75% of the time. "Isn't your problem just that?" "Oh, of course!" "Could we do it this way instead and do almost no work?" "Oh, right!"

I have a feeling that most of these things just needed someone with a different perspective to look at them - and because I was constantly coming at one project after looking at a totally different one five minutes earlier, I was guaranteed to have a different view of things than the person who was stuck. It's convenient - you can look smart without having to actually be smart all the time.

Since all the due dates appear to have turned out to be Monday morning, I guess I'll find out then just how smart I am. :)

People Hacking Again

Today I was introduced to an area of Montreal that actually has streets with special bus lanes. This is actually funny for Montreal, which has great public transit (including a subway we call the Metro, as all good Franglish speakers will do) but such generally bad road systems - I personally suspect they are deliberately bad to discourage automobile traffic - that buses tend to move rather slowly.

These bus lanes are in the usual North American style, in which they paint little diamonds on the pavement and you're not supposed to drive your car there during peak hours. But there are two minor surprises involved. First, the lanes are the two center ones (one in each direction) instead of the outside ones. Second, and this is the fun part, in order to discourage people from driving their cars in them during peak hours, the bus lane on your side of the street is going the opposite direction from your car. That is, the left lane goes forwards, and the right lane goes backwards, if you see what I mean.

Aha. You see what I mean by "deliberately bad." It's obviously a great way to keep drivers out of the bus lanes - in that they're going to have a head-on collision with a bus if they drive there. But on the other hand, well... this scheme has actually been put out of service recently, "due to too many accidents."

There's a twist: the accidents were actually *not* cars having head-on collisions with buses. They were pedestrians getting run over by buses, because they would only look one way, run towards the median, and then get hit by a bus coming from the wrong direction.

Why am I telling you this story? Well, because it just struck me that there was a completely obvious reason that this scheme shouldn't have worked, and that problem didn't happen. Drivers just spend too much time staring in front of them to not notice an oncoming bus on the rare occasions where they're driving in the bus lane illegally. Instead, the scheme was doomed for a reason we *didn't* expect, just like a perfectly valid-sounding scheme could have been. So the moral is: don't judge a book by its cover? Theory vs. practice? Don't be afraid to try new things, because they'll fail anyway? I don't know, you tell me.

Supposed USB GPL Violations

In other news, hub mentioned someone accusing Silicon Labs of "blatantly" violating the GPL by writing a binary-only Linux USB driver. The theory goes that to do this, you "obviously must have" included the Linux USB header files, which are GPLed, and are therefore creating a derived work.

But actually, this is not necessarily such a "blatant" license violation. There are special copyright exceptions for things that "could only be useful if written in a particular way". For example, most legalese cannot be copyrighted, because there is theoretically only a limited set of ways that you could use to objectively say what you need to say about a particular legal problem.

It has been argued that the same could apply to C header files, because if you want to talk to the Linux USB layer - a perfectly legal thing to want to do, unless someone wrote a DMCA-enabled license stopping you from doing so (and *that* surely wouldn't be GPL compliant!), you *have* to use the structs and code defined in that header. You could reverse-engineer the interface, but some people would say you don't have to. Similarly, to write any Linux driver you pretty much end up including at least some of its headers. This has always been declared okay up to now - at least, I'm pretty sure Linus has said so explicitly.

(This all doesn't apply to "normal" code. There are lots of ways to write a program that does something. There may be only one sensible way, in C, to talk to another particular program. Remember those people who compare "interfaces" to "contracts"?)

What's the legal standing of all this? Beats me, the GPL has never been tested in court.

By the way, IANAL, YMMV, and so on. Please don't sue me.

UniConf Strikes Again

So Avi Alkalay has converted the newest x.org X server to use his Elektra (formerly Linux Registry) configuration system. But am I mad? Of course not!

Instead, I wrote a UniConf frontend for Elektra. Now Elektra can store its keys anywhere in UniConf, which means, by extension, so can my X server. So there. I hope he converts some more stuff soon :)

For the source (there's not much of it), see the "unity" project in Anonymous CVS on open.nit.ca.

Conspiracy Theory Updates

So I'm emerging from my ExchangeIt project acceleration marathon, which of course involved plenty of Windows programming. I won't go into the gory details of that, because the details are not that important. (The answer to my earlier question about _read(), by the way, is to special-case every kind of stdin, such as named pipes, console objects, and files. Like I said - gory.)

My conspiracy theory comes in three parts:

1. Architectural Philosophy

I think my next NonDirectionalFridays presentation will be about what I call "Architectural Philosophy" - how your way of looking at things influences the way you design software. In particular, it's interesting to compare Windows and Unix architecture (since I recently became intimately familiar with the former), where they came from, and the results.

The short version is that Windows was built, from day one, on pragmatism. There is no sense of art, no simplifying assumption that binds it all together. On the other hand, if you want to do something, it's for sure that you can (assuming you put in enough effort) - and better still, Microsoft will jump through hoops until the end of time to make sure that your code keeps on working forever. That's the only reason DOS programs still run in Windows XP.

Unix was built, at the core, on a sense of elegance. There are a small few simplifying assumptions in its design that makes many things easy to do. It is also, not quite by coincidence, very pragmatic - my old Unix programs can still work today, too (if I can compile from source), and this has little to do with art. It has to do with keeping the API relatively constant from day one. Just like Windows did. The only difference is that the Unix API made more sense on day one.

But the Unix philosophy, nowadays, is more about the elegance than the pragmatism. WvStreams is my personal example of this. The API is nice, and it lets you write simple programs, but I also change it relatively often; my simplifying assumptions weren't always right.

GTK, on the other hand, is really based on the Windows philosophy. The ability to write code simply and expressively doesn't figure into GTK at all; but the desire to make sure a program you wrote last year still runs ten years from now is hardcoded into the design.

What's interesting is that you usually have to choose between pragmatism and elegance; Unix is a rare exception in which, by sheer genius of the designers, you could have something both useful and expressive at the same time. But the original Unix design didn't include a GUI, and there are no design geniuses for the GUI like there were for the kernel. That, or their designs were never popular.

Lacking the ability to have elegance and pragmatism at once, you have to choose one or the other. Customers will choose the working solution, thank you very much. That's why GTK exists and is popular; it's also why GTK is no better than Windows.

2. Microsoft is a Gluer

I've written before about the role of Gluers in coding, and how their time has come. Microsoft is actually the biggest gluer of all; by forcing a pragmatic architecture down our throats, they force Windows applications to (more or less) interoperate. I wish the pile of crap this produces would be a bit more elegant sometimes, but at least it works. That's why customers buy it.

Unix people (like me) keep trying to build beautiful designs, hoping that if the design is sufficiently beautiful, it will defeat Windows and Windows applications. They point to the elegant design of Unix as an example of how this might be possible. But this won't happen. Your system must be pragmatic first, and pretty design is a bonus. People have missed the fact that Unix is not only elegant: it's also highly functional.

3. Microsoft Needs Competition, But It's Okay if They Win

One thing I'm becoming more and more sure of as time goes on is that Microsoft is one of the better monopolists I could have to deal with. I mean, the phone companies? Kill them all. Cable companies? Garbage. Oil? Well.

Microsoft, for all their faults, still has this misguided notion that the way to maintain their monopoly is to produce better products than everybody else. (For some definition of "better". Let's not go into that.)

But here's the catch: they stop at "better than everybody else." And if someone produces a slightly better product but drops dead too soon, Microsoft won't bother to steal their ideas. So you have to compete with Microsoft until they steal your ideas. Then your ideas become mainstream, and once Microsoft supports them, they'll never really die. So you win, even if you lost. (Example: IE is still the best web browser, darn it. And yes, I've tried Firefox and seen Opera.)

Conclusion

If in doubt, bet on Windows. But if you want something to show up in Windows, build it in Linux first, then make sure you don't die until they clone your stuff. It doesn't have to be pretty - it just has to work.

Of course, all of this is probably little help to you if you're actually trying to win the war...

12 Oct 2004 (updated 12 Oct 2004 at 06:03 UTC) »
Soul Sucking

This weekend I've been hacking the win32 port of WvStreams to work more smoothly. It already works, but the unit testing framework didn't compile, so I had my suspicions that it didn't all work. Sure enough, I fixed the few minor bugs in the unit testing framework, and next thing you know - failing unit tests everywhere.

So first of all, yay for unit tests. Automated magic bug pinpointers, they are. A busy weekend of hacking got the failure count down to zero where it should be, and sure enough - all the WvStreams demo apps work way better now.

Anyway, since I would hardly want to resort to using Visual C++, and since the unit tests are kind of most convenient when used with GNU Make, I thought: let's see how much of this I can do on my Linux system.

Ha. So I now know all about mingw32 (a wonderful system). I also know more than I'd like to know about msvcrt.dll's fd-to-handle mapping (a terrible system). And it all runs correctly under WINE (a truly horrendous pile of puke).

Oh well, if nothing else, I guess I can extend my UniConf demo. Now I can run a UniConfDaemon under wine, exporting the Windows registry over TCP so I can connect to it from a Linux box, replicate it into my Maildir, point gconfd at that, and then configure KDE through gconf. If all that put together doesn't crash, I guess something doesn't suck.

Related Question

If you're doing _read(0,buf,sizeof(buf)) in a thread in win32, does anybody know how, from another thread, to get _read() to back out gently and return? I wouldn't even mind closing fd#0 in order to do this, but stunningly, close() blocks forever because _read() is blocking while in a critical section. Argh. I'm sure there has to be a way to do this.

I used to think the Worse is Better guy was just making an idle example. But good old EINTR - holy cow. How I miss you!

Irony

Tomorrow, I'm giving a presentation on how to write/debug code more quickly. And I spent the weekend working around Windows quirks. Sigh.

Monopolize this!

If we end up extending XPLC's IDL compiler to support Java and .NET, I'm going to call the result .NIT (dot Net Integration Technologies). Just try and stop me.

Language Reliability, Round 2

Several people accused my last post of being a thinly-veiled troll. Well... yes. But I was also serious.

Thanks to davidw, who reminded me that Erlang does in fact both exist and run high-performance, high-reliability systems. I haven't looked at it very closely, though; I suspect it may have other overriding disadvantages, possibly including the most common one: incompatibility with pre-existing code. "100% Pure Java" my bum.

To the accusations that I was unclear in my requirements for "reliability" and "high-performance", I guess I can clarify a bit. My company makes highly reliable backup software. Imagine your job was to manage the mission-critical backups for a 1000-person company, and in case of any failure, you had to be able to get back up and running again within 24 hours. First of all, can a program written in one of these scripting languages deal with the massive quantities of data involved - hundreds of gigabytes, millions of files? Would your backup even finish every night? Can you trust your backups to be reliable?

This is an honest question, and when I ask myself, the answer is no. I've just never seen a program written in one of these languages that I would trust with my mission-critical data. So I ask you the same: have you seen programs in these non-C/C++ languages that are actually this fast and reliable? I haven't. I would love to hear some examples.

Scripting Languages and Reliability

Since I've said this to several people at work in the last few days and nobody has had the heart to disagree with me, I will now open myself up to public flaming and see if that helps.

My assertion: it is totally impossible make really reliable, high-performance programs (like oh, say, idb backup) in a language other than C/C++ (and maybe ADA and C#, but I'll reserve judgement for now). This includes, but is certainly not limited to: python, perl, shell, java, tcl, and php. Especially python. And *really* especially PHP.

My evidence: nobody has ever written a reliable, high-performance program in *any* of those languages.

Thank you. Have a nice day.

Management Architecture

To avoid the worried feeling I get about a recent directive from top management to effect of "Do everything possible to trick Avery out of writing actual code, because he's most useful doing other things," I've been trying to make my own job seem more attractive. (That's the actual quote, by the way. There is no directive to me, only to other people. I love this company :))

So here's my latest attempt: in a parallel with the similarities I noticed between programming and People Hacking, I've noticed a similarity between code architecture and company management structure. My latest theory - and the coders at NITI will be familiar with the results of this by now - is that a manager, like an object, should do just one thing, and do it well. If it takes you more than a sentence to clearly explain what your manager does, then his job is not clearly defined, and sure enough: he'll do it badly.

So, after the OO fashion of the moment, we've been trying to rearrange our management structure on a functional-block basis instead of using a pure inheritence hierarchy. For example, the new Pusher job (no link yet, sorry) is "responsible for when a release comes out." The now-simplified Visionary job (well, that link is for EvilVisionary, but you get the idea) is "responsible for what goes into a release." Best of all, you instantiate a new Pusher for each release, but they all communicate with the singleton Visionary object, er, person, who can move features around between releases.

Consider what the pusher does when your release is late:

  bool ok = visionary.drop_features(release, 5 /* days */);
  if (ok)
     return true; // on time again!
  else
     release.duedate += 5; /* days slipped */

I think pphaneuf will agree with me when I say that there needs to be one object at the top that ties it all together by setting up the initial objects, but it should probably be about ten lines long and do almost nothing.

Okay, I'll stop now.

36 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!