Here are some slides and examples I used for a kernel course I developed (some time ago now). The course was aimed at C developers who wanted an introduction to both general UNIX-style user-space and Linux kernel development with a focus on embedded systems issues. The course is aimed at two 8-hour days, and is pretty packed in even then. The first day is user-space development and kernel building, focusing on things like make, autotools, advanced gcc, getting cross-compilers working, configuring the kernel and building. The second day we get into kernel internals; building up a kernel module to produce some simple proc nodes, take data, crash and debug, etc, look at internals like concurrency and the driver model, and focus on USB quite a bit. Here is a tarball of the entire thing, including the examples. Hopefully these can help out anyone tackling the design of such a course.

• Day 1
  • Linux philosophy, people and processes
  • UNIX build environment
    • Makefiles, Autotools
  • Executable and Linker Format
  • Advanced GCC
  • Linker, Dynamic Linker, Shared Libraries
  • Cross compilation toolchain
    • Building toolchains on Debian
  • Kernel development process
  • Source control, patches, GIT, Quilt
  • Configuring and building a kernel
  • Cross compiling kernel
  • initrd, initramfs, init tools

• Day 2
  • Kernel source layout
  • Kbuild, Kconfig
  • Syscalls (x86-32)
  • Kernel view of userspace
  • Virtual Memory
  • Getting data in/out kernel
  • Crashing, Oops, backtraces
  • Various tools
    • systemtap, kprobes
    • perfmon, oprofile
    • valgrind
  • Basic constructs
    • Concurrency, locks
    • Interrupts, sleeping
    • Atomic access
    • Memory allocation
  • VFS layer
  • /proc
  • Char and block devices
  • Driver model
    • sysfs, kobjects
    • buses, devices
  • USB Overview
    • Protocol overview
    • Registering drivers
    • uevents
  • Useful development paradigms
  • Unit testing

I bought an EEE 901. More on that later.

For the past few weeks I've been trying to work out which "mobile broadband" provider to go with for my daily commute. It's a train journey from the north coast of Northern Ireland to Belfast and goes through some sparsely populated areas, so I wasn't expecting to get anything that would provide 3G all the way. However I do want a provider that can do their best to keep a session up for the journey, handing over between 2G + 3G as necessary. Coverage maps/checkers aren't too bad if you just want to check a static point, but really even then it's better to actually try the provider in the location yourself. So, armed with a bluetooth GPS (Bl eNEXT BN-909GR), an Option GT 3G Quad PCMCIA card and my laptop I set about measuring signal strength along my train journey for each of the 5 providers available. I also made sure to actually try a session with them for at least one journey, because signal strength is not everything.

I wrote some Perl using Net::GPSD and Device::Gsm to query my current location, signal strength, 2G/3G status and network every 10 seconds. I did this for 3 train journeys (except for O2) and then also produced an "optimistic" file of all the data points combined for that provider.

A second piece of Perl took this data and drew the maps you see below. The graph on the right for each provider is all data points. Red means 2G, blue means 3G, green means "Limited Service" (ie it could see a signal, but not one it was allowed to connect to). White means that we had a GPS location and no signal at all. Click on the maps for bigger versions. You can see the route on OpenStreetMap - my graphs are a little squished horizontally, but the journey is from Castlerock (top left on the coast near Coleraine) to Belfast (bottom right).







At first glance 3 look to be the best bet. Lots of blue, a reasonably priced data plan. Except they can't hold up a session to save themselves. Not only does a 2G/3G handover almost always seem to result in a drop, but I had periods of failing to get a 2G session up at all and had some random drops while in 3G coverage as well. So strike them off.

O2 and T-Mobile don't manage any 3G outside Belfast (that's the bottom right corner btw). I found that a few periods of 3G along the journey helped a lot; it meant I could do a quick mail sync rather than the long drawn out affair it was on a 2G connection. They can both handle handover between 2G/3G and keep a session up for most of the journey, but the lack of speed counts them out.

Vodafone managed the worst reception, which is disappointing. I found them quite good when I lived in England (my datacard is from a Vodafone Pay as You Use data contract). I did find sessions being dropped during the no signal regions, so they just don't seem to be a good bet.

Which leaves Orange. I've had issues with Orange and data in the past (pre 2004 IIRC) but in testing they were able to keep a session up between Belfast and Castlerock, handling 2G/3G handover fine. Coverage was reasonably good and they manage 3G at several points along the journey (the blue points roughly correspond to Coleraine, Ballymena, Antrim and Belfast). I understand Orange have some EDGE capability, but my card doesn't do EDGE so I've no idea if that'll be an extra gain or not. I had a few issues with getting dud DNS servers but this happened with the other providers too so I was beginning to suspect the datacard of playing up. Manually setting known good servers in resolv.conf worked fine.

So, before I go and sign up to an 18 month Orange contract, what have I forgotten?

