At casa Geier, there is a slightly broken Asus A3G laptop, formerly known as salmiakki. The symptom is that upon pressing the power button, the machine ponders for a few seconds, then decides to turn off again. Since these laptops come with CD playback function keys on the outside, I think this is the safety feature against accidentally powering on; it just turns off again when the lid is closed. Which makes me suspect that only the lid switch is broken. Trouble is, there is no switch. This thing uses black magic to find out if it's open. There are no wires going to the hinges, there is no magnet either, or anything else that looks like it could be used in this way. So dear lazyweb, I'm interested in any hints how this might work. Pure speculation is also fine.

The general idea on the 25th was to relax, watch some , and generally do not care too much about anything. Right, only after 13 episodes of ("Crest of the Stars") hunger set in, and it being late at night on a holiday, we scrounged the kitchen for things that might fit together. Idea 1: Let's make Spaghetti Alio e Olio. — Well, no Spaghetti in the house. So replace them with Farfalle. Idea 2: We could also add some onion. — Splendid. Idea 3: We could add sugar to the onion. — Yay, caramel. Unforeseen Circumstance 1: Whoops, not that much sugar. Idea 4: It being Christmas, and the food being awfully sweet now anyway, let's add apples and cinnamon. So, I present the ultimate Christmas dinner, featuring:

• as much garlic as you like
• an onion
• sugar
• an apple
• noodles

And it tasted quite good, actually. I shall remember to buy more food before the holidays next year though.

"Do things on time." Oh, wait.

I shall take this opportunity to join the "global warming? I'm freezing my bottom off here, thankyouverymuch" crowd. Not much happening here, besides porting some code to Linux and still cursing Windows Installer, though.

Brandon, back in my day, I compiled python-imaging on an Amiga 1200 with a 25 MHz 68040 and then uploaded through a 14.400 baud modem. You youngsters have it easy these days.

