Wouter points out a mistake in one of my blog posts which was based on old data [1]. My original post was accurate for older distributions of Linux but since then the bug in question was fixed. Normally when writing blog posts or email I do a quick test before committing the text to avoid making mistakes (it’s easy to mis-remember things). However in this case the bug would dead-lock machines which made me hesitant to test it (I didn’t have a machine that I wanted to dead-lock). There are two lessons to be learned from this. The most obvious is to test things thoroughly before writing about them (and have test machines available so that tests which cause service interruption or data loss can be performed). The next lesson is that when implementing software you should try not to have limitations that will affect user habits in a bad way. In the case of LVM, if the tool lvetend had displayed a message such as “Resizing the root LV would dead-lock the system, until locking is fixed such requests will be rejected - please boot from a rescue disk to perform this operation” then I would have performed a test before writing the blog post (as it would be a harmless test to perform). Also on occasion when I really wanted to resize a root device without a reboot I would have attempted the command in the hope that LVM had been fixed. A bug that deadlocks a system is one that will really have an adverse affect on users, both their habits in future use, and the probability of them using the software in future. A bug (or missing feature) that displays a warning message will have much less of a problem. From now on I will still be hesitant in using lvextend on a LV for a root filesystem on any machines other than the very latest for fear that they will break. The fact that lvextend will sometimes work on the root filesystem and sometimes put the machine offline is a serious problem that impacts my use of that feature. Most people won’t be in a position to have a bug or missing feature that deadlocks a system, but there are an infinite number of ways that software can potentially interrupt service or destroy data. Having software fail in a soft way such that data is not lost is a significant benefit for users and an incentive to use such software. I’ve put this post in the WTF category, because having a dead-lock bug in a very obvious use-case of commonly used software really makes me say WTF.

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

Share This

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!

A few months ago, I had shown a chart with per-5k-segment paces of my prior marathons runs (or at least those for which organisers had 5k splits). Since then, I ran two more: New York in November and London last Sunday. I have updated the charts to show both of these: A few things stand out:

• New York (in orange with small squares) clearly was my steadiest run, with very little variation and that nice burst at the end where the pace dropped below 7min/mile for the finish;
• London (in yellow with open circles) was allright, but with a noticeable drop around kilometers 30, 35 and 40 -- but then the second-best finish.
• I really cannot pace myself at the start: The two most recent races had the fastest start, including the hot and humid Chicago 2007 marathon (in light blue with circles)

