Noting comments by bubulle and Debian-uk preparations, I've started looking at flights for Debconf8 with an eye to actually making a booking.
There appears that there will be a variety of Debian-ites hanging around Madrid airport and catching an apparently very limited number of flights to Buenos Aires as I seem to only be able to find 2 flights a day between Madrid and Buenos Aires.
Bubulle notes a connection from Paris to Madrid, I (and most of the UK team) would need a connection from London to Madrid. For some bizarre reason, leaving from Gatwick is more expensive than leaving from Heathrow. That's a PITA for me because my return flight home leaves from Gatwick.
More annoying is that the evening flight is much more expensive than the (very) early morning flight. So much so that it comes out at almost double the cost of even a relatively expensive hotel for the night.
My current ruminations revolve around:

flight  780.62   	- Expedia Special Fare

07:25 Depart London (LHR) 

Arrive Buenos Aires (EZE) 19:25 	Fri 1-Aug



13:25 Depart Buenos Aires (EZE)

Arrive London (LHR) 10:05  tip+1 day 	Sun 17-Aug

The arrival back in London is good for me because it provides plenty of time to get between Heathrow and Gatwick, even on a Sunday.
I guess London is a little further from Madrid than Paris - my trip comes out at over 1,000 compared to 900 from Paris. Can't really justify a return Eurostar for that difference.
(Yes, I'm travelling out for DebCamp too.)

Who has already been using dd for endless data transfer without really knowing what is happening ? That is rather annoying. Sure, when the target is a normal file, you can always use

watch ls -l target

But, that won't tell you the rate of transfer, and it won't work if the target is a special file (device, pipe, ...). Fortunately, dd accepts the USR1 signal to print out some small statistics... Well, combining that with the watch tricks gives this:

watch killall -USR1 dd

And there you go, dd is now regularly printing out statistics. Pretty neat, isn't it ?

There is currently a lot of speculation about the future of Windows following the massive failure of Vista in the market. One theory that is being discussed is that Microsoft will cease kernel development and adopt a Unix kernel in the same way that Apple adopted a BSD based kernel. I predict that MS in it’s current incarnation (*) will never do that. Having an OS kernel that enables easy porting of code to/from other platforms is entirely against their business model which relies on incompatibility to lock customers in. Whatever kernel MS use, it has to be incompatible in some ways with everything else. One easy way of achieving this would be to have a shared object (DLL) interface published and have the interface between the libc and other libraries and the kernel be undocumented and ever-changing (simply renumbering the system calls on every minor version increment would be a good start). The DLL interface could then have the complex APIs that MS loves to force on their victims (see Stewart Smith’s post about getting a file size in Windows for an example of the horror [1]). The advantage of this approach would be that MS could cease developing an OS kernel (something that they were never much good at) and concentrate on owning the proprietary DLLs. There would be nothing stopping them from using a Linux kernel for this, as long as they release all source to the kernel they use (including the patch to renumber the system calls) they would be within the terms of the GPL. My specific prediction is that some time between Jan 2011 and Dec 2016 Microsoft will release systems with the majority of the kernel code coming from BSD or Linux as their primary desktop and server operating systems. Could people who disagree please make specific predictions for the future (including dates and actions) so that we can determine who was most accurate. (*) For future incarnations of Microsoft after chapter 11 or being split in the way that AT&T was there seems no possibility to predict their actions.

• [1] http://www.flamingspork.com/blog/2008/02/11/getting-a-file-size-on-windows/

Share This

I've been writing about Git a bit lately.

I've decided to switch some of my Debian work over to it to start with, as well as some of my other projects.

Although I was thoroughly frustrated with Git a year ago, now I am quite pleased with it. What's different? The documentation is a LOT better. So far I have only found one manpage (git-show) that omits lots of its options. The system is friendlier, keystroke-happier, and powerful.

Compared to Mercurial, I've found some nice things:

In-directory branching. I didn't expect to care about this, since both git and hg permit lightweight clones. But it turns out to be so easy to use that it is great. Especially since I don't have to setup multiple branch repos on the server. I really like this. Note that "hg branch" is not the same as a git branch, and see the discussion on the hg lists about renaming that before 1.0.0 for why.

Flexibility in getting things around. Plain HTTP works fine (no static-http:// hack). ssh. git daemon. rsync. Very slick.

Performance. Surprisingly, git actually feels faster than Mercurial, especially when pushing or pulling. I didn't expect that.

Tags. They seem smarter in git. No more merging of .hgtags all the time. Also I like that I can attach a message to a tag and sign it.

All that power. There is a *lot* that Git can do. I should have been taking notes about it all.

My main complaint is still that Git doesn't have something as nice as "darcs send". Mercurial doesn't either, but it's a bit closer. Git has moved closer, but still has room to improve on that.

So I have set up git.complete.org and am starting to publish my Debian stuff on Debian's alioth server as well.

Also, hg-fast-export in the fast-export project is *awesome*. Branch-aware and everything. It made a perfect Git version of my Mercurial work.

I’m starting all over again. New domain, new blog. I will try to dig up and repost all of the great things I wrote earlier. Posts about code, debian and pink ponies. I can also say that I’m back on planet.debian.org and on planet.samfundet.no. The link to my blog on women.debian.org should also be fixed soon.

It's rare that one does something for themself, and entertainment has happen. Yesterday I had been to a cabaret and did take my other half with me. With the thought, it doesn't always have to be Resetarits, Gunkl or Dorfer I chose "Wegen Renovierung offen" ("Opened due to renovation") from and with Gery Seidl–being the child of a master-builder and having done my A-levels at a high school for structural engineering it wouldn't had been a better fit thematic wise. The role of the construction supervisor Roman Schweißer is catching right from the start, and that's not only for insiders but also for people who generally have no connection to this business branch; a human like everyone else: The internal conflict between what his boss tells him and what his heart tells him, different approaches to get that done, and at the same time trying to also work on his shaken relationship isn't easy—but for sure it's extremely entertaining and worth seeing. My other half didn't regret it to got convinced by me. Dates are still a lot left, partly sold out, partly though also from other projects to which I'm looking forward to. It's rare that a still young performer is not only just able to catch up with oldsters but also to perform with them on stage.

I'm very happy to announce that Canonical are hosting a Squid meetup in London this coming Saturday and Sunday the 1st and 2nd of March. Any developers (in the broad sense - folk doing coding/testing/documenting/community support/) are very welcome to attend. As it is a weekend and a security office building, you need to contact me to arrange to come - just rocking up won't work :). We'll be there all Saturday and Sunday through to mid-afternoon. The Canonical London office is in Millbank Tower http://en.wikipedia.org/wiki/Millbank_Tower. So if you want to come by please drop me a mail. We'll be getting very technical very quickly I expect - for folk wanting a purely social meetup, I'm going to pick a reasonable place to meet for food and (optionally) alcohol on Saturday evening - I'll post details here mid-friday.

Just a minor update on AcmeCal. The new feature is the Import/Export frameworks. At the moment I can export to an YAML stream of the internal representation and import from the same YAML string or from a subset of the iCal standard. At the moment no unfolding of recurrent events take place. Calling it a framework might be a bit of a stretch but support for other formats should be as easi as handling these formats. To prove that everything is to be considered unstable I renamed the scripts from acme-(\w+)cal to acmecal-$1. Download AcmeCal version 0.2

That's it...

Student for now :-)

