A common trait of virtually all of the media in Mexico -and, as far as I have been able to see, in Latin America- is the push for society to be afraid. The government and the media (which go hand-in-hand, mainly due to a series of favors owed to each other - currently stemming from the government's illegitimacy and lack of trust from the general population) wants us all to think the country is as violent and as dangerous as it has never been before.
And yes, I cannot and won't try to deny that there are many critical points that need attention - But the answer cannot be militarization, cannot be further restraining the civil liberties, cannot be criminalization.
The only way to prevent crime is to reduce poverty. And poverty is not reduced by giving foreign "investors" (bah, ask people living on cities that border the USA if the maquilas have brought any kind of investment or somehow bettered the living conditions of the population!) access to segments of the economy so far limited to the government - Poverty will only be reduced when the government starts reviewing the tax systems to remove the legal loopholes that make it possible for a large enterprise to get tax exemptions on most of their income, and make the lower income people pay zero taxes, even get social aid.
But back to the topic: Since the 1994 crisis (the "decembrine errors"), we are being constantly bombed about the raging insecurity in Mexico. Maybe we have been bombed with that same ideas for more time, but I was not very politically conscious before that. When things go a bit smoother on the political side, the media relaxes the "we are so fucked" mantram.
When our de facto president current ruler took power, on December 2006, he had so much opposition he could not for months attend a single public event. So far, he is still avoiding them; everywhere he goes, the place must be cleared and sanitized of anybody who might show he just does not agree with the imposition we had. What was his first government action? To decree that every branch of the government would get a 10% budget cut on the salaries - but the security forces (the army, the different police corporations) would have a 46% raise.
After almost two years of ineptitude, they keep chanting the old "oh, we are living such dangerous times" mantra. The security forces recently got yet another raise, and everybody in the media says this country cannot be lived in anymore.
And people buy that crap.
Up to a month or two ago, the general outcry is that the drug lords had taken over the country - And, yes, in several areas of Mexico, their presence is bigger than the official security, or the security agencies are completely coopted by them. But not even His Majesty Felipe Calder n I "El Ileg timo" can say with a straight face that "we are winning the war against the drug lords" (a war brought by himself, of course - Think of it as Mexico's Irak. Think of Calder n as Mexico's Bush.) - A new attention sink was needed.
Of course, this country is not safer than Finland. But crimes do happen there as they happen here. Here, we have got a tremendous movement because of one brutal kidnapping in August, and everybody now thinks that everybody is at risk of dying kidnapped.
So today, after over a month of bombarding us with fear about kidnaps, I am sick of reading stupid reactions. What made me post this was a request for ideas at a local Free Software-related portal about monitoring known potential criminals. Of course, such a proposal would violate the right to anonimity and to lead a personal life even a convicted criminal has. And, of course, the cries of people that think the society should castrate rapists and kill kidnappers, basically going back 4000 years in history. People, let me hand you a stone and a stick so you can club the whole society to death.
The first step towards getting out of this security nightmare perception we have is to be critical towards what the media tells us - and to understand (and _really_ understand. I won't buy your argument that "it's easier to rob somebody for MX$4000 than to work a full day for MX$100", as it's only easier on one level, but it is a tremendous cost on many others) what makes good people act against the society.

Xen 3.3 added a tool called PV-GRUB. It is a GRUB (legacy aka 0.97) built against MiniOS and bootable as a PV kernel. It works fine on a Xen 3.2.1. It is easy to use, I just set this in my config:

kernel = "/usr/local/lib/xen/boot/pv-grub-x86_64.gz"
extra = "(hd0)/boot/grub/menu.lst"

However it decided to not load my config as defined in the config and simply show me that:

    GNU GRUB  version 0.97  (524288K lower / 0K upper memory)
       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
grubdom>

The reason is quite easy:

grubdom> root (hd0)
 Filesystem type unknown, using whole disk

Some debugging later, the reason is known and fixed.

grubdom> root (hd0)
 Filesystem type is ext2fs, using whole disk
grubdom> kernel /boot/vmlinuz-2.6.27-rc5-amd64
grubdom> initrd /boot/initrd.img-2.6.27-rc5-amd64
grubdom> boot
block error -1 for op 2
close blk: backend at /local/domain/0/backend/vbd/23/51712
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.27-rc5-amd64 [...]
[    0.000000] Command line:
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] ACPI in unprivileged domain disabled
[...]
[    0.022093] Booting paravirtualized kernel on Xen
[    0.022101] Xen version: 3.2-1

Xen 3.3 added a tool called PV-GRUB. It is a GRUB (legacy aka 0.97) built against MiniOS and bootable as a PV kernel. It works fine on a Xen 3.2.1. It is easy to use, I just set this in my config:

kernel = "/usr/local/lib/xen/boot/pv-grub-x86_64.gz"
extra = "(hd0)/boot/grub/menu.lst"

However it decided to not load my config as defined in the config and simply show me that:

    GNU GRUB  version 0.97  (524288K lower / 0K upper memory)
       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
grubdom>

The reason is quite easy:

grubdom> root (hd0)
 Filesystem type unknown, using whole disk

Some debugging later, the reason is known and fixed.

grubdom> root (hd0)
 Filesystem type is ext2fs, using whole disk
grubdom> kernel /boot/vmlinuz-2.6.27-rc5-amd64
grubdom> initrd /boot/initrd.img-2.6.27-rc5-amd64
grubdom> boot
block error -1 for op 2
close blk: backend at /local/domain/0/backend/vbd/23/51712
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.27-rc5-amd64 [...]
[    0.000000] Command line:
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] ACPI in unprivileged domain disabled
[...]
[    0.022093] Booting paravirtualized kernel on Xen
[    0.022101] Xen version: 3.2-1

