(A continuation of my reminiscences as an expert witness.) In an earlier post, I made brief mention of the unpleasant realities of being a witness in a trial. More details, ahoy! Most witnesses aren't allowed in the courtroom except when they're giving evidence (to avoid bias) and have to sit out in the hallway. Bring a fat book, because you could be out there for days. I don't think much compensation is provided for your time, either. And, as a final indignity, the lawyers might not even end up calling you to the stand. For example, one of the prosecution witnesses in the case I was involved with was called to appear, and sat outside the court for eight (count them, 8!) days, before being told he wasn't needed after all, and he could go home. I don't know about you, but if that had been me, I would have ended up in the dock myself on a charge of mayhem. Another witness, after having been through her time on the stand, made a comment along the lines of "I'm going to make sure I'm overseas next time". Expert witnesses (as I was) get treated a little better. We can watch most of the bantering in court, while we evaluate the technical evidence presented by other witnesses (experts and non-experts alike), and at least the pay is sensible. As an occupation, "expert witness" would be OK. The hours are pretty sweet, the pay is good, and the conditions quite reasonable. For a regular geek like myself, though, it was fairly close to agony by the end of it. I've had three big projects on indefinite hold while I was at court, unable to give my clients a firm date when I could resume work for them. They were all understanding, bless them, but I could have lost out badly. The complete uncertainty as to what is going to happen and when means that you basically end up camping out at the courthouse for umpteen days. At least, in my case, I was being paid regular consulting rates for my camping. When I say uncertainty, I really do mean it. I was originally told I'd be needed for a day or two -- a quick look at what the other witnesses were saying, maybe jump in the box for a bit, and then I'm off. Then the first witness in the stand was there for nearly three days (along with a day or two of procedural stuff in amongst it so I had been there a week before he was finished). Then the defence was going to make a motion for dismissal, because the prosecution were being pummeled by his honour for their lack of case preparation, so I would have been out of there. That never materialised. Then more procedural faffage, another witness that ended up in the box for about 4 days -- each day of which I thought was the last -- and then it was my turn, which lasted nearly four days. At no stage did I have any indication of when it was going to be over, either, so I couldn't say with any sort of certainty when I could start helping anyone else out. While the legal system has a vital part to play, I'm wondering if something could be done to improve the running of trials to reduce this sort of pummeling of witnesses. On the sweet hours: court convenes each morning at 10am. There's usually half and hour to an hour of transcription correction (although I get the impression that isn't a standard thing) then witnesses start going through. There's a half hour morning tea break around 11 or 11:30, and then an hour lunch at 1pm. Usually there will also be an afternoon break of 10 to 15 minutes, before court adjourns for the day at 4pm (if not a bit earlier). I presume that the reason for the short days is that it's mentally very tiring, and there's lots of prep work for the lawyers mornings and afternoons, but it's a lot better life when you've got none of that to do. Unfortunately, the day isn't short enough that I could get a lot of other work done, so it's effectively just a short-paid day.

