Older blog entries for claudio (starting at number 113)

Why do I think that NSI sucks?

Oh, I know. It's because I requested a registrar transfer three weeks ago and they waited until the domain expired to tell me that I must renew the domain to transfer it. Now, what should I do?

Latest developments:

• Busyboxed install-info. Now let's see what I can do for update-alternatives.
• niemeyer's dm is doing a superb job detecting broken relationships between packages.
• Dwrap is a bit more usable (well, and a lot more usable than the plain ed2k client). Check it if you're into this sort of thing.
• I'm producing daily builds of scummvm.

At least one of the two affirmations is false:

• Bash, when invoked as /bin/sh, will behave like the Bourne shell.
• Ash is a fairly complete Bourne shell.

I installed ash on a test box as /bin/sh and it broke lots of local scripts running with /bin/sh, previously a link to bash. A statically linked ash has 100 Kb (built with dietlibc), which is much smaller than a dynamic bash, and doesn't depend on ncurses.

Also built busybox with dietlibc. Now I'm planning to implement install-info and update-alternatives as bb applets.

Spent a few hours discussing dm with niemeyer last Friday. dm is a python-based modular dependency analisys tool for RPM-style packages with helpers to detect and fix incorrect, stupid, or brain-dead inter- and intra-package dependency issues. You don't know how messy your packages are untill you start to chart them.

Once you start to use APT, correctness of the dependency tree becomes critical. We (at conectiva) tried to pay special attention to this issue and to fix existing problems. We thought we were mostly clean, but dm shows us otherwise.

Also our experience with APT helped us to understand the reasons of many seemingly arbitrary entries in the Debian packaging policy: APT ditactes that way. Tests on our policy-enforcing autotester should be improved to block packages based on dm's analysis.

And this, after all, seems to be a worthwhile to learn python (and try to get used to the annoying braceless syntax). The results of the preliminary dm prorotype are already helping me on the redesign of some important packages, where dependency mess should be kept at a minimum. Let's see how it evolves...

Oh boy, I'm so stupid.

I spent six hours this afternoon trying to understand why this old Sound Blaster card wasn't returning the correct value after a reset. I read all the available documentation on Sound Blasters I could find in google. I read the Linux and FreeBSD drivers to confirm that they do exactly the same as I was trying. Tried two different cards and they didn't work. And they would never work, unless you set up PnP correctly :P (Yeah, I checked all other details and forgot this stupid PnP thing. Oh well.)

At least I got some experience points, or so I hope.

Totally unrelated note: Edonkey2000 has a strange name, but it seems to work pretty well. The binary-only Linux client has a messy output, so I wrote a curses-based wrapper.

Running in kernel mode for a couple of days, after many months of userland activities.

Debian should try not to break mozilla and konqueror at the same time. So I'm stuck with old Navigator 4 in my Debian Box.

I'm transferring helllabs.org from (ick!) NSI to dotster. With the price difference I can donate $10 to dyndns and save $10.

[RPM-]Packaging several versions of gcc in such a way that they'll all work is a PITA. kgcc and stackguard will be integrated after 2.7/2.95 and 3.0 can coexist peacefully. The 2.95-based cross-compilers will be next.

Do QNX and BeOS run under VMware?

Something must be wrong. It's 5:50AM (-0300) and I'm fixing gcc packages.

(By the way, gcc is very packaging-unfriendly. It's tricky to have it built and installed in some alternative place in your filesystem to build packages. A better way to build packages would be to divert installations from the real prefix to the buildroot the same way fakeroot does with owners.)

Last weekend I read the format specs of old SCUMM-based games. After writing a Sierra AGI interpreter that (kind of) works, how difficult would it be to write an alternative SCUMM interpreter?

Finally got my OV511 camera back. And it's not running very well, perhaps it's time to mess with the driver again.

Someone tell kojima that I borrowed a couple of Moloko CDs from his desk. I hope he doesn't mind. I've been told that he's in Denmark now and will return in a month or so.

Autoconf is a nice and useful tool. I like it. It solves problems.

#ifdef ALLOW_RANT

Automake, OTOH, is a crapball of infinite radius. It adds immense amounts of bloat to your otherwise simple makesystem. It wouldn't be such a problem if it simply worked, but that's not the case. And since RPM doesn't provide a diversion mechanism, I'll have to circumvent this annoyance in a less elegant way. To hell with "GNU Standards-compliant Makefiles", I want packages I can actually build!

Libtool is a different story. It's conceptually interesting, but the way it was implemented is braindead. Calling it stupid is an insult to stupid things.

#else

I suspect the autoconf 2.13->2.5x transition have some minor flaws that break some ill-behaved packages, but that's a minor issue. Life is beautiful.

#endif /* ALLOW_RANT */

After the new ports integrated to the CVS tree, I guess I can declare Sarien as a fairly cross-platform project:

• The Amiga port now operates in windowed/full-screen modes (switchable at runtime) with AHI sound, and is buildable with gcc and DICE.
• The MacOS X Cocoa port is working fine, native sound drivers are in the works.
• Sega Dreamcast, with working sound.
• A PocketPC port runs in WinCE-based handhelds. kojima tested the Linux version in his iPAQ and it seems to run fine too.
• QNX: full-screen and windowed modes are available in the Photon driver, sound uses the ALSA driver.
• MS-DOS: both 16 and 32-bit versions available.
• BeOS: uses SDL.
• Win32: native and SDL versions available.
• POSIX: Known to run on Linux (IA32, IA64, PPC, S/390, Alpha), FreeBSD, IRIX, AIX and Solaris. Some problems in OpenBSD have been reported.

Todo list: PalmOS, MacOS 7/8/9, Atari ST, Playstation, Microwindows/Nano-X, OS/2.