In case anybody is interested (C'est bien toi, Christian, non?), the R script is available and I will be taking questions by email as R may not be obvious at first if you haven't used it.

For the second year in a row, I didn't vote in the DPL election. Not because I have lost interest in Debian affairs but because nothing is really going on that demands my attention. All three of the candidates who ran this year were eminently capable of representing of Debian and its ideals, all three had more or less the same vision for the role of DPL (IMO. See here for platforms,) and all three are, as far as I know, nice people. Organizational and social problems that previously existed have been fixed. The only problem I have with Debian these days is a lack of time but I can hardly expect the DPL to do anything about that. However, a recent post from Lucas reminded me that there is one group for which all is not fine and dandy. Given that this is the same complaint that has been made for atleast five years nows, one has to wonder why it remains singularly unfixable? Well I don't know but this delegation makes me confident that we will finally see the end of this last bottleneck too. Joerg is the one who sped up NEW package processing and I am sure he will have account creation humming along in no time. I sympathize with the frustration people stuck in NM feel, but I would like to remind them that Debian acts the way Winston Churchill observed the United States does:

"Americans can always be depended upon to do the right thing—after they've tried everything else."

I’ve just read an interesting post on TomsHardware.com about a solar powered PC [1]. It describes all the steps involved in creating a modern high-performance low-power computer. They have a lot of interesting information. One surprising fact (from page 3) is that the PSUs tested (both for AC and DC input) were more efficient when idle (I expected the greatest efficiency to be when under load). An AMD processor was chosen due in large part to the fact that chipsets in suitable motherboards used less power. For the CPU itself Intel had a competitive offering but no matching motherboard was power efficient enough (from page 7). Page 8 documents how using a cooling fan (instead of passive cooling) reduced the power requirements of the CPU to such a degree that it always saved power use overall. Why do CPUs take less power when they are cooler? Page 9 mentions that a small passively cooled video card can draw 88.5W when idle! That sucks pretty badly, it seems that having a video controller integrated with the motherboard is the way to go if you want to save power. It’s interesting to note how much energy can be used by RAM. Page 13 shows that the difference between 2*1G and 2*512M can be as much as 3.4W and that the difference between different brands of RAM for the 2*1G can make as much as 1.2W difference. Their final system drew 61W when idle, my latest 64bit system takes 52W when idle [2] (which compares to the 38W of their system without a monitor), so we are talking about 9% of system power being saved by using less RAM or 3% being saved by using a different brand of RAM. The summary of hard drive power use on page 14 is interesting, the fact that 2.5 inch laptop disks use less power than 3.5 inch desktop disks is hardly surprising, but the difference when idle is very surprising (apparently one of the 3.5 inch disks spends 8W on turbulence and friction in the bearings). It’s unfortunate that they didn’t compare any of the server-class 2.5 inch disks, it was about 6 months before the article was written that HP announced that in future they would cease shipping 3.5 inch disks and only use 2.5 inch disks (I wonder if this is related to all HP’s recent work on server cooling). Rumor has it that many server class 3.5 inch disks have platters that would fit into a 2.5 inch case because at high rotational speeds a larger diameter platter would not be strong enough. The information on DVD power use on page 15 is quite shocking. From now on when I install machines as servers which don’t have a need for for a CD-ROM drive I’ll remove the drive prior to deployment. Even if it saves only 0.47W then it’s still worth doing on a machine which uses less than 40W! An additional benefit of this is that it might speed up the boot process as the system won’t need to check for a bootable CD. It’s unfortunate that most computer parts don’t have published documentation on how much power they draw. Even if you don’t want to run on solar power there are still significant benefits to saving electricity (including reducing the noise from cooling fans and heat problems in summer). If technical data was published then people could make informed decisions about which parts to buy. Update: Changed the percentage savings for different types of RAM to be based on the system power use without the monitor. I’m most interested in saving power for servers and for idle desktops (running a desktop machine 24*7 is pretty common) so most of the time the monitor will be turned off. It’s interesting to note that they power their system uses is about the same as a P3 system and could be less if they used a different hard drive.

• [1] http://www.tomshardware.com/2007/09/13/hardware_components/


• [2] http://doc.coker.com.au/environment/computer-power-use/

Share This

It's time for me to stop complaining about the commercialisation of SourceForge and vote with my code. I'm leaving for brighter, bluer pastures at Alioth.

Query Object Framework is first (libqof1). The others will follow. I'm leaving because of unusable mailing list archives, impossibly slow web pages and wiki and the general amount of work involved in the SF interface. I'm gaining sane mailing lists, a friendly and usable ikiwiki and a simpler (although very similar) interface.

I'm also migrating most of those packages to subversion. With so many other changes, it's not exactly a problem to add cvs2svn into the mix.

Now, of course, this does not mean that these upstream packages suddenly become Debian-only or Debian-native. It does mean that I have a chance of encouraging new developers to join the team by providing the kinds of services and support that people need when starting off with a new project. (I suppose the one thing I don't yet have is an IRC channel. Not sure if it is worthwhile but I'll see what happens.)

QOF will form the basis of the support available for each of the other projects - all will share the same low-volume QOF-devel mailing list and QOF Wiki as provided by Alioth. I'll also migrate QuickList because I'm looking at restarting development on a stalled project allied to QOF and which could provide missing functionality in QuickList. I did look at Gaby in this mix but a botched Gtk1->Gtk2 transition that ended up with two incompatible forks running different parts of the original codebase put me off completely (and neither of the forks actually worked). (Some packages deserve to be dead upstream.)

I'm looking for new blood, fresh faces and a new desire to take these projects forwards. The driving force is data freedom - creating data-driven applications that are completely agnostic to where and how the data happens to be stored. It is user data, it should be as free as the source code that wrote it. Who cares what format it is in? Let's get it into a format that some other program can use and make use of the existing data instead of duplicating it all the time. (The observant will note that my old haunt of GnuCash is stubbornly ignorant of the merits of a decent import/export implementation that actually covers more than 50% of the data in the application. No wonder I took the chance to sponsor homebank.)

DWI Data With Interaction (aka DUI -- Data Under the Interface) is what can provide the missing interfaces. It'll take a while to get it back up to date and available in Debian but it can provide the link between data and interfaces. GNU/Linux users should be able to design an interface purely on the basis of the data that it needs to handle and not care one jot about how that data comes from one free software app and goes on to the next free software app. QOF is gaining a connection to libgda which means that data can go to and fro between a whole range of databases and file formats. Homebank and pilot-qof can gain new data inputs (and possibly outputs) by utilising the existing import/export support in new ways via DWI/QOF (as libqof2). That can give a complete interface for all PIM and financial data for a typical SOHO user and all based on SQL-type queries so that every stage of the process can be tweaked and optimised according to user requirements at runtime.

(Where does Emdebian come into this? Well, many people like me need to record and process PIM/financial data on the move so Emdebian means that those users can have the same data processing on their handhelds as on the desktop. Smaller apps to capture the data quickly and efficiently whilst on the move; larger apps to refine, optimise and filter the data on the desktop entirely under user control but with a simple, scriptable, interface based on runtime queries so that the user can do exactly the same conversions tomorrow with new data but none of the configuration. Easy!)

Is this groupware ? No - it is personal, ultimately flexible and entirely customised for particular users by the users themselves. It's about small niche markets, about independent business people with bespoke and highly specialised requirements. No one is going to spend time writing their reports in Scheme or Haskell, because they are the only people who need that particular report. Instead, that individual user needs to be empowered through a simple and intuitive interface to take a piece of data from one source, correlate it with a static piece of data from individual configuration sources, calculate a result according to a third piece of data from a completely separate source and combine them all into a new set of objects that can be used in other queries. It's about preparing invoices from Palm data, it's about handling customer accounts for a one-man company or handling a stocks and shares portfolio for a partnership. Ultimately customised, ultimately flexible and completely format-agnostic.

These are the kind of applications that hold people back from GNU/Linux migrations - bespoke applications that are developed for just a few small companies or just a few situations. Free software finds it hard to provide those apps because free software depends (currently) on someone else being motivated to write a bespoke program and that person rarely understands the niche. This is a chance to put the development into the hands of those with the motivation to do the work, by making the development process more WYSIWYG.

The question is: Can we come up with a better name for DWI, dear lazyweb?

"DWI is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade."
http://dwi.sourceforge.net/

The big appeal is that DWI is database-agnostic - it only cares about the data structure, not the file format. Ally that with QOF which provides data-centric SQL-based queries and conversions between objects (including combining elements from one object into one or more other objects without having to hardcode the connection between the objects at compile time) and we have an interesting and powerful combination of engines, frontends and backends that are all data-centric.

Please, if this sparks your interest, join the QOF-devel mailing list, have a play with the ikiwiki at http://qof.alioth.debian.org/ and have a go with the code. This whole area is begging for development but it is just so far from being usable by the target audience at this stage. There is a lot of programming to be done by current developers before the principles can be let loose on the masses.


This is about working between existing projects and between distributions - no longer dedicated to a single application, platform or file format, no more tunnel vision. Work on the edges of existing applications (and indeed projects), remove the sharp edges of applications that should work together but can't. The majority of the code in these libraries and applications is already stable and mature. Like so many parts of free software, it is time, IMHO, to put aside our egotistical devotion to the one-true-executable and come up with an actual solution.

Bah! I'm beginning to sound like a PR exec instead of a dedicated geek. What does it take to motivate people and get things done around here?

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.

A lot of haskell-related projects use the darcs version control system. Darcs has the nice feature that you can easily submit a patch by e-mail, usually sent to the project maintainer or a mailing list. What has bothered me in the past was that I had to manually check whether my patch was applied yet.So this week, I wrote DarcsWatch. DarcsWatch receives submitted patches and compares them to the repositories it knows about, whether the patch is missing there or not. You either send your patches to DarcsWeb directly when submitting them, using CC, or DarcsWatch is subscribed to the project mailing list itself, which is the case for the darcs-devel and xmonad lists. Other than that, not much is to do, and you ll find a nice overview of your patches, like this overview of my patches, with diffs and download links.If you want to use DarcsWatch for your contributions to other projects, or for your own projects, have a look the documentation. There are probably still bugs around, and the problem of marking patches as obsolete is not really solved yet, so if you have ideas about it, mail me, comment here, or come to #darcs on freenode. Patches are always welcome, you can get the source from DarcsWatch s repository.

Not done one of these round-ups for a while and I'm really pushed for time today, so here are some sites that I've written on:

1. Property of a Lady Wicca on House
2. Ross Burton: The End Of Homeopathy?
3. Enough with the dried yoghurt covered raisins Korerorero: Just random ranting and raving
4. How to host a free software advocacy event Free Software Magazine
5. Raw Output: AGPL
6. One for the Morning Glory: Facebook comments
7. Sam Liddicott GPL3 Questions and Implications
8. Drugs and an Election etbe
9. New Tropicana images
10. robmyers - Support BY-SA/SFDL Compatibility, Not BY-SA/FDL Compatibility
11. Internet Psychology: Teenagers do not need our help online - we need them to help us oldies by Graham Jones, Internet Psychologist
12. Wanting Your Opinions about Blog Comments and City Attorneys : David Lee King
13. Zookoda - I Don't Recommend them Anymore
14. Solar Water Heating :: ShowBlog
15. Internet Psychology: Forget email - it's old hat by Graham Jones, Internet Psychologist
16. Drake.org.uk: That's a wrap! Time to roll the end credits..
17. Internet Psychology: Internet criminals are going to have a field day by Graham Jones, Internet Psychologist
18. A Cambridge Co-operator: Rebranded Stores
19. robmyers - Two Common Errors
20. Lucas Nussbaum's Blog Blog Archive Where is the NM bottleneck?
21. NM: FD is fixed - MadBlog

It is not the case that “copyleft” is paired with issues such as sexual freedom and immigrant rights all that often. But there are times when they are bundled together as in this video, which is advertising a Pan-Europe set of May 1st events. And even if you don’t know Spanish, you will get something out of the video given its zany aesthetics (and note that “El Copyleft” is number 1 on their list )

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.

It's stories like the following that make you realise just how puny your talents are... (Reposted from a place not to be named, by the legendary Al Viro)

Give them what I got yesterday. As in, box that got
        a) Linux kernel running.
        b) init and bash running.
        c) serial and floppy - built as modules. And not loaded.
        d) no sash.
        e) no ethernet.
        f) bloody large number-crunching that Should Not Be Aborted(tm).
        g) libc and ld-linux.so - unlinked (self-LART by owner).