I previously mentioned in a sidenote to another post that I've been involved in a court case over the last few weeks, and I promised a few people I'd blog about my adventures there. Obviously, not quite everything can be discussed in an open forum, but I checked with the legal beagles and I'm OK as long as I stick to generalities. Which is fine by me, since the detailed specifics are actually immensely boring. Executive Summary: It's the law Jim, but not as the TV shows it. I have to recommend that everybody spend a bit of time watching a case or two at their local court. It's surprising how different reality is to what you see on TV (of course, Australian courts are going to be different to the US courts we primarily see on TV, but even the dramatic representations of Australian courts I've seen are fairly inaccurate). The legal system, while appearing to be out in it's own little world, is a vital and integral part of most societies, so it's useful to have at least a basic idea of what goes on in them -- not because you'll end up in one (and even if you did, your lawyer will tell you what to do) but because it's an interesting insight into a part of our world that often affects us, but we don't like to look at. (Going and watching your houses of parliament, or an abboitoir, is a similar thing). Second, if you can possibly avoid it, don't get involved in a case. Not as a defendant, not as a litigant (in a civil case), and not as a witness. Litigants and defendants get screwed because they're stuck in a small room with a bunch of people they don't know or particularly like, for days or months, with a limited understanding of what's going on. Boooooooring. For witnesses, it's a different kind of pain. But I'll leave the details of that for another post. One of the things that quite surprised me is the general good nature and decent relationship between all of the legal professionals involved. They're willing to help each other out, they concede points graciously, and there's a surprising amount of banter between all of the lawyers and (in some cases) the witness as well. I'm told that this was peculiar in my case because I was involved in a voir dire[1], and everyone's on their more formal behaviour when there's a jury in the room. At times, it was almost a pleasure to watch the proceedings -- like a slightly dry but nonetheless compelling play. Most of the time, though, I characterised as "Snail Racing" -- about the most dull activity one could imagine, but nevertheless you just can't tear your attention away in case something interesting happens while you're blinking. When I say that the lawyers are good natured, that's not to imply that they're not vehemently arguing their case. Toward the end of the voir dire, in particular, counsel for the defence started to get rather vocal as to the lack of proper procedure on the part of the Crown. Over the entire voir dire, too, both counsel were always pressing hard and always trying to get their case seen in the best light. But their vigourous pursuit of the case never got personal or competitive. I think that's actually something that a lot of free software people could take on board (myself included) -- argue strongly for your position, but never internalise it or make it personal. Your position may be rather important (the defendant in my case was looking at up to 14 years if he got sent down) but making it a personal attack isn't going to help your case. I was amazed at the speed with which counsel picked up on new concepts and ideas. Unsurprisingly, the expertise I provided was quite technical, and counsel were not particularly computer literate. However, over lunches, I was able to essentially brain dump fair chunks of knowledge at the barrister, and he then went inside and laid it all out, usually accurately and very good presentation. It's also intensely satisfying to know that the questions that are being presented were suggested by you, and the skillful way that the ideas and queries were weaved together. I guess you'd get a similar buzz writing a play and then watching skilled performers bring it to life -- not necessarily exactly the way you imagined, but with an undeniable skill and vibrance. I've got a lot more material about my adventures in the legal system, which I'll be posting over the next while, but I figure this is probably well enough to be going on with for now.

---

1. A voir dire (as explained to me) is a sort of "trial within a trial", used to determine a point of fact or the admissability of a particular piece of evidence. It is run in the absence of a jury. They're only supposed to run for a couple of days; apparently mine was extraordinary at three weeks, although mention was made of a six week marathon (in the context of "this better not be like $OTHER_VOIR_DIRE").

Hanno B ck asks which free clients are available for receiving and subscribing to video podcasts, videoblogs, vlogs, vodcasts or whatever you want to call them. I was asking myself the same question for a number of reasons lately, and here's what I have found:

• Armangil's vodcatcher is a video podcast client for the command line. Written in Ruby, cross-platform, GPL'd, no GUI (obviously).
• PenguinTV, an RSS feed reader which supports podcasts and video blogs. Written in Python, cross-platform, GPL'd, GTK+ GUI.
• kmplayer, proposed by Hanno B ck. Haven't tested it, yet.
• DTV (DemoTV), a "free and open-source platform for internet television and video. An intuitive interface lets users subscribe to channels, watch video, and build a video library". This looks like the most mature client right now (for Mac at least), and it has been ported to Linux just yesterday. It's written in Python, cross-platform, GPL'd, GTK+ GUI. I have filed an ITP and hope to have a Debian package ready in a few days. The DTV Linux code itself is pretty beta, any helping hands with porting would be nice (contact Nick Nassar and/or the devel mailinglist).
• Kitty, a podcast and videocast client for KDE. Written in C++, GPL'd, Qt/KDE GUI.

As for the content, there's lots of videoblogs out there, and I will blog about that in more detail later on. As an appetizer, you can now subscribe to the new (German) Tagesschau Video Podcast (thanks Tim Pritlove). Update: Added Kitty.

KDE

I have never once written anything using Qt. Why not? I have no real dislike of the toolkit, license, or implementation language. It just hasn’t ever been necessary or appropriate for me to use it. Generally speaking I only dabble with coding online applications in Perl/PHP (Perl is my preference, sometimes I get suckered into using PHP). Any software which I’ve needed to write with a GUI usually ends up being coded using the raw X11 libraries (xlib, etc). A few times I’ve needed to have something be stable, sharable, and GUI-driven and xlib didn’t cut it I’ve chosen to use the GTK libraries. Mostly that has been down to three reasons:

• Finding small examples of code is very simple; as it is well-used.
  • By contrast many Qt applications are larger pieces of code. Finding examples using the functions you’re interested in is harder.
• I love C++, but generally I develop in Perl, or C.
• I don’t have to worry about the moc preprocessor, writing Makefiles, etc.

I’m sure that sometime in the future I will experiment with Qt, and possibly even install KDE to try it out. But it won’t be soon. (I think that desktop environments are a good thing, and can be attractive, productive, and useful. However I’ve only used Gnome briefly and tend to stick with the more lightweight IceWM environment). Once upon a time I did install and tinker with KDevelop, but nothing much came of it. When I lost my desktop machine due to hardware failure I didn’t feel the need to re-install it. Instead I stuck to using GNU Emacs + Vim for editing code.

Right now I’ve written that I shall go back to shaving my head. To make me look more like my avatar.

I'm working on new fuse (filesystem in userspace) packages and I really wonder if I should simplify their postinstallation procedure as it was mentioned in #337572. That would make my life much easier, cause there's quite many bugreports against undefined behaviour of post-debconf tasks, which are pretty hard to track for me. In fact I suppose that most users simply accept default answers so asking them about anything seems to be overhead.
Let's assume I will remove these superflous questions... now the problem is that if someone answered for them in some previous installation then I could leave unneded group and some config files on their systems. On the other head removing this group could even lead to nonworking system because of one of these bugs: #307624, 307627, 306281.
I'm quite confused what to do now. Both solutions have some advantages and disadvantages. First one at least could lead to less bugs in the future. Hints welcome.

David Berlind: “[P]icture a world where, instead of carrying a notebook computer with you everywhere you go, and instead of having power-drinking desktops in every corner of your house, all you have is a USB key that you take from one dirt cheap thin client to another. On that key is not just all of your personal data (that is stored in the cloud but replicated to your USB key for offline usage), but perhaps a small Web server and some applications, both of which are thin-client friendly.” I’m in complete agreement that the thin client/web application computing model is the wave of the future, and that the days of the fat client as the primary mechanism for monetizing software are numbered. However, I don’t buy into the notion that software-as-a-service displaces the traditional fat client entirely, for one very simple reason: It’s going to be a while yet before we have truly ubiquitous network connectivity. Sure, perhaps if you live in the San Francisco Bay area or in a similarly technology centric place, it’s easy to buy into the notion that it won’t be long before we’ll all be connected all the time. However, we can’t lose sight of the fact that a vast majority of the population doesn’t live in a world where technology billboards dominate the morning commute. Heck, my cell phone doesn’t even work when I visit my grandfather in rural Indiana—the notion of an omnipresent wifi fabric built from community hotspots is a long way off there, to put it mildly. And even when we do get to the day when we have ubiquitous connectivity, we’ll still want caching for optimization and replication to eliminate the single point of failure problem, not to mention the ability to retain control over our own digital lives. So, I view the thin vs. fat client juxtaposition as being not so much about user experience—AJAX has shown us that remarkably good user interfaces can be built on the web. It’ll be more about caching and data replication, two very important considerations in any distributed system. I think most people are missing that. David, as usual, appears to get it. My prediction: Applications will increasingly move to the web, so you’ll be able to get to your data anytime, anywhere, and from any connected device. No surprise there. But the majority of the time, when you’re using “your” client device (whether it’s a PC in your home or office or a handheld device or something that lives on a USB key and securely attaches to the network via some device that’s outside of your administrative control), you’ll still primarily interact with the web through a fat client of some sort. To be sure, the fat clients of the future will look a lot different from the fat clients of today. Hint: “Fat client” doesn’t have to mean “self-administered”. Perhaps the fat clients of the future are delivered on demand or via independently developed components that integrate into some larger framework. Perhaps it’s as simple as running a web server locally. But the fat client in whatever form will still be the primary interface the vast majority of the time. That’s why I don’t buy for a minute that Web 2.0 is yet another death knell for Microsoft. They’ve obviously got a great fat client story, and in case you haven’t noticed, they’ve just woken up to what’s going on around them. By the way, this is the area where I think Linux on the desktop could have the biggest impact—it won’t be about who has the better desktop or who can replicate the popular fat client applications of today in open source. It’ll be about who can mold Linux into the fat client framework of the future, seamlessly integrated with applications and services delivered via the web but open. If I were Microsoft’s competitors in this space, namely Google and Yahoo, I’d be spending a lot of time thinking about this. In today’s fat client world, Microsoft is between them and their customers more often than not, and if the past is any indication, they’ll be able to use this position to tremendous advantage.

