I just tried installing the hurd for qemu environment.the Debian official ports page seems to be up-to-date and good. Which is nice to know.

You're welcome.

Today, Terah:

• Wrote about multimeters


• Linked to a website selling "the only combination impact and torque tool designed to meet your wire termination requirements"


• Linked to a site named vanguardpipe.com


• Mentioned that her favorite version-control system is CVS

And all of that in a single blog post (which is also very amusing). Oh, and on Tuesday, she wrote about debconf.

I think this is the surest evidence yet that both Terah and I are geeks. She claims that only one of us is. What does everyone else think?

I should also add that she has strong operating system preferences (OS X or Linux), likes OpenOffice, uses Firefox and IMP, used Pine as her first email system when she was a student at Purdue, remembers using telnet, uses ssh to this day, and is more bothered than I am when the Internet link goes down.

That's right, more bothered than a Debian hacker.

She's talking about forming a "wives of geeks" BoF at debconf. I think just a simple "geeks" BoF would be fine.

First, don't get me wrong. The project is really interesting, i haven't played with a beta yet but so far it looks real good. I've some doubts about the UI, but it isn't what this post is about. I think that X0 will fail here in Brazil.

The Brazilian government doesn't want to buy the laptop to some children in public schools (the poor pay for it through taxes, the not so poor pay for private schools and the public ones through the same taxes). The gov't is going to give it to some teachers to motivate them and will try to add X0 in the daily routine of a school. The cons of this approach:

• X0 can be the next big thing, but if only teachers and children in public schools will use this, it won't have appeal here, it will be discarded and treated like a complicated toy. They want what's on TV, the TV ads here are really big. e.g: We don't have iPods ads, these children don't want them, they want some of the crap mp3 player models simple because there are ads on tv and people with some more money actually buy them
• Come on, people are talking about customize the shiny new X0 interface for teacher usage here. What's their problem? There's a lot of gadgets with similar set of features in a way that if the gov't cut the abusive taxes over the products, the teachers can benefit instantly. The X0 is for children, they want to buy tons of these to teachers, but it seems that the goal isn't "let the teachers own it and show the children how to use". It's more a "let us hack the toy for teacher daily usage"
• There's no clear plan on how to integrate this project with the current gov't telecentres one going on. I'm participating in a national telecentre project and some local ones. We're talking about kiosks with 20 thin-clients and one server and 5000 subscribed people on each (medium) - hours for free web navigation and reserved ones for classes. These telecentres are located on the areas with lower human development index. What's the appeal here? Well, PCs are on tv, orkut and youtube too. They want to be part and they're. I'm sure that using the money we're going to spend in X0's the way the gov't wants to use them, that's better spend this on telecentres and the current low priced PCs programs, including more people.

We've a huge cellphone market here, initiatives like OpenMoko would work way better than X0. The cell phone companies would sell the phones (eg.: Neo1973) to the people that can buy (just a few teachers in really poor areas haven't cell phones yet) and the gov't could give one for each children in the public schools. There's a gov't program that try to keep the children in the public schools giving the family (when it's really poor) some money. The same rules could be applied for the cell phone usage, if you leave the school, you loose the gadget. Let us give the kids something that's more than useful and they need. We can give them something they want. I want one X0, but the teachers and children here doesn't. I'm sorry, somebody should tell you about what's really going on here, sometimes it's much more about social aspects than tech specs.

