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. :-)

Conditional partitioning in debian installer I needed to create an automatic, unattended installer that would repartition the whole disk, but keep an existing home partition if it is already existing. The idea is to replace the operating system, but keep the user's home files. If the home partition does not exist, however, we need to create it. The starting point for this is in Holger's website, which does everything except create the partition if it's missing. The technique I used is to create a udeb that would scan the partitions using /usr/lib/partconf/find-partitions and then load the right preseeding for partman-auto, the automatic partitioner. Here you find the udeb source. I'll comment the most important bits: First, the two partman-auto recipes that we are going to preseed. The format is documented in the debian-installer documentation. This will create /home if missing: And this will keep /home if it exists: Then the postinst file of the package, where the logic is. Otavio and Daniel on #debian-boot have taught me that udebs are, simply put, just big postinsts (installer wise, apart from shipping binaries). Postinst is where the logic is done, or applications are started. Finally, debian/control. The basic bits about creating a d-i udeb are to put it in Section: debian-installer and to use XC-Package-Type: udeb. Then there is XB-Installer-Menu-Item, that defines the order of execution of postinsts. The d-i documentation lists the numbers that are currently assigned. I am using 38 rather than 3800 because I'm targeting etch d-i. After etch, "numbers have been multiplied by 100 from what they were before to give us more space". This is it. debian/rules is just boilerplate, except installing the preseed files in the right place. CDBS is useful to make this self-evident: To build the installer CD with this d-i, I'm using simple-cdd; here are the profile files I'm using at the moment, with the main preseeding for fully unattended install (it is designed to trash your hard disk if you boot it, so only test it in an emulated environment) and the inclusion of the custom udeb.

People don't seem to get that once you load a 1MB binary blob into your kernel you are no longer running a free operating system. There is no way to fix it. No way to see what is going wrong. Fedora 9 is shipping the latest xorg Release. It features major improvements for the Intel and Radeon drivers. The well known randr features got pushed even more. Plus gaining better 2D and 3D effects and important power saving improvements. Thanks to all the xorg hackers! Big blame on a unnamed company that can't keep up with latest Linux (Xen gained paravirt_ops support in 2.6.24 - oh yeah but we are still on 2.6.18 state). To truly support Linux you'd have to first release your specs and then help existing xorg hackers. Even Via seem to have got the message lately after years of no transparence.

I'm excited by version 7 of debhelper, in particular the opportunity for debian/rules minimization. I suspect this will lower the barrier for rapid, reasonable packaging of simple software tools in a way that should be easy to audit and maintain. The most-minimized debian/rules possible with it is just (from dh(1)):

#!/usr/bin/make -f
%:
	dh $@

And all of the project-specific interesting bits go into nice, clean, well-named files under debian/. However, lintian (at least as of 1.23.48) complains loudly about the minimized debian/rules:

E: xdotool source: debian-rules-missing-required-target binary
E: xdotool source: debian-rules-missing-required-target binary-arch
E: xdotool source: debian-rules-missing-required-target binary-indep
E: xdotool source: debian-rules-missing-required-target build
E: xdotool source: debian-rules-missing-required-target clean

I'm not sure the right way to proceed: should i try to manually add overrides for each package that uses a minimized debian/rules? Should lintian recognize debhelper-specific minimized rules files and accept them? Should debhelper assuage lintian somehow? Or is this rules file minimization actually not as good an idea as I think it is? I notice that mr, which is Joey Hess's first example package using the minimized rules also reports the same errors.Tags: debhelper, lintian, packaging

This was meant to echo Jeff Bailey s Out and about!, where Jeff wrote about blood transfusion. Every country has its own values, rules, and methods for blood donation (be it about anonymity, retribution, etc.), but please consider getting informed, and donate. According to the tablissement Fran ais du Sang (roughly translated to: French Blood Institute), the key point is to donate again, possibly on a regular basis. Various possibilities in France: donate full blood (2 months delay between each, takes about 10 minutes), or selectively (plasma or platelets, 2 to 4 weeks delay between each, takes about a full hour). You can save lives. Will you do it? Many thanks to Helen for reminding me to write a note about important things.

Looking at the current discussions, I'm wishing some people would calm down a bit. It's always impressive how some things switch sides like pendulums. First of all, Debian already is centered about packing software and not developing them. We already have the rules and policies and methods in place. Our policy states:

If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.

