England swings like a pendulum do! There's another fuel price protest and the coverage in the London press is pretty biased, with occasional balanced reports and very rare dissenting opinion. One of the favourite whines on news-and-nutters phone-ins is "waah, I live in a village, I need my car". While that's true for some people, most villagers could switch to bicycles for many journeys without problems. At the moment, the biggest problem with cycling to town is the number of cars on the small lanes, followed by the number of potholes. Switching to cycling or walking will have a triple benefit: fewer cars on the road will free up space for cycling, wear the roads out less and reduce fuel demand (so petrol should become cheaper for those who really need it). Over the last few days, I've been happy to read Bike The Drive 2008 [Dirk Eddelbuettel], Mountainbike, By Joerg Jaspert and How to Start Bicycling to Work, by John Goerzen. A couple of tweaks to that last one: in England, I don't think that a cycling helmet is necessary. I've not worn one for the last few months (it went mouldy after a rain storm) - I find I can hear traffic better and many drivers seem to give me more room on the road. I wonder if helmet-wearing "dehumanises" cyclists to drivers? The safety data seems rather confused, but it's a personal choice. If you feel safer with a helmet, wear one. I also wear ordinary business or casual clothes, relying on a good quality commuter saddle rather than cycling shorts. I suspect that drivers here are developing a sort of blindness to the "screaming yellow" hi-vis jackets, so I don't wear those - but sometimes I wear hi-vis reflective armbands if I'm wearing black in the dark. I agree completely with the comments on that page about being predictable, Cateye lights and pannier bags. Finally, Bike Week 2008 starts on 14 June, which would be an ideal time to try a group ride - or just get a free breakfast for cycling into town.

Dear readers, What are currently the best websites to look for cheap flights? liligo.fr is OK, but doesn’t allow to specify “this date is flexible”, and the listing of the results doesn’t provide a lot of info.

A few months back, keithp introduced me to Treehouse/Icehouse as a generic system for gaming, like playing cards. Recently I realized that I didn't actually know many card games, and most of those that I did know I'd forgotten long ago. So today I spent a good chunk of the afternoon learning a few new games and playing them. John McLeod's site was the first hit I found on Google, and it's a phenomenal resource full of games from all over the world. The games that I learned or re-learned today were Casino, 500 Rum (which is a Rummy/Gin Rummy variant), and German Whist.

It's striking how many games are generally unknown these days. We have so many other forms of entertainment available that we've collectively forgotten how to play most of these games. It's fun to be reminded what you can do with a simple deck or two of cards though.

[Non-Debian and even non-IT related post ahead, in case you want to skip them] Since some time I try to regularly take some time off of the PC and actually use my bike again. (Those pictures are old, some things have changed since then. Like, I have a different, larger, set of brakes now). After a break of more than a year (more like 1.5 - 2 years, I think), it was a pain. The first few rides haven’t been much fun, and after some 10 til 15km I was exhausted and felt bad. But now, where I found a semi-regular schedule and do the torture two or three times a week I actually feel better. And get away with longer rides. A few days after I started I bought myself a nice “Bicycle computer”, a Garmin Edge 305 - “Garmin’s GPS-enabled personal trainer and cycle computer.” Im not doing any kind of special training with it, but its still nice to see heartrate, pedal cadence and all the other information it offers (which is a lot). And to see how you improve over time. Still, my main motivation to carry it with me is really to be able to see where I went (I only made some of my entries public :) ). And maybe, at some time, somewhere, load waypoints to it and then follow those. The included GPS chip is pretty good, keeping a good signal accuracy even in terrain where you just wouldn’t expect it to have any signal. Now, if google maps would have recent images, not ones that are years old, some tracks wouldn’t look that weird. On other news - I’ve lost 10kg weight since February. Damnit. Update: If you are from (around) Fulda and also like that OpenStreetMap thing, Enrico just uploaded my tracks there. Now it needs someone doing the post-processing to make them useful, and Enrico says you should go here and have fun. So if you have time, know the roads, feel free to look there. I guess Enrico keeps uploading new tracks from me, whenever there are some. Comments: 2

LDAP user database errors In case your machine uses an external LDAP server for the user database, and you see this error:

id: ldap-nss.c:1376: do_init: Assertion  cfg->ldc_uris[__session.ls_current_uri] != ((void *)0)' failed.

The solution is to check that you have no passwords in /etc/libnss-ldap.conf and make it world readable, because software needs to access it in order to access the user database. This is apparently "normal" folk knowledge. Already in the BTS. Now, why is /etc/libnss-ldap.conf not world readable by default? Because a debconf question offers it to be that way. Why does it do so? I have no idea, since passwords should go in the not world readable /etc/libnss-ldap.secret anyway. Why do we get that assertion instead of something like cannot read /etc/libnss-ldap.conf? These sort of obscure errors or behaviours happen so often that I start to believe it's an intentional coding style. Maybe LDAP needs to be something for lite sysadmins with a painful initiation path, so that only the Worth and Pure of Spirit can use the only sane way to have a central user database in Linux. I almost feel like if I disclose these tricky bits one day I will be tied to a rock with an eagle eating my liver.

A small memo in case it happens again… Maybe this can also help others… I have made a typing error when incrementing a zone serial number this morning (I though we were in year 2009!). I realized this error after the transfer was made to my secondary server, and I couldn’t figure out how I could fix this: if the serial number on the slave server is lower than the serial number on the master, the slave server will attempt to update its copy of the zone. I have read some websites explaining one should add 2147483647 (2^31-1) to the number, reload the zone, let the slave get updated and revert to the appropriate serial number. Unfortunately, this solution hasn’t worked for me. I have read in RFC 1912 (section 2.2 - SOA records), that the system was planned until year 4294. I have henced updated the number of my master server to year 4294123199 (ie. the last possible serial number), reloaded the zone. After the transfer was propagated to the slave, I could simply revert to a standard serial number.

Last weekend I was at FOSSCamp. Since I live in Prague I wanted to go to Ubuntu Developer Summit (UDS) each day, but unfortunately I had some exams, so I only went on Wednesday and Friday.

On Wednesday I first met Lars Wirzenius:


we agreed to go to pub in the evening. Then I did a little work, there was quite a nice view from the window (Prague castle on the horizon):



and I went to the #ubuntu-devel-summit IRC channel and pinged Scott Kitterman, whom I new from the Debian Python Modules Team (DPMT), but didn't know how he looks like. We met and once I knew Scott, it was easy to get around, so he introduced me to Steve Langasek (pronounced Lang ek). We agreed to go to pub as well. Steve lives in Portland, OR, where I spent the summer 2005 and Scott is from Baltimore where I spent the summer 2006.
Then I also met Riku Voipio, Martin B hm, Christian Reis (whom I asked if it's possible to support Debian unstable on Ubuntu Personal Package Archives and he said that it will probably happen, so that's really cool -- I also offered my help with this) and others, so in the end, there were 14 of us going to the pub, so I chose again the same pub as with the FOSSCamp people and it seems it tasted good again:




Notice the sv kov na smetan above, my favourite meal. Good choice Scott. :)





Ok, that was on Wednesday. On Friday I arrived at around 3pm, looked at the schedule table and noticed that Matthias Klose should be at UDS too, so I started IRC and pinged him. Fortunately, Emilio Pozuelo Monfort, whom I know from DPMT as well, replied first so we met, it was cool and he showed where Matthias is. I am very glad I met him, so we discussed python-central and python-support packages and why we have them both, also with Scott later on.

When I was waiting for Matthias, I sat next to Nicolas Valc rcel, started my laptop and begun looking at some SymPy bugs and Nicolas noticed that and said -- "You are developing SymPy?", I said "Yes.", flattered. And he showed me a bug with plotting and Compiz, so we immediately reported that to pyglet.

In the evening people continued to some kind of a party, but unfortunately, I was already going to some other pub.

Overall, even though I was there for only two afternoons, it was just awesome and I utterly enjoyed meeting all the people I knew from mailinglists and IRC.

Yesterday, I wrote about bicycling to work, pointing out that it's a safe, inexpensive, way for many people (including office workers without access to showers) to get to work. There were a lot of thoughtful comments there too.

Today I'd like to provide some tips for getting started commuting on a bicycle. As I'm just getting started on this, these are mainly things I've learned from poking around online, so I'll be including lots of links.

The Bicycle

This varies from person to person, but as a general rule: if you have a very short ride -- say a mile or less -- you can probably just use any old bike and a bicycling helmet. Don't try to use a motorcycle helmet. It won't vent your head, so you could overheat. Also, it won't be comfortable.

Most people will have a longer ride and will want to get a bike that works specifically for them. Each model of bicycle comes in different frame sizes. It's important to get a bicycle that is the right size for you. Also, you'll want to get a quality bicycle that will let you be fast and won't break down along the way.

For all these reasons, I -- and every single other person I've ever seen talk about this -- highly recommend that you buy your bicycle from a bicycle shop. Don't buy a bicycle from a "big box" store like Walmart or Target. They may be cheaper up front, but you'll pay for it in the long run because they won't last as long, won't fit you as well, and may even be unsafe. Bike shop staff will help you find a bike that fits you, which is important for avoiding aches and pains and even injury. They'll be able to help you find appropriate accessories for your bike, as well as repair it. Here is a helpful article on this topic, written by a bike shop.

Generally speaking, bike shops can repair bikes bought at any other bike shops. However, they can instantly recognize bikes bought at big box stores. Many will repair those too, but some refuse to work on some of those bikes on the grounds that it is impossible to bring them to the level of service they expect their mechanics to do.

Aches and Pains

With any sport, when you start it, you can expect a little bit of aches and pains at first, as you start using muscles that you may not have really used at first. Bicycling is no exception, but it's easy to deal with.

Your first stop if you have aches and pains might be the where does it hurt page. It provides detailed, helpful advice. There are also some common things that go wrong for people.

First on the list is wrong size of bike or improper adjustment of your bike. You want a bike frame that is the right size for you, and you want the seat and handlebars adjusted properly for you. A bike shop can help you get this done easily. If your feet can reach the ground while you're on the seat, you almost certainly have the seat too low, which is a common mistake.

Sometimes the way you position yourself on the bike, or your technique, could be to blame.

Also, clothing can be a problem. A good place to start here is with some cycling shorts. Another common complaint from new cyclists appears to be blisters on the feet. This can be caused by improper positioning on the pedals, or by using the wrong type of sock. Typical socks absorb moisture and trap it next to the skin; bicycling socks will wick it away and let it evaporate. In fact, cycling clothes: socks, shorts, and jerseys (shirts) are all designed to wick moisture away from you and let it evaporate, which keeps you cooler and more comfortable. Bicycling gloves are cheap and can help your hands stay comfortable.

Expense

You can easily save thousands of dollars by riding a bicycle instead of driving a car. Bicycles do need periodic maintenance, just like a car. Usually you can do a lot of that yourself. It probably will pay off to take your bike in to the shop for an annual tuneup. If you have no bicycling equipment at all, and buy your equipment at a bike shop new, you can probably get started for around $500. Even that will probably pay for itself in less than a year if you average riding your bike at least a few times a week.

Safety

Safety on a bicycle can usually be summed up with three rules: be visible, be predictable, and ride with traffic.

Unless there are dedicated bicycle-only lanes or paths, the safest way (in the United States) to ride your bike is on the road, riding with traffic (acting like a car). Don't ride on a sidewalk, and never ride against traffic. This may sound counter-intuitive, but it is backed up by solid research. It all has to do with being predictable. Nobody is looking for something the speed of a bicycle to emerge from a sidewalk to cross a road or driveway. Sidewalks often aren't that visible and frequently don't provide enough room to pass. Sidewalk-riding cyclists get into accidents all the time with cars backing pulling out of driveways, making turns, or even just driving down a road where the cyclist cuts in front of them to cross a street.

A great book for learning how to ride in traffic can be viewed free online: the Bicycling Street Smarts book. There are also some safety videos online that are helpful.

Staying visible is certainly important. In some places, like cities where cyclists are common, drivers are going to be on the lookout for you already. In my case, I'm riding on rural roads that have some hills, where cyclists are rare, so I'm putting extra effort into this.

