Wed, 16 Feb 2005
Blogging
I'm considering switching to using blosxom on my own webserver, rather than using LiveJournal. So, for that reason:
Does anyone know whether it is possible, somehow, to download all blog posts I ever made on LiveJournal, preferably including comments?
Tue, 15 Feb 2005
Hardcoded keyboard shortcuts considered harmful
Evolution is a nice piece of software, but it has a few problems that make me still use mutt quite often. I won't go into details on all of them, but here's one to consider: the fact that evolution uses ctrl+] as a keyboard shortcut to go to the next unread message, and that (TTBOMK) that is not configurable.
Now, you might think, "what's wrong with that? It's still available as a shortcut, it's easy to remember, and it isn't hard to type, is it?" Well, not if you use a US qwerty keyboard, where [ and ] are positioned right above the enter key and don't require any shift keys. On my PowerBook G4 with Apple azerty keyboard, however, there is no immediate [ character. There is an immediate ( character, however, and that one is overloaded to get to { and [, as follows: for {, I use Meta_R+(; for [, I use Meta_R+Shift+(. This means that for ctrl+[, I need to hit four friggin' keys at a time. Feels like a space cadet keyboard. It's still possible to use that shortcut, of course, but it isn't really interesting that I have to use so many keys for something you want to do every time you read your mail.
mutt has tab to go to the next unread message. There, that was easy.
So please, pretty please, with sugar on top: make your keyboard shortcuts configurable.
weekend
Yes, I know it's tuesday already.
We (that is, mum, dad, my brothers and sister, and Roel's girlfriend) just had a nice weekend at the Belgian coast. We rented two small apartments of four beds each, and toured around a bit. Been to the sea, where the hurling winds did some nice things with the sand over there. Been to bruges (which was only 6km away), but all I did there was pay a visit to a local De Slegte 2nd hand bookstore for an hour and a half; I left with two 2nd hand DVDs.
For those interested, the DVDs were one of Paul Verhoeven's Starship Troopers (the 'special edition' DVD, whatever that means), and one of an 80s-era fantasy movie called Red Sonja. Starship Troopers is an okay movie; the plot is quite nice, but it's not really held up by the acting—one would expect that if you make a movie in which over half the main characters die, those deaths would get the director's and actor's attention they deserve, so that they would be convincing. They don't. I've never seen so many over-acted and unconvincing deaths in one movie, and they fail to bring the emotion of sorrow to the audience, instead making me smirk on occasion. Apart from that, it's quite entertaining.
The other one sucks. Nothing more to say about that. There is no plot; just a bunch of people who are on a trip and kill some others; and the current governor of California who gets on a girl with a sword. That's about it.
On sunday, the wind had intensified to a storm of the level where my brother's girlfriend got blown away if she got out the door, so we stayed in the house. I played chess and poker against Joris, which was fun to do.
Yesterday, I finished a small project for work, and in the evening, Roel and I went to the house of a friend of my father who happens to be my old Flute teacher, to rehearse the piece we're going to play on the wedding of Marian, my cousin. Did some good work there; we also had a nice chat over a glass of wine afterwards.
Wed, 09 Feb 2005
Wasted CPU cycles
To: Wouter Verhelst <wouter+buildd@grep.be> Subject: Re: Log for successful build of gtk+2.0_2.6.2-1 (dist=unstable) From: buildd@kiivi.cyber.ee In-Reply-To: <20050209195744.GB27344@grep.be> Message-Id: <20050209195828.E1576B6956@kiivi> Date: Wed, 9 Feb 2005 21:58:28 +0200 (EET) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Format: 1.7 > Date: Sun, 6 Feb 2005 00:16:52 +0100 > Source: gtk+2.0 > Binary: libgtk2.0-dev libgtk2.0-0-dbg gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-doc gtk2.0-examples libgtk2.0-bin libgtk2.0-common > Architecture: m68k > Version: 2.6.2-1 > Distribution: unstable > Urgency: low > Maintainer: Kiivi build daemon <buildd@kiivi.cyber.ee> > Changed-By: Sebastien Bacher <seb128@debian.org> > Description: > gtk2-engines-pixbuf - Pixbuf-based theme for GTK+ 2.x > gtk2.0-examples - Examples files for the GTK+ 2.0 > libgtk2.0-0 - The GTK+ graphical user interface library > libgtk2.0-0-dbg - The GTK+ libraries and debugging symbols > libgtk2.0-bin - The programs for the GTK+ graphical user interface library > libgtk2.0-dev - Development files for the GTK+ library > Closes: 291051 293711 > Changes: > gtk+2.0 (2.6.2-1) unstable; urgency=low > . > * New upstream release: > - fix the loop in gtkdialog (Closes: #291051). > - should fix the issue on sparc (Closes: #293711). > Files: > 67986d29a264d4df66eaa3a100d73260 2028138 libs optional libgtk2.0-0_2.6.2-1_m68k.deb > 506a027f271a6f1c8993e591f852cb84 18106 misc optional libgtk2.0-bin_2.6.2-1_m68k.deb > b19e0e39ac2f24260bbb1caf2e3afec6 7572358 libdevel optional libgtk2.0-dev_2.6.2-1_m68k.deb > 623741d88e1213a7d9dd70bf9f9103bd 17831436 libdevel extra libgtk2.0-0-dbg_2.6.2-1_m68k.deb > 76df666d13590f0eef8579787a0c2e12 252126 x11 extra gtk2.0-examples_2.6.2-1_m68k.deb > 7fb77d74d5b6c782bea53fa47bc1f172 44420 libs optional gtk2-engines-pixbuf_2.6.2-1_m68k.deb > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD4DBQFCCms4PfwsYq950p4RArEPAJicu9/GwlVIHxfc+9Ln3cX2S701AJ0REvsG > rfLZZxuq0ahi2x69KhlXMw== > =rBMd > -----END PGP SIGNATURE----- Your mail could not be processed: Package gtk+2.0_2.6.2-1 (unstable) is outdated. The following new versions have appeared in the meantime: unstable: gtk+2.0_2.6.2-2
Yell. Scream.
Tue, 08 Feb 2005
DoS the spammers
How does one stop spam? I don't think it's possible to entirely stop it. But it could be possible to make it less interesting, or at least less easy. DoS the spammers. Of course, preferably without DoSsing yourself.
I'm thinking about setting up something like the following:
- Make sure I use SMTP-time spam filtering.
- Write an application 'throw-junk-back' or something that will take an IP address on the command line and a bit of data on stdin, that will pick five random numbers between 1025 and 65535, and that will send the stdin data to the IP given to it on the UDP ports with the numbers we generated.
- When we're quite sure that what we received was spam (in case of spamassassin, when the score is above 15 or so), pipe the mail to 'throw-junk-back' with the IP of the connecting system.
If everyone would do this, then spammers will require four or five times their current bandwidth (not six times, because UDP has less overhead than TCP, and there'll also be false negatives), which is going to cost them a /lot/ of money, whereas it would not really hurt people that get hit by false positives (provided that only happens once or twice).
Is that a good idea, or am I crazy?
Mon, 07 Feb 2005
not atypical
Thomas Vander Stichelen talks about how he's downloaded an album, but plans on buying it anyway, and claims he's probably atypical in doing that.
Well, I'm not sure. I've downloaded a fair number of Star Trek: Voyager episodes over the last year or so, and I've become a fan – even though I almost never saw it while it was still on Kanaal 2, one of our Belgian TV stations. I like them so much that I've decided I want them all, so I've added them to my wishlist, and have bought the first season already. I will buy the others as soon as my budget permits it (they're quite expensive, but still worth it). I don't think we're so lonely as Thomas suggests. In fact, I know quite a number of people who buy the CD after they like a few of the downloaded MP3 files they have on their hard disk.
Maybe the recording industry should stop thinking of MP3 files as infringing, and start using them as the marketing instrument they really can be, for instance, by allowing people to share low-quality MP3 files but requesting they buy the CD if they want better quality or want to use it for professional purposes, or so.
...
Oh my. I just suggested a shareware-type of distribution for music. This can't be right. I must be sick.
In fact, I am. Philip, my business partner, stayed home sick today, and my nose and head aren't feeling well. I also appear to be having a fever. I would've been to bed, if not for this customer who's doing a server migration at this exact moment and requires me to do some DNS changes from time to time. Sigh...
Thu, 03 Feb 2005
Beefing up pop
pop, my parents' computer, is a Pentium I @ 133Mhz. It was running Windows 98 since ages
Since I haven't installed that system on my own machine since about four years or so, I was getting more and more problems in supporting them. I had suggested a few weeks ago they try out GNU/Linux, but they seemed afraid of that. And being stubborn and persistent is unfortunately a family trait, so I couldn't convince them, even if they are already using Thunderbird for mail and OpenOffice.org for office under Windows.
Luckily, Windows itself came to the rescue. Something's gone awry with kernel32.dll, and it doesn't boot anymore. Since the darn thing a) contains a mass of software they regularly use, and b) is frigging slow, I wasn't too happy to reinstall the box. So, I rebooted the thing to GNU/Linux, configured Gnome, and Thunderbird the way they were used from Windows, and let them use that "until I find the time to reinstall Windows". That might take longer than expected, but if they're really not happy with GNU/Linux, I will reinstall Windows. I still have to be able to live with them. For the time being.
Anyway, the kernel32.dll happened a few days ago, so today dad told me the system was running too slow to their liking. Considering the fact that Gnome 2.6 isn't exactly meant for systems running at 133Mhz, this isn't really surprising, and I should've known better than to hand them a default Gnome desktop. This needed fixing.
So, what can a guy do?
Quite a few things, apparently.
- The Gnome system administrator's guide, which is available through a certain specific website I was pointed to a few weeks ago contains a nice chapter 9, which helps to disable those settings in Gnome that eat the most resources. But that, of course, isn't enough.
- Since one of the complaints was that the system took so awfully long to boot, I tricked it into appearing faster. cd /etc/rc2.d; mv S99gdm S19gdm; mv S99rmnologin S19rmnologin can do wonders.
- While doing that, I discovered that there were a huge number of useless packages installed on pop. Which isn't surprising; I originally installed GNU/Linux on this machine when potato had just been released. That's ages ago. In the mean time, it has been upgraded, upgraded, extra software installed, some software removed, and was hardly used. Thank God for debfoster. I ran debfoster -n, and threw about 800M worth of software off the system. That included things that were useless on this hardware but do run a daemon, such as the sensord package. Helpful.
- After all this, i ran top and had a look at the result. The system ran considerably faster, but there was still room for improvement. One thing I noticed was that with no software running except for Gnome, gnome-terminal and top, it had actually more swap space in use than I had physical memory. That couldn't be a good idea. So, I thought about the things I could do about that; and this reminded me to the fact that the migration of services from folk to western I had been doing had almost been completed; and that folk,a 100Mhz Pentium, requires the same type of RAM as pop. Back before I had western, folk was everything and the kitchensink in my network – NFS- and Samba-fileserver, Windows PDC, mailserver (exim4, courier-imap, and IMP), router, firewall, LDAP; it did backups, updated the F-Prot virus data files on other systems, and did DHCP and DNS. So it required quite a bit of memory to keep all that going smoothly. Since, however, most of those services have now been taken over by western (with the exception of the router/firewall, DHCP, and backup stuff, all are migrated), it doesn't need as much RAM anymore. So, I removed two 32M SIMMs from folk—now running on 16MB of RAM—and added them to the 96M already in pop, to end up at 160M of RAM.
That should do it. I hope. I switched it on again, but didn't wait for it, as it was late enough already and I really had to go to work now.
While typing this on the train, however, mom called me on my cellphone that pop didn't boot properly. It was waiting for folk; apparently there's still an NFS mount configured, but it's not working for some reason. Meaning, it takes over five minutes to get past that stage.
Grmbl.
Wed, 02 Feb 2005
Thank God I don't live in Germany... and I'm male... and I'm not unemployed.
Jamin Philip Gray reported about a little problem in the current German employment laws:
- If you're unemployed for more than a year in Germany, and you refuse a job offer, you can apparently lose your welfare benefits. Which is reasonable; the same is true in Belgium.
- Since 2002, prostitution is no longer illegal in Germany; prostitutes and brothel owners pay taxes like everyone else. This was done in an attempt to fight trafficking in women, which is reasonable. As a result of this, brothel owners can now send out job offers for prostitutes in exactly the same way a hospital can send out a job offer for a nurse, possibly through a job centre where unemployed people would go and ask for a job.
Now combine the above two.
Tue, 01 Feb 2005
Releasing Debian
Yes, I know there's a wiki entry about that subject, but I happen to think wikis are a horrible way to discuss stuff. I don't like them. If someone thinks what I say makes sense and is interested in adding this (or a synthesis thereof) to the wiki, be my guest.
I've been thinking a while about why we can't seem to be able to release within a reasonable time. What exactly is "a reasonable time" is, of course, open for discussion; but the time it takes us right now is way more than "reasonable". My take is that to find out what we should do better, we should have a look at our history and try to find out what's going wrong. From there, we should try and find solutions to those problems. We should also not be blind to the world around us: there are other Free Software-projects comparable to our own (the BSD's and Gentoo, but in a way also KDE and Gnome, although those are different) that do seem able to release; it would be healthy to compare their release processes with our own and try to find out where we could improve ours.
I have come up with the following:
- Lazyness
- When the release has happened, we are happy. We have a party, congratulate ourselves for finally doing it, and then sit back and lazily wait what happens. It takes quite a while before someone gets up and say "it's time for us to release again; let's freeze base".
Unfortunately, this means that in the time between releases, people aren't focused on the actual release; if you ask a random Debian Developer about where we are in the release at any given point in time between the release of the then-current stable and the freeze of the next stable, it's very likely they'll tell you "I dunno". I know that was the case for me after potato's release and after woody's. - Time bombs
- Right when woody was about to be released, the security team yelled "whoa there, we can't support woody with this security infrastructure!" As a result, the release was delayed quite dramatically. Something similar has now happened to the sarge release. There's a pattern there. One could say the pattern is that we need to ensure that the security infrastructure is up to date before we release; but the real problem here is insufficient planning. When the release is near, people will find out that we're not ready, and the bomb will blow; at that time, the release will have to wait, no matter what— we can't release with the problem unfixed.
Of course, nobody can be expected to know about every possible and impossible problem before it happens; but people working on a particular task within the project will know if there are any problems that need to be adressed before the next release. They might just not know how close the release really is, and therefore do not communicate it to others... until it is almost too late. It has been the security infrastructure two times in a row now; but if we focus on not letting this happen to the security infrastructure for the next release, I fear it'll just be something else. Volatile not being integrated into Debian proper, for example. Whatever; it could be anything. - The sheer size of the project
- The Debian Project started off like many Open Source-projects do: a few enthousiasts thought it was a good idea to do a distribution, so they did one. When there was a problem, they would talk to eachother or just simply fix it; and when the release was near, everyone would know.
Today, the Project has grown way beyond that original group, with over 1000 individuals having the status of Debian Developer. We could easily fill all but the largest movie halls, opera houses, or stage theaters; if we would celebrate one Debian Developer each day, it would require us about three years to reach the last one of them. 1000 People is the size of a small village. As a result, it's nearly impossible to know each of those 1000 individuals personally. And if we can't know everyone, we certainly can't know what they're working on.
... In other words, I think it all boils down to one important thing: communication. If there are clear channels as to how something must be communicated, those channels are usually used properly. But what we lack is the big picture; someone to manage all the available information about what's needed to release, and communicate that to the Developer body at large. A way for each and every one of us to better understand our role within the scheme of the Release. Act on problems if there are any. This is the Release Managers' job, you'd say, and I agree; but I feel that for some reason that isn't working out as it should1. The fact that there have been time bombs is one prove of this.
This brings me to what I think is the heart of the problem: People in Debian are working way too much separately, and aren't talking to eachother enough. If we have a look at the Gentoo project, we'll see that they have identified some teams within their developer body, who work closely together; they all define a team leader of sorts, and the team leaders have weekly IRC meetings to discuss problems and plan ahead. There's a documentation team, a base team, a desktop team, a Portage team, etc; this ensures problems are dealt with before they're going to be a problem.
I'm not sure applying that to Debian is a good idea, though; I don't want a hierarchical structure where there are leaders and followers. Besides, I don't think our constitution would allow it. Thus, we'll need something else.
Looking at the FreeBSD project, we can see that they send periodical status updates to their announcements mailinglist. We have something similar in our Release Updates, but there are two differences: first, our Release Updates are only being sent when a Release is supposed to be near; second, the Release Update is created by the Release Managers, who will obviously only talk about the things they know about. In contrast, the FreeBSD status updates are sent regardless of whether a release is near; and they are composed after a request for status updates that is sent to their developers. In other words, every FreeBSD developer can write a section for the status update.
I'm thinking it might be a good idea to try this once Sarge is out the door; if people are working on something big, something important, they should have a way to inform the Developer body about the fact that they are doing so. Using -devel-announce could be a way to do that, but people don't usually make announcements about stuff that isn't ready yet; and if we would do so, then -devel-announce would no longer be the low-traffic list it is supposed to be. Grouping status updates into one mail would be reasonable to keep developers updated and informed on what needs to be done before we can release and how much of it has been done already, without annoying the hell out of people by sending them mail every other day.
But will this be enough? I'm not sure.
One thing that seems also quite problematic is that the Release Managers aren't always as informed about the release themselves, either. I was stunned to learn around last september that about a month had passed without a release, and that even the Release Managers didn't know what we were waiting for. I think we should all agree that the Release Managers will need to know at all time what's going on to be able to properly do their job; and that they may have reasons to ask other people that they do something in a particular way, even if that is against their procedure -- for instance, Release Managers might have a reason to request ftpmasters that NEW-processing for some package is done as soon as possible, or that the build of some other package on some architecture is prioritized over other packages; all so that the release won't be delayed. Currently, Release Managers can (and do) ask this of other developers, but if those other developers decide that they're too lazy or that they disagree with the Release Manager's decision, they will simply not do it; and there's nothing the Release Manager can do about that.
Of course I'm not pointing any fingers, nor am I advocating that the Release Managers be given some extra powers that would allow them to overrule any developer's decision without paying any attention to that developer's wishes; I do think, however, that they should have the ability to do what's necessary to make the release happen; and that might require more than just the ability to edit britney's hints, or politely ask other developers to please do something for them.
Whoa, this post ended up way beyond what I intended it to be. Let's keep it at that; in summary, I think the best course of action would be to
- Not stop doing release updates after sarge is out the door,
- Allow people beyond the Release Managers the ability to get something in the release updates, so that subprojects the Release Managers aren't familiar with can be more easily made public, too. This might include stuff that isn't necessarily important for the release,
- And finally, to give the Release Managers more powers. They don't need to become the Project Managers, but they should have the ability to say 'I want you to do foo, because the release is waiting for it' without being frowned upon
Of course, that might not make any sense, be stupid, or things might already be (partially) done that way. I dunno, I'm not a Release Manager...
1That's not to say that the Release Managers aren't doing their job right, of course; please read on
Found it!
I thought I had lost my Debian T-Shirt a while ago. Apparently, that isn't true; I found it back this morning while going through my clothes trying to find a T-Shirt to wear.
Happily wrapped inside the Debian logo right now...
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|