With this patch, dpkg-buildpackage starts passing a new variable DEB_VARIANT into the package build process which can then be used by the package to customize itself on different systems. As already written in the bug report, the prime candidates for this are the gcc package (which currently looks into /etc if it's building on Ubuntu, and then applies a patch that is left out on Debian) and packages often used on embedded systems, which could benefit from splitting out documentation and translations, but where we don't want that in the main Debian archive. As usual, feel free to tell me that I'm on crack.

A Debian package is uniquely identified by its name and version; there is no further information taken into account by dpkg. This keeps the packaging system rather simple, but has the disadvantage that all information that would otherwise be placed in extra data fields has to be encoded into these two fields. As the names of all binary packages generated from a single source package need to be known when building the .dsc file, no substitutions are allowed in the package name. Back in the Good Old Days, the only extra bit of information in the name field used to be the SONAME from the library in the package (thus implicitly saying that each library should have its own package), which meant that the maintainer had to adapt the debian/control file every time a library's ABI changed. This being the Good Old Days, people writing libraries actually thought about things, so ABI changes were few and far between. These days, libraries are stacked on top of each other, re-exporting the underlying libraries' ABI. The SONAME system could in theory handle these situations if the SONAME of every library whose ABI is re-exported is encoded into the SONAME of the newly built library. So if my own ABI version is "2", and some of the functions I export use types defined in glib, then after building against glib1.2, my SONAME would be somewhat similar to "2+glib1.2". For languages that don't have a well-defined ABI (i.e. anything but C), the version of the language ABI(s) used will also have to be added. Obviously, this would also have to be encoded into the package name, which is where trouble starts during transitions. The last C++ ABI transition had all C++ library maintainers add a suffix to the package name; dependent ABIs are not handled at all in Debian right now (which led to the libpng mess). The existing encoding rules are not entirely formalized, and it is not guaranteed that they are bijective. For example, packages used together with cross compilers have been following the convention of using the name that the native package would use, followed by a dash, the target architecture name, another dash and the word "cross". There is no guarantee that the architecture name does not contain a dash, however, so we cannot simply take the second to last word as the architecture name if the last word is "cross" (think "libgcc1-kfreebsd-i386-cross"), which makes it difficult to write a plug-in to apt that would automatically download the binary for the target architecture and convert it using dpkg-cross. I've decided to nonetheless go ahead with my request that the "-*-cross" part of the package name space be reserved for packages related to cross compilation; it will work for the time being.

Ian, what you have discovered is not ARM specific. A lot of cast expressions in use in today's software would actually be undefined behaviour, but compilers accept them anyway. Write that code by explicitly reading the bytes from the array and ORing them together — it is the duty of the compiler to find out that the CPU can optimize this.

(continued from "This is Delicious Crack") Essentially, a .msi file is a relational database, and everything that should happen during an installation is stored as an entity. The benefit is obvious: there can not be any bugs in the packaging that cannot be rolled back easily, as the Installer always knows what is happening. Well, in theory. This approach has a massive drawback: you cannot really do anything that was not anticipated. To solve this, the Installer allows you to provide a DLL that takes over a bit of the installation procedure - which still ought to be described in the database. When properly written, these DLLs can be reused and become a kind of standard, such as DIFxApp, which is the handler for device driver installation. The last remaining difficulty here is that Visual Studio does not know hardware drivers at all (there is a separate SDK), and so it supports neither building nor installing them, which means that I have to edit the .msi file generated here by hand to add the information for the driver installer.

The main project I'm currently working on for money is a device driver for an actual bit of hardware. Since people working on Windows are slightly more used to the idea that money is exchanged for goods and services, this is the primary target platform. After dealing with all the interesting bits concerning development on this platform, I now have a .sys, a .inf, a .dll and a .xsl to install. The DLL was easy, Windows Installer has special handling for COM DLLs; the XSL file was a bit tricky since it needs to be placed in a "special" directory that will be phased out before Longhorn (the documentation is that old...), and I'm completely lost on the other two as the Installer does not know about the special registration system for drivers at all. At this point, I started entering the rabbit hole.

I'm thinking about hacking a wrapper around the compiler (or libtool) that handles compiling IDL files and linking against the proxy/stub code. Automake would have to be taught that when an IDL file is listed in the sources of a program or library, the compiler call needs to be replaced (thus doubling the number of variants again (to eight: C/C++, simple/libtool and with/without IDL), which adds a certain amount of complexity (but hey, we're talking about automake), and, more difficult, we'd have to handle source files that live outside the build tree (or make people use small IDL files that include the files that define the necessary interfaces -- but that is ugly).

It seems that -- again -- I've managed to catch something nasty on the way back (probably I should only check in my coat if I know that it won't take long until boarding). So, two days later than anticipated, I am officially back and working. I have yet to clear the autobuilder backlog of the last three days (these ARM boxes are blazing fast these days; and a lot of packages failed due to GNOME being uninstallable) and also catch up with the real world (I turn off my phone when I have a migraine attack, keeping a log of calls but this time there's just a batch of unknown numbers with some calls having dropped off the list already -- please send emails instead of calling if it is important, there is a reason why I don't use my phone for business). In other news, this posting needs paragraphs.

My flight got delayed. There is still a slim chance I will be home before midnight. Having a laptop would definitely be an advantage.

For those of you wondering why I'm not in Madrid yet, it is a long story.

Wouter, I had a different association.

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 plan for tomorrow includes possibly breaking my computer by soldering the JTAG connector onto the CPU board. Then there will be much debugging of mISDN drivers, and hopefully some rejoicing when I find out what makes the kernel hang on loading the layer 1 driver. This will also be an excellent opportunity to clean up my desk to make space for the soldering iron, and to build another Internet router in case anything goes wrong.

in case my last post was not cynic enough yet: "XUL is the Java of the new millenium"

"Neon Genesis Evangelion is bad for you if you want to maintain a positive view of the outside world." NP: Carl Orff - Carmina Burana

Norbert, I'm not entirely confident you'd be able to reliably restore a database from such a backup, unless the database had a QUIESCE command that would be called before the snapshot is taken.