Some people think that you can recognise a good restaurant by the presence of obscure dishes on the menu or having high prices. The reality is that there are two ways of quickly identifying a good restaurant, one is the Michelin Guide [1] (or a comparable guide - if such a thing exists), the other is how quiet the restaurant is. By a quiet restaurant I certainly don’t mean a restaurant with no customers (which may become very noisy once customers arrive). I mean a restaurant which when full will still be reasonably quiet. Making a restaurant quiet is not in itself a sufficient criteria to be a good restaurant - but it’s something that is usually done after the other criteria (such as hiring good staff and preparing a good menu) are met. The first thing to do to make a room quiet is to have good carpet. Floor boards are easy to clean and the ratio of investment to lifetime is very good (particularly for hard wood), but they reflect sound and the movement of chairs and feet makes noise. A thick carpet with a good underlay is necessary to absorb sound. Booths are also good for containing sound if the walls extend above head height. Decorations on the walls such as curtains and thick wallpaper also absorb sound. A quiet environment allows people to talk at a normal volume which improves the dining experience. It seems to me that the same benefits apply to server rooms and offices, with the benefit being more efficient work. I found it exciting when I first had my desk in a server room (surrounded by tens of millions of pounds worth of computer gear). But as I got older I found it less interesting to work in that type of environment just as I found it less interesting to have dinner in a noisy bar - and for the same reasons. For a server room there is no escaping the fact that it will be noisy. But if the noise can be minimised then it will allow better communication between the people who are there and less distraction which should result in higher quality of work - which matters if you want good uptime! One thing I have observed is that physically larger servers tend to make less noise per volume and per compute power. For example a 2RU server with four CPUs seems to always make less noise than two 1RU servers that each have two CPUs. I believe that this is because a fan with a larger diameter can operate at a lower rotational speed which results in less bearing noise and the larger fans also give less turbulence. While it’s obvious that using fewer servers via virtualisation has the potential to avoid noise (both directly through fans and disks and indirectly through the cooling system for the server room [2]). A less obvious way of reducing noise is to swap two 1RU servers for one 2RU server - although my experience is that for machines in a similar price band, a 2RU server often has comparable compute power (in terms of RAM and disk capacity) to three or four 1RU servers. To reduce noise both directly and indirectly it is a requirement to increase disk IO capacity (in terms of the number of random IOs per second) without increasing the number of spindles (disks). I just read an interesting Sun blog covering some concepts related to using Solid State Disks (SSDs) on ZFS for best performance [3]. It seems that using such techniques is one way of significantly increasing the IO capacity per server (and thus allowing more virtual servers on one physical machine) - it’s a pity that we currently don’t have access to ZFS or a similar filesystem for Linux servers (ZFS has license issues and the GPL alternatives are all in a beta state AFAIK). Another possibility that seems to have some potential is the use of NetApp Filers [4] for the main storage of virtual machines. A NetApp Filer gives a better ratio of IO requests per second to the number of spindles used than most storage array products due to the way they use NVRAM caching and their advanced filesystem features (which also incidentally gives some good options for backups and for detecting and correcting errors). So a set of 2RU servers that have the maximum amount of RAM installed and which use a NetApp Filer (or two if you want redundancy) for the storage with the greatest performance requirements should give the greatest density of virtual machines. Blade servers also have potential to reduce noise in the server room. The most significant way that they do this is by reducing the number of power supplies, instead of having one PSU per server (or two if you want redundancy) you might have three or five PSUs for a blade enclosure that has 8 or more blades. HP blade enclosures support shutting down some PSUs when the blades are idling and don’t need much power (I don’t know whether blade enclosures from other vendors do this - I expect that some do). A bigger problem however is the noise in offices where people work. It seems that the major responsible for this is the cheap cubicles that are used in most offices (and almost all computer companies). More expensive cubicles that are at almost head-height (for someone who is standing) and which have a cloth surface absorb sound better significantly improve the office environment, and separate offices are better still. One thing I would like to see is more use of shared desktop computers, it’s not difficult to set up a desktop machine with multiple video cards, so with appropriate software support (which is really difficult) you could have one desktop machine for two, or even four users which would save electricity and reduce noise. Better quality carpet on the floors would also be a good thing. While office carpet wears out fast adding some underlay would not increase the long-term cost (it can remain as the top layer gets replaced). Better windows in offices are necessary to provide a quiet working environment. The use of double-glazed windows with reflective plastic film significantly decreases the amount of heating and cooling that is required in the office. This would permit a lower speed of air flow for heating and cooling which means less noise. Also an office in a central city area will have a noise problem outside the building, again double (or even triple) glazed windows help a lot. Some people seem to believe that an operations room should have no obstacles (one ops room where I once worked had all desks facing a set of large screens that displayed network statistics and the desks were like school desks with no dividers), I think that even for an ops room there should be some effort made to reduce the ambient noise. If the room is generally reasonably quiet then it should be easy to shout the news of an outage so that everyone can hear it. Let’s assume for the sake of discussion that a quieter working environment can increase productivity by 5% (I think this is a conservative assumption). For an office full of skilled people who are doing computer work the average salary may be about $70,000, and it’s widely regarded that to factor in the management costs etc you should double the salary - so the average cost of an employee would be about $140,000. If there are 50 people in the office then the work of those employees has a cost of $7,000,000 per annum. A 5% increase in that would be worth $350,000 per annum - you could buy a lot of windows for that!

• [1] http://www.michelinguide.com/


• [2] http://etbe.coker.com.au/2008/09/10/efficiency-of-cooling-servers/


• [3] http://blogs.sun.com/studler/entry/why_you_should_avoid_placing


• [4] http://en.wikipedia.org/wiki/Netapp

Share This