So, the D-I team again made it: a new release of the "installer with no name yet" happened. First of all, yet another occasion to publicly reward Joey Hess work. Joey has managed to lead this work for five and a half years. I think that we all agree that without Joey's work, we wouldn't have such a nice installation system for our distribution. Joey now gives the lead to Frans Pop. Knowing Frans as we know him now, I'm confident that the good work will go on. Joey will have more time to hack in various parts of D-I or lead the testing security team. From my narrow point of view, I'm again proud that we cover more and more languages. The official announcement mentions 9 of them. We can add Vietnamese to it, even if the installer has a broken display in second stage because of a now solved localechooser bug. As a consequence, we continue to paint the world map in red. The next big push on that matter will be the release of a graphical version of the installer (an alpha version is already advertised) which will support the rendering of the various languages from india for which translation is on its way.

<p> Zeeshan Ali <a href="http://www.advogato.org/person/zeenix/diary.html?start=77">writes about Finnish women</a>. Onella is actually one of the better bars in Helsinki, hopefully you discovered the two "secret" bars after the inital heavy-metal one. The first is your typical dance-floor, the other is a uniquely Finnish experience. </p> <p> Basically it consists of drunk Finns, mainly drunk Finnish women, getting up on the table &mdash; dancing as best they can &mdash; and singing along to all the recent songs. <strong>Except it is all in Finnish!</strong>. Every song you know, and some you wish you didn't, will be sung, the audio will sound familiar but the words are Finnish. Distinctly odd. </p> <p> Yes, Zeeshan, Finns are very weird. I can not imagine anything like <a title="No secrets in Finland" href="http://today.reuters.com/news/newsArticle.aspx?type=oddlyEnoughNews&storyID=2005-11-02T150542Z_01_EIC254324_RTRUKOC_0_US-FINLAND-WAGES1.xml">this</a> happening anywhere else. Even the BBC's <a href="http://news.bbc.co.uk/1/hi/programmes/from_our_own_correspondent/4384992.stm">Night out in Helsinki</a> is fairly tame to my experience at Debconf5 </p> <p> Over the course of many nights, I saw </p> <ul> <li>Drunk women falling off tables (many times &ndash; and cute ones too!)</li> <li>People punching fists into windows</li> <li>Large brawls</li> <li>Pepper spray indiscriminately bandied about</li> <li>Bottles being thrown &ndash; by the bar staff at customers</li> </ul> <p>It makes for lots of fun adventures &mdash; If you ever meet <a title="Horms" href="http://www.vergenet.net/~horms">Simon Horman</a>, he can fill you in far better than I can</p>

<p> Or '<a href="http://en.wikipedia.org/wiki/Moblog">mobloging</a>' for short. Basically it is using your mobile phone to add content to your blog. All very interesting, except when you get to the details. </p> <p> <a href="http://www.flamingspork.com/blog/">Stewart Smith</a> gave it a whirl ([<a title="first attempt" href="http://www.flamingspork.com/blog/?p=503">1</a>], [<a title="take two" href="http://www.flamingspork.com/blog/?p=504">2</a>]) with fairly predictable results. This is because the message you might receive is dependent on the phone manufacturer <em>and</em> the <aabr title="Multimedia Messaging Centre">MMC</abbr> does to your message. And that is before it might be mangled along the way via email. </p> <p> Basically most phones (or MMCs) will convert the content to either <a href="http://en.wikipedia.org/wiki/Base32">Base32</a> or, more commonly, <a href="http://en.wikipedia.org/wiki/Base64">Base64</a>. Generally the MMS is composed of only two parts, and then sent to an email address. From there you'll have to write something that takes the email and converts it into a blog entry. </p> <p> A while ago a friend of mine wanted to do the same, so I wrote some perl to do it for him. It seemed to work for him (with some tweaks) and it might be enough for you too. You can grab it <a title="Code to help with mobile blogging" href="http://www.progsoc.org/~wildfire/arch/projects/moblog--devo--1.0/">here</a> However you might find it simpler to use <a href="">GNU Arch</a> and register <code>http://www.progsoc.org/~wildfire/arch/projects/</code> and then browse in <code>wildfire@progsoc.org--projects/moblog</code>. </p>