Now, I could tell the guy to piss off, but... WTF? He had decent beer and
was properly scared. Oh, well... So we have no exec() for anything
dynamically
linked. And we have no chance to access any external stuff - insmod is
linked
dynamically, so no insmod floppy for you. Shutting the system down was not
an
option due to (f) (aside of dealing with fsck later - umount(8) is
dynamically
linked too). Now, I knew that both /lib/libc.so-2.1.2 and
/lib/ld-linux.so-2.1.2 were still alive - mmaped by init, for one. And
/proc/1/maps would even contain their inumbers. So the plan of attack was
to create a file in root and then cannibalize the entry (change inumber in
the directory). Alas - not enough. In-core inode got zero i_nlink and
if I would just create a link by hands it would not become positive. I.e.
still remove-upon-close. But. But if we will manage to call link() on the
hand-made link we will get i_nlink raised to 1 - iget() will find the same
in-core inode, so we are OK. We'll have to revert the phony link to avoid
PO'd fsck, but that's not a problem...
        So there we go: assuming that we got static ln
echo >foo
ln foo bar
flip inumber in foo entry to point to libc
ln foo /lib/libc.so-2.1.2
flip inumber.......................... bar
repeat for ld-linux.so
rm foo bar
begin recovering other damage (self-LART was a bit larger).
        But... we don't have this flip stuff and we don't have (aaarrgh)
