Velisurmaaja was published in Elias L nnrot’s collection of traditional Finnish poems, the Kanteletar in 1840. It bears some similarity to the British ballad Edward. What follows is the original text, lifted from the tenth Gutenberg edition of Kanteletar juxtaposed with my English translation (which is more concerned with getting the message across than being good poetry). However, I am assured the translation is not beyond redemption, so here it is: (more…)

In a discussion which covered some of the differences between Linux and Windows, a Windows using friend asked me if I felt compassion for Windows users. I feel some compassion for people who have bad working environments. While using an operating system that has poor support for the business tasks does decrease the quality of the working environment, there are bigger issues. For example a while ago I was doing some sys-admin work for a financial organisation. I had to use Windows for running the SSH client to connect to Linux servers, this was annoying and decreased my productivity due to the inability to script connections etc. My productivity was also decreased because of my unfamiliarity with the Windows environment, it seems reasonable to assume that when you hire a Linux sys-admin they will have some experience of Linux on the desktop and be quite productive with a Linux desktop system - while the same can not be said for a Windows desktop. But what really made the working environment awful was the paperwork and the procedures. If a server doesn’t work properly and someone says “please fix it now” and I only have a VT100 terminal then I’ll be reasonably happy with that work environment (really - I wouldn’t mind a contract where the only thing on my desk was a VT100 connected to a Linux server). But when a server process hangs in the same way several times a week, when the cause of the problem is known and the fix (restarting the process) is known it really pains me to have to wait for a management discussion about the scope of the problem before restarting it. But I don’t have a great deal of sympathy for people who end up in bad working environments such as the one I was briefly in. Anyone who is capable of getting such a job is capable of getting a job with a better working environment while still earning significantly more than the median income. The people I feel sorry for are the ones who work on the minimum wage. I don’t think that the difference between Linux and Windows on the desktop would matter much if you were getting the minimum wage, and people who are on the minimum wage don’t have a lot of choice in regard to employment (I think that all options for them suck). I don’t have much sympathy for adults who use Windows at home. I have to admit that there are some benefits to running Windows at home, mainly that the hardware vendors support it better (few companies sell PCs with Linux pre-loaded) and there are some commercial games which are in some ways better than the free games (of course there are more than enough free Linux games to waste all your time - and some games are best suited to a console). Linux has significantly lower hardware requirements than Windows (my main machine which I am using to write this blog post is more than three years old and has less power than any other machine on sale today apart from some ultra-mobile PCs), so any long-term Windows user can install Linux on one of their machines which lacks the resources to run the latest version of Windows. The only Windows users for whom I have much sympathy are children. When I was young every PC came with a BASIC interpreter and everyone shared source code. Books were published which taught children how to program in BASIC which included fairly complete example programs. For the cases where proprietary software was needed the prices used to be quite low (admittedly the programs were much less complex - so pricing is probably in line with the effort or writing the code). Now it seems that computers are often being provided to children as closed systems that they can’t manipulate, the web browser has replaced the TV. I believe that Linux is the ideal OS for a child to use. There is a wide range of free educational programs (including kturtle - the traditional Logo turtle) and there are also a range of free powerful programs which can be used by any child. Few parents would buy Photoshop or Adobe Illustrator for a child to play with, but anyone can give a child a $100 PC with GIMP and Inkscape installed. They might as well give 3yo children access to the GIMP - it will be less messy than fingerpainting! I expect that some parents would not consider Linux for their children because they don’t know how to use it. Fortunately Linux is easy enough to use that a child can install it without effort. Some time ago the 11yo daughter of a friend who was visiting asked if she could play some computer games. I gave her a Fedora CD and one of the PCs from my test lab and told her that she had to install the OS first. Within a small amount of time she had Fedora installed and was playing games. While the games she played were not particularly educational, the fact that she could install the OS on a computer was a useful lesson. It seems to me that children who are raised as Windows users are less likely to learn how computers work or be able to control them properly. I expect that on average a child who is raised in such a manner will have fewer career options in today’s environment than one who properly understands and controls computers.

Share This