Staying visible in the day or at night starts with high-visibility clothing. A "screaming yellow" jersey or an ANSI safety reflective vest (less than $10) are good ways to do that. Several people recommend a Cateye TL-LD1100 flashing tail light for use at night, or even for daytime use when visibility is critical (such as my situation). If you will ever ride at night, laws require you to have the proper reflectors on your bike. And, you must also have a white headlight that does not cover up your front reflector (in some locations, you may also be required to have a red tail light that doesn't cover up your reflector). Companies like Cateye carry those products as well.

Other tips: avoid drainage covers; they sometimes have slats that a bicycle tire could fall into.

Accessories

Here are some suggestions you might consider as a commuter.

Start with pannier bags. They mount over your rear tire and are cooler for you than a backpack because your back can still breathe. They're more aerodynamic than a front basket. You can get bags suitable for carrying papers, laptops, a change of clothes, etc.

Next on your list might be a bicycle lock, to help keep it from being stolen. Your local bike shop can make suggestions here.

You might want to consider a spare inner tube (about $5) and tire-changing tools (also about $5) to carry with you in your bag. You wouldn't want to have to walk 5 miles if you get a flat.

Along with that goes an air pump. I suggest a frame pump -- it's a small pump that can clip on to your bicycle's frame, so you always have it handy. Obviously you will need this if you have to change a tube, but it could be handy even if you don't.

You can find some more suggestions from bicycling.about.com and from Mike or your local bike shop.

Where to buy

Besides your local bike shop, you can buy a lot of accessories online. I wouldn't suggest buying a bicycle online, because you really want to get a good fit at a bike shop.

When I asked at bikeforums.net, readers suggested three online stores:

www.pricepoint.com
www.bikenashbar.com
www.performancebike.com

You can also find some bicycling accessories at general-purpose stores like Amazon or sporting goods stores like REI. I personally wouldn't recommend local "big box" sporting goods stores any more than I would Walmart or Target for this stuff, though.

More info

For more information, check out my bicycling links at del.icio.us.

Last week-end, I was in Prague for FOSSCAMP, a Canonical-sponsor event aiming at bringing together people from various Free Software projects. Such an event is a very good idea, especially after the openssl debacle, where we saw how difficult it is to build good relationships with other Free Software projects. The event was organized in a rather interesting way: the attendees make up the schedule as the event happens, by adding sessions to the timetable using marker pens on a whiteboard (see picture, hi Jorge!). If we have a spare BOF room at Debconf, it would be great to do the same thing: I always find it frustrating that many important discussions at Debconf happen outside BOFs/lectures, and are so easy to miss, simply because you submit talk proposals months before Debconf, so you can’t know yet what will be the hot stuff when Debconf finally arrives :-) It was also interesting to see all the different ways people organized BOFs. It might be interesting to write a list of DOes and DON’T about BOFs (not that the sessions weren’t of good quality!). Does anyone know if such a list already exist? And finally, as usual, it was great to meet all those people from this nice community again. If you still believe that some projects are fighting with each other, you need to attend such an event. And special thanks go to Ond ej ert k for guiding me through a visit of Prague!

Matt Bottrell has written about some issues related to the acceptable weight of laptops for school use [1]. Matt cites a reference from the Victorian government stating that a school bag should not be heavier than 10% of the body weight of the child who carries it [2]. So the next thing we need to do is to calculate what a student can carry without being at risk of spinal injuries. Firstly we need to determine what children weigh, if we restrict this to the 14+ age range (the older children have more need of computers) then children are almost as heavy as they will be when they are 18 and can carry significantly heavier bags than those in the 10+ age range. Also it seems reasonable to consider the 25th percentile weight (the weight which is exceeded by 75% of children). Of course this means that 25% would be carrying overly heavy bags but it does give us a bit more weight allowance. The 25th percentile weight for white girls in the US is 48Kg [3]. The 25th percentile weight for white boys in the US is also 48Kg [4]. When considering the Australian situation it seems that white children in the US will be most similar (in terms of genetics and diet). The 25th percentile weights at age 18 are 53Kg for girls and 64Kg for boys. So the acceptable bag weights would be 4.8Kg for 14yos, 5.3Kg for 18yo girls, and 6.4Kg for 18yo boys. The next step is to determine the weight carried to school. The weight of one of my laptop bags is almost 1Kg, I think that a school-bag would have a similar weight. When I was at school I recall that the worst days for carrying baggage were when I had PE (Physical Education - sports), the weight of PE gear was a significant portion of the overall weight I carried. I tried to estimate this by weighing a track-suit top, a t-shirt, and a pair of board-shorts (the only shorts I could find at short notice), and it was almost 1Kg. While the board-shorts might weigh more than PE uniform shorts I didn’t include the weight of track-suit pants. Assuming that a female PE uniform has the same weight as a male uniform is the least of my assumptions. The weight of a good pair of sneakers (suitable for playing basketball and other school sports) that is in my size is just over 1Kg. To get a rough estimate of the weight of lunch I put six slices of bread and a small apple in a lunch box and found that it weighed 500g. A real lunch would probably include four slices of bread but the other things would weigh at least as much as the extra two slices. If a drink was included then it could be more than 500g. So the total is 3.5Kg for bare essentials (including PE gear) without including any books! It seems that it would be impossible to stick to the government recommendations for school bag weight if a full set of PE gear is included. Probably the best thing that could be done would be to make a school uniform allow wearing sneakers which removes 1Kg from the overall bag weight. So a bag with lunch and PE gear (minus sneakers) is about 2.5Kg, leaving 2.3Kg for books etc at age 14. As text books for 14yo children are considerably thinner than those for 18yo children, it seems that this might be achievable. Fitting a couple of text books and an EeePC into the 2.3Kg weight budget should be achievable. But fitting a full size laptop (which seems to start at about 1.8Kg) and some text books into a 2.3Kg budget will be a challenge - it might be possible to do that but wouldn’t leave any budget for the random junk that children tend to carry around. For an 18yo girl, the weight budget (after the basics have been deducted) is 2.8Kg, it seems likely that on occasion the weight of year-12 text books will exceed that. Therefore it seems that the only way of avoiding spinal injuries in year-12 girls would be to have text books stored in digital form on a light laptop such as an EeePC. Rather than avoiding the use of laptops because of weight (as some people suggest), laptops with electronic text books should be used to replace traditional text books! An EeePC weighing less than 1Kg will give a significant amount of extra capacity for any other things that need to be carried. If there is little other stuff to be carried then 75% of 18yo girls should be able to carry a full size laptop plus PE gear without risk of back injuries. If digital text books are used then if in any journey two text books (which according to my previous measurements can be as much as 1.6Kg [5]) can be replaced with an EeePC then overall something like 600g is saved (depending on the configuration of the EeePC, if one battery was stored at home and another at school then it could save more than that). It seems that a year 12 girl who has PE and three science subjects scheduled on the same day would be most likely to exceed the recommended weight in the current situation (even without having to carry a spare pair of shoes), and that carrying a laptop with digital text books would be the only way of avoiding back injury. For an 18yo boy the weight budget is 3.9Kg after the basics have been deducted. So if they don’t carry other random stuff in their bag (I probably had 1Kg of random junk in my bag on occasion) then they could carry PE gear, a full sized laptop, AND a full set of text books. It seems to me that there is no situation where children would be unable to have a laptop within the reasonable weight allowance if digital text books were used. The only way that the weight of a laptop could be a problem would be if it was carried in addition to all the text books. One final point, it would be good if books from the Gutenberg project were used for studying English literature, that’s one easy way of reducing weight (and cost). Also it would be good if there was an option for a non-literature based English subject. Knowledge of English literature is of no value to most students. It would be better to teach students how to write while using topics that interest them. Maybe have blogging as an English project. ;)

• [1] http://matt.bottrell.com.au/archives/155-Laptop-clarifications.html