I wonder if we should do some RDF representation of packages - especially including dependency data. That way we can maybe use some RDF reasoners to query our data, and maybe extract some interesting information. On the other hand, people with interest in RDF to use our real-world data for their experiments, and maybe we get something back from them. There is a couple of package metadata we currently are not tracking inside the actual archive, but in different places. Including licensing information (debian/copyright), homepage location (on packages.qa.debian.org), download location (debian/watch) - it would be nice to aggregate these into some RDF store, and export them somehow. For most of the package information (especially dependency information), we'll have to write our own ontology (I wonder if we can map version numbers to some standard rule language, or if applications will need an external reasoner to process them?); for some things we can reuse the FOAF (Friend-of-a-friend) or DOAP (Description of a project) ontologies. The first is rather common for describing people, people-people and people-thing relationships; the latter was designed for describing opensource projects (but won't be directly applicable to packages of a project). I've blogged about my RDF export of Debtags data before; the canonical first step would actually have been to export the package data, and enrich it with the Debtags collected data... Note that RDF is designed in a way that you can have one site provide metadata for another site. For example, the Debtags RDF export contains "category" information for Debian packages, but does not contain e.g. the description of the packages it talks about via an URI. So there is nothing wrong from a RDF point of view of keeping e.g. the licensing, watch or homepage data separate. For the Google Summer of Code, there was a proposal including "collaborative repository of meta-informations about source packages (CRMI)"; but the first part of the proposal, the "distribution wide tracker tool (DWTT)" showed to be a bigger task than expected. But maybe we'll still see CRMI at some point, and maybe we can have it provide an RDF export of data (using a semantic wiki might be a good starting point for CRMI maybe?). [P.S. this blog posting maybe belongs more into the en/linux/debian category. But only the xml category is also syndicated on planet.XMLhack, and I want this post to go there to reach more RDF users. I really need to switch my blog to some software which supports tagging...]

Ruby's thread more "functional" than OCaml's I'm relaxing some of mine initial bad impressions on Ruby. This is mainly due to the fact that the Ruby book I ordered on Amazon finally arrived (after a lost shipment, the first of my whole customer story with Amazon, happily they refunded me completely). In the book I managed to find a rigorous (though not formal as I would have liked) description of Ruby's semantics and even some snippets of the grammar of the language (Rant: how the heck is possible that a modern language like Ruby lacks a complete description of its grammar????). Anyhow, now I'm feeling more comfortable with the language and I'm starting to put in the right setting some of what I believed to be its rough edges. Today, playing with Ruby's threads, I discovered a function in Ruby's Thread API that I can't help noticing is "more functional" than corresponding features in the Thread API of my beloved OCaml. Using Thread#value indeed the value returned by the last statement executed in a given thread can be retrieved (note that in Ruby every statement returns a value: yet another functional pearl). It's like a Thread#join on steroids. In OCaml the only way (that comes into my mind) to do the same is establishing a (typed) channel among the thread creator and the created thread, sending a return value from the thread, and having the creator block on the matching receive. Or (please don't) ... you can use a global variable ... Neat Ruby threads. To balance this, according to my first read of Ruby's threading capability, it's my impression that not only at most one thread can execute Ruby code at a time (limitation shared by OCaml, due to the non-distributed nature of mark and sweep garbage collectors), but also a thread blocked on a syscall will block all other threads to run. Dumb Ruby threads (but I still hope I'm wrong ...)

Python scoping How do you create a list of similar functions in Python? As a simple example, let's say we want to create an array of 10 elements like this:

a[0] = lambda x: x
a[1] = lambda x: x+1
a[2] = lambda x: x+2
...
a[9] = lambda x: x+9

Simple:

>>> a = []
>>> for i in range(0,10): a.append(lambda x: x+i)
...

...but wrong:

>>> a[0](1)
10

What happened here? In Python, that lambda x: x+i uses the value that i will have when the function is invoked. This is the trick to get it right:

>>> a = []
>>> for i in range(0,10): a.append(lambda x, i=i: x + i)
...
>>> a[0](1)
1

What happens here is explained in the section "A Jedi Mind Trick" of the Instant Python article: i=i assigns as the default value of the parameter i the current value of i. Strangely enough the same article has "A Note About Python 2.1 and Nested Scopes" which seems to imply that from Python 2.2 the scoping has changed to "work as it should". I don't understand: the examples above are run on Python 2.4.4. Googling for keywords related to python closure scoping only yields various sorts of complicated PEPs and an even uglier list trick:

a lot of people might not know about the trick of using a list to box variables within a closure.

Now I know about the trick, but I wish I didn't need to know :-(