Ultimate Debian Database (UDD) is a GSoC project (now finished) which aimed at importing all different data sources that we have in Debian in a single SQL database, to make it easy to combine that data. Currently, we import information about source and binary packages, all bugs (both archived and unarchived), lintian, carnivore, popcon, history of uploads, history of migrations to testing, and orphaned packages. The goal is really to have that data, without really thinking of a specific use cases: there will be lots of use cases. Buildstat is a project by Gon ri Le Bouder, that provides a framework for running QA tests (rebuilds and lintian currently, but buildstat is built in a very extensible way) on packages, using both packages in the archive, and packages in the VCS repositories of teams. This is pretty cool: it allows teams to get an overview of the status of their packages, not using the archive as reference, but using their VCS. Buildstat schedules and runs the tests, store the data in an SQL database, and allows to browse the data using a web interface. Buildstat also import some data from other sources (only the BTS currently, using the LDAP dump) to display it on the web interface. Since both projects are using an SQL DB, people have been asking why we don’t simply merge them. The big advantage would be that the data is synchronized: buildstat would display more up-to-date info about the data sources it doesn’t generate locally (like bugs), and UDD would get fresh buildstat data. We have been talking a lot with Gon ri, considering the different possibilities. But I don’t think it’s a good idea. I think that both projects should try to do one thing, but do it very well, instead of trying to fix the world. UDD focuses on importing data that exists elsewhere. Sometimes it means doing some complex processing. But data should be be generated by UDD. Merging the projects would mean having a very big piece of software that does everything (or tries to do everything). Both databases were designed differently, with different goals. UDD tries to stay close to the data it imports. There might be some incoherences in the data sources, but that’s fine: one of the goal of UDD is to make it easy to find them (and fix them), so we need them in the DB. In buildstat, since the goal of importing data is to display it on the web interface, with a strict use case, you can freely “simplify” data if it helps. Another big difference is that UDD is designed to be easy to use (ie write and run queries) by a human user: UDD uses multi-column primary keys, while buildstat uses surrogate keys (integer “id” keys), that ORM tools usually require. There are also more technical concerns: currently UDD makes a compromise, for each data source, on what it imports: it tries to import the data that is useful, not all the data available. Merging buildstat and UDD would mean increasing the DB size significantly, by adding all the “private” data that buildstat needs. Another problem is the stable API problem: if buildstat and UDD are merged, it means that buildstat cannot change its DB schema without making sure that it wouldn’t break what UDD users are doing. So, what should we do, from my POV, instead of merging? - Continue to talk, and get Gon ri into the UDD “team”. He gathered a lot of experience working on buildstat, and he probably would be able to help a lot. - Data that is not generated by buildstat (bugs data) should be imported from UDD. Doing SQL->SQL will probably make things easier there. - A summary of buildstat’s infos should be imported into UDD. There’s also the issue of providing the data through a web interface, to the DDs, which buildstat tries to address partially. The Debian Developer Packages Overview (DDPO)’s main limitations are: - lack of knowledge about VCS (what buildstat solves) - lack of knowledge about complex organizations (you can’t get any list of packages, or list of packages maintained by teams not using a consistant Maintainer/Uploaders scheme, or list of packages from tasks, etc) - poor handling of large amount of packages. In teams with lots of packages, it’s useful to have restricted views, such as “packages outdated compared to upstream”, “packages which have bugs/RC bugs”, “packages which are newer in the VCS than in the archive”. The perl team’s work on PET clearly shows the kind of things that are needed. At this point, I think that DDPO would benefit from a full rewrite (using the existing code as a source of inspiration, and making sure that there are no regressions, of course). Using UDD as the data source, it should be easy to get something done (even if UDD still lacks some of the data DDPO has currently). But it still requires web developer skills, which I don’t have. If you are interested, contact me!

There are some things you just wouldn't want to do without living in the country in Kansas.

A lot of rock on your driveway.

A good view of the sunset.

Neighbors with tractors.

Some way to get rid of trash and recycling.

Some friendly outdoor cats.

That last item is there because there are a few things you would really love to do without:

Mice.

Rats.

Pack rats.

Other assorted rodents.

Now, although we were adopted by a stray cat not too long ago, he is really the skittish, wondering hobo type of cat. Sometimes he's around, sometimes he's not. We'd really like more of a 24/7 rodent patrol. Plus we can't ever get close enough to Sneaky to play with him.

So on Labor Day, I brought home two cats from my parents place: Hudson and Nash. Both are yellow. Neither of them were really accustomed to a car carrier, and though the trip is less than 15 minutes, were quite scared by the end of it.

We normally pen up outside cats for the first few days so that they can identify with a new home, then let them roam free. So we decided to take them in to the grain elevator and let them roam in there for a little while. This is a big old wood structure about 80 years old. It has two stories, and a series of wooden grain bins built into the first floor.

We took the cats, in their carriers, into one of those bins, closed the door, and then let them out. Both were scared, but one of them calmed down quickly, and was soon happily playing with shoelaces, purring loudly, and generally wanting to be held.

The other made a run for it. He couldn't get out the door, but, well, he managed to climb up the wall. Up and out of the grain bin, and another jump or two and he was in the second story of the building -- no doubt finding a lovely cat-sized place to hide.

We eventually closed up the elevator as best we could, and left for the evening.

Tuesday morning, we saw only the smaller cat around. By the afternoon, Terah saw the older cat prowling around in the yard. That's one thing about 80-year-old farm buildings: they can't keep cats in or out. A cat will find a way in, or a way out, if it wants.

By now, they're playing outside and love it. They still like to go inside, and Hudson -- the older cat -- will let me get within about 5 feet of him. Nash tries to not let me get more than 5 feet away, and has climbed most of the way up my jeans using his claws by now.

When we're not outside, we can see them prowling about outside. Sometimes they'll see something -- maybe a cricket or a mouse -- and they'll crouch down, tail moving excitedly, ready to pounce. They don't really play with each other, but they stay close by.

