Section 5.7.2 of the ACPI specification provides for a method called _OSI. Platform firmware can query for various interfaces, which allow it to tweak its behaviour depending on the interfaces that the OS supports. Linux claims to support the following interfaces:

• Windows 2000
  
• Windows 2001
  
• Windows 2001 SP1
  
• Windows 2001 SP2
  
• Windows 2001.1
  
• Windows 2001.1 SP1
  
• Windows 2006

which all correspond (unsurprisingly) to different versions of Windows. Linux used to be in there, but was removed for reasons I'll get into later.

The typical way in which this feature is used by a platform is by querying each of the interfaces in turn, starting with the most recent a firmware is aware of. After the first match, a value will be stashed somewhere and used elsewhere in the firmware when making certain decisions. An example of this may be only enabling certain devices (such as the HPET) if the OS claims to support Windows Vista.

As I mentioned, recent versions of Linux no longer claim to support the Linux interface. There's a couple of reasons for this. Firstly, some platforms break if they're told that they're running on Linux. It's usually an entirely untested codepath. Secondly, the whole point of the _OSI method is to provide the platform with information about the interface supported by an OS. "Linux" is too coarse grained - we make no guarantees that the interface between the OS and the platform will remain constant. "Linux 2.6.25" isn't all that much better, since distribution patches may alter the behaviour and BIOSes would become specific to a given kernel version. We could have something like "Linux ABI 1" and then bump that every time we altered the behaviour of the kernel in this respect, but this would become unwieldy fairly quickly (what would count as an ABI breaking change?)

So what kind of interface can we claim to provide? The sad truth of the matter is that most vendors will only test their code against Windows, and that as a result Windows provides the de-facto specification for OS/platform interaction. We could skip claiming to be Windows, but (in the best case) that means that the system will assume it's working with an OS that supports no advanced features. Rather than getting support for brightness changes being handled by the OS, we get stuck with SMM traps and unexpectedly missing time. If we want hardware to work to its full potential, we need to claim to be a recent version of Windows.

Does this mean the entire _OSI mechanism is useless? Not really. It's still useful for providing information about supported functionality. One example used in the spec is whether or not the OS implements the ACPI 3.0 thermal model. Another obvious (but unspecced) example might be whether or not the video opregion spec is implemented in the OS. _OSI strings which explicitly advertise the existence of advanced functionality are something that should be specified and encouraged. What they shouldn't be used for is as a way of advertising lacking functionality, which is effectively the only way that Linux can be usefully interpreted today. We don't want machines to automatically repost their video if they detect they're running Linux. It makes it harder to implement proper kernel-level graphics resume code. We don't want them to suddenly alter their keyboard behaviour, because that probably makes it harder to support older machines that don't have these workarounds.

Message to vendors: If we're not behaving in the same way as Windows does, let us know. We'll fix it. This has the benefit of fixing not only your latest and greatest platform, but also all the older ones that expected the same behaviour. Please don't try to work around our bugs in your BIOS - it just means that we need to special case you forever, and in the long run your hardware won't work as well as it would if we just fixed things properly.

when I woke up today (after sleeping in for the first time with my new roll-top in front of my bedroom window) I was surprised & confused by a couple of "congratulations!" messages in my irc away-log. it took me a bit of time & coffee (& looking into my mailbox) to begin to realize that my Debian account had indeed been created while I was asleep. — in fact I guess I still haven't completely realized my new status as Debian Developer.

as others I'd like to follow the good tradition of taking the opportunity to thank some of the people who helped me to get there:

• first & foremost Tony Mancill, my advocate, permanent sponsor, & long-time co-maintainer; for all his support in preparing & quickly uploading packages, tracking down bugs, encouraging & advocating me but also for our very pleasant "chats" via email. — we have already agreed to continue co-maintaining each other's packages.
• the friendly & helpful guys from the Debian Perl Group: Gunnar Wolf, for always encouraging me (to join the group, to apply for the New Maintainer Process, ...); Damyan Ivanov, for teaching me so much (even if he called it "nitpicking"); Gunnar, Damyan, Krzysztof Krzyżaniak, Niko Tyni, Roberto C. Sánchez, Stephen Gran, Frank Lichtenheld, Jaldhar H. Vyas, Russ Allbery, Raphaël Hertzog, & some others for uploading packages I've prepared & helping me when I had questions or problems; Martín Ferrari, for all his help, expertise, & especially for the fun & the good times we share on IRC.
• my Application Manager Wouter Verhelst; for guiding me through the New Maintainer process not only fast but also in a very helpful, at the same time demanding & supporting way.
• the Debian Women sub-project; for making Debian a better & friendlier place not only for women but in general.
• finally: the people who used the time while I was asleep to actually create my account tonight :)

some final thoughts about the NM process from my point of view:

• it took me some time to actually apply for NM; what deterred me was not that I knew it would take some time but that I didn't know how long the time would be; & that I knew that the bigger part of the overall time would consist of waiting.
• I applied on 2007-04-03, my account was created on 2008-04-18; 380 days is not bad altogether in my opinion; the actual work with my AM was from 2007-08-12 until 2007-11-28 (i.e. 108 days, or 28% of the whole duration).
• I did enjoy the actual checks; I had to read & think a lot, & I learned a lot in that period.
• Front Desk (i.e. Christoph Berg) was very quick on all necessary steps.
• I was never demotivated about my Debian work because of all the people supporting me & taking the burden of uploading packages I had prepared. but I have to admit that I got a little bored in the last months of waiting after the report had been submitted by my Application Manager.

& now it's time first to celebrate & then to try to fully grasp my new rights & responsibilities.