Aigars Mahinovs mentioned that it would be nice if applications would not clutter the home directory with their config files as much. I agree a lot. Dotfiles for configuration suck badly. If you start a new application (or if you are in an early stage and have a small userbase), please follow the Freedesktop.org XDG base directory specification. I.e. use .config/applicationname instead of .applicationname for configuration files (unless an overriding environment variable is set), and .local/share/applicationname for data files. And for cache files, use .cache/applicationname (anyone writing a patch for firefox?) What I'd also like to propose is to reduce the number of different configuration file syntaxes. It sucks having to find out which syntax an application uses again and again, because every application is different. We probably won't be able to convince everybody on one format, but we could maybe cut it down to, like 3 formats, please? There is no reason that one application needs to start comments with "#" and another with ";" while a third application uses "//" but doesn't allow "/* comment */"... A small set of syntaxes (preferrably with standardized parsers) should be good enough for just about every application:

• key=value pairs, quotations optional, comments match "^\s*#"
• ini-style configuration files with limited nesting
• JSON syntax (nesting, all strings quoted)
• XML files (arbitrary nesting, mixed contents, repeated elements)

If we had just these few syntaxes and an appropriate schema description language, we could write generic configuration file editors. That would be very nice. Also we avoid having config file parser bugs by using libraries, and if someone prefers using e.g. gconf or dconf, this could be handled by the library, transparently for the application. (Note that many application lack error handling when writing their configuration files, especially when the disc is full... - they really should be using a library. IIRC xchat also has some bugs of this kind, I remember having tried to patch some of them once when we were preparing for the sarge release, just to find out that there might be many more of them...)

Steve Jobs: “You don t want your phone to be an open platform.” More Steve Jobs: “These are devices that need to work, and you can t do that if you load any software on them. That doesn t mean there s not going to be software to buy that you can load on them coming from us. It doesn t mean we have to write it all, but it means it has to be more of a controlled environment.” It’s widely understood that Microsoft beat Apple in the PC game because Apple was a tightly integrated, closed platform, whereas Microsoft was an open ecosystem where anyone could play (albeit at their own peril). Clearly, the strategy has not adapted well to digital media players. Why? Because people are tired of products that don’t work. Anyone who has ever had to glue a PC back together for a family member knows what I mean. Does “open” have to mean “poorly integrated” though? Clearly, I don’t think so, given how much I’ve invested in Linux over the years and how much I’m investing in the LSB now. And the job the distributions do in the Linux world is nothing short of amazing, if you think about it—taking thousands of moving parts written by thousands of different people and crafting them into what appears, for the most part, to be an orchestrated whole. Personal experience bears this out too—it’s not that the entire Windows Media ecosystem produces bad products (iTunes pales in comparison to Rhapsody), it’s that the integration points are extremely fragile (e.g., I tried Rhapsody To Go with a Plays For Sure device, which was an awful experience). In other words, just like a chain, an open ecosystem is only as strong as its weakest link, because it’s the links where things break. Sure, there are bad products. I’ve owned no less than two MP3 players in the last few years, and they were pretty terrible. It’s the very, very simple things too. For example, I listen to a lot of podcasts. There’s (gasp!) a Podcasts menu on the iPod, whereas on every other device I’ve owned, podcasts are interspersed with the music, making them difficult to find and, adding insult to injury, mixing gobbledygook into my otherwise well organized collection. Furthermore (gasp!), the iPod keeps track of which podcasts I listen to, and in concert with iTunes, automatically deletes the ones I’m done with. Them’s lasers! Ah, iTunes. Despite the fact that anyone in the world can write a podcatcher (it’s just RSS with enclosures, fer godsakes), the only one I’ve ever used that works worth a damn is iTunes. Everything else is just “integrated” with bailing wire—create a Windows Media playlist, drop it in this directory, etc. The situation on Linux is a bit better, but guess what—Rhythmbox, Banshee, etc. didn’t work with either of the open media players I owned, even though the integration point for one of them was the file system. No, the players on Linux support the iPod best because that’s what everyone has, and if I’m going to pay extra for the iPod, aren’t I primarily buying the integrated experience? (On a related note, I’ve never understood why people pay top dollar for Macs and install Linux on them. But I digress..) Once you taste the fruit of the integrated experience, it’s easy to get sucked in all the way. I eventually tired of all the wasted time and money trying to use an open media player and broke down and bought an iPod. Not too long after, I canceled my Rhapsody subscription. Why? Because I couldn’t use it with my iPod. My overall music experience is diminished (I’m a big believer in the celestial jukebox), but I want one music platform, not two. And the iPod is the one with critical mass. Anything else is swimming upstream. Are open platforms doomed then? I think that’s, as they say, throwing the baby out with the bath water. The key is to have open interfaces, and the key to having open interfaces that work is cooperation between the vendors that implement them. Perhaps surprisingly, the iPod is a good example of how it can be done. The biggest reason for my iPod purchase: I can hook it directly into my car stereo instead of using an FM transmitter. Apple isn’t getting into the car business—it’s decided to cooperate with other companies to make this work. And you don’t hear too much about people calling their technophile relatives to come glue their cars back together. (And talk about the importance of not crashing..) The lesson here, it seems to me, is that an ecosystem is never the sum of its parts—it’s either a whole lot more or a whole lot less. Furthermore, it’s the responsibility of the vendors (and community) that make up that ecosystem to ensure the result comes up on the right side of the equation in the final analysis.