which is what was shipped with it, and I think there might be a newer firmware out there which fixes some of the issues. I just got my Nokia 770 and I must say it's a nice device. Some initial experiences are:

• No pen calibration on bootup. Nice and cool. All other handheld devices have that, but the 770 seems to work just fine without it. Kudos.
• It's not a PDA. No PIM thingy built-in, the device asks for its own name, but not the user's.
• It doesn't show that it's running Linux. I find this quite cool, as it shows that you can produce devices which run Linux and feel like they're targetted at non-geeks.
• The device feels sluggish and lacks feedback when doing stuff, whether it be closing an application, launching an application and so on. This makes it sometimes hard to know whether it has caught your action or not. Also, sometimes menus pop up for half a second, then goes away.
• The 770 has support for multiple applications at the same time. Works well enough, I guess.
• I want something to protect the screen, or I know it will develop scratches from the pencil over time. I guess I can get something from a shop in not too long.
• When putting the lid on, it's quite neat that it turns off the screen the moment the lid closes. I'll have to investigate how they do this. Hub thought it might be a magnet. Getting an X-Ray of the whole device would probably show.
• The feed reader needs work, I want to mark stuff as "read" explicitly and not just have a rolling list of news where I need to know where I was.
• Reduced-size MMC cards appear to be cheap. Around 30 for a 512MB card which should be enough for a fair amount of music. I need to find an Ogg Vorbis player as well.

All in all, mostly happy, but there are still a bunch of rough edges which should be smoothed away in a few more revisions. I'll see if I can get a development environment up and running on it, as well as getting a newer firmware onto the device (if I can find it; I wonder if the developer rootfs on maemo.org is newer or not..), but all that's for tomorrow.

I’m writing a registration database for Anime Detour, our local anime convention. Normally I would hate this kind of work (does anyone actually like SQL?) but SQLObject, which gesten pointed me towards, is really awesome. It basically turns any SQL database (in my case SQLite) into a Python object database, with classes as tables, instances as rows, and Python class methods for queries. People stuck writing database code should definitely check it out. Another Optimization Lesson
Quod Libet stores a library of your music, like most other players. The most common things the library needs to do, and therefore the most efficient things it should do, are 1) get a list of songs in the library, and 2) check to see if a song is in the library (or equivalently, given some handle, retrieve the song with that handle from the library). Anyone familiar with Python will probably think of a dict keyed to something unique, like the filename or URI. That’s what I did, and that’s what I wrote. When QL saves, it serialize the song list using pickle, and dump it to the library: pickle.dump(library.values(), file). When it loads, it does something like for song in pickle.load(library): if song.valid(): library.add(song) where song.valid() reloads the song if its mtime has changed or removes it if the file no longer exists. So what’s the problem with this code? I sure didn’t see one until this morning, when our Italian translator complained about interestingly long cold cache startup times. The answer’s at a lower level than Python programmers usually have to work at: This sucks for disk cache. library.values() dumps the file in Python dict order, which is not only not meaningful, it’s actually semi-random for security reasons. When I reload the dumped file and iterate through the songs in it, I’m stat(2)ing files in an order designed to be as unpredictable as possible. How is the cache supposed to cope with that? The answer is, it doesn’t. Sorting the songs by filename when saving the dict costs almost nothing (Python out-sorts every other language as far as I know), but saves 10% wall clock time for me when starting - it will probably save even more on filesystems that perform poorly on stats of large files (reiser3), and directory trees that go more than 2 levels deep. Lessons learned: First, CPU profiling is good, but doesn’t have all the answers; profile.py insists the program is slower because of the sorting on exit. Second, ideas that work fine for n=100 don’t work well for n=10000 even if the algorithm you chose scales well with regard to complexity theory. Finally, the fundamentals still matter; fixing slow Python code still makes you consider OS/hardware-level cache effects.

