Tartan theme
Debian so needs a Debian Tartan theme.
For reference, my .Xresources file contains these xtartan configuration items:
XTartan.colorCode.EB: rgb:09FF/21FF/48FF XTartan.colorCode.DR: rgb:57FF/0000/0AFF XTartan.colorCode.DY: rgb:E4FF/A8FF/48FF XTartan.Mine.nextTartan: Debian XTartan.Debian.sett: %a EB16 DY2 EB16 DR16 BK2 DR16 W6 BK2 W2 BK2 W2 DR6 W2 DR6 W6 BK2 W2 BK2 W2 BK2 W2 DR6 W2 BK2 W2 DR6 W2 BK2 W6 DR6 W6 BK2 W2 DR16 BK2 DR16
Which (when calling xtartan -r -t Debian) provides for a nice Tartan background; but it's not a theme. I'd do it myself, but I'm not a graphical guy; but I would so love such a theme.
Someone with graphical skills please make it!
Debian @ FOSDEM 2009: Postmortem
Well, no, neither FOSDEM nor Debian are dead. But FOSDEM '09 is gone, over, and dealt with.
It was a breeze, for the most part. I'm still not very happy with the booth; that needs to be done better next year. Help and suggestions in that area are more than welcome.
One thing that more than deserves a follow-up is Lucas' post about FOSDEM:
On a more sad note, the worst talk of the week-end was without any possible doubt Frans Pop's release team bashing. Nobody is claiming that the release management of the lenny release cycle was perfect: there's always room for improvement. But given the context and the constraints, I think that they did a very good job. Frans' talk boiled down to: "The release team doesn't know what they are doing, I would have done much better because I'm so qualified."
As the person responsible for allowing Frans on the schedule in the first place, while being fully aware of the relationship between Frans and the release team (not at first, but certainly in time to kick him off if I'd have wanted to), I'd like to comment on that.
First of all, I do not agree that the last statement in the above is true. Frans showed a few stories of things that went on in the release team, and gave his opinion on what he believed went wrong. He also explicitly said, at the beginning of the talk, that none of the talk was meant personally; that he wanted to offer some constructive criticism instead. I believe he did not fail in doing that, but of course YMMV.
Secondly, and more importantly, I do not believe it is healthy for
Debian (or any project, for that matter) to reject criticism. Indeed,
nobody is claiming perfection. I do not believe any venue where talks
can be had should be a good news show
. People in a position of
power—not just the release team, but also, say, the DPL,
ftp-masters, buildd maintainers and whatnot—have received our
trust to do what they need to do to the best of their abilities. If
someone in the project would believe that I can significantly improve my
work as buildd maintainer, it is not just their right, but indeed their
duty to inform me of that fact. This is exactly what Frans was
attempting to do, and there is nothing wrong with that.
It is also not as if he's not tried reasoning with the release team first. He has made suggestions, which have gotten ignored. I feel that talking to more people about what he feels is right, to see whether they agree with him, is the next logical step to take, and that this it is exactly what Frans was attempting to do at FOSDEM.
Having said that, I agree that finishing the talk late was a very bad thing. If anything, a talk on a subject like this should have more, not less, time for discussion. So while I do not agree that his intentions were wrong, I do agree that the execution could have been better.
There, that was criticism too. Now, what's next?
Oh yes, suggestions. If people have suggestions on how to improve the Debian presence at FOSDEM next year (especially, as above, ideas for creative use of the booth would be welcome), then please send me an email, making sure the subject contains the word 'FOSDEM', so my mailfilters know what to do with it. You'll preferably do so now, while FOSDEM is still somewhat fresh in your memory; I'll take notes and use those for doing better next year.
Thanks,
Heather Dale: Live in Köln
Last june, I went to Cologne to visit a friend
I'd first met Heike at Debconf7 in Edinburg, where we had much fun playing some music together. So the next time we met, which was at FOSDEM '08, she told me that she'd been playing in a band. As in, the kind of people who make music profesionally. Which was really cool. She also told me that this band, which consists mainly of a Canadian couple, would be playing in Cologne in early june, and that perhaps it'd be nice if I could come over to watch.
Considering that'd be a nice excuse for a short holiday, I went, and had a great week in Cologne. Since Heike and the others had to practice, I only saw them in the evening; but Cologne is a great city, with interesting museums and other things, so I would spend the day sightseeing in Cologne (and Bonn on one day), and would be at the particular bar or whatever where the concert would be in the evening. I had a great time. Before going home, I bought one of their CDs, since I really liked the music.
Anyway, at this year's FOSDEM, Heike told me that there was a new CD out (actually MP3 downloads), made from a recording that was done at one of the concerts. So, today, I bought a copy.
Come to think of it, this is the first time I bought an album of a concert that I actually went to, and where I did not perform myself. After all, I don't really go to concerts all that often—unless I'll be on stage.
What's strange is that the music sounds slightly different from how I remember it. The mind can do strange things... or is it the case that a recording is not the real thing?
Probably. In any case, the music is great, so go check it out!
RedHat sucks
So a customer of mine needs to use RedHat. It's not their choice, the choice was forced upon them by the people who wrote the tools they need to use.
The new version of this particular tool which they wanted to use requires RHEL5, and they're currently running RHEL4. So I had to upgrade their systems from RHEL4 to RHEL5. No sweat, right?
Yeah, right.
RedHat has this nice 'Red Hat Network', where you can manage your servers, and remotely mark packages for upgrade. You can also, by way of a command line tool, say that you want it to upgrade from one release to another. This can't be done remotely, which sortof makes sense; upgrading from one release to another might cause problems that you really really don't want if you don't have an immediate shell. So you should use 'up2date --upgrade-to-release=5' to upgrade from RHEL4 to RHEL5.
Except that that doesn't work. For some reason, RedHat chose not to support in-place upgrades from RedHat 4 to RedHat 5. Instead, you have to download installation media, boot from them (thereby inducing downtime) and select 'upgrade' in the installer. Which part of this distribution is "Enterprise", again?
Oh well. So I download the first ISO, and start the upgrade process. Surely that'll work, right?
Hah. No, I really need all six images. So I download them, and start again.
Some minutes into the installation, the HP iLO session that I'm using times out, and takes my Virtual CD device with it. As such, the installer-in-upgrade-mode obviously can't find the CD-ROM anymore, and produces a read error. This is totally normal. The system provides me with a 'retry' button. That button doesn't work.
That is to say, it works, but after two or so files, the installation goes to a grinding halt. I had to reboot, and start over.
So after rebooting, changing my iLO session settings so the timeout is at 120 minutes (the maximum) rather than 30 minutes (what appears to be the default), and I restart the upgrade process, making sure to click in the iLO interface every once in a while to keep it active. When it's somewhere at 80% and 3 hours into the upgrade process (god, why does that have to take so long?), it suddenly finds itself out of disk space.
Well, shit happens, of course; guess there's nothing to blame RedHat with that one. But the way this situation is handled, is beyond my comprehension:
The only 'recover' option is 'reboot'. There's no 'retry'. I don't mind diving to a second console, mucking about a bit on the mounted partition, and doing 'retry', but the installer doesn't even offer me that option. Instead, I have to choose 'reboot'. Never mind that the system is halfway through an installation process and might be totally and utterly broken, and not even bootable. Well, that's what rescue modes on installation media are for, I guess, but still.
After cleaning out some old files that aren't needed anymore and going back to the installer, you'd suppose that the system could figure out what it'd already done, and continue from there, right?
Well, no, it can't. It starts over from scratch, thereby forcing me to sit and wait for another three hours.
Times like these make me remember why I'm a Debian developer, and not a RedHat one. Why I chose not to finish that Linux From Scratch project that I'd started after using RedHat for three years and about six months before becoming a Debian Developer. Why I stopped hitting my computer screen around that time.
Stupid piece of shit.
disclaimer: this is all IMAO, and you don't have to agree with me. But what's a blog for, if not to rant?
On Linux viruses
Some guy from New Zealand blogged about a vulnerability in .desktop files as used by Gnome and KDE, and claims you can write a virus with them for Linux. He actually meant a Trojan rather than a virus, but still.
I'm not saying the vulnerability does not exist. It does, and the trojan he describes should work in theory.
However, in practice, I believe that the real reason why there aren't any Linux viruses is not the fact that Linux is somehow 'safer', but really the fact that Linux isn't a monoculture like Windows is.
If you want to write a Windows virus, you have to deal with, at most, four to five different versions of windows that are currently still in active use with most users. Target that, and your virus will live like there's no tomorrow.
If you want to write a Linux virus, the range of target system is much, much larger. In his very blog entry that describes the vulnerability, 'foobar' describes already two special cases he has to consider: the fact that KDE and Gnome write .desktop entries that get executed on startup to different locations, and the fact that, while most distributions ship either curl or wget, none of them has standardized on either of those, requiring the virus writer to account for that, too.
While his blog entry stops at that, there's way, way more he has to deal with. If our supposed trojan writer wants his trojan to proliferate, he will have to deal with distributions that come with or without SE Linux; distributions that ship with a /tmp mounted noexec; distributions that ship with python 2.3, 2.4, 2.5, or 3.0; users who use Thunderbird, Evolution, Kmail, mutt, pine, or another mail client; and possibly much, much more (this only describes what's required as described in the referenced blog post). All these differences would make writing some malware that would exploit the described vulnerability tedious, at best, and rather impractical in most cases.
Again, I'm not saying the vulnerability does not exist; it does. But I think this lack of monoculture under Linux, not the (perceived) strength of the platform, is what helps users defend against malware on Linux.
New toys
Got myself a new laptop this week. Not that the other one broke down or some such, but it was getting old; and its single-core 1.3Ghz PowerPC was starting to be somewhat slow in comparison to what's available on the market today. Additionally, while it was still functional, there were some issues with wear-out; for instance, sometimes the battery would just fall out while I was walking around with it, or the network cable connection would not fit entirely, and similar minor problems
The new one is quite a bargain; 2G of RAM, 2Ghz Core2Duo, one of those newfangled 'n' wireless network interfaces, plenty of diskspace, and other interesting things; and all that for only €600ish. You'd say it's a netbook, but it isn't—although I guess the low price of those netbook systems is pulling down the bottom line of these machines.
Anyway. After using it for slightly more than a day, I'm quite happy with it. I did have to upgrade a few packages in order to make all the hardware work properly; for instance, kernel 2.6.26 does not yet support the wireless (so I'm running 2.6.28 now), and the X.org in unstable can only get at the screen in vesa mode, which means I'm running the 7.4 X.org packages from experimental. But overall, most of it (that I care about) works flawlessly.
With a single exception: I have no audio. The weird thing is, the audio chipset is recognized, and I can play around with alsamixer; but no matter, there is no sound. Which is kindof annoying. It doesn't appear that I'm the only one with this problem (witness this debugging page on the alsa wiki), so I'm sure I'll get there. Eventually.
Oh wel.
While fetching the laptop, I was told that the NSLU2 which I had on backorder had arrived, so I took that with me, too. Add to that the 160G disk that I'd fetched earlier, and the USB NIC that I also got, and the Thecus N2100 that's still running at my parents' place will soon be moved to my home again—and its 500G RAID1 with it.
Whee.
Blue LEDs must die!
Preferably by way of a blunt chainsaw. One with a broken engine.
That is all.