Following up to Myon’s post, I also wanted to blog my honest opinion about the GR. Given my current understanding of the GR, I hope to see it fail (and will send my vote shortly after this blog entry I think). The reason is not that I think it shouldn’t be made easier to contribute to Debian (on the contrary). But the GR micro-manages too much and on the other hand doesn’t make the current NM process any easier for DM’s than for any non-DM applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer DM status over DD status. And the same is true (IMHO) for other people wanting to contribute to Debian. This is a simple thing: If I contribute to something regularly in my spare time (like most contributors in the FL/OSS world do), I also would like to have some influence over its directions. And a DM is missing this influence even more than a DD is. So what should be done instead in my opinion?
I think that a DM like status is fine as part of a (possibly re-designed) NM process. Given the current NM process, I would like people been given a DM like status after they finished the T&S (tasks^IIRC and skills) part if their AM found their skills and knowledge of the policy rules sufficient to give them that status. If that is all they wanted, they can drop from the NM process at that point and stay DMs. If they want to become DDs later on, they can resume the NM process at that very step (or continue right ahead). This would do several things:

• introduce the DM status as an alternative to full DD status
• integrate the DM status closer with the existing NM process
• take some load of the friendly sponsors who upload non-DD packages now, giving them more time to help more new contributors
• give people waiting for DD status some intermediate level at which they already can do more than before their joining of the NM queue

So I really think “more discussion” is the only valid option for me in this GR. If you want to change my mind: Please leave some feedback in my blog. Or give a precise (but brief) description why the current proposal is better than integration with the current NM process in one way or the other. Abbreviations:

• DD = Debian Developer (a full Debian project member, includes voting rights)
• DM = Debian Maintainer (planned to be a somewhat restricted DD, among others without voting rights)
• NM = New Maintainer (should actually be: New Developer)
• GR = General Resolution (a way in Debian to create new rules or to ask the project leader or others in the project to do or refrain from doing something)

Update:
The GR even seems to contradict itself a bit. If the upload rules are applied in an AND fashion, one of these rules is superfluous (the first one), at least if I’m not mistaken:

• the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
• the most recent version of the package uploaded to unstable or experimental includes the field “DM-Upload-Allowed: yes” in the source section of its control file
• the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)

The first rules also means that no DM could ever do an upload for packages team-maintained in the fashion cyrus-imapd-2.2 is maintained (Maintainer address is the teams mailinglist address, all uploading team members are in the Uploaders field). This is IMHO a serious flaw in the proposal. If the first rule was dumped, all would be well for team maintainers.

Share This

Christer Edwards over at Ubuntu Tutorials has written a short tutorial on Devil's Pie. Thanks Christer! Now if only people would stop using a hack I wrote several years ago and fix the real problems... NP: The Last Flowers from the Darkness, Mark Van Hoen

Since march the DSA team uses a request tracker to handle all the requests that they get. Therefore you should no more use the debian-admin@debian.org alias (DSA members only). The debian-admin@lists.debian.org mailing list (DSA + local admins) is also scheduled for removal. Instead you should mail admin@rt.debian.org making sure to put “Debian RT” somewhere in the subject (crude but working spam prevention). By default, your ticket ends up in a private incoming queue. Up to now only DSA members had access to those queues. They moved most tickets in the public queue but it happened several times that this simple administrative burden took several weeks. Since a few days, Matt Taggart and myself have been granted RT accounts with required privileges to handle tickets and move them between the various queues. So from now on, all tickets will be quickly moved in the public queue (when they don’t contain sensitive information of course). We’ll be able to do some triage and ping DSA members for urgent requests. Matt and me have been trying to help out the DSA team for quite some time now, and while we’re not DSA with root rights, we’re in regular contact with the members (except Martin “Joey” Schulze who refuses to join the DSA IRC channel, who doesn’t use the request tracker and who doesn’t read the DSA mails either) and with several local admins. So if you have some troubles interacting with the DSA team, you can try to get in touch with us and we’ll see if we can help you. In too many cases people contact directly individual DSA members (Joey in particular). Please refrain from doing so, other volunteers (who might help you) won’t notice your request. Furthermore systematic request tracker usage helps us identifying what is well handled and what’s not. And it’s not more complicated than a simple email for you. Update: currently local admins are not subscribed to the request tracker. The RT setup will need some further adjustment for that, so the debian-admin@lists.debian.org list can still be useful if you want to reach them.