iPhone is cool in a lot of ways (except in the freedom side, but not too different than the current iPods). I wish to buy one until the xmas and replace my now obsolete looking LG model. I think if Apple is trying to promote this product as 'more an iPod than a phone' - as Steve Jobs said in an inteview. They give it the wrong name, it should be called: iPod Phone. Yes, same deal as they did with the iPod video thing until they 'merged' the feature on the iPod brand. Remember that it would save them from the current trouble with Cisco/Linksys too.

The multitouch screen on that thing looks promising. I'm sure that there are a lot of cooler screens in development out there right now, but if Apple (or the real manufacturer behind the screen) can manage to make larger ones, i can see some time in the next year the motto: "Do you remember where did the computer go?" "Where did the keyboard and mouse go now?". Ok, maybe a bit too optimistic (they could keep the keyboard and throw away the mouse), but i think the iMacs could be a interesting target for the multitouch thing. Considering they've iSight already in place, with a larger multitouch screen in a good position and shiny cool gestures software, there we've minority report ready desktops, some time after laptops. Can you hear chairs?

A post by Scott James Remnant describes how to hide command-line options from PS output. It's handy to know that but that post made one significant implication that I strongly disagree with. It said about command-line parameters "perhaps they contain sensitive information". If the parameters contain sensitive information then merely hiding them after the fact is not what you want to do as it exposes a race condition!

One option is for the process to receive it's sensitive data via a pipe (either piped from another process or from a named pipe that has restrictive permissions). Another option is to use SE Linux to control which processes may see the command-line options for the program in question.

In any case removing the data shortly after hostile parties have had a chance to see it is not the solution.

Apart from that it's a great post by Scott.

Yesterday I went to activate phone service out at the farm. It got me to thinking a bit about how things change, and how they stay the same, too.

Before I go on, I'll have to say that every one of my history books is in storage, so if I get some details wrong, it's because I'm not remembering correctly.

Anyhow, phone service came to our community via an unusual route about 100 years ago. It wasn't Bell/AT&T or some other company that brought it there, as it was most places. I'm sure they figured that a small, scattered rural community would cost too much to support. So the community organized, built, and supported the phone system themselves.

Even today, roads around here can be impassible after a good rain. I'm sure that, in the early 1900s, before heavy road-maintaining machinery, things were worse -- and, of course, transportation was a lot slower then anyway. There were real problems: getting the word out about funerals, being able to summon a doctor when necessary, or letting people know that church was cancelled because of too much snow.

People in the community saw a phone system as a real need. So did the churches, which have left a legacy that is still reflected in phone company territories today.

Once phone service arrived, it was used for all the things that people expected, of course. But it also proved to be an important part of the social fabric of the community. Since party lines were the norm, it was possible to announce things to every listening subscriber pretty quickly. Older people remember announcements of fresh fruit arriving at the grocery store, funerals, or other news of the day.

To place a call, you would pick up your phone and turn your crank. That caused a bell to ring at the telephone office, which everyone called "Central." The operator would connect to your line and ask whom you wanted to talk to. The operator would then send the distinctive ring for your party down their party line, and patch -- manually -- your call through to them. And, if he was busy, the operator wouldn't listen in on your conversation -- but others on the party line very well might.

Central's hours were published. If you were making a call in the middle of the night, you were going to wake up someone at Central to do it -- plus everyone on the entire party line. So calls after hours were rare.