The 2005 Machinima Festival will be taking place in New York City at the Museum of the Moving Image in Astoria, NY, starting November 12. Here's what Wikipedia has to say about Machinima:

Machinima (a portmanteau word for machine cinema and/or "machine" "animation") is both a collection of associated production techniques and a film genre (film created by such production techniques). As a production technique, the term concerns the rendering of computer-generated imagery (CGI) using low-end 3D engines (as opposed to high-end and complex 3D engines used by professionals) in video games (typically, engines in first person shooters games have been used). Consequently, the rendering can be done in real-time using PCs (either using the computer of the creator or the viewer), rather than with complex 3D engines using huge render farms.

Have a look at the popular Red vs. Blue if you have never seen a machinima video. Checkout more stuff from the Machinima Archive over at the fantastic archive.org. I won't be at the festival, but I'm getting more and more interested in video in general and especially in machinima, so I'll probably create some films myself eventually. (via Digerati University and Slashdot)

Note: All of this is specific to Australian law. Similar principles may apply elsewhere, but I've got no idea where, if any, they might apply. Also, I'm not a lawyer, nor do I play one on TV, and my writings here (and for that matter, everywhere else) are for entertainment purposes only. If swallowed, do not induce vomiting. In the middle of a cogitation this morning, my thoughts turned (as they occasionally do) to the much loathed EULA for Nobody's Favourite OS. As we all know, this EULA is pretty brutal in the things you agree to allow other people to do to your machine, and the rights you agree to give up. As I was, in general, thinking about issues of copyright law, the EULA got looked at through copyright-coloured glasses. And it was... weird. As we all (probably) know, copyright law is about limiting the actions that can be performed with a work of creation, and giving the author of the creative work the ability to be the sole arbiter of who can perform those actions. The Australian Copyright Council has a nice information sheet on Copyright and Computer Software if you'd like to get the full story. The set of actions which the Copyright holder has exclusive rights to is fairly well proscribed. The statement "All Rights Reserved" doesn't mean "every possible right is reserved", it means "those rights which I can control (by virtue of the legally-protected monopoly of copyright law) are reserved". As far as I can tell, there is no right which allows the copyright holder to control the use of the creative work. It's important to think about what "use" actually means. The Copyright Act and the above info sheet tend to apply the word "use" to include the act of making copies, as well as other dealings (protected or otherwise) in the copyright work, but that doesn't seem particularly useful for this discussion, because I can't think of another appropriate word to use to describe a non-copying action involving the work. So I'll stick with "use" for that, and go with "copying" for any duplication. Obviously, the type of work that we're looking at determines what "using" that work means. A book is read, or perhaps burnt for warmth. A picture is stared at. A computer program is run. I can't find anything in Copyright law that covers reading, burning, or staring, but section 47B of the Copyright Act 1968 (Cth) deals with the "normal use or study" -- basically, the act of using the thing. It says that users are allowed to copy the program into RAM to run it[1]. Goody. So far, it looks like there's no way the copyright holder can stop us from running our legally acquired copies. There are two flies in the ointment, though. The first is s47(2)(b) of the Act:

(2) Subsection (1) does not apply to the making of a reproduction of a computer program:
[...]
(b) contrary to an express direction or licence given by, or on behalf of, the owner of the copyright in the computer program to the owner or licensee of the copy from which the reproduction is made when the owner or licensee of that copy acquired it.

