Search Results: "hmh"

14 December 2016

Antoine Beaupr : Debian considering automated upgrades

The Debian project is looking at possibly making automatic minor upgrades to installed packages the default for newly installed systems. While Debian has a reliable and stable package update system that has been an inspiration for multiple operating systems (the venerable APT), upgrades are, usually, a manual process on Debian for most users. The proposal was brought up during the Debian Cloud sprint in November by longtime Debian Developer Steve McIntyre. The rationale was to make sure that users installing Debian in the cloud have a "secure" experience by default, by installing and configuring the unattended-upgrades package within the images. The unattended-upgrades package contains a Python program that automatically performs any pending upgrade and is designed to run unattended. It is roughly the equivalent of doing apt-get update; apt-get upgrade in a cron job, but has special code to handle error conditions, warn about reboots, and selectively upgrade packages. The package was originally written for Ubuntu by Michael Vogt, a longtime Debian developer and Canonical employee. Since there was a concern that Debian cloud images would be different from normal Debian installs, McIntyre suggested installing unattended-upgrades by default on all Debian installs, so that people have a consistent experience inside and outside of the cloud. The discussion that followed was interesting as it brought up key issues one would have when deploying automated upgrade tools, outlining both the benefits and downsides to such systems.

Problems with automated upgrades An issue raised in the following discussion is that automated upgrades may create unscheduled downtime for critical services. For example, certain sites may not be willing to tolerate a master MySQL server rebooting in conditions not controlled by the administrators. The consensus seems to be that experienced administrators will be able to solve this issue on their own, or are already doing so. For example, Noah Meyerhans, a Debian developer, argued that "any reasonably well managed production host is going to be driven by some kind of configuration management system" where competent administrators can override the defaults. Debian, for example, provides the policy-rc.d mechanism to disable service restarts on certain packages out of the box. unattended-upgrades also features a way to disable upgrades on specific packages that administrators would consider too sensitive to restart automatically and will want to schedule during maintenance windows. Reboots were another issue discussed: how and when to deploy kernel upgrades? Automating kernel upgrades may mean data loss if the reboot happens during a critical operation. On Debian systems, the kernel upgrade mechanisms already provide a /var/run/reboot-required flag file that tools can monitor to notify users of the required reboot. For example, some desktop environments will popup a warning prompting users to reboot when the file exists. Debian doesn't currently feature an equivalent warning for command-line operation: Vogt suggested that the warning could be shown along with the usual /etc/motd announcement. The ideal solution here, of course, is reboot-less kernel upgrades, which is also known as "live patching" the kernel. Unfortunately, this area is still in development in the kernel (as was previously discussed here). Canonical deployed the feature for the Ubuntu 16.04 LTS release, but Debian doesn't yet have such capability, since it requires extra infrastructure among other issues. Furthermore, system reboots are only one part of the problem. Currently, upgrading packages only replaces the code and restarts the primary service shipped with a given package. On library upgrades, however, dependent services may not necessarily notice and will keep running with older, possibly vulnerable, libraries. While libc6, in Debian, has special code to restart dependent services, other libraries like libssl do not notify dependent services that they need to restart to benefit from potentially critical security fixes. One solution to this is the needrestart package which inspects all running processes and restarts services as necessary. It also covers interpreted code, specifically Ruby, Python, and Perl. In my experience, however, it can take up to a minute to inspect all processes, which degrades the interactivity of the usually satisfying apt-get install process. Nevertheless, it seems like needrestart is a key component of a properly deployed automated upgrade system.

Benefits of automated upgrades One thing that was less discussed is the actual benefit of automating upgrades. It is merely described as "secure by default" by McIntyre in the proposal, but no one actually expanded on this much. For me, however, it is now obvious that any out-of-date system will be systematically attacked by automated probes and may be taken over to the detriment of the whole internet community, as we are seeing with Internet of Things devices. As Debian Developer Lars Wirzenius said:
The ecosystem-wide security benefits of having Debian systems keep up to date with security updates by default overweigh any inconvenience of having to tweak system configuration on hosts where the automatic updates are problematic.
One could compare automated upgrades with backups: if they are not automated, they do not exist and you will run into trouble without them. (Wirzenius, coincidentally, also works on the Obnam backup software.) Another benefit that may be less obvious is the acceleration of the feedback loop between developers and users: developers like to know quickly when an update creates a regression. Automation does create the risk of a bad update affecting more users, but this issue is already present, to a lesser extent, with manual updates. And the same solution applies: have a staging area for security upgrades, the same way updates to Debian stable are first proposed before shipping a point release. This doesn't have to be limited to stable security updates either: more adventurous users could follow rolling distributions like Debian testing or unstable with unattended upgrades as well, with all the risks and benefits that implies.

Possible non-issues That there was not a backlash against the proposal surprised me: I expected the privacy-sensitive Debian community to react negatively to another "phone home" system as it did with the Django proposal. This, however, is different than a phone home system: it merely leaks package lists and one has to leak that information to get the updated packages. Furthermore, privacy-sensitive administrators can use APT over Tor to fetch packages. In addition, the diversity of the mirror infrastructure makes it difficult for a single entity to profile users. Automated upgrades do imply a culture change, however: administrators approve changes only a posteriori as opposed to deliberately deciding to upgrade parts they chose. I remember a time when I had to maintain proprietary operating systems and was reluctant to enable automated upgrades: such changes could mean degraded functionality or additional spyware. However, this is the free-software world and upgrades generally come with bug fixes and new features, not additional restrictions.

