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!.

Xen-Hosting

Two years ago I started running the xen-hosting.org setup, offering Xen hosting for 7 people for a reasonable price. (Basically to subsidise my own desire to have a big guest and not pay too much for it) At that time I was charging £11.50 for a Xen guest with 256Mb of memory and 10Gb of disk space. Each year since then we've managed to increase the spec. For the same price. Two years on this means I'm now hosting 7 Xen guests with 1Gb of memory, and 40Gb of disk space, for that same price of £11.50 a month. Nice to see how things can improve as time goes on :) In other news - It is just past our two year anniversary.

DNS Blacklist

Thanks to the people who said nice things about the DNS blacklist I setup the other day. I suffered a couple of DNS-problems earlier in the day, but things should be back up and running for good now. I hope. The ultimate cause was using ":" not "&" records with tinydns. Sigh.

ObFilm: Teenwolf

Do you know this experience: A program, in my case subversion, has a bug and starts to eat memory. You can not interact with your system any more, only watch the memory and swap run full (if you have a display for that). Then it takes a while, while the kernel kills the (hopefully right) program. Things start to move again, until they are fully recovered from the swap and you can continue your work. Or the kernel does somehow not kill the right program, and you are screwed.During regular work, though, your swap is hardy ever needed. Only after a while, a few megabytes of never-used RAM is swapped out, to make space for using the RAM as a file cache.I d like to see the kernel not give out more memory to processes than there is physical memory, because that s plenty for normal work, and if there is more requested, then that s most likely wrong. But I still want the kernel to use the rest of the memory for caching files, and also move some unused RAM pages to the swap file.Unfortunately, there does not seem to be a settings that achieves this directly. But if you happen to have the swap about the same size as your RAM, then these settings, when written to /etc/sysctl.d/vm.conf, will do the job:

vm.overcommit_memory = 2
vm.overcommit_ratio = 0

The first one is to make sure the kernel does not hand out more memory than you tell it to, and the second is to make sure that it only hands out (swap size + 0 * RAM size) to processes.Beware that things go wrong if you happen to have no swap any more for some reason, beause then the kernel will hand out zero memory! Therefore, you need to make sure that these settings are applied after swap was enabled. On a Debian machine, rename /etc/rcS.d/S30procps to /etc/rcS.d/S37procps. This would not be possible if you could also specify the ration of swap memory to be used. Then I could set that to zero and the RAM ratio to 100.If anyone knows better ways to achieve this, I m interested to hear them.Update: For my qemu based armel package builder, this is not enough it seems. I m now running it with overcommit_ratio = 50.