I've received a fair number of responses to my previous blog post on labelling/tagging mail and have created a list for public discussion of the topic. Please subscribe if you're interested in this topic. I am also trying to get permission to repost some of the responses I got there. Furthermore an update of my blog post with some of these comments is pending. Busy times NP: Dredg: Catch without Arms

After my comments about the TV audience figures, Ismael Valladolid Torres commented:

"Audience in Spain will keep on raising while Contador keeps playing such a big race!"

I hope that's still the case after the recent revelations. The evidence suggests that Vinokourov had someone else's blood [tdfblog] and Cofidis's Moreni was using something like a nutsack patch [tdfblog] while Rabobank have fired race leader Rasmussen for telling them he was in Mexico when he was in Italty [tdfblog] so it looks like this year's race is still really unpredictable as the dopes are caught and kicked out. Maybe my hopes for a Valverde (now 6th, 10:18 back) win still stand a chance... (My "serious" prediction, Kl den, left with Vino.)

You may have noticed that my frequency of posting has increased significantly recently, and that my posts are generally at 7AM and 7PM. I am using the scheduled posting feature of Wordpress and writing my posts in advance (currently I have 8 posts in the queue including this one). Generally readers of my blog (particularly those who read Planet syndication pages) don’t want to read 5+ posts in one go. In the past I would write one post at a time and sometimes a couple of days would pass between feeling inspired to write. I had been writing text files and uploading them, but having a text file that’s 95% done is not the same as having a complete post scheduled to be released while I’m doing something else. This technique works for me, I encourage other people who have things to say but don’t seem to get around to blogging on some days to give it a go. Incidentally I chose the times 7AM and 7PM because the traffic to my site seems to peak between 7PM and 11PM local time (I haven’t analysed the logs in enough detail to determine whether this is Australians reading blogs after work or people in other countries doing it at work). To release two posts per day it seems most appropriate to space them 12 hours apart (and means that people in the same time zone as me can read a post before going to work).

Share This

Today was HP day again. Kinda like Christmas, HP day is when I wake up to some new HP hardware in a box under the mailbox on the porch. For some reason, HP keeps sending me hardware, and this time they shipped me a HP t5725. It's kinda funny what's called a "thin client" these days. This box has 512 mb of flash memory, no moving parts, and is silent. Other than that it's a fullfledged desktop machine in a very nice smallish package. The OS is a very lightly modified Debian sarge. They did a good job at adding their tweaks without getting in the way of Debian. I was able to install whatever additional packages I wanted on the hundred+ megabytes of free space. Most users will probably be perfectly happy with the preinstalled system, you can surf the web, etc. This was one of the few preinstalled systems that I've actually used for more than 10 minutes without wanting to blow it away with my own custom install. If felt sorta silly to do so, but I'm installing testing on it right now via netboot. ... That went fine, no issues whatsoever. Though on a system with this size disk, tasks are useless and every package must be hand-picked right down to the xorg video driver packages. So it really is a thin client for me, NFS root is a good way to go, and means that I have a machine on my desk that I can use as a workstation, and easily reboot to use as a d-i and rootsync testbed, without worrying about preserving the contents of its disk.

I am still looking for a solution that allows me to tag my mails similar to what Gmail offers. Having thought about this for quite a bit now, I can see three solutions, implemented at different levels in the mail flow: as filesystem, patch to the IMAP server (Dovecot), or patch to mutt. Since this post is about the filesystem, I'll concentrate on that, but I'll also touch upon the other two solutions briefly.

I've only taken a quick look at the quilt documentation but the
following thoughts occur to me:

1. emsource / emdebuild are similar to quilt and in some ways, I have
   reimplemented a subset of quilt in these scripts.


2. emsource handles 'quilt add' provided that changes are confined to
   files in debian/ (including new patches added to debian/patches).
   However, I was unable to find out how quilt handles unchanged files.
   e.g. emdebuild skips creating the patch if the diff is empty - does
   quilt do the same for files that have been added?


