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 2009/11/20: 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).
5 replies for this story:
Karel Zak wrote: single-user desktop distro
Is there any opposition against single-user manners in Fedora community? Unfortunately, answers is NO. People who are working on non-desktop stuff are usually busy working on upstream, or on RHEL or they don't use Fedora at all... We have https://fedoraproject.org/wiki/SIGs/Server but the project is almost dead :-(
Milan Zamazal wrote:
BTW: As for the African-Debian distro, I wouldn't recommend it to anyone who cares about stability (actually I wouldn't recommend it to anyone at all, but this is another topic). Use Debian instead.
ApoC wrote:
Also FreeBSD can be good choice :)
Yenya wrote: Re: FreeBSD
Well, I am not sure whether I would use a system maintained in three different _centralized_ version control systems ... [That said, I have a FreeBSD installed in a KVM-based virtual machine for testing purposes; they don't have virtio though, so the system is pretty sluggish; I have yet to get time to upgrade it to FreeBSD 8]
ApoC wrote:
There is also distributed git mirror of FreeBSD on http://www.gitorious.org/freebsd About virtio i didn't find any driver :/
Reply to this story:
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.
5 replies for this story:
Milan Zamazal wrote:
SQL databases are not inherently bad. It's just that no complex software is without problems. I can't comment on Oracle but e.g. PostgreSQL, despite its own problems (the most notable one being that SELECT COUNT(*) requires sequential scan), can be a reliable and very useful tool for some purposes. When using any complex software one sometimes falls into a rage but frankly how about bugs and design flaws in our own software? Nothing is perfect and still not everything is a pile of rubbish.
Yenya wrote:
I have probably been misunderstood: the article was not about every software being crap, but about SQL databases specifically containing _lots_ of implementation-dependent behaviour (especially in locking), which is impossible to predict when designing an application, especially a high-performance one (oh look, this idiot has said "SQL" and "high-performance" in one sentence ;-).
Milan Zamazal wrote:
Do you mean Oracle locking behavior is not documented in its manuals? If so (really?), you shouldn't generalize your experience to all SQL engines without reason.
Yenya wrote: Re: Oracle
The point is that it is not a general property of SQL locking, but a (default-only?) property of the Oracle implementation. Which is impossible to anticipate until you actually try to use it and run into the problem. (As for PG, the missing packages and missing subtransactions/checkpoints, as well as the count(*) problem you describe are sufficient examples).
Milan Zamazal wrote:
You can't expect to find an SQL engine without implementation limitations, for clear reasons. I don't know what you mean by missing packages etc. in PostgreSQL, but AFAIK PostgreSQL manual is pretty complete, including documentation of locking behavior, subtransactions, checkpoints, extension packages and the COUNT(*) problem. So you can anticipate it all, just read the manual, especially if you intend to base a performance critical application on the engine. If you don't read the manual then complaining about unanticipated behavior and labeling SQL engines as piles of rubbish for this reason is demonstration of a completely different problem...
Reply to this story:
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.
4 replies for this story:
Vasek Stodulka wrote:
Yes, the "brand new" gdm is a piece of crap. But it looks so ughly, that it is not a big deal to switch to good old xdm. Personally I like theese old apps, for example after all the years I am still ising xterm.
Yenya wrote: xdm
Well, xdm has problems on its own - for example, it only recently get a decent integration with ConsoleKit and SElinux. As for the terminal, I like gnome-terminal better. It uses a single process for all windows, can use new client-side fonts (not that I use any), and the most important feature is that I can open a new window just by right-clicking to any other terminal window, which speeds up my work).
Matěj Cepl wrote: Hint: it's Fedora
Hi, just my completely personal reply (I haven't consulted it with my colleagues working on gdm). Isn't this Fedora we are talking about? What in the world stops you from packaging gdm 2.20 and supply it to the Fedora repos? During those two years there was enough rambling on this bug (and in many other places), that I guess making a package (or reviving the old one), should be less work. And yes, we should do better than that. Matěj
Yenya wrote: Re: Matěj Cepl
Well, I don't want to be a gdm maintainer - lack of time beign definitely a reason, but also the lack of will to integrate the whatever *Kit of the day the desktop architects come up with.
Reply to this story:
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?
1 replies for this story:
Milan Zamazal wrote:
I've never managed to get water-resistant shoes, but I've never tried hard. One possible way to prevent falling into a costly, time consuming and distressing obsession about this is to accept the simple principle "if it becomes wet, it will also dry sometimes". This may not be that easy in winter (but winter shoes are usually acceptably resistant) or on longer trips (what? can a family man even dream about that?), but otherwise it's a solution of excellent simplicity that can help to balance the caveman in you against your overused high-tech thinking. :-)