All of this is great, but it comes with a price: I no longer have an excuse to avoid cleaning the rat droppings out of the elevator, because they won't just reappear within a month anymore.

GMsoft reported a few weeks ago, that kernels on his A500 were hanging on startup with CONFIG_PRINTK_TIME enabled. Knowing that all this does is prefix the kernel messages with a timestamp, I was interested to find out how this could possibly be causing a hard hang. Obviously, the first thing to do, is to try and reproduce the problem. But I was completely unable to reproduce it on my RP3440… How very strange. Ok, well, let’s poke at the A500 and see if it will happen there. It does! Spooky…[1] Well, now I was really interested. Let’s see what CONFIG_PRINTK_TIME actually does… In kernel/printk.c::vprintk, around the if (printk_time) section, we see that after printing the priority level tag, such as KERN_INFO, etc., we attempt to print a timestamp obtained with cpu_clock. The returned value from cpu_clock is in nanoseconds, so before it’s printed, it is munged into two smaller integers, the whole-seconds portion, and the decimal portion. Ok, this gives us a great place to start looking for ways PA-RISC could be tripping up on these codepaths. The first was a fairly fruitless search of the cpu_clock call chain, which turned up nothing suspicious, aside from a maze of CONFIG_ options. Turned out, on non-x86, this code reduced into some fairly trivial stuff, none of which could really have been causing a hang. However, we now had a basis for a fairly good hunch. If it wasn’t the cpu_clock going awry, the do_div routine, or sprintf must have been causing it. A quick boot-test to comment out the do_div routine and replace it will a fixed value resulted in a working system. Hooray. Then it hit me like a freight train, when I saw what was being printed. This was the banner line… the very first thing printed in init/main.c, right after jumping into the kernel in virtual mode at start_kernel.
Linux version 2.6.27-rc5-00283-g70bb089 (kyle@shortfin) (gcc version 4.3.1 (GCC) ) #2 SMP Sat Sep 6 19:45:05 PDT 2008
FP[0] enabled: Rev 1 Model 20
The 64-bit Kernel has started…
console [ttyB0] enabled
Initialized PDC Console for debugging.
Seeing the “FP[0] enabled” line immediately caused me to smack my head at the obviousness of the problem. We were attempting to do a division, which, because of how the kernel and libgcc are compiled, is attempting to use the fpu. However, this is faulting on the very first printk in the kernel, well before any of the architecture-specific initialization is done. A quick hack removing any printks before we initialized the fpu fixed the problem as well. But, dirty hacks are not appropriate for mainline. I thought long and hard about a nice way to fix this, but, really, open coding firmware calls in assembly didn’t strike my fancy. There is, however, another easy way to solve it. I ended up replacing the jump to start_kernel in head.S with my own function to turn on the fpu, and called start_kernel from there. Kind of ugly, but at least the fix is entirely contained to arch/parisc, instead of leaking all over the tree. The patch is available, but I’ve been too busy to push it this last release-cycle (and, didn’t really want to tempt fate at pushing a not-quite-actually-serious-fix outside of -rc1 time.) This has been another post brought to you by the maintainer of an inconsequential architecture. We do hope you enjoy it. 1. This ended up being due to either 1) the fpu being enabled by firmware on the PA8800, or 2) the fact that I was doing warm resets instead of cold starts.

Two reasons:

1. 'foo FTBFS on m68k' is not RC. 'foo FTBFS on m68k because it segfaults during the build since it does bar and baz, which just happens to result in a segfault on m68k at startup but might randomly result in a segfault on every architecture, really' in most cases is.
2. It, well, is just fun to debug someone else's code. On m68k, it's easy to do that, too, if you know a bit of assembly language.

Today's (and last week's) bug: #497262. Xemacs21 segfaults at startup on m68k (and FTBFSes because of that), which is RC for m68k. Reason: confusion between a pointer and its value. In other words: the sanity check might succeed, or it might not, depending on your luck. In fact, the first time the code flows through this buggy path, it does not bomb. Once we do get through this bit, it's also very likely that regular error handling will catch it—the only reason why xemacs segfaults here is because we're still in initialization, and the error object in the lisp stuff hasn't been initialized yet, so we get a nice null pointer dereference... That alone isn't enough to make it RC everywhere, but it's good enough to make it important and fixable for the maintainer. Like I said, fun. Sorry for those of you who want to release Lenny ASAP, but I think I'll be making your life a bit harder :-> Next week's bug: a similar issue in emacs, or the build failure of ghc6 on m68k, depending on time and complexity.

For about eight years, I was a very happy WindowMaker user. It was very lightweight, aesthetically pleasing, and I had interiorized its behaviour and keybindings so much, I didn't feel I'd ever switch away. I periodically tried (forced myself even!) to use any of the other, more en vogue environments... Experimented using Gnome for a week, KDE for a week, XFCE for a week (so I would have enough time to learn their ways)... And always came back to my good, well-known wmaker.
In 2006, when we held DebConf6 in Mexico, I saw how other people worked with ion3. I fell immediately in love with it. Not because it is prettier, snappier or has nicer widgets than other window managers - but because it is enormously more usable. Quoting Tuomo Valkonen, the ion3 author,

Ion is not perfect and certainly not for everyone, but neither is any user interface. Usability is subjective.

