Too Busy For Words - The PaulWay Weblog
06 11 2006

Mon, 06 Nov 2006

Familiarity breeds contempt
Now that I've had the laptop for a bit over a week, I'm starting to find all the niggling little problems. Nothing disturbing, nothing worth enquiring to the manufacturer about, but things that need tracking down in all that free time that I don't seem to have.

I think there are problems with the Intel Pro-Wireless 3945 driver, or at least FreshRPMs' packaging of them. Occasionally I get 'Microcode SW errors' detected in /var/log/messages ("Can't stop Rx DMA" seems to be the popular one) that indicate that the wireless is going to fail. This usually presages the machine freezing for a second or so, and then after it's irritated me with this for a while it'll just hard crash and I'll have to power it off. I've had occasional luck with turning the machine off, leaving it a while to cool down, and turning it back on again. But not always, now being one of those times.

I also need to investigate more thoroughly how to get CPU frequency scaling working. I have a feeling that I'm driving the Centrino at top speed all the time in Linux, which while it gives me a lovely sense of power, means that the overheating problem above (if it is such) is worsened.

After finally getting MythFrontend working and connecting to the back end, it's worked some black magic in the sound settings that means that no audio comes out at all. I've turned up and unmuted every control that the GNOME volume manager can lay its hands on, to no avail. I'll have to see if this is a long-term problem - maybe it's just caused by having plugged my headphones in and confused it somehow.

DMA is apparently not enabled on either the hard drive or the DVD writer. Trying to turn it on gives an 'Operation not supported' on both - the former because it's a SATA device, the latter because... I don't know why. It makes DVD playback in Xine slightly skippy.

The Amazing Everything Card Reader in the side has manifestly failed to work. I get a bit annoyed at the proliferation of physically incompatible memory cards out there and at the complete lack of an obvious 'correct' insertion direction. I can figure that the contacts go in first, and the label probably goes up. But there's certainly nothing registered in the kernel messages whichever way I insert the thing.

I've worked out now that it won't go into standby mode when you shut the lid if you have the power connected. This confused me at first.

The few odd little crashes that seemed to accompany leaving it on and connected for any length of time have now apparently gone away, though. It's too short a baseline to tell.

Overall, it's still a wonderful thing. The AIGLX/Compiz Window Effects and the general smoothness and speed of the thing have been great. Surfing the net from the couch is starting to become very attractive. Typing while in bed likewise. I'm just trying to note down what has soured the experience slightly so that, if nothing else, I can read it later and remember the data points...

posted at: 15:41 | path: /tech | permanent link to this entry

Binary Lump Compatibility
I was thinking last night, as I vainly searched for sleep, about a long-standing idea of mine: the Blockless File System. If you imagine the entire disk as just a big string of bytes, then several problems go away. You don't need to have special ways of keeping small files or tail-ends of files in sub-parts of blocks (or, for that matter, waste the half-block (on average) at the end of files that aren't a neat multiple of the block length). The one I'm really excited about is the ability to insert and delete arbitrary lengths within a file. Or append to the start of a file. And what about file versioning?

Aaaanyway, for some reason I was thinking of what would go in the superblock. I have only done a tiny bit of study into what goes into the superblock in modern file systems, so I'm not speaking from the point of view of a learned expert. But I thought one idea would be for a header that could detect which endian-ness the file system was written in. A quick five seconds of thought produced the idea that the block 'HLhl' would not only be fairly easy to recognise in a binary, bit-oriented way, but would make it really easy for a human to check that it was big-endian ('HLhl'), little-endian ('lhLH'), middle-endian ('hlHL') or any of the twenty-one other combinations of 32-bit endianness the computing world has yet to explore.

It would also mean that the reader could simply translate whatever they read into their own endian-ness and then write that straight to disk (including setting the HLhl header in their native endian-ness). So writes are not penalised and reads are only penalised once. If the entire disk was written this way, it would mean that you could take the device to a machine with different endian-ness and it would behave almost exactly like normal - almost no loss of speed in writing or reading little-endian defined inode numbers or what-have-you. The entire disk could be a mix of endian-ness styles and it would still be perfectly readable.

Of course, it's not really going to matter if you don't take your disks to foreign architectures, or those architectures support some sort of SWAB instruction to swap endianness with little slow down, or if the users of disks that have been taken to foreign architectures don't mind a bit of slowdown reading the file system structure.

This is probably one to chalk up in the "Paul solves the problems of the early 1970s computer industry - in 2006" board.

posted at: 15:37 | path: /tech/ideas | permanent link to this entry

Co-operation reworked
We have an espresso machine at work, which has greatly improved the quality of the coffee I drink (up from plunger coffee). However, occasionally I come to the machine and find the filter-thingy still attached and full of spent grounds. Even worse has been the occasions when someone has frothed their milk and forgotten to wipe it off. These people work in botany and zoology labs where controlling rogue infections can be vitally important to not only the validity of their experiment but their health. So leaving dry, not-sterilised milk to rot on the frother has been a source of irritation. And I always like to leave the thing cleaner than I found it - why is someone leaving their work for other people to do?

I found out the other day. I'd just made coffee and was gently manoeuvering my cup out of the machine when Ian stepped up and grabbed the filter handle and said "I'll take care of that". He then explained that his idea was to leave the filter on the machine. The next person completes exactly the same steps when making a cup of coffee - empty out the filter, add new coffee, make the coffee - just in a slightly different order (his first step is my last step). And it means that cheaters - people who receive the machine in a clean state and leave it filled with coffee - now have to do exactly the same amount of work as everyone else.

It's left me feeling rather odd. It's going to take a while to retrain myself to his ways, and through that time I'll be thinking 'but, but, but this is leaving it dirty!'. But I can't find a flaw in his logic, the grounds are already steam-sterilised and will probably only be left in the machine for a day or two before the next person uses it, and it does mean that the people who really do irritate me - the ones who do less work than everyone else - are now doing their share. It just still feels ... wrong somehow... :-)

I can't think of any other real examples where you can make the use of a shared resource fairer by redesigning the workflow. But there's got to be similar systems.

And, though this might be considered stretching the point, the GPL and the Free Software movement has been making the point that, by stepping outside the bounds of 'paying for' and 'owning' software, we avoid a whole raft of 'fair use' and 'copying' issues. There are so many things that proprietary applications have to restrict its users from not doing - reverse engineering, selling or giving away, leasing, using to create another product - that are null issues in Open Source software. We should keep looking for these 'alternative' ways of solving problems, stepping outside the box and saying 'what scenarios can we envisage that would mean that you never had this problem?'.

It's the way of the future, man!

posted at: 14:09 | path: /personal | permanent link to this entry


All posts licensed under the CC-BY-NC license. Author Paul Wayper.