Two tips on using ssh for alioth. Just because I currently have sloooow connection to alioth, I looked into making the connection better. Installing pdnsd and improving perceived DNS performance, installing webcaching etc are important too, but there is a ssh improvements which can be done. Using ControlMaster argument for ssh. You can have a master ssh session open, and ssh will reuse that connection, without asking for your password every time, just like using ssh-agent, but faster. I remembered this setting just because someone mentioned alioth -guest login names being a nuisance because they always have to specify it on ssh and scp; you don't. You just set the respective 'User' directive to the -guest names.

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English. When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

Some people troll free software lists with remarks like:

Linux will never be able to displace MacOS/Windows since the latter are much more pretty/user-friendly. You will lose.

Such people assume that hackers write free software because they "hate Microsoft" or "hate capitalism" or have some other pet hates. However, it should be obvious that such a large creative effort cannot be sustained if it is based on such negative emotions.¹ There are a number of positive reasons why one works on free software. The software that I like to work on is software² that I use or want to use. This has some consequences which are worth underlining:

• Contrary to the views expressed in some articles about free software, the theme of usability (by me!) is uppermost in my mind whenever I approach any task pertaining to software.
• Since the software I work on should be usable long after I have forgotten the ideas behind its implementation, the user interface should be one that confirms to "standard" expections. This means that it should be possible to use the software without reading the code.
• When I look at the code after a long time (for example to extend it in some way) I should be able to read and understand it, which requires clean code with adequate documentation.

Giving others the "four freedoms" results in wider critical examination of these aspects. Bugs must be acknowledged and fixed --- or elevated to features! Moreover, there are parts of the task that are "obvious" to me but I would have to ask others for advice on other parts. So I gain a lot by being part of a larger community. There are other reasons to write free software. For example, someone may pay you to do it. However, this is just deferring the same question to your employer. In most cases, your employer already has a use in mind for the software. The employer has the same concerns as I outlined above except that the job of writing the code is being out-sourced. The usability, portability and long-term maintainability are probably even bigger concerns for your employer. "Last but not the least" (as we always wrote in our school-day essays) free software is fun! You share ideas with people from across the globe and to show them your own clever little tricks. Good code and good themes resonate with people who may not even speak the same language as you do. What could be nicer than that!

In few hours after releasing 1.20.93 it became obvious that I will need another testing release, because number of bug fixes grow too much. So here it comes. Schedule for 1.21.0 is Tuesday next week, so please report any problems you face with this testing version. Full list of changes in 1.20.94:

• Automatically switch to nodtr connection if DTR/RTS setting fails.
• More verbose debug messages in API.
• Free phone data after testing model to avoid memory leaks.
• Properly handle if IMEI is too long (bug #709).
• Try to handle situation when CMGL does not list all messages.
• Fix typo in MySQL file (bug #716).
• Better parsing of USSD replies (bug #718).
• Properly restore caller groups on Nokia 2630 (bug #706).
• Fix listing of used calendar locations on Nokia (bug #710).
• Properly encode class and coding to SMS (bug #714).
• SMSD for MySQL no longer fails when sending message (bug #715).
• SMSD stores signal and battery state in PostgreSQL.
• Properly handle multiline firmware information.

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.

After Lennart posted his summary of Linux sound APIs, the debate heated up again between ALSA and OSS zealots. Both ALSA and OSS developers think their API is the definitive interface for sound support in Unix and like to bash each other, and tell how the other API sucks and how the others are spreading FUD. This is not only a sterile debate, but it is completely irrelevant. Do you know why? Because neither of them is a suitable sound API. Technical constraints, functional requirements and history make the ideal sound stack on Linux look like the following:

• a sound driver, consisting of a kernel module and if necessary a low-level library
• if configured so, a sound daemon which brings software mixing and network support PulseAudio finally kicking out all crappy alternatives
• a high-level programming API for use by developers.

Only the last bit should be of interest to application developers. Everything else is plumbing. When you develop a multimedia application or a mixer controller, why would you care of the insanely complex ALSA library or to make ioctls somewhere in /dev when GStreamer and Phonon provide you with high-level functions that can do it in a snap? When you want to insert sounds in your game or application, why would you care of those bits when, with SDL_Mixer or libcanberra, a single line of code is enough to decode and play the sound? If we want to see sound working properly under Linux, we need to keep the stack simple and to clearly separate the roles. In the end, this boils down to very simple things:

• Application developers must stop using ALSA and OSS. Both of them are completely unsuitable for the task, and it only serves the purpose of letting ALSA and OSS developers troll. Whichever application you are writing, there is one of the high-level frameworks SDL, GStreamer, Phonon, libcanberra, KNotify, JACK that is better.
• OSS and ALSA should stop trying to be application-level APIs. Instead of trolling about which API is better, they need to write drivers so that sound fucking works instead of asking users to use Windows to see their brand new computer output some sound.
• The plumbing layers (backends for the high-level APIs and PulseAudio) need excellent support for both ALSA and OSS. In the end, what matters is to have a driver for your sound card and to have it usable by all applications. Keeping the driver layer independent from the sound API is the only reliable way to keep things working over time. If someone else starts writing yet another driver framework, we will be able to make applications use it, instead of adding yet another ton of compatibility stacks.
• In the end, compatibility layers that cross layers in the stack must disappear. ALSA emulation for PulseAudio? OSS emulation with a LD_PRELOAD hack? Seriously, WTF? Applications should not have used them as a sound API, and we need to trash this crap eventually.

Please, guys, hold off a minute. You are developing drivers and you must be praised for that. Keep doing that well, and stop trying to invade applications. There are people who may not know how to develop a driver, but who obviously know better what a sound API should look like.

Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

And here is what one of the devs from OSS answered to this [1]:

It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].

If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.

This looks kind of interesting: http://wiki.reia-lang.org/wiki/Reia_Programming_Language In short: it's a Ruby/Python type of language on top of Erlang. It has a mishmash of Ruby and Python syntax, and also does objects, implemented as Erlang processes. Funny quote:

Reia uses an indentation-sensitive syntax. This allows Reia to look similar to Erlang without relying on "ant turd" tokens (i.e. , ; and .) to structure relationships between forms.

That made me laugh, and is in all seriousness, something that I do find to be a bit annoying in Erlang, especially when refactoring code. You can't just move a line of code from one place to another; you move it, then change the line endings in both places. My preference would be to do something more Ruby style rather than Python style for the following reason: the indentation thing makes it harder to use straight-up Python for templating purposes, whereas Ruby can be used as-is. Templates are something that I wouldn't particularly want to do in Erlang, either, so doing them with this language might be a very nice alternative. Anyway, it looks to be in its infancy. Unfortunately, it seems to require a more recent version of Erlang than what ships with Ubuntu Hardy. Maybe Intrepid will have something recent enough to run it. It's a little known fact that I originally wrote Hecl in Erlang, although, sadly, I can't find the code any more.

DISCLAIMER: Paranoid rant ahead. You ve been warned. Every two years, around this time of the year, I feel concerned: it s voting time in Brazil. For quite some time now, Brazil has had electronic voting, but that doesn t make me more confortable with it. Yes, having the results within the same day is an enormous advantage, but I am not sure about the security of the whole process. You can call me paranoid (and surely I am a bit), but there are some things that give me the creeps about it. For a start, let s look at the operational process. The voting machines are certified and sealed by Electoral Justice officers the week before the voting. They are opened in the electoral section by those officers in the presence of common citizens. Those citizens are called to work in the Electoral process usually for four or five elections in a row, being replaced after that by newcomers . The voting machines are not connected to any network. During the day, voters come with the voting document (voting is mandatory in Brazil), one of those citizens enable the voting machine by typing the document unique number in it, the voter give his vote and go home. Then the voting machine is unable to receive votes if not enabled by entering another document number, and it goes on and on the whole day long (pretty boring work ). At the end of the day, the president of the section (usually the most experienced of those citizens) close the voting machine, prints a tally sheet , hand a colored 3 -inch floppy disk to the Electoral Justice officer with the votes and go home. Other officers will pick up the voting machines later on. The first officer then goes to the voting processing central of the Electoral Justice and within hours we will know the result of the election. As you can see, there are lots of points of failure in the whole process! All this sealing of voting machines are just a matter of trust. First point: there s no way we can know for sure if the machine does what it s suppose to do. Even if officers say that they randomly choose machines to be tested, there s no way to know how random is that. There s a report [pt-BR] made by a prestigious university (English summary here), stating that 1/3 of the voting machines in a particular studied state had corrupted log-files (among other important security problems!). This study also showed differences in the countings (sometimes as large as 20-thousand votes!)... Hey! This is supposed to be a deterministic system: if nothing in the conditions changed, counts should always match! Until recently, closed-source software were used in the voting machines, but that has changed recently. I doubt that it makes any difference, since we ll never really know what is actually running in the machine. Surely, Electoral Justice officers know (or should know), so we d have to trust them So second point: we don t know how the voting is processed within the machine. (Also, we don t know for sure the machine doesn t have a network connection. It may have a wireless connection we don t know about and can be passing all the votes to someone else, or even receiving instructions But since that can be spotted with a scanner, I ll trust other paranoids have already done that.) Surely the machine must be enabled before every vote with the voters document number. If it were not, how could we know that no one voted twice, or that a non-voter have voted? But we don t know how the machine records that! Third point: we cannot know if the voting machine database doesn t link the voter to the vote. That is a nasty one it opens up the possibility of voting by intimidation . Also, the tally sheet that is printed at the end of the day only brings the total of votes, the total of absent-voters, and the votes each candidate (or party) have received. So, on to the fourth point: there s no way of knowing for sure that your vote was counted right (or was counted at all!). At least a copy of this tally sheet is glued at the entrance of the voting section, so an independent audit only on the numbers is do-able (although hard to do!). What happens to the colored disk between the voting section and the voting processing central is not known. It goes with the officer and what he does with it is just a matter of trust. Now for the most insteresting point: the security is based on the color of the disk!. The Electoral Justice checks if the officer handed the right colored disk and puts the data in the system. Surely (?) they might have some way to check data integrity other than that On the same issue, maybe even worse: even if the disk is not tampered, but just read (or copied) by the officer before being handed, and if the database links the voter to the vote, this information is valuable, and may be sold. Finally, since we don t know (and have no way to know for sure) what the machine does, we don t know if the machine keeps a copy of the voting database in it. So when it is taken back by other officers, we cannot know whether the same thing that may happen to the disk also could happen with the machine. I am missing a lot of things about the whole Brazilian E-Voting process, and also I surely have missed other points of failure. I heard of fraud in the past, with paper ballots, and those were pretty nasty frauds. But this whole tale of impossible fraud in e-voting is nothing but a tale (as fraud is more than possible!). I think we have to begin investigating other systems, surely with cryptography involved. A system like Debian s, far from perfect (we all have to trust secretary s word on the secrecy of the voting system key), is much better, for instance. I understand that it s not simple enough for non-geeks, but there might be a way! It doesn t need to be a whole new system! I would be happy if, as an example, the tally sheet printed a hash of my vote that I could verify later on or if the security of the disk is not just color-based or if the tally sheets had a way of being validated and be available on-line for auditing (and not just glued at the entrance of every voting section). Look! I am not distrusting any officer a priori... I think the message is auditing should be made easy... then I could trust a version of Linus s Law adapted to E-Voting: Given enough eyeballs, all frauds can be discovered .

The last two weeks I've been too busy to do much work for the release or blog about my and our efforts to get lenny out of the door. Two weeks ago we were at 144 RC bugs which are open in lenny and not fixed in sid, today it's 138, thats not much progress :( OTOH, d-i has finally been frozen and the amount of bugs alone is not a good indicator per se, as can be seen with the 500k bug contest ;-)

So, what have I done in the last two weeks regarding the release? I sponsored two uploads, irusian for 497255 and poker-network for 498497, though poker-network was then removed from testing, because it was simply too buggy.

Then I up+downgraded 498852, because it very much sounded RC but then turned out to be unreproducible :-) Last friday I uploaded munin 1.2.6-6 which includes a fix for 494547 an annoying and important bug, leading to a useless mail every 5min...

And today I had fun finally closing 322762 after doing a (delayed-2) NMU to fix 359574, so lenny will not include code refering to /usr/doc anymore, a promise we already gave for woody. Yay.

I shall blog next monday or tuesday again about this and have fixed another RC bug by then. But, then, I will have to do my taxes next week...

I wrote before about datapacker, but I didn't really describe what it is or how it's different from other similar programs.

So, here's the basic problem the other day. I have a bunch of photos spanning nearly 20 years stored on my disk. I wanted to burn almost all of them to DVDs. I can craft rules with find(1) to select the photos I want, and then I need to split them up into individual DVDs. There are a number of tools that did that, but not quite powerful enough for what I want.

When you think about splitting things up like this, there are a lot of ways you can split things. Do you want to absolutely minimize the number of DVDs? Or do you keep things in a sorted order, and just start a new DVD when the first one fills up? Maybe you are adding an index to the first DVD, and need a different size for it.

Well, datapacker 1.0.1 can solve all of these problems. As its manpage states, "datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools." datapacker accepts lists of files to work on as command-line parameters, piped in from find, piped in from find -print0. It can also output its results in various parser-friendly formats, call other programs directly in a manner similar to find -exec, or create hardlink or symlink forests for ease of burning to DVD (or whatever you'll be doing with it).

So, what I did was this:


find Pictures -type f -and -not -iwholename "Pictures/2001/*.tif" -and \
-not -wholename "Pictures/Tabor/*" -print0 \
datapacker -0Dp -s 4g --sort -a hardlink -b ~/bins/%03d -


So I generate a list of photos to process with find. Then datapacker is told to read the list of files to process in a null-separated way (-0), generate bins that mimic the source directory structure (-D), organize into bins preserving order (-p), use a 4GB size per bin (-s 4g), sort the input prior to processing (--sort), create hardlinks for the files (-a hardlink), and then name the bins with a 3-digit number under ~/bins, and finally, read the list of files from stdin (-). By using --sort and -p, the output will be sorted by year (Pictures/2000, Pictures/2001, etc), so that photos from all years aren't all mixed in on the discs.

This generates 13 DVD-sized bins in a couple of seconds. A simple for loop then can use mkisofs or growisofs to burn them.

The datapacker manpage also contains an example for calling mkisofs directly for each bin, generating ISOs without even an intermediate hardlink forest.

So, when I wrote about datapacker last time, people asked how it differed from other tools. Many of them had different purposes in mind. So I'm not trying to say one tool or the other is better, just highlighting differences. Most of these appear to not have anything like datapacker --deep-links.

gaffiter: No xargs-convenient output, no option to pass results directly to shell commands. Far more complex source (1671 lines vs. 228 lines)

dirsplit: Park of mkisofs package. Uses a random iterative approach, few options.

packcd: Similar packing algorithm options, but few input/input options. No ability to read a large file list from stdin. Could have issues with command line length.

I have just took a quick look at yet another OpenID-related php script which is, just like the others I've seen, open to XSS attacks.

---

People, be prepared; probably by this weekend[1] I will be disclosing those vulnerabilities in at least three different so-called "products". When will people finally take security and quality seriously? (especially on auth stuff!)

[1] I'll be taking part in a small talk this Saturday (an introduction to GNU, Linux, and Debian; followed by an install fest) so I hope I will have time to review all of the openid-related scripts I'm aware of.

---

As of the next PTS pulse, it will be less pedantic and won't warn when the watch file has only failed less than three continuous times. Hope this makes some people happy :)

I have previously written about how I refused an offer of a free iPhone [1] (largely due to it’s closed architecture). The first Google Android phone has just been announced, the TechCrunch review is interesting - while the built-in keyboard is a nice feature the main thing that stands out is the open platform [2]. TechCrunch says “From now on, phones need to be nearly as capable as computers. All others need not apply“. What I want is a phone that I control, and although most people don’t understand the issues enough to say the same, I think that they will agree in practice. In the 80’s the Macintosh offered significant benefits over PCs, but utterly lost in the marketplace because it was closed (less available software and less freedom). Due to being used in Macs and similar machines the Motorolla 68000 CPU family also died out, and while it’s being used in games consoles and some other niche markets the PPC CPU family (the next CPU used by Apple) also has an uncertain future. The IBM PC architecture evolved along with it’s CPU from a 16bit system to a 64bit system and took over the market because it does what users want it to do. I predict that the iPhone will be just as successful as the Macintosh OS and for the same reasons. The Macintosh OS still has a good share of some markets (it has traditionally been well accepted for graphic design and has always provided good hardware and software support for such use), and is by far the most successful closed computer system, but it has a small part of the market. I predict that the iPhone will maintain only a small share of the market. There will be some very low-end phones that have the extremely closed design that currently dominates the market, and the bulk of the market will end up going with Android or some other open phone platform that allows users to choose how their phone works. One issue that I think will drive user demand for control over their own phones is the safety issues related to child use of phones (I’ve written about this previously [3]). Currently phone companies don’t care about such things - the safety of customers does not affect their profits. But programmable phones allows the potential for improvements to be made without involving the phone company - while with iPhone you have Apple as the roadblock. Now having a small share of the mobile phone market could be very profitable, just as the small share of the personal computer market is quite profitable for Apple. But it does mean that I can generally ignore them as they aren’t very relevant in the industry.

• [1] http://etbe.coker.com.au/2008/07/16/mobile-ssh-client/


• [2] http://www.techcrunch.com/2008/09/23/touching-the-android-its-no-iphone-but-its-close/


• [3] http://doc.coker.com.au/safety/mobile-phone-safety/

Share This

Just to make it a day of firsts, and perhaps because someone else spent four hours messing with wire and such in my mouth and I needed to take some control back, I also crimped my first ethernet cable today. Plan is to see if a 400 foot out of spec cable will reach the yurt. If not, I'll cut it 100 feet back and add a hub in a can to be a repeater.

Dear American: I need to ask you to support an urgent secret business relationship with a transfer of funds of great magnitude. I am Ministry of the Treasury of the Republic of America. My country has had crisis that has caused the need for large transfer of funds of 800 billion dollars US. If you would assist me in this transfer, it would be most profitable to you. I am working with Mr. Phil Gram, lobbyist for UBS, who will be my replacement as Ministry of the Treasury in January. As a Senator, you may know him as the leader of the American banking deregulation movement in the 1990s. This transactin is 100% safe. This is a matter of great urgency. We need a blank check. We need the funds as quickly as possible. We can not directly transfer these funds in the names of our close friends because we are constantly under surveillance. My family lawyer advised me that I should look for a reliable and trustworthy person who will act as a next of kin so the funds can be transferred. Please reply with all of your bank account, IRA and college fund account numbers and those of your children and grandchildren to wallstreetbailout@treasury.gov so that we may speedily transfer your commision for this transaction. After I receive that information I will respond with detailed information about safeguards that will be used to protect the funds. Yours Faithfully Minister of Treasury Paulson **** The source of this? A former U of C graduate anthropology classmate. This actually may be the original source, or like all really good spam, somewhat (seemingly at least) sourceless.

Last weekend at the Software Freedom Day party, I was a little surprised to find myself among hundreds of attendees and supporters. Even if NYC is not known, like Silicon Valley is, for its vibrant tech scene, this event reminded me that we definitely have a thriving community of programmers and advocates but we have lacked a central “place” to check for computer-related events in the area. At least until now. James Vasile, a lawyer at the Software Freedom Law Center will now be publishing an event feed. Please send him an email if there is any event you want advertised (contact details on his page), you can subscribe here, and here is a calendar.

I ve been silent in this blog last few days, but that has an explanation: I ve been trying to make JRuby 1.1.4 work with one of my scripts. The problem is that after having done all the tweaks I can imagine, I still can t get enough performance with Ruby 1.8.7 (latest etch-backports). Our client will not allow Ruby 1.9 in the server (what is really a pity, for the performance boost I had with Ruby 1.9 is awesome!), but it already have Java6 So the only option I have left is trying JRuby beast. Since our script deals with system stuff, it uses syslog a lot, and that is where the main problem seems to be. Syslog support is new in JRuby, has had some implementation problems, and sure are not something to rely on right now so I dropped it from the script, and it run! Twice as fast (not as good as Ruby 1.9, though)! There are some other problems with this script and JRuby, more important ones being (1) at_exit doesn t work; and (2) errors are not easy to backtrace (when JRuby fails it seems to mess up with the backtrace stack), but not preventing it to work So with the increased performance of JRuby, and after fixing those minor glitches, I was still left with the syslog problem Until I investigate some final solution (I think I ll have to use some Java native syslog library given such a thing exist), I ve split the script in performance-boost needing and syslog-needing parts; the first is using JRuby, and the second, Ruby 1.8.7 They communicate using sockets (I know ugly I would like to use DRuby, but I would not introduce another point of failure in an already messy situation) and the overall performance was brought to a satisfactory level. So far, it s been interesting to study the issue Mainly because I haven t used JRuby since it s early versions, and it has improved a lot. But also because I read a lot about the future of Ruby (bytecode compilation, YARV and so on), and it made me even happier with my primary-do-it-all programming language. Now I ll try to compile java bytecode generated by JRuby into a native binary with GCJ :-D. Let s see if that is do-able Updated 2008-09-24 18:03:00: As you can see in the comments, syslog actually works. I figured this out this morning, but JRuby Subversion already had a patch. Anyway, I submitted another bug I found.

This morning I finally found some time to add an init script to the Debian package of mysql-proxy (0.6.1-3 which includes it was just uploaded to unstable, I will try to get a freeze exception for lenny). It is disabled by default, because mysql-proxy is quite useless without a proper configuration. It can be enabled in /etc/default/mysql-proxy, here is an example:

ENABLED="true"
OPTIONS="--proxy-lua-script=/usr/share/mysql-proxy/rw-splitting.lua
         --proxy-address=192.168.1.140:3306
         --proxy-backend-addresses=192.168.1.20:3306
         --proxy-read-only-backend-addresses=192.168.1.23:3306
         --proxy-read-only-backend-addresses=192.168.1.24:3306"

In this example the proxy binds to 192.168.1.140 port 3306 and does read/write splitting. Writing statements are directed to 192.168.1.20 port 3306 (master), and reading statements are loadbalanced between 192.168.1.23 port 3306 (first slave) and 192.168.1.24 port 3306 (second slave).

Just spent a good two^Wthree hours trying to configure awesome 3.0 to match my awesome 2.x setup. Docs are effectively nonexistant. So far, I'm stuck on several fronts:

• I want to be able to left click on a titlebar and drag to resize. Without pressing the modkey. But the definition for that is set deep within awful.lua, which is not a configuration file, and so I cannot see a good way to configure it.
• Why can't I resize an xterm to 80 characters wide? It jumps between 79 and 81.
• Why is it that despite using the same font as with 2.0, enough additional vertical space is used by the title bar and status bar, that I get one less line in all my xterms? It's using only a few pixels more than before, but that's too much..
• How do I configure a textbox so that, if I click on it, a command is run? Update: Figured this one out, for example: mympd:mouse_add(mouse( , 1, function () os.execute("awesome-mpd show &") end)) (Note that if the command isn't run in the background, and opens a window, it will deadlock awesome.)
• Can't figure out how to use awesome-client to add a value to a graph widget. (I'm sure this is simple, but I haven't stumbled over an example. I'd use wicked, but it's not packaged.) Update: Figured it out via the source: mpgraph:plot_data_add("foo", "10")
• Can't figure out how to make a textbox widget have a fixed width and truncate the text in it. Since it's displaying the currently plaging song, using the default dynamic width would make everything on my status bar jump around. Update: mytextbox.width=100
• There's no emptybox widget aymmore, so how do I add horizontal padding between widgets? Best I've managed so far is an empty textbox with a defined width.

Anyone else hate lua, or at least build-your-own-WM-in-lua config files for window managers that used to have simple config files?

(semi-joke only fully understandable by French folks. Julien Blache used the same joke in the past) My dear Genneff, "Valid-Until" is certainly a good idea and I have no doubt it's well implemented in our archive tools. I'm less sure about this being implemented in apt, because of the loose resources of the APT maintenance "team" as of now. And I'm damn sure that implementing that feature will add yet more work coordinating l10n. APT is currently fully translated to 18 languages and, of course, the warning message issued by APT when a user is directed to a faked security repository *has* to be translated for the user to really understand what's happening. It even has to be translated very carefully. Contrary to popular belief, not all systems admins understand English easily. And we really want the important message that will be issued by APT in such case, to be understood and understood well. So, good luck to /me dealing with a last minute l10n update that will quite certainly happen, now. I can't even use this in an attempt to get bug #500000, as #499897 is already reported against apt. Crap. I'm out of ideas for getting that bug report... As a revenge, I propose that next time we all see Ganneff in a group, we all hug him to death for implementing that very good feature in our archive tools.