Dutch log

When fragmenting IP packets, you usually split the packets up into "n-1" pMTU sized packets, and 1 packet of the remainder.  Now with wireless networks the larger the packet is the more likely it is to be lost/corrupted.  I suspect it would make more sense to fragment packets into equal sized pieces, so totlen/n bytes each.  Most routing overhead is per packet, and the total number of packets hasn't been changed.  Also this would tend to avoid so many pMTU issues as your packets are probably going to less than pMTU sized.

So recently I was setting up an home theatre system. TV, DVD Player, Sky, PS/2, etc. and an AMP/Reciver. After dealing with S/Video, Component, Composite, RF, Scart, HDMI, DVI, and VGA as well as power and speaker cables, I came to the conclusion that convergance couldn’t happen fast enough.
Imagine having all your components plug in via ethernet. They could be anywhere in the house, audio video could be streamed over IP. Devices could be discovered via mDNS. No need for limited numbers of inputs, want 6 DVD players? Sure, no problem. Want 4 SKY decoders? No issue.
Your reciever would have one ethernet uplink, and terminals for your speakers, maybe preamp outputs. It would decode whatever codecs are the current fads (much as it does now). Assuming enough bandwidth it may even use 802.11 wireless reducing the need for even more cables. Other components (DVD, TV, Sky etc) would all also take power and ethernet as their ownly source.
You could converge your home theatre with your phone (video conferencing? why not!), when your phone rings your DVD (or DVR) pauses the current output, and brings up a nice overlay with the callerID.
Your remote control could be 802.11, which while it might chew through batteries could easily detect all your components and provide a consistant interface to them anywhere in the house.
If people really care about DRM (personally I think it hurts everyone more than it helps, but I could be wrong…), then all of this can be easily authenticated/encrypted by IPsec and X.500 certificate CA’s.
HDMI is close. It provides an integrated point-to-point audio/video connector which sends uncompressed video and encoded audio. It has no theoretical maximum cable length although it has a pracatical limitation of about 15m. compared to 100m for Ethernet. You can get HDMI repeaters, you can get ethernet switches. Ethernet lets you address multiple devices on the same subnet allowing you to have multiple sources (eg DVD/CD/sky/etc) and sinks (TV’s/recievers/etc) on the same network. HDMI has i2C to do autodetection of devices (eg for EDID), and supports AV Link for remote control features for multirooming etc. IP has a wide variety of protocols that could be used for this. Ethernet is well established and things such as ethernet switches/cables/etc are all mature products.
So, I wish everything spoke Ethernet, it would rock. I guess I’ll just have to wait until more than just DVD players have HDMI to get close.

So as you may remember, I've been thinking about (and quietly implementing) a distributed filesystem.  Tonight I got as far as it mostly working, and since everyone around here is sick of me telling them about it I thought I'd tell you all about it instead
It uses the 9p protocol to talk to the kernel (although I'm using the 9p python client for testing).  I use the chimera DHT for indexing, and libnpfs for dealing with the low level details of the 9p protocol.  I've managed to find bugs in all of these pieces of software so far
 Anyway, onto the interesting part of the show:
9p> ls
foo/
9p> cd foo
9p> ls
readme
9p> cat readme
Hello World
9p> mkdir sample
9p> ls -l
-rw-r–r– perry perry 0 readme
drwxr-xr-x perry perry 0 sample
9p> cd sample
9p> ls -l
9p> put testfile
9p> ls -l
-rw-r–r– perry perry 0 testfile
9p> cat testfile
This file is a test
9p> 
You may notice that the file sizes are all 0, even though most of them seem to contain data, this is coz I've not finished implementing stat(2) yet.  Permissions etc are kinda implemented (they're stored, but not read off disk yet, although libnpfs appears to verify them for me).
There's a bit of polishing off to do before the "local" part of the filesystem is mostly viable. Then I just have to hook all the distributedness together and I should have a fully functional prototype! (yeah right…)