Using a keyboard-oriented, tiling window manager represented -for the first time in 20 years (I had my first contact with a Macintosh in 1986)- a radical user interface change. For my way of working, I just don't need a desktop, I don't need having a background space or overlapping windows. What I need is a way to functionally organize the windows I have open at any given time, quickly switch between them (and not depending on the mouse, please!), maximizing screen space and all that. ion3 was godsent.
Now, in 2007 there was (yet another) huge flamefest. Valkonen basically does not want distributors distributing any version of ion3 that's not the latest, and introducing changes not approved by him - He basically demands ion to be non-free. So, it was moved to the non-free section of Debian where only Womble decided to keep giving it support. And, of course, by September 2007 Julien Danjou announced he had written another window manager: Awesome.
My main motivation for switching away from ion3 is that... I don't want to use non-free software. But I was very comfortable with ion3. It was only after I saw many other people using Awesome at DebConf8 I decided to bite the bullet and switch. It looked at least as comfortable as ion3.
But... Well, I cannot come up with better phrasing than what Joey said when he switched to Awesome, almost exactly a month ago. When changing between the mainstream window managers, the differences are mostly cosmetic. But with these really different window managers... I cannot but reproduce Joey's words:

I wish I had a good analogy to explain to my nontechnical readers what changing to a new window manager is about.
One way to think about it is that it's like driving a car down the road, and suddenly swapping the steering wheel and brakes out for a tiller and gear shifter. And having to downshift for braking until you learn that the brakes moved to the turn indicator lever. By trial and error.
But that's really only part of it. Another way to look at it is adopting a new philosophy. Or, in some cases a cult. (In some cases, with crazy cult leaders.) Whether they use Windows or a Mac, or Linux, most computer users are members of a big established religion, with some implicit assumptions, like "thy windows shall be overlapping, like papers on the desktop, and thou shalt move them with thy mouse".
So, changing to a new window manager is a process of being dumped into a different environment, where nothing works like you've come to expect, and trying to construct a mental model that you can use to make sense of it. But it's also a process of modifying that environment to behave the way you like.
And when done whole-heartedly, this doesn't just mean trying to make it like the environment you were used to before. It means trying to absorb the underlying philosopy of the window manager, and think up new ways of doing things, inspired by that philosopy, and modify the environment to allow doing those things.
So ideally, "I switched to a new window manager" doesn't mean "my screen has some different widgets on it now". It means "I'm looking at the screen with new eyes."

So, what's so different?
Besides learning some new keybindings (expected, of course), Awesome has several suggested layouts to help you organize your workflow, usually (although not always) consisting of a main area and a side area, tiled side by side (or one above the other, or several stranger ways). This sounds rigid, but it is incredibly comfortable - and I've only been an Awesome user for three days!
But what sets Awesome apart from basically anything else is the concept of tags. Whey you see an Awesome session, you recognize something similar to the very well known workspaces concept we have had in any Unix-like environment for many years, right? Well, but they are not workspaces. They are tags. What is the difference?
When I work with workspace, each of my windows can be in a different workspace. So in one, I'll have my mail-related stuff. In another one, I might be browsing. In another one, I have my development things, and I might be following some logfiles in yet another one.
Awesome allows you to use tags for categorization in much a more flexible way.
For example: I am mostly a web-oriented developer. I usually need four things when developing a system: A browser, Emacs, the log for my development server, and a console where I can peek and poke at my objects and interactions. Of course, cramming them all into the same screen makes no sense - It would be better to follow the good ol' desktop metaphore, and just switch the focus and raise the window, right?
In Awesome, I can have them all set to the maximum screen size - _and_ use the most common combinations as well. Each of the windows can be tagged to more than one workspace (and yes, this is immensely more flexible than the always visible hint on traditional WMs).
To begin with, I'll give each major process a tag to itself, to work full-screen. Emacs is on tag 1, my browser on tag 2. The log and the console share a terminal (i.e. via screen or terminator).
This console by itself is not too useful, so I'll set it to tag 4, and we will go back to it later.
So if I'm building a view or following online documentation, I will add tag 3 to both Emacs and the browser.
I'm also setting tag 4 to the browser - That allows me to use it next to my terminal, following the results of my website-clicking.
And, of course, tag 5 will be set to Emacs and to the console, so I can quickly check any quick API-related question that does not need the documentation or look at a newly written method.
By the way, have you noticed CapsLock is the most stupid key invented, ever? Ok, I gave a good use to it: It's called Mod4. Imagine it is just an extra Ctrl, Alt or Meta key.
So, Mod4-1 gives me Emacs. Mod4-2 gives me the browser. Mod4-3 gives Emacs+browser, Mod4-4 gives browser+console, and Mod4-5 gives Emacs+console. And, of course, the handy Mod4-0 gives me all of my open windows tiled side by side.
Even this is a pattern of being a newbie, I know - I could keep 4 and 5 free, and just tag several simultaneous tags to be active. How? Switch to tag 1 exclusively (Mod4-1), and activate tag2 as well (Ctrl-Mod4-2). There, I have Emacs and browser side by side. Want to get the console instead of the browser? Simple. Ctrl-Mod4-2 (toggle off tag 2), Ctrl-Mod4-3 (toggle on tag 3).
Anyway - As you can see, I am excited at finding a very new and nice tool to help me work better. Today I was playing a bit with the Awesome widgets, but that's something to be talked about later.
In Debian, we are at a crossing point: Awesome is just reaching ion3's popularity. And I'm adding my two main machines' votes to Awesome.
This is Awesome. Quoting (yes, one last quote) the official Awesome site, This gonna be LEGEN... wait for it... DARY!.

It may come as no surprise to some of you that I actually enjoy -- yes, enjoy -- watching political conventions. I've spent some time watching them over the past two weeks.

McCain has yet to speak tonight as I write this, but I've got to get out a few comments.

First of all, both parties of course were attacking the presidential candidate of the other. But did you notice a key difference? The Democrats attacked McCain on policy, while the McCain people attacked Obama on biography. VP nominee Palin even went so far as to mock Obama's work 20 years ago as a community organizer. I think that is incredibly telling. It seems to me to indicate that the Republicans know that their policies aren't working, and are grasping at straws to find something else. There is plenty in McCain's biography that the Democrats could go after -- his involvement in one of the worst scandals in the Senate, for instance -- but they aren't.

