I have just come back from a half week stay at the Hilton Indian Lakes resort (which is the second time in a month that I have stayed at a golf resort and club and proceeded to spend 9 hours a day in a windowless conference room). On Thursday night, an ex Chicago native wanted to show us the traditional Chicago pizza (which can be delivered, half cooked, and frozen, via Fed-Ex, anywhere in the lower 48). Google Maps to the rescue! One of the attendees had a car, and we piled in and drove to the nearest pizzeria. It was take out only. We headed to the next on the list, again to be met with disappointment; since making the pizza takes the best part of an hour, and we did not want to be standing out in a chilly parking lot while they made out pizza. So, I strongly advocated going to Tapas Valencia instead, since I have never had tapas before. Somewhat to our disappointment, they served tapas only as an appetizer, and had a limited selection; so we ended up ordering one tapas dish (I had beef kabobs with a garlic horseradish sauce and caramelized onions), and my very first paella (paella valencia), with shrimp, mussels, clams, chicken, and veggies. We ate well, and headed back to the hotel. As we parked, and started for the gate, I realized I no longer had my wallet with me so back to the restaurant we went. The waiter had not found the wallet. Nor had the busboy. The owner/hostess suggested perhaps it was in the parking lot? So we all went and combed the parking lot once, twice. At this point I am beginning to think about the consequences I can t get home, because I can t get into the airport, since I have no ID. I have no money, but Judy can t wire the money to me via western union because I have no ID. I need money to buy greyhound tickets to get home on a bus and then there is the cancelling credit cards, etc. Panic city. While I was on my fourth circuit of the parking lot, the owner went back and checked the laundry chute. I had apparently carelessly draped the napkin over my wallet when paying the tab, and walked away and the busboy just grabbed all the napkins, wallet and all, and dumped it down the chute. Judy suggests I carry an alternate form of ID and at least one credit card in a different location than my wallet for future trips. If that was not excitement enough, yesterday, I got on the plane home, uneventfully enough. We took off, and I was dozing comfortably, when there were two loud bags, and the plane juddered and lister to the port. There was a smell of burning rubber, and we stopped gaining altitude. After making a rough about turn with the left wing down, the pilot came on the intercom to say We just lost our left engine, and we are returning to O Hare. We should be in the ground in two minutes . Hearing the in , a guy up front started hyperventilating, and his wife was rubbing his back. My feelings were mostly of exasperation, I had just managed to get myself situated comfortably, and now lord only knows when we would get another aircraft. When we landed, the nervous dude reached over and kissed his wife like he had just escaped the jaws of death. And he asked if any of us knew statistics, and if we were fine now. (I was tempted to state that statistics are not really predictive, but hey). It was all very pretty, with six fire engines rushing over and spraying us with foam and all. When we got off the plane the nervous dude headed straight to some chairs in the terminal, and said his legs would not carry him further. He did make it to the replacement plane later, though. Turns out it was a bird flying into the engine that caused the flameout. Well, at least I have a story to tell, though it delayed getting home by about three hours.

Thursday evening, when I came from work I found my nslu2 not working. It is/was a router and a local mirror. I tried to understand what's going on, but I couldn't. Everything looked fine, except that it did not resolve any addresses and the ping to my provider was not giving any results.

I tried to restart dnsmasq, although it seemed it was running fine, and then, in a desperate gesture (after trying to understand what was going on) I thought of restarting networking. I got locked on the outside and was forced to restart the system.

Everything looked to come back to normal. Since it was late, I set myself to investigate the next morning what happened. But yesterday morning, the network was again down and the slug was inaccessible.

