Various people have asked me why there'd ever be a justification for ACPI tables to base various types of behaviour on the operating system they're running on, and why Linux claims to be Windows. There's pretty straightforward explanations that don't involve conspiracies, but they're not necessarily obvious. Let's start from the beginning.

ACPI provides two mechanisms for determining the OS, _OS and _OSI. _OS is an ACPI object containing a string. This string is supposed to represent the operating system. Windows 98 contained "Microsoft Windows", NT4 "Microsoft Windows NT" and ME "Microsoft WindowsME: Millennium Edition". All later versions of Windows contain "Microsoft Windows NT". Linux was "Linux" up until 2.6.9, and has been "Microsoft Windows NT" since then.

The obvious drawback to _OS is that it's a single string. _OSI was introduced with later versions of ACPI, providing an interface for ACPI tables to request which interfaces an OS supported. Interfaces may be something like "3.0 Thermal Model", indicating support for a specific aspect of ACPI, but may also be used to indicate the interfaces supported by the OS. The _OSI method is passed a string and returns either true or false depending on whether the OS claims to support that interface. The OS can therefore claim to support many different interfaces. Linux implements pretty much every aspect of ACPI that Windows does, and so claims to support all the interfaces that Windows implements. As a result, Linux will return true when asked if it implements support for any of the Windows interfaces (up to and including Vista).

That's all straightforward enough, but leaves two questions. The first is why Linux now claims "Microsoft Windows NT" for _OS. That's actually pretty simple - some DSDTs only check for various _OSI strings if _OS is "Microsoft Windows NT". This is stupid of them, but not a violation of the ACPI spec. The second is why Linux returns false for _OSI("Linux"). This is a little more subtle, but it basically boils down to "There is no Linux interface". The behaviour of Linux changes over time. We make no guarantees that its behaviour will be consistent over time as we find and fix bugs. Microsoft take a different approach. Their ACPI behaviour has few changes over time. Something claiming to be Windows 2000 will always behave the same way. We can't even bump the interface string per release - doing so would require us to maintain every broken behaviour we've ever implemented and switch between them depending on what the BIOS asked us for. Linux does not provide a stable ACPI API to platform firmware, and we make no guarantees that it ever will. The only behaviour you can depend on is that Linux will conform to either the ACPI spec or (where it differs) the behaviour of Windows. If you find behaviour that does not fall into either of those categories, then it's likely that the behaviour will change when we notice. The reason we removed Linux from the supported interfaces list in 2.6.24 was that we were beginning to see BIOSes that changed behaviour when they detected that they were running on Linux, and changes we wanted to make could have potentially broken these BIOSes.

Anyway. That's why we claim to be Windows. Now, why would a DSDT want to do anything with that information? It should be noted that making decisions based on this is not a contravention of the ACPI spec - section 5.7.2 even describes a case of this. There are a few situations under which this can be helpful. The first is due to varying interpretations of the spec. Early versions of Windows require that hotswap bays signal their removal by sending a bus check notification to the parent IDE bus. Later versions want a device check notification on the device itself. Both are valid, but you ideally want to use the right one on the corresponding OS. Checking the OS version lets you do so.


Red Stripe makes a lousy spec-compliant ACPI implementation. That is because it is not a spec-compliant ACPI implementation, it is beer! Hooray beer!

Another is user experience. Not all hardware is supported by all operating systems. For instance, older versions of Windows don't support high-precision event timers (HPET). The HPET is defined as an ACPI device, and so will show up as an unknown device in the Windows device manager unless the firmware disables it. This is acheived by altering a flag in the _STA response depending on the Windows version - earlier versions are told that the device should be invisible, and later versions are told that it should be exposed. Finally, there's bug workarounds. An example of this is Windows 98 crashing if a thermal zone reports a temperature of less than 15.8 degrees celsius. Working around that seems like a perfectly reasonable thing for a piece of hardware to do, since Microsoft don't make it easy for vendors to provide hotpatched versions of Windows.

The final part of this mystery is why various BIOSes attempt to check whether they're running on Linux. Almost all the BIOSes I've examined do nothing with this information, which is consistent with someone writing an OS lookup table many years ago and adding Linux just in case someone found it useful. People don't generally write ACPI tables from scratch (doing so would be very dull), so they'll base it on the one from a previous version. Code won't be removed unless it's breaking things, so you'll end up with various odd evolutionary dead ends that have persisted anyway. If your ACPI firmware checks for Linux, this is not inherently a bug in your BIOS. It's more likely that nobody cared enough to remove two lines of code that might turn out to be useful one day.

Introducing the Humongous Merged Packages File From Hell Suppose you want to build some service that requires information about all packages in all architectures. Like, for example, the debtags web tagging interface. If that is the case, then you may be interested in the Humongous Merged Packages File From Hell. It contains a merge of all Packages and Source files of etch, lenny, sid and experimental, for main, contrib and non-free, in all architectures. The merge is done according to completely arbitrary criteria of mine:

• One record per (package, version) couple found; multiple record per (package, version) are merged together
• Size and Installed-Size are the average of all values found
• MD5sum, SHA1, SHA256, Filename, Files, Directory, Checksums-Sha1, Checksums-Sha256, Binary are thrown away
• Information (such as Homepage, Vcs* fields, Uploaders) found in the Sources file is repeated for every binary package
• All other packages get as value a list of all the values found, with duplicates removed

It's there in case anyone other than me may find it useful.

I just wrote this in my user page in the English wikipedia:

Antti-Juhani Kaijanaho is no longer actively working on Wikipedia. While I approve, in principle, all the new and stricted editor policies, it is emotionally very demanding to be challenged under new policies for edits that were made in good faith under older policies. There just aren’t enough positive aspects to doing Wikipedia to offset that very big negative aspect.

Some of the challenges toward my edits have happened in the English Wikipedia, and some in the Finnish Wikipedia. I have felt like this for about a year now – it’s probably time to make it official. I may make minor edits, or write in talk pages occasionally, but any substantial edits I won’t bother with any more.