• [2] http://www.betterhealth.vic.gov.au/bhcv2/bhcarticles.nsf/pages/Back_pain_schoolbags?open


• [3] http://www.halls.md/on/girls-weight-w.htm


• [4] http://www.halls.md/chart/boys-weight-w.htm


• [5] http://etbe.coker.com.au/2008/02/18/laptop-vs-book-weight/

Share This

foosel tagged me, whatever that means. Perhaps it’s the English word for “Stöckchen” (German for “small stick”) of which I always wondered how the English blogging part of the blogosphere is calling that kind of coercing blog posts… ;-) So these are the rules:

1. blog a list with your favorite desktop Linux software (as many or few you want)
2. add links to the software project’s websites
3. post these rules
4. tag three other Linux using bloggers

Interestingly splitbrain, who started the thing just calls it “Meme”, but to me memes are the same thing just without duress. ;-) So you want to know about what Linux desktop software I like and use, hmm? Desktop means GUI, doesn’t it? There are only a few GUI application I really use often since, as you probably know, X is primarily a terminal multiplexer and screen resolutions are compared by how many 80×25 xterms with fixed font you can get on one screen without overlapping. ;-) But to be honest: Although I’m more the command line guy hacking cryptic lines into windows with small fonts, there are a few thing where I don’t want to miss X and the GUI applications: For all things web – that means web browser, feed reader, etc. But then there is also a bunch of GUI software I use occasionally or as alternative tool to some text mode or command line software. Web

• Liferea – My favuorite feed reader although it takes ages to start and since a few days also starts crashing, probably since I have configured it to cache up to 1000 items per feed and have subscribed to several hundred feeds. I do not read them all though, but I use them togther with Liferea’s “search all feeds” feature as a Google News replacement. ;-) I though read a lot of feeds in it, since I use it for news, blogs, webcomics and to read missed tweets on Twitter. It organizes the feeds in a tree structure so I can easily group different types of content together.
• Opera – I’m back using Opera as my primary web browser since they offer alpha versions for 64-bit Linux. Initally I started using Opera with version 3.60 on Windows 95 somewhere about 10 years ago and I’ve always come back to it when no current free browser fits my needs. Although it hasn’t an AddOn possibility as Firefox has, I still prefer it over the bloaty and leaky and quite unstable Firefox 2, since it offers nearly every functionality I need (mainly mouse gestures and a flexible tab management), is fast, needs less RAM and is quite stable for an alpha version. And Firefox only offers those features I need via Addons which are often the cause for leaking or crashing. Haven’t tested Firefox 3 yet, but it’s said to be be less bloaty…
• Kazehakase – Formerly I used kazehakase as my primary web browser since I really like its user interface, but the version in Etch is quite slow and seems to have memory leaks. It’s currently the second browser I have always open. But since my browsers always have uptimes in terms of months I don’t need web browsers that are leaking, so I’m thinking about replacing it with something more stable.
• Conkeror – A Gecko 1.9 (i.e. Firefox 3) based web browser completely controllable with the keyboard. And the key bindings are those from Emacs and partially also from the classic text-mode browser Lynx. Will be available in Debian Experimental soon.
• Netsurf looks very promising as it’s a simple and fast browser with it’s own rendering engine and originating on RISC OS. But since I’m a heavy tab user (60 tabs in one window are not really seldom), a browser (yet) without tabs isn’t really that useful for me. But I hope it will get tabs soon.
• Midori – The other upcoming new browser in the Linux world is using Apple’s WebKit (which itself is based on KDE’s KHTML) underneath. Only in Experimental yet (form a Debian point of view :-). Use it on my Debian Sid machine to play around with it.
• Twitux – A simple GTK Twitter client which doesn’t clutter the screen with unnecessary icons or buttons. Just a small menu bar, status bar and the tweets.
• Azureus – In the seldom case where I need to download files via Bittorrent I either use Opera’s builtin client or Azureus. The nice thing about Azureus is that you can get nice graphical as well as textual statistics about all aspects of your downloads.

X / Desktop Environment

• FVWM – My favourite window manager for normal, big or multiple screens. I use it since more than 10 years (twm and tvtwm were its predecessors) and its configuration has evolved since then quite a bit to tinted transparent window frames and title bars, etc. I tried other window managers in between (e.g. Sawfish and GNOME’s own Metacity, each for a month or so and both together GNOME, also played around with KDE on one machine) and I always came back to FVWM. No other window manager is so fast and configurable in regards of keybindings. Handles multiple screen very well and out of the box, too.
• ratpoison – My favourite window manager for small screens (less than about 1024×768, e.g. on my EeePC, on the 8” touchscreen connected to my MicroClient Jr. or on my 1996 ThinkPad 760ED with 133 MHz Pentium 1) since it doesn’t waste screen space for window borders or title bars. It just maximizes all windows by default to screen resolution. You then can manage (split, resize, switch, close, kill) windows as you are used to manage shells and text-mode applications with screen(1). Doesn’t work that well with multiple xrandr managed screens though if they don’t have the same size.
• FLWM – The Fast and Light Window Manager. My favourite low-end but still DAU compatible window manager. Use that on demo and guest accounts, especially on low end machines.
• Synergy – connects displays of other computers (not only X but also even Mac or Windows) with your mouse and keyboard similar to a KVM switch. I use it at work to add my laptop as fourth monitor. ;-)
• trayer – A desktop environmen independend system tray developed by the FVWM Crystal Project. Since I changed from manually editing /etc/network/interface on my laptop each time I came into a new wireless LAN to using GNOME’s Network Manager, I needed a system tray for the nm-applet. Trayer is quite easy to configure using command line options and can handle tinted transparency as I use with FVWM and ATerms. So it fits in perfectly.
• ratmenu and dmenu – For showing generated menus together with ratpoison, I use ratmenu (e.g. as replacement for ratpoison’s non-interactive window list) and dmenu (e.g. as application menu using my own wrapper which generates the menu from some config file). Probably will publish that code once it proved itself stable.

xtrlock – the simplest tool to lock you desktop: The mouse turns into a lock and it only goes away if you enter the right password. No screen saver included though and everyone can see what’s on your desk. I like it though. Use it on low-end machines.

XScreenSaver and Really Slick Screensavers (GLX Port) – Configurable and command controllable screen saver daemon. Favourite modes: GLMatrix and Substrate from XScreenSaver and Lattice Sky Rocket and Hufo’s Smoke from RSS GLX.

xosview – my favourite system monitor since more than a decade.

Terminals