Damn it, I should had wrote about it a couple of days ago. Anyway, it happened last Friday (20080222), my last day at work. After 4.5 years (exactly 4 years, 6 months and a week), I quit my job to dedicate more time for my "supposed" last year studying Computer Science at the University.

In a far far away galaxy...

During the translation of packages' descriptions, when I found something that looks like a typo or a wrong reference I try to report wishlist bugs and, when possible, provide patches, I know this is somewhat noisy, it is just to register the fact, so Smith Review can also spotted it, sorry for the noise. :-)

BTW, I would still vote for a genius if we are going to elect a mascot.

Thanks: frolic

In 1996 Peter Gutmann wrote a paper titled “Secure Deletion of Data from Magnetic and Solid-State Memory” [1]. In that paper he mentions the fact that the contents of RAM last longer at lower temperatures and suggests that data could be retained for weeks at a temperature of -60C or lower (while 140C causes rapid data loss). The paper also addresses issues of data recovery from hard drives, but given that adequate CPU power for encryption is available recovering data from a disk shouldn’t be an issue unless thee attacker can get the key to decrypt it or crack the algorithm - so disk recovery is not a hot issue at the moment. Recently some researchers at Princeton University have published a paper describing in detail how to chill RAM to make it keep its data after a power cycle and even after being installed in a different computer [2]. This attracted a lot of attention, while Peter’s paper described the theoretical concept (in great detail) the Princeton group showed how to implement the attack using materials that are commonly available. Most of the analysis of this misses some fundamental points. Any suggestion that you can wipe the RAM on power failure or on boot misses the point entirely. If an attacker can chill a DIMM and then remove it from the system then there is no chance for it to be wiped. Maybe if you had security on the PC case to detect case opening (some servers have a basic version of this) such things would do a little good, but it shouldn’t be difficult to bypass in most cases. Another common flawed analysis is to suggest that this is no big deal because sniffing the memory bus has been possible for years. While it has always been possible for government agencies and companies who design motherboards to sniff the bus, for most potential attackers it has been overly difficult. When considering the effectiveness of a security system you should first consider what your threat model is. Who is going to attack you and what resources will they be willing and able to devote to the attack? An organisation that is prepared to use expensive equipment and highly trained people to break your encryption probably has other methods of gaining access to your secret data that are easier and cheaper. The research from Princeton suggests that I could perform such attacks with my spare time and with equipment that is very cheap. I’ve been idly considering doing this to an old PC just for fun! Therefore I have to assume that everyone who has the same amount of skill and money as me can potentially compromise my data if they capture one of my machines. It is still most likely that if anyone steals my laptop they will want to sell it and use the money to buy drugs. I don’t think that I have any data that is anywhere near valuable enough to justify a targeted mugging. But my procedures (in terms of changing passwords etc) in the case of my laptop being stolen now need to be scaled up due to the ease in which data might be compromised. The best way of dealing with this would be to have the decryption keys locked inside the CPU (stored in registers or memory that’s locked in the CPU cache). The possibility of getting a modern CPU to operate at any temperature approaching -60C is laughable, and the CPU is a well contained package that can operate on its own and is difficult to attack. This would make things significantly more difficult for an attacker while requiring little effort (in fact it might be possible to lock data in the CPU cache already in which case a software change is all that is required). Update: A comment by Mike made a good point about CPU cooling. Toms Hardware performed an overclocking experiment (from 3.2GHz to 5.25GHz) and used liquid nitrogen cooling [3]. It might be possible to cool a CPU core to -60C in a reasonably small amount of time. But I still believe that it would raise the bar enough to make it worth doing. Update2: Thanks Jaime for the spelling advice.

