Combining ScriptAlias and DirectoryIndex
Apparently that's not possible. When you say "ScriptAlias /cgi-bin /usr/lib/cgi-bin", everything under /usr/lib/cgi-bin is assumed to be a script. That counts for directories, too; so trying to access 'http://localhost/cgi-bin/myapp' isn't going to work, even if you say 'DirectoryIndex index.cgi' and create a file /usr/lib/cgi-bin/myapp/index.cgi.
Workaround: use mod_rewrite:
<Directory /usr/lib/cgi-bin/myapp> RewriteEngine on RewriteBase /cgi-bin/myapp RewriteRule ^$ index.cgi </Directory>
Sucky, but it works.
"Going to FOSDEM"
Planet Debian is currently plastered with this "I'm going to FOSDEM" banner that the FOSDEM people have created. That's great; it means I'll be seeing lots of people there the first weekend of February. I'd put it here, too, but I'm lazy, and people know I'll be there—I'm doing th Debian devroom. So just assume a blue banner here.
What I'm not seeing, however, is talk submissions. So far 5 people have expressed interest in giving a talk, and two have made a definite commitment. That's not enough! I'll probably be sending out second a Call for Talks if I don't get enough submissions by next weekend, but for now, let me give people a list of talk titles I'd like to see in the DevRoom but that haven't been submitted yet:
- The Lenny release cycle: the release team's view
- New stuff from the Debian-CD team. (Not only would that be interesting, I also owe them that much after my messup two years ago.)
- Booting Debian everywhere: the live-CD tools.
- Doing Another Katie: the dak rewrite.
- Debian on the EeePC
- ...or, well, anything people can come up with, really.
People, above all, please remember that FOSDEM is less than two months from now. Usually I can (and do) send the CfT about four months before the actual event, but circumstances have forced us in this position now. If you want to have an interesting Devroom, I need talks, and I need them sooner rather than later. See my CfT for details.
Rails: followup
I received quite some comments on my rant about Ruby on Rails a few days ago; I guess I must have received some inbound link on a ruby-fanboy-website or some such. Most of it is just bashing me since, I'll admit, my post wasn't very constructive (and which according to my policy of only blocking spammers I've not moderated away), some of it just posits another opinion about packaging (which is valid), and one Eric Anderson gave a good and constructive set of arguments that I just have to reply to.
First of all, yes, I hate RubyGems more than I hate Ruby on Rails. However, Ruby on Rails is the major success story in the Ruby community, and the main reason why people use that language; it's not unfair to say that I won't use RoR because of RubyGems. But perhaps I should've been clearer.
Anyway.
Eric mentions that RubyGems "solves two problems that other packaging systems are not addressing": the ability to install two versions of the same library, and the ability to install a single package on multiple operating systems. Well, first of all, the latter one simply is not true. There's CPAN.pm, which does much the same thing as RubyGems; but much of CPAN can be easily turned into a Debian (or RPM, or whatnot) package. The few cases where it can't, you're usually dealing with a broken CPAN package, anyway. There are similar things for Python (egg), and, heck, even TeX (CTAN). The fact that other scripting languages have proper and working packaging systems only outlines that there really isn't an excuse for the horrors of RubyGems.
Second, the fact that you even need to be able to install multiple versions of a library really shows that there's a problem with your development ecosystem. C, Perl, and Python programmers are used to stable APIs, and prefer not to change their APIs all that much. Most packaging systems reflect that preference, and deal with incompatible API changes the way they should: as the exception, rather than the rule. The people in the Ruby ecosystem clearly have a different opinion on that, which probably results in the difference in packaging system requirements. Personally, I prefer the non-Ruby way—I'll leave the discussion about "what happens when you need to do an urgent security update of one of your libraries but the API has changed three times since you last looked at it and now the library update breaks your application" as an excercise to the reader.
In closing, I'd like to reply to this one sentence that Eric put in his comment:
And of course there is no reason software cannot start as a gem (for people close to the ruby community) but as it's popularity increases packages can be created that are more tightly integrated into the native package manager.
Well, in an ideal world, he'd be right: there would be no reason. Unfortunately, in the RubyGems world—which is far, far away from an ideal world—the fact is that packaging RubyGems in a sane way so that they'll integrate with the rest of a Debian system is simply impossible. You simply cannot currently go from a gem and create a package out of that, because of how gems are done. That, more than anything, was what I was objecting to.
I can understand that many Ruby developers do not care about this much; that they are used to RubyGems, and that they can geet anything they need using that system. However, they should understand that different people have different preferences, and that packages for systems other than RubyGems is going to be necessary if their software is to become popular beyond the select set of people who care enough about Ruby. I personally know of plenty of people (myself included) who prefer things to be installed as operating-system level packages on the Linux systems they install; and even if it's not your personal preference to do things that way, you should at the very least not stand in the way of those who do.
The advantages of a home-grown comment system
A while ago, I was investigating the possibility to move blog backend to something else; something like, say, drupal, so that I wouldn't have to maintain it too much myself.
For those who care, this blog is a very strange contraption based on subversion, blosxom, php, and a postres backend for the comments.
I've now dropped that migration thought, for a very simple reason: comment spam.
A while back, the spammers had found my blog, and started placing comments using a bot. They might think that these comments will eventually show up on my website, but that's wrong; I always moderate away spam. First, they posted a few comments. I changed a few details about the form, and the bots (who only went to the POST URL, never checking whether the form they requested was unchanged) failed miserably. Then, they posted loads and loads of comments, in a weird attempt to overrun me with comments. One psql run and one DELETE statement later, those comments were gone -- and one minor form change later, the bots failed miserably, again.
This went on for a few months, until the stupid spammer finally understood that he was wasting loads of his time in trying to post something on a website that wasn't ever going to enable his comments, anyway. Or so I thought.
You see, the thing they're really after is my pagerank. In itself, grep.be is nothing special -- but planet.grep.be is, and apparently some of that pagerank score trickles to the other grep.be subdomains. Or, at least, that's what the spammers seem to think, in case it isn't (I wouldn't know).
When the comment spam on my blog had been silent for a few weeks, I found that the spammers had found my gallery installation, and had posted some several thousand comments there. One DELETE statement later they were gone, but a few hours later some of them were back.
I don't know the gallery source code well enough to pull the same trick here (disable comments until manual moderation), and unless I want to do something like using a CAPTCHA on my gallery site (I don't) or disabling comments altogether (I don't, either), I'll just have to resort to removing these comments from the database.
At least by doing that, I can remove them all in one go. And at least the spammers are easily recognizable. For now.
Perhaps I'll have to look into changing gallery's source code after all... or, perhaps, just use something else. Sigh. Stupid spammers
Samba's tdbtool
root:~# tdbtool gencache.tdb tdb> keys [...] key 14 bytes: NBT/BEFS01#20 [...] tdb> show NBT/BEFS01#20 fetch failed tdb> show NBT/BEFS01#20\0 [...data...]
Or, in other words: string delimiters are part of the string, as far as samba is concerned (oh, puh'lease!)
-lgnodbify-gtk
A while back, I wrote about this GObject-based Object/Relational mapper that I wrote, which is called 'GNoDbify'. It isn't complete yet, but parts of the library work; I use it for a project that I'm supposed to commercially support. For those who don't know what that is: an O/R mapper builds objects out of database tuples; so I can run a 'lookup' function on the object class and get one (or more) objects representing data from the database, then perform some modifications on that object, and store it back in the database; my O/R mapper does all the SQL magic.
Last week, I've been working on another object that takes an array of GNoDbify objects, and presents them using the GtkTreeModel interface, for easy viewing in a GtkTreeView:
my @customers = Vpbs::Db::Customer->get_all();
my $model = GNoDbify::ListStore->new_from_array(@customers);
my $view = Gtk2::TreeView->new_with_model($model);
my $renderer = Gtk2::CellRendererText->new();
my $column = Gtk2::TreeViewColumn->new_with_attributes("Name", $renderer, "text", $model->get_column("name"));
$view->append_column($column);
And there you have it: a treeview showing all the names of all the customers in the database. On the classical approach, one would have to use DBI or some such to fetch data from the database, create a GtkListStore or something similar, and then append the data one row at a time to that. Of course that still happens here, in a manner of speaking, but it all happens behind the scenes. It also means that in an application which wants to show a load of data, I don't have to do the same thing all the time.
The magic happens in the second line, and in the second-to-last line. GNoDbify::ListStore->new_from_array is pretty much self-explanatory, really. It takes an array of GNoDbify objects, and returns a GNoDbify::ListStore.
The second-to-last line shows how to add a column to a GtkTreeView. With GtkListStore and GtkTreeStore you basically define yourself what column gets what number; however, with GNoDbify, that isn't as easy (it depends on the implementation of the GNoDbify subclass), so the ->get_column returns the number of a column as represented by the model, and wants the name of the field that you want the column of.
Everything else is really the same.
It won't stop here, though. The original plan for GNoDbify was that it could detect changes in the database, and update the tree model accordingly. Most of that has already been implemented in GNoDbify (though not yet in the ListStore thing), but just needs some debugging. The fun thing is, the above six lines of code would not have to change at all for that.
Of course all this juicyness comes at a price. In order to generalize this much, I had to do a lot of extra stuff; so there's some performance loss. Especially in perl; most of GNoDbify is written in C, and converting perl arrays to and from C arrays is a process that can only be done by looping over the perl array (or the C array) and creating the other side of the equation. Obviously, that's a costly approach, performance-wise; an obvious optimization of the above example could be to have a subroutine that returns Customer objects already in a GtkTreeView in one API call. We'll see.
Planet Sucks
That is, the python software which runs a blog planet; not a particular planet instance.
Case at hand: I wrote a rather extensive piece on the current Debian vote, but it's not showing up on Planet Debian for one reason or another that I can't immediately find out.
I wouldn't even have know if not for Kurt, who noticed that it did show up on Planet Grep, but not on Planet Debian.
I contacted the planet people, hopefully this will get resolved. Perhaps it's related to the fact that I semi-accidentally also committed that blog post about gnodbify-gtk, which I still had to proofread. Oh well...
The pragmatist pledge
I had a revelation a few days ago.
Years ago, I had a tendency to hit my computer screen when the computer would not do what I wanted it to do. I stopped that at some point; like I said, it was years ago. That's not the big revelation, though.
The big revelation was the fact that the day of me stopping to hit the screen happened to coincide with the day of me reformatting my Windows partition to free up space for /home.
I guess that, more than anything, is the main reason why I've never looked back. Though I subscribe more to the Free Software philosophy than I do to the Open Source philosophy (that is, "software should be free" rather than "open source improves software quality"), I do not think Free Software is the end solution to all problems relating to software. In that regard, I am a pragmatist: if there is a free alternative, I'll prefer to use that, but I do not shirk away from using something which is non-free—or not entirely free—when it will solve a problem.
In that context, I have recently been somewhat depressed and demotivated because of some things that have been happening of late in Debian. Without wanting to comment on the case at hand, I must say that after having been a Debian Developer for almost eight years now, I am starting to see a pattern:
- Debian releases
- Developers are happy, and start working on all sorts of new code to put in Debian
- We work a lot, and interesting things happen all over our code base.
- Somebody (presumably someone from the release team) calls a freeze.
- Because new features are a no-go now, suddenly loads and loads of people have too much time on their hands.
- Loads and loads of people spend time looking at other people's bugs, and see things they do not like.
- Suddenly, it becomes immensely important to resolve that issue now. Never mind that we're about to release, that can wait. Never mind that some people actually depend and/or wait on the next Debian release. That doesn't matter. All that matters is that this issue must be resolved now, because it's not free!!!1!!.
As a pragmatist, I'm extremely unhappy about that. Yes, I agree that getting Debian rid of non-free software is a worthy goal, but not at every cost. Yes, I agree that releasing Debian with non-free software is a bad thing, but did people really have to wait until we were about to release to bring that issue up?
The problems were out there for a very long time. Ignorance is not an excuse; if you cared about these things so much, you could have looked for them earlier, too.
I'm not about to say what people should and should not do during the freeze. But as a pragmatist, I do not think that bringing up such issues when we're trying to release tings is a good idea. So I'm putting forward this pledge, which I call "the pragmatic DD's pledge":
I will not, deliberately or otherwise, delay the release of the next Debian stable, by proposing or seconding a GR that will have an impact on the release schedule when the freeze is in progress. I will instead make sure I detect such issues before the freeze has started, or will deliberately wait until after the release has happened before bringing these issues up.
As for the current Lenny vote, here's my ballot:
[ 4 ] Choice 1: Reaffirm the Social Contract [ 2 ] Choice 2: Allow Lenny to release [...] [ 2 ] Choice 3: Allow Lenny to release [...] [ 2 ] Choice 4: Empower the relase team to decide about allowing DFSG violations [ 2 ] Choice 5: Assume blobs comply with GPL unless proven otherwise [ 1 ] Choice 6: Exclude source requirements for firmware (defined) [ 3 ] Choice 7: Further discussion
My only wish is that I would now also be able to find some more time to fix some RC bugs. Sigh...
(as an exception to my policy, comments on this item will be silently dropped. UYOB)
update: Only after I posted this blog entry did I see that many other people had issues with this insanity; and I see some problems with some of the voting strategies that people propose. Let me make something clear: if you do not want choice 1 to win, then you must not vote any of the other options below "Further Discussion". The reason is that since those need a 3:1 supermajority, and since supermajority is decided by whether an option on the ballot beats Further Discussion in our voting system, this means that if more than 25% of our voters vote everything below "Further Discussion", Choice 1 will win by virtue of being the only option reaching its required majority.
If you think, like I do, that "releasing Debian" is more important than "being able to tell people that vrms isn't lying to you", then you should vote Choice 1 below "Further Discussion", and vote all the other options above it, even those which you think are not the best option; because if your preference does not win, then at least you allow the other options that you can live with to stand a chance of reaching the required supermajority, and will allow them to win.
Also note that if you've already voted, you can still change your vote!
On fixing firmware blobs
Ingo blogs about the current vote, and wonders whether we did not have enough time in two years to do something about the fact that there were firmware blobs in the kernel.
Well, we did, and we did. It's just that in two years, several new kernel releases came out, and that also resulted in some new firmware blobs entering the kernel. This, in a way, is a relatively new issue.
Having said that, I do agree with his sentiment; even if they're new issues, they could and should have been fixed ages ago. As I said in my 'no more hitting' post, too.
Speaking of which, Jorg did not understand why that post did not show up, either. So I've just moved it into /en/computer/debian (where it belongs, really); perhaps that will fix it. Having been the maintainer of Planet Grep for a few years, I know now that this kind of strange behaviour would not be beyond planetplanet...
Manoj Srivastava resigning
I went on IRC to ask a simple technical question earlier today. I wasn't going to ask it in the #debian-devel channel, since it was a samba question rather than a debian-related one; but since my IRC client was still running, and had that channel active, I couldn't help but notice some discussion about "what-ifs" when there isn't a secretary, and who gets to do what then.
Surely this was idle speculation, I thought? But that can sometimes be fun, so let's look at the backlog, and see...
That's when I found out that this wasn't, in fact, idle speculation.
Oh dear.
Well, that's the end of an era, I guess. Not that it wasn't totally unexpected; when I learned that Neil McGovern had become "assistant secretary", I already suspected that Manoj was going to resign eventually, and he does confirm that suspicion in his resignation email. However, the suddenness of it certainly was unexpected.
Here's a tip of the hat for everything Manoj has done for Debian so far. I can only wish to be at your level.
What does distress me, however, is a part of Manoj's email, in which he mentions some people had been trying to get him kicked from the project:
As to the people who emailed me that they are putting together a petition for the DAM to have me removed from the project, I hear you too. I am going to spend the next few days evaluating how important the project is to me, and whether I should save you the bother or an expulsion process.
Well, Manoj, if my voice means anything to you: ignore those people, and stay a happy Debian Developer. You became project secretary not too long after I became Debian Developer, and over the years I've learned to respect you as a person with great integrity for your work, who would always do what you considered to be "the right thing". Even when I disagreed with you on what "the right thing" is (and there have been cases of this happening, including this particular vote, although I wasn't very active in the discussions), I have never been able to pinpoint our disagreement on you abusing your position as secretary in order to win the argument, or some such. You have been consistent and (where necessary) predictable in performing your duties as project secretary, and that is a great compliment. I can only hope we'll see those same virtues in our next secretary.
As for that expulsion process, please do not tell us who those people were, for I do not like seeing people made utter fools of in public.
Metablogging
Ciarán O'Riodan blogs about how to blog, and his post is a good read. Most of it is solid advice, and I find there's little I disagree with; if you want to get a blog that's well-read by many people, then his advice is probably sound. So why am I posting this in my 'retorts' category?
Because I feel that blogging isn't something that should be taken too seriously. A blog is an outlet, a place to get your thoughts out; it is a bit of a combination between a column and the readers' letters section in a newspaper.
The writing style of a blog should reflect that; when I write a blog post, I don't care about what the truth is, I only care about my opinion. If I want to write the truth, I'll write a wikipedia article. If I want to read about the truth, I'll go and kill myself—because I'm not naive enough to think something like "the truth" exists in this life. And if I want to read a magazine-style article, how about I'll go buy a magazine instead of reading a blog post?
A blog post doesn't require references (beyond, perhaps, what you're replying to); a blog is a reference, one to the personal opinion of the author. If you think something is great, then as far as your blog is concerned, that something may be the best thing since sliced bread. If you think something is ugly, crap, and should be forgotten about, then on your blog it is. In more than one sense, blogs are like opinions: everybody has one.
That doesn't mean I disagree with most of what Ciarán wrote; on the contrary. Points 1 through 3, and 6 through 10, will help you develop a good writing style. I couldn't agree more on point 11, that you have to push for publication yourself; and it's certainly true that being aggregated is a good way to put your thoughts in context, and to expose yourself to a larger readership. But I vehemently disagree with his point 4:
It can take time. A good article-style blog entry can take six hours to write!
Not that I think writing a blog post should take no time at all—this particular one has been almost an hour in the making, now—but because I feel that, simply, articles, with all their references, scientific or other background, and whatnot, simply do not belong on a blog. A bunch of articles with an RSS feed is not a blog, plain and simple. So while I do agree that it can take time, I do think you're doing fundamentally wrong if your blog post takes more than, say, an hour and a half, to be written.
So, in the interest of being constructive, here are my own suggestions:
- Don't think too much, just write. It may sound stupid, but the most important part about blogging is actually doing it, and not wondering about how or why.
- Do reread if possible. While blog posts are usually read in a few minutes, they take much longer to write; it's easy to lose track of your line of thinking during that process, in which case you may end up with a completely incoherent post. That certainly is to be avoided.
- Ciarán's argument that if it's worth doing, it's worth blogging
about certainly holds merit, but I'd go one step further: if it's
worth thinking about, it's also worth blogging about. After
all, a blog is mostly a braindump, so why not?
That's not to say every thought can be turned into a coherent blog post, and I have a bunch of half-finished unpublished blog posts on my local hard disk which I may revisit at some undefined point in the future; but the principle is there. - And last, but not least: don't care about what other people are doing. Your blog is your own, not someone else's; if you get an email that your content sucks, ignore it. If you get an email that you should be writing about something else instead, ignore it. You're not getting paid for your blog, are you?
Shopping for a new laptop
So my current Apple PowerBook is now 4 years old, and starting to show its age. Some parts of it have been replaced (keyboard, hard disk, bottom cover, and battery), and now it's starting to have issues again. It's not breaking down completely just yet, but seen its age, I might as well start looking for something new rather than having it fixed.
I bought this PowerBook because I wanted a laptop that did not have an Intel or AMD processor at its core, which at the time meant either apple or tadpole; since, however, tadpole is only for the rich and famous (seriously—well, perhaps being famous is not a requirement), and apple now also only has intel-based laptops, I guess I'm stuck with intel stuff. Besides, a 1.2Ghz SPARC is slower than my current 1.3Ghz PowerPC.
So, dear lazyweb, I'd appreciate any suggestions about good laptops. What 'good' means, in my eyes, is the following:
- Long battery life. And I mean long. My current laptop has 4 hours on a new battery, which is not really short, but I find that to be somewhat unsatisfactory.
- Good Linux support. The days when I used to enjoy fiddling with software configuration for three months until everything works just about right are over. I'd prefer to buy, install Debian, and be there 99% of the way.
- A wireless chipset that does not require ndiswrapper, binary kernel blobs, or similar kludges. This is really part of the previous item, but important enough that I thought I'd mention it.
- Bluetooth. I guess this is somewhat standard these days, but one can't be too careful.
- No nvidia. I don't want to have to deal with their braindamage again.
- A full-sized keyboard. That is, it doesn't have to be a 17" laptop with numeric keypad and everything, but I do not want smaller keys than normal. I'll be using this laptop as my main workstation for several years to come and I do not like the prospect of developing RSI, so it had better have a good keyboard.
- Durable. As my business partner likes to say: "wouter is an expert in breaking laptops". Obviously I don't do that on purpose, but a laptop that is to be my laptop ought to be able to survive a few bumps here and there.
I guess the above list is quite long, and realize that my ideal laptop might just not exist; but hey, it never hurts to try, right?
If it does not come preloaded with Windows, that's a plus; but OTOH, wiping a hard disk is not hard.
I should also note that I'm not really interested in the low-price laptops that are available everywhere these days. Those usually have much lower performance, too small a screen, and other cutbacks that make the laptop be less than interesting for me. This is for work, not play.
Cantilene "Jeugdkoor van het jaar"
or, "Youth choir of the year"
Between my 16th and 25th birthday, I was a happy member of this particular choir; and today, five years later, there are still many members of this choir that I know personally—including, of course, their conductor.
It's not the first time Cantilene joined the race for "Choir of the year". The first two times, I was still a member. However, it is the first time they won in the category "youth choirs"; the first time, Cantilene came up second; the second time, we unfortunately did not make it to the finals. The fact that they did make it this time around, gives me mixed feelings; of course I'm happy that they won, but I'm sad that I couldn't be part of it this time. Well, that's part of getting older, I guess.
In any case, here's a big contratulations to Cantilene!
For those who care, if you do a search on youtube for "Cantilene", "Koor van het jaar", or "Luc Anthonis" (the conductor), you'll find a number of films—most of them from the Canvas belgian TV station.
In related news, with Caljenté (the choir that I am a member of, today) we had two concerts last weekend. They were a success, but unfortunately no thanks to me; I lost my voice somewhere during the evening of the 20th, and thus was quite unable to sing most of what we were going to sing. That did not stop me from being on stage and singing anyway, but I had to playback about half that time...
Here's for hoping that my voice will be better on christmas, since we're singing in mass then... I'm mostly there, but not quite entirely yet.
Root on NBD, now with partitions
A while ago, I wrote an initrd script and hook that would allow one to run a system with root on a Network Block Device (NBD), that I maintain both upstream and in Debian.
Since then, Laurent Vivier submitted a kernel patch that got merged, and which will allow one to partition an NBD device. I had a patch for my initrd script that would support running root off a partitioned NBD device, but did not yet have the time to test and debug it.
Until today, that is. Well... not really. I made the time, but I didn't really have it. For reference, the time is 07:25 right now, and yes, I did stay up all night. But, well, who cares, right?
Right.
I'd really love to get this into lenny still, but since we're in deep freeze... not keeping my breath. We'll see, I guess. The upload is going to unstable, anyway—after this one final test.
So how does it work? Unfortunately, no d-i support as of yet. I'd been working on that, but then it turned out that in order to support root-on-NBD, I'd have to somehow, somewhere, teach partman that NBD is this strange thing which can be formatted, but not partitioned. I was way far in my research (but nowhere in code, yet) on that when Laurent sent in his partitioning patch, so it got postponed then, and I didn't get a chance to pick it up anymore in time.
But if you're willing to use debootstrap manually, it's really simple to set up:
# apt-get install nbd-client # nbd-client server port /dev/nbd0 # fdisk /dev/nbd0 [... create partitions ...] # mkfs -t ext3 /dev/nbd0p1 # mkdir /mnt/tmp # mount /dev/nbd0p1 /mnt/tmp # debootstrap --include=nbd-client sid /mnt/tmp # echo KILLALL=false >> /mnt/tmp/etc/nbd-client
The "KILLALL" is necessary, since otherwise the nbd-client initscript will do nasty things with your root filesystem. Note that you still need nbd-client installed and run the initscript, even if it only uses nbd-client inside the initrd; because the initscript writes the nbd-client PID to /lib/init/rw/sendsigs.omit.d, which is also required if you don't want sendsigs to shoot the root filesystem from under your nose. This might see some changes in the future.
Now boot with your kernel and initramfs, and boot it with the following arguments:
nbdroot=server,port root=/dev/nbd0p1
Obviously, in the above two examples, you should replace 'server' by the IP address or hostname of your server, and 'port' by the port number on which your nbd-server is running. It is of course also possible to use nbd1p2 or nbd0p4, should you want that.
And that's all there is to it.
Well, almost; due to the way the network configuration is written in initramfs, I had to choose between reinventing the wheel, or hardcoding the NIC name to 'eth0'. I chose the latter. What this means is that if you want to boot off an NBD blockdevice that is only available on eth1 or wlan0 or some such, you lose.
Other than that, go ahead and try. Should be on a DMNY (Debian Mirror Near You) RSN.
Update: fill in the link to git.kernel.org, and mention the KILLALL thing. Oops.
Why GNOME sucks
A recent post by Adrian von Bidder got me to reread the "Printing dialogs and GNOME" thread that Linus started on the GNOME mailinglists a few years ago. I don't know how or why I missed it back then, but I did see this little gem in a post by Mike Shaver:
You and I are not interesting GNOME users, in part because we already _are_ GNOME users. The interesting GNOME users are the ones that haven't tried it yet, and we need to figure out why they haven't. There are lots of things that I want in GNOME, but if they aren't going to bring a hundred thousand of my closest friends along as well, I would hope that nobody goes out of their way to do them.
That is precisely what is wrong with the GNOME people. While encouraging new users to try and use GNOME certainly is a good and worthy goal, it is this mentality of 'only the new users matter, the existing ones can go f*ck themselves' which will ultimately drive away users.
Of course this post is a few years old, and I'm not involved in GNOME development in any way, so this mentality might have gone away now; but I don't hold my breath.