I recently bought a 4GB Sansa Clip to solve the problem where once-a-week or so I want portable music or podcasts and don’t have any: namely, at the gym, occasionally when walking somewhere, and on trains and buses. I’ve been looking for something exactly like this for ages—small, attachable for use during exercise, enough space for a few hours of music/audio, OGG support, and not necessarily much more than that. Basically, an iPod Shuffle that plays OGG and doesn’t involve dealing with Apple. For the longest of time, this was pie-in-the-sky nonexistant. After a few weeks of using the Clip, I’m extremely pleased so far. The battery life is much longer than I’d ever want to listen to music for continuously (they claim 15 hours, and I haven’t gotten it down to less than half charge yet). It’s light in the hand but not too flimsy in feel, the clip makes it easy to attach to e.g. shorts, the interface is easy to use, and the sound quality is good. After upgrading to the latest firmware, it plays OGG as well as MP3. Both Rhymthbox and Banshee work for transferring files to it. I think my biggest complaint so far would be that the audio jack doesn’t fit in as securely as it could, which sometimes manifests as sound skipping and can be fixed by making sure the headphones are completely plugged in. Seriously, it was funny when my Walkman skipped during runs in 2003, but I hope I’m past that phase of life at this point. At any rate, it doesn’t happen all that often, so it’s more of a minor annoyance than anything. And well, the firmware isn’t free—but hey, can’t have everything.

(when your wife/SO is not around)

• Finally get around to play with the PowerPC you have had standing besides your desk for about a month.
• Discover that it still doesn't boot, since it can't find its hard drive. Also discover that it doesn't want to talk to your USB keyboard.
• After a while, think of removing and replugging the SAS connectors, which fixes the boot problem. The machine now runs YDL.
• Decide you want to install Debian instead of YDL, but also wonder how to do that safely since you still can't talk to Open Firmware.
• Search for the RJ45-to-serial adapter you got with the box. Discover you probably wired it wrongly the first time around. Break it when you try to rewire it.
• Find that spare DB9 connector you had lying about, find soldering iron and fix up the connector.
• Become very, very confused, since you get perfect output, but input still doesn't work. Discover you managed to solder all the connections mirrored. It worked with effectively just one wire, not even shared ground. Resolder.
• Download Debian ISO, burn it on a DVD. Get annoyed at the machine for failing to boot from the DVD.
• Set up netboot, boot from network.
• Discover d-i doesn't install a kernel, nor a bootloader, do that by hand.
• Oops, bootloader didn't work. Iterate a couple of times of running mkofboot until it suddenly feels like booting from the hard drive.

Hurrah! And it only took like six or seven hours. Notes for later: This is an YDL Powerstation, the magic mkofboot invocation is mkofboot -b /dev/sda1 --filesystem raw; the raw bit is needed for IBM hardware. The firmware also cares about whether the partition is marked as bootable or not, so make sure to mark it as such.

Lennart Pottering’s post about the sound APIs available for Linux appears to have caused some consternation from people working with the modern out of tree OSS drivers who feel that the current, out of tree, OSS drivers are being unfairly maligned. This rather misses the point of his post. The fact that there are improved versions of the OSS code doesn’t really help developers who are trying to target current Linux distributions which only ship the old OSS drivers. From this point of view the new OSS drivers are probably best looked at as a completely different product. Joss is right, though - most applications should be working with a higher level user space API than either ALSA or OSS. One of the most obvious examples of this is in the embedded space where there are often vast numbers of controls that need to be exported in order to support the complex audio routing that devices like phones can have. Most of these should only be touched very occasionally when changing use case and should therefore be hidden from normal applications where they’re at best irrelevant and at worst confuse end users. They do, however, need to be exposed by the kernel in order to allow user space the flexibility to manage the audio configuration of the system at run time.

Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

And here is what one of the devs from OSS answered to this [1]:

It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].

If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.