static
ln. Oh, shit... OK, but all we really need is a couple of syscalls, right?
There we go:
        eax=__NR_link;
        ebx=s1;
        ecx=s2;
        int 0x80;
        eax=__NR_exit;
        ebx=0;
        int 0x80;
s1:     "foo"
s2:     "bar"
The next step was getting the syscall numbers. grep? We don't need no
stinkin'
grep.
# while read i; do case $i in *__NR_link*) echo $i;; esac;
done </usr/include/asm/unistd.h
#define __NR_link 9
# while read i; do case $i in *__NR_exit*) echo $i;; esac;
done </usr/include/asm/unistd.h
#define __NR_exit 1
#define __NR__exit __NR_exit
Now, scratching the head and recalling intel code...
start:  b8 09 00 00 00
        bb (address of s1)
        b9 (address of s2)
        cd 80
        b8 01 00 00 00
        bb 00 00 00 00
        cd 80
s1:     66 6f 6f 00
s2:     62 61 72 00
Fine, but... a.out support is compiled... you guessed it, as module and not
currently loaded. So we are in for crufting up an ELF binary. OK, we don't
actually need 100%-correct ELF, just something that will pass for the
exec(). Now, we don't have shell scripts, but . will work. So the next
step was rolling more(1) in shell and reading through the relevant code
(surprisingly small - binfmt_elf.c and two headers). After much swearing
the following abortion was created:
7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
02 00 03 00 01 00 00 00 start______ 34 00 00 00
00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00
00 00 00 00 01 00 00 00 00 00 00 00 base_______
base_______ size_______ size_______ 05 00 00 00
00 10 00 00
start:
b8 09 00 00 00 bb start+1d___ b9 start+21___ cd
80 b8 01 00 00 00 bb 00 00 00 00 cd 80 66 6f 6f
00 62 61 72 00
OK, set base to something page-aligned, start=base+54, size=79. There we go:
7f 45 4c 46 00 00 00 00 00 00 00 00 00 00 00 00
02 00 03 00 01 00 00 00 54 00 00 80 34 00 00 00
00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00
00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 80
00 00 00 80 79 00 00 00 79 00 00 00 05 00 00 00
00 10 00 00 b8 09 00 00 00 bb 71 00 00 80 b9 75
00 00 80 cd 80 b8 01 00 00 00 bb 00 00 00 00 cd
80 66 6f 6f 00 62 61 72 00
well, while read l; do for i in  echo $l ; do echo -ne "\\$i"; done; done
made for oct2bin, overwriting /usr/bin/emacs with the output of that gave
us static equivalent of ln foo bar. And it worked. The rest was essentially
the same - the only tricky part was to find the location of directory entry.
Which was done with (lseek, read byte, exit(said_byte)) and shell wrapper
around that. So we had a way to read a block and dump it on the console.
The rest was obvious - start from relevant block in inode table and walk
through the references... Once we got that, it was an easy ride - trick
with inumber flipping brought libc and dynamic linker back and after that
we had 99% of system back into the working state. Amazing how little you
actually need to bring the system back to life...

