I decided to move my blog again. It's now a self-hosted wordpress instance at my homepage. Wordpress was deceptively easy to set up. I had imagined it to be a lot more involved. There are many knobs to tweak though, so I'll likely be fiddling with it for months to come. I've still not found a 'theme' I'm happy with, but what's there now will do for the time being. (anyone sensible will read it with an rss reader anyway).

At the same time, I've decided to start blogging about my noise-making habit on a separate site. The separation of Linux nerdery from my modular synth nerdery should appease those who couldn't care less about one or the other. (And for those oddballs that are interested in both, there's this neat thing called RSS).

Why the move? I've been toying with the idea of doing this for a long time, and procrastination was the only real reason I didn't get to it. My web site was looking a little neglected, so it felt like the right time for an overhaul.
Additionally, my livejournal account runs out sometime next year, and I don't think I'll bother renewing it. (It's not like I ever used any of the paidmembers features anyway).

I'll let it revert to a free account, and will still use it to comment on other peoples blogs etc, but I'll likely not post here again after this.

I've been thinking about just how much a nightmare video codecs are lately. The usual case that everyone complains about is the inability for Linux distros to ship various patented codecs. But when I thought about it, the problem is much bigger than Linux.

There's not a single operating system, or media playback device that will reliably play every single format that could be thrown at it. Not even close.

My OSX box gets kinda close thanks to perian, but still fails with many of the wmv variants amongst others. Windows also requires a bunch of apps & codecs installed. It's not just a Linux problem, and in honesty, never has been.

A few nights ago, I rigged up ushare, to see how the PS3 coped with its built-in media player. It failed pretty spectacularly. Other than MPEGs, almost nothing worked.

I've been toying with the idea of getting a PMP for a while, but it's the same story. I'm not particularly interested in re-encoding all my music again, and even more disillusioned at the thought of not being able to actually play most of the videos I have.

Free, open standards like vorbis should make all of this a non-issue. Yet hardware manufacturers seem reluctant to implement them. The workarounds of taking codecs from other OS's and running them in Linux seems to have become 'the norm' for playing back a lot of formats in Linux. This of course works great for x86, but all the embedded variants of Linux I've seen so far in media playback devices are running ARM, or MIPS, which means of course.. no playback of those formats.

I'd like to believe it's a problem that will eventually go away, but each seems to get worse, with yet another format we're unable to play back universally.

initramfs@vger dot kernel dot org now exists. As usual 'subscribe initramfs' in the body to majordomo @ vger.

This list will be for discussing the cross-distro initramfs support I've been suggesting at for the past few months.

Every release, there's at least one bug that affects a significant number of users. Most of the time, we get lucky, and the users can get the system installed, and we can fix the problem in an update. The worse-case scenario however is the case where a bug prevents installation, or prevents booting post-install.

F10 had a bug just like this.

It manifested in several different ways.
For some people, it result in a 10 second pause during boot up. For others, it failed to find the root filesystem, even after waiting.

What happened here?

The initrd has code to wait for the kernel to finish enumerating devices. This is an important thing to do so we don't try anything silly like trying to mount the root filesystem before the driver for the disk controller has found the disks plugged into it.

In F9 and earlier, we would emit this code when the initrd included the scsi_mod module.

Late in the F10 development, we moved a bunch of things to be built-ins, to tweak the boot-up speed.
This turned out to be a really bad idea, as it meant the 'stabilization' code didn't get emitted. Ouch.

How come it didn't affect everyone? Different controllers behave differently. Some initialise so quickly that there's no reason to wait any longer.

Why didn't it get caught during testing? We did have a large number of reports, but the correlation wasn't made until post-release.

Should it have held up the release? Possibly, if we knew it would affect so many people.

FTR: None of the hardware I personally tested was affected by this problem, which made it a real pain to track down.

The good news is that in the hopefully not to distant future, all this code is going the way of the dodo anyway.

Saving money by implementing better power management isn't the fast path to richness it seems. Writing about it for $279 a pop seems to be.

I wonder how many people actually buy these 'reports'. Probably a ridiculously high number.

I really like spicy food. I eat a fair amount of spicy indian & mexican. But none of this prepared me for what I tasted a few nights ago. This stuff is quite possibly the most brutal hot sauce I've ever tasted.

I had a tiny amount and tasted it. Within seconds I had to chug down a load of milk to try and make the burning stop. Even with that, it continued burning for a while. If I had any appreciable quantity of this stuff I think I'd have some kind of religious experience. It's not so much spicy, it's just ridiculous amounts of searing pain.

Habañero peppers, Scotch Bonnet peppers and African olesoresin.

I'm curious how many scoville's this stuff is, but the internet seems not to know. The closest guess is somewhere in the 300-500,000 range.

On a scale of 1 to 10, I'd score this one "oh my god I think I'm going to die".

Thanks Erinn.

Hacking on the new initrd stuff with Jeremy..

"Yeah, you probably don't need those sound/ modules in the initrd"
"Dude, music whilst you boot!"
"We could have a contest to have people submit a 30 second boot-time song"

Yeah. Maybe this idea won't make the cut.

Some of the more sensible ideas in a post later. In the meantime, some rough notes.

Some questions related to virtual memory never seem to go away.

Here are some of my favorites that I just love getting asked at least once every couple weeks. (Despite not being a VM hacker).

• My computer is using N MB of swap space, and there's memory free! This sucks!
  
  To understand this, think about what happens to infrequently used pages of a process when there's memory pressure. The OS decided to use those pages of RAM for something more useful.
  
• My computer has N MB of swap space free, and my processes still get oom killed. the kernel is buggy!
  
  When something got oom-killed, you ran out of _memory_, not swap space, and there was nothing else that could be swapped out to free up memory.
  
• My computer had N MB of RAM free, and they still got oom killed! the kernel sucks!
  
  There are different zones of memory. Having hundreds of MB of HIGHMEM available is irrelevant if something really needs memory it can use for DMA (Which is a very tight resource).
  

And my all-time favorite..

• I run without any swapspace configured, and once my app that allocates hundreds of gigs of memory keeps getting oom-killed. How do I stop the kernel doing this.
  

Answers on a postcard for that one ...

Dilemma. I need some portable storage device, but all the USB/Firedire ones seem to be made of fail. But whilst searching, I found this thing which raised some questions.

• The obvious one - what's up with the bamboo?
  
  
• What the hell is Turbo USB?
  
  Asides from "25% faster than a USB 2.0 connection", it doesn't really say. So I poked around the interwebs a bit.
  The best I've been able to dig up so far, is buffalo claiming a 60% speed increase over USB2 (wait, 60% ? hmm), and this speculation
  that it's just a cache that sits between the host and the USB->SATA bridge. From a little searching, it seems that a whole
  bunch of vendors now implement this same gimmick, whatever it really is.
  
  
• From reading the comments left by some customers on the amazon page linked above, the "auto-sensing power feature that turns the drive on and off with your computer" doesn't seem to actually work (and that's in those other OS's, good luck getting it work in Linux if it doesn't even work there). This doesn't really surprise me much. I've had many USB/Firewire drive enclosures over the years, and every single one of them has screwed this up. (Most of them make it impossible to use features like SMART too).
  The amusing thing is that of all the enclosures I've had, the electronic parts are nearly always identical.
  So they suffer all the same firmware bugs across vendors, just in different cases, with different flashing lights.

All of this just makes me wonder. Isn't it about time that USB storage died a long overdue death and we all just moved to eSATA?

• It would be faster. No pointless protocol conversion. Transfers running the speed of the SATA link rather than the USB link.
  
• It wouldn't suffer unfixable firmware dumb bugs in protocol conversion.
  
• It would allow access to native features the drive is capable of like ALPM, SMART etc..
  
• Given the addition of ALPM & spindown that works, it would end up using less power.
  

The only thing missing seems to be that hardly any laptops feature eSATA connectors yet.

update:Immediately after posting this, I stumbled across this which is as Kyle McMartin said "a lot of data to accidentally put through the wash". I had no idea they were making usb sticks that big now. I think a handful of these is probably a better option than any usb->ata convertor + rotating media right now.

Recently I've read about or spoken with a few people using Fedora on eeepc's who have been making some fairly big blunders without realising it. I've played with a few of these now, in their various incarnations.
The current one I've been carrying around is the 900 model
with a whopping 20GB of flash. It's quite deceptive, because there are actually two SSDs in there (one 4GB, and one 16GB)
These ssds are also pretty damn awful performance-wise compared to the newer generation of SSDs, but short of opening it up and retrofitting something, there's not much that can be done. The tips below should at least make it more bearable.

• First off, don't use the default partitioning scheme.
  By default, anaconda will choose to use lvm, and make a contiguous volume out of the two SSDs. This idea is fail, because the two disks aren't the same, and run at different speeds.
  
  # hdparm -t /dev/sda
  
  /dev/sda:
  Timing buffered disk reads: 108 MB in 3.04 seconds = 35.57 MB/sec
  
  # hdparm -t /dev/sdb
  
  /dev/sdb:
  Timing buffered disk reads: 86 MB in 3.05 seconds = 28.20 MB/sec
  
  
  So, don't do that. Just create regular partitions, and make sure you put / on the faster of the two disks (the 4GB one), and leave the 16GB one for /home
  
  
• Next, the default filesystem will be ext3. You really don't want this.
  Given the journal is in a fixed location on disk, scribbling to it every time a file gets written is a great way to wear out the flash. Go with ext2. (Given that you've only got a few GB of flash anyway, a fsck doesn't take that long should you need to). Additionally, not having to write to the journal means that you're doing less IO, which is obviously a win when it's on such slow media.
  
  
• This should go without saying - no swap.
  Not only for the flash wear problem in the previous bullet, but also, because it's slow as all hell. If you find you run out of ram and get stuff oom-killed in this setup, well, you probably need to add more ram, or consider a real laptop.
  
  
• After installing, change the fstab so that everything gets mounted with noatime. Writes to the disk are just painful, so minimising them is the path to success here. It's doubtful that you'll be running anything on an eee that would actually care about atimes anyway.
  

With these points taken into consideration, the eee isn't a half-bad machine.
I still wouldn't want to be building kernels and such on it, but it's perfectly usable for email and such whilst travelling.