327780

Yes, I know that number by heart now. It's not a silly number, it's a bug. A grave bug on binutils which I opened, since the current version of binutils in unstable is, well, rather broken. I spent today tracking it down, and I found it. I must say I didn't expect that—I know next to nothing about the ELF file format, and even less about the binutils internals, so...

But anyway, this is what I did:

• I compiled a simple application with a broken binutils installed, and ran it inside gdb. It of course segfaulted before it even reached main(), but that was expected. The interesting bit of information was where it segfaulted.
• With objdump -D, I checked where that was. Turned out it was in some obscure section called '<.plt>', which I had never heard of before; as I found out, that is the "Procedure Linkage Table"—whatever that may mean.
• I then compiled the same application against a known good binutils, and compared. The result of that comparison can be found in the bug log (which I linked to above); anyhow, there was a difference in one of the opcodes. The result of that was that rather than jumping to some bit inside the application (at 0x8000267c), it would jump to address 28b6.
  That can't be right, of course.
• The issue was now to find out what the relevant change was. Running debdiff over the sources of both packages produced a 30M diff, so going through that would've been a little too cumbersome.
  IRC to the rescue.
  P2 told me that the code responsible for the PLT was to be found in libbfd, and that I should look at the source files in the directory for that file. Looking at the diff, I found that the file bfd/elf32-m68k.c had seen quite a lot of changes relating to ColdFire V4E support. The ColdFire V4E is a processor of which the instruction set is based on the m68k instruction set, and it should technically be possible to produce an ABI that will run on both systems, though Debian doesn't support it yet; however, it appeared that the relocation code which was added in support of the V4E was broken somehow—after reviewing patches for a few hours, I finally stumbled upon revision 1.74, of which the commit log says Add support for generating PLT lookups for the ColdFire. Which is so closely related that it can't be a coincidence. I built me a new cross-binutils based on the most recent source package but with that revision reversed, and tested, which seemed to succeed. Now I'm double-checking by building a native version, which might take a while; but I expect that one to work, too.

I'm pretty excited about this, both because we've had this bug for almost two months now (and we really needed to get rid of it) and because it's actually the first time I track down a bug in anything toolchain-related. This is nice.

Quadra 700 arrived

Today, a UPS delivery guy delivered a largish box, containing the Quadra 700 that had been donated to me by Sebastiaan Couwenberg (thanks!). The box was much larger than I expected, however. At first, I was afraid; if it ended up very large, I wouldn't have any space to put it anywhere. Fortunately, on opening the box, I found that it was, in fact, not very large, as the case is the same as that of the IIci (which is the smallest case I have—people who went to DebConf5 may remember what it looked like, since it stood in the hacklab the whole time); instead, the box contained more than I expected.