3. quilt is targetted at "upstream builds" and it will require various
   config settings to get quilt to both keep patches outside the package
   source directory AND handle situations where the package itself uses
   quilt with a different series of patches. emsource and emdebuild are
   completely separate from any existing patch method.


4. quilt does NOT make autobuilding emdebian packages easier. Conflicts
   are meant to be resolved by hand (e.g. emdebian-changelog.patch). A
   bespoke method can embed specific logic on handling such issues that a
   general method like quilt cannot.


5. quilt could be *almost* as transparent as the current method (which
   hides nearly all patch management within emsource and emdebuild) but
   would still require a wrapper to add support for keeping the patches in
   SVN.

Hmm. Think I'll stick for now. You can have too many nested tools.

"It is unlikely that X_oce is larger than X_atm , because the ocean initially exists below the atmosphere". From Enhanced atmospheric loss on protoplanets at the giant impact phase in the presence of oceans, Genda et. al, Nature, 2005. Tags astronomy, quotes

For a while now, Iceweasel/Firefox comes with built-in phishing protection, which is undoubtedly a good thing given the number of idiots using the Web these days. But the implementation is crap. If you surf to a phishing site, such as this test site, the page loads as you would expect and then the first strange things happen:

• the mouse movement becomes sluggish as the browser increases its virtual memory needs from 466Mb to a measely 912Mb, while the RSS jumps from 134Mb to 423Mb. The entire computer hangs for 2-3 seconds whenever I drag the mouse pointer off the window. I am not saying that my window manager (fluxbox) or Xorg or anything else on this machine is flawless, but this problem only ever appears with Iceweasel/Firefox. Anyway, it's impossible to follow any links on the page, the mouse pointer does not even change.
• suddenly, an icon and a little triangle appear at the right side of the URL bar.
• about 7 seconds later, the rest of the balloon appears, alerting me to the dangers of phishing attacks. Did people think those things are so extraordinarily beautiful that they had to be copied from Windows (or Apple, or whatever)?
• another 5 seconds later, the webpage darkens.
• with an entirely unresponsive browser, I have no other choice but to try to leave the page, which is easier said than done: Hitting Ctrl-W to close the tab does not have any effect for almost 25 seconds; then the page was finally gone and the system restored itself to normal.

I get similar performance problems on the StaTravel website, and on map.search.ch, it almost always crashes. Thank you, Firefox developers, for bringing the joys of the Windows world to Linux! NP: Dream Theater: Metropolis Pt 2: Scenes from a Memory Update: several people have responded that they cannot reproduce the problem. I thus created a new profile, uninstalled all system-wide extensions, removed all plugins such that about:plugins was empty and tried again. The problems persist, although I think the lags are not quite as long as before and the memory consumption is obviously down. Maybe this is amd64-related? Update: It's not amd64-related, as several users have pointed out. Update: still no luck, but James Andrewart pointed me to this bug report, which might improve things a bit:

"The new protocol specifies a single lookup algorithm for all tables, rather than having per-table logic. This lookup logic was moved in to the db service from the javascript. URL canonicalization was moved completely into C++ too. The DB service can now handle a query from a raw URI, which will be needed for malware blocking."

Bloomberg: Tour de France TV Audiences Rise in Europe Even After Scandals (tip tdfblog ) reports audiences are up 6% in France, 11% in Spain and 40% in Denmark (to over 800,000). Italy's RAI reports 1.2million viewers, while ARD/ZDF averaged 1.4million until they pulled the plug over half a dope test. In the UK, the BARB Weekly Summaries show the tour's London-Canterbury Stage 1 charting with 178,000 viewers on itv4. That's up from 143,000 for 2006's stage 1 (up 24%). Last year's itv4 coverage seems to have peaked at 197,000, so it'll be interesting to see how later stages fare, as details are announced. Stage 1 was also shown on the more widely available (analogue+digital) itv1 channel. The itv1 coverage didn't chart, so it must have had less than 3.41 million viewers, but I can't see exactly how many. British Eurosport's reported audience for Stage 1 increased from 84,000 last year to 118,000 (up 40%). Their 2006 peak was 100,000 for the last Thursday highlights, so that's already broken. They've been advertising pretty widely, with really annoying Franglais adverts that mispronounce the race name ("Tardy France" eh?). There was also an overspill into other channels, which we don't usually see. Two of my favourites: Graham Jones: What do the Tour de France and a Victoria sponge have in common with your social networking web site? Channel 4: Tour de France's UK appeal (video feed) mms://a1167.v15478c.c15478.g.vm.akamaistream.net/7/1167/15478/v0004/origin.channel4.com/news/2007/07/05_bike.wmv