Hot damn that's some deep hackery...

Updates of the moment:

* I can put a t-shirt on now! About 3 days ago, I got brave and decided to give it a try. So, yay, no more zip up sweaters!

* Had my 6-week checkup yesterday, and everything is looking good. The incision is still a bit red and since my skin is so sensitive, the surgeon doesn't want me in the hottub for another 2 weeks. *pout*

* I started physiotherapy today. I can only give it a mixed review. The therapist was absolutely wonderful, it turns out that I got the clinic director. However, she doesn't actually have time to see me 3 days a week. Her schedule is so booked up that I'd be lucky to see her once a week. On top of that, the receptionists and assistants were not terribly professional (tending not to articulate, getting flustered, sort of tossing sheets of paper at me expecting me to know what to do with them), and the place was not clean. It was also in one big room, so the therapy is done in front of everyone else. Blech. So I have an appointment with a different clinic on Friday. Hopefully this one will go better.

* I don't think I've mentioned Leif recently. He's walking, can open the doors in the house now, and can clearly say "All Done". He also climbed onto my lap the other day and cuddled with me. So cute!

* Lastly, this is the end of the contest of "Guess the cost!" And the final total for the bill was.... $199,849.24. Our running total is of all things combined at UCSF is now somewhere around $280k, so I'm guessing the final total for everything will be around $300k when we're all said and done. Crazy. The closest guess was by runasand at $192,000, whoever you are. Linked-in says the winner is in Norway. So finding that vegan restaurant might be interesting. I still remember Debconf 3 in Norway when the caterer told me "In Norway, we have a special way of preparing vegetables... We feed them to the animals." And the meat-eaters begging the vegetarians who were going elsewhere for food for their meals so that they had something other than slabs of meat to eat.