Aaaargh! Does this mean that the copyright holder can force a licence on us, against our will? I really don't know the answer to that. Hopefully, at the very least, the protections of contracts law[2] would apply to such licences. If licences can be treated as contracts, then they can be rejected. If the copyright holder can't restrict the running of a legally obtained copy of the program, then how can they compel the acceptance of a licence? One idea that comes to mind is the process of installation. That is neither an incidental nor an automatic copy, and hence doesn't fall under the allowances of s47. So, without the permission of the copyright holder, making an installation from CD to your hard drive would seem like an infringemnet. On the other hand, the installation program usually runs directly from (for example) the CD, and if it wants to make copies of other copyright material owned by the same person or company as part of it's ordinary operation, then who are we to stop it? But back to the idea of compelling acceptance. Looking at the XPToy Retail EULA for a moment, part of the agreement is that you agree to be bound by the terms by the action of installing, copying, or "otherwise using" the software. But if you don't agree to any of the EULA, I'm not sure how you can agree that you agree to be bound by the EULA by performing an action which the copyright holder cannot restrict you from doing. On the other hand, perhaps I've drunk too much of the GPL "You don't have to accept this licence, but nothing else gives you the right to copy this software" inplied-licence-acceptance kool-aid, and there is provision in law for licences to specify other positive means of signifying acceptance. I know that contracts can be accepted by written agreement between the parties, and with a suitable verbal exchange, so perhaps you can add "Installing, copying, or otherwise using" to that list. I wonder if "You agree to the acceptance of this agreement to give me your first-born child by blinking within 15 metres of me" would be valid? No, I didn't think so either. Does anyone know where the descriptions of permissible means of agreeing to a contract are defined in Australian law? To get back on track, let's assume for a moment that we can refuse the EULA. Can we still use the software? s47(2)(b) says we can't contravene licence terms, but if we can refuse the EULA then it doesn't look like there are any licence terms. So we're back to relying on s47(1), which says copying for running the program isn't a problem. If you can avoid accepting the EULA, and don't do anything otherwise naughty with the software, I can't see how anyone can have any complaint, in Copyright law, with your actions. Of course, the next trick is to avoid clicking-through the EULA "you accept" notice without falling foul of any other provisions, but if we've already knocked the paper-EULA on the head with contracts law or something, then I don't think that your click-through acceptance (coerced, as it were) is going to worth a hell of a lot more. I know the DMCA in the US did a lot to strengthen the power of click-wrap licences; perhaps those provisions got written into AusNSFTA. Of course, this whole thing is based around a lot of conjecture and a lack of real, detailed knowledge of the law. Perhaps there's even some bits of the Copyright Act I've missed. I'd be interested to hear your thoughts on the matter. Do we need a licence to use software we've legitimately purchased? I'm interested in your comments. E-mail me at mpalmer@hezmatt.org.

---

1. I'm not quite sure why this is so majorly different to a person with an eidetic memory reading a book, but I guess it's better to cover the issue to stop lawyers getting richer. 2. There's all sorts of goodies in contracts law, from what I recall -- prohibitions against coercive contracts, and contracts presented as a fait accompli (AKA "take it or leave it") without any ability or intention to negotiate. Certainly sounds like a EULA to me...

Tomorrow I leave Montr al, Qu bec and Canada and will move down to the US, on my way to New York City. This part of my stay in North America is a bit (others would rather say "totally") improvised, and the plans are not too accurate even now, 8 hours before our departure. The first idea for this was to travel on a night bus from Montr al to Boston, meet mako and mika and then move to New York City during the weekend. The unavailability of any buses that did this route in less than thirteen hours made me look for alternatives. Chatting with mdz, I found out he was flying with Mark and Jane to NYC very early on Friday night, on the private jet. Sounded like a plan. Only it had a big flaw: non commercial flights entering the US require visas for everyone aboard, apparently. If you don't have it, the reports say you're really, really fucked up. So, having no visa as I don't need it in normal conditions, this was discarded too. Finally I learned that jblack was driving down to Pennsylvania after the conference. I asked him if it was possible to go with him on his way South, and he said yes. He could drop me in the nearest point to Boston, or drive me straight to NYC. As NYC is the easiest for me and jblack and Clint has no problem with hosting me one extra day, that's what we're going to do. (After having everything more or less clear, Paul Sladen came along and proposed yet another plan involving a bicycle and hitch-hiking. I was able to say no, though.) Here starts this crazy road trip. Wish me luck, and see you in NYC!

Tim Pritlove Jens (argh, need some sleep!) from the Chaos Computer Club (CCC) has asked for more english blog posts about 22C3, the upcoming hacker conference in Berlin. So here you go. Reminder:

The 22nd Chaos Communication Congress (22C3) is a four-day conference on technology, society and utopia. The Congress offers lectures and workshops on a multitude of topics including (but not limited to) information technology, IT-security, internet, cryptography and generally a critical-creative attitude towards technology and the discussion about the effects of technological advances on society.