One thing that seems overlooked by most people who discuss productive work habits is the varying mental capacity for performing different types of work. While it’s well known that alcohol and other substances decrease mental ability and it’s slightly less well known that sleep deprivation has a similar affect to being drunk [1], the reference cites the case of medical residents - the effects of sleep deprivation can affect people with medical training who presumably are better qualified to recognise and mitigate such problems than most people. Previously I wrote about increasing efficiency through less work [2], which was mainly based on the total number of hours worked in a week - with some mention of extreme fatigue. However it seems obvious that things aren’t that simple. The ability to perform work can be reduced due to temporary issues, poor sleep the previous night (not the same as sleep deprivation but enough to decrease performance), general health (I find that having a cold really reduces the quality and quantity of my work), and physical state (skipping a meal due to being busy can lead to lower quality work). For the work I do (system programming and system/network administration) there are a range of tasks that I need to perform, which require different levels of skill. Now when I have several tasks that need to be done it makes sense to do the most demanding task that I can do well. The problem is in assessing my own ability to perform such tasks, while I can have a general idea of how alert I feel, it seems likely that self assessment by subjective criteria will decrease in accuracy at least as fast as my ability to perform the work in question. So having an ability to assess my mental capacity at any time seems useful in determining when to work on the hard tasks, when to work on easy tasks, and when to just give up and go to bed! ;) Fortunately I have found a benchmark that seems to give reasonable results. I have found that I can reliably solve the game Codebreaker (based on the board game Mastermind [3]) on the Familiar distribution of Linux running on my iPaQ in under 30 seconds when I’m fully alert. So far my tests have indicated that when I seem less alert (due to finding tasks difficult which should be easy or making mistakes) the amount of time taken to complete the game increases (my worst day was when I couldn’t complete it in under a minute). It seems likely that someone who is doing intellectual work could take one day off work a week without a great decrease in productivity if it was their least productive day. If there was a factor of three difference in productivity between the best and worst days then skipping the worst day might decrease productivity by 10% if the 8 hours in question were used doing something as demanding as working. If what might have been the least productive day had been spent relaxing followed by going to sleep earlier than usual then it doesn’t seem impossible for productivity to be increased enough on the next day to provide a net benefit. One thing I plan to do from now on is to use Codebreaker to help me determine when I should cease work in the evening. If I take more than a minute to complete it (or have difficulty in solving it) then it’s probably best to finish work for the day.

• [1] http://www.marketwatch.com/News/Story/Story.aspx?guid=%7B00065B6D-36F9-44C0-AEC9-8E4FF76151DA%7D&siteid=google&print=true&dist=printMidSection


• [2] http://etbe.coker.com.au/2007/11/02/increasing-efficiency-through-less-work/


• [3] http://en.wikipedia.org/wiki/Mastermind_(board_game)

Share This

Some weeks ago, we (the icecast packaging team) were requested an icecast2 backport for debconf8. It is now stuck in backports.org's NEW queue, feel free to unblock it.

Liquidsoap 0.3.8 has just been released. Initially targeted as a bugfix release, fixing a nasty race condition in playlist sources, this release is finally more important. It can be seen as the first minor release after the major changes that occured in 0.3.7. Several issues where fixed, but also new functionalities have been added, mostly on users' request. We also had a nice beer two weeks ago. There, we have met some users as well as developers. This was a nice occasion to discuss (...)

Martijn isn't too sure about Debian testing, though he doesn't go into much detail about the "not sure" bits. Well, Martijn, even though I could really use some more detail, let me make an attempt:

• Debian Testing isn't the perfect thing to use at all times. Especially right after a release, when people start uploading all kinds of crap to Debian unstable, it's probably better to stick with Debian Stable for a while. Right before a release (such as the time we're in right now), however, using testing on a laptop is probably a much better choice if you want reasonable up-to-dateness of the software on your system.
• In case you didn't know, testing does get security updates these days (since quite a few years already, actually).
• In the pre-sarge days, installing Debian almost required some magician to do it for you. These days, however, installing Debian is much easier, so if you're afraid of that, don't be. Also, the default "desktop" installation can compete with Ubuntu in many areas already, although there surely is some more work to be done.
• Debian is a bit more conservative with updates than is Ubuntu, even in the development distributions ('testing' and 'unstable'). This is generally a good thing if you don't want your system to break in all kinds of "interesting" ways right when you don't have the time (although that might still happen, though more so with unstable than with testing).
• Most of the bits that are available in Ubuntu are also available in Debian; and in Debian, in most cases they're done more thorough, because of the difference between Debian's and Ubuntu's approach to package maintenance: in Debian, every package has its own maintainer who is solely responsible for the package; in Ubuntu, maintainers are responsible for a whole lot more packages, which improves their view on the distribution as a whole, but makes it more difficult for them to follow up on the state of individual packages.

In all, I still prefer Debian over Ubuntu, mostly because of the higher attention to detail you'll find in Debian; I find that ubuntu developers usually don't have the time to pay too much attention to pesky details. This makes the system work slightly better. But, of course, YMMV, and if you decide to stay with Ubuntu because you think it works better in your particular use cases, more power to you!

Michael Janke has written an interesting article about data flows in networks [1], he describes how data from the Internet should be considered to have low integrity (he refers to it as “untrusted”) and that as you get closer to the more important parts of the system it needs to be of higher integrity. It seems to me that his ideas are very similar in concept to the Biba Integrity Model [2]. The Biba model is based around the idea that a process can only write data to a resource that is of equal or lower integrity and only read data from a resource that is of equal or higher integrity, this is often summarised as “no read-down and no write-up“. In a full implementation of Biba the OS would label all data (including network data) as to it’s integrity level and prevent any communication that violates the model (except of course for certain privileged programs - for example the file or database that stores user passwords must have high integrity but any user can run the program to change their password). A full Biba implementation would not work for a typical Internet service, but considering some of the concepts of Biba while designing an Internet service should lead to a much better design (as demonstrated in Michael’s post). While considering the application of Biba to network design it makes sense to also consider consider the Bell LaPadula model (BLP) [3]. In computer systems designed for military use a combination of Biba and BLP is not uncommon, while a strict combination of those technologies would be an almost insurmountable obstacle to development of Internet services I think it’s worth considering the concepts. BLP is a system that is primarily designed around the goal of protecting data confidentiality. Every process (subject) has a sensitivity label (often called a “clearance”) which is comprised of a sensitivity level and a set of categories and every resource that a process might access (object) also has a sensitivity label (often called a “classification”). If the clearance of the subject dominates the classification of the object (IE the level is equal or greater and the set of categories is a super-set) then read access is permitted, if the clearance of the subject is dominated by the classification of the object then write access is permitted, and the clearance and classification have to be equal for read/write access to be permitted. This is often summarised as “no write-down and no read-up“. SGI has published a lot of documentation for their Trusted Irix (TRIX) product on the net, the section about mandatory access control covers Biba and BBLP [4]. I recommend that most people who read my blog not read the description of how Biba and BLP works, it will just give you nightmares. The complexity of either Biba or BLP (including categories) is probably too great for consideration when designing network services which have much lower confidentiality requirements (even the loss of a few million credit card numbers is trivial compared to some of the potential results of leaks of confidential military data). But a simpler case of BLP with only levels is worth considering. You might have credit card numbers stored in a database classified as “Top Secret” and not allow less privileged processes to read from it. The data about customers addresses and phone numbers might be classified as “Secret” and all the other data might merely be “Classified”. One way of using the concepts of Biba and BLP in the design of a complex system would be to label every process and data store in the system according to it’s integrity and classification/clearance. Then for the situations where data flows to processes with lower clearance the code could be well designed and audited to ensure that it does not leak data. For situations where data of low integrity (EG data from a web browser) is received by a process of high integrity (EG the login screen) the code would have to be designed and audited to ensure that it correctly parsed the data and didn’t allow SQL injection or other potential attacks. I expect that many people who have experience with Biba and BLP will be rolling their eyes while reading this. The situation that we are dealing with in regard to PHP and SQL attacks over the Internet is quite different to the environments where proper implementations of Biba and BLP are deployed. We need to do what we can to try and improve things, and I think that the best way of improving things in terms of web application security would involve thinking about clearance and integrity as separate issues in the design phase.

• [1] http://lastinfirstout.blogspot.com/2008/07/presumed-hostile-your-application-is.html


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


• [3] http://en.wikipedia.org/wiki/Bell-LaPadula_model


• [4] http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_EndUser/books/TCMW_UG/sgi_html/ch02.html

Share This

So hot off the back of my successful upgrade from Sarge to Etch, I thought I'd try the new "Etch and a Half" 2.6.24 kernel on daedalus Let's just say that it's times like these that I'm glad I got the serial-over-LAN thing working, and have remote power. I spent many hours today rebooting, trying to get to the bottom of why it wouldn't work. At first, I thought it was hanging, but then I realised it was dropping to a shell in the initramfs, and just not making that very obvious because the serial over LAN console is a bit crappy. Once I realised what was going on, I did some poking around. It seemed like udev wasn't getting started properly, so when it went to assemble the mirrors, that failed, because the component devices couldn't be found, then it freaked out because it couldn't mount the root filesystem. If I ran the relevant bits of /scripts/init-premount/udev by hand, the SCSI devices appeared, and I could manually assemble the mirror, and mount the root filesystem, which was handy, because I also discovered that you can boot with debug on the kernel command line, and it logs the initramfs run to /tmp/initramfs.debug. So that was a convenient way of preserving the log, because there seemed to be some characters in it that made inspecting it over the serial console difficult, and there was no way to get it off the machine from the initramfs environment. As far as I can determine, it's telling udev to start, but it certainly isn't still running when it bombs out to a shell after failing to mount the root filesystem. It's not immediately clear if there's something later on that is stopping it again. I've put the log here in case anyone's interested in looking at it. This was with the addition of "x" to the options of the shebang line of /usr/share/initramfs-tools/scripts/init-premount/udev so that I could see what was happening when /scripts/init-premount/udev ran. So I don't think the kernel itself is at fault, it's some sort of weird udev/initramfs interaction. Rather than further rebooting the tripe out of daedalus, I'll have to see if I can reproduce the problem on a less important machine locally to do further debugging. In the meantime, I'll have to stick with 2.6.18.

Well, tomorrow will be one week since my last of the prescription drugs, and the last Tylenol I had was on Tuesday. I think I'm finally free of these damned things.

It's worth noting that these bottles aren't all empty, but this doesn't include the ones given to me in the hospital, the various stomach things I had to take so that the steroids didn't hurt me, and the various bottles of Tylenol that I lost from being such a basket case (Everyone, especially Angie, has been so patient with me with the mood swings, the memory holes, etc. Thank-you so much!) Based on this, I'm assuming that the count probably evens out. I totalled the number of pills in these bottles: 1333.

I've heard that there's an org, "Doctors Without Borders" to which I can donate the ones that I will definitely not need again, like the steroids and such. I'll hunt them down soon.

Next update: Tuesday. I get to see the surgeon again and my movement restrictions are expected to be lifted. That means the only other visit is to the oncologist who *still* after 5 months can't manage to schedule an appointment with me. They're the ones who finally phoned a week ago to schedule one. I wanted to check with my surgeon on something, and when I went to phone them back, their call display number isn't valid. They were supposed to phone me back anyway, but I also asked my surgeon's practice coordinator to arrange it for me. Still nothing. *sigh* I'm going to take the opportunity at the hospital to go talk to them in person to see if I can get things moving. We're still at the stage where noone expects anything, but they want the tests to make sure that's actually the case.

Still, I'm excited to be this far. It's nice to finally feel like I'm thinking somewhat more clearly now.

Ryan kindly sent me a copy of the ACPI tables for his motherboard, so I've had the opportunity to look at them in a little more detail. There's nothing especially surprising. The first method of interest is OSFL, which I've annotated below:

   Method (OSFL, 0, NotSerialized)
     
        If (LNotEqual (OSVR, Ones))
         
            Return (OSVR)
         

This block simply skips the checks if they've already been evaluated and returns the cached value

        If (LEqual (PICM, Zero))
         
            Store (0xAC, DBG8)
         

If the programmable interrupt controller has been set up in PIC mode rather than APIC mode, 0xAC is written to i/o port 0x80. This would then show up on a plug-in card if one were attached. Simply debug code

        Store (One, OSVR)

Set OSVR to 1, which in this case clearly means "Unknown OS"

        If (CondRefOf (_OSI, Local1))

This checks whether the OS supports the _OSI method. If it does, the following block is executed. If not, the older _OS method is used to detect the OS

         
            If (_OSI ("Windows 2000"))
             
                Store (0x04, OSVR)
             

Newer versions of Windows will also claim to support the interfaces defined in older versions, so this set of checks is done in release order

            If (_OSI ("Windows 2001"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001 SP1"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001 SP2"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001.1"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001.1 SP1"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2006"))
             
                Store (Zero, OSVR)
             

If we've got this far, OSVR is now set to 0. Linux will claim to support all of these interfaces, and so OSVR should be 0 on Linux systems. Note that there is no _OSI check for Linux - the 2.6.24 change to remove Linux from the set of claimed interfaces is therefore irrelevant

         
        Else
         

Linux supports _OSI, so we should never be here. But if we somehow are...

            If (MCTH (_OS, "Microsoft Windows NT"))
             
                Store (0x04, OSVR)
             

Linux has responded to _OS with "Microsoft Windows NT" since 2.6.9. MCTH is simply a string matching routine defined elsewhere in the DSDT. So, worst case here is that OSVR is 4

            Else
             
                If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
                 
                    Store (0x02, OSVR)
                 
                If (MCTH (_OS, "Linux"))
                 
                    Store (0x03, OSVR)
                 

..because this could never be true unless you're running 2.6.8.1 or earlier. But even so, getting here would still indicate failure - we've supported _OSI since before then, and so should never come anywhere near this code block.

             
         
        Return (OSVR)
     

In summary, we end up with the following values:

Value	OS
0	Windows XP, 2003 or Vista. Linux (assuming absence of bugs)
1	Unknown OS
2	Windows ME
3	A version of Linux that doesn't implement _OSI and is from before 2.6.9
4	Windows NT 4 and 2000. A version of Linux that doesn't implement _OSI and is 2.6.9 or later (I don't believe any such version exists

Now, where is this used? The majority of the OSFL checks only check whether the return value is 1 or 2, which will only be true for an OS that (a) doesn't claim to be Windows or (b) is Windows ME. Linux doesn't fall into either of these categories, so we can ignore them. The first interesting hit we have is in the HPET code, where _STA will return 0xf (device present and working) if OSFL is 0 and 0xb (device present and working, but should not be shown in the UI) otherwise. This is just to keep the HPET from showing up in versions of Windows that don't know what it is. The only other interesting hit is the following code from the PCI bus initialisation pathway:

 
                               If (LEqual (OSFL (), Zero))
                                 
                                    Store (0x59, SMIC)
                                 
                                Else
                                 
                                    If (LEqual (OSFL (), 0x04))
                                     
                                        Store (0x5A, SMIC)
                                     
                                    Else
                                     
                                        Store (0x58, SMIC)
                                     
                                 

This writes different values to SMIC (which turns out to be i/o port 0xb2) depending on the OS. 0xb2 is the standard(ish) way to trigger a system management interrupt, which causes the CPU to execute some code from a memory region that can't be accessed by the OS. This isn't that unusual, but it's a little weird. In any case, note that there's no check for whether OSFL is 3 here (which would be true if the _OS call returned Linux), and so Linux is being treated identically to Windows ME and any unknown OS. In reality, Linux will be treated identically to either Vista or 2000. This block provides no evidence of conspiracy. Finally, the OS version flag is written to a region of memory before suspend and read back afterwards. Nothing appears to be done with this information - it's conceivable that the low-level resume code in the BIOS has conditionals based on this, but I suspect that it's just boilerplate code that's ignored.

To summarise:

• There is no code in this DSDT that could determine that the system is running any Linux kernel of 2.6.9 or later. This may even be true of earlier versions - I'm not sure when _OSI support was added
• Even if the code did manage to determine that the system was running Linux, there are no codepaths that are Linux specific. Every piece of code is run on at least one version of Windows

What's the problem, then? I've no idea. The only "significant" issue is that the OEMB table provided by the BIOS has an incorrect checksum. Given that the OEMB table is never used by Linux (it's a vendor extension of some kind, with the best hint I've been able to find being that it can be used to pass information from the BIOS to the OS - kind of like the rest of ACPI, then...), this is pretty unimportant. And given that the OEMB table isn't part of the ACPI spec, it's certainly entirely irrelevant when it comes to determining whether the system is ACPI compliant or not.

Are there ACPI issues with Ryan's system? It sounds like it. The "Error attaching device data" complaints indicate some kind of failure on the part of the kernel to work out how the devices correspond to the ACPI namespace, but I strongly suspect that this is a Linux bug. Failure to reboot after suspend? Could be anything (I'd need direct access to the hardware to figure it out properly), but again it's almost certainly a Linux bug. The standard way Linux reboots systems is to bang the keyboard controller, and it's conceivable that something we're doing on resume is leaving the keyboard controller in a slightly confused state. We're clearly doing something wrong there, given that my Dell comes up without a keyboard about one resume in twenty - I just haven't had time to look into it yet.

The only remaining thing is the mutex handwaving. I've got no clue what's going on there. Ryan's suggested change (from Acquire (MUTE, 0x03E8) to Acquire (MUTE, 0xFFFF)) simply means that the OS will wait forever until it acquires the mutex - in the past it would only wait a second. The reason the compiler generates a warning here is that the firmware never checks whether it acquired the mutex or not! Bumping the timeout to infinity obviously fixes this warning (there's no need to check the return code if you're happy to wait forever rather than failing), but the original code is merely stupid as opposed to a spec violation.

Take home messages? There's no evidence whatsoever that the BIOS is deliberately targeting Linux. There's also no obvious spec violations, but some further investigation would be required to determine for sure whether the runtime errors are due to a Linux bug or a firmware bug. Ryan's modifications should result in precisely no reasonable functional change to the firmware (if it's ever hitting the mutex timeout, something has already gone horribly wrong), and if they do then it's because Linux isn't working as it's intended to. I can't find any way in which the code Foxconn are shipping is worse than any other typical vendor. This entire controversy is entirely unjustified.

I’ve used the TLA EOM occasionally, but never considered the full scope of its utility. Lifehacker just made me a full convert:

EOM means much more than End of Message. It means “good use of time.” It means “concise.” It means “clarity.” But GUOTCC doesn’t have the same ring as EOM, so let’s stick with it. Here are eight great reasons for you to adopt EOM while crafting your email messages. (1) EOM saves your recipient’s time. Don’t you value your time? Isn’t it nice when others value your time too? By keeping your subject line short and using EOM you are showing the people you send to you value their time. They’ll thank you for it (when they know what it means). … (8) EOM guarantees 100% readership We’ve all had the frustrating experience of waiting on someone to read our important email and respond. Sometimes we wait a long time and follow up to find out they haven’t even read the message at all. Perhaps the most powerful advantage of EOM is 100% readership. Why? Because your entire message is in the subject line. Your message becomes impossible to ignore because it comes in front and center no need to double click.

In a job where I receive between 300-1000 emails on most weekdays, every little bit helps. The main drawback of excessive EOM’ing may be that it breaks threading for some mail readers, and may be incompatible with other email conventions. Technorati Tags: Email, EOM, Lifehacker, Productivity

Share This

As an update to this, it turns out that I can't read and talking about _OSI isn't very helpful when the DSDT in question is calling _OS, but it does leave me somewhat more confused - Linux has claimed to be Windows NT since approximately forever. Without the original DSDT I've got absolutely no clue what's going on, but comments like:

Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they're trying to crash the kernel by locking a region of memory that shouldn't be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead. ;)