DISCLAIMER: Paranoid rant ahead. You ve been warned. Every two years, around this time of the year, I feel concerned: it s voting time in Brazil. For quite some time now, Brazil has had electronic voting, but that doesn t make me more confortable with it. Yes, having the results within the same day is an enormous advantage, but I am not sure about the security of the whole process. You can call me paranoid (and surely I am a bit), but there are some things that give me the creeps about it. For a start, let s look at the operational process. The voting machines are certified and sealed by Electoral Justice officers the week before the voting. They are opened in the electoral section by those officers in the presence of common citizens. Those citizens are called to work in the Electoral process usually for four or five elections in a row, being replaced after that by newcomers . The voting machines are not connected to any network. During the day, voters come with the voting document (voting is mandatory in Brazil), one of those citizens enable the voting machine by typing the document unique number in it, the voter give his vote and go home. Then the voting machine is unable to receive votes if not enabled by entering another document number, and it goes on and on the whole day long (pretty boring work ). At the end of the day, the president of the section (usually the most experienced of those citizens) close the voting machine, prints a tally sheet , hand a colored 3 -inch floppy disk to the Electoral Justice officer with the votes and go home. Other officers will pick up the voting machines later on. The first officer then goes to the voting processing central of the Electoral Justice and within hours we will know the result of the election. As you can see, there are lots of points of failure in the whole process! All this sealing of voting machines are just a matter of trust. First point: there s no way we can know for sure if the machine does what it s suppose to do. Even if officers say that they randomly choose machines to be tested, there s no way to know how random is that. There s a report [pt-BR] made by a prestigious university (English summary here), stating that 1/3 of the voting machines in a particular studied state had corrupted log-files (among other important security problems!). This study also showed differences in the countings (sometimes as large as 20-thousand votes!)... Hey! This is supposed to be a deterministic system: if nothing in the conditions changed, counts should always match! Until recently, closed-source software were used in the voting machines, but that has changed recently. I doubt that it makes any difference, since we ll never really know what is actually running in the machine. Surely, Electoral Justice officers know (or should know), so we d have to trust them So second point: we don t know how the voting is processed within the machine. (Also, we don t know for sure the machine doesn t have a network connection. It may have a wireless connection we don t know about and can be passing all the votes to someone else, or even receiving instructions But since that can be spotted with a scanner, I ll trust other paranoids have already done that.) Surely the machine must be enabled before every vote with the voters document number. If it were not, how could we know that no one voted twice, or that a non-voter have voted? But we don t know how the machine records that! Third point: we cannot know if the voting machine database doesn t link the voter to the vote. That is a nasty one it opens up the possibility of voting by intimidation . Also, the tally sheet that is printed at the end of the day only brings the total of votes, the total of absent-voters, and the votes each candidate (or party) have received. So, on to the fourth point: there s no way of knowing for sure that your vote was counted right (or was counted at all!). At least a copy of this tally sheet is glued at the entrance of the voting section, so an independent audit only on the numbers is do-able (although hard to do!). What happens to the colored disk between the voting section and the voting processing central is not known. It goes with the officer and what he does with it is just a matter of trust. Now for the most insteresting point: the security is based on the color of the disk!. The Electoral Justice checks if the officer handed the right colored disk and puts the data in the system. Surely (?) they might have some way to check data integrity other than that On the same issue, maybe even worse: even if the disk is not tampered, but just read (or copied) by the officer before being handed, and if the database links the voter to the vote, this information is valuable, and may be sold. Finally, since we don t know (and have no way to know for sure) what the machine does, we don t know if the machine keeps a copy of the voting database in it. So when it is taken back by other officers, we cannot know whether the same thing that may happen to the disk also could happen with the machine. I am missing a lot of things about the whole Brazilian E-Voting process, and also I surely have missed other points of failure. I heard of fraud in the past, with paper ballots, and those were pretty nasty frauds. But this whole tale of impossible fraud in e-voting is nothing but a tale (as fraud is more than possible!). I think we have to begin investigating other systems, surely with cryptography involved. A system like Debian s, far from perfect (we all have to trust secretary s word on the secrecy of the voting system key), is much better, for instance. I understand that it s not simple enough for non-geeks, but there might be a way! It doesn t need to be a whole new system! I would be happy if, as an example, the tally sheet printed a hash of my vote that I could verify later on or if the security of the disk is not just color-based or if the tally sheets had a way of being validated and be available on-line for auditing (and not just glued at the entrance of every voting section). Look! I am not distrusting any officer a priori... I think the message is auditing should be made easy... then I could trust a version of Linus s Law adapted to E-Voting: Given enough eyeballs, all frauds can be discovered .

I wrote before about datapacker, but I didn't really describe what it is or how it's different from other similar programs.

So, here's the basic problem the other day. I have a bunch of photos spanning nearly 20 years stored on my disk. I wanted to burn almost all of them to DVDs. I can craft rules with find(1) to select the photos I want, and then I need to split them up into individual DVDs. There are a number of tools that did that, but not quite powerful enough for what I want.

When you think about splitting things up like this, there are a lot of ways you can split things. Do you want to absolutely minimize the number of DVDs? Or do you keep things in a sorted order, and just start a new DVD when the first one fills up? Maybe you are adding an index to the first DVD, and need a different size for it.