• xterm – there is no better X terminal emulator than the original xterm. I found no other terminal which is so fast, has no problems with text-mode applications (aterms break aptitude’s display), no problems with character set encodings, which can be embedded into other applications and which has a fully working classic Unix cut & paste.
• aterm – When I need a fancy transparent terminal for showing a fancy desktop, I use the AfterStep Terminal Emulator aterm. In that case, the system tray, the window borders, the window’s title bar and the terminal on my desktop have the same fancy tinted transparency.
• yeahconsole – A wrapper around xterm which works like the pulldown console in quake. Good for the short shell usage inbetween. ;-) The other similar pull down consoles I know (KDEish yakuake and GNOMEish tilda) had some issues with focus and keybindings while yeahconsole works just out of the box and showed no problems until now.

Audio and Video

• XMMS and Audacious – If I want to play a single list of files of the same file format or single stream, I usually use the command line tools mpg123 and ogg123. But if I need anything more fancy or more flexible, I prefer the WinAMP clones. Formerly XMMS, nowadays Audacious. Both with some old skin which I use since more than a decade and which I initially used with WinAMP 2 on Windows 95.
• mplayer – no fancy GUI, easily controllable with the keyboard, plays most video file formats I can remember. ;-)

Editing and Developing

• GNU Emacs – I’ve been raised with GNU Emacs and Lisp at university, so I’m quite sticked to that. I usually only start one Emacs instance and connect to it using emacsclient. I also like TRAMP for editing remote files. but I don’t need it that often. On machines, where I don’t want a full blown Emacs installation or under root I prefer GNU Emacs’ little brother GNU Zile (Zile Is a Lossy Emacs), but that’s text-mode and no GUI software.
• OpenOffice.org – I think it’s a really great software, but I use it quite seldom, usually only when I have to open some file in a Microsoft file format. For writing letters, articles, presentations and so I have LaTeX.
• Gnumeric – My preferred spreadsheet application. Although for some purposes I use the OpenOffice.org spreadsheet, usually when Gnumeric has not all necessary features.

Graphics

• xv – Yet another tool I use since more than a decade: No other image viewer is so fast and yet so easy to use with both keyboard and mouse. Open source, but unfortunately not (yet?) free software.
• keyjnote – fancy PDF presenter with a lot of interactive features.
• pdfcube – PDF presenter turning pages as a cube as compiz or Macs do with the desktop.

Chat

• Pidgin – I usually use irssi inside a screen for IRC as well as Jabber and ICQ (via Bitlbee), but I also often have a local Jabber client running which then is Pidgin (formerly known as GAIM).

Other Tools

• Unison – I use it to synchonise the cache and state of my feed reader between laptop and workstation. And I do indeed prefer the GUI version over the text-mode version. I use the text-mode only if I use it from some remote location.
• XKeyCaps – The ideal tool to wreck you keyboard layout. ;-)
• XGnokii – Used it to backup my former Nokia mobile phones, the 6130, the 6210i and the 6310i. Doesn’t work anymore with my new E51, though.
• Sunbird / Iceowl – Not really using it yet, but I plan to use it as my primary calendar tool.
• QEMU / KVM / KQEMU – My favourite desktop hardware emulator. (For servers, I prefer Xen for virtualization.)

Games

• ScummVM
• Planet Penguin Racer / Extreme Tux Racer (all forks of Tux Racer)
• Frozen Bubble
• Battle for Wesnoth
• cuyo, xpuyopuyo, flobopuyo
• Sauerbraten
• PrBoom / Freedoom
• Neverball / Neverputt
• Briquolo
• xfrisk
• Icebreaker
• XBomb

Non-Desktop Applications In case someone wonders about my mail client, Jabber client, IRC client, ICQ client, file manager, notes taking application, shell and versioning system – they’re all command line or text-mode applications:

• E-Mail: mutt
• Chat, Instant Messaging: irssi + Bitlbee + GNU Screen
• File management: coreutils (and sometimes busybox ;-)
• Notes: hnb
• Shell: zsh
• Version control: Subversion (svn), Mercurial (hg)

Who’s next? That’s difficult:

• maol would be interesting, but since a while he just blogs in Jeopardy style, so he would need pack all those programs into the subject of his blog post… No, not a good idea.
• Venty! No, has no active blog anymore.
• Dieter! No, no Linux user.

Hmmm, I think I have to look in a different corner of my circle of friends. Hmm. Ah, now I know:

• dyfa – not really a Linux user, but I guess FreeBSD is ok, too. :-)
• nion – this will be really interesting. He even uses more strange software than I do. ;-)
• alphascorpii – no idea what she prefers (except that it will be available as Debian package ;-)

And no, I don’t expect posts as comprehensive as mine. :-)

Just got back a little earlier from running the 2008 edition of the JP Morgan Chase Corporate Challenge. And again a record crowd of now just over 23000 in Chicago -- announced to be bigger than those at the JP Morgan Chase races in Boston, San Francisco or New York! This year the weather wasn't quite as stunning as it has often been in the past. But at least, temparatures in the high 40s and an overcast sky make for good running conditions. This time, two colleagues and I tried to make it close enough to the starting line to not waste too much time 'surfing' around slower runners who for whatever reason think they have to be up at the front. And that seems to have worked: despite a still crowded start, I ran even, steady and fast enough to beat the PR from 2005 by a decent margin with a (hand-stopped) time of 20 minutes and 46.65 seconds. That yields 5:5619 min/mile (or for Christian, 3:4132 min/km) which seems too fast given the splits I saw at miles two and three. Oh well -- same cours as as the other five times that I've run this, so I trust the course is USATF certified. And as always, good to hang with folks from work for a cold one or two afterwards. Given the temperatures, I didn't last very long though.

I write most of my email (in gmail) and submit most web site content in English, however, a significant portion is also done in Italian. I leave the spell checker in English, because Italian is, in general, quite easy to spell, so that even as a native speaker, a helping hand is occasionally welcome. However, it isn't as if I write Italian perfectly either, so the help there would be nice as well. I find it quite annoying to go change the language in the spell checker option each time, especially when, as an example, I'm responding to email and do 2 in English, one in Italian, another in English, and so on. Ideally, some sort of adaptive technology would be possible, where it figures out what language I'm using, out of a preselected list, after a few words, and starts behaving accordingly. It seems as if there is some discussion, so hopefully a solution won't be too far in the future.