• [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html


• [2] http://citp.princeton.edu/memory/


• [3] http://www.tomshardware.com/2003/12/30/5_ghz_project/index.html

Share This

It’s done, we have new releases of grml, the Debian-based Linux Live-CD for sysadmins and texttool users:

grml 1.1 (32bit) - Codename Skunk

grml64 0.2 (64bit) - Codename Schwammerlklauber

grml-medium 0.1 (32bit) / grml64-medium (64bit) - Codename Pfuh

It’s the first stable release being based on our new build-framework grml-live which itself is based on FAI (Fully Automatic Installation). Thanks to grml-live we can provide you a new grml flavour grml-medium which tries to close the gap between grml-small and grml. As usual you’ll get software and kernel updates, many new packages and features plus additional hardware support. We are using LZMA compression for squashfs and provide several additional kernel modules like atl2, iscsitarget, madwifi and (for the first time) loop-aes. Oh and the grml release is known to work fine on the Asus Eee PC - LAN, WLAN and webcam working out-of-the-box! Find all the glory details about the new releases in above mentioned release notes or just visit grml.org. For german readers there’s an article about the new release at pro-linux.de. BTW: On the next weekend (1st and 2nd of march) we - the grml team) - will present the new release on Chemnitzer Linuxdays at the grml booth. grml-CDs, grml-shirts und (new!) “ready to go grml-usb-pens” will be available as well as the chance to talk to us in reallife. So, we wish you a fast download and hope you enjoy the new release!