Well, datapacker 1.0.1 can solve all of these problems. As its manpage states, "datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools." datapacker accepts lists of files to work on as command-line parameters, piped in from find, piped in from find -print0. It can also output its results in various parser-friendly formats, call other programs directly in a manner similar to find -exec, or create hardlink or symlink forests for ease of burning to DVD (or whatever you'll be doing with it).

So, what I did was this:


find Pictures -type f -and -not -iwholename "Pictures/2001/*.tif" -and \
-not -wholename "Pictures/Tabor/*" -print0 \
datapacker -0Dp -s 4g --sort -a hardlink -b ~/bins/%03d -


So I generate a list of photos to process with find. Then datapacker is told to read the list of files to process in a null-separated way (-0), generate bins that mimic the source directory structure (-D), organize into bins preserving order (-p), use a 4GB size per bin (-s 4g), sort the input prior to processing (--sort), create hardlinks for the files (-a hardlink), and then name the bins with a 3-digit number under ~/bins, and finally, read the list of files from stdin (-). By using --sort and -p, the output will be sorted by year (Pictures/2000, Pictures/2001, etc), so that photos from all years aren't all mixed in on the discs.

This generates 13 DVD-sized bins in a couple of seconds. A simple for loop then can use mkisofs or growisofs to burn them.

The datapacker manpage also contains an example for calling mkisofs directly for each bin, generating ISOs without even an intermediate hardlink forest.

So, when I wrote about datapacker last time, people asked how it differed from other tools. Many of them had different purposes in mind. So I'm not trying to say one tool or the other is better, just highlighting differences. Most of these appear to not have anything like datapacker --deep-links.

gaffiter: No xargs-convenient output, no option to pass results directly to shell commands. Far more complex source (1671 lines vs. 228 lines)

dirsplit: Park of mkisofs package. Uses a random iterative approach, few options.

packcd: Similar packing algorithm options, but few input/input options. No ability to read a large file list from stdin. Could have issues with command line length.

Yesterday, another of our mailboxes got joe-jobbed, just like last week. Again, it was one of our Exim servers (yes, one got done along with a qmail last week). Again, it was an address that should never appear as the SMTP sender. Again, I put something like

        deny
          message = 553 That address is not used for outgoing email so should never get errors - please telephone us if in error
          senders = :
          recipients = !/etc/exim4/permitted-envelopes

into /etc/exim4/local-rcpt.acl, added CHECK_RCPT_LOCAL_ACL_FILE = /etc/exim4/local-rcpt.acl to /etc/exim4/conf.d/main/02_local_options, put all permitted envelope addresses into /etc/exim4/permitted-envelopes, then ran update-exim4.conf and /etc/init.d/exim4 reload and the flood stopped. So far, it seems to be working like it should. Is there a drawback I haven’t spotted yet, apart from the obvious problem of needing to list all outgoing envelope addresses?

Russell writes about the iphone. I think he's missing a few things.

The open nature of the PC wasn't inherently what brought it greater success. The open nature of the PC meant that it could spawn an ecosystem of third party hardware vendors, sure. It also meant that it could be cheaply cloned by other manufacturers, ensuring competition that drove down the price of hardware. The net result? x86 is ubiquitous, sufficiently so that even Apple use a basically standard[1] x86 platform these days. Low prices and the wide availability of software that people wanted to run bought the PC the marketplace, with Microsoft being the real winners. Apple hardware remained more expensive for years, and the compelling MacOS software was mostly limited to areas like DTP. Nobody else had any incentive to buy a Mac.

Now, let's look at the phone market. Third party hardware vendors? No real distinction between the iphone and anything else. Sure, anything remotely clever has to plug into the dock port, but developing something to work with that also gets you into the ludicrously huge ipod market. Other phone accessories are either batteries, chargers or headphones. That's really not going to be what determines market success.

Competitive cheapness? When you have a multivendor OS like Android or Windows Mobile, you might expect there to be more opportunity to compete to undercut each other, offering equivalent platforms for less cost. But that's missing something. In the same way that the home computer market has basically consolidated towards PCs, the phone market has already consolidated. Your smartphone has an ARM in, probably along with an off the shelf GSM chip and some 3D core (generally something from Imagination, though in Android's case Qualcomm seem to have come up with their own core - I haven't been able to find out if it's derived from something else). There's no realistic way to make a phone with equivalent hardware functionality and quality to the iphone and sell it for significantly less money. And if you figure out how to, Apple get to take advantage of the same price reductions in their next generation hardware. And, being Apple, they'll probably find some compelling wonderful design feature that costs them nothing extra but makes you want it more anyway. So hardware competition probably isn't going to be what determines market success.

Which leaves two things - advertising and applications. Apple are good at marketing. This is unfortunate, because I'd really rather live in a world where everyone running MacOS was running Linux instead, but we seem to suck in comparison. The good news is that Microsoft also seem to, so maybe we'll have our act together some time between now and Apple crushing us to death. So, assuming current trends continue, Apple's marketing probably isn't going to kill the iphone. Which leaves one thing: applications.

The obvious argument against the iphone's success is that, as a closed software distribution platform, it's less attractive to developers. I don't think that's true. If we look at the console market, the gp2x was hardly a PSP killer. Or a DS killer. You could possibly argue it was a Gizmondo killer, but only if you ignore the Finnish mafia. Being an open platform doesn't immediately result in you killing closed platforms. You need developers, and you need applications. Otherwise nobody's going to buy your hardware, even if it costs $10 less than an iphone and has a few extra bits of plastic. What attracts developers? An attractive development environment and a revenue stream. Android has one real thing going for it here - it's not tied to Objective C, and so there's probably a larger number of potential developers. But let's be realistic. If you're a competent developer, you can move from C++ or Java to Objective C without too much effort. And if you're an incompetent developer, you're not going to be deciding the future of a platform.

Apple have made it easy for people to write applications that share the iphone's delightful[2] UI. There's almost active encouragement to write beautiful programs that integrate well. Sure, the platform limitations bite you in weird ways (like the no background running thing), but Apple have come up with hacks to smooth most of those over. The iphone is a wonderful device to develop for. Sufficiently delightful that there was a huge developer base even before Apple had released the SDK. What does that tell you? Developers actively want to write for the iphone. In fact, they wanted to even before there was a real revenue model. Mindshare means a lot.