Automating major upgrades? While automating minor upgrades is one part of the solution to the problem of security maintenance, the other is how to deal with major upgrades. Once a release becomes unsupported, security issues may come up and affect older software. While Debian LTS extends releases lifetimes significantly, it merely delays the inevitable major upgrades. In the grand scheme of things, the lifetimes of Linux systems (Debian: 3-5 years, Ubuntu: 1-5 years) versus other operating systems (Solaris: 10-15 years, Windows: 10+ years) is fairly short, which makes major upgrades especially critical. While major upgrades are not currently automated in Debian, they are usually pretty simple: edit sources.list then:
    # apt-get update && apt-get dist-upgrade
But the actual upgrade process is really much more complex. If you run into problems with the above commands, you will quickly learn that you should have followed the release notes, a whopping 20,000-word, ten-section document that outlines all the gory details of the release. This is a real issue for large deployments and for users unfamiliar with the command line. The solutions most administrators seem to use right now is to roll their own automated upgrade process. For example, the Debian.org system administrators have their own process for the "jessie" (8.0) upgrade. I have also written a specification of how major upgrades could be automated that attempts to take into account the wide variety of corner cases that occur during major upgrades, but it is currently at the design stage. Therefore, this problem space is generally unaddressed in Debian: Ubuntu does have a do-release-upgrade command but it is Ubuntu-specific and would need significant changes in order to work in Debian.

Future work Ubuntu currently defaults to "no automation" but, on install, invites users to enable unattended-upgrades or Landscape, a proprietary system-management service from Canonical. According to Vogt, the company supports both projects equally as they differ in scope: unattended-upgrades just upgrades packages while Landscape aims at maintaining thousands of machines and handles user management, release upgrades, statistics, and aggregation. It appears that Debian will enable unattended-upgrades on the images built for the cloud by default. For regular installs, the consensus that has emerged points at the Debian installer prompting users to ask if they want to disable the feature as well. One reason why this was not enabled before is that unattended-upgrades had serious bugs in the past that made it less attractive. For example, it would simply fail to follow security updates, a major bug that was fortunately promptly fixed by the maintainer. In any case, it is important to distribute security and major upgrades on Debian machines in a timely manner. In my long experience in professionally administering Unix server farms, I have found the upgrade work to be a critical but time-consuming part of my work. During that time, I successfully deployed an automated upgrade system all the way back to Debian woody, using the simpler cron-apt. This approach is, unfortunately, a little brittle and non-standard; it doesn't address the need of automating major upgrades, for which I had to revert to tools like cluster-ssh or more specialized configuration management tools like Puppet. I therefore encourage any effort towards improving that process for the whole community. More information about the configuration of unattended-upgrades can be found in the Ubuntu documentation or the Debian wiki.
Note: this article first appeared in the Linux Weekly News.

22 June 2014

Simon Josefsson: OpenPGP Key Transition Statement

I have created a new OpenPGP key 54265e8c and will be transitioning away from my old key. If you have signed my old key, I would appreciate signatures on my new key as well. I have created a transition statement that can be downloaded from https://josefsson.org/key-transition-2014-06-22.txt. Below is the signed statement.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
OpenPGP Key Transition Statement for Simon Josefsson
I have created a new OpenPGP key and will be transitioning away from
my old key.  The old key has not been compromised and will continue to
be valid for some time, but I prefer all future correspondence to be
encrypted to the new key, and will be making signatures with the new
key going forward.
I would like this new key to be re-integrated into the web of trust.
This message is signed by both keys to certify the transition.  My new
and old keys are signed by each other.  If you have signed my old key,
I would appreciate signatures on my new key as well, provided that
your signing policy permits that without re-authenticating me.
The old key, which I am transitioning away from, is:
pub   1280R/B565716F 2002-05-05
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
The new key, to which I am transitioning, is:
pub   3744R/54265E8C 2014-06-22
      Key fingerprint = 9AA9 BDB1 1BB1 B99A 2128  5A33 0664 A769 5426 5E8C
The entire key may be downloaded from: https://josefsson.org/54265e8c.txt
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key 54265e8c
If you already know my old key, you can now verify that the new key is
signed by the old one:
  gpg --check-sigs 54265e8c
If you are satisfied that you've got the right key, and the User IDs
match what you expect, I would appreciate it if you would sign my key:
  gpg --sign-key 54265e8c
You can upload your signatures to a public keyserver directly:
  gpg --keyserver keys.gnupg.net --send-key 54265e8c
Or email simon@josefsson.org (possibly encrypted) the output from:
  gpg --armor --export 54265e8c
If you'd like any further verification or have any questions about the
transition please contact me directly.
To verify the integrity of this statement:
  wget -q -O- https://josefsson.org/key-transition-2014-06-22.txt gpg --verify
/Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iLwEAQEKAAYFAlOnV+AACgkQ7aIelLVlcW89XgUAljJgYfReyR9/bU+Om6UHUttt
CAOgSRqdcQSQ2hT69vzuhb/bc8CslIQcBtGqTgxDFsxEFhbm5zKn+tSzy5MHNHqt
MsqHcZjlYuYVhMXDhka+cfyhtd9zIxjVE5vk8v+GqEGoh8DGYq0vPy3VfvcSz5Z3
MSUpSj8gN00jlU1z4nad3maEq0ApvsLr8EsLZmtxF5TNFvzJ8mmwY+gHBGHjVYkB
8AQBAQoABgUCU6dX4AAKCRAGZKdpVCZejD1eDp46XGL2puMp0le2OF75WIUW8xqf
TMiZeB99ruk3P/jvuLnGPP2J5o7SIKE50FkMEss0yvxi6jBlHk+cJeKWGXVjBpxU
0QHq063NU+kjbMYwDfi5ZxXqaKeYODJm8Xmfh3d7lRaWF5rUOosR8nC/OROSrhg4
TjlAbvbxpQsls/JPbbporK2gbAtMlzJPD8zC8z/dT+t0qjlce8fADugblVW3bACC
Kl53X4XpojzNd/U19tSXkIBdNY/GVJqci+iruiJ1WGARF9ocnIXVuNXsfyt7UGq4
UiM/AeDVzI76v1QnE8WpsmSXzi2zXe3VahUPhOU2nPDoL53ggiVsTY3TwilvQLfX
Av/74PIaEtCi1g23YeojQlpdYzcWfnE+tUyTSNwPIBzyzHvFAHNg1Pg0KKUALsD9
P7EjrMuz63z2276EBKX8++9GnQQNCNfdHSuX4WGrBx2YgmOOqRdllMKz6pVMZdJO
V+gXbCMx0D5G7v50oB58Mb5NOgIoOnh3IQhJ7LkLwmcdG39yCdpU+92XbAW73elV
kmM8i0wsj5kDUU2ys32Gj2HnsVpbnh3Fvm9fjFJRbbQL/FxNAjzNcHe4cF3g8hTb
YVJJlzhmHGvd7HvXysJJaa0=
=ZaqY
-----END PGP SIGNATURE-----
flattr this!

29 March 2013

Gunnar Wolf: Looking for a (small) place to host a Free Software-related meeting, course or similar in Mexico City?

Hey, Mexican hackers! If anybody is interested in holding a small Free Software-related meeting (say, with up to 10-15 people) in the South of Mexico City, please tell me We have adapted a nice room at our house where we want to invite people to come and do activities Courses, meetings, whatever. It is not very big (~5 5 meters), but it has all of the needed amenities (some chairs, a projector, coffee-related amenities, and is very conveniently located). We are not charging for hosting your activities (but will of course want to schedule it beforehand with you). So, if you have something to teach, or some project to hack on, and want a nice place to do it in, please drop us a line/call. (hmh, yes, this is one of the posts that should probably be in Spanish But this blog has a long-standing policy for English content ;-)

11 November 2009

Yves-Alexis Perez: Key transition (this is _not_ a meme)

Ok, so following the trend, I created some time ago a new GPG key, which I'm now transitioning too. I've set up a transition document, available at http://molly.corsac.net/~corsac/key-transition.txt. It's signed by both the old and the new keys and is reproduced below:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160,SHA512
Wed, 11 Nov 2009 13:44:05 +0100
I've recently set up a new RSA-based GPG key, and will be transitioning away
from my old DSA-based one.  The old key will be revoked soon, so I prefer all
future correspondence to use the new one.  I would also like to ensure that
this new key is well-integrated into the web of trust.  This message is signed
by both keys to certify the transition.
The old DSA key was:
pub   1024D/C5C05BAE 2004-11-11
      Key fingerprint = DE26 2FC4 7097 FFC6 DE2C  D8C0 4D44 C020 C5C0 5BAE
The new RSA key is:
pub   4096R/71EF0BA8 2009-05-06
      Key fingerprint = 4510 DCB5 7ED4 7040 60C6  6476 3055 0F78 71EF 0BA8
If you already know my old key, you can verify that the new key is
signed by the old one:
  gpg --check-sigs 71EF0BA8
If you don't already know my old key, or if you're extra-paranoid, you
can check the fingerprint against the one given above:
  gpg --fingerprint 71EF0BA8
If you have previously signed my old DSA key, and if you're satisfied
that you've got the correct new RSA key, then I'd appreciate it if you
would sign my new key as well:
  caff 71EF0BA8
The caff program is in the signing-party package in Debian.  Please be careful
to generate signatures that don't rely on the weakening SHA-1 hash algorithm,
which requires some careful configuration even if you've already configured
gpg correctly.  See http://www.gag.com/bdale/blog/posts/Strong_Keys.html for
the gory details.
Thanks,
- --
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREDAAYFAkr6sqQACgkQTUTAIMXAW64HiACeIyabQueDHAeiAX8EkIeApiDj
++UAn2z7YkjHx0lQh0+s5WdhikG0YztiiQIcBAEBCgAGBQJK+rKkAAoJEDBVD3hx
7wuodUcQAKMbG9Rehxz+uZ6fST99cHt5Fjnv9TorY4hQaQK+85ZgiwPaHMHfYM1G
5hcrXI+JFUpz8j40deZuaWuspOdHBHwnHNQril8MqT0CJgtB6HFTo+w/7Lmmui5M
DDMMed39UJl7bF73hV9ywGecxPpeh+dtoVnh0VT16uK2xTvW6ICEZgaPw1xfPUHS
+jxQ7I05X1OWQkPpmhxXJqGclDyO+qx4CJZsOxUAvt2LphHxhZxB3QE5OUdudGKQ
AH6KhC4rpNQdJVMX20SG8PybL/AipN3Y8N/63VkoqVC2heRlaQ69HjsuqIAkIyan
hHnqmJH8Q+TDTbdKZvOQv6jcd4o3VSibz0T9MwnOfqQ0uRYyTpaXC0vLUH6lXaC4
eK+VVWbY8vCAFHR3h80Q61i2me2HU5ly7a/W22dz19zzDNNC5q9MO78uIYkUK78N
Z0wzJrmOxRyhvs5DOSOpNVlXZhffNQM1f42xxG8cUDaIf7pR5jK+xqHV7tIBQE1D
CrD0mt+YQCnngK0i4wQTO7VT/vjypf4A9W+VSsoJJpRhBbngU4pHu9JWqO84/7AA
j5FN8ug15MWysaS+FQ/EqzHmT7BGBWaTPv3yGlHKUjx0w4bPEpbH7y3fwHAcmOFf
xFRzvZFQ03zeer06yAqTVNuwr77HZgrCzgyQVgIkegAg6iUPiZcs
=CBT+
-----END PGP SIGNATURE-----

