Since Enrico added some useful tagging features to ikiwiki tonight, I'm now able to offer a version of my blog that leaves out all the technical computer bits. If you never get anything more than a headache out of reading those bits, you can use my lay feed. (Is "lay" really a synonym for "nontechnical"? My dictionary assures me it is.) This assumes that I remember to tag articles as nontechnical of course, which may or may not happen. If anyone for some reason likes reading only the technical bits, let me know and I could set up a feed for that too.

Well, I finally have a new laptop. Got it yesterday, spent about 3 hours installing and downloading all the software, and then let rsync run all last night to transfer over my home directory. Of course like any good Debian user I've filed a detailed installation report.

(Update: See kodama for current details on getting Debian running on this laptop.)

I'm fairly pleased with the fujitsu p7120 so far. Compared to my old p1100:

• The keyboard feels larger, and the couple of keys that were moved around all make sense, except for delete. The right shift key is enormous, larger than that key is on a regular full size keyboard, and the other non-alphanumerics are also very nicely sized. Even the spacebar is larger than the usual laptop chiclet. I'd not realised how dead my old laptop's keyboard had gotten until keys started falling off; typing on this new one is just fun. Sorry for the length of the resulting blog entry..
• It runs a little bit hotter, but still seems quite nice for a fanless laptop with a fairly modern processor in it (1.2 ghz).
• The screen is much nicer, very bright. Was worried that it would be too reflective, but situations where it is seem rare. It's very nice to be able to see the screen outdoors; I'm writing this in direct sunlight.
• The touch pad is very small, but very responsive. I can't normally use touch pads and I wasn't able to consider buying this laptop until I got a chance to try it out at DebConf. With that said, the lack of a middle mouse button is very annoying, and I'm looking for some way to bind keys in X to a) paste and b) touch pad disable toggle. I'm still having significant problems with reliably dragging to highlight text too, about 10x as slow at is as I was with the old laptop's pointer. You don't realized how often you copy text around that way until it becomes easier to just re-type it.. The two mouse buttons are not very conveniently placed, their positioning makes it hard to do a one-handed click and drag.
• The case doesn't feel as solid as my old laptop's. It's also an inch longer, which makes it seem less safe to toss it in the bottom of my backpack and run around with it than the old laptop, which was basically an indestrictible little lump. All the other changes made to the case design seem like improveents, except they used a blue LED for the power indicator, which like all blue LEDs is too bright to be comfortable at night. I'll probably use some whiteout on it.
• The battery lasts 4.5 hours real usage without any tuning beyond cpufreqd, which is quite nice. I haven't felt the need to add in a bay battery yet; that battery should bring it up to ~11 hours.
• The drive is one of those new really tiny laptop hard drives, and it's whisper-quiet. I have to put my ear right on the bottom of the case to hear it.
• The speakers are quite a lot better (for laptop speakers). The internal dual microphone array seems to not be very sensative at all, I wonder how much work the windows drivers for it do in software? The keyboard sound controls don't work in linux, which is a pity.
• The fingerprint reader and card reader are the only bits not yet supported by linux. If you care about non-free firmware, only the wifi needs that.
• 3D works; I can finally try out most of the new games that have been written in the past 6 years or so. Whee..

Something weird is going on.. When I left for Mexico, there were a rooster and a hen penned up in the barn, my sister's chickens that I've been somewhat reluctantly chicken-sitting. I got back and saw the hen in there, and the next day, saw a rooster out in the field. So I opened up the coop to let him get back in, or the chicken out, but he stayed outside and I didn't see the chicken with him. A few days later a chicken did appear, but it's not one I've ever seen before (and where could it have come from?)

Then I learned that the rooster wasn't the original rooster either, Ken or Megan or Rick or someone brought it out. Some people think the original rooster was gotten by whatever've been getting into the chicken coop, while I was away. So, what happened to the old hen when I opened up the coop, and how did this new hen appear down in the valley? And how did I go a week not noticing the rooster wasn't the same one while he ran around in the field and yard?

I can only answer the last question: To me a rooster is a rooster, they're interchangeable, though I have no trouble telling hens apart.