don't give me a lot of confidence in any of this being a correct diagnosis given that the second argument to Acquire is a timeout and not an address (0x03e8 gives a timeout of a second, while 0xffff is "Block on acquiring this mutex forever").

In any case, it's highly unlikely that this is any attempt by Foxconn to prevent Linux from working. The majority of checks for Linux in ACPI tables are copy and pasted from reference tables that Intel (and other manufacturers) have provided at various points - even the Intel Macs attempt to check for Linux! Most vendors will never attempt to boot Linux on their boards or validate them appropriately, so it's entirely conceivable that they'll end up screwing things up in such a way that the only tested paths are the ones that are run by Windows. This is why we now attempt to ensure that Linux reports itself as Windows. If we're running Linux-specific code in the DSDT, then that's a bug in Linux.

Anyway. Accusing companies of conspiring against us when the most likely explanation is simply that they don't care is a fucking ridiculous thing to do and does nothing to get rid of the impression that Linux users are a bunch of whining childish hatemongers. Next time, try talking to someone who actually understands this stuff first?

Yay, finally! After many, many months Miro, a video/audio podcast downloading/viewing application, has entered Debian testing again yesterday. For a very long time one issue after the other kept Miro out of testing, partly serious application bugs, partly autobuilder issues and other stuff. I had almost given up hope, but luckily my 1.2.3-2 upload has now finally entered testing, just in time for the freeze...