In a default configuration of Xen there will be a virtual Ethernet device created for each interface which will be associated with a bridge. A previous post documented how to configure a bridge named xenbr0. The basic configuration of Xen that most people use is to have a single virtual Ethernet port for each Xen instance and have them all connected to the one bridge, and then the Dom0 will have an IP address on the bridge interface that is used for routing packets to the outside world. This works really well if you have a subnet that you are using for all Xen DomU IP addresses, if you are using NAT for communication, or if the DomU needs no communication outside the Dom0 and other DomU’s on the same machine (a common case for testing). But if you have a collection of servers that you want to consolidate on a single piece of hardware then you end up using a single sub-net that spans some physical machines, some Xen Dom0’s, and some DomU’s. The solution to this is to use bridged networking. Unfortunately most documentation of bridged networking is really confusing, and non of my google searches turned up the most relevant fact: When setting up a bridge on the local Ethernet you must make your physical ethernet device (eth0 or whatever) be strictly a slave to the bridge and then assign the IP address used for the physical network to the bridge.

ifconfig eth0 up

brctl addif xenbr0 eth0

For example if you have 10.0.0.42 being the IP address used by the Dom0 on the local Ethernet via device eth0 and you want to use bridging for DomU’s then you simply make eth0 owned by xenbr0 (the typical name for the Xen bridge) with the above commands in your script to configure the xenbr0 device. Then treat xenbr0 in the same way that you treated eth0 before enabling bridging. Also there’s nothing stopping you from having one bridge for DomU’s that can talk directly to the physical Ethernet and another for DomU’s that are only to use routed networking, see my previous post about using multiple ethernet devices in Xen for more background information.

Share This

DemoCamp Montr al 3 is happening tomorrow. We're going to be at the SAT from 18:30 to 20:30, holding demonstrations on a whole range of different topics. Why DemoCamp? Well, Montrealers are some of the most creative people I know and they've got plenty of things to show and tell. DemoCamp is like a big gathering of creative minds who get to watch fifteen-minute presentations on anything. And since all you can do is demo: no slides, no gimmicks, then you actually get to see real stuff doing real things. I'm going to be there to show you how to make a counterclock. You know, the opposite of a clock that goes clockwise. Along the way, I'll do a little explaining of electricity, timekeeping, and motors. I just have to remember to buy a clock today. :P Come on, it'll be fun! DmoCamp Montr al 3
Tuesday, 24 July 2007
18:30 20:30
Societ des arts technologiques
1195 boul. St-Laurent
Free admission ( Sign up Facebook Upcoming Google Maps )