What about the other difference? Hope vs. fear. Obama's speech last week was truly inspiring. I don't think I've ever been inspired by a politician before. Make no mistake about it, he set the bar for himself incredibly high. I don't think anybody since Kennedy has done that. Obama realizes that there are things we must do as a country, and he also emphasized that the "ask not what your country can do for you" theme. Watching Giulianni and Palin was an exercise in fear-mongering. It's a constant stream of "9/11 MUSLIM OIL SHORTAGE TERRORISM NUCLEAR BIN LADEN IRAN GAS PRICES RED ALERT PANIC PANIC PANIC MEXICANS 9/11 9/11 9/11 SCARY WAR WAR WAR." It's as if they have discovered M-x spook RET in Emacs.

The Democrats, on the other hand, are talking about reducing health care costs, making sure everyone is covered, ending war, making the economy better for working-class people. It's an interesting disconnect that Obama highlighted well: McCain has said that the American economy has done well over the past 8 years. And indeed, by some "traditional" measures, such as productivity or GDP, it has. But the vast majority of Americans are not better off today than they were 8 years ago. Obama argues that the way McCain measures economic success is way off; our economy is not doing well if the vast majority of regular Americans are not doing well.

Also telling was how both candidates promised to reach across party lines (Bush promised that too). One actually is working to do it. Take abortion, for example. Obama said that he doesn't agree with the pro-lifers, but surely everyone can agree that providing better funding and support for alternatives to abortion such that it becomes incredibly rare is a good thing. Where's McCain looking for common ground? And then, of course, we have Palin wanting her family to be off limits -- but only when it's convenient to her.

I've voted in the past, but usually as a vote against someone rather than a vote for someone. This year, I'll make a single vote and do both.

Ever thought that there should be an automated way to handle ssh keys? Do you know the administrators of your servers, and wish that SSH could verify new host keys from them automatically, based on your personal connections to the web-of-trust? Do you wish you could revoke and/or rotate your old SSH authentication keys without having to log into every single machine you have an account on?Do you administer servers, and wish you could re-key them without sowing massive confusion among your users (or worse, encouraging bad security habits among them)? Do you wish you could grant access to your users by name, instead of by opaque string? Do you wish you could rapidly revoke access to a user (or compromised key) across a group of machines by disabling authentication for that user?A group of us have been working on a public key infrastructure for SSH. Monkeysphere makes use of the existing OpenPGP web-of-trust to fetch and cryptographically validate (and revoke!) keys. This works in both direction: authorized_keys and known_hosts are handled. Monkeysphere gives users and admins tools to deal with SSH keys by thinking about the people and machines to whom the keys belong, instead of requiring humans to do tedious (and error-prone) manual key verification.We have debian packages available which should install against lenny (for i386, amd64, powerpc, and arm architectures at the moment), a mailing list, and open ears for good questions, suggestions and criticism.If you have a chance to give it a try (as a user or as an admin), it would be great to get feedback.

At the dayjob, we've been evaluating various OS options for a customer project. Without going into details, it involves installing embedded software on a ThinCan for a special usage case. The basic needs are simple: graphic environment to run a custom application (OS neutral), plus a few drivers for hardware attached to the ThinCan. That's it. Nothing to excited about. Comparing various team members' proposals to implement the OS base was the real shocker: no matter how optimized the software base and compiler options, no matter which build environment was used (Thin Station, Open Embedded, Gentoo, etc.), we couldn't get a performance that was remotely usable:

• Boot time goes well over a minute, which is way too slow.
• The graphic environment is sluggish, to say the least. True enough, distributions like Thin Station come with rather outdated versions of everything, but still... that slow?!
• Refactoring IceWM to provide clean 95-ish functionalities using current XDG standards would require a fair amount of work. By the time we'd be done, IceWM would probably gain a thick footprint like XFCE progressively did.

Then came the proposal from our team's lone Windows guy: XP Embedded. Booted in less than 10 seconds, has a graphical environment that is usable out of the box and integrating the customer's application was a breeze. Heck, the demo is practically a finished product already and took just a couple of hours to assemble! To make matters worse, the total we'd be paying in licensing fees, for all the Windows components we choose, would amount to far less than what it would cost to polish either of the Free Software -based proposals. Before anyone goes and puts on their asbestos suit, I'm already aware that the point of Free Software is to keep people employed and to make the community at large benefit from everyone's code improvements by contributing patches to upstream. Please keep in mind that, in contrast, business requirements are to get results at a reasonable cost, reasonably fast and to produce a well-polished product. The Free Software community has finally conquered the challenges of the desktop and was already on the server ages ago, but we ain't quite there yet on embedded devices, I'm afraid. While I personally refuse to run anything else than Ubuntu on my laptop, let's face it, in the above case, the savings in time=money were obvious and the resulting product quality, even at demo stage, spoke for itself. Thus, another Tux bit the dust.

Back from Argentina, back from DebConf. As always, the ~3 weeks I spent there were really great, in as many fronts as I can imagine or describe. But I won't go into that now - For the purposes of this posting, the single thing that I got out of DebConf was looking with envy at all the people that had something that used to be called a sub-notebook some time ago, and now morphed into the more modern(?) name netbook.
Several people were seen with their tiny Asus Eee machines, of various models. And I definitively decided I want one - I was quite close to buying one in Argentina, as they are readily for sale there (surprisingly, in Mexico Asus sells motherboards, but no netbooks)... But I've always prefered waiting or paying a little premium for having an on-country seller and warranty.