24 April 2008

Gunnar Wolf: Password security, data safety - A government perspective

One week ago, I went to a branch office of Servicio de Administraci n Tributaria, the government office in charge of processing taxes. This year, I plan on doing something quite bold, as my Mexican friends will acknowledge: I will prepare my (quite simple, I hope) tax declaration by myself. I do not want to be held hostage of the accountant guild - So I might end doing some fuckup which in the end costs me money or time. I hope it is not the case.
Anyway... Last week I went to this office, as I needed either a CIECF (Clave de Identificaci n Electr nica Confidencial Fortalecida - Strengthened Confidential Electronic Identification Key) or a FIEL (Firma Electr nica Avanzada - Advanced Electronic Signature). No, please don't believe it is a security token, a card with printed numbers, a one-time-pad or the sort - The CIECF is... A password. Why is it strengthened? Because it has the feature of including a question, in case you forget the key, to allow you to change it. I guess the FIEL is a more reliable device, but I prefer not to even request it.
And as far as the questions go, the emergency questions for CIECF suck. First, I was not even asked the meta-question - I was not told why this information was needed. So imagine the clerk saying: Full name? ... Date of birth? ... RFC (Tax ID)? ... Favorite color? I was there just... Stunned. Why do you need it? Oh, just in case you forget your password. Ok... Don't you have any other questions which I am not prone to answer a different thing, and that are not dead obvious for a casual passer-by? (I guess that at least 1/4 of the public will say blue. Feel like brute-forcing SAT to its knees?) Other questions include your fathers' second family name, your favorite soccer team, your pet's name... It seems they took the first "security dos and don'ts" book off the wall, and started reading backwards.
But anyway, that's the system, and I must play nice with it. So I get back home, and decide to start hacking up my declaration. No, Mr. Policeman, I'm not saying I would try to break into the SAT - I just say it is a complex and non-obvious task to do. Now please release me. Thanks.
And I enter the system. Of course, I tried first with Iceweasel, knowing it would fail (it is documented: MSIE 5.5 recommended). I tried again with Konqueror. I tried, sigh, with MSIE from inside Wine. No luck. Well, even from within qemu's Windows 2000. Wrong password. WTF?! Stranger: It worked with SAT's My portal, although it didn't with the declaration, which is what matters now.
I cannot take the time every day to come to the SAT and move my data - It was a full week until I came back again. I insisted on fully logging in to the system, to be sure the password I entered this time was right. As well as my ber-secret safety question, of course.
And it failed.
Twice.
Until the clerk noticed something strange in the way I typed...
Sir, excuse me..., he muttered, why are you typing such a long password? Well, basically because I value my tax declaration, and I know brute force is a powerful force. (explain it, of course, in simple terms) Oh... No, the password must be eight characters long.
No wonder.
So I entered the first eight characters of my password, which was a true work of prose for their standards, at around 20 characters. And it worked.
Now, for bonus points: What do we gather from the fact that the long password works fine in one system, but in another system it only the short version? Why, but of course! I guess the passwords for every economically active Mexican is stored in their master database in plain text. Isn't it just beautiful?
Anyway, it seems I have a lot of work to do. If all goes as planned, maybe next year I will be for hire as a public accountant? Hmh, does not sound too much like fun, does it?

3 March 2008

Gunnar Wolf: Keep the simplest things DRY and rolling

What's the best way to join a community, any community? Little by little.
I have been working with Ruby on Rails for well over a year already, even given a talk (at Encuentro Nacional Linux y Software Libre ENLi) inviting other people to use this very nice and well thought out environment. But, so far, I've been only a end-user, not really giving anything back besides minor bug reports.
Well, it's not as much as to say that I'm now a contributor - this is just a first statement of intent. I have worked a bit on several bits of code I keep repeating and hand-copying over my different Rails projects. Of course, that's completely not DRY - And completely not nice. So I decided to stop advancing on several projects, and learn my way on stting those bits of code as Rails plugins.
So far, it's been quite simple - and a good excercise on proper separation. I started, of course, with the easiest bit of code I could think of as useful in a general sense, and packaged it up as acts_as_catalog (of course, proper SVN tree and very basic, introductory README. And, of course, as I keep progressing with this work, I'll keep adding some plugins to my currently quite empty RubyForge page.
Anyway... Little by little, time will come where we have to think more seriously on how to properly bring together the Ruby on Rails style to work more tightly with Debian. Currently, the two have such different points of view on how to manage and ship components that I am not sure we will be able to truly bridge them together... But it is definitively worth trying. Hmh, looks like a task for Debconf! ;-)