*Ahem*... I'm soooo excited! After 884 days, I just became a DD. It was almost two years and a half of much work, learning, patience, struggling to keep the morale up, and more work. In fact, Debian is already taking almost all my free time since months ago, something I don't regret at all. I was able to do most of the things I wanted to do, even without an account, including: DebConf organisation, team-maintaining packages (sorry pkg-perl folks, dc8 didn't leave me much time lately), some QA work, coding tools, etc. But this small feat has a huge symbolic importance to me, now the project as a whole is recognising me as a full member; many people already did individually, but sometimes you need the "official" stuff. So thanks to all the people that helped me during the way (sorry for the omissions!): maxy, for introducing me to Debian, marga for encouraging me to apply to NM —and all the moral support—, des for the help and the sarcasm, damog for being my first AM, even if we had our problems, ana for being my second AM and being so supportive, the Perl-lings for being such a nice bunch of people to work with and to learn from. Thanks also to all the nice people I've met along the way (dudes!), you make Debian a nicer place. Update: There was another paragraph that I butchered after noticing that the actual process in the last 24 hours was different than what I thought. But anyway, my thanks to Sam, Myon and Ganneff for their respective help in this process. Also, I don't want to forget to thank Ganneff for the trust he'd put on me during this time. Tags: Planet Lugfi, Planet Debian, Debian

This is a very local copyright story that concerns a local NYC coffee shop by the name of Think and a NYU student but it is this locality, or the fact that copyright regimes often act as a barricade in everyday, “mundane” situations, which makes these regimes so problematic in the first place.

I am very happy that 19 contributors who were waiting for their accounts, sometimes for a very long time, became Debian Developers today. This is great news for them, and for the project as a whole. Many thanks to all people involved for making this possible, including Joerg Jaspert, Steve McIntyre and James Troup. And congratulations to (using their account names) kibi, plessy, gregoa, goneri, tincho, akumar, filipe, miriam and the others I haven’t had the chance to work with yet. It also seems that the various pending issues (updating keys that expired, etc.) have been resolved, which is great news for several of our current DDs. But this doesn’t solve the DAM problem on a permanent basis. Something interesting about today’s events is that the account manager asked the system administrators to create the accounts, which is a nice way to offload part of the process. But the keyring maintainance is still a SPOF. A tool has been developed to allow multiple people to collaboratively edit the same keyring (and it’s used to maintain the Debian Maintainers keyring), but I’ve heard that some people weren’t satisfied with it, unfortunately. Let’s hope that this is solved soon, so the next ones to go through NM won’t have to wait that long!

I have never seem so many people at fisl. Seriously! All the rooms were crowded, all the time same as the expo and the user-group area. Our official counter were stopped at 6667 participants, but that is just because we ve taken the registration database off-line in order to process new registrations on-site. By the end of fisl all the numbers will be summed up, but I heard rumors of 7 thousand people! Awesome! I spent this first day mostly in the TVSL room. We ve had problems with the network all day long. PUCRS technicians and our link providers personnel were trying to figure out where the problem seems to be. Being stuck with a non-functioning stuff, to me this day was mostly a sequence of frustrating attempts to get over the blockage. By the end of the day I was told that they were close to a solution It reminded me of our second year trying to stream fisl, as was best told by Fluendo s Thomas ... This just leads me to an unavoidable conclusion: our network sucks! I had to hear from a Brazilian friend who lives in Europe how wonderful her Gigabit network is grrrrrrr Bored as I was, I went walking around. That, surely, were the best part of fisl so far: meeting old friends. I had the most pleasant chat (yet quick) with Otavio Salvador and Felipe van de Wiel, both friends of long time. I took some pictures of the crowd: And, since I was not available in the morning, when the huge crowd was arriving, I took a picture of a picture taken by Marlon of this initial moments: (It is not really clear in this picture, but beyond the red gates there were as many people as inside)

This week I'm in Mountain View for the X Developers' Conference, where I gave a presentation on things graphics drivers have to care about in order to make suspend/resume work reliably. Various people suggested that I write up an explanation of the current situation, along with some best practices for manufacturers.

One of the major differences between the ACPI specification and the older APM specification is that saving and restoring hardware state is generally left up to the operating system, with the firmware playing a much more passive role. Linux is now able to handle this state restoration for the majority of hardware, but we still have issues with graphics. Modern graphics hardware can be hugely complicated, which to a large extent we've been able to ignore because the platform will initialise it on boot. Many X drivers know how to switch a card from text mode to graphics mode (and vice-versa), but that's not adequate.

What can make this situation even more awkward is that the ACPI specification makes no guarantees about what state the hardware comes up in. It may still be in PCI D3. It may be powered up, but the registers may all be zeroed. It's even valid for the hardware to come up in text mode. A driver has to be able to deal with all of these situations.

So far, we've mostly tried to deal with this situation by running chunks of the video BIOS with applications like vbetool. This is hacky and often works badly - in some cases, it won't work at all (nvidia rewrite the entry point to their video BIOS after boot, in order to prevent situations where someone attempts to POST the card and it tries to jump to bits of the system BIOS that no longer exist). The only long-term option is for the kernel to handle the graphics suspend/resume. There's several levels at which this can be supported:

• Able to restore text mode. This is basically adequate right now, since the kernel enforces a virtual terminal switch around suspend/resume.
  
• Able to restore arbitrary video mode. In the kernel modesetting world, we want to be able to go straight into the mode that we're running X in, in order to reduce screen flicker. This would probably still be surrounded with a VT switch out of and into X.
  
• Able to jump straight into X. Right now, on x86 the process freezer will prevent X from running until after all of the devices have been resumed. As we move to a model where we remove the freezer and expect drivers to be able to block userspace tasks, we hit a pretty obvious problem with X - right now it hits the graphics hardware directly, rather than going via the kernel. With nothing to block it, it'll hit the hardware while it's still in an undefined state and then become very unhappy. This can't really be fixed until X does all its hardware access through the kernel. For now, we can inhibit X by leaving the VT switching in place.

Since 2.6.25, i915 and later Intel hardware can manage basic mode reprogramming without requiring any external assistance. The radeon kernel modesetting code is also heading in this direction, and we ought to be able to manage something there before too long. The nouveau developers are heading towards the stage of being able to do native mode programming, so there's some hope of progress there as well.

It's not all plain sailing, though. Vendors can wire up hardware in different ways. AMD and Nvidia hardware provides scripts in the ROM that, in theory, abstract this away. The downside to this is that we'll have to put the interpreters for these scripts in kernel space, though this is probably needed for kernel modesetting work anyway. Even then, it's possible that we'll need workarounds for specific pieces of hardware that don't quite behave as we expect them to.

As far as making graphics work over suspend/resume, we have a pretty good idea where we are now (failing on anything other than modern Intel hardware), where we need to be in the future (triumph, huge success, cake) and how to get there (?). However, hardware manufacturers can still help.
Chipset vendors:Tell us how to reinitialise your hardware. If that involves parsing BIOS tables, then please let us know how to do that. Expecting us to jump into your ROM and execute x86 code is ok if that's genuinely the only way to do it, but for any modern hardware that's clearly not the case.
System vendors:Try not to alter your system behaviour too wildly. Requiring magic register writes in order to light up the VGA output does not classify as value add. Please don't have your firmware program text mode directly - we're trying to get away from that. And do not attempt to detect that you're running on Linux and alter your system behaviour. If it's possible for you to tell that you're not running on Windows, that's a bug in Linux. If you rely on that bug, you will break. I'm not joking here in the slightest. The closest thing to a "standard" interface between an OS and the hardware is whatever Windows does, and we're basically aiming for bug-for-bug compatibility there.

Wouter, you seem to enjoy using huge filesystem volumes. So, dear lazyweb...
I have a 500GB disk for my users' home partitions - they mainly use it to back up their desktop data, but I do expect them to give it more usage. Anyway - I am currently using around 350GB of it, leaving the rest still unpartitioned. I have switched over to ReiserFS, as online resizing it is way faster than online resizing ext3 - it's basically instantaneous.
It seems I do belong to the old sysadmin school, and I value highly the reliability that comes from not having filesystems too large for their own good - After all, recovering from failure in 10GB is way more probable than doing the same in 100 or 1000, isn't it? But then again, it's just impractical to create /home/samba/ 1,2,3,4,5,6,7,8,9 / and randomly split users' directories inside them. Most users won't use more than a couple MB, but some users (legitimately!) back up tens of GB... It's hard for me to anticipate their needs.
Does any of you have scary stories regarding huge volumes? Or any data supporting the idea that I'm just too old fashioned and that half a TB is a good partition size?
Note that I _am_ holding full backups :)
[update]: So I'm undoubtley an old fart? Everybody seems to have partitions larger than me. Ok, I will stop crying...

