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.
It is nice when you work for a company where you can say:
The next thing was to ensure that the machine had RAID-6 (I have been convinced that that using only RAID-5 verges on professional malpractice). As the machine is rented from a hosting company there was no guarantee that they would follow my clear written instructions involving running RAID-6.
The machine is a HP rack-mounted server with a CCISS RAID controller, so to manage the array the command /usr/sbin/hpacucli is used.
The command hpacucli controller all show reveals that there is a “Smart Array P400 in Slot 1“.
The command hpacucli controller slot=1 show gives the following (amongst a lot of other output):
I had to learn it the hard way; really cheap plane tickets doesn’t exist unless you buy them months in advance, and killing three hours at an airport can be done by writing a long post on how to kill three hours at an airport. But Finnair does have the funniest instruction videos I’ve ever seen. Going to Helsinki for Assembly 2008 was worth the money.
This was my first party outside Norway, and the one thing that really surprised me was that most of the gamers actually did kill all audio and lights when told to do so. Smash told me that some hardcore gamers just put a towel over their head and screen to continue playing, but I still think it deserves some credit.
Being at the party place was ok, even with the security check. I think the scene booth organized by Truck was great, even though I don’t have anything to compare it to. It was nice to see someone walk up to the booth and ask a lot of questions. I’m happy about missing out on Hesburger, and sad that it took me two days to find the Pizza Hut.
Boozembly was a lot more fun, even with the rain. I found out that Sauli can be a very nice guy, that you don’t need toothpaste when you have mintu, that guys in kilts got nothing under and that kiitos means thanks. I sure hope information like this will be useful to someone someday.
It’s always nice to see old friends, like Spiikki, again and even nicer knowing that you can still pick up where you left two years ago. And it’s fun meeting the skilled people you’ve admired for a long time. Actually telling them that got a bit easier when I managed to stop being so shy.
I always find it difficult to keep it short and still cover the most important things, so I just want to say the following; I think the 4k by Portal Process and TBC rocks, and the 64k by Fairlight did impress me. Thanks to Leia and Little Bitchard for letting me crash at their place. And thanks to Gargaj for being awesome.
I found an 
I think that the next thing to do is to beat the floating-only window manager like the *box, etc An interesting challenge, so stay tuned! 
Trying to debug a race condition in dsh.
I received a report that dsh drops a few hosts when running 'hostname' on parallel on 1000+ node clusters.
I have set up some testsuite and simulation environment, and found some possible causes, and
managed to reduce that rate to about 1/3000. However, it's not zero, and I feel uneasy that not all corner cases have been found. I hate this feeling.
As mentioned earlier, I've uploaded a new
I recently bought a new MSI laptop and I am really pleased with my choice so far.
I just wrote this in my 
… 
As some of you know, I’ll stop working on Galician translations (of everything) after Lenny is released (or after the end of October, if Lenny is not released before). Before that, I’m going to start documenting several aspects of my work on it in several blog posts. I’m not going to follow any particular order; when everything’s written, I’ll collate the documents and make them available together in a single coherent document.
Although it is written for the future Galician team, this work (even the final document) will be written in English. If it is a problem for anyone, I don’t want them as translators. And, also, this will make this document potentially useful for other teams.