I think because of this, I'm going to have to award the prize to mmmmtino in the meantime, who came in second place at $185k. That way I can pay it out hopefully within the next year. I'll still keep the other as a raincheque in case I happen to wind up in Norway sometime again. =)

Further on the OMG-This-medical-system-is-barbaric, It looks like the insurance company negotiates the hospital down in price, because they're in network. I've only seen the payout information for that one day overnight stay, but the insurance company will only be paying 10% of the cost. So if I didn't have insurance, I'd have to pay $67k. But the insurance company gets to pay around $7k. Do they charge so much because they don't make enough money when someone is insured? How does that all work?

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.

I'm still ill with quite heavy fever, I feel like doing nothing, I'm even to weak to walk the dog properly... but he copes well and is great as usual :-)

Thinking about Debian doesn't make me feel better at all, reading through the comments of lucas post didnt help at all. Since 2000???! Gosh.

Unfortunatly the NM statistics miss two important data points: 1. people who made it thru NM and 2. people waiting for account creation. The second is only "good" to attribute blame, the first would be nice to have, so one could easily see, whether nowadays less people apply for NM or whether there are just less people in NM because the process is faster now.

I don't remember when exactly, but sometime in the past I resolved for myself to only blog positive things here, I'm seriously considering to drop this policy and poste a mean rant every day or so, either til Debian is really dead or those things are fixed or I am kicked.

Ironically it needs people to fix stuff, but yet most people in Debian are overworked. Maybe we should try to get more people in...

Besides fixing stuff and keeping up, there was also this thing called inno- what?

Also ironically I'm also and still very annoyed by whiners.

Guess I will look for a book or a movie now.