The first step is to copy /images/xen/vmlinuz and /images/xen/initrd.img from the Fedora (or RHEL or CentOS) DVD somewhere convenient, I use /boot/OS/ (where OS is the name of the image) but other locations will do. Now choose a suitable Ethernet MAC address for the interface (see my previous post on how I choose them [1]). Create a temporary block device for the install, I use /dev/VG0/OS-install (where OS is replaced by the name of the distribution, “f8” or “cent5“), it’s a logical volume in an LVM volume group named VG0. The device should be at least 2G in size for a basic Fedora install (512M for swap, 1G for files, and 512M free after the install). It is of course possible to use DOS partitions for the Xen block devices, but this would be unreasonably difficult to manage. An option for people who don’t like LVM would be to use files on an XFS filesystem (Ext3 performs poorly when creating and removing large files). When configuring Xen on Debian systems I generally use /dev/hda type device names. The device name seems quite arbitrary and /dev/hda is a familiar name for hard drives that many people have been used to for 15+ years. But the Fedora install process doesn’t like it and I’m forced to use /dev/xvda etc. I often install Fedora on a machine that only has 256M of RAM spare for the DomU. For recent versions of Fedora 256M of RAM is about the minimum for an install at the best of times, and a HTTP install takes even more because the root filesystem used for the install is copied via HTTP and stored in a RAM disk. It might be possible to use less RAM with a CD or DVD install or even a NFS install, but I couldn’t get CD/DVD installation working and I generally don’t give Xen DomU’s NFS access if I can avoid it. So I had to create a swap space (an attempt to do an install with 256M of RAM and no swap aborted when installing the kernel package). I expect that most serious use of Xen will have 256M of RAM or less for the DomU, part of the problem here is that Xen allocates RAM not virtual memory. VMWare allocates virtual memory so the total memory for virtual machines can be greater than physical RAM and thus this problem will be less common with VMWare. I believe that the best way of configuring virtual machine images is to have the virtual machine manager (Xen in this case) provide block devices to the virtual machine and have the virtual machine implement no partitioning (no LVM or anything equivalent). The main reason is that DOS partition tables and LVM configuration on a block device used by Xen can not be used easily in the host environment (the Dom0 for Xen). I am not aware of how to access DOS partition tables (although I’m sure it’s possible somehow) and while LVM can be used it’s a bad idea due to the fact that there is no way to deactivate a LVM volume group that is active, and the fact that there is no support for having multiple volume groups of the same name. The lack of support for multiple volume groups of the same name is a reasonable limitation, but an insurmountable problem when using a virtual machine environment. It’s quite reasonable to create several cloned instances of a virtual machine and renaming an LVM volume group would require more changes inside the virtual machine than you would want. Also using snap-shots of old versions of the virtual machine data is difficult if the same volume group name is used. So for ease of management I want to have filesystems on block devices (such as /dev/xvda) instead of partitions (such as /dev/xvda1). Unfortunately Anaconda (the Fedora installer) doesn’t support this. So I had to do the initial install with DOS partitions and then fix it afterwards. So use the manual option and create a primary partition for the root filesystem and then create a non-primary partition for swap (when using small amounts of RAM such as 256M) so that swap can be used during the install. The root filesystem needs to be at the start of the disk to make it easier to sort this out later. After installing Fedora and shutting the virtual machine down the next step is to copy the block device to the desired configuration (filesystem on an unpartitioned device). If the root filesystem is the first partition then the first 63 sectors will be the partition table and reserved space so dd can be used to copy the data with the following commands: dd if=/dev/VG0/OS-install of=/dev/VG0/OS bs=512 skip=63
e2fsck -f /dev/VG0/OS
resize2fs /dev/VG0/OS The next step is to mount the device /dev/VG0/OS in the Dom0 to change /etc/fstab, I use /dev/xvda for the root device and /dev/xvdb for swap. Now to remove the cruft:
Avahi is a network service discovery system, mainly used for laptops and isn’t needed on a server, it is installed by default on all recent Fedora, RHEL and CentOS releases but it is not useful in a DomU (any unused network service is a security risk if you don’t disable or remove it). Smartmontools is for detecting impending failure of a hard drive and does not do any good when using a virtual block device (you run it on the Dom0). It might be considered a bug that smartd doesn’t exit on startup when it sees a device such as /dev/xvda. The pcsc-lite package for managing smart cards is of no use to me and all the other people who don’t own readers for smart-cards, and it can therefore be removed. Bluetooth networking support (in the package bluez-utils) is also only usable in a Dom0 (AFAIK), and the only bluetooth device I own is my mobile phone so I can’t use it on my computer. The command “yum remove avahi smartmontools pcsc-lite bluez-utils” removes them. For almost all of my DomU’s I don’t use NFS or do any printing, so I remove the packages related to them. Also autofs is in most cases only useful for servers when mounting NFS filesystems. I remove them with the command “yum remove nfs-utils portmap cups autofs“. The GPM daemon (which supports cut/paste operations with a mouse on virtual consoles) is of no use on a Xen DomU, unfortunately the vim-enhanced package depends on it. I could just disable the daemon, but as I like to run small images I remove it with “yum remove gpm“. I may have to reinstall it on some images as some of my clients like the extra VIM functionality. It’s unfortunate that debootstrap doesn’t work on CentOS (and presumably Fedora) so installing a Debian DomU on a CentOS/Fedora Dom0 requires creating an image on a Debian machine or downloading an image from www.jailtime.org . Sample Xen Config for the install: kernel = “/boot/OS/vmlinuz”
ramdisk = “/boot/OS/initrd.img”
memory = 256
name = “OS”
vif = [ 'mac=00:16:3e:66:66:68, bridge=xenbr0' ]
disk = [ 'phy:/dev/VG0/OS-install,xvda,w' ]
extra=”askmethod text” Sample Xen Config for operation: kernel = “/boot/cent5/vmlinuz-2.6.18-53.el5xen”
ramdisk = “/boot/cent5/initrd-2.6.18-53.el5xen.img”
memory = 256
name = “cent5″
vif = [ 'mac=00:16:3e:66:66:68, bridge=xenbr0' ]
disk = [ 'phy:/dev/VG0/cent5,xvda,w', 'phy:/dev/VG0/cent5-swap,xvdb,w' ]
root = “/dev/xvda ro”

• [1] http://etbe.coker.com.au/2007/03/27/xen-and-eth-device-renaming/

Share This

I finally closed my cooperative's annual accounts for the year to 5 April 2008 yesterday. We wrote off one project (not bad for a year) and now we can start on the annual reports. For day-to-day entries, we're still using my simple scheme/web app called SQL-Journal and I should make a new release real soon now. I've added some features since 1.3 and there's a few more I want to add, but I'm no accountant, so it will remain simple and stupid, but good enough for me. Bristol Wireless's accountant has written some comments on GNUcash which is an interesting view: "not quite there yet" which could help finance software developers. Better searching is one thing I will add to SQL-Journal some time, but it will probably never have features like reporting (I either use an SQL-based report package or export to a spreadsheet) and I know it's no better at handling VAT, mainly because TTLLP isn't VAT-registered yet. I also spotted Finance software in Emdebian, by Neil Williams recently. I wonder if the bursts of accounting interest are connected to the end of the financial year?