Fortunately, while some of the old Central operators were still around, some people in the community wrote down some of their stories.

There were some people in the community that were notorious for eavesdropping on other people's conversations. Two brothers one time figured that they knew somebody was listening to their conversations, so they devised a code. One called the other, and said, "I'll be going to McPherson in the morning for band practice." That meant something along the lines of going to town to buy groceries.

A few days later, their prime suspect came up to him and said, "What on earth are you going to band practice for? I didn't know you knew how to play an instrument!" Apparently she realized she was had when he burst out laughing uncontrollably.

The Central operators learned to know the habits of telephone users. Sometimes they would connect calls without even bothering to ask who people wanted to talk to -- and seemed to always get it right.

The phone system supported itself for about 50 years. But as the rest of the world moved on provide direct dialing, this proved a controversial subject in the community. People liked having their operators. The people that worked at Central were everybody's friend. They were people that were there, 24 hours a day, to assist with any emergency. They would gather volunteer firefighters to help fight a fire, or be able to spread community news quickly. This wouldn't be available with the newer phone systems. How would the community be informed of events quickly now? Who would just happen to know whose house the doctor was at when he was urgently needed?

The change was resisted for some years, but eventually the finances of the telephone cooperative turned out to be in deep trouble. Operators grew to be much more expensive than automation, and in the late 1960s, the telephone cooperative was no more -- sold to a phone company from a small town more than twice our size, and a for-profit company at that! Central no longer existed. I remember reading about this event -- it seems people were sad about that for quite some time. They felt that they had really lost an important part of the community when Central went away. Some machine locked in a cabinet doesn't care for people the way Central did. Even today, the older people in the community sound a little sad when they remember telephone modernization, and get the wistful look of somebody that has just remembered something that they miss.

The phone company that bought the system wasn't an AT&T, though. It was a small, independent phone company. To this day, that phone company serves only the two communities. And it was this company that I called yesterday to establish service out at our house.

They had already upgraded our lines -- over a mile of new copper, benefiting only us, at no charge to us -- last fall. The box was already on the outside of the house. Just need to get it activated.

So I called the phone company. They said I needed to drop by their office and sign some papers. Uh-oh, I think -- this is a bad sign. Sounds like a bunch of phone company bureaucracy.

But not so much. I went to the office and signed up. They asked the usual questions: name, address. Plus a few that bigger companies wouldn't ask: who used to have service at that address? Of course, most people would know that answer in our community. I couldn't have told you in Wichita, Dallas, or Indianapolis.

Then they asked when I'd like service to be activated. "As soon as possible," I say, figuring that this would be a couple of weeks like it is with AT&T or Sprint. "Well, we probably can't get out there for a couple of hours. Would it be OK if it's on at about 3?" Yes, that would be fine!

Now, how about DSL? "Well, we're a little backed up on that right now." Uh-oh. Sprint took several weeks when they *weren't* more backed up than usual. "So it'll probably be Monday or Tuesday before we can get out there. Should I just have the installer call you and arrange a time when it gets closer?" Yes, that would be fine, too!

Now, how about finding a phone number.

Out comes a large paper book. Yep, paper. They paged through it, and told me that my grandpa's old number would be available if I wanted it. I said yes -- after all, we've got his old address, so might as well keep the same phone number. OK, no problem. She whips out some white-out, whites out grandpa's name, and writes ours in. Done.

Now, do we want any optional services? Caller ID, call waiting, voicemail? How much is caller ID, I ask. $5 a month. We'll try it for now. "OK". A box was checked on the form and that was that. No high-pressure sales pitch on taking "the works" for some poorly-disclosed price, providing a ton of services I'll never use and don't want. No confusing "discounts" for having The Works and DSL at the same time.

Then I ask about an unlisted number, or at least an unlisted address. We figure that anybody that we really want to be able to reach us will figure out how without using a phone book, and these things get in so many databases these days. Sprint charged almost $10/mo for a fully unlisted number, but only a few dollars a month to just keep our address off the directories.

Our new company charged 50 cents a month for a fully unlisted number. Done.