Another zero-day announcement of a Software in the Public Interest online meeting has been posted. The announcement mentions "one motion has been raised" but the agenda doesn't include any motions, so I'm not sure what. Also, the agenda lists "Debian logo licence" as up for discussion but I thought last month's meeting resolved that. I watch SPI fairly closely and I'm confused. How about the rest of you? SPI isn't alone in this: many software organisations seem to suffer from similar problems. For example, I ranted in passing about Free Software Manchester yesterday, who just posted the notes from their own zero-day meeting and I've suggested possible ways of reforming debian's currently-stalled New Maintainer process more than once. Are free software users particularly bad at the basics of running an interest society (like welcoming and expiring members, calling meetings, publishing routine communications, and so on), have I been spoiled by cooperatives with their friendly Member Services departments or secretariats, or what? Is this why so many free software orgs seem to include self-perpetuating leadership groups? Is this a serious problem if, as reported, Software Development is a Team Sport [etbe]? Are there fully-working free software mass participation groups out there? I feel a lot of these problems are caused by attempting to order our inherently entropy-filled world completely and insisting everything follows petty rules, such as refusing to answer a question because the "wrong" member asked it. The world will not become less random just because hackers try to impose arbitrary rules. Sometimes it's good to put down minimum standards (because calling zero-day meetings is a mostly-avoidable way of excluding some members) but it will always be a poor alternative to trying to do the best you can for others. How do we get past this? My pro-cooperation-and-better-business platform for SPI board went pretty badly and I've had some anti-cooperative flames back from someone starting another free software group this month, so I don't think I can fix these existing organisations any time soon. About 1 in 6 people in the UK are members of a cooperative, so even if that is reflected among hackers (and I think it's lower), all of them would not be enough to reform much. One of the most common memes in free software is "show us the code" and the few other free software cooperatives I've seen have mostly failed, with a few surviving but hitting a size limit. As a result, I'm currently negotiating the start of a new free software cooperative. So far, I'm really happy with how that's going. Many cooperators learn at the feet of large consumer cooperatives like the Cooperative Group who run training courses for new members about putting cooperative values and principles into practice, which we smaller groups couldn't run ourselves. As a result, most cooperators already know how to work well together. Should large software societies like SPI try commissioning similar courses?

I'm writing this blog entry as a reaction of Lucas Nussbaums one. More or less one year ago I also was a New Maintainer who completed the process after 3 months (Started in February and ended in May). My Intention was to become as fast as possible a Developer and I was very motivated. (I helped Lucas with filling the build twice in a row bugs in this time). The FD approves me quite fast... (I'll guess I was only waiting for two weeks?) but the next to steps (Approval of DAM and creation of the account) took very long. After waiting for 3 months I was quite demotivated and doing only necessary things in order to update my packages... it was very frustrating. But now I'm finally a DD, since 6 months. For those who doesn't want to calculate: I was waiting for DAM about 4 months. When I saw that I was again highly motivated and started again to work on Debian a bit more, because I thought that the account creation can't took long...this was an error: I was approved by DAM in the middle of October... and got my account in Dezember... again waiting for a simple action. I can really understand New Maintainer who are directly MIA after being a DD. Waiting a half year for account creation is much too long. In my eyes there is only one possible solution for this issue: Since DAM and the Account Manager have also many other tasks which consumes there time, I would suggest to give them assistants...every manager needs at least one assistant ;-). This would speed up the process and people who are doing actually a great job doesn't get frustrated by waiting, but can actively work on Debian. I hope that the new DPL will find a solution for this really big issue during his time.

Every so often, I come across some utility that need. I think it must have been written before, but I can't find it.

Today I needed a tool to take a set of files and split them up into directories in a size that will fit on DVDs. I wanted a tool that could either produce the minimum number of DVDs, or keep the files in order. I couldn't find one. So I wrote datapacker.

datapacker is a tool to group files by size. It is perhaps most often used to fit a set of files onto the minimum number of CDs or DVDs.

datapacker is designed to group files such that they fill fixed-size containers (called "bins") using the minimum number of containers. This is useful, for instance, if you want to archive a number of files to CD or DVD, and want to organize them such that you use the minimum possible number of CDs or DVDs.

In many cases, datapacker executes almost instantaneously. Of particular note, the hardlink action can be used to effectively copy data into bins without having to actually copy the data at all.

datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools.

I have, of course, uploaded it to sid. But while it sits in NEW, you can download the source tarball (with debian/ directory) from the project homepage at http://software.complete.org/datapacker. I've also got an HTML version of the manpage online, so you can see all the cool features of datapacker. It works nicely with find, xargs, mkisofs, and any other Unixy pipe-friendly program.

Those of you that know me will not be surprised that I wrote datapacker in Haskell. For this project, I added a bin-packing module and support for parsing inputs like 1.5g to MissingH. So everyone else that needs to do that sort of thing can now use library functions for it.

Update... I should have mentioned the really cool thing about this. After datapacker compiled and ran, I had only one mistake that was not caught by the Haskell compiler: I said < where I should have said <= one place. This is one of the very nice things about Haskell: the language lends itself to compilers that can catch so much. It's not that I'm a perfect programmer, just that my compiler is pretty crafty.