Ian, I am not sure that “good package management” is a real selling point for anyone but system administrators. Home users do not care, as there is not that much difference between double-clicking an executable (that pops up a window, asks a few questions and then installs the software) and selecting a check-box in a list and clicking “apply” (followed by window, questions, etc.). In a business setting the users usually do not have permission to install software anyway, so they could not care less how it was installed, the only thing important is that it is there. In my opinion, the single technology that has had the most impact would be COM, the “Component Object Model”, because this is what the ISVs want: an easy way to define a (binary) interface that will allow components from different vendors to work together, ideally in the same virtual address space for maximum efficiency. The registry provides the necessary lookup functionality, so that you can construct an object of a given type by giving its class name or GUID to CoCreateInstance, and you get something back that provides the interfaces that this class implements, which is either the object directly or an RPC proxy. The latter happens, for example, when a multithreaded application wants to call methods in an object that is not threadsafe (COM will then serialize the calls) or when the object is provided by a system service (where we have dbus). The fact that the only thing you can rely on is the defined interface (a set of methods and data objects that map to getter/setter methods) makes it necessary to define the interface first and invest lots of Interfaces become immutable as soon as they are published, incompatible changes need a new interface name (that's where all the interface names ending in …2 or …3 come from). Under Linux, the closest thing is GNOME and their use of CORBA. If you were to write an application that runs within the GNOME framework, and if you wanted third party vendors to be able to plug into it, then you would probably publish an IDL file for it. Lots of “if”s there. Licensing is also an issue here. One thing the GPL fails to address, even in version 3, is the integration of components without linking into the same address space (which ORBit never does IIRC). Technically, the component provider and the component user communicate via sockets using a well-known protocol, so the component user is not bound by the GPL; the only thing that could be argued is that the IDL file defining the interface would be GPLd (although most jurisdictions consider interfaces as not copyrightable and/or permit “reengineering” for interoperability purposes). Some people might consider this “cheating” around the GPL, as any GPL'd program or library providing components could be used freely by any closed source application as long as the source code to the GPL'd portions was made available. Last (but not least) it is a matter of developer motivation. Third party vendors are, for most of us, not our target audience, and properly supporting them is going to be quite a bit of work. I've written about mixing different C libraries in the same executable image before, as a “nice to have” item. For components that should share the same image, like COM does, it is an absolute must, and COM goes to great lengths to make sure this actually works. For example, allocating memory that is to be passed to a COM method must be allocated using midl_user_alloc() from the RTC DLL and freed using midl_user_free() from the same; as this is a system library and compiler vendors are forbidden from bringing their own, everyone uses the same allocator pair (that internally just calls malloc() and free() from the Microsoft C library, but that is an implementation detail you are not supposed to know). On the Linux side, people do not care much about matching allocator functions, because in essence it all ends up in glibc's malloc()/free() anyway. When glib introduced their own allocators and started using them for their own structures, a number of applications started crashing unless you set a certain environment variable that told glib to pass everything through to glibc. Personally, I've spent the last days compiling toolchains in order to provide compiler packages that work “out of the box” on at least Debian etch, lenny and sid, and Ubuntu dapper, edgy, feisty and gutsy. Right now, I feel a lot like shipping statically linked binaries. Where Windows has mostly gotten out of the “DLL hell”, Linux has built its own variant of it:

The Windows DLL hell

is a hot place. Everyone is bringing their own grill lighter they believe does not cause cancer, starts a small fire and begins to roast marshmallows. The problem there is that the floor is covered with a sticky mixture of lighter fluid and everything is burning.

The Linux DLL hell

on the contrary is freezing cold. It has small isolated fires where a few friends are sitting, and they suddenly decide to move on and pour water over the fire and your marshmallows without asking first. Getting into a group is difficult, and if you manage it, all it means is that you are told to pick up your marshmallows before they extinguish the fire.

At this point, I'm going to be comment- and trackback-whoring; instead of answering the obvious question, I'm going to leave it open: Would a COM-style componentization model work in the Linux world, and attract software vendors, provided we can put out stable APIs and support them properly, or is that a red herring?

Just because I can't run sa-learn on my 15,000+ messages spam folder. It'll crash due to some hardware problems.
I thought that splitting the mailbox into smaller files will allow me to feed it to sa-learn.
I'm not sure something similar doesn't exist but I wrote mine anyway ;-)

The only problem is it consumes a lot of CPU and RAM, it was killed/crashed multiple times but it worked and allowed me to feed my spam mailbox to spamassassin!

Here it is in case someone needs it: split_mailbox.py. Needs python 2.5
read more