Now it's time to pay for the first month's fees and the setup. Oops, I've forgotten my checkbook in the car. No problem, the secretary says, I'll watch your baby while you go get it! Jacob was with me, but had fallen asleep, so I brought him inside in his car seat. I went to get the checkbook -- just out the door and close by. I was back in a few seconds later, and the secretary was already on the other side of her desk talking and playing with Jacob. "My baby's 12 now," she said, and for a second, looked like a person that was remembering Central.

Or, Cleanliness is next to godliness The last time when I blogged about Spam fighting Mail Filtering With CRM114 Part 1, I left y'all with visions of non-converging learning, various ingenious ways of working around a unclean corpus, and perhaps a sinking feeling that this whole thing was more fragile than it ought to be. During this eriod of flailing around, trying to get mailtrainer to learn the full corpus correctly, I upgraded to an unpackaged version of crm114. Thanks to the excellent packaging effort by the maintianers, this was dead easy: get the debian sources using apt-get source crm114, download tghe new tarball from crm114 upstream, cp the debian dir over, and just edit the changelog file to reflect the new version. I am currently running my own, statically linked 20061103-Blame Dalkey.src-1. Cleaning the corpus made a major difference to the quality of discrimination. As mentioned earlier, I examined every mail that was initially incorrectly classified during learning. Now, there are two ways this can happen: That the piece of mail was correctly placed in the corpus, but had a feature that was different from those learned before; or that it was wrongly classified by me. When I started the chances were almost equally likely; I have now hopefully eliminated most of the misclassifications. When mailtrainer goes into cycles, retraining on a couple of emails round after round, you almost certainly are trying to train in conflicting ways. Cyclic retraining is almost always a human's error in classification. Some of the errors discovered were not just misclassifications: some where things that were inappropriate mail, but not Spam; for instance there was the whole conversation where someone one subscribed debian-devel to another mailing list, there was the challenge, the subscription notice, the un-subscription, challenge, and notice -- all of which were inappropriate, and interrupted the flow, and contributed to the noise -- but were not really Spam. I had, in a fit of pique, labelled them as Spam; but they were really like any other mailing list subscription conversations, which I certainly want to see for my subscriptions. crm114 did register the conversations as Spam and non-Spam, as requested, but that increased the similarity between Spam and non-Spam features -- and probably decreased the accuracy. I've since decided to train only on Spam, not on inappropriate mails; and let Gnus keep inappropriate mails from my eyes. I've also waffled over time about whether or not to treat newsletters from Dr. Dobbs Journal or USENIX as Spam or not -- now my rule of thumb is that since I signed up for them at some point, they are not Spam -- though I don't feel guilty about letting mailagent squirrel them away mostly out of sight. A few tips about using mailtrainer:

• Make sure you have a clean corpus
• Try and make it so that your have roughly equal numbers of Ham and Spam
• Don't let mailtrainer quit after a set number of rounds. I use a ridiculous repeat count of about 100 -- never expecting to reach anywhere close to that. Instead, I set the streak to a number = number of Spam + number of Ham + 10. This means that mailtrainer does not quit until it has processed every email in the corpus correctly without needing to retrain. Letting mailtrainer quit after it repeated the corpus twice, but before it got a streak of correct classifications left me with a filter with horrible accuracy.
• Make sure you have a clean corpus (yes, really)
• While the ratio of similarities between .css files to the differences between .css files is a fun metric, and I use it as an informal, rough benchmark while training, it is not really correlated to accuracy, so don't get hung up on it, like I was. Usually, the value I get when training from scratch on my corpus is somewhere around 7.5; but over time the ratio degrades (falling to about 5), while the filter accuracy keeps increasing.
• Train only on errors. The good news is that both mailtrainer and mailreaver already do so, so this is easy rule to follow. The reason is that you should only be doing minimal training, in case you have to modify/change the underlying rule in the future. So your filter should be trained to correctly classify the mails you get, but don't shoot for overwhelming scores.
• Use mailreaver. It has the nice behaviour of asking for retraining when it is unsure of some mail, and it caches mail for some time which really helps in training and rebuilding .css files. The reason mailreaver learns faster than mailtrainer is just this feature, I think.
• Stash mails you train on in your corpus, and don't hesitate to re-run mailtrainer over your corpus again after you have been training the unsure emails. When you train single emails, the changed filter may no longer correctly classify some email in the corpus you train with. Running mailtrainer over the corpus adjusts the filter to correctly classify every mail again. I generally retrain about once a week, though I no longer retrain from scratch, unless I change the classification algorithm.