25 November 2007

Gunnar Wolf: Goran Bregovi sends me northwards

What does this topic mean? Hmh... Maybe you don't know Goran Bregovi , a magical Bosnian musician, one of my all-time favorite artists. I have long loved Eastern European music (but I was mostly familiar with the Klezmer style, linked to Ashkenazi Jews but not necessarily performed by them anymore (i.e. Kroke), but it is thanks to Goran that I got familiar with the Balkan style... What can I say about it? It has an addictive rythm, and it has the folk sound of (even very similar instruments to) the Mexican tambora. It is a must-hear genre, in short. There are many magical Balkan music groups, I cannot just recommend one - But if I could, it would be Goran's :)
Now, why is he sending me northwards? Because Goran Bregovi is coming to Mexico - To the Northern city of Monterrey, some 1000Km north from Mexico City - He will be performing at the Forum Universal de las Culturas Monterrey 2007, on September 22, at the Explanada Plaza 400 a os.
I know already of a couple of friends who are definitively going, who are searching for the best airfare... This will be something to remember!

30 July 2007

Gunnar Wolf: On the Debian Maintainers GR

Hmh... It's hard to get to a decision on this aspect, although I'm mostly sure I'll vote for a "yes". I have read most posts on this subject on debian-vote and on the planet, and I'm still not too much at ease... Anyway, one of the most relevants so far is Joerg's - And not because he is so involved with the NM process, but because he drives me to what I think is a very important point few people have addressed:
For long, we have been saying that you don't have to be a programmer to help Debian - But so far, we have been unable to deliver except for this funny French guy. And although the current proposal still focuses on getting a step closer to DDness, and for many people this seems like geared at reducing the frustration when going over the NM process, my impression is that this will help us implement something similar for other areas.
Some people have complained about implementing decisions per policy instead of doing so gradually. Thing is, I feel, this kind of proposals have been reiterated over the years - and they have always dropped into the silence because some actions need to be taken by the people who are less willing to. Maybe the only way to break the inertia is to take a step by a GR vote. Maybe parts of it will have to be undone or re-done differently if we end up with the wrong results - but we will have broken the status-quo. Maybe, who knows, this will serve as an experiment - and after another long series of long flame threads we will end up in 2010 in the same position are we currently at - but it won't be because of inaction.

17 May 2007

Gunnar Wolf: On magazines without editorial direction

Scott complains on how Linux Format #93's articles comparing Ubuntu and other distributions often contradict each other, and blames it on the lack of any editorial direction or basic research.
I... Have to confirm this. But anyway, I can stand a bit on the different writers' side - Each article is written by a different person and, although the magazine must try to be coherent (of course, within certain limits - if the magazine suggests editor's picks in one article, they should not bash them to death in the next one).
I write the Linux column in the Spanish edition of PC Magazine. No, it's by far not a technical column, nor anything far like it. The magazine is end-user oriented, and clearly sponsorship-driven - In fact, my column was not part of the magazine for quite some time, as they gear it towards end-users, and sponsors (I cannot venture which sponsors, but your imagination will probably go to the same company as mine) do not like what I write about. All in all, I get the general topics which each month's edition will cover, and I just have to write an article about one of them. Of course, I don't know most of the other writers. There is no interaction at all.
And I guess that Linux Format is a typical magazine - If they run like PC Magazine, they just won't have the time to put all the articles together checking for inconsistencies. I think it is enough of a task to chase the contributors month after month (BTW, I'm a week late already :-/ But I cannot finish just today, as there's too much work to do, and I spend my time blogging... Hmh, time to finish this post, as coitus interruptus as it may seem).

20 December 2006

Gunnar Wolf: A mug of joy

I'm officially on vacation. That basically means there is nobody at my office. This time, though, it does not mean I will be the only sentient being in the building - I'll take most of the three weeks at home. I hope to be able to do some Debian work and catch up with some other projects... Anyway, part of not being at the office means I don't have my usual dose of coffee. At home, I very seldom drink coffee, although I really love to have it home-style (i.e. not made by the easy-to-massify drip coffee machine). In fact, for at least a month, we had not had any coffee.
Yesterday I bought 1/2 Kg of fresh ground coffee at a nearby store. Right away, I drank two large mugs of coffee. Yummy.
Today, I felt a bit more creative. One of the things that my nutriologist taught me in the last year (wow... it's been over a year I started dieting and excercising daily! Around 40Kg less. Not bad, huh? :D ) is that I was eating too little sugar, and ordered me to get at least two portions of sugar a day. So, I'm having today's second coffee. With kahl a (coffee liquor), which would be forbidden at my workplace. And I'm enjoying it terribly.
Hmh... I do hope I don't get too much sugar during vacations! ;-) (including the family dinners over holidays)

26 October 2006

Ben Armstrong: Tuxpaint GUI testing with xautomation

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing1. Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation2, imagemagick and xprop (from xbase-clients):

#!/bin/bash
testname="tuxpaint" 
root_geometry= xprop -root _NET_DESKTOP_GEOMETRY  cut -d= -f2 
root_x= echo $root_geometry  cut -d, -f1 
root_y= echo $root_geometry  cut -d, -f2 
xc=$((root_x/2-1))
yc=$((root_y/2-1))
capture_tuxpaint ()  
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc" 
   xte "mouseclick 1" 
   sleep 1
   xte "key Escape" 
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40" 
   xte "mouseclick 1" 
 
for lang in  tuxpaint --lang help  awk '$1~/^[[:lower:]]/  print $1 ' ; do
   capture_tuxpaint $lang
done

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts). Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists. In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