Back home, Pooka told me that several stores in Mexico do sell the Acer Aspire One. After a little research, I decided to go for it. Office Depot sells the AAO for MX$4500 (around US$450). The only model they carry comes with Windows XP installed (instead of Linpus Linux), which is a shame I thoroughly repeated to the vendor - But it does come with 1GB RAM and 120GB HDD, much better for my needs than the other model, with 512MB RAM and 8GB SSD. This is, after all, a full (although very small) machine. It has an Intel Atom 270 CPU - I haven't yet measured how it fares, but it feels quite responsive so far for typical desktop tasks.
But what made me really happy about it is the Debian support. The only tricky part was to get the installer going, as it does not have a CD drive to boot from (and I didn't want to completely overwrite my only available USB stick's data). Don't try installing Debian Etch, as its kernel will not support the built-in Realtek RTL8101E network card (maybe etch-and-a-half's kernel does?). My greatest ally in this was, of course, the wiki.debian.org article on the Acer One - I rebooted with Lenny's debian-installer, and everything was smooth from that point on. Propietary firmware is required for the wireless AR5007 card and webcam, but -exactly as documented in the wiki- they are covered respectively by madwifi and linux-uvc.
I did a very regular install, with basically the default desktop and notebook setup. I continue to be amazed... Everything just works! It is not even fun, there are no funny drivers to recompile, no bang-your-head-against-the-wall... Even suspend-to-RAM. It just works.
The only glitch I found so far is that, after suspend-to-RAM, the madwifi module must be removed and reloaded to have wireless network. This is a well-known glitch that can be easily worked around. But besides that, it is... as easy as it gets. And, at such a price, and under 1Kg weight... This computer will get used to go out with me quite often! Battery life is just 2 hours, but for most situations, it's more than enough.

One of my favorite things to watch are the “making of [movie, documentary etc] segments that are now routinely included in any DVD. It is nice to look behind the curtain and see exactly what choices are made, what is excluded, and why they are made. I wish that more books, especially academic ones, had a “making of” section, giving a window into these choices. We are not exactly encouraged to include this commentary in the book itself but one can find this type of insight in author interview. I recently read one such interview with the author of Two Bits: The Cultural Significance of Free Software. The interview is on his site and the original is here. There are a couple of things that I found particularly interesting, such as how to treat iconic figures such as RMS and ESR [not as researchers, for example ] and the importance of letting your research and thinking brew over a fairly long period of time, despite the pressure of publishing fast, quick and dirty, which is especially strong with anything “digital.” The book is hefty and long, but as is emphasized in the interview, it is also pragmatic and readable. If folks on Planet have not yet checked it out and are not ready to commit to a long book, I would checkout Chapter 6 on the creation of the copyleft. It is sure to please academics and geeks alike.

As I start this blog post, I'm on the train between Amersfoort and Osnabr ck, on my way to Kiel, where there'll be a meeting of the m68k porters, kindly organized by m68k kernel maintainer Christian Steigies. I took the 8:40 train in Mechelen this morning, and if all goes well, I'll be arriving in Kiel at 17:22 tonight. Some train trip... but I certainly prefer that to any flight. Anyway. The days of Debconf were very nice. Debconf is a lot of things to me. Travel. Hacking. Mao, evolving into a drinking game. Beer. Attending talks. Giving talks. Meeting people. Face-to-face non-flaming. Gesturing for an extra knife at luunch. Hangover. Whiskey. Talking to the person next to you—over IRC. Getting killed before knowing what the rules of the assassins game are. Filing bugreports in person. Pictures. Kilts. Streaming video. Not being sick, hopefully. Name badges. Flying. Sleeping. Yes, sleeping. Most of all, though, this year, Debconf was just great. Thanks. You know who you are. After debconf, I flew to Buenos Aires, where I slept for one night in a Youth Hostel somewhere downtown. They were affordable, but the bed wasn't great—the mattress sorely needed replacement. Since I had a day in BA, and since there were apparently not enough people on the schedule, I'd agreed to hold a talk, and came up with the idea of a 'debian secrets' talk—about Debian-specific commands, such as dpkg-divert and update-alternatives etc—so that people could learn how to use their Debian system more efficiently. As I was sitting in Andreas' talk, who was right before me on the schedule, suddenly Dag walked up to me and said hi. This was unexpected; Dag is a fellow Belgian, who's involved with the CentOS project, and who maintains a positively huge RPM repository at his site—if you maintain an RPM-based system somewhere, you'll probably know about that site. So while I recognized him, I immediately wondered what he was doing there. Turned out he was invited to hold a talk at the Free Software event to which Debianday was attached (and which would not start for another day or two), and that when he saw my name on the schedule, he decided to attend. Fun. He learned a thing or two from my talk, and was talking later about writing some tools for RPM-based systems that would perform the same or similar functionality implemented by some of the Debian tools I talked about. Great. We had a picture together (in front of the DebConf banner—hah) that I still should upload, and then went out for lunch together with some other CentOS guys. The talk itself seems to have been well-received, and I'm glad about that; I only gave it because there was a need for more talks, not because I felt confident I was very knowledgeable about that subject. In fact, I did have to ask on the debconf-discuss mailinglist for some input (which I received) so that I could make sure the talk would actually be useful to people. That helped a lot, I guess. After that, we played some mao in the lobby of the DebianDay venue. While doing so, I overheard Dag talking about CentOS, advocating it to some of the people there, which I must say felt pretty weird on a Debian event. Not that there's anything wrong with it, of course. Except that Dag was supposed to be writing his talk slides. How did that work out, Dag? ;-) Eventually, I got in a cab to the EZE airport, and flew home. That wasn't fully without issue, but I did get there. And now, I've been, eh, overloaded. Still have to follow up on a question a customer asked me, but I've barely been home or at the office, just enough to sleep really. Should do something about that, I guess... Two days ago, I also managed to forget my camera somewhere. For 12 hours, I was worried, even though I had a pretty good idea of where it was; but since I'm getting quite good at taking pictures now, and since I really like doing so as well, I really didn't want to lose my camera. Fortunately, when I called this morning to the place where I thought I'd lost it, they told me it'd been found, and where to get it. In other words, it's safe, it's taken care of, Philip went to get it, and I just need to arrange to get it when I get back. Which is a relief. Let's not be so stupid anymore in the future... Finishing up now, a day later, and I'm at Christian's office, playing with his and my coldfire board. As it happens, it appears that Freescale has brought out a new BSP for these boards, so that's nice. Let's see whether we can get those to boot again...

