Thu, 24 Jun 2010
On LDAP objectClasses
Petter suggests to make the dhcpHost LDAP objectClass an auxiliary one, to make it possible to combine it with the dNSDomain objectClass in one and the same object.
Unfortunately, you can't do that. Well—not if you want Debian-edu to remain compatible with everything else under the sun. You see, one of the features of LDAP is that each and every objectClass is well-defined, and that you cannot change it. As such, once a tool knows about an objectClass, it can make assumptions about objects in that class, for any such object, in any LDAP-server anywhere. Change an objectClass, and some tools will break.
The proper fix is, first, to verify that you are using the proper objectClasses. To me, an objectClass called dhcpHost and one called dNSDomain don't sound like they were meant to be used together; I would suspect that there is another DNS-related objectClass that is meant for hosts rather than domains. If that isn't the case, then one can create a new objectclass—say, auxiliaryDhcpHost or some such—that is the same as dhcpHost in all but name, OID, and the fact that you make it an auxiliary rather than a structural objectClass. Because luckily, what's true for an objectClass is also true for an attributeType: if it is assigned to an LDAP object, tools may assume that their meaning is what they think it is...
Tue, 18 May 2010
Can I have my Debian back?
So someone thought it might be a good idea to switch the default from the time-honoured Debian style ("booting foo... ok") to the RedHat style ("<left-align>booting foo... <right-align>[ok]"). I don't think the switch adds any value (it's not like it looked bad or anything in the past); in fact, I think it's a bad idea. And I even have a technical reason.
On my 26" 1920x1200 screen (when the i950 driver detects it properly and actually sets the framebuffer to that resolution), the output looks like this:
Now imagine you get to see that screen for about two to five seconds. Please tell me which two initscripts failed. And no, you cannot use a ruler. Bonus points for if you manage to do so while the text is also moving upwards, which tends to happen when systems boot.
Also note that because kernel mode-settings has become the default, a lot more people are going to be using framebuffers.
Am I the only one who thinks this is a bad idea?
Wed, 03 Mar 2010
dpkg vs RPM
Thomas blogs about some issues he had with his N900's facebook plugin. This post isn't about that, as I don't use facebook.
But as part of his blog post, he mentions the following:
This reminded me of a pet peeve I have with those people who claim Debian’s packaging system to be far superior to rpm – apparently dpkg doesn’t have any equivalent of rpm -qv which allows you to verify that the files that should be installed by a package are indeed on disk
True, probably because the script would be so trivial:
for i in $(cat /var/lib/dpkg/info/nbd-client.list) do [ -f "$i" -o -d "$i" ] || echo "$i missing" done
There, that wasn't hard, was it?
Now I'm not sure whether rpm's -qv option actually checks the checksum of the files, too. If it does that, then the semantically similar way would be:
(cd / && md5sum -c var/lib/dpkg/info/nbd-client.md5sums)
... except that MD5 is totally and utterly useless these days, and that we should be changing to something else. And that md5sums is an optional feature, provided by some, but not all, packages. And it may also be that maemo packages don't have md5sums (which would make sense). But, anyway.
Sun, 15 Nov 2009
NaN currency
The Daily WTF, an excellent website that I recommend everyone remotely involved in computers has a look at every now and then, has one series of posts where it shows 'strange' or 'funny' error messages from not just desktop computers, but also ATMs and other embedded devices.
One of the more recent entries of these Error'd series contained a picture that made me cringe; it showed 'NaN' for a currency value. Obviously this is an unhandled floating point error, but that's not what made me cringe.
What did make me cringe is that people who are supposed to work with shitloads of money are using floating point numbers to store monetary values. This is stupid. By their nature, floating point numbers are imprecise and inaccurate. The representation of a floating point number is an approximation. This is not the kind of thing one would like for bank transfers. "Mr Foo would like to transfer approximately €100 from his account to that of his neighbour." Err, no; it doesn't work that way.
Instead, whenever you use currency, you should use integer numbers. If your local currency is the US Dollar or the Euro or another similar currency where zero-point-something amounts of money are regularly used, work on the convention that "1" in your variable actually means ".01", or ".1", or whatever is most convenient, and make the right conversion whenever you need to do some output. Do not think you can deal with rounding errors in floating point, because you cannot.
COBOL (I can't believe I'm saying this) actually makes the latter easy, because you can create a statement that says "to output this variable, show the first three digits, then a point, then the last two digits". I believe it doesn't even have support for floating point numbers. Unfortunately this kind of thing is harder in C (and similar languages), but that doesn't mean you should just go ahead and assume that floating points are a good idea...
This is the kind of error I could accept from a first-year graduate student, but not from someone who's supposed to work with money on a daily basis.
Oh well. At least the ATM is about US Dollars, so it's not likely that it's going to be my problem any time soon.
Thu, 24 Sep 2009
RedHat is so medieval
So there's three systems. One of them runs CentOS 4, the other two run RedHat EL 4. One of the RedHats has been in use for quite a while, but the other two are freshly installed, and would need to have the same functionality as the first, but don't yet, mainly because they miss a number of packages.
So we do this.
[wouter@working-host ~]$ rpm -qa --qf "%{NAME}" | sort -u > working-host
[wouter@CentOS ~]$ rpm -qa --qf "%{NAME}" | sort -u > CentOS
Next, we compare the two:
diff -u working-host CentOS | grep '^-' | tail -n +2 | sed -e 's/^-//' > CentOS-missing
At this point, the file CentOS-missing contains some 403 lines. So how does one install packages on CentOS4?
[root@CentOS ~]# yum install $(cat CentOS-missing)
It starts thinking about it, then after several minutes comes back to me with "foo is already installed in an older version. I can't do what you're asking me"
[root@CentOS ~]# grep foo CentOS-missing [root@CentOS ~]#
In other words, it decided that, to satisfy one of the dependencies of one of the packages I'm asking it to install, it needs to have some other package installed, too, so adds it to the set. Then figures out that it's already installed, at an older version than what it was trying to install. Then bombs.
Okay Wouter, what were you thinking? Surely you can't expect a package manager to suddenly update packages when you ask it to install something else? That would mean upgrading and installing in the same command execution! Oh, the horror.
So, okay, we run yum update first.
Do you think that fixes it? Of course not!
It now comes back with... a message saying that a newer version of what we're trying to install is already installed.
Sigh.
So I'm now running 'for i in $(cat CentOS-missing); yum -y install $i; done' on this host. Since it takes yum several minutes to resolve dependencies, that means it's going to take a while to have it install 403 packages.
The not-yet-working RedHat 4 installation seems to have the exact same problem, except that up2date takes even longer to resolve dependencies, so we're not beyond the 'upgrade' step there yet. I'm sure it will come up with all kinds of other interesting failure modes. Luckily the RedHat-missing file is much smaller (83 packages).
How do RedHat users not eat their keyboard in frustration?
Note: yes, I'm aware of apt-rpm. Unfortunately, that is not supported on 64bit installations, because apt (in neither its dpkg nor its rpm variant) understands the notion of multiarch. At this time.
Thu, 17 Sep 2009
#include <iwlib.h>
Writing a network configuration tool is... fun.
Well, mostly anyway.
/***************************** SCANNING *****************************/ /* * This one behave quite differently from the others * * Note that we don't use the scanning capability of iwlib (functions * iw_process_scan() and iw_scan()). The main reason is that * iw_process_scan() return only a subset of the scan data to the caller, * for example custom elements and bitrates are ommited. Here, we * do the complete job... */ /*------------------------------------------------------------------*/
(from iwlist.c)
Not. The. Way. To. Do. It. Especially not if you're the person who writes both libiw and iwlist. Grmbl.
Also, documentation for libiw seems to be, well, nonexistent.
Fun. Not.
Thu, 30 Jul 2009
Passwords
The Debian System Administrators decided, apparently, that disabling password logons is a good thing that warrants a 'Good News' post.
Allow me to politely disagree, for two reasons:
First, an SSH key is a password that is stored on the hard disk, while a 'regular' password is only stored inside someone's brain. While torturing someone to get at their password is arguably possible, it is not possible to do so without this person noticing. The same cannot be said about someone secretly stealing a file from someone else's hard disk; and while it is certainly possible to protect an SSH key with a password, it is not at all required to do so in order to use such keys. As such, on the server end you have no way to know whether a remote client is in fact the person whom they claim to be, just because they happen to have a SSH key that just happens to match the original.
Second, security is not accomplished by forcing people to use things they do not want to use. If you do that, they will find ways to work around your security—leaving you with no security at all.
But oh well, it's not my call to make, so whatever.
Fri, 17 Jul 2009
Death
GNOME-KEYRING MUST DIE
that is all.
Mon, 22 Jun 2009
Dear Google,
Why oh why does Google Maps return Vismarkt, 2500 Lier, Belgium as a result for a search for Vismarkt, Mechelen, Belgium? The place I'm looking for is here, thank you very much.
Mon, 11 May 2009
"Please file a bug!"
I received a few comments on my previous post, some of which suggested that I file a bugreport explaining my thoughts. Of course I did consider that; and I do agree that in many cases, filing a bugreport is the right thing to do. However, this is not always the case.
There are times when you just know that a bug which expresses your feelings towards a particular thing will just be closed on sight, or at the very least tagged 'wontfix'. Filing a bugreport in such a case is just not helpful, and a waste of both my time and that of the maintainer. As such, I just don't do it.
Instead, what I will do is rant. Not because I want to annoy the world, but because it helps me to blow off steam—that's what my blog is for. Also, writing out my thoughts on a particular subject will often help me to reconsider things in such a way that I'll be able to better formulate what the real bug really is; and if it doesn't, it's likely that other people will respond and point me towards what I'm misunderstanding—if I am—so that, again, I might be able to better formulate what the bug really is.
If I sound frustrated in a rant, that's because I am. The simple fact that someone changed something in a piece of technology that I'm using with the intent of improving things should not have to mean that I agree that it is, indeed, an improvement. I will not hide my feelings because it might offend someone. I've done that too much in the past.
So please, pretty please, with sugar on top, when I'm ranting, do not tell me to file a bug report.
That is all.
Console-setup sucks
I have a few reasons for this:
- It wants to change the framebuffer font without asking. I seriously dislike the font it sets up.
- I have a habit of writing my own Xkb keymap. With xorg <= 7.3, that meant creating a file /usr/share/X11/xkb/symbols/wouter and having something like Option "XkbLayout" "wouter" in xorg.conf. Console-setup doesn't pick that up, though, and loads a default keymap that somehow looks closely similar to what I'm using.
- What's worse, the default keymap it picks up on my Apple Powerbook (which isn't my primary laptop anymore, but considering how my actual primary laptop is in for repairs, is what I need to use for now) is a PC Belgian AZERTY keymap, rather than the Apple AZERTY. This is *wrong*.
I might understand why they did this kind of thing, but the current implementation of autodetection is horribly broken.
Tue, 17 Feb 2009
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? ;-)
Sun, 18 Jan 2009
Filesystems: the saga continues
Bernhard comes up with a few arguments in support of multiple filesystems which, in my arrogant opinion, make no sense.
The first argument (about hardlinking a file to your homedirectory until something bad is discovered in one of the binaries) has been sufficiently debunked by Joey Hess.
The second and third arguments are the same, really. Repeating your argument won't buy you any beer, sorry.
Finally, all your arguments talk about server. I was talking about laptop. I don't know about you, but me, I'm not in the habit of loaning out my laptop to someone I don't trust. I'm not even in the habit of loaning out my laptop to someone I do trust, come to think of it. I do run some servers on my laptop, but I also have a firewall on my laptop that refuses incoming connections.
This is a laptop. Not a machine in a data center.
As such, the only person with access to my machine is me. Now I don't say I trust each and every bit of software that I run on my laptop, but I do trust myself. I won't start scanning my laptop's hard disk for rogue SetUID hardlinks in another user's home directory, because there isn't another user, stupid!
Paranoid security is nice and dandy and totally useless. Security is all about trade-offs. Even Bruce says so: if the cost of a security measure (having to deal with with 73 filesystems) does not outweigh its benefit (protection against cosmic rays changing not only my firewall configuration, but also writing a suid CGI binary and installing that in /usr/lib/cgi-bin), then it's just not worth it. Now of course you might argue that 'having to deal with 73 filesystems' is no cost at all, in which case it would be worth it. But to me, it certainly is a cost, and one I'm not willing to take—even if it did protect me against a real-life problem.
And if someone were to break into my system, I'll just reformat it and recover from back-ups. I won't even have to revoke my GPG key, this time, since it's no longer on the disk.
Mon, 29 Dec 2008
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.
Wed, 10 Dec 2008
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!)
Tue, 09 Dec 2008
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.
Mon, 24 Nov 2008
Rails? Stay the f* away from my system.
I knew for a long time that rails is somewhat fun to work with. The first time I read something about it, I went to check it out, and kindof liked the idea. Web development really isn't my cup of tea, so I didn't do anything with rails; but really, the idea made somewhat sense to me.
It's unfortunate that the implementation is such a piece of crap. Luckily I don't have to deal with it firsthand, but the stories I hear and read everywhere speak for themselves. I won't enumerate them all; but in case you're not familiar with them, the Debian Ruby team has a pretty clear explanation on their website. In addition to complaints by packagers, I also hear that many ruby developers recommend that you install gems inside the project you're running (or that you ship your software in such a way that it includes those libraries as part of your source). Oh, the horror.
Now, however, they've really topped it. Via Koen's blog, I found some other page that contains this:
Now, in theory, to update to the latest version of RubyGems, you just need to run
sudo gem update --system
But - depending on what version of RubyGems you have installed, running that command may lie and tell you that you have nothing to update. If you’re currently on RubyGems 1.1 or 1.2, you need to run a different set of commands to update RubyGems:
sudo gem install rubygems-update
sudo update_rubygems
Seriously. This is why we have distributions, packagers, and, really, people spending a whole shitload of time making sure everything works together nicely. This is why there is Debian, RedHat, CentOS, Mandrake, SuSE, and whatever.
Me touching rails? Not with a 10-foot pole. Not if you pay me a million, in any currency. Stay away from my system!
Sun, 05 Oct 2008
Belgian electronic ID card and security
I received some feedback on my previous BeID post, where I explained how to log in to a remote system by use of your digital ID card.
Philip and Guy both claim it possible or likely that the crypto keys on eID cards are stored on a system of the government somewhere and that you therefore should not be using them.
I find this to be jumping the gun a little. Security is always a trade-off; indeed, if you want to hide stuff from the government, then using eID-based authentication might not be a very good idea. However, there are other cases where eID-based authentication really is the correct option; and it is nice to know that this kind of thing is possible. Security always is a trade-off; and if you make an informed choice, there's nothing wrong about giving someone else access to your server.
The fun bit is that Philip actually advocates carrying a clear-text printout of a list of still-valid passwords. Now that, I feel, is unacceptable, security-wise. Personally, I'd rather use a smartcard that only some secret government agency might be keeping copies of rather than a list that any random thief might make use of. The question really boils down to this, I think: how likely do you think it is that someone else will be able to get at your password by guessing or stealing it?
- Using a password that's related to your person or someone near you, or is based on a dictionary: rather likely. There are scripts out there that will guess these passwords. Don't use them.
- Using a printout of a list of one-time passwords: somewhat less likely (they can't be guessed by script), but still not very hard (wallets get stolen by the hundreds every day, and it usually takes a while before one notices)
- Using smartcards with keys generated by someone else: somewhat unlikely (there may be a few people who know my private key, but one can't be sure of that; and, color me naive, but I tend to trust the government to abide by its own laws—for the most part—laws that prevent this kind of behavior)
- Using strong password: rather unlikely, provided you take care of them.
What I mean by that last bit is that you should always generate your passwords with a tool that generates fully-random passwords ('pwgen -s', for example), and never write them down in cleartext anywhere. That of course makes it slightly hardish to memorize them; what I do is to store the password encrypted to my GPG key on my laptop, and I memorize the password by changing it on a remote server that I need to access fairly often (Debian's systems will do), but leaving my GPG passphrase and laptop password as is for the time being. Every time I need to log in to the remote server, I first try to remember the passphrase. If I can't remember it, I look it up in the encrypted file (again taking care not to store the file on disk). Once I start being able to log in to the remote server without having to look it up in the file, I change all my other passwords. This process usually takes a few weeks. Then, the only way someone can get my password is either by coercing me or by killing me and disecting my brain. And then still.
Unfortunately, in the real world, I realize that many people do not wish to go through all this trouble just to get a secure login, and instead just choose a weak password. I guess that's why I think the next best thing might be slightly better than using strong passwords...
Mon, 29 Sep 2008
Autoconf: sigh
wouter@country:~/nbd-2.9.11$ ./configure --host=m68k-linux --build=powerpc-linux [...] checking for m68k-linux-gcc... no checking for gcc... gcc [...] wouter@country:~/nbd-2.9.11$ ./configure --host=m68k-linux-gnu --build=powerpc-linux [...] checking for m68k-linux-gnu-gcc... m68k-linux-gnu-gcc [...]
So why do we have config.sub again?
Tue, 16 Sep 2008
Worst. Error. Ever.
ldaphost:~# slapadd < ldapdump slapadd: bad configuration file! ldaphost:~# man slapadd ldaphost:~# slapadd -v < ldapdump slapadd: bad configuration file!
Helping users? You gotta be kidding me.
Thu, 14 Aug 2008
Ganneff, you suck.
- You don't want me to post pictures of you, yet you post a movie of me dancing. So there.
- You post a movie of me dancing in a format my PowerPC-based laptop can't read.
Please, pretty please, with sugar on top, convert it to Ogg Theora.
Thanks,
The Management.
Sat, 09 Aug 2008
Mail "migration"
I never thought I'd have to use my 'cluebat' section in my blog for myself, but apparently I do.
Since I moved out, a while back, mail to wouter@grep.be (and w@uter.be) was still being delivered on my Thecus N2100 that serves as server and internet gateway at my parents' place. This made sense when I set it up, because I don't usually read mail anywhere but home.
Since I now don't live with my parents anymore, however, I don't usually read mail anywhere near that server anymore. So, I'd been preparing to move the mail endpoint from goa (the Thecus) to samba (which has been my primary MX for quite a while, and which also has sufficient disk space to do so). Yesterday I made the switch, but forgot the important thing of checking up on whether the mail was actually arriving.
I'll spare the details, but suffice to say that I did make an error, and that over the last 12 hours, not a single mail that was sent by a server not known to me could send email to any of the grep.be or uter.be domains, amongst others. It wasn't blackholed (only 5xx'ed), but that's bad enough; I've now probably been kicked off every mailinglist in the universe. Go me!
Anyhow; if you sent me an email and you expect me to read it, you may want to send it back.
Off trying to resubscribe myself to some mailinglists now...
Tue, 05 Aug 2008
Locales
Sami, it's really not that bad.
There are, as you say, many variables to modify the behaviour of several programs. What you seem to have missed, though, is that there are really only four types of variables:
- LANGUAGE
- This is a GNU-specific extension which allows you to set fallbacks on different languages than "C" (which is locale-speak for "disable translation completely"). It somewhat overrides LC_ALL, but then at the same time it doesn't. Pretty strange thing, this variable. See "info gettext" and search for LANGUAGE if you want the ugly details.
- LC_ALL
- This variable exists to (temporarily) override any locale-related variable; for instance, when you want to file a bugreport in grep and you want to make sure you don't get any output that might be unintelligible for the developer, you could run LC_ALL=C grep --broken-parameter to temporarily disable locales. Using LC_ALL completely and utterly overrides anything else, so you probably don't want to set it in the general case.
- LC_NUMERIC, LC_PAPER, LC_MESSAGES,...
- These variable are meant to be used to divert from the defaults. For instance, as in your case, a user may want to have messages in en_US but have dates and papersizes etc be as is common in fi_FI. In that case, you'd set the default to fi_FI but set LC_MESSAGES (which specifies the language in which messages are set) to en_US. Or you might be a Dutch-speaking Belgian guy living in the US. You'd set the default to nl_BE.utf-8; but since A4 paper isn't easy to come by where you live, you'd set LC_PAPER to en_US.
- LANG
- This variable is used for "the default". If you haven't specified LC_ALL, nor the other relevant LC_* variable, then the value of LANG is used for whatever you're trying to do.
So what you really want to do is to set LANG to be fi_FI.utf-8, but have LC_MESSAGES be either en_US or, perhaps, C. This should give you english messages, but finnish conventions for date and number formats.
Do note, though, that this is only the theory. It may be the case that some software is broken and doesn't look at the correct LC_* variable. If that happens to be true for some software you've seen, just file a bug...
Sun, 03 Aug 2008
Rijksregister access through Belgian electronic ID card
On the mijndossier website, it is possible to view your own file in the belgian 'rijksregister' (state register), provided you have an electronic ID card and a computer set up to use it. I should note that the website uses a certificate that iceweasel on Debian, in its default configuration and after installing and configuring the necessary packages for using the electronic ID card, still warns about the certificate being 'not safe'. I should check what's going on there. But that is not what this post is about.
What it is about, however, is the fact that this website contains a "death" chapter.
Now, by definition, this "death" chapter can never be filled in, since one can only access their own data. And I can hardly do that if I'm death, can I?
Oh well, not that I care or anything.
Tue, 29 Jul 2008
On LVM volume group names
Lior blogs about LVM volume group names colliding, after he'd done an installation on two systems with 'vg00' as the volume group name, and trying to add the hard disk from one of them to the other machine. Which breaks in all kinds of interesting ways, of course.
Me, I avoid the problem altogether by just naming my volume groups sensibly.
wouter@samba:~$ sudo vgdisplay|grep 'VG Name' VG Name samba [...] wouter@goa:~$ sudo vgdisplay|grep 'VG Name' VG Name goa
... etcetera. If I ever have to put one of the disks from goa's (500G) RAID array into samba, then that'll be no problem, at all.
Tue, 08 Jul 2008
Christian,
One word: V.E.R.A.
(as in, 'dict -d vera')
Thu, 26 Jun 2008
Firefox sucks. No, really!
Warning: big rant ahead.
I received some comments on my previous post, as expected. Most of them were helpful; e.g., the oldbar extension is very useful. One of them was silly.
It depends: If your application is "fullscreened", clicking on the link without having the focus could lead to interesting situation like "Hey, It does nothing?"
Just to make a point here, let me reiterate:
There is no excuse whatsoever to steal the focus
Sorry for the shouting, but seriously. I have the following in my icewm configuration:
ClickToFocus = 0 RaiseOnFocus = 0 FocusOnMap = 0 FocusOnAppRaise = 0 FocusOnMapTransient = 0 FocusOnMapTransientActive = 1 RaiseOnClickClient = 0
What this means is that I don't want anything to either get the focus or get on top of anything else all by itself, unless it happens to be a new dialog box created by an application that already has the focus. I also don't want windows to appear on top of anything else just because they received the focus. I also happen to prefer focus-follows-mouse, which you can get by way of the ClickToFocus thing.
The reason I prefer it this way, is that often I have several applications open all at once. For instance, when I read RSS feeds, I have my RSS reader open on one virtual desktop, and read through the articles. Since my laptop's processor is much, much faster in certain things than is my network, I also make use of its multitasking abilities to have it preload links in the background (on another virtual desktop, preferably).
Unfortunately, somehow, firefox manages to bypass all that configuration and shows up in front, stealing the focus; and in the process, it completely interferes with the way I work. No doubt they do this in order to help some hypothetical "grandma" or other stupid clueless person who's never used a computer before, but let me tell you something: software should be written for people who actually do use software, not for stupid nitwits who can't even read an error message that tells them "you cannot do A, please go ahead and do B instead".
But I guess I'm too stupid or something to understand the usability "experts" who know it all best and say that software should be "intuitive" so that those who are 53 and see a computer for the first time in their live can sit right next to it and start emailing.
Hah.
As if the above wasn't enough, firefox 3 also is a crashing load of shit. I just spent the better part of an hour to try and make a payment using my bank's excellent online payment software which requires nothing more than javascript, SSL, and a digipass 810 that is provided by the bank as part of the online banking contract. Unfortunately firefox insisted on crashing halfway through entering the required information, for six times in a row. You'd think I'd be filing a bug now, but no, it managed to crash in a different location every time. I'd probably have to start debugging firefox to get this done, which is not something I'll do in this life.
You know what the problem is? Webbrowser developers think they're developing the most important application for any computer. They're not. It's just a webbrowser, no more important than an xterm or a mail client: a tool to get a job done. Period.
Grunt.
Wed, 25 Jun 2008
Iceweasel sucks.
I knew this since quite a while, actually—most of the firefox developers seem to developing for something else than what I use; but, well, using something else isn't very appealing to me. Anyway, yesterday the Iceweasel 3.0 update came on my laptop, and I couldn't help but sigh. I hadn't tried anything, hadn't read any reviews, didn't know what would happen; but given their track record, I expected only problems. I wasn't disappointed. Or, well, I was, depending on how you look at it.
- When I go to about:config, I want to configure my webbrowser. I have no need for hand-holding.
- When I click on a link in a different application, I want you to open, not to steal my focus. I will decide who gets the focus.
- The URL bar is slow and ugly. Having the title of a webpage show up there serves no useful purpose to me -- if I need the title, I'll go to the "history" part of that browser, that's what it for. Also, the underline-as-you-type nonsense slows things down considerably.
And that's only after a day. I fear the next few weeks. For the time being, hints on getting the above moronic stupidities gone (apart from the about:config one, which takes a single click) would be helpful.
And then of course I'm not even mentioning the fact that most of my add-ons don't work with 3.0 yet—but that is to be expected with a new brouwser, of course. At least flashblock works, which is the most important one.
Mon, 09 Jun 2008
Grmbl
wouter@country:~$ for i in $(seq 1 64) > do > killall -$i firefox-bin > done
I know it makes no sense, but goddammit.
Wed, 23 Apr 2008
Hah
priceless. Even if I had to check twice to get the joke.
Thu, 17 Apr 2008
Actually, you can
Uwe Hermann and Russell Coker talked about resizing ext3 volumes in several scenarios. While they point out interesting things (i.e., the fact that you can resize stuff without losing data), they both get the important bits wrong.
Uwe, you can do online resizing. Just use
resize2fs <device-node>. The kernel will notice that the device is mounted, and perform an online resize. This takes slightly longer than an offline resize, but (a) you don't need to do the fsck, and (b) you can still write and otherwise use the file system while the resize is in progress, so the net result is that you win time, especially if the file system in question is huge (I've done things like resize a 700+G LVM volume by 50-100G, which takes half a minute or so; an fsck will take seriously longer).
Russell, resizing the LVM volume on which the root filesystem lives used to deadlock the kernel in the old days, but that bug has been fixed since around Linux 2.6.13. I've done online resizes of the LVM volume (and ext3 filesystem) of my root filesystem many times since then, both on some of my home systems and on huge customer boxes, and never encountered any problems.
I really love LVM, especially on servers. /home is full? lvresize -L +5G /dev/<hostname>/home && resize2fs /dev/<hostname>/home, and we can work again.
Sat, 05 Apr 2008
IRC nicknames
Yes, I too would like to explain that my name is 'Wouter', and not 'Yoe'. I've always considered nicknames a necessary evil—'wouter' usually being taken on most IRC networks I connect to, and 'retuow', as some have suggested, being far too silly—and one which I prefer not to be reminded of if at all possible. No, please don't ask why.
That being said, I must ask: Martin, if you're only mad on IRC, why does your hackergochi refer to your nickname, and why are your blog and hostname named after it, too? I find it helps people limit their use of my nickname to IRC if I do so, too.
Mon, 24 Mar 2008
Perl
Martin blogs about how the Camel book mentions the fact that scalars, arrays, and hashes have completely separate namespaces, as if this is a problem. Well, I disagree.
As with anything in Perl: yes, obviously it's possible to confuse yourself with this feature, and yes, obviously it's true that if you do this, you will get to keep both pieces of your program. So don't do that then.
However, when used properly, I find that it actually helps me improve readability of my programs.
Let's say we have a subroutine which returns a reference to a filehandle to a bunch of data in a format that we know how to parse. We don't know what the filehandle points to (and we don't care, either), but we do know what the data is. So we store the filehandle in some scalar, and then proceed to parse the data into a hash.
Now we could use variable names such as $fh and %hash, but I'll hope that everyone agrees with me that this is very bad practice. So, instead, we should name the variables after what they contain. Say our data file contains books:
$books = get_books_fh();
while(<$books>) {
(... parse $author out of $_ ...)
push @{$books{$author}}, $_;
}
The filehandle to which $books is a reference, points to some useful data; and the %books hash table contains the exact same data, only structured in a different, more useful way. So why give them a different name? They're the same thing, call them the same way. Personally, I find this makes a whole lot of sense. And you can do the same thing with arrays vs hashes, or scalars vs arrays.
Of course you can also write code that uses $somevar and @somevar, with no semantic connection between the two. That is stupid, so don't do it. The fact that you can do stupid things with Perl, however, should not mean the language sucks.
You see, other than some other programming language I could think about, Perl does not assume its users are stupid, or inexperienced, or dummies, or whatever. Yes, that does mean that new users will get confused; but it also allows experienced users to Get Stuff Done in a proper way. And, well, I'm sure you can do stupid things with python, too.
Tue, 18 Mar 2008
Public service announcement.
The "Data Display Debugger" sometimes is a great tool in, well, debugging stuff. Those who have never met it before, please take a look—it has some nice qualities not found in any other debuggers (or gdb wrappers).
However, here is a public service announcement to the ddd developers:
STOP MESSING WITH MY LAYOUT, DAMMIT!
Here ends this public service announcement.
I mean, seriously. Why the fuck do these widgets need to dance around on my screen?
Thu, 13 Dec 2007
Counterpoint
Microsoft has an article on their website in which they compare Windows to "Linux". As can be expected, the comparison is rather one-sided, and in some cases flat-out wrong. Usually I ignore this type of things, but this time I decided to just point out why it's so wrong, and put it online. Comments are welcome.
Tue, 11 Dec 2007
Hardware sucks, but their manufacturers too.
A while back, I needed to do something with a mainboard made by Intel. The mainboard doesn't have a PS/2 connector; so I had to use a USB keyboard. In itself, this is horrible; USB is an incredibly bad interface to connect a keyboard to, IMO. But, well, sometimes the decision isn't yours, you know. Bad Intel.
Given my above-stated opinion on USB, I guess it's not surprising that I don't have a USB keyboard; I don't believe in them. But, well, a mainboard without a PS/2 connector doesn't suddenly get one because I look at it, so I went to a nearby computer shop with the intention to buy me a keyboard.
While it's bad enough that I had to get me a USB keyboard, they managed to make things worse. The particular model that I'd bought is broken in ... well, let me count the ways.
- Blue LEDs are annoying. Yes, a keyboard needs LEDs to show that num lock (etc) are enabled, but a yellow LED works too, and is far less flashy or distracting.
- A "Fn" key is nice if you want to overload keys on your keyboard. However, if there is not a single key on your keyboard that is overloaded using the Fn key, then you're silly.
- The particular model used a "condensed" layout, rather than the standard 105-key be azerty layout. I'm used to the standard 105-key keyboard layout, and having to type on one that is different is no fun. When I mentioned this to the salesguy, he told me that I'd "get used to this pretty quickly". Well, perhaps if that were my only keyboard. But I also have my home desktop (standard 105-key layout), my laptop (apple azerty laptop layout), some m68k macs (mac azerty 105-key layout), and some more; then, it doesn't get so easy.
- They keys on the keyboard were flat as on a laptop keyboard, rather than thick as on a desktop. This makes it harder to disassemble when it gets dirty, with the risk of breaking it (I've had to have my laptop's keyboard replaced when I broke it by disassembling it because the keys started to get stuck and I wanted to clean it...)
Now obviously it's possible to fix most of these issues by simply buying a decent keyboard—except that the shops that I went to simply don't have a decent keyboard anymore these days. At least this one still had 105 keys; for reasons that totally escape me, some keyboard manufacturers today seem to think it's a good idea to drop the insert key on their keyboards. WTF?
People just don't make decent quality keyboards anymore these days...
Bad hardware manufacturers. Bad, bad, bad!
Thu, 15 Nov 2007
Androids etc.
There's a huge amount of buzz around some "Android" API that some huge search company apparently released recently.
Not that I care about mobile phones. Not as if you can do a lot of useful stuff on those, anyway. And, heck, "android"?
Am I the only one who associates that with stuff like the above?
Tue, 30 Oct 2007
Abbreviations
C1n we p4e s2p u3g s3y a11s s2h as 'i18n', 'l10n', a1d m18n? T4s.
Mon, 29 Oct 2007
Key mappings
Sometimes, I think people go out of their way to create key mappings that are silly, stupid, and whatever.
- Why is irssi's "Ctrl-K" a key combination to delete a whole line, when "Ctrl-J", with J being right next to K, is a key combination to confirm the same line?
- Why is mutt's "x" a command to leave a folder without saving changes, while "c" is a command to leave a folder with saving changes?
- Why did the mac designers position the "eject" key right above backspace—the second most often used key on a keyboard?
Please, pretty please, with sugar on top: make sure accidentally mishitting a key in any application doesn't perform the opposite of what one would assume it would do. Thanks.
Wed, 17 Oct 2007
Crap
wouter@country:~$ mount /media/cdrom0; echo $?; mount /media/cdrom0/; echo $?; eject; mount /media/cdrom0/; echo $? 0 mount: /dev/hdc already mounted or /media/cdrom0 busy mount: according to mtab, /dev/hdc is already mounted on /media/cdrom0 32 mount: No medium found 32
I guess I'll have to parse mount's output, then.