The way Xen works is that the RAM used by a virtual machine is not swappable, so the only swapping that happens is to the swap device used by the virtual machine. I wondered whether I could improve swap performance by using a tmpfs for that swap space. The idea is that as only one out of several virtual machines might be using swap space, a tmpfs storage could cache the most recently used data and result in the virtual machine which is swapping heavily taking less time to complete the memory-hungry job. I decided to test this on Debian/Etch (both DomU and Dom0). Above is a graph of the time taken in seconds (on the Y axis) to complete the command “apt-get -y install psmisc openssh-client openssh-server linux-modules-2.6.18-5-xen-686 file less binutils strace ltrace bzip2 make m4 gcc g++“, while the X axis has the amount of RAM assigned to the DomU in megabytes. The four graphs are for using a real disk (in this case an LVM logical volume) and for using tmpfs with different amounts of RAM backing it. The numbers 128000, 196000, and 256000 and the numbers of kilobytes of RAM assigned to the Dom0 (which manages the tmpfs). As you can see it’s only below about 20M of RAM that tmpfs provides a benefit. I don’t know why it didn’t provide a benefit with larger amounts of RAM, below 48M the amount of time taken started increasing exponentially and I expected that there was the potential for a significant performance boost. After finding that the benefits for a single active DomU were not that great I did some tests with three DomU’s running the same APT command. With 16M of RAM and swap on the hard drive it took an average of 408 seconds, but with swap on the tmpfs it took an average of 373 seconds - an improvement of 8.5%. With 32M of RAM the times were 225 and 221 seconds - a 1.8% improvement. Incidentally to make the DomU boot successfully with less than 30M of RAM I had to use “MODULES=dep” in /etc/initramfs-tools/initramfs.conf. To get it to boot with less than 14M I had to manually hack the initramfs to remove LVM support (I create my initramfs in the Dom0 so it gets drivers that aren’t needed in the DomU). I was unable to get a DomU with 12M of RAM to boot with any reasonable amount of effort (I expect that compiling the kernel without an initramfs would have worked but couldn’t be bothered). Future tests will have to be on another machine as the machine used for these tests caught on fire - this is really annoying, if someone suggests an extra test I can’t run it. To plot the data I put the following in a file named “command” and then ran “gnuplot command“:
unset autoscale x
set autoscale xmax
unset autoscale y
set autoscale ymax
set xlabel “MB”
set ylabel “seconds”
plot “128000″
replot “196000″
replot “256000″
set terminal png
set output “xen-cache.png”
replot “disk” In future when doing such tests I will use “time -p ” (for POSIX format) which means that it displays a count of seconds rather than minutes and seconds (and saves me from running sed and bc to fix things up). I am idly considering writing a program to exercise virtual memory for the purpose of benchmarking swap on virtual machines. My raw data is below:

time apt-get -y install psmisc openssh-client openssh-server linux-modules-2.6.18-5-xen-686 file less binutils strace ltrace bzip2 make m4 gcc g++ 96M: 0m37.416s
64M: 0m47.607s
48M: 0m55.050s
32M: 1m8.200s
30M: 1m15.010s
28M: OOM process 2 with default initrd, needed MODULES=dep to make it boot
28M: 1m18.694s
24M: 1m25.517s
20M: 1m38.376s
16M: 2m15.594s
14M: 3m14.777s
13M: OOM when the initrd is not hacked to remove LVM stuff and drivers for Dom0 stuff
13M: 4m15.930s
12M: really won’t boot 128000K of RAM in Dom0 for caching (18M cache and 70M free), 256M swap per DomU on tmpfs. 96M: 0m40.121s
64M: 0m48.207s
32M: 1m12.394s
24M: 1m21.929s
16M: 1m59.042s
14M: 2m48.517s
13M: 3m29.391s 196000K of RAM in Dom0 for caching: 64M: 0m47.871s
32M: 1m12.078s
24M: 1m22.360s
16M: 2m0.336s
14M: 2m36.459s 256000K of RAM in Dom0 for caching: 64M: 0m47.949s
32M: 1m11.435s
24M: 1m21.402s
16M: 1m58.884s
14M: 2m39.081s 256000: of RAM in Dom0, three DomU’s: 32M: 3m41.583s 3m40.737s 3m41.071s
16M: 6m16.430s 6m14.832s 6m7.569s hard drive, three DomU’s: 32M: 3m42.100s 3m47.516s 3m46.333s
16M: 6m41.587s 6m50.837s 6m51.795s

Share This

When recording changes in some software there are basically three approaches, with their different advantages and disadvantages.

• One approach is just record modifications chronologically. Each modification is just a little diff (or some glorified variant of diff, or if you insist something that is no diff but just has some similarity). Advantages are:
  • It keeps itself out of the way. You just do modifications and store them somehow one after the other.
  • You can reconstruct all past points, so can regain missing documentation by looking at the evolution in time.
  So it is no surprise that essential every tool (i.e. all the VCSes) to handle non-packaging work on software essentially uses this way. If you have an canonical other source for the software (like an upstream for an package), it has quite some severe drawbacks:
  • Reviewablity does not scale. While every single diff can easily be reviewed, the mass is not. Most changes are relative to past versions of the software. If something introduces a problem or and upstream change introduces a problem with that, the fix might only show up years later, separated by tons of other changes in between. (The effect especially with changing upstream always depends a bit on the later merging, but the worst case is still the same).
  • For the same reason changes cannot be easily extracted. Single commits usually are fine, but what of those past changes is needed to make some specific change in the functionality is easily lost after some time, some improvements and updates to new upstream versions. The whole approach degenerates to having a single large .diff.gz file of the package. (Except one has a bit of history recorded, so when sorting out the stuff in that diff one can better guess what effect a single unattributable line has).
• The next possibility is to store modifications sorted by topic and against upstream (either as .diff files relative to the upstream source, as topic branches, or or or). Advantages:
  • As you have to send the patch upstream anyway, you have to create such an patch initially, anyway. Also each is in a format that if upstreams wants to apply a single one, each is in the correct format for this.
  • Branches relative to a (relatively) fix point are usually use to store in VCSes.
  • When other people want to pick a subset of those patches, they only have to do the merging, and not dismerging with the missing ones first.
  On the other hand, there are some disadvantages with this:
  • As the differences are relative to the upstream code, multiple patches are in general not applicable without additional merging.
  • Because of this, those patches cannot be used to generate the source to build the Debian package.
  • Thus those patches by itself are never directly used, unless the maintainer regularly tests them, they are essentially untested and will see bitrot.
  • As those are not the changes to the package because of the missing merge, they are nice for a cursory review, but if you want the review the actual changes, you need to review the merged variants.