What are we going to see in response from Android? To begin with, uglier applications. I'm sure that'll get better over time, but right now the Android UI just isn't as well put together[3]. It's functional, even attractive. But it's not beautiful. And lowering the bar to developer involvement means the potential for more My First Phone Application. Windows Mobile and Symbian have huge numbers of applications. They're mostly dreadful lashups of functionality you'd never want and a UI that's ugly enough to make you want to stab out your eyes, coupled with a nag screen asking for a $10 donation to carry on using it assuming it hasn't crashed before it got that far. To be fair, a lot of iphone stuff isn't much better. But proportionately? Right now the Apple stuff has it. I never want to see another listing of Symbian freeware.

At the moment, Apple wins at providing compelling applications. They may be a gatekeeper between the developer and the user, but right now that's not causing too many problems. Well. It wasn't. The recent fuss about Apple dropping applications because of perceived competition with their own software is an issue. If a developer is going to spend a significant amount of time and money on an application, they want a reasonable reassurance that they're going to be able to ship it. And, right now, Apple's not giving that. It remains to be seen whether this has long term consequences, but there's some danger of Apple alienating their developer base. If those developers move to another platform, and if they create compelling software, Apple might stand some real competition. At the moment? Apple has the hardware, the OS and the applications. They have the potential to take over broad swathes of the market. But they also have the opportunity to throw it away. And that's what's going to decide the success of the iphone - a closed platform is not inherently a problem, but it gives the vendor the option of removing one of their key advantages. If Apple get through this with their developer popularity intact, I don't see the open/closed distinction as having any real-world importance at all.

The relevance to Linux? We're not going to succeed by being philosophically better. We have to be better in the real world as well. Ignoring that in favour of our social benefits doesn't result in us winning.

[1] It's slightly more legacy free than a "genuine" PC - there's no i8042, and things like the gate A20 hack aren't implemented. But it'll boot DOS (given enough effort), so hell, it's a PC

[2] And yes, I genuinely do think that the iphone's UI is better than anything else on the market. There's no reason someone else, including us, couldn't have got there first. But we didn't, and now everyone gets to play catch up. Shit happens

[3] I have no idea where Apple gets its UI engineers from, but someone needs to find the source and start waving huge piles of money to pick them up first.

Dear American: I need to ask you to support an urgent secret business relationship with a transfer of funds of great magnitude. I am Ministry of the Treasury of the Republic of America. My country has had crisis that has caused the need for large transfer of funds of 800 billion dollars US. If you would assist me in this transfer, it would be most profitable to you. I am working with Mr. Phil Gram, lobbyist for UBS, who will be my replacement as Ministry of the Treasury in January. As a Senator, you may know him as the leader of the American banking deregulation movement in the 1990s. This transactin is 100% safe. This is a matter of great urgency. We need a blank check. We need the funds as quickly as possible. We can not directly transfer these funds in the names of our close friends because we are constantly under surveillance. My family lawyer advised me that I should look for a reliable and trustworthy person who will act as a next of kin so the funds can be transferred. Please reply with all of your bank account, IRA and college fund account numbers and those of your children and grandchildren to wallstreetbailout@treasury.gov so that we may speedily transfer your commision for this transaction. After I receive that information I will respond with detailed information about safeguards that will be used to protect the funds. Yours Faithfully Minister of Treasury Paulson **** The source of this? A former U of C graduate anthropology classmate. This actually may be the original source, or like all really good spam, somewhat (seemingly at least) sourceless.

First root canal today. There were some interesting parts. I'll spare you. If I seemed a bit annoyed with awesome 3 configuration in the last post, this has put it well in perspective. One nice thing about awesome 3 is that it has good system tray support built in. So I've at least temporarily mainstreamed my laptop, so it's using the gnome power manager, and network manager, instead of hibernate and sleepd and my own scripts.

I ve been silent in this blog last few days, but that has an explanation: I ve been trying to make JRuby 1.1.4 work with one of my scripts. The problem is that after having done all the tweaks I can imagine, I still can t get enough performance with Ruby 1.8.7 (latest etch-backports). Our client will not allow Ruby 1.9 in the server (what is really a pity, for the performance boost I had with Ruby 1.9 is awesome!), but it already have Java6 So the only option I have left is trying JRuby beast. Since our script deals with system stuff, it uses syslog a lot, and that is where the main problem seems to be. Syslog support is new in JRuby, has had some implementation problems, and sure are not something to rely on right now so I dropped it from the script, and it run! Twice as fast (not as good as Ruby 1.9, though)! There are some other problems with this script and JRuby, more important ones being (1) at_exit doesn t work; and (2) errors are not easy to backtrace (when JRuby fails it seems to mess up with the backtrace stack), but not preventing it to work So with the increased performance of JRuby, and after fixing those minor glitches, I was still left with the syslog problem Until I investigate some final solution (I think I ll have to use some Java native syslog library given such a thing exist), I ve split the script in performance-boost needing and syslog-needing parts; the first is using JRuby, and the second, Ruby 1.8.7 They communicate using sockets (I know ugly I would like to use DRuby, but I would not introduce another point of failure in an already messy situation) and the overall performance was brought to a satisfactory level. So far, it s been interesting to study the issue Mainly because I haven t used JRuby since it s early versions, and it has improved a lot. But also because I read a lot about the future of Ruby (bytecode compilation, YARV and so on), and it made me even happier with my primary-do-it-all programming language. Now I ll try to compile java bytecode generated by JRuby into a native binary with GCJ :-D. Let s see if that is do-able Updated 2008-09-24 18:03:00: As you can see in the comments, syslog actually works. I figured this out this morning, but JRuby Subversion already had a patch. Anyway, I submitted another bug I found.