Since the only way to restore sanity in such a situation (because I don't have a serial console on the slug) was to reset and hope for the best, I did that.


The slug didn't start anymore. It seemed to cycle through boot -> reset -> reboot. I tried to see what was going on and connected the hard disk to my laptop. The filesystem was clean, although /var/log/boot.0 was a directory (and that directory had the same content as /var/lib/dpkg/info). I manually removed that, but that didn't make the slug boot.


It seems my slug is kind of dead.

Now I would like to know if is there any way to do remotely what flash-kernel does from within debian.

I recently wrote some suggestions about appropriate swap space sizes [1], the main point being that the advice to use 2* RAM size never really applied to Linux and a system that actually has swap space equivalent to 2* RAM in use will usually be too slow to use (and you are better off having the kernel OOM handler kill some processes). There were a number of responses to that post, Ingo suggested that significantly larger amounts of swap can be used for compiling [2]. I have had similar experiences when compiling KDE long ago on a machine with 96M of RAM. Even in 1999 96M was not a lot of memory for a machine running KDE, and when compiling MICO (the CORBA system) a single G++ process could use more than 96M of memory. Obviously a lot of swap was used, but performance didn’t seem too bad. I avoided touching the keyboard or mouse (so most of the X server was paged out) and allowed all memory to be used by the build process. It seems to me that the build process is not as intensive as other processes in terms of swap use because it is a chain of processes that call each other. You may have several instances of make running (launching a new instance for each directory as you descend the build tree is common) and then a gcc process that launches some child processes. But unless you use the -j option to make at most times during the build there is only one process with any serious work to do. So the parent processes can be entirely paged out to make room for the process that is doing the work. A counter example is a shell server that has many interactive users, on such a machine if it runs slow then the users start opening more sessions so that they can perform other operations while waiting for a slow command to complete, opening more sessions uses more memory and makes the problem worse. Ingo notes that he uses several hard drives to give good performance. The priority of swap spaces is listed in /proc/swaps and can be set by pri=N in the options field in /etc/fstab. If you have multiple hard disks then the performance of swapping on a system that is being used intensively for multi-tasking will increase significantly at a rate that would hopefully be close to linear scaling with the number of disks. If a system only has one active process that is being paged (which might be reasonably common as part of a build process) then the performance benefits for reading will be significantly reduced.

• [1] http://etbe.coker.com.au/2007/09/28/swap-space/


• [2] http://blog.windfluechter.net/index.php?/archives/71-Swap-sizes.html

Share This

SLO2 (FTA 13e) is advertising a sports documentary called RAAM 2007 today (Saturday 10 November) at 1630 CET - that might be the Race Across AMerica and there’s no telling what language it will be in! RAI Sport Sat (FTA 13e)
has coverage of the 4 Days of Milan stage from Montichiari to Castellana on Sunday 11 November at 1700 CET. I can’t find this race on the UCI calendar - does anyone know it?

Only an outline so far but most of this code already exists in Emdebian SVN.

1. C/C++ application: langupdate using libapt-pkg and libglib2.0-0
   
   • Reads supported locales and silently installs only the supported translations for all installed packages, with fallback support where configured.
   
   
   • Silently removes all translations for all unsupported locales.
   
   
   • First run in langupdate postinst
   
   
   • Removes package translations on the next run after package removal.
   
   
   • Separate /etc/langupdate/tdeb.sources.list and /var/cache/langupdate/lists/ to keep apt cache size down. Manual changes will be overwritten so maybe it ought to live in /var/ or /usr/share/.
   
   
   • One source for each locale root, main_en, main_fr, main_pt etc. All sources maintained by langupdate directly, according to the list of supported locales.
   
   
   • Each source contains all translations for locales within scope: en_GB in en, pt_BR in pt etc. to support fallback correctly.


2. XS-Package-Type: tdeb with a file suffix of .deb (not .tdeb) to reduce the number of patches needed for a working implementation.


3. Server-side perl script: langmigrate that parses the .changes file:
   
   • Removes tdebs from existing repository.
   
   
   • Moves incoming tdebs into new layout.


4. No descriptions, no dependencies. All tdebs are Priority: extra and Architecture:all. Possible support for a tdeb1 version suffix for updates that are not yet in Debian. (Allows for translation updates without package uploads.)


5. Plan to remove (or support an alternative package) dependency on libglib2.0-0 but OK for Emdebian at the moment due to targetting of GPE.


6. langupdate itself Priority: optional and not part of the default emsandbox


7. langupdate is a native package, uploaded to and maintained in Emdebian. Migrate into Debian once infrastructure is ready.


8. langupdate has little or no output, only a help option and possibly support for --clean but everything else automated.

This is built on the emlocale method (from emdebian-tools) and emlocale will be modified to fit this plan in 0.5.4.
langupdate (and langmigrate) cannot be part of emdebian-tools themselves, so will be separate packages.
(and yes, it is 4am, I'm not sleeping well due to a viral infection.)

Ian Lance Tailor started a discussion that has in the meantime reached Planet Debian via Miry and Giacomo. The single-threaded memory model is the only sane choice for languages that are as close to the "metal" as C and C++ are. For a multi-threaded model to work, the compiler needs to have intrinsic knowledge of "locking", and it needs to emit the appropriate code around all accesses to variables that cannot be accessed atomically (which also means that signal handling does not work — the signal might arrive in a critical section). Java uses such a model. In the language, there is the "synchronized" keyword, which can be used either as a modifier on a method definition (locking the object the method is called on), or before a block (locking an explicitly specified object). The lock is recursive, so calling another "synchronized" method on the same object works fine, leaving the last one finally unlocks the object. Memory consistency is achieved by flushing the object before unlocking (so accessing an object that another thread may use without locking it is still undefined behaviour — but class authors can avoid that by allowing access only through "synchronized" methods). I doubt we want the same in C/C++. For one, it adds a recursive lock to each instance of a class or struct, whether needed or not, since the compiler cannot rule out that some code might want to use this object as a lock. Also, the object inclusion and inheritance rules are quite different, as Java does not have inclusion, and only allows simple inheritance. Basically, if I were to emulate Java's rules, I'd need a "virtual" base class to provide the lock, which is a lot of extra overhead since every derived class now needs to keep the offset to the most derived class. The other two big show stoppers are the "intrinsic" knowledge of locking that the compiler must have (it needs to know how to embed a recursive lock into an object, which is an operating-system dependent structure as it stores some thread identifier for the current holder of the lock) and that it becomes a lot more difficult to write signal handlers, as you need to avoid any code that might implicitly lock some object (which is true already, but there is no implicit locking). Java can do that, as they have a virtual machine that provides locking primitives and object lookup (so they can keep the lock separate). There is a change to the memory model I'd like to see though: the concept of an I/O buffer that behaves like regular memory (so load/store coalescing/reordering is allowed), but will be flushed before volatile accesses and re-read afterwards (optionally, with finer grained control). This would work for both hardware accesses (where the volatile access triggers some hardware) and for "hosted" environments (where the compiler assumes that system calls perform volatile accesses), and still allow most optimisations like writing in the hardware's natural bus width. If you want to write reliable multi-threaded code with current compilers, there are two simple rules:

1. any data structure shared by multiple threads needs to be marked volatile
2. any access to a shared data structure needs to be guarded by a lock

The accesses to the shared data structure are ordered with regard to the locking functions and cannot be optimized out, which is exactly what you want. The appropriate mental model is that anything that is not declared volatile (or handled by a platform locking primitive) cannot be seen by the other threads.

The search for the ideal mobile text editing device is over. While the price was well over my original budget, we’ve since gone ahead and splurged on two new Eee PCs: one for me, one for my wife. In the end, I think it will be worth it because these systems are capable of far more than just editing text. Now comes the challenging part. Xandros is the default OS and we want Debian on it instead. I have started supplementing the system with packages from Etch and Etch-backports using apt pinning, but already I have noticed some cracks beginning to develop: with pure Xandros, an SD card was automounted when it was inserted. Now it fails. Also, the Network utility no longer launches. I can work around these glitches for now, but it is plain that in the long term this Xandros/Etch hybrid is going to be more grief than it is worth. To that end, enter Debian-eeepc. Building on the work started by timbobsteve and drawing from the collective experience of the Eeeuser.com community we will make a debian-live cd + debian-installer to install Debian (as pure as possible—obviously the kernel is going to be our most contentious issue) on the device. So stay tuned for more articles on that work-in-progress. And how does my new toy shape up for mobile text editing so far? I’m delighted! For starters, this article was drafted on the bus home from work. The keyboard, while small, is still quite usable for touch-typing, the display is crisp and bright, and the size is just perfect for the cramped quarters of a public transit bus seat. But beyond just editing text, I have loaded up the system with all of the tools that go around it: subversion, git, ruby, gcc, meld, etc. I’ll be able to manage a fair amount of development on the bus, with the exception being really large builds that will continue to be done on remote build systems.

Explaination for non German Readers: Today the german parliament passed an act, which orders all communication-connection data (caller-ids, times, email-communication, other internet-transactions) have to be stored for 6 months.

More info on vorratsdatenspeicherung.de

On Thursday at Secure Con [1] I gave a lecture about SE Linux that went according to plan, and they gave me a nice bottle of Penfolds Shiraz afterwards (thanks to the sponsors). During my lecture I announced my plan to run the hands-on training session over the net. The idea is that the Debian and CentOS images from jailtime.org with minor modifications will be put online somewhere for anyone to download. Anyone can then run the images on their own Xen server, go through the exercises, and ask questions on IRC at the same time. If you are interested in such training then please indicate in a comment what times would be good for the IRC discussion. Note that I’m only available between 7AM and 10PM starts in time zone +1100 (that is 20:00 to 11:00UTC for the starting time), the finishing time would be two hours later - and it would be possible to do the training in multiple sessions. One interesting thing was that at the end the moderator of the session offered a box of lollies to the first person who could tell him my user-name (which was included in ls output on one of the slides). Afterwards I was in idle conversation with some delegates and the topic of the Mac Mini [2] machines came up. Those machines are smaller than the Cobalt Qube (that I have in the past lugged around for portable SE Linux demonstrations), quite powerful (1G of RAM with an 80G hard drive seems to be the minimum for buying new at the moment), and they have keyboard and video ports which is often more convenient than sys-admin by serial port. I am now patiently waiting for Intel-based Mac Mini’s to start selling cheaply on eBay. Such a machine with 1G of RAM would make a nice SE Linux demo machine, I could run at least 7 Xen DomU’s for different users! Of course a second-hand laptop would do just as well, but laptops seem to hold their value better than most other machines. One thing that disappointed me was the small turn-out for the conference dinner. It seemed that as there was a gap in the program between the official end of the conference at 5PM and dinner at 6PM most people decided to go home. One thing to note for future events is that leaving gaps in this way is probably a bad idea. Maybe if they had said “drinks at the restaurant from 5PM and dinner at 6PM” then the turn-out would have been better.

• [1] http://securecon.unimelb.edu.au/


• [2] http://en.wikipedia.org/wiki/Mac_mini

Share This

Reading mig21’s weblog, in which I often find really interesting stuff, I found Ian Lance Taylor’s article “Single Threaded Memory Model“, which kind of bothers me a bit. It reports a recent discussion on the gcc and LKML mailing lists about how C compilers, gcc in this case, optimize for single threaded code, sometimes leading to counter-intuitive results which won’t work properly in multi-threaded software (leading, for example, to race conditions). The interesting part is that the C language standard, which in general describes a single threaded model, apparently says nothing about when values have to be written to memory. Thus, this kind of optimization seem to be perfectly valid. Linus Torvalds complains about gcc developers taking more care about “what the spec says” than about real problems, but the fact is that if those kind of optimizations are valid according to the specs, there’s no guarantee at all that it won’t happen with whatever C compiler you might be using. To prevent this kind of behaviour in standard C, according to Ian, the variable needs to be marked as volatile, or it needs to use an explicit memory barrier. The moral in this case is that multithreading might not be as easy as it seems and should be handled with caution.

Sheep Farmers Daughter is an old favourite, which I have read lord only knows how many times. Elizabeth Moon has written a gritty, enthralling story of the making of a Paladin. This is the first book of a trilogy, and introduces us to a new universe through the eyes of a young innocent (which is a great device to introduce us to a universe from the viewpoint of someone who is not seeing it through eyes jaundiced by experience). For me, books have always been an escape from the humdrum mundanity of everyday existence. Putting myself in the shoes of a character in the story is the whole point; and this story excels there: it is very believable. Not many people can tell a tale that comes alive, and Ms Moon is one of them. An ex-marine, much of the detail of the military life of Paks has been drawn from Moon s own military experience. More than just that, the world is richly drawn, and interesting. I read this book in a hotel room in Chicago, since, as usual, there was nothing really interesting on TV, and I don t get the whole bar scene.

As MJ Ray reports, ftp.mozilla.org now has “Free software” Firefox tarballs. While they are truly free and don’t contain the non-free logo nor Talkback, they are not Firefox either. Only the tarballs and the executables are named Firefox. The product itself is “Bon Echo”. And the name is going to change at every major release. This is why we changed for a “static” name.

I wrote a lot of messages on Sunday, trying to clear some things up and start a few slow balls rolling before various workshops, meetings and training sessions this week. Sadly, I botched at least three subject lines. One was the "Dear Blogger" post on this site which was written to someone who blogs, not Google's Blogger site. Few people saw the second mistake, so I'll not republish it here. The third was trying to ask whether debian t-shirts like the one I wear are affected by the Uzbek cotton problems which were in the news several times last week. That was on debian-project so I got some personal abuse for the botched subject. Debian lists are more funny than fun - some people get less flak for mailing violent threats than I do for a misjudged subject line... Oh, and about the cotton-picking: it appears the debian project doesn't know where material for debian-branded clothing comes from and some seem to argue strongly that we should remain ignorant of it...

After DebConf7, I started to work with the Debian Perl Group, which I think is an example of how good a packaging group can work. We maintain currently 400+ packages, with a log bug-count (0.11 active bugs per source package says asdfasdf, and it's not like we are a lot of people there. To be honest, I haven't been too active on the packaging front, but I spent countless hours on tweaking and modifying what I think it's the most important tool for the group success: a script that generates a webpage where you can instantly see the status of every package in the SVN repository. The great thing about this is that it gives you a visual idea of the status of everything in a moment: which packages have bugs, which one are ready to be uploaded, and —since we keep all watchfiles updated— also which have a new upstream version. Being a group with many non-DDs, it's great that there's no need for maintaining a list of to-be-sponsored packages; we just mark the package as ready to go, and when somebody can do it, reviews and uploads the package. I can hear the cries of people who think that sponsored packages are the incarnation of the devil, but our bugcount backs me :-). I tell you all of this because, first of all, I'm really glad to be part of a healty group of great people, and secondly, because we are finishing a completely new version of the tool, which was thought from the beggining to be used by other groups. In fact, a lot of debugging has been done by checking that it could process correctly other groups' data (it only works with SVN by now, but that's easily fixable as the code is pretty modular). You can see the (static) pages I've done while testing, showing the packages from the Collab-maint, Games, Java, KDE and Python-modules teams/groups. If you find a bug, I'd love to hear about it. So, if you're interested, grab the sources from the repository, and drop in #debian-perl@OFTC if you need help. Tags: Planet Debian, Debian

As often seems to be the case, my internet at home vanished shortly after I arrived in Portland. Remote debugging (hurrah for flatmates) revealed that the modem would come up, start a PPP session and then OOM around 30-40 seconds later. This was kind of odd, since running ps in a tight loop showed that it wasn't the PPP daemon that was taking up all the extra RAM. Once we'd pretty much ruled out userland, that left the kernel. Limiting the value in /proc/sys/net/ipv4/ip_conntrack_entries brought stability back, but left us wondering why it had suddenly broken (and, of course, made it difficult to actually route anything...). /proc/net/ip_conntrack showed a bunch of ssh connections. Lots of ssh connections. All coming from one machine inside the network, but targeted at a large number of machines with roughly consecutive IP addresses.

At this point, I remembered a party a month or so ago. One where I'd created an account on the TV machine to let people upload stuff to play. An account I'd cunningly called "media", giving it the highly secure password of "media". I blame vodka from Ikea.

You can guess where this is going.

Unplugging the TV machine resulted in everything rapidly returning to its normal state. I'm sure there's some sort of important lesson here, but I'm sure I don't know what.

One of the things I love about programming is that you are always learning new things. You have to learn new things to keep up. One of the benefits of using the Plotr Javascript library for the language popularity stats I did is that instead of having to download separate images for each statistic, a user just fetches the library once and then a few small bits of data for each chart, which is probably a net savings, especially when I start to add more statistics. However, Plotr, plus its various supporting libraries, is fairly hefty, so I needed to find a way to compress it. One of the helpful people on the freenode IRC network's #javascript channel pointed me at Yahoo's YUI Compressor, which is a nicely done project that squeezes quite a bit out of Javascript files. I would recommend it to anyone else who needs to pare down their production JS files to the bare minimum. Best of all, it's available under a very liberal open source license! Incidentally, over the course of the language stats project, I was surprised at how much helpful stuff Yahoo provides, first and foremost, a real API for their search engine, something that Google no longer has. Hopefully, it's a sign of better things to come for them (if for no other reason than to keep Google on their toes!). By the way, for those interested in the language stats project, I set up a forum with RSS feeds, where I will be posting updates, and accepting suggestions for further improvements.

Groups that campaign for free technology, like the Free Software Foundation and the Electronic Frontier Foundation, tend to be supported primarily by technologists. Both groups have struggled to communicate their messages to non-geeks. I have written an article and helped create a new weblog, both called Revealing Errors, that attempt to address a root cause of this issue in what I hope is both an insightful and entertainingly manner. Geeks support groups like the FSF and EFF because, as people who understand technology, they understand just how powerful technology is. Geeks know that control of our communication technologies is control over what we can say, who we can say it to, and how and when we can say it. In an increasingly technologically mediated age, control over technology is not only the power to control our actions; it is the power to limit our possible actions. Our freedom to our technology is our freedom, full stop. This message fails to resonate with non-geeks but it does not fail because non-geeks are happy to hand over their freedom. It fails to resonate simply because the vast majority of people do not understand that technology, and control over it, is powerful enough to impact their freedom. Most people fail to see the power because, quite simply, most people fail to see technology. While we all see the effects of technologies, the technologies themselves are frequently hidden. We see emails but not mail transport agents. We see text messages but not the mobile phone network. Before one can argue that such systems must be free, one must reveal their existence. Technologists are keenly aware of the existence of these systems. To everyone else, they are completely invisible. Marc Weisner of Xerox PARC cited eyeglasses as an ideal technology because, with spectacles, "you look at the world, not the eyeglasses." When technology works smoothly, its nature and effects are invisible. But technologies do not always work smoothly. A tiny fracture or a smudge on a lens renders glasses quite visible to the wearer indeed. Similarly, people see their MTAs when messages bounce. They see Windows on their ATM or phone when the system crashes. Technological errors are moments when usually invisible technology becomes visible. They are, in this sense, also an educational opportunity. I have recently published an article in Media/Culture Journal from the University of Melbourne within a special issue called Error. If you are interested in learning more about what I'm trying to do or looking at some examples, please read the article. With support and ontributions from Aaron Swartz, I have also created a new weblog, Revealing Errors, that reveals errors that reveal technology by posting descriptions of errors with commentary on what the error reveals. I've posted a few examples there already and I will be updating it regularly. The goal is to help explain the power and influence of technology in the service of broadening the base of people who can get excited about freedom to technology. Eventually, I hope to be able to communicate this message to a less technical audience. With that said, I hope that even seasoned technologists will learn things about their technological environment through the analysis and interaction. I hope readers of this blog will subscribe to it and, if possible, comment on and contribute to the project as it moves forward.