It's the X Development Summit in Edinburgh this week, so I've been hanging out with the graphics crowd. There hasn't been a huge amount of work done in the field of power management in graphics so far - Intel have framebuffer compression and there's the lvds reclocking patch I wrote (I've cleaned this up somewhat since then, but it probably wants some refactoring to avoid increasing CPU usage based on its use of damage for update notifications). That still leaves us with some fun things to look at, though.

The most obvious issue is the gpu clock. Intel's chipset implements clock gating, where unused sections of chip automatically unclock themselves. This is pleasingly transparent to the OS, and we get power savings without any complexity we have to care about. However, there's no way to control the core clock of the GPU - it's part of the northbridge and fiddling with the clocking of that would be likely to upset things. Nvidia and Radeon hardware is more interesting in this respect, since we can control the gpu clock independently of anything else. The problem is trying to do so in a reasonable way.

In an ideal universe, we can change these clock frequencies quickly and without any visual artifacts. That way it's possible to leave it in the lowest state and clock it up as load develops. There's a couple of problems with this - non ideal hardware, and the software in the first place. Jerome's been testing a little on Radeon and discovered that changing the memory clock through Atom results in visual corruption. It's conceivable that this is due to some memory transaction cycles getting corrupted as the clock gets changed. If we could ensure that the reclock happens during the vertical blank interval, that's something that could potentially be avoided (of course, then we have the entertainment of working out when the vertical blank interval actually is when you have a dual head output...). The other problem is that 3D software tends to consume as many resources as are available. Games will produce as many frames per second as possible. Demand-based clocking will simply ramp the gpu to full speed in that situation, which isn't necessarily what you want in the battery case (as the number of frames per second goes up, so does the cpu usage - even more power draw) but is probably pretty reasonable in the powered case.

Handwavy testing suggests that this can save a pretty significant amount of power, so it's something that I'm planning on working on. Further optimisations include things like making sure that we're not running any PLLs that aren't being used at the time (oscillators chew power), not powering up output ports when you're not outputting to them and enabling any hardware-level features that we're currently ignoring. And, ideally, doing all of this without causing the machine to hang on a regular basis.

I recently announced that German and French reached 100% completion in unstable for po-debconf translations (by the way, both are now 100% in lenny as well). However, l10n efforts also happen for many languages in that area, so it's time to highlight them as well:

• Third is Portuguese at 98.3%. Nearly all complete. It would need some overview by the team, lead by Miguel Figueiredo, to complete the currently incomplete files.
• Czech if 97.85%. The effort is a very longstanding one by Miroslav Kure, nearly alone. Miroslav has small difficulties to cope with changes in eth->lenny release cycle which explains why, despite they once were virtually 100%, cs could never reach it. This will happen for squeeze
• Vietnamese is 84.97%. Clytie Siddall fights with changes and her real life conditions and still succeeds in keeping the l10n effort up. I'm admirative
• Dutch is 80.72%. The Dutch team is an "old" team in Debian with a thorough, but sometimes slow, QA process. I have no doubt about the quality of their work. The manpower seems fairly short, though, with people involved in many other areas in Debian and outside.
• Swedish was slowly vanishing until Martin Bagge recently resurrected it. They even passed over Russian again at 78.76%. Congratulations.
• Russian is constantly progressing. Kudos are due to Yuri Kozlov who efficiently leads the team. They'll make it at 100%, I don't doubt it. 78.71% for now.
• Galician is the longstanding one-man effort by Jacobo. He already described in details his work process and took great advantage of my NMU campaigns to progress constantly. 76.80%: will he pass over Swedish and Russian before lenny?
• Spanish is an "old" team. I expected to see a good progress, which doesn't really happen. The NMU campaigns do not benefit them and I don't see that many bug reports. What's happening there? Tis team is one I'm most worried about.
• Finnish took great advantage of the NMU campaing with Esko Ar j rvi following it very closely. He bumped the stats from less than 40% to 66.5%
• Japanese slowly goes its own way. The effort is less constant than others, but they successfully manage to stay around 60%
• Basque is also constantly progressing. Under the lead of Piarres Beobide, the team reached 60% after starting below 40%
• Brazilian Portuguese is more focused on DDTP these days (they have impressive stats, thanks to Felipe can de Wiel's work) so they just manage to stay around 55%

Other translation efforts are more hectic. I'd like to point the slow decrease of the work on Catalan, probably due to low manpower and other areas of interest for the old timers. I'll try to soon make such report for other areas of translation effort in Debian.

Here some news from the Smuxi front. As you might already know Smuxi 0.6.2 was released. With the 0.6.2 release we have now German translation and Smuxi packages in Debian (Unstable) (as promised), Ubuntu (intrepid) and ArchLinux (AUR)! Now just OpenSUSE, Foresight Linux, Gentoo and Fedora are missing for world domination^W^Wconvering the major Linux distributions. The upcoming 0.6.3 release will contain Spanish (thanks to Juan Miguel Carrero), French (thanks to Clement BOURGEOIS) and British English (thanks to Ryan Smith-Evans) translations. Besides bugfixes this release will contain the famous tray icon support and some other goodies! The release should be ready by this weekend... stay tuned.

My previous post titled AppArmor is Dead [1] has inspired a number of reactions. Some of them have been unsubstantiated opinions, well everyone has an opinion so this doesn’t mean much. I believe that opinions of experts matter more, Crispin responded to my post and made some reasonable points [2] (although I believe that he is overstating the ease of use case). I take Crispin’s response a lot more seriously than most of the responses because of his significant experience in commercial computer security work. The opinion of someone who has relevant experience in the field in question matters a lot more than the opinion of random computer users! Finally there is the issue of facts. Of the people who don’t agree with me, Crispin seems to be the first to acknowledge that Novell laying off AppArmor developers and adding SE Linux support are both bad signs for AppArmor. The fact that Red Hat and Tresys have been assigning more people to SE Linux development in the same time period that SUSE has been laying people off AppArmor development seems to be a clear indication of the way that things are goind. One thing that Crispin and I understand is the amount of work involved in maintaining a security system. You can’t just develop something and throw it to the distributions. There is ongoing work required in tracking kernel code changes, and when there is application support there is also a need to track changes to application code (and replacements of system programs). Also there is a need to add new features. Currently the most significant new feature development in SE Linux is related to X access controls - this is something that every security system for Linux needs to do (currently none of them do it). It’s a huge amount of work, but the end result will be that compromising one X client that is running on your desktop will not automatically grant access to all the other windows. The CNET article about Novell laying off the AppArmor developers [3] says ‘“An open-source AppArmor community has developed. We’ll continue to partner with this community,” though the company will continue to develop aspects of AppArmor‘ and attributes that to Novell spokesman Bruce Lowry. Currently there doesn’t seem to be an AppArmor community, the Freshmeat page for AppArmor still lists Crispin as the owner and has not been updated since 2006 [4], it also links to hosting on Novell’s site. The Wikipedia page for AppArmor also lists no upstream site other than Novell [4]. The AppArmor development list hosted by SUSE is getting less than 10 posts per month recently [6]. The AppArmor general list had a good month in January with a total of 23 messages (including SPAM) [7], but generally gets only a few messages a month. The fact that Crispin is still listed as the project leader [8] says a lot about how the project is managed at Novell! So the question is, how can AppArmor’s prospects be improved? A post on linsec.ca notes that Mandriva is using AppArmor, getting more distribution support would be good [9], but the most important thing in that regard will be contributing patches back and dedicating people to do upstream work (Red Hat does a huge amount of upstream development for SE Linux and a significant portion of my Debian work goes upstream). It seems to me that the most important thing is to have an active community. Have a primary web site (maybe hosted by Novell, maybe SourceForge or something else) that is accurate and current. Have people giving talks about AppArmor at conferences to promote it to developers. Then try to do something to get some buzz about the technology, my SE Linux Play Machines inspired a lot of interest in the SE Linux technology [10]. If something similar was done with AppArmor then it would get some interest. I’m not interested in killing AppArmor (I suspect that Crispin’s insinuations were aimed at others). If my posts on this topic inspire more work on AppArmor and Linux security in general then I’m happy. As Crispin notes the real enemy is his employer (he doesn’t quite say that - but it’s my interpretation of his post).

• [1] http://etbe.coker.com.au/2008/08/23/apparmor-is-dead/


• [2] http://blogs.msdn.com/crispincowan/archive/2008/09/02/go-ahead-make-my-day.aspx


• [3] http://news.cnet.com/8301-13580_3-9796140-39.html


• [4] http://freshmeat.net/projects/apparmor/


• [5] http://en.wikipedia.org/wiki/Apparmor


• [6] http://forge.novell.com/pipermail/apparmor-dev/


• [7] http://forge.novell.com/pipermail/apparmor-general/


• [8] http://forge.novell.com/modules/xfmod/project/memberlist.php?group_id=1864


• [9] http://linsec.ca/blog/2008/09/03/crispin-responds-to-allegations-that-apparmor-is-dying/


• [10] http://www.coker.com.au/selinux/play.html

Share This

I don't know what it says about Debian but while the political content of my last post was ignored, I have received a steady stream of email today saying Michael Palin was in fact the lumberjack in "And Now For Something Completely Different" Obviously I am unfit to be a heartbeat away from the DPL. obTheOtherPalin: Today is Ganesh Chaturthi so I have been to busy praying to watch it. I presume it will be on youtube or something by tomorrow. In any case as long as she didn't embarass herself, my view that she will be a plus for the McCain campaign still stands.

I've been too busy to follow GCC development recently and haven't done any testing of development snapshots during the GCC 4.4 development phase so far. However, GCC 4.4 moved to stage 3 yesterday, the development stage dedicated to bug fixes and documentation. Given that GCC is now in stage 3 and that Debian unstable has fairly little churn because of the freeze, it's an ideal time to do some archive rebuilds. I started archive rebuilds on amd64 and powerpc last night and added ia64 today. I also tried to build GCC on armel, alpha and sparc but there are compiler errors during bootstrap. mips builds fine but I haven't started any archive rebuilds. I found and reported 9 compiler errors so far. Most of them have already received some attention and one of them has been fixed in the meantime. I'm not looking at build failures of packages at the moment since that's very time consuming and I'm not sure whether I'll find the time to report build failures later as GCC becomes more stable, but we'll see.

Here are my notes on growing a KVM disk image’s root filesystem. I had a few 4G partitions that really needed to be bigger. This shows how to get a report on the sizes of the disk images, convert them to raw, work on the partition tables, grow the root filesystem, and rebuild the swap partition with the original UUID. With some work, it could probably become fully scripted, but since the partition layout may not always be the same from VM to VM, the “fdisk” step needs human interaction to delete and rebuild the partition table. Note that the method below also maintains the sparseness of the images.

# Look for files to change
for i in /vmware/*/* vmdk,qcow2 ; do qemu-img info $i; done
...
# Pick one...
cd dir...
ORIG=64bit-Ubuntu-7.10-desktop.vmdk
SIZE=8G
ORIG_TYPE=$(echo $ORIG   awk -F. ' print $NF ')
TARGET_TYPE="qcow2"
TARGET_BASE=$(basename "$ORIG" ."$ORIG_TYPE")
TARGET_RAW="$TARGET_BASE".raw
TARGET="$TARGET_BASE"."$TARGET_TYPE"
qemu-img convert -f "$ORIG_TYPE" "$ORIG" -O raw "$TARGET_RAW"
trunc "$TARGET_RAW" "$SIZE"
sudo kpartx -a "$TARGET_RAW"
SWAP_PART=$(for i in /dev/mapper/loop0p*; do sudo vol_id $i   \
    grep -q ^ID_FS_TYPE=swap && echo $i; done   head -n 1)
UUID=$(sudo vol_id "$SWAP_PART"   grep ^ID_FS_UUID=   cut -d= -f2)
sudo kpartx -d "$TARGET_RAW"
# use losetup otherwise fdisk doesn't know cylinder count
sudo losetup /dev/loop0 "$TARGET_RAW"
# FIXME: Need to automate fdisk (detect swap partition size, etc)
# I'm deleting the swap and growing the root partition, then re-adding swap
sudo fdisk /dev/loop0
sudo losetup -d /dev/loop0
sudo kpartx -a "$TARGET_RAW"
sudo e2fsck -f /dev/mapper/loop0p1
sudo resize2fs /dev/mapper/loop0p1
sudo mkswap -U "$UUID" "$SWAP_PART"
sudo kpartx -d "$TARGET_RAW"
qemu-img convert -f raw "$TARGET_RAW" -O "$TARGET_TYPE" "$TARGET"
rm "$TARGET_RAW"
# FIXME: change disk image path
sudo vi /etc/libvirt/qemu/THING
# FIXME: have the daemon notice the file change
sudo /etc/init.d/libvirt-bin restart
if [ "$ORIG" != "$TARGET" ]; then rm "$ORIG"; fi

The “trunc” command above is based on my network backups post, but is now a general script I use:

#!/usr/bin/perl
# Copyright (C) 2006-2008 Kees Cook <kees@outflux.net>, License: GPLv3
use strict;
use warnings;
my $filename = $ARGV[0];
die "Need valid size also\n" unless ($ARGV[1] =~ /^(\d+)([KMG])$/);
my $size       = $1 + 0;
my $multiplier = $2;
$size *= 1024 if $multiplier =~ /^[KMG]$/;
$size *= 1024 if $multiplier =~ /^[MG]$/;
$size *= 1024 if $multiplier =~ /^[G]$/;
#die "Not trunc’ing existing file\n" if (-e $filename);
die "$filename: $!\n" if (!open(FILE,">>$filename"));
die "seek: $!\n" if (!(seek(FILE,$size,0)));
die "truncate: $!\n" if (!(truncate(FILE,$size)));
die "close: $!\n" if (!(close(FILE)));

There are many online blacklists which are populated by volunteers. I'm looking for such a blacklist which contains records of hosts conducting portscans, ssh brute-forcing, or other similar "badness". dshield looks good - but doesn't make the scanning IP availble - just shows the port data. denyhosts allows you to upload/download a list of IPs trying to run ssh bruteforce attacks - but when I wrote my own RPC code to poll that list of IPs I found I couldnt' get the full list.

I'm aware that I could run denyhosts on a spare IP, then just copy the IPs it downloads but that feels icky...

I'm unaware of any existing service that I could use for my purposes. So would there be any interest in a service listing only portscanning/ssh brute-force IPs? (Allowing DNS queries, XML-RPC, or rsync downloads of the submitted data.) Obviously I have my own reason for wanting such a list of bad IPs... Those are probably obvious, but it does seem like it would be generally useful. I'd be willing to host a server to process the submitted reports, and make the results available, but I guess thats the easy part. The hard part is persuading people to run my "submit IP" client. Which has to understand ssh logs, iptable logs, or something similar.. Ugh. I guess between the machiens I work with and the machines I host myself I've got a fair number of IPs which I could collect scans from - I could populate the database myself. But this is a perfect job for distributed submission. ObQuote: Batoru rowaiaru

Google have announced a new web browser - Chrome [1]. It is not available for download yet, currently there is only a comic book explaining how it will work [2]. The comic is of very high quality and will help in teaching novices about how computers work. I think it would be good if we had a set of comics that explained all the aspects of how computers work. One noteworthy feature is the process model of Chrome. Most browsers seem to aim to have all tabs and windows in the same process which means that they can all crash together. Chrome has a separate process for each tab so when a web site is a resource hog it will be apparent which tab is causing the performance problem. Also when you navigate from site A to site B they will apparently execute a new process (this will make the back-arrow a little more complex to implement). A stated aim of the process model is to execute a new process for each site to clear out the memory address space. This is similar to the design feature of SE Linux where a process execution is needed to change security context so that a clean address space is provided (preventing leaks of confidential data and attacks on process integrity). The use of multiple processes in Chrome is just begging to have SE Linux support added. Having tabs opened with different security contexts based on the contents of the site in question and also having multiple stores of cookie data and password caches labeled with different contexts is an obvious development. Without having seen the code I can’t guess at how difficult it will be to implement such features. But I hope that when a clean code base is provided by a group of good programmers (Google has hired some really good people) then the result would be a program that is extensible. They describe Chrome as having a sandbox based security model (as opposed to the Vista modem which is based on the Biba Integrity Model [3]). It’s yet to be determined whether Chrome will live up to the hype (although I think that Google has a good record of delivering what they promise). But even if Chrome isn’t as good as I hope, they have set new expectations of browser features and facilities that will drive the market. Update: Chrome is now released [4]! Thanks to Martin for pointing out that I had misread the security section. It’s Vista not Chrome that has the three-level Biba implementation.

• [1] http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html


• [2] http://www.google.com/googlebooks/chrome/


• [3] http://en.wikipedia.org/wiki/Biba_Integrity_Model


• [4] http://www.google.com/chrome

Share This

gksu-polkit gets pipe support One of the features I really wanted to get into gksu-policykit early was working correctly with pipes. With the current gksu you cannot do something such as echo blah gksu tr a-z A-Z. It is actually very hard to work correctly with input/output with su and sudo bellow. I do think it also has something to do with me not being too clever in UNIX file descriptors at the time I originally planned how gksu works. I did get an email from someone at Sun offering to write support for that who never mailed me again, but anyway… gksu-policykit is currently able to get all the input and output forwarded to/from the process by using an interface similar to glib’s g_spawn_async_with_pipes. Here’s what we are able to do already:

$ echo test string   ./gksu/gksu-polkit /usr/bin/tr a-z A-Z
TEST STRING
$

It’s impressive to me that all the input and output goes over DBus quite nicely.

The comment policy has changed; check the page links for the details. The big change: I’ve turned off the CAPTCHA page that would be presented for comments judged to be “borderline” spam by the spam filter software. For those not aware, CAPTCHA is the name given to the funny letters and numbers on weird backgrounds that you sometimes have to type in to do things on certain web sites. The idea was that computers couldn’t read those letters and numbers, but humans could; thus, each solved CAPTCHA was proof that a human had done whatever it was that had been done. CAPTCHA had issues even from the beginning. They present obvious issues for the blind, and were often simple enough to be read by modern OCR software. Because of this, I never turned it on for every comment, and any comment rejected because of the CAPTCHA just went into the moderation queue. But I’m now convinced that CAPTCHA has reached the end of its useful life. So when a commenter on my last post expressed his dissatisfaction with my CAPTCHA, I decided it was time to turn it off. And so, references to it have been expunged from my comment policy. The Esperanto translation of my comment policy has also been updated, in the hopes that I might someday post a little more often in that language. It’s also been moved to a page.

This is 'back to school' season aroun here. So on Saturday we went and set up two desks for our two kids. And with that I finally converted 'their' computer to a working multi-seat setup. At first, I had fiddled with two distinct (ATI Radeon) graphics cards. Somehow I never got x11 to recognise both cards properly. But two cards are not needed. As the machine is running a standard Kubuntu setup, I just followed this excellent three-part tutorial for Ubuntu multi-seat setup which describes the process using nothing but standard Ubuntu software. From setting up a 'big desktop' spanning two screens (which is easy enough using one card via the vga and dvi outputs), it is fairly straightforward to modify the gdm.conf setup to spawn two gdm greeter instances using the Xephyr nesting xserver. So far, all is well. We'll see what possible shortcomings we will find. The GL extensions are not supported, so some eye-candy will be unavailable.

Is anybody out there really using the Pdiffs we offer for apt & co? I have them turned off on all my machine as they only make apt slower on every machine I know, I can’t see any benefit from them. Only seem to blow up the download time A LOT, waste space on mirrors, time in dinstall (well, 2 minutes, but still), … It seems to me to be a feature that would have been useful some decades ago, where you had something called floppy discs to transfer files. But nowadays even ISDN should be fast enough to not require them? Can someone enlighten me please and comment here? Thanks. Comments: 14

Is anybody out there really using the Pdiffs we offer for apt & co? I have them turned off on all my machine as they only make apt slower on every machine I know, I can’t see any benefit from them. Only seem to blow up the download time A LOT, waste space on mirrors, time in dinstall (well, 2 minutes, but still), … Can someone enlighten me please and comment here? Thanks.

Running apt on the FreeRunner I've already mentioned that I'm running approx in the laptop and I configured the FreeRunner to access the laptop's cache. Here are the other customisations needed to have a decently working apt:

# cat /etc/apt/apt.conf.d/99freerunner 
APT::Install-Recommends "false";
Acquire::PDiffs "false";

The rationale is that recommends would bloat a system that is supposed to be small, and pdiff requires more CPU, memory and disk space/time than it actually saves in bandwidth. Thanks to Michael Banck and Peter Palfrader for helping me to find out how to disable pdiffs.

When volume becomes high enough you start to observe patterns in SPAM pretty easily. I think that this is primarily because people like to see patterns, whether they are present or not. The trick is determining whether they are real patterns or not, and then to a lesser extent whether they are useful patterns. For example I host mail for a business domain. That means that incoming messages come primarily from existing customers, and very rarely from potential new ones. In practise that means that email is expected to arrive from 9am til 6pm (+/-2hours) Email received at 2AM? Either it is somebody working remotely, a foreign contact, or much more likely it is SPAM. Now clearly you cannot dump all messages received at unusual times of the day, but it is a surprisingly robust SPAM indicator for that particular domain. All heuristics are fallable, but some are useful regardless.. I'd love to know what people can learn from their SPAM. This week I'm handling approximately 80,000 messages a day, per MX, which isn't huge (ie. 2-3 million a month). ObQuote: Highlander

Sorry, ever since Debconf I've been busy, ill and otherwise distracted. I'm still catching up... Stuff that's happened: Dude, you're married! For the second year running, I had to leave Debconf a day early to attend a wedding party. My good friend Matthew married Oxana last Monday. I've just put my photos of the happy event online today. After a successful Debconf where I managed to evade the normal plague, it hit hard on the Tuesday morning and I've been struggling with it ever since. Just about over it now, but I've been feeling crap for over a week. On the way to Buenos Aires to catch my flight back to England, I received a text message telling me the sad news that my uncle, John Bolton had passed away. This means that the eldest two of my mum's three brothers have died this year, in the space of just a few months, and it's been a very hard time for the family. The funeral happened earlier this week, so I was away and mostly off-line for a couple of days travelling there and back. I'm trying to get back up to speed on a whole host of different things at the moment; if you're waiting on a response from me about Debian-related stuff, please feel free to prod me via email or IRC.