Just spent a good two^Wthree hours trying to configure awesome 3.0 to match my awesome 2.x setup. Docs are effectively nonexistant. So far, I'm stuck on several fronts:

• I want to be able to left click on a titlebar and drag to resize. Without pressing the modkey. But the definition for that is set deep within awful.lua, which is not a configuration file, and so I cannot see a good way to configure it.
• Why can't I resize an xterm to 80 characters wide? It jumps between 79 and 81.
• Why is it that despite using the same font as with 2.0, enough additional vertical space is used by the title bar and status bar, that I get one less line in all my xterms? It's using only a few pixels more than before, but that's too much..
• How do I configure a textbox so that, if I click on it, a command is run? Update: Figured this one out, for example: mympd:mouse_add(mouse( , 1, function () os.execute("awesome-mpd show &") end)) (Note that if the command isn't run in the background, and opens a window, it will deadlock awesome.)
• Can't figure out how to use awesome-client to add a value to a graph widget. (I'm sure this is simple, but I haven't stumbled over an example. I'd use wicked, but it's not packaged.) Update: Figured it out via the source: mpgraph:plot_data_add("foo", "10")
• Can't figure out how to make a textbox widget have a fixed width and truncate the text in it. Since it's displaying the currently plaging song, using the default dynamic width would make everything on my status bar jump around. Update: mytextbox.width=100
• There's no emptybox widget aymmore, so how do I add horizontal padding between widgets? Best I've managed so far is an empty textbox with a defined width.

Anyone else hate lua, or at least build-your-own-WM-in-lua config files for window managers that used to have simple config files?

I’ve just installed Eran Sandler’s OpenID Delegation Plugin [1]. This means that I can now use my blog URL for OpenID authentication. I’ve also included the plugin in my Wordpress repository (which among other things has the latest version of Wordpress). One thing that I consider to be a bug in Eran’s plugin is the fact that it only adds the OpenID links to the main URL. This means that for example if I write a blog comment and want to refer to one of my own blog posts on the same topic (which is reasonably common - after more than two years of blogging and almost 700 posts I’ve probably written a post that is related to every topic I might want to comment on) then I can’t put the comment in the URL field. The problem here is that URLs in the body of a blog comment generally increase the spam-score (I use this term loosely to refer to a variety of anti-spam measures - I am not aware of anything like SpamAssassin being used on blog comments), and not having OpenID registration also does the same. So it seems that with the current functionality of Eran’s plugin I will potentially suffer in some way any time I want to enter a blog comment that refers to a particular post I wrote. deb http://www.coker.com.au etch wordpress My Wordpress Debian repository is currently available with the above APT repository. While it specifies etch it works with Lenny too (my blog currently runs on Lenny). I will eventually change it to use lenny in the name. For the OpenID server I am currently using the OpenID service provided by Yubico as part of the support for their Yubikey authentication token [2] (of which I will write more at a later date). I think that running their own OpenID server was a great idea, it doesn’t cost much to run such a service and it gives customers an immediate way of using their key. I expect that there are more than a few people who would be prepared to buy a Yubikey for the sole purpose of OpenID authentication and signing in to a blog server (which can also be via OpenID if you want to do it that way). I plan to use my Yubikey for logging in to my blog, but I still have to figure out the best way of doing it. One thing that has been discussed periodically over the years has been the topic of using smart-cards (or some similar devices) for accessing Debian servers and securing access to GPG keys used for Debian work by developers who are traveling. Based on recent events I would hazard a guess that such discussions are happening within the Fedora project and within Red Hat right now (if I worked for Red Hat I would be advocating such things). It seems that when such an idea is adopted a logical extension is to support services that users want such as OpenID at the same time, if nothing else it will make people more prone to use such devices. Disclaimer: Yubico gave me a free Yubikey for the purpose of review. Update: The OpenIDEnabled.com tool to test OpenID is useful when implementing such things [3].

• [1] http://eran.sandler.co.il/downloads/openid-delegate-wp-plugin/


• [2] http://www.yubico.com/


• [3] http://www.openidenabled.com/resources/openid-test/checkup

Share This

Thanks to Wolfger for pointing out an HTTP 500 while trying to greet me by comment. :D I totally forgot about upgrading Net::Akismet to the new version that comes with my patch, as described previously. All the while I was thinking Net::Akismet was doing too good of a job keeping out comment spam, when it may as well have kept out all comments :( But its my fault, really. Among other things, Jerome has finally started a new grassroots group for the OLPC effort here in the Philippines, fresh from the success at the recently-concluded SFD. There's now an IRC channel up too, with logs available locally (text-only, until I can set up a web and fileserver frontend.) I'm personally interested on running a port of Inferno and perhaps help out on the TODOs for it.

Just stumbled over this meme at Adrian (the meme seems to be started by madduck involuntarily), and since I’m fascinated by how people choose hostnames since my early years at university, I can’t resist to add my two cents to this meme. To be exact, I have two schemes, one for servers out there somewhere (Hetzner, xencon, etc.) and they’re all wordplays on their domain name noone.org, e.g. symlink.to.noone.org (short name “sym” :-), gateway.to.noone.org (usually an alias for one of the machines below), virtually.noone.org (always a virtual machine, initially UML, soon a Xen DomU), etc. So nothing for a quiz here. My other scheme is for all my machines at home and my mobile machines. I’ll start this list with the not so obvious hostnames, so the earlier you guess the scheme, the better you are (or the better you know me ;-). One more hint in advance: “(*)” means this attribute or fact made me choose the name for the machine and therefore can be used as hint for the scheme. :-)

azam

My first PC at all, a 386 with 25 MHz and MS-DOS. (Got named retroactively(*). Hadn’t hostnames at that time.)

ak (pronounced as letters)

Got it from my brother after he didn’t need it anymore. It initially was identical to azam, but once was upgraded to a 486. Still have the 386 board, though.

azka

My first self-bought computer, a pure SCSI system with a AMD K5-PR133 and 32 MB RAM. Initially had SuSE 4.4 and Windows 95 on. Still my last machine which had a Windows installed! :-)