The congress (sub-titled "Private Investigations") will be held from December 27th to 30th, 2005, in Berlin, Germany. Some noteworthy bits and pieces:

• If I don't get hit by a bus, I'll be there.
• They have an (English) event blog which should keep you up to date.
• The 22C3 public wiki launched today.
• There are very nice 22C3 wallpapers available now (thanks to Antenne).
• The CongressRadio team will be podcasting during the congress.
• There is a 22C3 Planet (actually there are two).

This is gonna be one of the highlights of this year, I'm really looking forward to the congress.

Jurij Smakov et al have published the Debian Linux Kernel Handbook, which will help in documenting the internals of the Debian Linux Kernel build process. The document is still work in progress with a lot of sections missing, but it's a giant step in the right direction.
Continue reading "Debian Linux Kernel Handboook"

Yesterday, Amtrak's board of directors fired Amtrak president David Gunn. Here's something unusual about this firing. David Gunn actually was the best thing to happen to Amtrak in years. He improved the physical condition of the railroad's equipment, raised ridership, cut costs, and even ended this year with a net surplus despite a crippling brake problem on Amtrak's high-speed Acela equipment that took the entire fleet out of commision for most of the summer. The Amtrak board knew this too, and even testified to that fact before Congress a few months ago. The board, though, is made up of Bush appointees. You might remember that Bush's budget proposal contained a plan to bankrupt Amtrak as a way of "reforming" it. That failed to pass Congress, and David Gunn failed to be incompetant. So you have the odd case of firing David Gunn for improving things on the railroad. Yikes. I will be so glad when this administration is gone.

I’m going to travel in Europe within the next two weeks for business reasons. The first move will be in Berlin but unfortunately, it will be for a single day (next tuesday: Nov. 15).
On the other hand, I’ll come to Barcelona on the 21st of november and will stay there for two days (coming back to Paris on 22nd). That means that I’ll be on Barcelona the evening between monday and tuesday, so if there are somme DD around, feel free to contact me so we can meet ourselves, and why not, sign our GPG keys… People interested can mail me at my usual address: sukria at sukria dot net.

I've been relatively quiet lately because I've been plodding along, working on modular packages for Xorg. For those who don't know, the next release of Xorg will actually be two releases of the same code. One release, 6.9, will be based on the old monolithic build system. This system requires me to build every single part of Xorg whenever I want to update any one part. This means that whenever I push out an Xorg fix, no matter which component it's in, you have to download all the other components even if they are 100% identical to the previous version already on your hard drive. We've all lived with this for a long time, and while it's not pleasant, we all seem to get by. The packaging apparatus for this system is mature, stable, and well understood, if complex. That's why I've been able to get the 6.9 release candidate packages out to experimental fairly quickly after they are released.

The other release happening is for 7.0, which is obviously a major version number bump. The actual code you run for 6.9 and 7.0 is 100% identical, but the build system has been totally rewritten around the venerable autotools (you know... configure /make/make install). Each piece has been split out from the others so that you can build any one component without building all the others. This means that if we want to ship a driver update, you don't have to download all of the fonts and other things that weren't touched. That also means that you won't have to install the drivers for cards you don't own if you don't want them. Furthermore, it lowers the barrier for things like hacking on X significantly.

The problem with the modular tree is that the packages for it are brand new. Ubuntu shipped modularized versions of the libraries, and I've already stolen those, fixed them up for Debian, and built them locally (they're sitting in our svn repo, but running them won't get you anything at this point.) The server and driver packages are brand new, and I've been taking the packages from Ubuntu's development branch and working on them for Debian. Today was a milestone day because in addition to the libs, with Daniel Stone's constant help I've finally managed to build packages for the modular X server itself. Now I can't run it yet (I haven't packaged the drivers and a few other bits) but the fact that I managed to produce what will be a functional server package is a huge step, and constitutes the cornerstone of the whole thing.

Once we can create packages that can actually run on at least the machines of the XSF, we can start looking at getting the packages in to the archive. Since these aren't well tested like the monolithic packages, we'll have to do a lot of polishing to get them to the same level of quality. My goal is to get that done for etch though, and I think we can do it. Exciting things are happening, and I'm hoping that the modular packages will encourage more people to hack on X, leading to even more exciting things. Build that momentum.