• Last but not least, there are stacked patches, i.e. patches that are supposed to be applied in a specific sequence. Advantages:
  • The patches itself are actually used. Thus they get wide testing and bitrot cannot happen that easily.
  • Equally, reviewing the actual changes can be separated into the different patches, as connected changes are next to each other and the files describe the changes without pitfalls in merges.
  • If someone else wants to use multiple patches from the start of the sequence, no merging is necessary. They can directly be applied.
  Given these advantages, it is no big surprise that all Debian specific patch management tools (like dbs) and other programs to deal deal with multiple patches against other people's code (like quilt) use this approach. Though there are also some disadvantages:
  • Ordering patches is not important. Only unrelated patches can be skipped to have later patches applied cleanly, so ordering needs to predict what patches are more likely to be used by other people.
  • Testing only happens for the whole stack. If some match modifies parts that a later patch removes, bitrot can still happen.
  • Extracting those patches from the currently available VCSes is not trivial.

So the format most suitable to Debian packages (stacked patches) is the total opposite of a format most suitable when you are upstream yourself and nothing is suitable for everything. There are many different thinkable ways to combine the different things to get more of the advantages, though many are a bit lacking (like storing quilt series in a VCS as text files), not yet possible or non-trivial with the current tools. Hopefully the future will improve that.

I just wrote about the system administration issues related to the recent Debian SSL/SSH security flaw [1]. The next thing we need to consider is how we can change things to reduce the incidence of such problems. The problem we just had was due to the most important part of the entropy supply for the random number generator not being used due to a mistake in commenting out some code. The only entropy that was used was the PID number of the process which uses the SSL library code which gives us 15 bits of entropy. It seems to me that if we had zero bits of entropy the problem would have been discovered a lot sooner (almost certainly before the code was released in a stable version). Therefore it seems that using a second-rate source of entropy (which was never required) masked the problem that the primary source of entropy was not working. Would it make sense to have a practice of not using such second-rate sources of entropy to reduce the risk of such problems being undetected for any length of time? Is this a general issue or just a corner case? Joss makes some suggestions for process improvements [2]. He suggests that having a single .diff.gz file (the traditional method for maintaining Debian packages) that directly contains all patches can obscure some patches. The other extreme is when you have a patch management system with several dozen small patches and the reader has to try and discover what each of them does. For an example of this see the 43 patches which are included in the Debian PAM package for Etch, also note that the PAM system is comprised of many separate shared objects (modules), this means that the patching system lends itself to having one patch per module and thus 43 patches for PAM isn’t as difficult to manage as 43 patches for a complex package which is not comprised of multiple separate components might be. That said I think that there is some potential for separating out patches. Having a distinction between different types of patches might help. For example we could have a patch for Makefiles etc (including autoconf etc), a patch for adding features, and a patch for fixing bugs. Then people reviewing the source for potential bugs could pay a lot of attention to bug fixes, a moderate amount of attention to new features, and casually skim the Makefile stuff. The problem began with this mailing list discussion [3]. Kurt’s first message starts with “When debbuging applications” and ends with “What do you people think about removing those 2 lines of code?“. The reply he received from Ulf (a member of the OpenSSL development team) is “If it helps with debugging, I’m in favor of removing them“. It seems to me that there might have been a miscommunication there, Ulf may have believed that the discussion only concerned a debugging built and not a build that would eventually end up on millions of machines. It seems possible that the reaction would have been different if Kurt had mentioned that he wanted to have a single source tree for both debugging and for regular use. It also seems likely that his proposed change may have received more inspection if he had clearly stated that he was doing to include it in Debian where it would be used by millions of people. When I am doing Debian development I generally don’t mention all the time “this code will be used by millions of people so it’s important that we get it right“, although I do sometimes make such statements if I feel that my questions are not getting the amount of consideration from upstream that a binary package destined for use by millions of people deserves. Maybe it would be a good practice to clarify such things in the case of important packages. For a package that is relevant to the security of the entire distribution (and possibly to other machines around the net - as demonstrated in this case) it doesn’t seem unreasonable to include a post-script mentioning the scope of the code use (it could be done with an alternate SIG if using a MUA that allows selecting from multiple SIGs in a convenient manner). In the response from the OpenSSL upstream [4] it is claimed that the mailing list used was not the correct one. Branden points out that the openssl-team mailing list address seems not to be documented anywhere [5]. One thing to be learned from this is that distribution developers need to be proactive in making contact with upstream developers. You might think that building packages for a major distribution and asking questions about it on the mailing list would result in someone from the team noticing and mentioning any other things that you might need to do. But maybe it would make sense to send private mail to one of the core developers, introduce yourself, and ask for advice on the best way to manage communication to avoid this type of confusion. I think that it is ideal for distribution developers to have the phone numbers of some of the upstream developers. If the upstream work is sponsored by the employer of one of the upstream developers then it seems reasonable to ask for their office phone number. Sometimes it’s easier to sort things out by phone than by email. Gunnar Wolf describes how the way this bug was discovered and handled shows that the Debian processes work [6]. A similar bug in proprietary software would probably not be discovered nearly as quickly and would almost certainly not be fixed in such a responsible manner. Update: According to the OpenSSL project about page [7], Ulf is actually not a “core” member, just a team member. I had used the term “core” in a slang manner based on the fact that Ulf has an official @openssl.org email address.

• [1] http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/


• [2] http://np237.livejournal.com/17981.html


• [3] http://marc.info/?t=114651088900003&r=1&w=2


• [4] http://www.links.org/?p=328


• [5] http://advogato.org/person/branden/diary/5.html


• [6] http://gwolf.org/node/1743


• [7] http://www.openssl.org/about/

Share This

Since development kernels 2.6.26-rc*, the iwlwifi drivers (iwl3945, iwl4965) have LED support. While LED support is nice to have (making it easy to see when the wireless connection is available), the blinking of the LED whenever there is data transmitted is annoying.In most networks, there is a constant chatter on the net. Windows server browsing and announcing, Zeroconf/Bonjour announcements, Printer discovery. When you're using some instant messaging or chat such as IRC there is some data transmitted all the time. Your email program might be polling for new emails, and your weather applet might be fecthing the latest forecasts. So basically, there always is ome network traffic. Often in the range of less than 1k/s, but there is.The new iwlwifi drivers don't flicker the LED with each packet received, but apparently will just set the LED to a blink mode when they received or transmitted some data, which if find rather irritating.Fortunately, this can easily be configured in Linux, just save this script in /etc/network/if-up.d/iwl-no-blink and make it executable:

#!/bin/sh
if [ "$IFACE" = "wlan0" ]; then
	for dir in /sys/class/leds/iwl-phy*X; do
		echo none > $dir/trigger
	done
fi

This is a quick hack, but it does the job well for me - when the device is connected it will stop blinking on data. It will still blink when connecting (leds:iwl-phy*:assoc) and indicate if the connection is available (leds:iwl-phy*:radio).