m35

Same case and same speed as azka. Used it for experimenting(*) with Sid years ago.

azu

Initially also an AMD K5-PR133, later replaced by a Pentium 90 and used as DSL router.

azl

An HP Vectra 386/25N book size mini desktop I saved from the scrapyard at Y_Plentyn before his (first) move to Munich. The cutest(*) 386 I ever saw.

ayce

A 386 with 387 co-processor(*) and solded 8 MB of RAM.

ayca

A 1992 Toshiba T6400C 486 laptop bought at VCFe 5.0.

bijou

My 1996 ThinkPad 760ED, which is still working and running Debian GNU/Linux 5.0 Lenny (I started with Debian 3.0 Woody on it and always dist-upgraded it! :-)

gsa (pronounced as letters)

My long-time desktop after azka. A Pentium II with 400 MHz and 578 MB of RAM at the end. Bought used at LinuxTag 2003, it worked until end of last year when it started to suddenly switch off more and more often and now refuses to boot at all. Hasn’t been replaced yet though. I mostly use my laptops at home since then.

gsx (pronounced as letters)

An AMD K6 with 500 MHz I got from maol and which was used as Symlink test server more than once. (It was the machine initially named symlink.to.noone.org because of that.)

hy

My 32 bit Sparc, a Hamilton Hamstation.

hz (pronounced as letters)

My 64 bit Sparc, an UltraSparc 5.

tub

An HP Apollo 9000 Series 400, model 400t from 1990.

tpv (pronounced as letters, too ;-)

My Zaurus SL-5500G.

tryane

A Unisys Acquanta CP mini desktop with a passively cooled(*) 200 MHz Pemtium MMX. Used as DSL router for while, but the power supply fan was too noisy.

lna (pronounced as letters)

A 233 MHz Alpha

loadrunner

An IBM ThinkPad A31 running Sid. I use it as beside terminal.

pony

A Compaq LTE5100 laptop with a Pentium 90 running Sid.

dagonet

A Sony Vaio laptop which ran Debian GNU/kFreeBSD until it broke.

Those who know me quite good should already have guessed the scheme, even if they can’t assign all the names. For all others, here’s one name which doesn’t exactly fit into the scheme, but still is related in someway, but you need to knowledge of the theme’s subject to know the relation:

colani

A big tower from the early 90s designed by Colani.

Ok, and now the more obvious hostnames:

rosalie

A very compact Toshiba T1000LE 8086 laptop running ELKS and FreeDOS.

amisuper

Also an old Symlink test server from maol. He named it “dual”. 2x(*) Pentium I with 166 MHz. Unfortunately doesn’t boot anymore.

visa

An IBM NetVista workstation running Debian GNU/kFreeBSD. My current IRC host.

nemo

My ASUS EeePC running Debian 5.0 Lenny.

pluriel

My current WLAN router running FreeWRT.

c1

My MicroClient JrSX, an embedded 486SX compatible machine with 300 Mhz for VESA mountings.

c2

My MicroClient Jr, an embedded Pentium MMX compatible machine with 200 Mhz for VESA mountings.

c-crosser

My Lenovo ThinkPad T61 running Debian 5.0 Lenny.

c-cactus and c-metisse

The KVM based virtual(*) machines on c-crosser running Sid and Debian GNU/kFreeBSD.

jumper

My NAS(*) at home, currently a TheCus N4100. Soon to be replaced by some Mini-ITX box.