Is XFS that bad? Well, at least with default settings, XFS on Debian seems to be blown away by ext3 completely in terms of speed. I don't mind 1.5x slowdown, maybe even 2x, but 20x is a show stopper. I am already using ext3 for any pbuilder builds, because it's a difference to wait for 30s with XFS, compared to 3s with ext3 to extract the base image. And I'll probably switch to ext3 completely, unless someone finds a way how to fix this.

I recently got burned by this when running Sage on my computer, because it compiles a lot of Python files when started for the first time. Normally it should take roughly 15s, but instead it took 6 minutes on my comp and then it triggered a so far undiscovered bug in Sage, that I reported.

Michael Abshoff, the release manager of Sage, suggested that something is FUBAR (Fucked Up Beyond Any Recognition) on my shiny Debian amd64 sid system running on Intel Core Quad, so I said no way, because I really care about this machine, as I use it for larger finite elements calculations and other stuff (like compiling huge deb packages in parallel, like paraview).

So I offered a bet, that I give him an access to this compter, he finds the problem and if it's a problem in my Debian configuration, I'll write to this blog that I am lame, while if it's a problem in Sage, he will write to his blog that he is lame. And I was smiling to myself, how good I am and that I will have some fun too reading planet.sagemath.org with the top post from Michael saying that he is lame.

But then I remembered my old struggle with cowbuilder and XFS and I stopped smiling. See e.g. this wiki I created half a year ago. Something is FUBAR with XFS and Debian. I also asked on the Czech server Root, that is famous for having a lot of experts willing to share their knowledge, and it was quickly revealed, that the problem is with the "nobarrier" option of XFS (my post is here, but it's in Czech).

First, on that amd64 machine, the above problem was fixed after issuing this command:

mount -o remount,rw,nobarrier /dev/sda3 /home/

(notice the "nobarrier" option). You can read some background behind this on the lkml list. Unfortunately, I also have my laptop, and there I already use this "nobarrier" option, and it doesn't help at all. I just created a new ext3 partition and verified that on my laptop, ext3 is around 10x faster than XFS with nobarrier (that was supposed to fix this). I use the latest 2.6.24 kernel from unstable on both.

Time to move from XFS to ext3 on my laptop? Seems like that. I'll leave XFS on the other machine, because I know some other peole have good experience with XFS and the "nobarrier" option seems to fix the problem there.

But as to the bet, yeah, I am lame and I should still learn a lot from Michael. :)

After 10 days of nice holidays, I'm back. I was totally offline, so I had to read some hundred of mails first, which is done now. For a good restart, I've fixed a bunch of bugs in awesome and released 2.2-rc2 version. I've also migrated apt-build repository on Alioth from Subversion to git. I've uploaded a new version of this one with some patches, and a also put in the archive a new version of the mp32ogg package. Next step will be to move my packages repositories which are in my global home Subversion repository, to my own git repositories on Alioth.

Ever since I started University, I've been a member of the Institution of Electrical and Electronic Engineers. Although I don't really do what you would call "Engineering" any more, I like to read the IEEE Spectrum magazine and some of the Computer society journals are quite relevant to what I do. However, this year the IEEE have produced what is, without a doubt, one of the most shithouse online ordering systems I have ever had the misfortune of trying to use. To start with, if you happen to go to the account login screen with cookies disabled, you get a page that is utterly blank. I've seen a lot of ways to fail to handle cookies, but I think the completely blank page is a first for me. Once you work out what's going on and log in, you're presented with a long and painful journey through a series of "checkout" pages, mostly alike. I think I got presented with my list of journals about four times. After navigating that pest, it comes up with this little gem when you start the credit card processing step: Then, every time you input practically anything into the form, it does a Javascript submit and does things to the form. For example, when you enter your credit card number, you get a form back that has blanked out all but the last four digits of the card number. OK, a little dumb, but not spectacularly so. Although, when you're a quick typist and have filled in the next three fields while the web browser was playing footsie with the slow-as-molasses web server, only to have that data wiped out when the page refreshes, is a bit of a pest. Far more annoying is when you start entering your address "for verification purposes". Here, you get a form resubmit every time, presumably to update the form based on (for example) your selected country, but not a lot changes. Even though I picked Australia, I still got a pull-down with all of the the US states in it. You could short-circuit all this with the "choose existing address" option, except that (despite me being logged in) my existing addresses aren't in a select box, but in a separate pop-up window (which didn't actually display anything after all). In short, the IEEE's online renewal system is a disgrace, and is an embarrassment to what is purportedly a technical organisation.