On a real cooking kick right now. For some reason I felt this strong urge to download and watch Iron Chef shows, which I'd not seen in years. In between watching those, I've been cooking quite a few things, nothing directly related to the shows except for mapo tofu. I've got untried dishes in the fridge, which is very unusual for me, but then I don't normally cook at 11 pm either.. So for the whatever's-available-in-Joey's-fridge battle, the menu is:

• mapo tofu
• frozen yogurt with clementine infused chocolate sauce
• rice salad with balsamic parsnip and carrot garnish
• paprika fried baby squash rings and green beans (planned)

So, the Apple iPhone has been launched, it was brought to my attention as actually being announced by the MD at work, who appears to have become a complete apple freak (poor bastard... or is that rich bastard to be able to afford apple's mediocre offerings and be happy about it?). Anyways - from reading the story from BBC News and the official website, here's my conclusions. First off, when marketing a phone, how about you actually mention it's phone capabilities as the number one priority? I'd like to know about the sound capabilities, the battery life, the overall user feel for it as a phone... maybe I'm odd, but a phone has a purpose, it should make and receive calls, and it should do that job *well*, with good quality voice, a decent (filtering) microphone (it's a mobile, you'll be walking whilst speaking on it, reducing the background noise is a selling point), but apple appear to have mostly avoided talking about this. Instead, the first thing that you're told about from the news story is the unique user interface - great, so we have a touchscreen "whoop, de, do!". Worse still, from the official site, the first thing that springs out is that it's a "Wide Screen iPod" - it's a phone, if I wanted an iPod I'd buy a damned iPod - as it stands, for my music needs I have an iAudio M3 which suits my portable music experience really rather well. I choose that on the basis that it provided ogg support out of the box, didn't require any magical software (I run linux on my machines, it presenting itself as nothing more than a USB hard disk was fantastic, and means that I can use it for other things when needs arise). For a phone I want something that actually behaves like a phone, looking at the iPhone it's primary purpose appears to actually be a media player - that's not good. With the iPhone only having a touch screen interface, and from everything that I've read there's no stylus and the "finger is the ultimate pointing device", I'm just expecting that within the first 2 weeks you're going to have a scratched or smudged screen from usage alone, add in the fact that it's a mobile phone, and therefore generally treated with contempt (neccessity rather than luxery), and that most people carry mobiles in their pockets without any form of protection (easy and fast access) and you've got a recipe for disaster! The touch screen is going to be hit (wether you like it or not) whilst the phone is in your pocket, it will wear - there's no question in my mind about it. Touchscreens aren't designed to be smacked around 24/7, they're touchscreens - they respond to touch! So, assuming that you're shiny new iPhone is sitting in your pocket a lot of the time that's a lot of usage of the touchscreen - they're not designed for constant pressure (think about what happens to pockets in trousers when you sit down...), so I don't think that, overall, the sensitivity of the screen is going to last very long. It's only got a fairly narrow screen too, so what about those of us with not entirely slender fingers? When composing SMS messages on it with the on screen qwerty keyboard, do you really think that you're going to get the right keys every time? Small, on screen, buttons and pubs do not mix - and I'd hasten a bet there's a fair number of SMS messages sent from, or on the way back from, the pub, with a predictive text system at least you can almost work out what the heck the person was trying to say - this is a whole new ball game. The iPhone also makes the phone functionality only available after you've hit the part of the screen that says "Phone", now, I don't know about other people, but if I'm being given a number, I tend to just start hitting the right buttons on the phone, I can store the number later (via the call register or whatever) and hit call, now there's an extra step to getting in touch with people. From the official site we have the words """ iPhone also introduces an entirely new user interface based on a large multi-touch display and pioneering new software, letting you control everything with just your fingers. """" - now, err, just when did a phone require you to use anything other than your fingers? Please tell me, I'm dying to know - I've never yet needed to use my feet to operate my phone, have you? This is marketing gone insane - and what worries me is that people actually believe this bullshit. Apple may have "revolutionised" the computer industry with "Mac OS X" (this is actually not something that I believe, and OS X actually makes me more frustrated than being sat infront of a windows desktop - and believe me, that's difficult), but this is a phone, how about they try making it about the phone first, and the next generation tart audio player second? I'm willing to be convinced that I'm wrong, but I definately won't be going out of my way to aquire an iPhone just because the marketing spiel looks good.