One of the things I've wanted to do since I discovered that Caltrain (and the VTA light rail) are well-equipped to take bikes, was go for an outing further afield on our bikes using one of these methods of public transport. So we finally got around to doing that yesterday, when we threw our bikes on the train, and BART, and went for a ride around Golden Gate Park. The grand plan was to bike to the Caltrain station, take Caltrain to Milbrae, BART to downtown, then bike from there to the park, and then catch an afternoon showing of The Dark Knight in IMAX at the Metreon, then bike back to the BART station, and reverse the whole thing. We had a minor hiccup in that Sarah had just gotten her bike back from a friend she'd lent it to, and as we were about to head to the Caltrain station, discovered that it a broken spoke. She managed to extract the spoke and we got to the station with a couple of minutes to spare. It turned out that Mike's Bikes were fairly close to the BART station, so we stopped in there on way to the park, and they were able to fix the spoke on the spot in 20 minutes for the princely sum of $21. Unfortunately the weather was pretty typical summer San Francisco weather, and it was quite cold and foggy. It didn't get any better as we got closer to the park (and the coast), so the ride around the park itself wasn't terribly exciting. The hill we had to get over (Hayes Street) was a bit of a slog. On the way back we saw the filming of a Japanese Nissan commercial (complete with right-hand drive car). I'd done some research into bike parking beforehand, and found that all of the parking garages are required to provide bicycle parking, and there's a pretty comprehensive list. So we parked our bikes in the Moscone Center garage, which was about a block from the Metreon, and went and caught the movie. The Dark Knight was really good. Very... dark. I really liked Ledger's portrayal of the Joker, much better than the original. I wonder if they'll just keep re-imagining the Batman movies over and over? There was pretty good continuity from Batman Begins. I thought the voice of Batman was a bit ridiculous though, at least initially. You kind of got used to it after a while. Anyway, we got back to the parking garage, and some lowlife had cut through the cable lock that we'd used to lock our bikes to each other and the rack, and stolen Sarah's bike! Annoyed does not begin to describe it. We trundled off the seven or eight blocks to the Hall of Justice to file a report. The SFPD weren't the least bit interested, really. The somewhat astounding thing was the bike racks were right behind the cashier's office, and there was video surveillance, and someone still managed to just walk right in, cut the cable, and walk out with the bike. We checked with the duty manager, and he reviewed the video footage and said they have footage of him walking in and then walking out with the bike. So hopefully the police will get hold that. We have to see if we can dredge up the purchase documentation for the bike and see if the serial number is recorded. I have no idea if we'll ever see the bike again. Our renter's insurance may cover it, but I suspect the deductible won't make it worth our while to make a claim. I have to say (and it's not like it's a recent discovery or anything) that the Bay Area's public transportation is a joke. It cost us $32 to go from Mountain View to Downtown San Francisco, via Caltrain and then BART. Our Prius takes about 11 gallons at worst, and with gas prices being at say $4.30 a gallon, that's about $47 a tank. We get about 400 miles out of a tank usually, and it's vaguely 40 miles from home to the guts of Golden Gate Park. So it's cheaper, and faster to drive to San Francisco than it is to use a bicycle and public transport. Particularly when you factor in the risk of theft of your bicycle. Our next bike lock will be one of those fancy Kevlar ones.

One thing that I would like to get fixed for Lenny is the shared objects which can reduce the security of a system. Almost a year ago I blogged about the libsmpeg0 library which is listed as requiring an executable stack [1]. I submitted a two-line patch which fixes the problem while making no code changes (the patch gives the same result as running “execstack -c” on the resulting shared object). My previous post documents the results of the problem when running SE Linux (a process is not permitted to run and an AVC message is logged). Some people might incorrectly think that this is merely a SE Linux functionality issue. The program paxtest (which is in Debian but is i386 only) tests for a variety of kernel security features in terms of memory management. To demonstrate the problem that is caused by this issue I ran the commands “paxtest kiddie” and “LD_PRELOAD=/usr/lib/libsmpeg-0.4.so.0 paxtest kiddie“. The difference is that the test named “Executable stack” returns a result of Vulnerable when the object is loaded. This means for example that attacks which rely on an executable stack will be permitted if the libsmpeg-0.4.so.0 shared object is loaded. So for example a program that loads the library and which takes data from the Internet (EG FreeCiv in network mode) will become vulnerable to attacks which rely on an executable stack because of this bug! My Etch SE Linux repository has had a libsmpeg0 package which fixes this bug on i386 for almost a year [2] (the AMD64 packages are more recent). I have now added packages to fix this bug to my Lenny SE Linux repository [3]. I have also volunteered to NMU the package for Lenny. It seems that it would be rather embarrassing for everyone concerned systems were vulnerable to attack because of a two-line patch not being applied for almost a year. I expect that the Release Team will be very accepting of package updates for Lenny which have patches to address this issue. A patch that has one line per assembler file (in the worst-case) to mark the object code is very easy to review. The results of the patch can be tested easily, and failure to have such a patch opens potential security holes. Package maintainers who can’t fix the assembly code can always run “execstack -c” in the build scripts to give the same result. Lintian performs checks for executable stacks and the results are archived here [4]. There are currently 36 packages which contain binaries listed as needing executable stacks, I would be surprised if more than 6 of them actually contain shared objects that need an executable stack. If you use a package that is on that list then please test whether an executable stack is required by running “execstack -c” on the shared object and see if it still works. If a test of most of the high-level operations of the program in question can be completed successfully without an executable stack then it’s a strong indication that it’s not needed. Note that execstack is in the prelink package. I am happy to help with writing the patches to the packages and using my repositories to distribute the packages, but am not going to do so unless I can work with someone who uses the program in question and can test it’s functions. As an example of such testing I played a game of Frozen Bubble to test out the libsmpeg0 patch.