Today I've noticed that my last post was on August and I've decided that I'm going to try to keep this blog alive. Since this summer I've left the University and now I only have two jobs... my daily work and my son; I believe that things are going better at a personal level, but the truth is that lately I have near zero time to devote to Debian and Free Software in general. As I don't want to leave the FLOSS world and I'm still able to do some sysadmin related tasks at work and at home I've decided that I'll try to reserve some time for blogging about them. I'm also thinking about starting a blog and a wiki in Spanish, mainly to be able to publish some of the documents I write at work about our installations, the advantage for me is that I can publish them with a little revision and that is much faster than translating them into English. Anyway, before creating new blogs my first task is to finish my home server migration; I'm moving all the services that were running on my old PowerBook (PowerPC @ 400Mhz, 378MB of RAM, 10 GB HD) to my other PowerBook (PowerPC @ 1Ghz, 768MB of RAM, 60GB HD), as I haven't used it for ages and I still use a lot the old machine. On the move I plan to change a lot of things, the machine is going to run multiple vservers and I plan to change a lot of the software I was using, always trying to simplify the maintenance and/or get more performance from the new machine:

• The internal network will use dnsmasq for DNS and DHCP (replacing bind9 and the dhcp3-server).
• My authoritative nameservers are going to be served by powerdns using the named backend for the primary servers and sqlite3 for the secondary domains.
• I'm going to move all my webservers from apache2 to nginx and fast-cgi (the speed and memory gains are huge at work).
• I plan to move all my repositories from Subversion to git, including this ikiwiki installation.

I'll try to blog about this new installation once it is done.

As you probably know (well, in case you read d-d-a (hello man-di)), we got two new people as FTP Assistants. While I disagree with the way it went, it’s a good thing to not have NEW, removals and override changes a (pretty much) one man show. OTOH I am also pretty reluctant to having others do NEW, as the long time I am now doing it makes me feel about it like - well “it’s my baby”, or something like that. It’s just that I processed a lot of packages, rejected even more and (mostly) had fun doing it. (And I hate to share fun, HA :) ). But I understand the need of having more people doing it, so today I gave an introduction to Thomas and Kalle. Now they at least know where to start. And while that took somewhere around 2 hours - its still only an introduction. I bet there will be many more questions when they do more than just reading the large amounts of text I flooded into the ftp teams IRC channel. :) But that should work fine, I am online most of the day - and then there are the other ftpteam-members and ftpmasters in the channel, someone should be able to respond sooner or later. :) And now some real content. The ultimate way to get a totally bug free Debian:

for i in $(dak control-overrides -t dsc -l awk ' print $1 '); do
 dak rm -m "Cleanup" -C package $i
done

Don’t try this at home, kids. (Yes, a nice DELETE FROM $correct_table in projectb also works, but isnt as much fun! The above gets you nice and pretty logs in the removals.txt and also nice and pretty mails to the package address!)

Recently, the EFF reported that the European commission had responded to a request by European Parliament member Satu Hassi about tracking dots in printers. European Commissioner Franco Frattini replied that tracking dots may constitute a human rights violation saying that:

"..to the extent that individuals may be identified through material printed or copied using certain equipment, such processing may give rise to the violation of fundamental human rights, namely the right to privacy and private life. It also might violate the right to protection of personal data."

Intriguingly, the request text includes a mention to and link to the Seeing Yellow project I started last year as an example of the fact that consumers have complained to printer manufacturers and that these complaints have fallen upon deaf ears. Everyone who called their printer manufacturer in response to Seeing Yellow deserves come credit for the raised visibility to the issue that we've created and the set of actions that have brought the issue this far. Please, keep it up! If you've not complained to your printer manufacturer, visit Seeing Yellow and call today.