Today, fifty years ago, my mother was born.

On July 24th, 1958, Vicenta Leyva gave birth to Olga Cristina Garza Leyva in the small town of Zumpango del R o (later renamed to Eduardo Neri), in the southern Mexican state of Guerrero. Her father Guillermo Garza, who is still alive, was a private pilot. Olga Cristina was named Cristina after the saint that is celebrated on the same day.

She was their third kid, a couple of years before V ctor and Guillermo were born and a couple of years after, Carlos was born, all of them being born on total different places on southern and central Mexico. The father, being a pilot, was absent from home for long periods, he even had "another family" somewhere in northern Mexico, supposedly in Sinaloa.

In the early 60s, the family moved to Mexico City where they were going to spend most of their life. They lived on a small apartment on Col. Moctezuma, which was (and still is) a working class neighborhood, just besides the Mexico City International Airport, on the eastern part of the city. Back in the days, it used to take quite some time to travel from there to any point of the city, like the downtown area or beyond.

All the kids spent most of their childhood there attending public schools. They weren't a wealthy family who couldn't even afford to buy and have meat on some days but only in special ocassions.

As the years passed and the kids became adults, Olga met David Moreno Rojas in the same neighborhood. He was enrolled at the National Autonomous University of Mexico, under Enterprises Administration in Ciudad Universitaria. He was also an avid f tbol player. He was named David after his father, David Moreno Gonz lez. They became boyfriend and girlfriend and got married when she was 20 and he was 24 years old on December 19th, 1978. They lived together for a few years in Col. Del Valle in central Mexico City.

Ten months later they were married, Lorena Moreno Garza, their first kid, was born on October 7th, 1979. S The family then moved to the suburb in Aragon, Estado de M xico. They had their second child on August 8th, 1984, named David Moreno Garza, becoming David III.

After the 1985 Mexico City massive earthquake, the family wanted to move outside the city and found relocation in Ciudad del Carmen, on the Mexican state of Campeche, located on the shore of the Gulf of Mexico, on 1988. They spent three or four years there and then moved to Celaya, Guanajuato where most of the father's family was located. They spent about five years there and then, for family reasons, they returned to Mexico City in 1995 to attend the family business.