Ouch. Absolutely no takers on the Squeezed Books contest: http://www.squeezedbooks.com/book/contest http://www.squeezedbooks.com/book/leaders I wonder what didn't work out? I mean, a book isn't a huge prize, exactly, but I know I've participated in mini-contests such as "leave a comment on my blog saying why you should win this book". I actually got a copy of Nick Carr's "The Big Switch" that way. And as it turns out, all it would have taken to win a free book in the Squeezed Books contest is an edit of a few words (as long as it wasn't random gibberish), so the 'barrier to entry' was pretty low. Perhaps I wasn't able to publicize it enough? Maybe the 'right' people didn't find it? Maybe people didn't find it credible? Too much of a pain to log in? The instructions aren't clear? It's tough - I am and always will be a programmer at heart, and this marketing stuff is harder than it seems! However, barring any sudden blinding insights, I'm going to try again. This time, whoever contributes the most to new or existing business book summaries by September 30th gets two business books of their choice, since we didn't give one away last time.

When my friends Karen and Annina were confronted with an offensive sticker on the laptop of someone working at our lab, they organized a very constructive and effective intervention. I was so impressed that I made a short illustrated write-up of the story on my wiki.

Russel Coker blogs about a problem, which concerned me as well: Killing Servers with Virtualisation and Swap, i.e.: what happens when one domU is happily swapping the whole day?

Luckily this didn't happen to me yet, but as Russel do I tend as well to give a small sized swap area to domUs. If they're doing extensive swapping, something is wrong and most probably a task has a memory leakiing problem or the virtual machine is undersized with its RAM.

Anyway, Russel had some thoughts and ideas how to deal with the problem, such as giving dedicated swap areas on single disks to some domUs to seperate disk I/O for the filesystem and the I/O for swap. He proceeds with:

Now if you have a server with 8 or 12 disks (both of which seem to be reasonably common capacities of modern 2RU servers) and if you decide that RAID is not required for the swap space of DomUs then it would be possible to assign single disks for swap spaces for groups of virtual machines. So if one client had several virtual machines they could have them share the same single disk for the swap, so a thrashing server would only affect the performance of other VMs from the same client. One possible configuration would be a 12 disk server that has a four disk RAID-5 array for main storage and 8 single disks for swap. 8 CPU cores is common for a modern 2RU server, so it would be possible to lock 8 groups of DomUs so that they share CPUs and swap spaces. Another possibility would be to have four groups of DomUs where each group had a RAID-1 array for swap and two CPU cores.

I would myself consider a different approach:

• make your RAID as usual across your 8 or 12 disks, but don't use the whole disks, but just a partition on it, leave 10 GB or so free on each disk for later swap purposes.


• with 10 GB on each disk you'll have 80 GB swap with 8 disks or 120 GB with 12 disks in your 2 RU server.


• you can setup your swap areas as needed. Maybe some domUs would benefit from more heads when swapping, some need more space or another one should survive when one disk fails. So you can setup each swap differently, be it as a single partition on a single disk or a RAID1 or JBOD for multiple heads.

Of course you can mix up both approaches or even use swap over NFS or NBD/DRBD. There are many ways and possible solutions, but the best way to deal with swapping is to take care that it doesn't happen, of course... ;)

I recently wrote about wanting to have a teletype. Well, I have since realized that teletypes weigh hundreds of pounds, draw hundreds of watts, and aren't available on eBay for a reasonable price. Well I knew the hundreds of pounds bit, but still. I pretty well have had to give up on a real teletype.

So, now on to the next best thing: a teletype simulator. Enter the two free dot-matrix printers that found their way to my office earlier this week. One of them even works. I bicycled to the awesome local office supplies store (about 11 miles away) to buy a ribbon for it. This is the place that's been there since the 1890s. They still stock dot matrix ribbons, typewriter ribbons, and even fanfold paper.

On the project. Linux has its heritage in Unix, which was used with these devices. It can be made to work with them even now. But there's a trick: teletypes used a bidirectional serial link. Dot matrix printers have no keyboard. So we have to take input from a different device than we send output to.

A simple trick will do for that:

TERM=escpterm telnet localhost > /dev/lp0

Now, here's the next problem. Dot-matrix printers have a line buffer. They don't start printing the line at all until they see CR or LF. Makes it annoying for interactive use. So I wrote a quick tool to insert into that pipeline. After a certain timeout after the input stops, it will force the printer to flush its buffer. Took a little while to figure out how to do that, too; turns out there's a command ESC J that takes an increment for vertical spacing in 1/216 inch, and accepts 0. So I can send \x1BJ\x00 to flush the buffer. I can run it like this:

TERM=escpterm telnet localhost escpbuf > /dev/lp0

That leaves another problem, though: the printhead is right over the text. (Even though it moves to the right of the printing position, and then moves back left for the next character to print.) I modified the program to roll the paper out a bit, and then reverse feed it to continue printing the line. But that is slow and, I suspect, tough on the stepper motor.

Also, I have crafted a terminfo file for the Epson-compatible dot-matrix printers (which are almost all of them), which can also be found at the above link.

So here's the question, for anyone that has used a real teletype:

Did the printhead obscure the text there too, or could you see the entire current line at all times?