A bug was reported on linux-parisc@ last week, that “ls -l” was whinging about “Operation not supported” once per file. Easy, I thought, I’ll just break out strace, figure out which syscall it is, and Bob’s your uncle, we’ll have it fixed. Not so, unfortunately, as strace was bloody broken. upeek: ptrace(PTRACE_PEEKUSER,2606,4294967292,0): Input/output error Again, no big deal, some kernel change must have broken ptrace(2) on me. git logs didn’t shed any light on it, so I pulled an old strace binary out of an etch chroot and tried that, which failed as well. Wonderful. But… curious… it still works inside the chroot. At this point I was a little bit beyond annoyed, but the fact that it worked in the chroot was a big clue. Anyway, long story short, strace decides to assume that you can have up to 32 possible syscall arguments (wtf?#1) which is all well and good and generally harmless. However, it also decides to yank MAX_ARGS of them out with ptrace(PEEK_USER, …) if strace is unaware of the syscall prototype. Again, this would be mostly harmless, on every other architecture. On parisc though, argument registers count down from %r26 through %r20, which is the syscall number. Instrumenting the PEEK_USER path through sys_ptrace in the kernel made it pretty obvious when a consecutive request was suddenly 0xfffffffc (which is 0-4, especially suspicious given the previous values of 4, 8, 16…) that I needed to find a loop in ptrace. Searching through all the HPPA specific syscall code found it quickly,
for (i = 0; i < tcp->u_nargs; i++)
    if (upeek(pid, PT_GR26-4*i, &tcp->u_arg[i]) < 0)
        return -1;

where “i” is 0 .. u_nargs, which is set to either the known number of syscall args, or MAX_ARGS (which, remember, was 32.) There, the culprit found, and with a simple one line fix, strace works again. In case you’re curious, the reason things worked inside the chroot, is because the syscall being strace’d was dependant on libselinux being loaded.
syscall_298(0x400e0fbc, 0x58, 0xfb444310, 0, 0x409878ac, 0x409878ac) = -1 (errno 2)
Which is statfs64. The moral of the story here? strace is out of date and doesn’t yet support recently added syscalls. Also, the code quality is pretty atrocious. Oh, and the problems with ls? getxattr was returning -EOPNOTSUP because the filesystem doesn’t support
xattrs. Or, more correctly, because that config option was disabled. This seems to be causing laughs on the buildds too. Doesn’t anyone check errno anymore? Now back to our regularly scheduled hacking. –
wtf?#1: Generally speaking, more than 5 uint32_t syscall args is frowned upon, since that makes the poor register-starved i386 pass args on the stack.

16:46 < epmf> tp-glib is made of magic

—#telepathy, 2008-04-15

Rob pointed out today that I'd been promising to blog about telepathy-glib for several months and still haven't done so. I think there's too much to cover in one blog post, so I'll start with the oldest part - implementing a service (typically a Telepathy connection manager).

While telepathy-glib is (obviously) intended for Telepathy implementors, I think the ideas we've been implementing are likely to be useful for any D-Bus API, particularly flexible/complex APIs where an object implements many interfaces.

Uwe Hermann has described how to resize a root filesystem after booting from a live-cd or recovery disk [1]. He makes some good points about resizing an LVM PV (which I hadn’t even realised was possible). The following paragraph is outdated, see the update at the end:
Incidentally it should be noted that if your root filesystem is an LVM logical volume then it can’t be resized without booting from a different device because the way LVM appears to work is that the LV in question is locked, then files under /etc/lvm/ are written, and then the LV is unlocked. If the LV in question contains /etc/lvm then you deadlock your root filesystem and need to press reset. Of course if your root filesystem is on an LV which has been encrypted via cryptsetup (the LV is encrypted not the PV) then a live resize of the root filesystem can work as locking the LV merely means that write-backs from the encryption layer don’t get committed. I’m not sure if this means that data written to an encrypted device is less stable (testing this is on my todo list). If your root filesystem is on a partition of a hard drive (such as /dev/hda2) then it is possible to extend it without booting from different media. There is nothing stopping you from running fdisk and deleting the partition of your root filesystem and recreating it. When you exit fdisk it will call an ioctl() to re-read the partition table, the kernel code counts the number of open file handles related to the device and if the number is greater than 1 (fdisk has one open handle) then it refuses to re-read the table. So you can use fdisk to change the root partition and then reboot to have the change be noticed. After that ext2online can be used to take advantage of the extra space (if the filesystem has a recent enough version of the ext3 disk format). One thing he didn’t mention is that if you do need to boot from another device to manipulate your root filesystem (which should be quite rare if you are bold and know the tricks) then you can always use your swap space. To do this you simply run swapoff and then run mkfs on the device that had been used for swap (incidentally there is nothing really special about the swap space, but it does tend to often be used for such recovery operations simply because it has no data that persists across a reboot). The minimum set of files that need to be copied to a temporary filesystem is usually /bin, /sbin, /dev, /lib (excluding all directories under /lib/modules apart from the one related to the kernel you are using), and /etc. Also you should make directories /proc, /sys, and /selinux (if the machine in question runs SE Linux). The aim is not to copy enough files for the machine to run in a regular manner, merely enough to allow manipulating all filesystems and logical volumes. Often for such recovery I boot with init=/bin/bash as a kernel parameter to skip the regular init and just start with a shell. Note that when you use init=/bin/bash you end up with a shell that has no job control and ^C is not enabled, if you want to run a command that might not terminate of it’s own accord then the command “openvt /bin/bash” can be used to start another session with reasonable terminal settings. I recommend that anyone who wants to work as a sys-admin experiment with such procedures on a test machine. There are lots of interesting things that you can learn and interesting ways that you can break your system when performing such operations. Update: Wouter points out that the LVM bug of deadlocking the root filesystem has been fixed and that you can also use ext2online to resize the mounted filesystem [2].

• [1] http://www.hermann-uwe.de/blog/resizing-a-dm-crypt-lvm-ext3-partition


• [2] http://www.grep.be/blog/en/computer/cluebat/actually_you_can

Share This

The delays in granting accounts have other effects on Debian as a whole, besides possibly dissuading people from joining.
The constant stream of sponsoring requests from people who are stuck in the final stages of NM are impeding sponsoring generally. DM is not a complete solution because a lot of these uploads are QA uploads - very useful they are too. It's just that there is no good reason why the nearly-DD's preparing the QA upload should even need a sponsor when the only thing preventing them making the upload themselves is a bottleneck in Debian that hasn't changed or improved in what seems like years.
Personally, I don't see evidence of people being dissuaded from joining - I've advocated a couple of new people recently and I know a few more who are prepared to do what is necessary to become a DD. However, I do not think it is right that existing DDs are expected to sponsor uploads from people who have passed all the hurdles of NM and are simply waiting for another DD to do an administrative task.
To echo Lucas, Debian cannot afford to impede recruitment. Debian also cannot afford to distract the existing manpower with increasing amounts of "workarounds" that fail to fix the problem.
Creating the accounts for new NMs should be considered in a similar manner to an RC bug - if the regular DD cannot find time to do it within a particular timeframe, then the task must be opened up to others who have the time to get it done. With RC bugs, we have NMUs. With NM, we need assistants to be given whatever access is necessary to step in and prevent backlogs.

I don't think any of these are mine, but this needs to be published to the general public (at least until it rests on AlumNit).

Poo Alliterations
- The Earl of Excrement
- The Duke of Dung
- The Prince of Poop
- The Sultan of Shit
- The Father of Feces
- The Matriarch of Merde
- The Steward of Stink
- The Dignitary of Dangleberries
- The Grand Poohbah of Grand Poo
- The Tyrant of Turd
- The Shogun of Scheisse
- The Baron of Bowels
- The Cardinal of Crap
- The Director of Dump
- The Surveyor of Stool
- The Lord of the Log
- The Crown Prince of Cow Patties
- The Royal Archbishop of Road Apples
- The Duchess of Droppings
- The Princess of Poodie
- The Legionnaire of Loaf
- The Supervisor of Stinkers
- The Pharaoh of Floaters
- The Magnate of Manure
- The Tycoon of TCPDumps
- The Czar of Czesspools
- The Mogul of Bowel Movements
- The Ruler of the Runs
- The Dean of Diarrhea
- The Royal Ringleader of Rump Raisins
- The Denizen of Doo-doo
- The Emperor of Evacuations
- The Headmaster of Horrible Odors
- The Titan of the Trots
- The King of Klingons
- The Big Boss of Bum Beans
- The Taskmaster of Turtleheads
- The Supervising Sovereign of Sewer Serpents
- The Colonel of Colon Cobras
- The Nobleman of Number Two
- The Top Dog of Toilet Twinkies
- The Kingpin of Keester Cakes
- The Shepherd of Sea Pickles
- The Head Navigator of Heinie Nuggets
- Rectal Representative
- The Commander of Cow Pie
- The First Mate of Fecal Matter
- The Creator of Cloth Touchers
- The Protector of Porcelan
- The Theologian of the Throne
- The God of Grunts
- The Small Insignificant Yodeling President of Shit in your Pants
- The Diaper Destroyer
- The Loader of Loincloths
- The Pontiff of Plum Pudding
- The Daiymo of Dysentery
- The Master of Montezuma's revenge
- The Squire of Squirts
- The [Weaver] of [WvLog]s
- The Primary Contact of Pudding Cookies
- The Best Producer of Brown Puddles
- The Senior Partner of Steaming Piles
- The Fine Baker of Fudge Brownies
- The Sheriff of Stench
- The Don of the Deuce
- The Torrid Putrid Tainted Pervert of Two-Ply Toilet Paper
- The Sacred Monarch of Skid Marks
- The Main Scientist of Microfeceological Studies
- The G.I. Joe of Gastro Intestinal Journeys
- The Premier of Polyps
- The Brigadier General of Bedpan Gold
- The Plunger Pilot
- The Specialist of Splashers
- The Foreman of Fake Farts
- The Ambassador's Under-Secretary of Astounding Unearthly Scents
- The Old Man and the Sea of Odiferous Monsters in the Sink
- The Bafflingly Blunt and Blasphemous Bearer of Big Bad Beastly Booty Burdens
- The Crisp Pungence of Chain Pooping
- The Goddess of Groundhogging
- The Burly Bobby's Brief Battle with Brim Blasting Bowel Bombs
- The Nasty Neighbour's Noisy and Nefarious Neglect of Normal Nasal Niceties
- The Judge Jury and Executor of Jolly Jumper Excrement
- The Forwarder of the Forwarded
- The Wizard of the Water-closet
- The Grunting Lobber of Great Logs
- The Annoyingly Arrogant Architect of Awful and Abhorrent yet Amazingly Aerodynamic Anal Atrocities
- The Dark, Dangerous and Delusional Dealer of Death-Defying Doses of Disturbingly Decadent Dung
- The Shakespeare of Sinfully Smelly and Supremely Scary Scripture with Soggy Stains and Screaming Splashes
- The Wise but Weakened Warlord Whose Willful Wrath Was Wholly Wrought With Wicked and Wretched Winds from Within
- The Languid and Lackluster Legend of the Little Log from the Loo and its Lavish Life of Luxury in a Lasagna
- The Kahuna of Kaka
- The Emergency Evacuator of Enraged Entrails
- The Squire of Sultry Stinknuggets
- The Deadening Discomfort of a Dearth of Dumps
- The Far From Favourable Fragrance of Four Fragments of Fantastically Fresh Feces
- The Principal of Prodigiously Putrid Pellets
- The Markedly Morose Maintenance of Maniacally Mounded Midden Movements and Mostly Meaty Meals Mysteriously Made Mushy
- The Crass and Cranky Coroner Connecting Clues Concerning a Cornucopia of Casualties Caused by a Crude Cluster of Completely Contemptible Colon Concoctions
- The Thinking Thoughts of a Thinker
- The Horrible, Hubristic Heathen Hoarding Hoary Humps of Hideousness Hailing from His Huge Hairy Heinie in His Harmfully Heady Hovel
- Inane Writings on Irritated Wreathing of the Incubator of Wrath
- That Special Numbness from Sniffing Noodled Stink Nougat
- The Moral Sanctity of the Mystery Shit
- The Ornery Opressor's Opulent Outpost Overseeing the Ordinary Occupants' Outrageous and Ongoing Observance Of an Occasional but Offensive Orgy Of Offal
- The Rector of Relief
- The Rectal Regurgitator
- The Shit Squat
- The Smelly Surprise
- The World Wide Wisdom
- The Slayer Supreme of System Shock

I’ve just been reading about oil deterioration when deep frying [1]. Apparently frying food can cause the production of Acrylamide [2] which causes cancer, is a neurotoxin, and does other bad things to your body. Deep frying in a vacuum [3] is a solution to this problem as the lower temperatures reduce the formation of the bad chemicals (and also increase the life of the oil thus making for cheaper fried products). Of course this means that deep frying in a pressure cooker as KFC does probably gives a result that is a lot worse for your health [4]. For some time I’ve been avoiding KFC due to concerns about the treatment of the chickens. I have been regularly eating fried chicken from a local store which looks and tastes very similar to KFC so presumably is cooked in the same way. I guess I’ll have to stop eating that now. I wonder if toast is also bad in this regard. I expect that sausages would be a problem when cooked on a BBQ. In other health news I’ve been reducing my meat consumption and I’m considering trying to entirely avoid farm raised animals to restrict my meat consumption to game meat, this should be good for my health and is also a lot better for the animals and the environment.

• [1] http://en.wikipedia.org/wiki/Deep-frying#Oil_deterioration


• [2] http://en.wikipedia.org/wiki/Acrylamide


• [3] http://en.wikipedia.org/wiki/Vacuum_fryer


• [4] http://www.kfc.com/about/pressure.asp

Share This

For some time I have been running Google Adsense adverts on my blog. Not long after I started running the adverts the revenue exceeded the amount of money I pay for net access, so it’s worth having. I recently increased the amount of advertising by including an advert in the middle of the post and received one negative comment from a reader who doesn’t like reading content with adverts in the middle. I have just changed my advertising to have that advert spot in question be before the start of the content rather than in the middle (I’m not sure if that will make them more or less happy). It seems expected nowadays that there will be a moderate amount of advertising on all web sites which have good content and don’t charge membership fees, many of my blog posts cite as references pages on web servers run by media companies that have significant amounts of advertising. Chris Samuel is considering implementing advertising [1] and is planning to not display adverts to “friends” (which means people who have commented or who are referred by social media sites). One significant problem with this idea is that sometimes the adverts become part of the blog conversation. Google adverts give an idea of which of the things that people are prepared to pay money for are considered by the Google algorithm to be related to the post in question. In my experience it’s not uncommon for people who comment on blog posts (both through the blog interface and through private correspondence) to reference the contents of adverts. Also while writing this post I updated my post about car sharing because I discovered a third car-share company through the adverts on my own blog [2]. I know one professional journalist who blocks the adverts on his own site so that his writing will not be biased (or be perceived to be biased) by his advertisers (which makes sense given his situation), but for my situation it clearly makes sense to review the advertised offerings of all three companies that compete in this space in Melbourne and there is no potential for bias (incidentally all three of them are advertising on my blog post). A problem with giving a different version of the content for friends (in the more traditional meaning of the word - as opposed to using the word to mean people who have visited your blog in a certain way) is that they will not be able to correctly review your web site. I regularly notify friends and people who do worthy things of deficiencies that I discover in their web sites and occasionally receive such notifications from other people. I don’t want to have bugs in my site concealed from friendly people who would like to help me out and displayed to random people who don’t care and will respond by visiting another site. When such things are discussed one topic that is mentioned is putting advertising in an RSS feed. I have no plans to do this, such RSS advertising would not be acceptable to Planet installations, but it would not be technically challenging to give an advert free feed to Planets but give adverts to everyone else. I think that most people who read my blog through RSS feeds will see adverts when they want to comment on my posts or when they want to forward the URLs or reference them in their own blog posts (always click on the permalink before forwarding - when a blogger messes up their permalinks it’s embarrassing if you forward them without checking). So I encourage Chris to put adverts on his blog and to show them to me.

• [1] http://www.csamuel.org/2008/04/13/pondering-adverts-feedback-sought


• [2] http://etbe.coker.com.au/2008/04/13/car-sharing-in-melbourne/

Share This

Habits control our choice sometimes more than we would like to admit… New mobile phone Since about two weeks ago I’ve a new mobile phone. The Nokia E51 will replace my slowly dying Nokia 6130i. I knew I needed a new mobile phone when my 6310i started to turn off itself shortly after I turned it on. I needed up to about ten times switching it on to make it stay on. Sometimes it already switched itself off before I could enter the PIN. Looks like a loose contact, but I never figured out where it is. Although I know about Nokia’s behaviour in Germany, I still had to buy a Nokia, because after using a 6130 (the GSM 1800 only clone of 6110 and 6150), a 6210i and the already mentioned 6130i over the last decade, I got so used to how Nokia mobile phones are navigated and how you type with Nokia phones (blank on 0, point and comma on 1, case changing on #), everything else (especially those with blank on 0 and case changing on *) would be worse than the half-dead mobile phone, I’m currently using. Spoilt for choice So which Nokia? For a long time I refused to buy a mobile phone with a camera or radio in it. But since the E70 was no more available (and is said to have quite buggy software) and the E61 has been replaced with the E61i, there are no more smartphones without a camera, at least not from Nokia. But I also found some useful uses of camera phones. After a while I could track down the number of choices to four: Communicator E90, E61i, E65 or E51: The picture above shows that the main differences of those models is size: Although having a QWERTY keyboard on the phone would be nice (for ssh, Jabber, the web, etc.) and the E90 being only slightly bigger than the 6310i on the paper, the size difference to the 6130i is more than only noticeable since the 6310i tapers off at the top. Besides, for the price of an E90, I get an E51 and an EeePC together… (Thanks to maol in whose blog I read about Sizeasy.) The E61i also has a (very small) QWERTY keyboard and is primarily only much wider than any of the other phones. It even has no bigger screen resolution than the E51 or E65. (Only the no more available E60 – a normal monoblock smart phone like the E51 – had a better resolution: 352x416 pixel instead of 240x320 pixels.) And since I usually carry my mobile phone in my trouser pockets, width matters most. So I had the choice to either get a phone which is too big for my trouser pockets or one without a QWERTY keyboard. The I remembered those foldable external keyboards for PDAs. There are at least three different makers of foldable bluetooth keyboards said to be working with Nokia Symbian S60 3rd Edition phones, so a QWERTY keyboard on the phone itself was no more important. (Only passwords will need to be entered over the number keypad since I don’t want to broadcast them… ;-) The choice between E65 and E51 was made easier by their reviews (E65, E51) at Xonio: The E65 seems to have not that good standby and phoning times while the E51 seems to be quite good regarding endurance. I looked through the usual shops around Z¨rich HB: Swisscom Shop, MobileZone, Phonehouse: All had the same prices (about CHF 250 for a two years contract at CHF 25 per month), except that Phonehouse had no E51 available in the shop. Interestingly digitec had a much lower price (CHF 100 for the same contract) and the choice of color (the shops always only offered one color), so I ordered a black one there. Converting a prepaid card to a postpaid contract isn’t that easy I wanted to change from a prepaid card to a postpaid contract, both at Swisscom, so I already own a SIM card. But digitec only offers new contracts including a SIM card or contract renewals, but no switching to a contract with keeping the number. And a new SIM card costs CHF 40 extra in their online shop. So I called their hotline and asked. The answer was: I need a new SIM card since prepaid SIM cards can’t be converted to postpaid SIM cards (but can be used with different providers). When I came to the shop, the employee needed three tries to fill out the Swisscom form for the number migration and still did it wrong somehow. No postpaid contract acknowledgement from Swisscom after two workdays. So I called their hotline. They told me, the wrong SIM card number has been entered and I need to make digitec to enter the correct one. A few days later back at the shop they were overextended. After a while an internal e-mail was on the employee’s screen which clearly stated that in case of prepaid to postpaid conversions (and a few other cases) no new SIM card must be given out and if this happens too often for the same employee he will be charged the CHF 30 a new SIM card costs digitec… (So they have a 25% margin of every sold SIM card…) About one hour after they closed their doors (I was there about ten minutes before shop closing time) Swisscom had accepted the contract changes and I had a credit note of CHF 40 for the erroneously sold SIM card. And the mobile phone became even cheaper than in all the other shops. :-) New gadget, new features So after a week, I can say that in general I’m quite happy with the new phone. It has a nice web browser, an IMAP over SSL capable mail reader and a feed reader, it can connect to the internet via WLAN and the 240x320 resolution isn’t as bad as I expected. I already have a Symbian port of PuTTY on it and sshing into my workstation works fine, even if I currently only have the phone keyboard and T9 as input device and helper. I also have Opera and Opera Mini installed, but to my own surprise the included web browser from Nokia (said to be based on Apple’s HTML rendering engine WebKit which itself is based on KDE’s HTML rendering engine KHTML) is way better, especially in navigation, even although Opera Mini 4.1 caught up a little bit in comparison to Opera Mini 4.0. (Hey, and you hear that from a web browser fetishist and Opera fan!) The only thing which currently really bugs me on the builtin web browser is that even an enforced updating of my feeds sometimes just results in nothing. Maybe a firmware upgrade can help… As barcode reader, I have installed the i-nigma Reader. (The Quickmark QR Code Reader download just showed the content of something which seems to be a Windows DLL instead of downloading it. *plonk*) It’s amazing how fast the i-nigma Reader recognizes a 2D barcode from Semapedia on my laptop screen. Of course I also have ScummVM on my new Symbian phone. I will also play around with Amora which turns your Symbian S60 mobile phone into a remote control for your presentations on Linux (or any other unixoid operating system) running laptop as soon as I managed to get an amd64 Debian package of it. (Currently there seems only i386 packages and no source packages available, but this may be due to the “Show all downloads” link gives a server error…) Oh, and many thanks to foosel since I found Amora in her blog. BTW: Any recommendations for a free (preferably free as in DFSG) Jabber and/or IRC client for Symbian S60 3rd Edition? I already downloaded and installed Gizmo5, but somehow it refuses to work each time I try to create an Gizmo account. Accessories Since the E51 has no QWERTY keyboard, I ordered a Nokia SU-8W Foldable Bluetooth Keyboard at Brack. It was a little bit bigger and thicker than expected, but OTOH the metal case seems to be very stable and robust. Since this keyboard is designed to fit on Nokia mobile phones it also has the two Nokia typical soft keys and the middle select key. So nearly all phone functions can be used with the external keyboard, even turning off the phone’s key lock. Only locking the phone’s keys again doesn’t work via the external keyboard. Additionally I equipped my E51 with a 2GB microSD card. Probably a bluetooth headset for driving will come once, too. What the Nokia 6310i did better than the E51 There are a few things which are annoying regarding Nokia’s UI consistency over the years. That the backspace key is no more the right soft-key is ok. It took me only five tries to get my e-mail account setup without hitting the abort key (no “Do you really want to abort?” questions ;-) instead of backspace key. But what’s really annoying is that the menu navigation via number keys only works for the first level and no more for all levels. So no more “menu 4 4 4” to switch to manual network selection. It’s also annoying that you (or at least I ;-) can’t enter phone numbers as the recipient of SMS directly anymore, at least those SMS never reach their receipient neither do I get an error message. Same counts for the missing acoustic acknowledgment of locking the keypad. You only hear pressing the first key but not even the second key anymore. And if you press the volume keys on the side of the phone, you also have neither acoustic nor visual feedback if you pressed them hard enough so that the volume changed. The 6310i had visual and acoustic feedback. The alarm clock in the E51 seems to be artifically castrated: After having pressed the snooze button two or three times there is no more snooze button on the right the soft key anymore. With the 6310i you could press snooze as often as you want. Only disadvantage with the 6310i in regards of the alarm clock: the snooze time was much too long (10 minutes)… Oh, and what’s also annoying is that I can’t move over the whole addressbook of my 6310i in one piece but have to send each contact via bluetooth or infrared and then the E51 even get’s the contact names mixed up: ‘Beckert, Axel’ becomes ‘Firstname: “Beckert,” Lastname: “Axel”’… Great! I have to edit nearly all contacts manually… The cut and paste feature helps here, but it takes about one to two dozens of key clicks to copy the whole content of a filed into the clipboard… The E51 can run several applications at the same time and that you can switch between them any time. While that’s generally a nice feature I started using quite soon, it’s sometimes annoying that you have to wait up to a second or so after you’ve chosen some menu entry until you can do anything further. Also the screen often flickers while loading applications, showing them, then showing only the background, showing them again, etc. … but finally I already got used to the new mobile phone so much that I already have the feeling that my old 6310i became more thick since I have the E51. (Won’t think about how thick the about ten years old 6130 feels now compared to the slim E51… :-)

Steve Kemp writes about security issues with C programs [1]. It seems obvious that if you are going to do something that is overly tricky (such as anything related to setuid programs) then you should have a good knowledge of what you are doing. Steve goes a little further and suggests that anyone who doesn’t know C should not package a C program. Andrew Pollock is a Debian developer who doesn’t program in C and yet packages some C programs, he explains why he thinks that it’s correct to forward C coding bugs upstream [2]. In this debate I have more sympathy for Steve’s position. Security is one of the most important things in software that we develop, if you can’t develop secure software then IMHO you shouldn’t distribute any software. Although it should be noted that the two posts in question don’t directly conflict. Steve’s main point (your should know the code well to do something relevant to security) does not directly conflict with Andrew’s main point that a non-C coder can maintain the Debian packaging files and forward bug reports related to C code upstream. In the more general case it’s often impossible to know all languages used in a project. It’s not uncommon for a single project to have core code written in C, a configuration file format (which is a programming language), a Makefile (GNU Make is a fairly complex interpreter), Autoconf/Automake (even more complex tools for creating complex Makefiles, and then some Perl or Python to manipulate input or output data. The SE Linux project has code in all those languages plus the M4 macro language. It seems obvious that in a large project the number of people who are capable of understanding all languages which are used is going to be a small sub-set of all Debian Developers. It also seems likely that someone who knows some of the languages really well may be capable of doing a better job than someone who has a passable knowledge of all of them. For the vast majority of my work in Debian I have been a member of the upstream project in question (for Bonnie++, Postal, Portslave, Maildir-bulletin, and logtools I’m the sole upstream developer). Often I start maintaining a package with the intent of doing the minimum needed to keep it maintained in Debian but then end up doing upstream work, for example I briefly had write access to the CVS repository for pppd when I was maintaining it and I had write access to the KDE CVS repository when I was working on KDE packages (which incidentally was before I became an official DD). When I first started working on the SE Linux project I aimed to merely package the code in question for Debian. I was not planning on spending seven years doing upstream work! When I’m working on a project I spend my time working on the things that most need attention. That often means that I get diverted from Debian packaging bugs (which are often minor issues) to work on upstream bugs. In many ways my work practices make me a Debian user and upstream developer who also does Debian packaging rather than a dedicated DD. This of course does have a detrimental affect on the quality of my Debian packaging work - but overall I believe that it’s best for the users! As an upstream developer who is focussed on Debian there are significant advantages in being a DD. I can immediately upload a new package to Unstable without any delay, and there is the potential to take over a related package (either be given the package or NMU) if it’s the best way to get around a roadblock. Another benefit is that in certain limited situations I can speak on behalf of Debian (in terms of packages I “own”). When it comes to upstream development of SE Linux I can make decisions about how things will be done in Debian and work with other upstream developers to ensure that cross-distribution compatibility works reasonably well. It seems to me that a fairly ideal process for managing Debian development would have the people who are capable of the hard coding doing so and some people who haven’t got specific coding skills working on the packaging. I would be very interested in receiving patches related to the Debian packaging of the packages I “own” (in Debian it’s widely regarded that a man’s package is his castle) so that I can spend more of my time on the C coding. I’m not bothered about NMUs (a Non-Maintainer Upload - is when someone else uploads a new version of one of my packages to fix a bug). If anyone would like to NMU one of my packages they are welcome to do so as long as there is a suitable combination of bug urgency, simplicity of the fix, and lack of response from me. If someone wants to start NMUing my packages to fix bugs reported by the latest version of Lintian in Unstable (Lintian is the Debian tool to automatically check for packaging bugs) then that’s OK. Of course there are a variety of other situations that DDs sometimes find themselves in. There have been situations of overtly hostile upstream developers. I try and avoid associating with people who have certain difficulties in interacting with others. If someone is going to change their license and try to back-date the change or create a license that makes it difficult to distribute modified versions of the code then I’m inclined to avoid even using the software, let alone being involved in developing it. This means that the software that I use in any serious way has reasonable people doing upstream development who welcome new people to join their work.

• [1] http://blog.steve.org.uk/adopt_a_less_marital_tone.html


• [2] http://blog.andrew.net.au/2008/04/12#packging_requirements

Share This

In mid-February, I started the lenny l10n NMU campaign, to tackle down pending debconf l10n bug reports. This page give the list of targets. I'm currently down to "isdnutils" in that list and, this week-end, I launched several NMU processes (a full NMU process lasts for 27 days). I'll now do my best to sustain a rhythm of 2 packages a day. Of course, several "NMU intent" mails end up with an upload by the package's regular maintainer, which is the best that can happen. I also fix many little QA issues in such process, most of the time trivial errors reported by Lintian (which was a lot improved recently, particularly about doc-base sections, menu sections, empty maintainer scripts and a lot of such things. As of now, 45 packages have been done (either by me or their maintainer) and 38 are in the pipe. As a result, all languages statistics are improving a lot. Four languages are now over 90% and 12 are over 50%!

fr   : 9507/9720,  213 missing, 97.80%
de   : 9349/9720,  371 missing, 96.18%
cs   : 8971/9720,  749 missing, 92.29%
pt   : 8757/9720,  963 missing, 90.09%
vi   : 7731/9720,  1989 missing, 79.53%
nl   : 7394/9720,  2326 missing, 76.06%
es   : 6562/9720,  3158 missing, 67.51%
sv   : 6547/9720,  3173 missing, 67.35%
ru   : 6213/9720,  3507 missing, 63.91%
gl   : 5870/9720,  3850 missing, 60.39%
ja   : 5836/9720,  3884 missing, 60.04%
pt_BR   : 5095/9720,  4625 missing, 52.41%
it   : 4538/9720,  5182 missing, 46.68%
fi   : 4589/9720,  5131 missing, 47.21%
ca   : 3954/9720,  5766 missing, 40.67%
eu   : 3942/9720,  5778 missing, 40.55%
da   : 3435/9720,  6285 missing, 35.33%
nb   : 3129/9720,  6591 missing, 32.19%
ml   : 2876/9720,  6844 missing, 29.58%
bg   : 2808/9720,  6912 missing, 28.88%
hu   : 2684/9720,  7036 missing, 27.61%
ro   : 2636/9720,  7084 missing, 27.11%
ta   : 2612/9720,  7108 missing, 26.87%
lt   : 2603/9720,  7117 missing, 26.77%
sk   : 2576/9720,  7144 missing, 26.50%
tr   : 2527/9720,  7193 missing, 25.99%

There have been a number of discussions on sane-devel in the past months revolving around the SANE2 standard (still in development) and/or extensions to the current SANE1 standard. SANE2 is an effort that has been “ongoing” (on and off, mostly off, unfortunately) for a number of years already. This led to a number of questions being raised, most notably this one: do we need SANE2, or can we get away only with extensions to SANE1? Or should we just redesign the whole stack from the ground up?
This matter is undecided as of yet, but extensions to SANE1 are planned, being discussed or in the making for some of them. During the discussions, a fork of SANE has been announced, dubbed “SANE Evolution”. No idea where that is going, but it’ll probably end up being merged back into SANE in the end. So, in a nutshell, things are moving again (albeit slowly), which is good news considering the project was mostly asleep in recent times. To celebrate that (and because I now have total control over my free time again), I’ve been working on the network side of SANE again. In 2 weeks (3 week-ends, roughly):

• saned has been turned into a regular, full-fledged daemon
• mDNS/DNS-SD service announcement & discovery has been added to saned and the net backend (using Avahi)
• I have 20% of a WireShark dissector for the SANE protocol written, and already spotted (and plugged) an information leak bug in the net backend thanks to it

Turning saned into a regular daemon made it possible to clean up a good chunk of the code duplication that was introduced by my previous AF-indep/IPv6 work; the startup code is readable again. The Avahi support is (I hope) a very nice thing as, when enabled, configuration of the net backend on the client side is no longer needed. This is an experimental feature still and as such it’s disabled by default at build time. I have a couple of ideas to improve that feature, but this means saned will have to evolve even more so it’ll take some time. The WireShark dissector is a tool for working on enhancing the network protocol. It proved useful already with the information leak I spotted with it (though it’s minor). It’ll be a long work to extend the network protocol and implement that into saned and the net backend in a backward-compatible manner.