Olga and her family had a good, loving family by then and had decided to not have any more kids. They had both of their children on private schools and taught them catholicism. On 1998, Vicenta passed away after a quick period of time because of liver cancer. This shocked most of the family.

As the years passed, the family business was sold and Olga stopped working, as she used to in the business. But as she had always been very active, she started working as a seller for a fine jewelry firm where she keeps working currently. Her husband, after pursuing his dream of going back to school and studying Law, works as a private work-related issues lawyer.

Olga is the most loving, nursing, affective, meticulous, scrupulous person I've ever met and even though I have only met her for almost twenty-four of her fifty years now, I admire her and love her as much as I have no words to describe. She is the one that built my sensitive, loving side where my heart resides, and I thank God for giving me such a great life gift and having her at any time.


Today, her husband is 54, her daughter is 28, her son is 23 and she is 50 now. This is also an special year because she and her husband will celebrate 30 years of their marriage.

Felicidades, jefecita.

My iRiver T60 has died after only 6 months of occasional use. This sucks. But since this is my 3rd MP3 player in ~ 2 years I feel i’m somewhat cursed in my ability to lose/break them. So my question is this: If I go into John Lewis (because it’s easy to take back if when it stops working) on Saturday and buy a shiny shiny iPod shuffle and turn myself into a complete sell-out will it *just* work with Rhythmbox 0.11.5? Will it just work or will I need to find a Mac to activate it or something painful like that?

One of the most significant tasks performed by a SE Linux system is loading the “policy“. The policy is the set of rules which determine what actions are permitted by each domain. When I first started using SE Linux (in 2001) the kernel knew where to find the policy file and would just read the data from disk as soon as it had mounted the root filesystem. Doing such things is generally considered to be a bad idea, but it was an acceptable mechanism for an early release. One issue is that the policy needs to be loaded very early in the system boot process, before anything significant happens. In the early days the design of SE Linux had no support for a process to change it’s security context other than by executing another process (similar to the way a non-root process in the Unix access control system can not change it’s UID, GID, or groups). Although later on support for this was added, it was only available as the request of the application (an external process could not change the context of an application without using ptrace - a concept that is too horrible to contemplate) and I am not aware of anyone actually using it. So it’s almost a requirement that there be no more than one active process in the system at the time that policy is loaded, therefore it must be init or something before init that loads the policy. When it was decided that a user-space program had to instruct the kernel to load the policy we had to determine which program should do it and when it should be done, with the constraint that it had to be done early. The most obvious solution to this problem was to load the policy in the initramfs (or initrd as it was known at the time). One problem with this is that the initramfs is limited in size by kernel compilation options and may need to be recompiled to fit a bigger policy. As an experiment to work around this limitation I had a small policy (which covered the domains for init and the scripts needed for the early stages for system boot) loaded in the initramfs and then later in the boot process (some time after the root filesystem was mounted read/write) the full policy was loaded. A more serious problem with including policy in the initramfs was that it required rebuilding the initramfs every time the policy changed in a significant way, of course scripts could not determine when a change was significant (neither could most users) so that required needless rebuilds (which wastes time). Even with a small policy for early booting loaded it was still sometimes necessary to change it and update the initramfs. I believe that as a general rule an initramfs should only be rebuilt when a new kernel is installed or when a radical change is made to the boot process (EG moving from single disk to software RAID, changing between AMD and Intel CPU architecture, changing SCSI controller, or anything else that would make the old initramfs not boot the machine). The initramfs that was used to boot my machine is known to actually work, the same can not be said for any new initramfs that I might generate. But the deciding factor for me was support of machines that did not use an initramfs or initrd (such as the Cobalt machines [1] I own). To solve these problems I first experimented with a wrapper for init. The idea was to divert the real init to another file name (or use the init= kernel command-line option) and then have the wrapper load the policy before running the real init. I never intended that to be a real solution, just to demonstrate a point. Once I had proven that it was possible to load the policy from user-space before running the real init program it was a small step to patch init to do this. One slightly tricky aspect of this was in getting the correct security context for init. The policy has always been written to allow a domain transition from kernel_t to init_t when a file of type init_exec_t is executed. The domain kernel_t is applied to all active processes (including kernel threads) at the time the policy is loaded. So init only has to re-exec itself to get the correct context. Fortunately init is designed to do this in the case of an upgrade so this was easy to manage. Since that time every implementation of SE Linux apart from some embedded systems has used init to load the policy. The latest trend in Linux distributions seems to be using upstart [2] as a replacement for the old SysV Init. The Fedora developers decided to make nash (a program that comes from the mkinitrd source tree in Fedora and is a utility program for a Red Hat based initramfs) load the SE Linux policy as it would apparently be painful to patch every init to load the policy. As far as I am aware there are only three different init programs in common use in Linux, the old SysV Init (which used to be used by everyone), Busybox (for rescuing broken systems and for embedded systems), and now Upstart (used by Ubuntu and Red Hat since Fedora 9). Embedded systems need to work differently to other systems in many ways (having the one Busybox program supply the equivalent to most coreutils in one binary is actually a small difference compared to the other things), and modifying the policy load process for embedded systems is trivial compared to all the other SE Linux work needed to get an embedded system working well. There are at least two commonly used initramfs systems (the Debian and Red Hat ones) and probably others. As one init system (SysV Init) already has SE Linux support it seems that only one needs to be patched to have complete coverage. I’ve just written a patch for Upstart (based on the version in Debian/Experimental) and sent it to an Ubuntu developer who’s interested in such things. I also volunteer to patch any other init system that is included in Debian (I am aware of minit and will patch it as soon as it’s description does not include “this package is experimental and not easy to install and use“). It seems to me that repeating the work which was done for SysV Init and upstart for any other init system will be little effort, at worst no greater than patching an initramfs systems (and I’ll do it). As the number of initramfs systems that would need to be patched would exceed the number of init systems it seems that less work is involved in patching the init systems. The amount of RAM required by the initramfs is in some situations a limitation on the use of a system, when I recently did some tests on swap performance by reducing the amount of RAM available to a Xen DomU [3] it was the initramfs that limited how small I could go. So adding extra code to the initramfs is not desired. While this will be a small amount of code in some situations (when I patched /sbin/init from Upstart it took an extra 64 bytes of disk space on AMD64), dragging in the libraries can take a moderate amount of space (the fact that an LVM or encrypted root filesystem causes SE Linux libraries to be included in the initramfs is something that I consider to be a bug and plan to fix). Finally not all boot loaders support an initrd or initramfs. I believe that any decision which prevents using such sweet hardware as Cobalt Qube and Raq machines from being used with SE Linux is a mistake. I have both Qube and Raq machines running fine with Debian SE Linux and plan to continue making sure that Debian will support SE Linux on such hardware (and anything with similar features and limitations).