Please don't use Planet Debian to discuss techinical topics like adding a "-" in front of dh_clean calls. There are numerous reasons not to do that, but Planet Debian is not the place to disucss them.

I'd be glad to elaborate in a proper forum.

I thought I knew most of what was wrong with rpm, but this bug has opened my eyes to whole new levels of evil. (It's also a textbook example of exactly how not to respond to bug reports.)

Description of why using rpm to upgrade a package with /usr mounted read-only can cause the package to silently be removed from the rpm database:

RPM uses a "best effort" algorithm when doing upgrades. What actually happened here is that the previous versions were removed as part of the upgrade process, and the newer versions were installed. At least as much as possible. :-) As many files as could be removed from the old install were, and that install was removed from the RPM DB. As much of the new stuff as could be installed was, but the install of some items failed, so the new packages were not added to the RPM DB.

dpkg's behavior in the equivilant situation is to complain as soon as it can't write to a file, and roll back the package state to the previous version.

irc.debian.org has changed networks, but at least for #debian-boot we've been unable to contact anyone to redirect the CIA bots to there. So I came up with this little IRC bot called watergate, which redirects CIA-speak on the old channel to the new one. Posted here in case anyone else finds it useful, and since I'm for once happy with the name of one of my programs. :-)

http://git.joeyh.name/?p=joey/src.git;a=blob_plain;f=misc/watergate.pl;hb=HEAD

Ever been doing something and find yourself thinking about how you'd blog about the thing you're doing right then? I often hate that, it cuts me off from being in the moment. My antidote is to almost never blog about such situations.

The problem with that is that I'll then get distracted from thinking about how I should blog about what I'm doing right now, to thinking about how I won't, to thinking about how I should blog about not blogging about it.

Which is why I'm finally writing this, since now I've given into temptation, blogged about not blogging and can stop worrying about it next time. Hope it works..

NP: 24 Hours 0415 (Kleptones)

Forking debhelper is apparently so much fun that everyone is doing it.