I’m just in the process of converting a multi-user system to a Xen DomU. It was running on a stand-alone Fedora Core 5 i386 system and I want to run it on a Fedora 7 DomU under a CentOS 5 Dom0 on an Opteron system. The first stage of the conversion was to copy an image of the Fedora Core 5 system and make it a DomU under CentOS. I had some problems getting a Fedora Core 5 Xen kernel to boot so I installed a 64bit CentOS 5 kernel with the Fedora Core 5 user-space and surprisingly everything worked. I had expected to have problems with kernel modules, but everything just worked! I had expected that the 32bit modutils would be unable to load 64bit modules, but things just worked. The first stage was to have the old server NFS export /home and have it mounted by the Xen DomU, this worked well for about a week. The next step was to move the data on to the new server. My first attempt was to have the Dom0 running the filesystems and NFS exporting them to the DomU but this caused an OpenOffice error “Error saving the document Name: General Error. General input/output error.“. So having 32bit Fedora Core 5 with a 64bit Cent OS 5 kernel NFS mounting from a 32bit Fedora Core 5 system works well, while mounting from a 64bit Cent OS 5 system fails. If anything I would have expected better results from having the same version of the kernel on NFS client and server. The next issue is whether a 64bit Fedora 7 system in a DomU can NFS mount the data from the Cent OS 5 kernel with Fedora Core 5 user-space. If not it’ll make testing the Fedora 7 upgrade significantly more painful than it might otherwise be. If only we had a network filesystem for Unix that supported POSIX semantics.

Share This

Since I spent quite some time thinking about my SMTP setup earlier today, I finally took the time to hack up a little perl script to parse my mainlog, pick out the IP addresses of hosts that appear to have been spamming me, put them in a database, and modified my exim4.conf to look them up and deny them access if I want to. Those lookups are pretty easy, really. In the first section of your exim4.conf, I have this:

hide pgsql_servers = (/var/run/postgresql/.s.PGSQL.5432)/*/spam/Debian-exim/

with '*' being the password. Except that this is ident authentication, so I don't need a password, but apparently exim still expects something (if I'm not on crack). Oh well. Then, in an acl, I have this:

  deny
    message = "Your IP was used for spamming over the last few days. Please stop the spamming, wait a few days, and try again."
    log_message = "denied access for $sender_host_address: in blacklist database"
    condition = $ lookup pgsql SELECT id FROM spammer WHERE       \
       adres='$sender_host_address' AND lastseen > now() - '10 \
       days'::interval true false 

(with the backslashed lines being one line, really, but I didn't want to fuck up scrolling) You can put this in any ACL you want, really. In my case, since I'm very sure by the nature of the way I gather these IP addresses that they're spammers, it's in acl_smtp_helo. Depending on how you populate your database, you may want to put this in a different place. If you want, you can teergrube them a bit by adding delay=30s. An alternative would be to set up a DNS blacklist; but that would just take too much effort to set up properly, and I just didn't feel like it. This works.

Hey folks, we released some minutes ago finally Debian-Edu/Skolelinux 3.0r0 “Terra” which is based on Debian 4.0 with some modifications to work out-of-the box. Here are the releasenotes: Oslo - July 22., 2007 Skolelinux 3.0 is ready. This is an community release with comprehensive support from regional and national projects in Germany, Spain, France, Greece and Norway. The Skolelinux project is now a part of Debian under the name Debian-Edu. Several other projects have made additional functionality to Skolelinux tailored for national needs. Skolelinux now supports more than 50 countries.

Whats new in Skolelinux 3.0:

• based on Debian 4.0 “etch” and therefore compatible to LSB 3.1, using kernel 2.6.18 and KDE 3.5.5
• Full support for networked Thin clients, LowFat (diskless) clients, Workstations and Laptops. With the LowFat clients users got full PC functionality with extremely low maintenance cost. The use of LowFat clients gives full support for sound, video, USB memory stick’s and DVDs without the need for a local installation.
• Skolelinux now got more than 80 applications selected for pedagogic uses, supporting more than 50 languages. Many new applications are introduced in addition to popular classic as GCompris, KDE-Edu, Iceweasel (unbranded version of Firefox) and OpenOffice.org.
• Installation is a breeze: Both the installation and source code for all software are now distributed on a single DVD now supporting three different processor platforms as i386, PowerPC and AMD64. This makes it more easy to choose hardware, and to study the recipes behind the software. Those interested can exercise their freedom to learn, participate and share knowledge more easily. Installation CDs are also available, but requires a working Internet connection for installation.

About Skolelinux Skolelinux is a complete tailored software solution for the needs of any educational institution or school. It is a ready computer system were the school does not need to piece together the components. Skolelinux is the result of the work of the Debian Edu project and Debian Edu is an official Debian subproject. It is installed in a great number of schools in Norway, Germany, France and other countries. Municipalities and Commercial Service Providers run Skolelinux across multiple schools, operated and maintained centrally. Service providers report that the “lowfat clients” require half the maintenance cost of other desktop alternatives. The next milestone of Skolelinux development will be to merge the Debian-based LinEx distro into Debian Edu. Currently LinEx is used by more than 250,000 students and public employees in the region of Extremadura in Spain.

In depth “Lowfat clients” is also known as Diskless workstations. They run applications locally on the client. All software comes from the server instead of locally from the client hard drive. Recommended minimum requirement for client machines is > 256 MB RAM and 800 MHz CPU. Skolelinux now got improved tools for system surveillance and maintenance. Roadmap for next merging of LinEx and Debian-Edu: * http://wiki.debian.org/DebianEdu/LinEx2DebianEdu-Roadmap Please note that the documentation for the 3.0 Terra release is only available in English at the moment and contains some rough edges. We have considered releasing before the end of the summer holidays more important and we will fix those rough edges in the coming weeks, when we also expect more translations to show up. Those fixes will be included in the upcoming 3.0 r1 release.

In the past something-over-half-a-year (wow, time flies like crazy), i have shuffled my (virtual) toolbox fairly significantly. In the desktop department, I no longer use the full KDE desktop, only a few applications from KDE 3 (that is mostly konqueror, plus some of kdeedu). I still use amarok, although by now mostly just to manage my iPod, since it is outright laptop-hostile. Most of the time, it’s better (and much more power-efficient) to use iPod hooked into usb for power, at least as long as the music is there. For the rest, i now use the commandline players to play single albums (just music123 for most formats). For the window manager, i have opted for xmonad, after briefly using ion3 and a faint attempt at wmii (which didn’t quite work for me). Xmonad, however, works great and its simplicity is quite amazing. Despite its absolute minimalism, it is, after some getting used to, much more usable than the rest of WMs i have used. For terminal, i use urxvt, which is lighter and apparently also faster than konsole (i may reconsider that choice when KDE 4 konsole comes out). With xmonad, i don’t really need tabs anymore, i’m not sure why, but it may be related to more general change in my workflow. In the version control department, i am now using darcs for all the projects where i decide. I no longer use svk, since i no longer really know how to. Not working with it for a while, i lost the ability to use it efficiently (which possibly hints at the fact it is somewhat too complex). On the other hand, i am much happier with darcs, also since it is much more forgiving about mistakes and generally very deterministic. It requires some insight to be used efficiently i suppose, but this is mostly due to differences with more traditional systems (i believe). Today, i have finally moved my ikiwiki to darcs, which was the last thing using subversion/svk (well, i have only been able to use it through ssh and local svn for some months now, so i generally didn’t use it at all). This hopefully means that i will be able to add more content to this page and blog as well, since it is less effort now. I am still using emacs (GNU emacs 22, xemacs didn’t quite work for me when i have tried it — i have a somewhat nontrivial setup, too). I intend to try out vimpulse at some point, in addition to viper, to supersede my emacs-lisp hacks for visual line selection. I have also started working on replacing my internet-facing services, since they are running in an “emergency” (ie, not really working well) mode, after the xen system broke down completely (it was mostly un-upgradable due to fragility of xen packages and of the whole xen system — and since the setup relied on working xen for even basic internet connectivity, upgrades were extremely painful). I am migrating to a solution based on user-mode-linux, and moving all the services to a less power-hungry and less noisy machine (an oldish pentium 3 box). When this is complete, i should be able to read my private mail sanely again, since currently the spam filters don’t work and my inbox is mostly trash. This is unrelated to the xen breakdown, my mail used to be handled by a machine at a company i used to do admin work for. However, they removed my accounts (and therefore access to my mail) without a line of prior notice. I still have control over my domain at least (although there will be a problem when it gets to expire, i will have to arrange a transfer with the said company, i suppose). Morale of the story: never do that. (Yeah, and in the spirit of the post, i am still using mutt for reading mail).