• [1] http://en.wikipedia.org/wiki/Cobalt_Networks


• [2] http://upstart.ubuntu.com/


• [3] http://etbe.coker.com.au/2008/05/22/xen-and-swap/

Share This

Today is our third wedding anniversary. We're marking the occasion by having a night at the Tickle Pink Inn, which I can vouch for as being very nice indeed. Unfortunately I ended up on-call this week, so my day off tomorrow isn't going to be as idyllic as it could have been. It's hard to believe we've only been married three years. I think we've already been through more than a lot of married couples would have to go through in a lifetime. Here's to at least another 50 years.

Several weeks ago, the people in charge of maintaining the Windows machines in my institute were desperate because of a series of virus outbreaks - Specially, as expected, in the public lab - but the whole network smell virulent. After seeing their desperation, I asked Rolman to help me come up with a solution. He suggested me to try replacing the Windows workstations by substituting local installations by a server having several virtual machines, all regenerated from a clean image every day, and exporting rdesktop sessions. He suggested using Xen for this, as it is the virtualization/paravirtualization solution until now best offered and supported by most Linux distributions (including, of course, RedHat, towards which he is biased, and Debian, towards I am... more than biased, even bent). So far, no hassle, right?
Of course, I could just stay clear of this mess, as everything related to Windows is off my hands... But in October, we will be renewing ~150 antivirus licences. I want to save that money by giving a better solution, even if part of that money gets translated to a big server.
Get the hardware
But problems soon arose. The first issue was hardware. Xen can act in its paravirtualization mode on basically any x86 machine - but it requires a patched guest kernel. That means, I can paravitualize many several different free OSs on just any computer I lay my hands on here, but Windows requires full- or hardware-assisted- virtualization. And, of course, only one of the over 300 computers we have (around 100 of which are recent enough for me to expect to be usable as a proof-of-concept for this) has a CPU with VT extensions - And I'm not going to de-comission my firewall to become a test server! ;-)
When software gets confused for hardware
So, I requested a Intel Core 2 Quad Q9300 CPU, which I could just drop in any box with a fitting motherboard. But, of course, I'm not the only person requiring computer-related stuff. So, after pestering the people in charge for buying stuff on a daily basis for three weeks, the head of acquisitions came smiling to my office with a little box in his hands.
But no, it was not my Core 2 Quad CPU.
It was a box containing... Microsoft Visio. Yes, they spent their effort looking for the wrong computer-related thingy :-/ And meanwhile, Debconf 8 is getting nearer and nearer. Why does that matter? Because I have a deadline: By October, I want the institute to decide not to buy 150 antivirus licenses! Debconf will take some time off that target from me.
Anyway... The university vacations started on July 5. The first week of vacations I went to sweat my ass off at Monterrey, by Monday 14 I came back to my office, and that same day I finally got the box, together with two 2GB DIMMs.
Experiences with a nice looking potential disaster
Anyway, by Tuesday I got the CPU running, and a regular Debian install in place. A very nice workhorse: 5GB RAM, quad core CPU at 2.5GHz, 6MB cache (which seems to be split in two 3MB banks, each for two cores - but that's pure speculation from me). I installed Lenny (Debian testing), which is very soon going to freeze and by the time this becomes a production server will be very close to being a stable release, and I wanted to take advantage of the newest Xen administration tools. Of course, the installation was for AMD64 - Because 64 bitness is a terrible thing to waste.
But I started playing with Xen - And all kind of disasters stroke. First, although there is a Xen-enabled 2.6.25 Linux kernel, it is -686 only (i.e. no 64 bit support). Ok, install a second system on a second partition. Oh, but this kernel is only domU-able (this is, it will correctly run in a Xen paravirtualized host), but not dom0-able (it cannot act as a root domain). Grmbl.
So, get Etch's 2.6.18 AMD64 Xen-enabled kernel, and hope for the best. After all, up to this point, I was basically aware of many of the facts I mentioned (i.e. up to this point I did reinstall once, but not three times)... And I hoped the kernel team would have good news regarding a forward-port of the Xen dom0 patches to 2.6.25 - because losing dom0 support was IMO a big regression.
But quite on time, this revealing thread came up on the debian-devel mailing list. In short: Xen is a disaster. The Xen developers have done their work quite far away from the kernel developers, and the last decent synchronization that was made was in 2.6.18, over two years ago. Not surprisingly, enterprise-editions of other Linux distributions also ship that kernel version. There are some forward-patches, but current support in Xen is... Lacking, to say the least. From my POV, Xen's future in the Linux kernel looks bleakish.
Now, on the lightweight side...
Xen is also a bit too complicated - Of course, its role is also complicated as well, and it has a great deal of tunability. But I decided to keep a clean Lenny AMD64 install, and give KVM, the Kernel Virtual Machine a go. My first gripe? What a bad choice of name. Not only Google searches for KVM gives completely unrelated answers (to a name that's already well known, even in the same context, even in the same community).
KVM takes a much, much simpler approach to virtualization (both para- and full-): We don't need no stinkin' hypervisors. The kernel can just do that task. And then, kvm becomes just another almost-regular process. How nice!
In fact, KVM borrows so very much from qemu that it even refers to qemu's manpage for everything but two command-line switches.
Qemu is a completely different project, which gets to a very similar place but from the other extreme - Qemu started off as Bochs, a very slow but very useful multi-architecture emulator. Qemu started adding all kinds of optimizations, and it is nearly useful (i.e. I use it in my desktop whenever I need a W2K machine).
Instead of a heavyweight framework... KVM is just a modprobe away - Just ask Linux to modprobe kvm, and kvm -hda /path/to/your/hd/image gets you a working machine.
Anyway - I was immediatly happy with KVM. It took me a week to get a whole "lab" of 15 virtual computers (256MB RAM works surprisingly well for a regular XP install!) configured to start at boot time off a single master image over qcow images.
KVM's shortcomings
Xen has already been a long time in the enterprise, and has a nice suite of administrative tools. While Xen depends on having a configuration file for each host, KVM expects them to be passed at the command line. To get a bird-eye view of the system, xen has a load of utilities - KVM does not. And although RedHat's virt-manager is said to support KVM and qemu virtualization (besides its native Xen, of course), it falls short of what I need (i.e. it relies on a configuration file... which lacks expresivity to specify a snapshot-based HD image).
To my surprise, KVM has attained much of Xen's most amazing capabilities, such as the live migration. And although it's easier to just use fully virtualized devices (i.e. to use an emulation of the RTL8139 network card), as they require no drivers extraneous to the operating system, performance can be greatly enhanced by using the VirtIO devices. KVM is quickly evolving, and I predict it will largely overtake Xen's (and of course, vmware and others) places.
Where I am now
So... Well, those of us that adopt KVM and want to get it into production now will have some work of building the tools to gracefully manage and report it, it seems. I won't be touching much my setup until after Debconf, but so far I've done some work over Freddie Cash's kvmctl script. I'm submitting him some patches to make his script (IMHO) more reliable and automatizable (if you are interested, you can get my current version of the script as well). And... Starting September, I expect to start working on a control interface able to cover my other needs (such as distributing configuration to the terminals-to-be, or centrally managing the configurations).

Here I am writing today to tell something that might not be known outside Brazil at least, I haven t read much in English about it the attempt to turn the Internet into a government surveillance device. This story goes back to 2006 (and even back), when we first successfully blocked the approval of a bill that would, in effect, turn the Brazilian Internet into a giant Big Brother. This bill was introduced by Senator Eduardo Azeredo as a replacement to a series of other similar bills that were attempted before and was followed by a strong resistance by civil organizations, one of those being ASL, of which I am proud of being one of the founders. By that time we ended having it postponed for more debate. It happened that the bill made a come back last weeks, and was pushed into approval by a subcommittee of the Senate (one that was suppose to deal with the constitutionality of bills) and now is heading to the Chamber of Deputies for appreciation. Apart from the first debates back in 2006, nothing happened between then and the approval. The bill have changed a little bit, but not much as to change its effects. In Brazil, we have two legislative houses, Federal Senate and Chamber of Deputies. If a Law Project is proposed by one, is revised by the other. So we have already lost 50% of the fight. Ronaldo Lemos, professor of Funda o Get lio Vargas (think about a Brazilian version of Harvard Law School ) have already stated how dangerous such a Law can be, once approved. In his own words: The wording of the law is too broad, and can be applied in several cases. The interpretation of what is a crime or not will be done by a criminal judge, who is used to deal with homicides and not with technology . Since its approval in Senate, several people have been putting together a resistance. Central to it is a Petition, hosted at Petition Online, that already holds 64-thousand signatures. One of the writers of that petition, Andr Lemos, a university professor and researcher, have said that the regular user will have the feeling of being watched, and not knowing if what he s doing in legal or not: For instance, if I disseminate a virus without knowing, will I be arrested? Can I exchange my files in P2P networks (my pictures, my musics, my text files) without asking for permission? How will the ISPs interpretate these exchanges? Can I copy a part of a text from a blog and paste it into mine? This law creates a feeling of insecurity and generalized fear . FGV s Center for Society and Technology have published an analysis of the Law Project, and have spotted a lot of problems in it. For instance:

• Unlock a cellphone to be used in another carrier or unlock a DVD player, so it reads disks from different regions, can be a crime punished with 1 to 3 years of imprisonment and a fine, as deals article 285-A;
• Copy something from a blog that doesn t state access restrictions is turned into a crime since a blog is covered by copyright and, if not stated otherwise, those restrictions should apply, and someone that copies can be punished with the same 1 to 3 years of inprisonment and a fine, as deals article 285-B;
• Unlock the iPhone using softwares like jailbreak is turned into a crime punished with 2 to 4 years of imprisonment and a fine, as deals article 163-A. Even put a link somewhere in your site pointing to the software jailbreak is considered a crime;
• The ISP is turned into a surveillance apparatus, and is mandate to inform the authorities about any of the crimes the Law deals with, as states article 22.

Thinking of how I can help, after sending an email to every Deputy whose email address I was able to get, I decided to translate the law into English (I also uploaded a version with indentation, since it s pretty hard to understand the whole law without it, if you re not used to), so the World can be made aware of what s going on in Brazil. I also just sent an email with it to EFF, asking for their help. Not that I think they can do much, but they surely will know one or two strings to pull in order to put more pressure on the Brazilian government. I also hope that, once this post reaches Planet Debian, even more people become aware of the issue. In a sense, this is an appeal for all the Freedom Culture lovers out there to take any actions they can to help us prevent this Law Project to become a Law. (In time, I d like to thank Alexandre Oliva, who revised the translation). Update (2008-07-23 11:50): Steve Langasek also revised the translation of the Law Project and I ve made a cherry-pick merge , which resulted in the version currently linked in the text above. Older version of the plain and the indented documents are still available. Thanks Steve!