1 For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

2 I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.

19 March 2006

Clint Adams: This report is flawed, but it sure is fun

91D63469DFdnusinow1243
63DEB0EC31eloy
55A965818Fvela1243
4658510B5Amyon2143
399B7C328Dluk31-2
391880283Canibal2134
370FE53DD9opal4213
322B0920C0lool1342
29788A3F4Cjoeyh
270F932C9Cdoko
258768B1D2sjoerd
23F1BCDB73aurel3213-2
19E02FEF11jordens1243
18AB963370schizo1243
186E74A7D1jdassen(Ks)1243
1868FD549Ftbm3142
186783ED5Efpeters1--2
1791B0D3B7edd-213
16E07F1CF9rousseau321-
16248AEB73rene1243
158E635A5Erafl
14C0143D2Dbubulle4123
13D87C6781krooger(P)4213
13A436AD25jfs(P)
133D08B612msp
131E880A84fjp4213
130F7A8D01nobse
12F1968D1Bdecklin1234
12E7075A54mhatta
12D75F8533joss1342
12BF24424Csrivasta1342
12B8C1FA69sto
127F961564kobold
122A30D729pere4213
1216D970C6eric12--
115E0577F2mpitt
11307D56EDnoel3241
112BE16D01moray1342
10BC7D020Aformorer-1--
10A7D91602apollock4213
10A51A4FDDgcs
10917A225Ejordi
104B729625pvaneynd3123
10497A176Dloic
962F1A57Fpa3aba
954FD2A58glandium1342
94A5D72FErafael
913FEFC40fenio-1--
90AFC7476rra1243
890267086duck31-2
886A118E6ch321-
8801EA932joey1243
87F4E0E11waldi-123
8514B3E7Cflorian21--
841954920fs12--
82A385C57mckinstry21-3
825BFB848rleigh1243
7BC70A6FFpape1---
7B70E403Bari1243
78E2D213Ajochen(Ks)
785FEC17Fkilian
784FB46D6lwall1342
7800969EFsmimram-1--
779CC6586haas
75BFA90ECkohda
752B7487Esesse2341
729499F61sho1342
71E161AFBbarbier12--
6FC05DA69wildfire(P)
6EEB6B4C2avdyk-12-
6EDF008C5blade1243
6E25F2102mejo1342
6D1C41882adeodato(Ks)3142
6D0B433DFross12-3
6B0EBC777piman1233
69D309C3Brobert4213
6882A6C4Bkov
66BBA3C84zugschlus4213
65662C734mvo
6554FB4C6petere-1-2
637155778stratus
62D9ACC8Elars1243
62809E61Ajosem
62252FA1Afrank2143
61CF2D62Amicah
610FA4CD1cjwatson2143
5EE6DC66Ajaldhar2143
5EA59038Esgran4123
5E1EE3FB1md4312
5E0B8B2DEjaybonci
5C9A5B54Esesse(Ps,Gs) 2341
5C4CF8EC3twerner
5C2FEE5CDacid213-
5C09FD35Atille
5C03C56DFrfrancoise---1
5B7CDA2DCxam213-
5A20EBC50cavok4214
5808D0FD0don1342
5797EBFABenrico1243
55230514Asjackman
549A5F855otavio-123
53DC29B41pdm
529982E5Avorlon1243
52763483Bmkoch213-
521DB31C5smr2143
51BF8DE0Fstigge312-
512CADFA5csmall3214
50A0AC927lamont
4F2CF01A8bdale
4F095E5E4mnencia
4E9F2C747frankie
4E9ABFCD2devin2143
4E81E55C1dancer2143
4E38E7ACFhmh(Gs)1243
4E298966Djrv(P)
4DF5CE2B4huggie12-3
4DD982A75speedblue
4C671257Ddamog-1-2
4C4A3823Ekmr4213
4C0B10A5Bdexter
4C02440B8js1342
4BE9F70EAtb1342
4B7D2F063varenet-213
4A3F9E30Eschultmc1243
4A3D7B9BClawrencc2143
4A1EE761Cmadcoder21--
49DE1EEB1he3142
49D928C9Bguillem1---
49B726B71racke
490788E11jsogo2143
4864826C3gotom4321
47244970Bkroeckx2143
45B48FFAEmarga2143
454E672DEisaac1243
44B3A135Cerich1243
44597A593agmartin4213
43FCC2A90amaya1243
43F3E6426agx-1-2
43EF23CD6sanvila1342
432C9C8BDwerner(K)
4204DDF1Baquette
400D8CD16tolimar12--
3FEC23FB2bap34-1
3F972BE03tmancill4213
3F801A743nduboc1---
3EBEDB32Bchrsmrtn4123
3EA291785taggart2314
3E4D47EC1tv(P)
3E19F188Etroyh1244
3DF6807BEsrk4213
3D2A913A1psg(P)
3D097A261chrisb
3C6CEA0C9adconrad1243
3C20DF273ondrej
3B5444815ballombe1342
3B1DF9A57cate2143
3AFA44BDDweasel(Ps,Gs) 1342
3AA6541EEbrlink1442
3A824B93Fasac3144
3A71C1E00turbo
3A2D7D292seb128
39ED101BFmbanck3132
3969457F0joostvb2143
389BF7E2Bkobras1--2
386946D69mooch12-3
374886B63nathans
36F222F1Fedelhard
36D67F790foka
360B6B958geiger
3607559E6mako
35C33C1B8dirson
35921B5D8ajmitch
34C1A5BE5sjq
3431B38BApxt312-
33E7B4B73lmamane2143
327572C47ucko1342
320021490schepler1342
31DEB8EAEgoedson
31BF2305Akrala(Gs)3142
319A42D19dannf21-4
3174FEE35wookey3124
3124B26F3mfurr21-3
30A327652tschmidt312-
3090DD8D5ingo3123
30813569Fjeroen1141
30644FAB7bas1332
30123F2F2gareuselesinge1243
300530C24bam1234
2FD6645ABrmurray-1-2
2F95C2F6Dchrism(P)
2F9138496graham(Gs)3142
2F5D65169jblache1332
2F28CD102absurd
2F2597E04samu
2F0B27113patrick
2EFA6B9D5hamish(P)3142
2EE0A35C7risko4213
2E91CD250daigo
2D688E0A7qjb-21-
2D4BE1450prudhomm
2D2A6B810joussen
2CFD42F26dilinger
2CEE44978dburrows1243
2CD4C0D9Dskx4213
2BFB880A3zeevon
2BD8B050Droland3214
2B74952A9alee
2B4D6DE13paul
2B345BDD3neilm1243
2B28C5995bod4213
2B0FA4F49schoepf
2B0DDAF42awoodland
2A8061F32osamu4213
2A21AD4F9tviehmann1342
299E81DA0kaplan
2964199E2fabbe3142
28DBFEC2Fpelle
28B8D7663ametzler1342
28B143975martignlo
288C7C1F793sam2134
283E5110Fovek
2817A996Atfheen
2807CAC25abi4123
2798DD95Cpiefel
278D621B4uwe-1--
26FF0ABF2rcw2143
26E8169D2hertzog3124
26C0084FCchrisvdb
26B79D401filippo-1--
267756F5Dfrn2341
25E2EB5B4nveber123-
25C6153ADbroonie1243
25B713DF0djpig1243
250ECFB98ccontavalli(Gs)
250064181paulvt
24F71955Adajobe21-3
24E2ECA5Ajmm4213
2496A1827srittau
23E8DCCC0maxx1342
23D97C149mstone(P)2143
22DB65596dz321-
229F19BD1meskes
21F41B907marillat1---
21EB2DE66boll
21557BC10kraai1342
2144843F5lolando1243
210656584voc
20D7CA701steinm
205410E97horms
1FC992520tpo-14-
1FB0DFE9Bgildor
1FAEEB4A9neil1342
1F7E8BC63cedric21--
1F2C423BCzack1332
1F0199162kreckel4214
1ECA94FA8ishikawa2143
1EAAC62DFcyb---1
1EA2D2C41malattia-312
1E77AC835bcwhite(P)
1E66C9BB0tach
1E145F334mquinson2143
1E0BA04C1treinen321-
1DFE80FB2tali
1DE054F69azekulic(P)
1DC814B09jfs
1CB467E27kalfa
1C9132DDByoush-21-
1C87FFC2Fstevenk-1--
1C2CE8099knok321-
1BED37FD2henning(Ks)1342
1BA0A7EB5treacy(P)
1B7D86E0Fcmb4213
1B62849B3smarenka2143
1B3C281F4alain2143
1B25A5CF1omote
1ABA0E8B2sasa
1AB474598baruch2143
1AB2A91F5troup1--2
1A827CEDEafayolle(Gs)
1A6C805B9zorglub2134
1A674A359maehara
1A57D8BF7drew2143
1A269D927sharky
1A1696D2Blfousse1232
19BF42B07zinoviev--12
19057B5D3vanicat2143
18E950E00mechanix
18BB527AFgwolf1132
18A1D9A1Fjgoerzen
18807529Bultrotter2134
1872EB4E5rcardenes
185EE3E0Eangdraug12-3
1835EB2FFbossekr
180C83E8Eigloo1243
17B8357E5andreas212-
17B80220Dsjr(Gs)1342
17796A60Bsfllaw1342
175CB1AD2toni1---
1746C51F4klindsay
172D03CB1kmuto4231
171473F66ttroxell13-4
16E76D81Dseanius1243
16C63746Dhector
16C5F196Bmalex4213
16A9F3C38rkrishnan
168021CE4ron---1
166F24521pyro-123
1631B4819anfra
162EEAD8Bfalk1342
161326D40jamessan13-4
1609CD2C0berin--1-
15D8CDA7Bguus1243
15D8C12EArganesan
15D64F870zobel
159EF5DBCbs
157F045DCcamm
1564EE4B6hazelsct
15623FC45moronito4213
1551BE447torsten
154AD21B5warmenhoven
153BBA490sjg
1532005DAseamus
150973B91pjb2143
14F83C751kmccarty12-3
14DB97694khkim
14CD6E3D2wjl4213
14A8854E6weinholt1243
14950EAA6ajkessel
14298C761robertc(Ks)
142955682kamop
13FD29468bengen-213
13FD25C84roktas3142
13B047084madhack
139CCF0C7tagoh3142
139A8CCE2eugen31-2
138015E7Ethb1234
136B861C1bab2143
133FC40A4mennucc13214
12C0FCD1Awdg4312
12B05B73Arjs
1258D8781grisu31-2
1206C5AFDchewie-1-1
1200D1596joy2143
11C74E0B7alfs
119D03486francois4123
118EA3457rvr
1176015EDevo
116BD77C6alfie
112AA1DB8jh
1128287E8daf
109FC015Cgodisch
106468DEBfog--12
105792F34rla-21-
1028AF63Cforcer3142
1004DA6B4bg66
0.zufus-1--
0.zoso-123
0.ykomatsu-123
0.xtifr1243
0.xavier-312
0.wouter2143
0.will-132
0.warp1342
0.voss1342
0.vlm2314
0.vleeuwen4312
0.vince2134
0.ukai4123
0.tytso-12-
0.tjrc14213
0.tats-1-2
0.tao1--2
0.stone2134
0.stevegr1243
0.smig-1-2
0.siggi1-44
0.shaul4213
0.sharpone1243
0.sfrost1342
0.seb-21-
0.salve4213
0.ruoso1243
0.rover--12
0.rmayr-213
0.riku4123
0.rdonald12-3
0.radu-1--
0.pzn112-
0.pronovic1243
0.profeta321-
0.portnoy12-3
0.porridge1342
0.pmhahn4123
0.pmachard1--2
0.pkern3124
0.pik1--2
0.phil4213
0.pfrauenf4213
0.pfaffben2143
0.p21243
0.ossk1243
0.oohara1234
0.ohura-213
0.nwp1342
0.noshiro4312
0.noodles2134
0.nomeata2143
0.noahm3124
0.nils3132
0.nico-213
0.ms3124
0.mpalmer2143
0.moth3241
0.mlang2134
0.mjr1342
0.mjg591342
0.merker2--1
0.mbuck2143
0.mbrubeck1243
0.madduck4123
0.mace-1-2
0.luther1243
0.luigi4213
0.lss-112
0.lightsey1--2
0.ley-1-2
0.ldrolez--1-
0.lange4124
0.kirk1342
0.killer1243
0.kelbert-214
0.juanma2134
0.jtarrio1342
0.jonas4312
0.joerg1342
0.jmintha-21-
0.jimmy1243
0.jerome21--
0.jaqque1342
0.jaq4123
0.jamuraa4123
0.iwj1243
0.ivan2341
0.hsteoh3142
0.hilliard4123
0.helen1243
0.hecker3142
0.hartmans1342
0.guterm312-
0.gniibe4213
0.glaweh4213
0.gemorin4213
0.gaudenz3142
0.fw2134
0.fmw12-3
0.evan1--2
0.ender4213
0.elonen4123
0.eevans13-4
0.ean-1--
0.dwhedon4213
0.duncf2133
0.ds1342
0.dparsons1342
0.dlehn1243
0.dfrey-123
0.deek1--2
0.davidw4132
0.davidc1342
0.dave4113
0.daenzer1243
0.cupis1---
0.cts-213
0.cph4312
0.cmc2143
0.clebars2143
0.chaton-21-
0.cgb-12-
0.calvin-1-2
0.branden1342
0.brad4213
0.bnelson1342
0.blarson1342
0.benj3132
0.bayle-213
0.baran1342
0.az2134
0.awm3124
0.atterer4132
0.andressh1---
0.amu1--2
0.akumria-312
0.ajt1144
0.ajk1342
0.agi2143
0.adric2143
0.adejong1243
0.adamm12--
0.aba1143