Aside from the Quadra, the box also contained a keyboard, a three-button ADB mouse (I didn't even know those existed in the first place), and a monitor.

Whee.

I had four macs (of which one has a broken LC040, so is not usable), but only two ADB keyboards (of which only one is in perfect working order), one ADB mouse, and one monitor (which beeps annoyingly if it's been powered on for more than a few minutes). With this, that amount has suddenly doubled, which is very welcome. I'll probably move this monitor to the office, and move the one at the office home some time. Not just yet, though.

Warning: rant ahead.

I hate bugzilla. With a vengeance. Not because it doesn't have features or anything; because you need to log on to it to be able to use it. I've got way too many passwords as it is already that I need to remember. I don't want one to be able to file a bug, thank you very much! And no, I'm not going to give you one of my precious other passwords -- especially not one that I use to log on to my system. So that means I'll have to do ugly things to remember it.

grumble.

Why is it that everyone and their mother uses this fsck'ing I-love-passwords-bugzilla? There are only two Open Source projects that I know of who don't: Debian and FreeBSD. The former uses a home-grown BTS which predates bugzilla by several years; the latter uses Gnats which, ironically (since so many FreeBSD developers have philosophical problems with the GPL), is GNU software. It's no accident that I'm associated with one of them.

One advantage of Free Software is that there's so many choice, and that you can use loads of different software—and this happens all the time, everywhere; consider Graphical User Interfaces (KDE, Gnome, ion, Enlightenment, WindowMaker, ...), shells (bash, dash, zsh, tcsh, ...), kernels (FreeBSD, Linux, NetBSD, ...) etcetera. So why doesn't this happen for bug tracking systems?

Eww.

The SQLite API is ugly, in comparison to the libpq one.

That is all.

Ternary operators

Daniel Silverstone asks about ternary operators, and whether people like to use them.

Well, I know I do. In fact, it's the single operator I like to use a lot. Too much, in fact -- sometimes I abuse it in horrible ways, such as nesting the thing three times, or so. Which is stuff that gets removed after a first reading, of course.

Most of the Microsoft languages have IIF, a function that does basically the same thing (as in "iif(condition, trueval, falseval)"). I find that a bit more intuitive than the ?: construct, but the difference isn't that important since it's semantically the same thing (and, more importantly, the ?: operator requires less characters, so is nicer).

I'm not sure about most other languages. I have learned a lot of programming languages at school, but it's been way too long, and I don't use most of them anymore. I'm quite positive that COBOL does not support it, so you need to type it out in a full 'if' structure. But that's okay, because writing COBOL feels like writing a novel anyway.

Whoops

I svn mved my ~/data/blog/live/en/computer/lang to ~/data/blog/live/en/computer/code earlier today. Turns out I made a little error which made the commit fail horribly; as a result, an old posting turned up on Planet Debian again. Whoops.

Interesting to be getting comments on it, though

Compiling belpcscd

Dear lazyweb, please tell me:

wouter@country:~/debian/eID/belpic-2.3.13.full$ LC_ALL=C make
Making all in winscarp
make[1]: Entering directory `/home/wouter/debian/eID/belpic-2.3.13.full/winscarp'
[...]
Making all in belpcscd
make[1]: Entering directory `/home/wouter/debian/eID/belpic-2.3.13.full/belpcscd'
if g++ -DPACKAGE_NAME=\"belpcscd\" -DPACKAGE_TARNAME=\"belpcscd\" \
	-DPACKAGE_VERSION=\"2.3.13\" -DPACKAGE_STRING=\"belpcscd\ 2.3.13\" \
	-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"belpcscd\" -DVERSION=\"2.3.13\" \
	-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 \
	-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 \
	-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 \
	-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE__BOOL=1 \
	-DHAVE_STDBOOL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 \
	-DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_STDLIB_H=1 \
	-DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_SYS_SELECT_H=1 \
	-DHAVE_SYS_SOCKET_H=1 -DSELECT_TYPE_ARG1=int \
	-DSELECT_TYPE_ARG234=\(fd_set\ \*\) -DSELECT_TYPE_ARG5=\(struct\ \
	timeval\ \*\) -DRETSIGTYPE=void -DHAVE_FTIME=1 -DHAVE_INET_NTOA=1 \
	-DHAVE_MEMSET=1 -DHAVE_SELECT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRCHR=1 \
	-DHAVE_STRSTR=1  -I. -I.    -Wall -Dlinux -I. \
	-I../ObjectsMultiPlatform/Include -I/usr/include/PCSC `wx-config \
	--cppflags` -g -O2 -MT belpcscd-wxmainapp.o -MD -MP -MF \
	".deps/belpcscd-wxmainapp.Tpo" -c -o belpcscd-wxmainapp.o `test -f \
	'wxmainapp.cpp' || echo './'`wxmainapp.cpp; \
then mv -f ".deps/belpcscd-wxmainapp.Tpo" ".deps/belpcscd-wxmainapp.Po";
else rm -f ".deps/belpcscd-wxmainapp.Tpo"; exit 1; fi
wxmainapp.h:88: warning: 'class MyApp' has virtual functions but non-virtual destructor
wxmainapp.cpp: In function 'int main(int, char**)':
wxmainapp.cpp:239: error: 'wxInitializer' was not declared in this scope
wxmainapp.cpp:239: error: expected `;' before 'initializer'
wxmainapp.cpp:240: error: 'initializer' was not declared in this scope
make[1]: *** [belpcscd-wxmainapp.o] Error 1
make[1]: Leaving directory `/home/wouter/debian/eID/belpic-2.3.13.full/belpcscd'
make: *** [all-recursive] Error 1
wouter@country:~/debian/eID/belpic-2.3.13.full$ 

(line feeds added for readability)

The offending bit of wxmainapp.cpp looks like:

int main(int argc, char **argv)
{
    wxApp::CheckBuildOptions(wxBuildOptions());

    wxInitializer initializer;
    if ( !initializer )
    {
        fprintf(stderr, "Failed to initialize the wxWindows library, aborting.");

        return -1;
    }
    MyApp *pTheApp= new MyApp();
    pTheApp->OnInit();
    
    while(1) sleep(1); /* run */
}

which doesn't look incorrect to me, but I could be wrong. class wxInitializer is defined in <wx/app.h>, which (according to gcc -E output) seems to be included (even if only indirectly), and its use is to initialize and cleanup the library automatically, so it would seem that upstream used it properly in the above bit of code.

People with more C++/wx knowledge than me would make me very happy if they'd point out what's wrong. Even if they first need more info to do so.

Thanks.

Update: Seems I need wxbase-2.4-config, rather than wx-config. As the upstream makefile (which I'm ignoring for the time being) showed me. Really need to learn to trust other people's judgement some time...

That's why C is usually preferred.

As I wrote earlier, I've been playing with m68k assembly lately. My first program looked somewhat like this:

.LFORMAT:
	.string	"%c"
	.text
	.align	2
.LENDL:
	.string	"\n"
	.text
	.align	2

	.globl	main
	.type	main, @function
main:
	link.w %a6,#-4		| allocate a stack frame		
	moveq #65,#-4(%a6)	| Move 65 (ASCII A) to an address on our
				| local address space
.L0:
	move.l #-4(%a6),-(%sp)  | push the address to the stack
	pea .LFORMAT		| push the format to the stack
	jbsr printf		| run printf
	add.l #1,#-4(%a6)	| add one to the letter
	cmpi.l #91,#-4(%a6)	| compare with 91 (ASCII Z + 1)
	jblt .L0		| if less, jump to label L0
	pea .LENDL		| push format to the stack
	jbsr printf		| run printf
	unlk %a6		| clear stack frame
	clr.l %d0		| store 0 in %d0 (return value)
	rts			| return
	.align 2
	.size	main, .-main

IOW, print out the alphabet. Nothing spectacular, and it worked. Then I decided to take it one step further, and rather than using an address in memory, I switched to using a register, which is supposed to be a tiny bit faster—even if that shouldn't be noticeable in this case:

main:
	link.w %a6,#-4		| allocate a stack frame		
	moveq #65,%d0		| Move 65 (ASCII A) to %d0
.L0:
	move.l %d0,-(%sp)	| push the address to the stack
	pea .LFORMAT		| push the format to the stack
	jbsr printf		| run printf
	add.l #1,%d0		| add one to the letter
	cmpi.l #91,%d0		| compare with 91 (ASCII Z + 1)
	jblt .L0		| if less, jump to label L0
	pea .LENDL		| push format to the stack
	jbsr printf		| run printf
	unlk %a6		| clear stack frame
	clr.l %d0		| store 0 in %d0 (return value)
	rts			| return
	.align 2
	.size	main, .-main

(that's only the main section, but please assume the rest is still there:-)

When I ran that, it bombed. It would print out the A, and then whole lines of nothingness. When I ran it inside gdb, it wouldn't even print out the A. It took me quite some time to figure out what went wrong.

main:
	link.w %a6,#-4		 | allocate a stack frame		
	moveq #65,%d7            | Move 65 (ASCII A) to %d7
.L0:
	extb.l %d7	
	move.l %d7,-(%sp)	 | push the address to the stack
	pea .LFORMAT		 | push the format to the stack
	jbsr printf		 | run printf
	add.l #1,%d7		 | add one to the letter
	cmpi.l #91,%d7		 | compare with 91 (ASCII Z + 1)
	jblt .L0		 | if less, jump to label L0
	pea .LENDL		 | push format to the stack
	jbsr printf		 | run printf
	unlk %a6		 | clear stack frame
	clr.l %d0		 | store 0 in %d0 (return value)
	rts			 | return
	.align 2
	.size	main, .-main

%d0 is used to store a function's return value. If I store my data in %d0, then the next time I call a function, that data is overwritten. Since I do call a function inside my loop, that function overwrites my data every time. Using a different register (say, %d7) fixes this.

Right. Apart from the fact that it's totally non-portable, assembly language also has quite a few quirks that you don't learn about when taught structured programming.

It'd be nice if there were a document somewhere that would explain how C functions expect to be called. I found out most of the above through trial and error, and through compiling stuff with -save-temps and looking at the result, comparing it with the 68k Programmers' Reference Manual. That works, but it's not really efficient—and not totally error-proof, too.

belpic_2.3.13.full-1

Close to uploading that one.

Previous versions of my belpic packages did not include the eidviewer, or libeid, because I couldn't find a license statement. As it turns out, that license statement was there all along--just in a different place than I suspected. This means the package now has the (ugly) 'upstream' version number of 2.3.13.full rather than 2.3.13, which is what upstream calls it; but at least that allows me to build everything.

Anyway, after weeks of fighting and one desperate call for help, I've finally been able to produce working packages. If you've got a SmartCard reader and/or a Belgian eID card (a real or a specimen one), I'd appreciate tests reports.

(Note that there are no i386 packages, yet. If I get a trusted i386 upload, I'll include it there.)

FOSDEM call for talks

I just sent out the Call for Talks for the Debian DevRoom at FOSDEM 2006. If you're involved with Debian and are planning to come to FOSDEM next year, please go read that mail. Even if you're not planning to give a talk or anything, volunteers manning the booth are also welcome.

Automatic networking

A long time ago, I wrote:

In these days of VPN, IPsec, dynamic routing, tunnels, IPv6, and autoconfiguration protocols, one would expect that it would be possible to configure a laptop to find all kinds of hosts automatically, both for those that are network-specific (proxy servers, NNTP-servers), and for those that are not (mail servers, version control systems, ...).

I then went on to say that I could not, at the time, expect my laptop to find those networks by itself; every time I logged on to some network, I had to set up at least two SSH tunnels.

I received a lot of feedback to that post, and I now do have my laptop set up so that it configures itself automatically if necessary. Well, almost; see below. This is what I've done:

I don't use ifupdown on my laptop anymore. The package is installed and configures my lo interface, but that's it—nothing else. Instead, I'm using whereami to configure my network cards. Whereami is an excellent piece of software that is configured through two configuration files: detect.conf and whereami.conf. The former has a pretty peculiar syntaxis, which you'll need to get used to at first; but it's very powerful. There are a few things you can do in detect.conf:

1. Run tests. A test will check whether a condition is true, and set a location based on the result. An example of a test could be

   testmii eth0 lan
   

   which checks whether the MII detects a cable (testmii) on eth0, and will set the lan location if that is true. Tests are the raison d'être of detect.conf; the point is to run as many relevant tests as possible, to get as much information as possible about the location where you are; that way, you can configure the system later on from whereami.conf (see below). There's other things like testdhcp (check for the presence and/or the returned IP address of a DHCP server), testap (test for the presence of an Access Point), testmodule (check whether something loaded a given kernel module), or even testarp if you're desperate (to test whether a node with a given MAC address lives on the network).
2. Checking locations. For instance, you might want to run testdhcp on eth0 only if the location lan is set already. This way, you don't get timeouts if you're on the train or anything. Checking locations is done with if <location> ... elif <location> ... else ... fi. Which is to say, you get a multi-line block of if structures, in which you can then run other tests conditionally. I'm just too lazy to write it out here
   Unfortunately, it is not possible to nest if structures in detect.conf; but I don't think it's actually necessary for the detection (it might be nice for whereami.conf later on, but there the issues can be worked around).
3. There's also the possibility to do things like setting environment variables, default locations, and some similar housekeeping things.

It is possible to set more than one location from detect.conf; for example, right now my laptop claims it's at werk,dhcp,lan. At home, it detects it's at thuis,dhcp,lan—unless I use my wireless interface, in which case it detects it's at zd1211,thuis,wlan,dhcp,wdhcp

After whereami finished the tests in detect.conf, your network should be working (provided you have a network cable plugged in, or are in the vicinity of an AP that you can connect to). Next, it will process whereami.conf. The genius of whereami probably lies in whereami.conf: this is a simple shellscript, but every line can be preceded by one of +, -, or =, followed by a location. For example, I have (amongst other things) this set up in my whereami.conf:

+lan ln -sf /etc/news/leafnode/config.generic /etc/news/leafnode/config
+werk ln -sf /etc/news/leafnode/config.werk /etc/news/leafnode/config
+thuis ln -sf /etc/news/leafnode/config.thuis /etc/news/leafnode/config

Whereami will check this file for any lines that start with '+' followed by a location it's going to, or '-' followed by a location it's leaving from, or '=' followed by a location it's either leaving from, going to, or staying at. It then removes the +/-/= plus the location, and dumps the rest of the line to a file; that file is then ran as a shell script. In other words, the above code will overwrite my /etc/news/leafnode/config with an appropriate configuration, depending on what network I'm entering.

I don't have to reconfigure NNTP servers anymore. Nor do I need to set up any tunnels—whereami does all of this for me, and more.

Next, since a few weeks, I've also added ifplugd. Previously, when I would get my laptop to resume from swsusp, I would need to manually run whereami afterwards; with ifplugd, this is no longer necessary—I just removed the ifupdown script in /etc/ifplugd/action.d, and replaced it with a whereami script that I quickly wrote myself (not as if it's hard, obviously).

There's just one thing left: the proxy server. There are just way too many programs that one needs to configure to use a proxy server (or not) in Linux; and though it's possible to configure a proxy server by letting firefox "detect" it, I have no clue how that's done. Additionally, programs that use proxy servers through environment variables can not be reconfigured, unless one logs off and on again.

I guess I'm looking for something that will do transparent proxying if there's a proxy server on the network, or just forward the requests to the remote server if not. But that's for another time.

Blog value

I knew it for a while already, but now it's official:

The point of this exercise? To point out how silly most of those memes really are. I mean, my blog would be worth nothing 'cause I don't use any technorati tags? What's next, I'm not officially using a computer if it doesn't run Windows? Hah.

Sick people

No, I'm not talking about sick, as in, crazy people. I'm talking about real, actual, sick people. Two guys that are rather close to me and that are in hospital currently.

One of them is my dad. Some infection to his intestines, and they need to check him up. Hopefully it's not all too serious.

The other is my best friend that I should try to see way more often. He's had issues with his health for quite a while now, and is in hospital (again).

I'm not going to add any details, not unless they ask me to.

Me, I'm healthy as a baby. However, I'm so busy these days that I don't even have the time to show the decency to pay both of you a visit. And that sucks.

Hang in there. Both of you.

Wanted: an NBD dissector for Ethereal

I could probably write it myself, given time, but I'm guessing it's going to cost me a lot more time understanding the Ethereal API than it is going to cost someone else undestanding the NBD protocol. Which is really simple. So, here's a short description of the protocol; now if someone could write me an Ethereal dissector, I'd be very happy. And if you need it, just ask for more information.

"Negotiation" phase:

• Connection is opened by the client
• The server sends out the literal string NBDMAGIC to the client (which is the "INIT_PASSWD" in the code and in error messages), followed by the the 'cliserv_magic', 0x00420281861253LL. The NBDMAGIC is there to identify a server; the cliserv_magic may be updated when the protocol changes incompatibly.
• The server sends the size of the device as a 64 bit unsigned integer.
• The server sends 128 bytes of zeroes (discarded by the client currently; these are reserved for further use)

(whether or not the above are all in one packet is something I don't know and don't really care about; they're all done using different write calls, so can technically be in different packets)
After that, the client is expected to be happy with the connection (if it isn't, it'll just drop the connection without explanation).

Main data pushing phase:

(I just made that name up, give it a reasonable name please

• Clients sends a struct nbd_request to the server (which is defined in <linux/nbd.h>. The fields in that struct are:

  magic (32bit unsigned int)

  must be NBD_REQUEST_MAGIC aka 0x25609513 (again defined in <linux/nbd.h>); if it isn't, the server disconnects (this should really be handled better, but at the moment it isn't; and changing the protocol to do this might be less than trivial). It is possible that previous versions of the protocol used 0x12560953 instead (the header file mentions that as something not to be used, but I don't know where it comes from).

  type (32 bit unsigned int)

  is NBD_CMD_READ aka 0 (to read data), NBD_CMD_WRITE (to write data) aka 1, or NBD_CMD_DISC aka 2 (to request a clean disconnect).

  handle (char array of eight bytes)

  used to uniquely identify a request; this is later sent back in the reply, and can be used to associate a reply with a request.

  from (64 bit unsigned int)

  the offset in the export where the read or the write should start.

  len (32 bit unsigned int)

  the length of the requested read or write.

• If struct nbd_request.type==NBD_CMD_WRITE, the client will then send struct nbd_request.len bytes to the server, containing the data it wants to see written.
• Server sends a struct nbd_reply to the client:

  magic (32 bit unsigned int)

  functions similar to struct nbd_request.magic, only its value is supposed to be 0x67446698. Analoguous to struct nbd_request.magic, there's a value, possibly from a previous version of the protocol, which says 0x96744668 instead.

  error (32 bit unsigned integer)

  is zero, unless an error occurred

  handle (char array of eight bytes)

  the exact same value that was received in struct nbd_request.handle

• If struct nbd_request.type==NBD_CMD_READ, the server will then send struct nbd_request.len bytes to the client, containing the data it read.

As you can see, a very simple protocol really... now if only somebody could write me a dissector—having to dissect it by hand isn't very funny, really.

You know you did it wrong when...

...people imitate you when you were trying to demonstrate the sillyness of doing so in the first place.

Belpic for backports.org

I just uploaded a belpic that compiles on stable to my people.debian.org webspace, so that people using stable will be able to use belpic, too, and might be able to use their digital ID card to sign emails, or use the tax-on-web thingy of the Belgian government. The idea is to get this into backports.org, but I can't reach Norbert Tretkowski ATM, so it'll have to wait 'till he reads his mail.

One thing is weird, though. To be able to build belpic for unstable, I had to change some things like (unsigned char **) in the code to (const unsigned char **), or it wouldn't compile. Now that I try to compile it on stable, I apparently have to reverse those changes, or it won't compile. Probably some definitions of one (or more) of the build-dependencies changed. Not that it's a problem, of course, but it is silly.

On a slightly related note, Zetes N.V. (belpic's upstream) suggested I go ahead and maintain packages for them to put on the Government's website, too, so that people would be able to install it by downloading from belgium.be. This wouldn't just be the Debian packages, but also packages for other distributions (probably RPMs, then). Sounds like fun. This isn't at all official yet, but it might be some time from now.

Belpic Backports

My belpic backports have now been added to the backports.org pending directory, until the dak setup there is finished (at which point they'll be accepted into the 'real' bpo archive).

Oh, and Yes, you're right; sorry. So, for those not familiar with the thing, belpic is a little piece of software which was written by the Belgian Government in the context of the electronic id card project; it allows Belgian citizens to read out the information and X.509 keys on their ID card, so that they can use it to identify themselves, make signatures, and thusly do other generally interesting stuff, such as using the government's tax-on-web application.

Announcing Planet Grep

Since everyone and their mother is now maintaining a Planet installation, I thought I had to have one, too. Pity it isn't packaged yet, but, well.

Of course, a decent planet requires a decent subject. So I decided to choose something I don't think exists yet, but which I do think would be nice to have: a planet for Belgian Open Source-people. I added the feeds of some people I knew were on some planets, searched a bit on google, and asked Mark for some suggestions, too. The result is at planet.grep.be. Suggestions are welcome; and if you think you should be on there too (or if you are, and think you shouldn't be :-), please do mail me!

Buitenlandse Belgen

Er is één dingetje waar ik nog niet helemaal zeker van ben, in verband met Planet Grep: of ik Buitenlandse Belgen (zoals Thomas Van Der Stichele, die in Spanje woont en Bart Decrem, die in de VS woont) ook aan Planet Grep moet toevoegen, of niet.

Het doel van Planet Grep is de Belgische FLOSS-community een beetje in de verf te zetten; je zou kunnen zeggen dat Belgen die in het buitenland wonen, niet echt deel uitmaken van de Belgische FLOSS-community. Aan de andere kant is het ook weer zo dat Belgen Belgen kennen, en vermoedelijk meer met Belgische FLOSS-mensen zullen omgaan, zelfs al wonen die in het Buitenland; en dan zou je kunnen zeggen dat Buitenlandse Belgen wél deel uitmaken van de Belgische FLOSS-community.

Met andere woorden, ik weet het nog niet goed ;). Wat denken andere mensen hiervan?

Update: okay, heb alleen mensen gehoord die het een goed idee vinden om Buitenlandse Belgen ook aan Planet Grep toe te voegen. Bij deze

Feed times

It's amazing what a feed aggregator such as Planet Planet needs to put up with. Apparently some posts don't have timing information with them, so planet needs to invent those times (which it does by the time a post appeared in its cache).

Since, however, my planet is still rather young, that meant I had three people flooding it already. Ugh. So I just opened the foo,times file in an editor and set the times for the posts of those people to something a bit older, based on what the HTML on their blog said the time of the post was. Which begs the question: why don't people just publish the time in their RSS feed if they do publish it in the HTML anyway? Oh well.

I've already added some extra feeds based on the suggestions Kris sent me; and more are, of course, always welcome!

Rock up again

Last time I booted rock to do some actual work on the thing has been a long time ago; the major reason being that it's (60G) hard disk had died, and that I didn't have an immediate replacement disk of the same size (or larger).

So, rock was powered down in my bed room for what was probably around half a year. Or at least I wouldn't be surprised if it was.

There was still one (13G) disk in rock that did work, however; but I didn't use it, because it still contained some data. Until today, when I realized that I had perfect backups of that data, and that I didn't actually need that disk anymore.

Bye, data. Have fun in the eternal bit fields.

Rock is now running ext3-on-lvm on its 13G disk, based off of an etch beta1 installation. The idea of the LVM stuff being that I'll add a larger disk some time from now, and I don't want to make it too complex. Long live LVM. I hope.

With that, I also moved away from ReiserFS. I'd been using Reiser on rock ever since it appeared in linux-2.4.0, and never migrated away from it. When I sidegraded rock from a Pentium III/600 to the dual Celeron 433 that it is now, it became horribly unstable, especially under load. Now that I've reinstalled it without Reiser, it suddenly is stable as a, uh, rock (no pun intended). Could it be that ReiserFS isn't SMP-safe?

EMILE working... sortof.

I don't know how I did it, but I did it: Somehow, I got EMILE to work on jazz, my Quadra 950. Unfortunately the kernel does get loaded but it will panic rather soon after that. But at least it's a step in the right direction.

Now to get the bloody thing to boot again, using penguin. Because that's the downside of EMILE: if you fuck up your boot, you're in trouble...

I'll probably need to test on different hardware; the Q950 is quite different from other hardware, and it apparently isn't entirely compatible. Oh well.

Planet Grep stylesheet

I just hacked up a little stylesheet for Planet Grep, because most people thought something had gone wrong with the layout (answer: no, nothing went wrong—I just didn't actually do any layout yet). The thing is based on the colors of the Belgian Flag, but nothing too fancy (given the bandwidth situation of the planet.g.b server, I don't have the luxury to make it anything fancy with images or the like).

By the time you can read this post on Planet Grep, the stylesheet should've been activated. Comments are welcome