The biggest party in Bavaria and part of the current german government, CSU, has announced that they want to make the "production and distribution of killer-games" illegal in germany. They claim it's because of a recent highschool shooting (no fatalities except the shooter; there was one other highschool shooting in germany a few years ago with 16 fatalities. Yes, that is 17 fatalities in over 40 years, the 42 years old amok runner back then didn't play killer games, I guess, although he used a flame thrower...). This would make the production and distribution in Germany unlawful, since we include games such as overkill, tremulous and openarena. Other distributions such as SuSE probably include some games that classify as "killer games" as well. Also note that "distribution" is a rather wide term. Does it apply to web sites? ISPs? If there is an online killer game, is the ISP "distributing" it? Polticians (especially those from CSU/CDU/SPD) are such a bunch of idiots. Please do NOT ever again vote for CSU. Software patents, killer games, "Problemfrauen & Schadbären", surveillance cameras and other surveillance, military inside germany (note that in desaster cases such as the flooding some years ago we could already deploy soldats without extra laws), shooting down of civilian airplanes, transrapid, reducing math and natural sciences in highschools, "google earth threatens worldcup security", police installing trojans on home PCs (because criminals don't install virus scanners?), kicking "irritating" students out of school, study fees, ... Often they make George W. Bush look like a genius, don't they? They don't do any important stuff, but just say whatever a majority people might want to hear. They waste our money (Transrapid). They destroy our biggest resource (changes in school system and university system, which will reduce average knowledge in germany a lot). They do lots of stupid things, which heavily invade privacy or public safety (military, surveillance) with no benefits in safety and many of which even where only stopped because they violated our constitution. Do not vote for them! [Updates: Daniel, sorry for posting a non-english post to planet. I again put it into the wrong category; I intended to do a longer post (this one) in english later on. For clarification: CSU is the sister party of CDU, these parties have an arrangement not to compete by region and are closely affiliated. On the nation-wide level they have a joint list, which often is called CDUCSU. So they're not just an "affiliate", but a strong part of the ruling party. Holger Levsen pointed out we are likely going to violate some laws much earlier by distributing ("hacker-") tools such as nmap, ettercap or whireshark.]

Lilypond is a great piece of software, but its documentation is sucky as hell. I've been trying to tweak the output of a particular piece of music which turned out to have just one system on the final page using the default settings, so that this final staff would end up on the first page, too. The documentation on how to do this, however, is less than helpful. If there is a mistake that could've been made by the people who wrote the manual, be sure they made it:

• In the "lilypond-internals" manual, there is mention of the fact that a particular variable needs to be a "moment", but no mention of how to do it; in fact, the default setting that is listed there for that variable is listed as #<Mom 1 4>, but trying to use that will give you a syntax error. It took me 15 minutes of trying, and finally more or less accidentally stumbling upon an actual example somewhere which sets a moment variable, to figure out how to do it; the right syntax is #(ly:make-moment 1 4)
• In the section on horizontal spacing, there is no single mention of the fact that settings on horizontal spacing apply to the score as a whole, and cannot be changed on a per-measure basis, or halfway the score in other ways. A pretty important detail, in my opinion.
• Yet, even if settings on horizontal spacing can only be made on a per-score basis, you still have to modify them by using \override commands somewhere in between your notes. Logic? Not really.
• In the section on horizontal spacing in the 2.10 version of the manual, there is also no reference to the new \newSpacingSection command, which allows one to split the score up in multiple sections in which the horizontal spacing can be changed anyway. Way to go.
• Even after reading and understanding most stuff in both manuals about horizontal spacing, my attempts still resulted in no visible changes on the page, and I have no clue why. There is no message, no way to be sure whether I did the wrong thing, or whether I did do stuff correctly but that it failed because of unrelated reasons.

Really, I would be very happy if the lilypond authors were to just find someone who actually knows how to write decent documentation.