And our source format shows how important marking the difference is to use: We have explicit .diff.gz files to contain them. The differences are not hidden in same Version Control System (like BSD) or in propretary formats (ever tried to unpack a .srpm without rpm or without downloading some magic perl script?), but in a simple universal understandable format. That said, please remember we are a distribution. Our priorities are our users and not the whims of software authors. We have to find the middle ground between harmful and necessary changes. Patching software to abide the FHS, to allow the user choose their editor or browser in an common way or any other thing to form a coherent set of packages is no bug in Debian, it is a bug in upstream to not allow this at least via some configure option. We have neither the manpower nor the job to rewrite and fork stuff to a usable state, though. Thus we have to keep to upstream and hope they will include our modifications or forward-port them to every new release. Thus, we need both: We need to patch (and in general, the worse the software from a distribution's point of view or from a general point, the more of this we need. This does not necessarily hold in the other direction, though.). And we need and want to show what we change. So our users can find out how exactly the software we ship is different. And so other people dealing with the same software can profit from our changes. (After all, free software is about "giving back" a lot.). And of course maintainer change over time and we want the new one understands what the previous one did. That said, there is of course things that can be improved. But as with all improvements there are things that improve and there are things where nothing is worse than good intentions. Adding more thing to keep in sync is almost always a bad thing in the long run. The easiest way to keep things accessible is to use stuff actually used. I think any additional place to track patches will be futile. A good interface to view the .diff.gz files in our archive in some browser, on the other hand, could hardly get unuseful. The format of a single .diff.gz is of course also improveable. Things like a quilt-like standardized patch series look like a very good idea to me. But the format is of course also very downgradeable. Storing VCS formated information for example, tempting as it is, spoils two very important points:

• universal readability is lost. Everyone coping with software can work with patches or patch series, no matter what tools they use.
• visibility of changes is sacrificed for history. Every single VCS I ever saw primarily coped with history. Even patch based ones represent changes in time and not by itself changes by topic.

And of course, a lot can be improved by just using some rules more strictly. Not using a pristine tarball or a proper subset of one where the first is not possible should not be some mere ignorable non-conformist behaviour, but seen as the serious problem it is.

As I said a month ago, my main server Delmak was dying. Well it still runs (proof: you could read this blog some days ago). Thanks to friends I host for free, they've kindly given enough money to buy a brand new server (C2D E8400, 4 GB RAM, 2x500 GB RAID 1) in order to replace the good old Delmak. This new box has been named Prometheus after the only BC-303 class battleship ever built. Delmak was used to mainly run as a Web, mail and databases server. I decided to do use this server switch to change the server software I use. The first mail server I setup was based on Exim 3, courier- imap,pop -ssl, with userdb files. That was... rough. Later I switched to Exim 4, using vexim, and MySQL as a back-end. That was something like 3 years ago I guess. Since then I never really touched that back. I added spamassassin and clamav filtering some months after, because some users asked for it. That's all. So this week, I decided to switch away from this configuration. I do not understand Exim anymore anyway, so I decided to use Postfix which I often use and administrate at work. Obviously, I also now use PostgreSQL as database back-end, since it rocks, and since Postfixadmin supports it. By the way, be aware that the Debian package of postfixadmin is crappy (the configuration file is readable by anyone by default, with the database password in it). I also set up postgrey which is quite nice and efficient. Well, then was time for amavisd-new installation, but I did not do it. Seriously, amavisd-new configuration is a bloody mess, as the language it is written in (yes, Perl). So I switched to dspam which I heard is nice. Well, it seems to be for now, since it even supports clamav daemon usage directly, which is very very nice because that means I do not have to set up another thing for that. I also switched from courier to dovecot, mainly because the latter seems to be faster and lighter. I then changed the default virtual_transport to Dovecot LDA. The main advantage of this is that the LDA updates the Dovecot index while delivering. It also supports quota, which I do not use and plug-ins, like the Sieve language for mail filtering. So I decided to change my procmailrc to a new Sieve filter. My procmailrc is quite small since I only use regex to match lists and some mail address, so it has only something like 12 rules. And well, I did not do it since I discovered after some googling that Dovecot implementation of Sieve is grabbed from Cyrus which does not support variables for now. That means that the following procmailrc code:

:0:
* ^X-Mailing-List: <debian-.+@lists.debian.org>
* ^X-Mailing-List: <debian-\/[^@]+
list-debian-$MATCH/

which will translate to:

require [ "regex", "variables", "fileinto" ]
if header :regex "X-Mailing-List" "<debian-(.+)@"
 
    fileinto "lists.debian.$ 1 ";
    stop;
 

But that won't work since Dovecot Sieve implementation does not support "variables". Well, since I'm not ready to list all the lists I'm subscribed to, Sieve is a no-go for now. I'll stick with procmail.

It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem. John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time… Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys. To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following: Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section: Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users. When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA. Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output. Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected. When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this? The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face. Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in. Also thanks to Helmut for advice on ssh-keygen.

• [1] http://www.debian.org/security/2008/dsa-1571


• [2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html


• [3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html


• [4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html


• [5] http://www.phrack.org/issues.html?id=11&issue=59


• [6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html


• [7] http://www.docunext.com/blog/2008/05/14/my-security/


• [8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki


• [9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Share This

(tl;dr: if you have a few minutes, please add information here) Joss, the problem with the new package formats is that there is nothing that actually uses the additional information in a way that adds significant new functionality, so the net result of the change was that we throw away the information at a different layer in our software stack, and one of the interfaces got a lot more complicated in the process. One possible application would be a "poor man's patch tracking" inside the BTS, perhaps with a new state "fixed in patch". I can see two ways of implementing that:

1. by extending the interface of the "new" package formats that Debian,Ubuntu bug numbers are attached to the actual patch files and having the archive maintenance software extract and process that information (reject packages that add a patch for a bug without closing it in the changelog, notify the BTS), or
2. by leaving the package format untouched and simply adding a regex matching "Fixes: #nnnnnn" that is reported to the BTS as "we have added a patch", so the submitter is notified that the bug is gone for him/her; the bug is then closed in the changelog of the upload removing the patch.

The former approach also allows us to link to patches from BTS pages, which the latter doesn't, so there could be actual benefit here if we believe it is worth the additional complexity. (Update: Rapha l thinks it is. I like the idea of a package format with separate patches a lot more in this context than I did without it, but still my fear that it will actually be perceived as sanctioning large patchsets still remains.) About mandatory co-maintenance: the problem isn't "helping". We have plenty of people with commit access to packages they don't even remotely understand who are really helpful (not). The problem is that someone needs to actually read all the commit logs and understand what the changes do in this context. In most cases, that person or group would be upstream, not a DD. My first impression after reading the patch was "adding uninitialized data to the entropy pool is pointless/harmful as it is not random, so this patch makes sense", because the loop around it was not contained in the patch. Obviously I'm not an OpenSSL developer. There is nothing Debian could have done internally to verify the correctness of this patch that would properly scale to the entire archive, even if we put "more emphasis on security". The only solution I see is reporting every patch to upstream immediately and getting affirmation that it is correct. This, however means that we need to produce patches that upstream can accept. For obvious code bugs, that is simple, but for integration patches like paths it is not sufficient to replace one string with another, but rather make it configurable in some place that can be reached from debian/rules. In an ideal world, we end up with very few Debian specific patches, so essentially we are talking about adding functionality to dpkg that we don't want to use. I've started a page in the Debian Wiki, Getting Packaged with an outline of a possible document aimed at upstream developers that should list the typical problems we run into and how to avoid them.

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large. The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education. To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk). Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull). Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work. On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible). The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to. If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages. I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way. With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down. The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation. Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts. The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too. So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before. Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really. The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed. The reason why I believe Linux is the better choice here is long-term support. Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of. The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable. To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did. The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.

"Here are three examples of rules that I think it's time to abandon. These particular examples are all about email. 1/ Top Posting [...] 2/ HTML Email [...] 3/ Reply-To On Mailing Lists [...] So, yes, the barbarians are at the gate. The lunatics have taken over the asylum. Good ideas have been crushed by the number of people who don't understand them. But there's no point in complaining about it. You just have to accept it and move on."

-- Pointless Battles For Geeks, By Dave Cross Unsurprisingly, given the above links to my site, I disagree with Dave Cross's conclusion, but I do agree with two aspects: battling is generally pointless and using hard rules about these things is unnecessary. I have those pages on my website so that I can point to them when their broken emails aren't handled as expected. I use some aspects of them as scoring inputs in my mail filters. I don't use them as rules and I try not to complain about them too often. Nevertheless, I still believe sending properly-trimmed plain text emails from a list-friendly email client is clearly best practice, to be recommended when someone asks why their email bad habits are causing them problems.

One of the proudest moments I had as a Canadian was sitting in the Senate visitor's gallery watching the debates on same-sex marriage that led to the full legalisation in Canada. In coming down to the US for work, I was sad to come to a place that not only didn't allow it, but had actually had a number of ballots in states voting specifically that the marriage referred to "One Man, One Woman".

I found a transcription of the Hansard of Prime Minister Paul Martin's introduction of Bill C-38 (The Civil Marriage Act). The logic in there for why Canada needed to legalise same-sex marriage is quite specific to Canada, but he talks about why it's important for the issue not to come to a vote:

The Charter was enshrined to ensure that the rights of minorities are not subjected, are never subjected, to the will of the majority. The rights of Canadians who belong to a minority group must always be protected by virtue of their status as citizens, regardless of their numbers. These rights must never be left vulnerable to the impulses of the majority.

I don't really understand the US system of rights. I hope that the protection of the right to love another consenting adult and make a commitment to them becomes the law of the land throughout the United States.

I love being married. I get the joy of being able to come home to my belle and share my day, spend time, and know that to the best of our ability, we're going to try to grow old together. I'm so happy that this ruling has come down and that in California the debate is now over.

The configuration of this blog has been explained earlier. There was one thing still missing from this blog --- comments.The comments plugin that comes in the contrib tarball from the pyblosxom web site is well-documented and easy enough to install. One modification I made is to remove all the javascript stuff since I don't understand the latter.After all this one still needs some sort of authentication to prevent complete rubbish from cluttering the comments section. The natural candidate was openid which is supported by a plugin from snarfed.org.This seemed easy enough to configure except that there is no version of these libraries in Debian "etch" (which is what people.imsc.res.in runs). So I downloaded the latest 2.x.x version of these libraries. Since I rarely install my own python libraries, it took me a while to figure out that I need to run

python setup.py install --home $HOME

in order to install it in my home directory. This also needed the codebase variable to be set in config.py.Unfortunately, this still did not work. The plugin comments_openid.py actually uses the API from the older 2.0.x version of the python-openid libraries.Some error messages from our web server led me onto a completely different track and I thought that the rewrite rules from the .htaccess file were in error. This was a McGuffin and I had to revert to the comment-free version in order to clean-up the mess. Thank goodness for git!The plugin currently works with the 2.0.x version of the libraries which may be mildly worse than the 2.1.x version.Some other things which are not working are e-mail/rdf notification of comments. I don't know if I will bother to fix that.

Imagine, for a moment, that you are a young man in your 20s, trying to make your way in the world. You are married and have a young daughter, just old enough to start to talk. You live in a run-down neighborhood, long passed-over by any economic advances. What schools you had access to barely taught anyone much. The few jobs you can reach have fierce competition, even though the pay is low. You worry about your health, but even more about that of your wife and child. Finding food is a constant concern. Although you are still healthy now, and you are willing and able to be a hard worker, there is simply nobody hiring people in your area. Not to mention the gunfights that erupt between gangs or drug dealers. Oh, and did I mention that your wife is 4 months pregnant?

Your top priority is to do your best to keep your family safe. You're afraid that your whole family will starve, or be killed by an errant bullet. You've tried for a long time -- it seems like forever -- to do everything you can think of, with no success. Finally, you decide that the only way you can have the hope for a better life is to move somewhere where the economy is better, and the drug dealers are fewer.

But moving hundreds or thousands of miles away is no easy task when you have no money to move. Somehow, with some luck, ingenuity, and tenacity, you have finally managed to find a way. You have no job offer in your new town, but conditions are so bleak at home that you just can't risk staying there. So the three of you move 1500 miles away.

You arrive with no money, no apartment, and don't know anybody. But you're a hard worker, and have talked yourself into a job. It pays what passes for minimum wage in your new home, but it's a fortune compared to what you made before. It's backbreaking work, and you work long hours. But soon you can afford a cramped apartment, and keep your refrigerator stocked with food. What a luxury!

Pretty soon your new baby son is born. You can afford to feed him, your daughter, your wife, and yourself, every day. When you're really lucky, you even have some money left over to send to your brother back home, who is still struggling to make ends meet there. You seem to have climbed the first rung on the American Dream ladder.

Years pass. Your old home becomes a memory; your daily life revolves around new struggles now. Your oldest child is in school, your wife finds part-time work sometimes too, cleaning houses for rich people. You've been laid off several times, your income isn't guaranteed, and the others in your new home don't take kindly to strangers -- and they still think you're one. But it's better than flying bullets and never knowing where your next meal will come from.

Then one day, while you are at work, federal agents show up. You are arrested and taken to jail. Agents show up at home, too, arresting your wife. It turns out that they realized you entered the country illegally from Ecuador those years ago. Meanwhile, your wife wonders what will happen to your son that was playing in a neighbor's yard while she was arrested, or to your daugther that was at school.

After months in jail, with little contact with each other, and poor medical care, the government decides to deport you to Mexico. Why Mexico? Well, it's cheaper, and there's no documentation showing where you came from. Apparently you "look" Mexican, and they don't believe your story.

After months in jail with no income, you are once again bankrupt. A government bus takes you to Mexico and drops you down someplace there, with your wife and your oldest child. Your younger child was born in the United States, and so is an American citizen and can't be deported. But the government isn't going to give him a free ride on a prison bus (and Mexico wouldn't take him anyway, since everyone knows he's American). You have no idea where he is. You have no idea how you're going to find food in Mexico, no idea how to find your son, no idea where to find refuge from the ever more prevalent drug dealers. Meanwhile, the Americans think you're scum because you wanted to protect your family, and it's going to be much more difficult to get back in to try to reunite your family.

This story is based on true events.

It's truly easy to demonize illegal immigrants, isn't it? Easy to round them up by the thousands, easy to build a bigger fence, easy to lock them away.

Sometimes it seems like this nation built on freedom, supposedly on Christian values, has lost sight of compassion for the lowly. In this country, we would throw in jail parents that didn't do everything humanly possible to find food for their children. We also throw in jail parents that grew up in other countries that are just doing the same.

How sad that we have people going on TV, suggesting we round up millions of Americans that happened to come here illegally, breaking up millions of families, creating an immense foster child problem, a human tragedy on a mass scale. How incredible that some of these people on TV wear the title "senator" or "candidate for president". How stupid do they think we are, suggesting that a poor South American family would somehow be able to navigate the arcane American immigration system and wait the 15 years to get here legally, if they manage to come up with all the necessary money somehow?

Politicians have been pushing our buttons for too long. We aren't a nation of selfish hoarders; we came together through tough times, survived the Depression, put in place the Berlin Airlift that saved countless lives in West Berlin. But the thought of someone with darkish skin coming to this country and building highways is enough to send some people looking for a rifle.

I hope that we will someday do better.

If you look at the po-debconf stats pages, you'll see that, as of today, the French translators translated 9693 strings out of 9688...:-) We are so clever! This is actually an annoyance on the scripts that generate these pages. Sometimes, in packages, the debian/po/*.po files contain *more* strings than the debian/po/templates.pot files. This happens when maintainers do not run "debconf-updatepo" in the clean target of their debian/rules files. People, there is a lintian warning for this...:) We will try to correct this (actually, more Nicolas Fran ois than me, indeed) but that will make my stats less easy to do... So, "sadly", we are indeed only about 99%... That said, the NMU campaign is still going on. Portuguese is now ahead of Czech (ranked 3rd). Russian passed Swedish and is very close to Spanish for rank 7. And, among the most actives, Finnish and Basque are still climbing up quickly.

Important note: This post has been modified according to a private remark from Marco d'Itri, thanks to him for his explanations ! I've been trying for a very long while to learn to write udev rules, but I've mostly been unsuccessful, or rather, successful by chance, which is hardly better, as it implies no understanding whatsoever of what I'm doing. My game, today, was to create a symlink for a loop device (loop7) and set the device's group to cdrom (I might elaborate some time later why I need that). So, here is what I learned:

• at least for the GROUP= directive, the latest item in the /etc/udev/rules.d directory rules
• to test the modifications, the best thing is to generate a synthetic add using the following snippet:

  echo add > /sys/block/loop7/uevent
  

  Many thanks to Marco d'Itri for this information !

With that in mind, the following snippet worked for me, under the name 40-private-loop.rules:

KERNEL=="loop7", SYMLINK="videoloop", GROUP="cdrom"

Enjoy !

backports.org currently lacks a security team and infrstructure, like testing has. Currently it's possible that someone uploads a package and stops caring and nobody notices. I guess the people running backports.org are aware of this and do their best to prevent it (and afaik dont really want backports.org to become official) but for an official backports service I think this issue needs to be tackled. What do you think?

I also like backports to become officially endorsed and supported as I would like stable to continue to have no new features introduced. EtchAndAHalf and LennyAndAHalf being the exceptions to this rule, though I see some (currently only potential) problems in the way it's handled now.

As some of you might have noticed, I have uploaded a bunch of new packages to my experimental repository, all of them related to digital photographic workflow. Most of them are based on existing packages, but built from a VCS snapshot to benefit from newly supported hardware and new features.

• ufraw was updated to support my Sony DSLR-A700 camera - packaged based on the latest release available in sid.
• hugin package in unstable is outdated - I have based my package on Debian PhotoTools member Cyril Brulebois’s work. It seems that some legal questions have been raised, preventing the package to be updated in the official archive.
• autopano-sift fixes FTBS and other bugs in Christian Marillat’s package and proves working well with hugin. I will e-mail him a patch with the amendments I have worked on.
• enblend needs to be built from VCS to work with current hugin snapshots. The package is fully based on the package available in sid.

Though I use these packages on a regular basis, they haven’t been thoroughly tested as official packages would be, and might still contain bugs or errors. Please report any problem you might have. I will try and update these packages when time allows it. VCS snapshots might be unstable, or even non-usable. As usual, use these non-official packages on your own risk. Also note that these packages are currently only available for amd64. I will eventually build i386 packages if requested.

Some of the more powerful tools combine data banks of information with robust technological features. One such tool is the Cause Caller developed by Fred Benenson, an ITP graduate student who developed it for his thesis project. Here is some more information and make sure to check out the blog for even more:

The promise of a truly participatory democracy has never been clearer than digital media has made it today. The unique distributive nature of the Internet provides a platform that has the potential to deliver on this promise by facilitating better group action at lower cost,thereby encouraging actual participation in democracy. There have been many meaningful developments in bringing better information and actions to citizens looking to use digital networks to serve their political needs, but many useful tools and databases remain proprietary and costly while others remain too general or ineffective for political action. Cause Caller uses open source technology to deliver on the promise of a participatory democracy by taking the hassle and difficulty out of organizing phone banks. Users of Cause Caller can create individual causes and associate new politicians to those causes.

Meet the Italian income agency The Italian income agency decided to publish online all the income levels for each and every single citizen and company in the country. I did not manage to see the actual data, because the entire income agency website was swamped with request and timing out all the time. You should have heard the comments of my accountant, who every day needs to access other parts of the website for work. That service is supposed to have been taken offline now, after the Italian privacy watchdog issued a polite What The Fuck! Why Didn't You Tell Us Anything About This? sort of note. The minister defended himself by saying "I can't see what is the problem, it's the same in all the world: if you want proof just watch any American TV series". What a wise man. I should watch some of The Greatest American Hero again. Since I could not see the actual data, I could not verify if what people were saying was actually true, that is that income information were published together with the full home address, providing a nice shopping list for house robbers, kidnappers and the other kind of professionals that would politely wait next to your door for you to come home late in the night. But fear not, the website was protected from bots: it used a captcha. Not only that: in order to comply with standard accessibility rules, the website used a perfectly accessible captcha: You can't get more accessible than that: the captcha is displayed in plain text, so any accessibility technology will be able to read it. Plus, anyone can easily copy and paste it into the text box. And if someone needs to do it often, it's even trivial to write a script that does it for you! But it's unfair to say that it was just plain text: it was cleverly encrypted:

<div class="educaptcha"><label for="educaptcha">I<!-- id9113507 -->nser<span>ire </span><span>nel c</span><span>ampo</span> di <!-- id5058508 -->v<span>erific</span><span>a suc</span><!-- id2643358 -->ces<span>sivo i</span><!-- id2500023 -->l valore <span>695</span><span>8571</span>4<!-- id3588853 -->:</label>
<input id="educaptcha" type="text" name="ucaptcha" value="" maxlength="10" size="20" /></div>

For your convenience, here is the version cracked with a malicious :%s/<[^>]\+>//g in vim. If you do not speak Italian, you can still look for this phrase in the screenshot above:

Inserire nel campo di verifica successivo il valore 69585714:

The meaning is of course:

Insert the value 69585714 in the following verification field:

It's been a fun day for Italians online.