• [1] http://etbe.coker.com.au/2007/10/07/executable-stack-and-shared-objects/


• [2] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/


• [3] http://doc.coker.com.au/computers/installing-se-linux-on-lenny/


• [4] http://lintian.debian.org/tags/shlib-with-executable-stack.html

Share This

It's more or less four months since I proposed to resurrect our newsletter. We already released eight issues of the Debian Project News and work for the ninth issue has already started. So I guess it's time for a small "state of the DPN" speech, but since I'm not attending DebConf, you will have to read this mail instead ;) After having a rough start (and in fact missing some self-set deadlines and completely underestimating how much work is involved in such a kind of newsletter) we finally developed a - more or less - working flow of work (Which is by the way documented here). Speaking of the current state sadly means to confess, that our hopes to draw a lot of help from the community by using a system for drafting the news with a low entry barrier were not fulfilled. We actually had a good start, with good participation, but due to (I assume) the aforementioned initial difficulties participation in the creation of the DPN dropped considerably. Currently the workload of creating our bi-weekly newsletter is shared by only two people (that being Meike Reichle and myself), which is barely enough :( While we at least get a hint from time to time, what we should mention in the next issue, it rarely happens, that someone contributes by drafting a text -- which is the real work. (At this point a BIG "Thank You" to those who did! (See list bellow.) It's much appreciated!) We suffer especially, since although we are a two people team, we have in fact no redundancy, since real live issues affecting one of us will most likely affect the other one, too. Therefore we mostly concentrated our work on creating the next issues and getting them out in time, and didn't have time to answer all mails considering suggestions for changes and improvements (yet?). We are sorry, but at least we tried to read them briefly and keep them in mind when drafting the next issue. As a result of this we re-added the list of DSAs, WNPP and new and noteworthy packages due to popular demand. There are still a lot of unanswered mails not dealing with content, but with workflow issues / proposals (including changing from wiki.debian.org to a special ikiwiki instance). We are sorry, that we couldn't yet act on them and take appropriate measures, but be assured, they are not forgotten. Other issues the DPN currently have are "unwritten guidelines" regarding editorial choices of DSAs to be published and which packages to list in the "new and noteworthy package" section. Both is more or less done by our gut feeling. Speaking of problems the DPN are facing, we also need to mention translations of the DPN. The current workflow makes it difficult for translators of the DPN, since we often fail to get the final draft of the DPN ready in time to give translators a "head start" so the translated DPNs can be released together with (or at least with a as small as possible delay to) the English DPN. So here is a big call for help! We really need your help writing the DPN. (Monitoring lists and newstickers we don't monitor ourselves would be nice, too, but only add more work to us if you only give us pointers.) We will both be very busy with our real live the upcoming month, and are not sure how much time we can dedicate to the DPN. So please help us! The current draft for the next issue of the DPN is always available here . There should already be a todo list with pointers to interesting topics, which need to be written out. Some guidelines about style and content are available here. Last but not least, we would like to thank the following people who have contributed to the DPN so far:

• Adrian von Bidder
• Ana Guerrero
• Andre Felipe Machado
• Bjoern Boschman
• Graham Cobb
• Jeff Richards
• J rg Jaspert
• Jon Evans
• Julian Andres Klode
• Justin Rye
• Luca Bruno
• Martin F. Krafft
• Paul van der Vlis
• Paul Wise
• Raphael Hertzog
• Russell Coker
• Sebastian
• Stefano Zacchiroli
• Thomas Lange
• Wouter Verhelst

(Unfortunately we can't list those people, who contributed by translating the DPN, nor do we have a complete list of the native English speakers, who helped by proofreading. But we thank them nonetheless!)

Looking at native code invocation options for ruby. To make apt-listbugs code safer, and faster, I was looking for ways of not forking dpkg every time it tries to analyse package versions. SWIG and other stuff seem to be good for calling C code, but not useful for calling C++ code. C++ code isn't exactly convenient for dlopening and calling. I tried making a little shared library for forking and it seems to work that way, but I don't know if I really want to create and maintain this C++ shared library just for this feature. 390332 is the old patch I crafted.

Here at DebConf 8 in Argentinia, I m working on getting Debian to work on the OpenMoko Freerunner Smartphone. We are progressing quite nicely, soon having the same features as the official freesmartphone.org image. See the pkg-fso wiki page for more on that. And why do we want to do that? Because we can use everything in the Debian archive on our phones!This is the xmonad window manager, programmed in Haskell and usually running on my Desktop, now on my mobile phone! And it s almost usable. Only problem is that the screen keyboard, metacity-keyboard, gets the focus by xmonad, so I can t actually type into other windows. This could be fixed by configuring xmonad, but for that, I need to install ghc and I do not have these 280MB left on my SD card...

Well that happened, and uneventfully as well. Now if only IntaServe actually made it possible to update glue records, everything would be done... What is it with domain registrars and glue records? Are glue records that much of an edge case these days that no one bothers having an interface for managing them?

Some time ago, there was some flamewars^H^Hdebate about the Release Team’s removals of RC-buggy packages from testing. Basically, some people claimed that popular packages shouldn’t be removed, even if RC-buggy. But, do we really miss popular packages in testing? It’s difficult to know. You could get the popcon data, and compare it with the Packages files for testing and unstable. Or work with source packages (which removes a lot of noise), but then, you have to convert the popcon data (which uses binary packages names) to source packages. Not completely trivial. That’s where the Ultimate Debian Database GSOC project comes to the rescue. The goal of Christian von Essen’s project is to gather data from various sources in Debian into a single SQL DB, so queries that combine all those data sources can easily be written. For example, here is the query that lists the source packages that are in unstable, but not in testing, sorted by their popcon (using the number of insts of the most popular binary package of the source package as value for the source package):

SELECT DISTINCT unstable.package, insts
FROM (SELECT DISTINCT package FROM sources
WHERE distribution = 'debian' and release = 'sid') AS unstable, popcon_src
WHERE unstable.package NOT IN (
   SELECT package FROM sources
   WHERE distribution = 'debian' AND release = 'lenny')
AND popcon_src.source = unstable.package ORDER BY insts DESC;

And the results are available on the web! Top packages (> 1000 insts):

lzo	64962
gnome-cups-manager	32346
db4.6	20708
ffmpeg-debian	12908
freetype1	10569
flashplugin-nonfree	7116
perlftlib	6769
nvidia-graphics-drivers	3864
wxwindows2.4	3640
dvi2tty	2239
kdebase-runtime	1725
easytag	1717
g-wrap	1582
yaird	1507
slocate	1499
youtube-dl	1390
hugin	1275
w3c-libwww	1058

Interested in UDD? Join #debian-qa or debian-qa@lists.d.o (or talk to me @DebConf!)

I'm starting my trip to Mar del Plata, Argentina for DebConf 8 for my second DebConf. Although I live in Indianapolis, I'm flying out of Cincinnati since I found a cheaper flight. My trip to DebConf 7 was riddled with delays and I was hoping for my trip to DC8 to be nice and trouble free. I almost got my wish, but 10 miles from CVG the transmission went out on my car. After dealing with AAA for an hour I finally caught a cab to the airport. So far, nothing else bad has happened but I won't hold my breath until I'm safely in MDQ. Hope to see you there!

Today is Galactic Freedom Day. Debian needs to join in and ensure future generations have full access to the source code of their anal probes.

Handling concurrent update-apt-xapian-index runs So, update-apt-xapian-index takes a bit of a long time to run. When you install the package, if the index isn't there then postinst will rebuild it in background, good. Now, suppose you have an advanced package manager that after installing apt-xapian-index, detects that it's installed, detects that there is no database and runs an update with a nice GUI feedback. If this happened while the update is running in the background, the usual thing to do would be to abort the update; however, the package manager wouldn't be able to know when the indexing has finished and it can enable the advanced features. Let's not do the usual thing, then: What happens here is that if the upload is in progress, the second update-apt-xapian-index will not be able to lock a lockfile. But instead of exiting, it connects to the other indexer via a unix socket, and shows the progress just as if it were the one doing the indexing. So, now, suppose I run update-apt-xapian-index:

# update-apt-xapian-index
Reading Debtags database: done.  
Rebuilding Xapian index... 20%

And suppose I run another one:

# update-apt-xapian-index
Another update is already running: showing its progress.
Rebuilding Xapian index... 20%

And suppose I run yet another one:

# update-apt-xapian-index --batch-mode
notice: Another update is already running: showing its progress.
begin: Rebuilding Xapian index
progress: 19/100
progress: 20/100

And suppose I run yet another one (running with -q shows nothing, but it will wait until the master indexer has finished):

# update-apt-xapian-index -q

This way, the advanced package manager (adept 3 does this) will show a progress indicator and correctly let the user know when indexing has finished... only, if an update is already running, the progress indicator will not start at 0% because the update was already in progress, and the user will think: "wow, I've been lucky!". The server side of the socket only uses nonblocking I/O, so there's no risk of slave indexers causing the master indexer to hang. It's been simple to implement, and brillant. It is in apt-xapian-index 0.15, which I have just uploaded to sid. Shame it's a bit late for lenny.

I’m the happy owner of a nice geeky toy: a Suunto X6HR watch, that includes an altimeter and an heart rate monitor, which I use mainly for moutain biking and hiking. During outings, the watch can log the altitude and heart rate every 2, 10 or 60 seconds, and the data can be transfered to a PC using a serial interface. The problem is that Suunto only provides software for Windows. I got tired of using virtualbox to connect to the watch (qemu doesn’t work, Suunto Activity Manager apparently does strange things with the serial port), so I reverse-engineered the protocol (using skimanager and J rome Kieffer’s work as a basis) and implemented a script to fetch the logs, and export them in a format suitable for gnuplot. Of course, Suuntux is publicly available. I’d be happy to hear from you if it works for you too. Also, if you own a Suunto X6 (similar watch, without HRM), I’d be interested in supporting it too (if it’s not supported already). Below is a example graph, from a short mountain bike ride just before leaving for Debconf.

I have just configured IPVS on a Xen server for load balancing between multiple virtual hosts. The benefit is not load balancing but management. With two virtual machines providing a service I can gracefully shut one down for maintenance and have the other take the load. When there are two machines providing a service a load balancing configuration is much better than a hot-spare, one reason is the fact that there may be application scaling issues that prevent one machine with twice the resources from giving as much performance as two smaller machines. Another is the fact that if you have a machine configured but never used there will always be some doubt as to whether it would work… The first thing to do is to assign the IP address of the service to the front-end machine so that other machines on the segment (IE routers) will be able to send data to it. If the address for the service is 10.0.0.5 then the command “ip addr add dev eth0 10.0.0.5/24 broadcast +” will make it a secondary address on the eth0 interface. On a Debian system you would add the line “up ip addr add dev eth0 10.0.0.5/24 broadcast + true” to the appropriate section of /etc/network/interfaces, for a Red Hat system it seems that /etc/rc.local is the best place for it. I expect that it would be possible to merely advertise the IP address via ARP without adding it to the interface, but the ability to ping the IPVS server on the service address seems useful and there seems no benefit in not assigning the address. There are three methods used by IPVS for forwarding packets, gatewaying/routing (the default), IPIP encapsulation (tunneling), and masquerading. The gatewaying/routing method requires the back-end server to respond to requests on the service address. That would mean assigning the address to the back-end server without advertising it via ARP (which seems likely to have some issues for managing the system). The IPIP encapsulation method requires setting up IPIP which seemed like it would be excessively difficult (although maybe not more than required to set up masquerading). The masquerading option (which I initially chose) rewrites the packets to have the IP address of the real server. So for example if the service address is 10.0.0.5 and the back-end server has the address 10.0.1.5 then it will see packets addresses to 10.0.1.5. A benefit of masquerading is that it allows you to use different ports, so for example you could have a non-virtualised mail server listening on port 25 and a back-end server for a virtual service listening on port 26. While there is no practical limit to the number of private IP addresses that you might use it seems easier to manage servers listening on different ports with the same IP address - and there is the issue of server programs that are not written to support binding to an IP address. ipvsadm -A -t 10.0.0.5:25 -s lblc -p
ipvsadm -a -t 10.0.0.5:25 -r 10.0.1.5 -m The above two commands create an IPVS configuration that listens on port 25 of IP address 10.0.0.5 and then masquerades connections to 10.0.1.5 on port 25 (the default is to use the same port). Now the problem is in getting the packets to return via the IPVS server. If the IPVS server happens to be your default gateway then it’s not a problem and it will already be working after the above two commands (if a service is listening on 10.0.1.5 port 25). If the IPVS server is not the default gateway and you have only one IP address on the back-end server then this will require using netfilter to mark the packets and then route based on the packet matching. Marking via netfilter also seems to be the only well documented way of doing similar things. I spent some time working on this and didn’t get it working. However having multiple IP addresses per server is a recommended practice anyway (a back-end interface for communication between servers as well as a front-end interface for public data). ip rule add from 10.0.1.5 table 1
ip route add default via 10.0.0.1 table 1 I use the above two commands to set up a new routing table for the data for the virtual service. The first line causes any packets from 10.0.1.5 to be sent to routing table 1 (I currently have a rough plan to have table numbers match ethernet device numbers, the data in question is going out device eth1). The second line adds a default router to table 1 which sends all packets to 10.0.0.1 (the private IP address of the IPVS server). Then it SHOULD all be working, but in the network that I’m using (RHEL4 DomU and RHEL5 Dom0 and IPVS) it doesn’t. For some reason the data packets from the DomU are not seen as part of the same TCP stream (both in Net Filter connection tracking and by the TCP code in the kernel). So I get an established connection (3 way handshake completed) but no data transfer. The server sends the SMTP greeting repeatedly but nothing is received. At this stage I’m not sure whether there is something missing in my configuration or whether there’s a bug in IPVS. I would be happy to send tcpdump output to anyone who wants to try and figure it out. My next attempt at this was via routing. I removed the “-m” option from the ipvsadm command and added the service IP address to the back-end with the command “ifconfig lo:0 10.0.0.5 netmask 255.255.255.255” and configured the mail server to bind to port 25 on address 10.0.0.5. Success at last! Now I just have to get Piranha working to remove back-end servers from the list when they fail. Update: It’s quite important that when adding a single IP address to device lo:0 you use a netmask of 255.255.255.255. If you use the same netmask as the front-end device (which would seem like a reasonable thing to do) then (with RHEL4 kernels at least) you get proxy ARPs by default. For example you used netmask 255.255.255.0 to add address 10.0.0.5 to device lo:0 then on device eth0 the machine will start answering ARP requests for 10.0.0.6 etc. Havoc then ensues.

Share This

As mentioned elsewhere, LSB 4 is due out soon, and won’t really make a lick of difference when it comes to improving compatibility with non RPM/redhat-like systems. With software appliances and software as a service becoming more relevant, and appliance-oriented non-RPM distributions like rPath, Ubuntu JeOS and Defusion coming around that offer equal (or arguably better) value to customized Fedora/RHEL/CentOS and improved administrative ability due to using tools not stuck in the 1990s (RPM, I am looking at you here), one would think that the LSB working group might actually want to make LSB not suck. Right now, Debian derivitives like Ubuntu JeOS and Defusion can compete by using alien, and rPath has the RPMPackageRecipe for conary, but these are kludges and carry their own share of problems. So, why does the LSB require a specific format? There’s no reason for them to. Really, LSB compliance is a redhat-only club. Not just an RPM-only club… last time I checked, SuSE is in the same boat as everyone else and they use RPMs. A lot of the LSB needs to simply be ripped out in order to do any good. Until the LSB working group is willing to drop a lot of the RedHat-isms they have had, non-RedHat distros will always have problems complying. What about source-based distros like Gentoo for example? There is really no easy way they can comply by default (on the other hand, do they care to?). To put things simply, the LSB sucks. Here’s why:

• The LSB spec depends on RPM. I mean, come on. Seriously. Why do they need to require a specific package manager? If package handling is really required, then why not create a simple package format that can be converted on demand into the system package format? Or why care about packages at all?
• The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that’s not as bad as depending on RPM or requiring a specific layout.

Ideally, the LSB spec would define a config format capable of describing how the system worked, and all of that, but it doesn’t. Until it does, then the LSB spec is worthless, because it can’t handle all distributions (even the common ones).

Hi, it’s that time again: new alpha version of Adept hits the block. For the unaware, Adept is an APT front-end for KDE. You can do all the cool stuff with it that the other kids can’t. Join the fun! New features since Alpha 5 (the list is a little less staggering than the last time, sorry about that, but it’s only been a week)

• Tags are back! Enhance your searches with tags. Very cloudy, very buzzword-compliant, so very web two-oh. It actually works, too! (No irony intended. Maybe…)
• Status-based filtering,
• improved search in installer,
• much better error handling for dpkg and download errors,
• lost icons are back and a load of other bugfixes.

Where to get I have again prepared binary packages, this time even more of them (a Hardy backport is included). Traditionally, in Debian, you can install alpha 6 from experimental:

apt-get install -t experimental adept

The sources.list goes:

deb http://ftp.debian.org/debian experimental main

If you are on Kubuntu Intrepid, the line is:

deb http://ppa.launchpad.net/mornfall/ubuntu intrepid main

and finally, on Kubuntu Hardy, the lines are (BUT: read below!)

deb http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu hardy main
deb http://ppa.launchpad.net/mornfall/ubuntu hardy main

Big fat warning: Due to somewhat unexpected difficulties, Adept requires newer APT than available in Hardy. This means, adding the above sources.list lines will upgrade your apt to a version from Intrepid, that’s also completely untested on anything resembling a Hardy installation. Be wary. Moreover, installing Adept means means KDE 4.1 for Hardy users. (This does not apply to Intrepid users, they are already on the cutting edge and no extra dangers lie this way.) (For all Kubuntu users, there are more instructions to be found on https://launchpad.net/~mornfall/+archive.) Heroes of Alpha 6 I hereby nominate the “Heroes of Alpha 6”, for their deeds that helped Adept move forward:

• Yuriy Kozlov, for early pre-release testing and numerous patch contributions throughout the 3.0 alpha series
• Jonathan Thomas (JontheEchidna), for discovering two bugs:
  • failed downloads resulted in a cryptic internal errors
  • an installer crash when using the search
• Samuel James Sarette (lunarcloud), for discovering that you could start apply changes twice in a row, by switching back to changes and hitting apply again (not surprisingly screwing up Adept)
• and finally, Jonathan Riddell, as there’d be no 3.0 alpha series without him…

(And a totally flirtless wink towards Blauzahl, who somehow inspired me to actually do some bugzilla sorting…) And now, it’s easy to join the ranks of these heroes — just test the new alpha version and find bugs. Immortality won’t escape your grasp. Also, please don’t forget to read the next section. Jobs for Alpha 6 Sorting through Launchpad for bugs that have been fixed in alpha 6 (compared to 2.1) would be really awesome. It is a big list and many of them are likely to need testing. (I can take care of that for the KDE bugzilla, but launchpad is a task just too daunting for me and my time possibilities, so help would be very much appreciated). Notifier is still not included. The components to test are (if you have sudo, kdesu for the rest):

sudo adept
sudo adept installer
sudo adept updater

Please give a go to all of them, report rough edges, crashes and all that, either through IRC (mornfall at freenode, oftc) or mail me-at-mornfall-dot-net or use KDE Bugzilla. Known Issues

• Sometimes, it seems that the installer search manages to break the layout. Change the search text and try again, it might fix itself. If you find a way to reproduce, please let me know!
• The installer search is still a little wonky at times (and maybe slow, dunno). And when there are no results, it keeps whatever groups there were before, they are just all empty. Oops.
• Icons fail to load on Kubuntu Hardy.
• Search seems to crash Adept just after installation on Hardy (could be related to xapian database update). Starting it again seems to help though. UPDATE: this does happen on other distributions as well. You run into the problem if you don’t have apt-xapian-index installed, you install it together with adept and then run adept right away. Then you get a crash on first search. Just restart adept and all should work just fine.
• UPDATE: When recovery fails, Adept will crash instead of reporting the error and closing gracefully. Run dpkg —configure -a.
• UPDATE: Don’t run adept through kdesudo on Kubuntu. It seems to cause mysterious issues with dpkg (and especially hal upgrades). No insight so far as to what is the problem.

One of the things of getting too much mail is that you will get swamped in it, sometimes to the level of not even managing to figure out there's been replies on your blog for the past several weeks. Oops. Apparently quite a number of people answered to my blog post about the belgian government issues, and I only found out right before leaving for Argentina. They're now all accepted from moderation, but that doesn't mean I can't follow up on them anymore. Most of them just agree with what I have to say, or posit another opinion (which is fine), but some clearly show a misunderstanding of what I was trying to say. So, since I don't want to appear as one posting gibberish, allow me to clarify:

"I could say that some other things about the past deb cle also puzzle me, such as the insistence of some people to get an unconditional split of BHV, thereby destroying all chances of even remotely reaching a compromise." You are saying that you would accept giving in to the demands of the Francophones that the Flemish give up territory. (Think about it, what century are they from? In what other country does one community demand the enlargement of its territory as an exchange for fixing a situation which the constitutional court has ruled to be illegal?)

Thanks for asking, but no, I'm not saying that. Let's be clear about this: there's a huge difference between a position that says "we need to split BHV, period" on the one hand, and "we need to give territory to the francophone community" on the other. It should be perfectly possible to, say, have the flemish community come up with some benefit to the francophone community in some respect somewhere that does not include "giving territory to the south of france"; but apparently the "negotiators" think not. To quote just one example: at some point Reinders (MR) suggested that a federal election circle be created to replace BHV, so that francophone politicians could still be elected in flanders, but also the other way around. This proposal was however killed by flemish politicians before the press as "not even negotiable" without even having discussed it. This, and other similar examples, I do not understand. After all, the fact that the constitutional court has ruled the current situation to be illegal does not change anything about the fact that this is still a request from the Flemish part of the country, and not from the Francophones; anyone telling you anything else is simply lying. There's nothing wrong with wanting something and being declared correct in court, of course; but there is something wrong with wanting that unconditionally. Unless you won a war, that is. And then still. Of course, not caring about much of the definitions of many political parties and not being a politician in any way, I ticked off someone who just happens to be a member of one of the parties I don't even like in the first place. Amedee, in case it matters: I didn't call CD&V a "Catholic" party to imply anything, but simply because I'm blissfully ignorant of the difference between Catholic and Christian. And happily so, too, given the CD&V's current behaviour. Oh, and the SP.A is not my favourite party; it's just that they seemed to be the more sensible of the lot during the last elections' campaigns. What's really my favourite party isn't something I'll tell you (or anyone), though.

When installing Xen servers one issue that arises is how to assign MAC addresses. The Wikipedia page about MAC addresses [1] shows that all addresses that have the second least significant bit of the most significant byte set to 1 are “locally administered”. In practice people just use addresses starting with 02: for this purpose although any number congruent to two mod four used in the first octet would give the same result. I prefer to use 02: because it’s best known and therefore casual observers will be more likely to realise what is happening. Now if you have a Xen bridge that is private to one Dom0 (for communication between Xen DomU’s on the same host) or on a private network (a switch that connects servers owned by one organisation and not connected to machines owned by others) then it’s easy to just pick MAC addresses starting with 02: or 00:16:3e: (the range assigned to the Xen project). But if Xen servers run by other people are likely to be on the same network then there is a problem. Currently I’m setting up some Xen servers that have public and private networks. The private network will either be a local bridge (that doesn’t permit sending data out any Ethernet ports) or a bridge to an Ethernet port that is connected to a private switch, for that I am using MAC addresses starting with 02:. As far as I am aware there is no issue with machine A having a particular MAC address on one VLAN while machine B has the same MAC address on another VLAN. My strategy for dealing with the MAC addresses for the public network at the moment is to copy MAC addresses from machines that will never be in the same network. For example if I use the MAC addresses from Ethernet cards in a P3 desktop system running as a router in a small company in Australia then I can safely use them in a Xen server in a co-location center in the US (there’s no chance of someone taking the PCI ethernet cards from the machine in Australia and sending them to the US - and no-one sells servers that can use such cards anyway). Note that I only do this when I have root on the machine in question and where there is no doubt about who runs the machine, so there should not be any risk. Of course if someone from the ISP analyses the MAC addresses on their network it will look like they have some very old machines in their server room. ;) I wonder if there are any protocols that do anything nasty with MAC addresses. I know that IPv6 addresses can be based on the MAC address, but as long as the separate networks have separate IPv6 ranges that shouldn’t be a problem. I’m certainly not going to try bridging networks between Australia and the US! Another possible way of solving this issue would be to have the people who run a server room assign and manage MAC addresses. One way of doing this would be to specify a mapping of IP addresses to MAC addresses, EG you could have the first two bytes be 02:00: and the next four be the same as the IPv4 address assigned to the DomU in question. In the vast majority of server rooms I’ve encountered the number of public IP addresses has been greater than or equal to the number of MAC addresses with the only exception being corporate server rooms where everything runs on private IP address space (but there’s nothing wrong with 02:00:0a: as the prefix for a MAC address). I also wonder if anyone else is thinking about the potential for MAC collisions. I’ve got Xen servers in a couple of server rooms, I told the relevant people in writing of my precise plans (and was assigned extra IP addresses for all the DomUs) but never had anyone mention any scheme for assigning MAC addresses.

• [1] http://en.wikipedia.org/wiki/MAC_address

Share This