Of course, Ubuntu continues to make changes to debhelper with no regard to the possible consequences, no matter how often I point out that this is a dreadful idea. Today I noticed (it's not like they bother to tell me) that they have added a dh_iconcache command to it, so presumably various Ubuntu packages cannot build with Debian's version of debhelper, and if I decide to add a different dh_iconcache command to it, things might build but incorrectly.

To add to the fun, the version of debhelper in Debian unstable is now forked from what I guess I have to consider the "upstream" debhelper, since it got NMUed. This fork modifies dh_python in ways that, if I decide I don't like, I will have to either painfully carry forward or break a lot of stuff to get rid of. The reason it was NMUed is because I'm not interested in debhelper being in the middle of the senseless conflict between python-central and python-support. (It's a good time to be a perl user BTW. TMTOWTDI?)

All this is not very much motivation for me to continue to work on this stuff, but we'll see I guess.

Does it make sense to use a wiki for issue tracking instead of using a standalone BTS? Martin Krafft suggested this might be a useful addition to ikiwiki.

It seems to me that this would mostly be worthwhile if it took advantage of the free form, open nature of the wiki in useful ways. Reconciling that with some of the more structured needs of a BTS is an interesting challenge.

Surveying a few examples of using a wiki as a BTS:

• jspwiki tracks issues in a BTS built using the wiki. They have a bug report form with several fields, basic queries for open and closed bugs, and wiki pages for each bug with a table of the fields at the top.
• ikiwiki tracks todo items using a blog. Metadata is currently limited to tagging an item as done. (All I've felt the need for so far; other tags could be used for things like severity, versions, etc.) Each todo item is its own wiki page. You can subscribe to RSS feeds of new or fixed items and use ikiwiki's standard subscription features to subscribe to diffs of changes to particular item(s).
• trac does not seems to actually use a wiki for its bug tracking component
• pmwiki has an issue tracker integrated into the wiki. Fairly similar to jspwiki though seems less refined. Includes a wacky voting system.
• Update: Simon Michael pointed me at Zwiki's tracker, which is at least superficially similar to jspwiki and pmwiki's trackers. One interesting thing is that it supports email submissions.

There is a definite feeling about all of these of finding a vaguely nail-shaped bit and pounding on it with the wiki-hammer, but I'm unsure whether it's really a nail or just an obvious pointy bit sticking up out of the main problem of issue tracking. On the other hand, the same could probably be said about a BTS built using a relational database.

discussion

Peak of the black raspberry season, picked nearly a gallon out of the patch here in the past hour; 2 days ago I got only 1/3 as much and I didn't even cover the whole patch this time.

I enjoy berrying mostly because of the way a bramble that seemed picked clean can turn out to have more unpicked berries when seen from a different angle. Also, it's sort of like being in the zone of tetris after an hour or so; the hands proceed without concious direction and the mind is left free to drift or think about the big picture. More prickley than tetris though.

Anyway, yum.

discussion

I hate the "interesting bits of this post are below the fold" thing some people do in blogs. With. A. Passion.

A full writeup of why I hate the fold is available by sending a SASE to my address as it appears in whois for this server.

discussion

Coming up on being a full year of only dialup internet at home. Slow dialup at that, generally 28.8. Most people I know who use the net a lot switched to high speed years ago and never looked back, while my internet speed graphed over time is a square tooth wave[1]. I seem to have learned to cope with a slow network, both in the tools I've chosen to use, the things I work on, and the ways I work.

Oddly often slow internet turns into an advantage. Watching apt download the new pdiffs (which relieved at least 1/5th of my current pressure to get a faster connection), I seem to be able to see the steps it's taking to update better than people with insanely fast connections. Checking up on d-i's memory use the other day as it downloaded itself, I could get a much clearer picture of which components used how much memory. Loading a web page, I can tell if it's built on 200kb of crap html or a well-designed style-sheet. Using different revision control systems to download software trees, I can tell which have innefficient protocols. It's the effect of being able to turn a crank and watch the lights as the CPU processes one instruction at a time.

Remember the first computer you used that could scroll text, maybe in a directory listing, faster than you could skim it? Did that feel like an improvement or a new burden? For me this happened with 486 66 machines in DOS as opposed to the older 33's. Now we have to remember to pipe certian commands through less or fiddle with a scroll bar to see their full output.

Now when I am on fast internet, I often seem to feel like too many things are going on at once. I can no longer flip over to my mail reader and read one of the messages that downloaded this half hour while a web page is loading; instead the page loads in an instant and I find myself triggering one mail download after the other, since after all, each takes only seconds, not tens of minutes. And as the mail is downloading I can't watch it out of the corner of my eye and get a sense for whether I have a lot of new mails in one mailbox or the other, whether spam is attachment-heavy today or light, whether there's a lot of work mail today or not, etc. Instead it's all there at once and I feel compelled to go deal with it.

The last time I had really fast internet at home, I ended up turning off my wireless for hours at a time so I could concentrate on coding or reading instead of the available distractions. Now I've inverted that pattern; I'll seek out a fast internet connection and spend a few hours soaking up the full slendour of the net, but then I'll go home feeling shakey and nervious and get back to getting something actually useful done on dialup.

Sometimes I feel we've lost sight of the reason why we want computers to be fast; it's not an end into itself, it's just one more means to let the computer accomplish what we want it to accomplish, when we want it accomplished. Sometimes that's not right away; sometimes, the Italians tell me, you want a nice long compile to go out for a cappuccino.

This all seems very interesting to me and ripe for more research. The rare bits of user interface that intentionally slow things down rather than operating at maximum possible speed (for example, edge resistance) are, I suspect, some of the hardest bits of UI design out there, and probably the most influenced by actual users. There are tie-ins with calm computing, all kinds of interesting UI and scheduling issues (for example, which download does the user need right away and which isn't a priority, as it's not really wanted until tomorrow), all kinds of stuff that we basically don't consider today in day-to-day program design.

And if I could buy an old-style instruction-level crank and front panel lights USB dongle for my laptop, I would, in a heartbeat.

[1] Old-timey-net "fast" at college, then dialup, upgraded to ISDN, back to dialup, then upgraded to ADSL, then blazing fast nearly symetric DSL, then back to dialup, then pretty fast cable, then crazy latency satellite, then back to dialup.

discussion