Any one who hasn’t guessed the scheme yet? For those understanding German it’s explained at the end of my old hardware page. For all others I suggest either to look at the domain name in my e-mail address (no, it’s usually not noone.org). Still not clear? Well, feel free to ask me for all the gory details or mark the following white box to see the scheme as well as the explanations for nearly all hostnames hidden in there:

All the machines are named after Citroëns. Old machines after old Citroëns, current hardware after current Citroën models or prototypes. Those names starting with “A” are 2CV derivatives since the 2CV was Citroëns “A” model. “AZ” was the 2CV, AZU and AK were 2CV vans and everything starting with AY (e.g. AYA, AYA2, AYB – but those don’t sound that nice ;-) is Dyane based, but I currently only use Méhara names (AYCA is the normal Méhari, AYCE the 4x4 version). Interestingly not everything starting with AYC is a Méhari: AYCD was the Acadiane, the Dyane van. HY and HZ are variants of Citroëns “H van” (HX, HW and H1600 as well, but they don’t sound that nice), TUB was the pre-WWII “H van” prototype and later the nickname of the “H van” in France. TPV was the name of the pre-WWII 2CV prototype and an abbreviation for Toute Petite Voiture (French for “Very Small Car”), hence the Zaurus, my smallest Linux box, got that name. Rosalie was the nickname of a rear-wheel drive pre-WWII Citroën. M35 was a Wankel engine prototype of the Ami 8 and the Ami Super was the 4 cylinder version of the Ami 8. Bijou was a 2CV based coupé build by Citroën UK in the late 50s and early 60s. Visa and LNA were 2CV predecessors which were available with 2CV engines, but were stopped before the 2CV. GSA and GSX are GS late derivatives. C1, C2, (C3) Pluriel, C-Crosser, Jumper and Nemo are current Citroën models and C-Cactus and C-Métisse are recent Citroën prototypes and show cars. The 2CV Dagonet was an aerodynamically optimised 2CVs by Jean Dagonet in the 50s. The Tryane is an aerodynamic and fuel efficient, three wheeled car by Friend Wood based on the 2CV and with a body of wood. And Colani once dressed a 2CV so that it broke several efficiency world records. The Namco Pony was a 2CV based light utility truck (similar to the Méhari, but with steel body) built in Greece under license in many variants. And Loadrunner is the name of some CX six-wheeler conversions.

Some links about the naming items:

• Tryane II
• An original Loadrunner and a just recently built Loadrunner. I even saw the base of exactly that one in RL shortly before it was converted into a Loadrunner.
• Luigi Colani
• Dagonet
• Namco Pony
• C1, C2, C-Crosser, C-Cactus, C-Métisse, Pluriel, Nemo, Visa, LNA, GSA, Ami Super, Rosalie
• AZAM, AZL, AZKA, AZU, AK, AYCD, Bijou, TPV
• HY, HZ, TUB.

Hope you had fun. I had. ;-)

Now playing: Willi Astor — Gwand Anham Ära

Due to Sarah Palin’s nickname, the Republican National Convention has been playing the tune “Barracuda” by a group named Heart. Being very much not a child of the 1970s, I’d never heard of Heart. But after reading this hilarious letter, I took a listen, and it’s pretty good music. I think this fantastic letter is as good a reason as any to buy their album…

After a short discussion time, my proposals have been ACK'ed and we will have 63 languages supported, including English, in Debian Installer for Lenny. Etch had 58 supported languages. The final winners are (alphabetical order of ISO code): Amharic, Arabic, Belarusian, Bulgarian, Bengali, Bosnian, Catalan, Czech, Welsh, Danish, German, Dzongkha, Greek, English, Esperanto, Spanish, Basque, Finnish, French, Irish, Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian, Italian, Japanese, Georgian, Khmer, Korean, Kurdish, Lithuanian, Latvian, Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch, Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese, Romanian, Russian, Northern Sami, Slovak, Slovenian, Albabian, Serbian, Swedish, Tamil, Thai, Tagalog, Turkish, Ukrainian, Vietnamese, Wolof, Simplified Chinese, Traditional Chinese Newcomers for Lenny are: Amharic, Welsh (back), Irish, Marathi, Northern Sami, Serbian We lost Estonian which was in Etch. Those that missed the deadline are of course all other languages of the world. We will put focus on languages where an effort started at some moment but could not be complete enough: Afrikaans, Estonian, Persian, Armenian, Icelandic, Kazakh, Kannada, Kashmiri, Lao, Malagasy, Malay, Sanskrit, Secwepemctsin, Telugu, Urdu, Xhosa Many thanks to all translators for this final effort. Thanks also to all people who urgently popped up last week to complete the translations for languages that were "orphaned". I hope this will bring us more translators...:-) I keep special thanks to Frans Pop here. He is, along with me, the author of the code that allows us to split D-I translations in "sublevels", allowing translators to focus on the most "important" messages. He also implemented prior warnings when users pick up a language where some less important screens aren't translated. This also allows us to more easily keep partly complete translations, or activate languages earlier. Without this, 11 languages should have been dropped.