5 December 2005

Enrico Zini: My company

I had an interesting conversation in which I was explaining my current work situation. It might be fun to share:
< mornfall> you are working on a timed contract?
< enrico> I'm probably worse than a timed contract: I had to setup a company
< enrico> The government is restricting them so badly that they couldn't hire
          me even temporarily, and they had to buy software from me
< enrico> so I had to become a company
< enrico> I AM THE COMPANY
< mornfall> oh duh
< enrico> I'm my employer
< enrico> and my employee
< enrico> in all this, the government proudly shows statistics of lots of new
          companies being created in Italy as a sign that our economy is so
          good
< mornfall> be nice to your employee :-)
< mornfall> hmh
< enrico> so last friday there was a general strike and my company sent a
          press release to the major labor union telling them that the CEO
          together with all the employees decided to fully take part in the
          strike
< enrico> Signed: Enrico Zini, directory of the company Enrico Zini;
          Employees of the company Enrico Zini: Enrico Zini
< mornfall> that's getting tough
< enrico> I'm very nice to my employees, hes :)
< enrico> but sometimes I wonder if masturbation could be considered sexual
          harassment from my boss
< mornfall> LOL
< mornfall> you need to appoint a secretary
< enrico> I have one: Enrico Zini.  He's a bit messy, though.
< enrico> The only thing which is not called Enrico Zini is the accountant.
< enrico> Incidentally, he's called Vincenzo Zini, but he's isn't a relative
          of mine :)
< mornfall> in that case i think the boss is harassing the secretary not the
          other employee
< enrico> However, he is member of the local LUG and has a Jabber account :)
< mornfall> fun :)
< enrico> oh, ok.  But the employee might be harassing the secretary, or the
          secretary is harassing the employee and the boss
< enrico> IDEA
< enrico> Tonight I'll propose an orgy with the boss, the secretaries and the
          employees!
< enrico> (but not the accountant)
(blogged with mornfall's permission)