Fri, 20 Nov 2009
Fedora 12
I have been using Fedora 12 on my laptop for a week now, and on my primary workstation for three days. So far I have walked through Bugzilla and checked that most of my bugs are still present in F12. But apart from that, there has not been any unpleasant surprise so far. The new KMS code and X server for Radeon cards work as expected, so I am looking forward to install F12 also to my dual-seat workstation at home. So far it is OK. Well, except ...
... except this
bug (covered also in
fedora-devel
and also at Slashdot).
I wonder who could seriously have thought this feature would be an improvement?
Probably if the Anaconda can ask whether this is a single-user workstation,
and only then enable it, it would be bearable. But having it on by
default is simply insane. The fact that to disable it, the 6+ lines file
in an undocumented format in four-levels deep directory under
/var/lib should be created, just underlines the gross insanity
of the whole thing.
I have been a long-term supporter of using Fedora also for other purposes than a single-user workstation, but apparently it seems that some Fedora maintainers either do not care (see my post about GDM), or - what is worse - some are actively trying to undermine the other usages of Fedora.
We have been considering returning Fedora to some of our computer labs (to solve some problems with that African-Debian distro), but with this problem I am not sure whether this is a good thing to do anymore.
Update - Fri, 20 Nov 2009: Resolved after all
From fedora-devel:
[...] Executive summary
We'll make an update to the F12 PackageKit, so that the root password is required to install packages.
Glad to see this being resolved relatively fast. This was the most voted-for bug in the Fedora bugzilla (by a factor of almost 10).
Thu, 19 Nov 2009
Database Woes
Using the SQL database for keeping one's data gives an excellent environment, maintaining the data integrity, providing the transactional behaviour, providing the remote access to the data, and so on. Even the locking properties can be something which one can get used to. That is, in the ideal world.
However, our world is not ideal. The huge problem of SQL databases is their implementation. For example, after rewriting the IS MU mailserver back-end to do a parallel delivery, it started to generate big load spikes on the Oracle DB server. The problem turned out to be the cache of SQL queries: when several processes tried to do exactly the same query in parallel, the DB server locked up on the access to the SQL cache, and a simple "select row by its primary key" query took as long as three minutes to handle.
Another example is the Oracle problem with foreign key locking which I have
recently ran into: I have a long transactions running in parallel,
modifying various rows of a single table (but each session touches
a different set of rows, so the access should be deadlock-free).
After creating another table with foreign key to the original one,
I started to get "deadlock detected" errors in DELETE commands.
Apparently Oracle locks not only the appropriate
row in the foreign-key table, but the whole block in this table.
So I have been getting the deadlocks when trying to delete the row
with primary key N, where another session added a row to the table
with foreign key referencing the primary key N+1 or N-1.
Replacing DELETE with UPDATE ... SET status='deleted'
and deleting afterwards from the single session fixed the problem for me.
The SQL databases are pile of rubbish, which can always surprise you not only with their by-definition properties, but often also with their implementation-dependent behaviour. Oracle is an excellent example of this.
Wed, 18 Nov 2009
The GDM Fiasco
A short trip to the history: for GNOME 2.22 (two years ago, in the Fedora 9 timeframe) someone decided that it would be nice to completely rewrite the GNOME display manager. So far so good, but they have decided to include this partially rewritten piece of crap without many important features (a display manager without XDMCP, WTF?) to the official GNOME and thus Fedora releases.
Fast forward to the present time: basically, for two years, GDM has not been usable for anything beyond a single-user desktop (I use xdm on my home dual-seat desktop, and we have replaced Fedora altogether in some of our computer labs partly because of GDM).
- It did not handle XDMCP (at least this one got fixed).
- There is still no way of setting the X server command line, making GDM unusable in multiseat configurations.
- It cannot be configured as XDMCP-only daemon without starting the local X server.
- The login window cannot be configured, and the way it works it is usable on a personal desktop, but definitely not in a computer lab with ~2200 accounts and users logging in on random hosts.
Apparently, somebody has started to work on solving at least some of the problems after all. But guess what? Instead of backing off quickly (say, before the Fedora 10 has been released), Fedora maintainers has ignored the problem despite many polite and even some profane requests to provide an upgrade to the latest working version (i.e. the Fedora 8 one). And now the answer is "wait for Fedora 13 (another half a year), we are probably going to fix it there". Without any hint of being sorry for forcing an utterly broken package to the users for two years and counting.
Tue, 17 Nov 2009
Footwear Waterproofing
This year's Tmou with its almost start-to-finish rain has made me to think again about my approach to waterproofing my boots. I have about eight years old Hanwag Alaska Nubuk leather boots with Gore-Tex membrane (which is definitely not functional anymore after these years). So the leather is now the only barrier between the outer wet conditions and the inside of the boot.
In the last few years, I have used wax-based water proofing (e.g. Granger's G-WAX). It worked, and the boots remained water resistant for several times of usage. However, I often had my feet wet from the inside, as I tend to sweat a lot.
Recently I have bought Granger's G-MAX Leather conditioner, which is not as "thick" as a wax, but apparently the boot is still water-resistant. I have however had no chance to test it in rainy weather until this year's Tmou. Expecting heavy rain during the competition, I have applied several layers of the leather conditioner on my Alaskas.
I was rather surprised that this time not only the boots remained water resistant, but I also had not my feet wet from the inside. Probably the wax, unlike the leather conditioner, keeps the boot air-tight, causing the feet getting wet because of sweating. So far so good, but there was another rather unpleasant surprise after Tmou: when my boots dried, the most exposed parts of the leather (namely foreparts) were completely dry as if it were just to crack.
Is it expected? Do I need to waterproof my boots again only after a day in a rainy weather? How do you waterproof your outdoor boots, my dear lazyweb?