Got this gem today:

This is to bring to your notice that I am delegated from the United Nations to Central bank of Nigeria to pay 100 Nigerian 419 scam victims $10 Million each, you are listed and approved for this payments as oneof the scammed victims, get back to as soon as possible for the immediate payments of your $10Million compensations funds.

Quite clever — the kind of stupidity that lets you believe this kind of email the first time will also get you a second time with this one... (Oh, yes: if you really want, you can contact mrjohnwilliamy2k1@live.com yourself.)

Spent the first half of the day working on a web inteface to configure ikiwiki. The next version of ikiwiki will have that and some other neat setup features that make it really easy to set up a wiki. Then up to Abingdon for VA highlands. I was actually reminded of Edinburgh, but not by the kilts and celtic music; instead by the post-rain damp and little alleys. Drove Anna's golf cart around the swamp. Suprisingly capable in mud and creek ford and general rough going. (PS, if my next car has internal combusion, please shoot me.) Another night on battery power @yurt. Now playing: Cicadas and The Who, loudly.

A while back wanted to know about a replacement for my Dreambox. I was also asked to write up a summary of the replies. Initially I assumed that my Dreambox 7025C was failing, it showed a classic symptom, progressively increasing error rate which wasn't showing up on my neighbors. Since we share the cable they should see the problems too, so I ordered new tuners for the box and the problem persisted. In the end it turns out that the problems were initially showing on such channels that my neighbors weren't watching or in such amount that they didn't pay attention to it. In the end it was a problem in the feed and my box is just fine. I now have 2 brand new DVB-C tuners for the 7025 (anyone want to buy them?) and a perfectly working setup. (YAY!). In a way I feel lucky that the box wasn't failing on me. Nobody suggested any complete solutions, but I was able to spot ReelBox Avantgarde as a possible alternative. It runs Linux like I want it to, but it's way too expensive. Another alternative could have been Maximum 8000, which appears to be a re-branded Marusys C-8000. It has Linux as the OS but the community side appears to be rather lacking. Then again, it's a pretty new device... I was suggested VDR and MythTV as the DIY solution. I dismissed MythTV without even looking in to it. Although I must admit that it's been quite a few years since I tried MythTV, but it was way too unstable for my taste. Also I wasn't too happy about the architecture of it. VDR is something I could have tried. The downside appears to be that it lacks in hardware support. The last time I was building my own PVR I ran in to the common problem of getting a decent output to the TV. VDR folks have traditionally solved this by using a HW decoder card to output the stream directly to the TV. Using VDR with a budget DVB card is possible but not recommended because of the CPU power needed to decode the stream. I've always considered VDR to be the more sophisticated solution of the two, but it is starting to sound a lot more hassle than it's supposed to. Also, the DIY solutions are hard to get in to a decent form. Usually the cases are bulky and custom modifications are required. I'm not one of those guys that install neon lights to their computers to make it look cool, but if I'm having it in my living room I expect it to look decent. Take a look at the VDR boxes section on the website for examples. While I admit that it's up to me to build a decent box, I'm not willing to spend too much time hand picking every single component so that it fits a casing and works with the given application. Finally, I'd like to thank all the people that sent me comments. Even though I ended up sticking with the current setup, it was a valuable look in to what is out there. The Dreambox I have, doesn't have a HDMI output and lacks in few areas. Keeping that in mind I'm eventually going to take this same look in to the alternatives while picking a replacement for the current box. Lets hope VDR, MythTV and Elisa (to name a few) continue to evolve and the video output properties of Linux become better and eventually I'll have the possibility of replacing my current setup with something that is even more flexible.

The lecture by Professor James Duane about why you should not talk to the police (in the US at least) is doing the rounds at the moment. The Google video site doesn’t work for me, so I downloaded it from youtube with the following references:
part 1 [rVq6N0xAEEM]
part 2 [-Z0bpj3EEHI]
part 3 [44-GSZofXIE]
part 4 [zSvxiaO-TG8]
part 5 [gzYHnWrqfWg]
part 6 [BErNzdOnWGY] The first thing that struck me about this is that it’s the first time I’ve ever seen someone clearly state the problem with the excessive number and complexity of the laws. It’s impossible to know whether you are breaking the law. This is obviously wrong and it should be a legislative priority to reduce the number of laws and the complexity of the laws. If for every law they sought evidence regarding whether it helped people or helped preserve the state then that would be a good start. The excessive number of laws is not just a problem due to the risk of accidentally breaking a law, but also due to the fact that a malicious cop could arrest anyone that they wished - it would merely be a matter of following them for long enough. In the second half of the lecture Officer George Bruch from the Virginia Beach Police Department gives his side of the story. At one point he cites an example of the road laws where he can follow a car and find a legitimate reason for booking the driver if he wishes. Virginian law allows the police to destroy primary evidence. If they tape an interview then they can transcribe it to a written record and then destroy the original tape. If the transcription removes some of the content that has meaning then the defendant is probably going to suffer for it. It’s often stated that on the net you have to make extra effort to make your meaning clear as jokes can’t be recognised by the tone of voice. It seems that the same effort would need to be made in a police interview (but without the possibility of going back and saying “sorry I was misunderstood” that you have in email). It’s also legal for police to lie to suspects. While I can imagine some situations where this could be reasonable, it seems that at a minimum there should be some protection for child suspects against being lied to by police (there have been some travesties of justice stemming from children trusting police in an interview room). It seems that if someone doesn’t get a good lawyer and refuse to talk to the police then they will be likely to be convicted regardless of whether they are guilty or innocent. Officer Bruch says that he tries to avoid interviewing innocent people. So I guess whether someone ends up in jail or not will depend to some extent on the opinion of a cop who may or may not interview them. While I guess a high rate of success at securing convictions is in most cases a good thing, the fact that convicting an innocent person is the absolute best way of letting a criminal escape justice seems to be forgotten. Another issue is the fact that a witness may have reason to believe that they could be a suspect. The advice that a suspect should never talk to a police officer seems to logically imply that intelligent people will be hesitant about providing witness statements in situations where they may be a suspect. I wonder how the legal system in Australia compares to the US in regard to these issues. I know that we have far too many laws and too many complex laws which can not be understood and obeyed by a reasonable person.

Share This

As always, we’re doing lots of interesting and significant things and have more good ideas than we have people to do the work.  If you have an Eee PC or are planning to get one, or are otherwise interested in our work, some of which has uses beyond just the Eee, here are some highlights: Earliest Eee models supported in Lenny Lenny will release with the atl2 ethernet driver and the non-free madwifi-source now works with the earliest Eee models as well, so our patched version is no longer needed.  This means Lenny will work with all of the earliest models of the Eee PC: 701 (2G and 4G surf, 4G, 8G) and 900! All we need now for full support in Lenny is to replace the non-free wireless driver with the free ath5k driver when it is ready. Free drivers Nick Kossifidis has submitted patches on linux-wireless supporting the Eee models currently supported only by the non-free madwifi in ath5k.  This means we’ll soon realize our goal of a completely DFSG free system for the earliest models of the Eee.  By 2.6.27, or at the latest 2.6.28, these models will be supported.  Then we will see about making a patch to support whichever kernel makes it into Lenny. New models Model 901, 1000 and 1000H users are now able to install using the atl1e ethernet driver from eeepc.debian.net.  Support for wireless and other aspects of the new hardware will follow soon.  The debian-kernel team was prompt to add atl1e to 2.6.26 which has just been uploaded to sid.  We hope 2.6.26 makes it into Lenny. Wireless installer Glenn Saberton has been doing an upstanding job adding wireless support to our custom Debian-installer.  We have supported WEP authentication for several releases, now, and a beta version supports WPA.  Glenn is also making progress with these patches upstream so that non-Eee Debian users will benefit from our work. LXDE is in Lenny LXDE has entered Lenny, thanks to Andrew Lee.  It is a quite lightweight desktop environment that is made with the Eee PC in mind. Live images Two flavours of Debian-live USB images are available: a demo of the LXDE desktop and a minimal console-only image for rescue/backup.  The images are still in alpha stage of development.  If you’d like to help, give us a shout.

More interesting things are planned for the future that benefit Debian as a whole.  With a small amount of work patching live-helper, anyone will be able to make a live image that includes a customized Debian-installer. Mobile device initiative This month on debian-devel, there was some interesting discussion about Debian support for the Intel Atom processor and a possible mobile net device initiative.  That’s something we could get behind, if anything comes of it. Wiki translation Robert Epprecht has been keeping the German wiki translation in good shape, but we could always use some more help with any of the translations. New members welcome If you’d like to join us, check out our site at http://wiki.debian.org/DebianEeePC and drop us a note on our list or join our irc channel and talk to us about what you’d like to do.    

When I first packaged the SE Linux policy for Debian the only way to adjust the policy was to edit the source files and recompile. Often changes that you might desire involved changing macros so while it would have been theoretically possible to just tack a few type definitions and allow rules at the end, you often wanted to change a macro to have a change apply all through the policy. To deal with that I had the policy source installed on all machines and the package update policy would compile it into a binary form and load it into the kernel. Now there was the issue of merging user changes with changes from a new policy package. For most configuration files on a Unix system you can just leave any files that are modified by the user, not taking the new default configuration might cause the user to miss out on some new features - but presumably they were happy with the way it worked in the past. However due to inter-dependencies this wasn’t possible for SE Linux, if one file was not ungraded due to user changes and other files related to it were then the result could be a compile failure. Another issue was the fact that a newer version of the policy might permit operations that the sys-admin did not desire and therefore not meet their security goals, or it might not permit operations that are essential to the operation of the system and interrupt service. To solve this I wrote a script that prompted for upgrades to policy source files and allowed the sys-admin to choose which files to upgrade. This worked reasonably well in the early days when the number of files was small. But as the policy increased in size it became increasingly painful to upgrade the policy with as many as 100 questions being asked. The solution to this (as implemented in Fedora Core 5, Debian/Etch, and newer distributions) was to have binary policy modules that maintain their dependencies. Now there are binary policy modules which can be loaded at will (the default install for Debian only installs modules that match the installed programs) and the modules can have optional sections with dependencies. So if you remove a module that defines a domain and there are other modules which have rules to allow communication with that domain then the optional sections of policy in the other modules is disabled when the domain becomes undefined. This solves the technical issues related to module inter-dependencies but the issue of intent and interaction with the rest of the system remains. With Red Hat distributions the solution has been to upgrade the running policy every time the policy package is upgraded and be cautious when changing policy. They do a good job of the upgrade process (including relabeling files when the file contexts change) and in terms of policy changes I have not heard complaints from users about that. Users who don’t want a newer version of the policy can always put the package on hold. For the Debian distribution after Lenny I plan to have a policy upgrade process that relabels files and a debconf question as to whether package upgrades should upgrade the policy. But for Lenny the freeze is already in progress so it seems to late to make such changes. Instead I’m going to upload a new version of the selinux-basics package with a program named selinux-policy-upgrade that will upgrade all the policy modules that are in use. This is not the ideal solution, but I think it will keep Lenny users reasonably happy.

Share This

I have written a script named postfix-nochroot to disable the chroot functionality of Postfix. I plan to initially include this in the selinux-basics package in Debian, but if the script was adopted by the Postfix package or some other package that seems more appropriate then I would remove it from selinux-basics. The reason for disabling chroot is that when running SE Linux the actions of the various Postfix processes are restricted greatly, such that granting chroot access would increase the privileges. Another issue is the creation of the chroot environment, the Postfix package in Debian will recreate the files needed for the chroot under /var/spool/postfix when it is started. The first problem with this is that when a package is ugraded the chroot environment won’t be upgraded (with the exceptions of some packages that have special code to restart Postfix) and when the sys-admin edits files under /etc those changes won’t be mirrored in the chroot environment either. The real problem when running SE Linux is that it requires extra privileges to be granted to the Postfix processes (to be able to call chroot()). While the SE Linux policy places much greater restrictions on the actions of daemons than a chroot would. For example a non-chrooted daemon process running with SE Linux will not be able to see most processes in ps output (it will be able to see that processes exist through entries under /proc, but without the ability to search the subdirectories of /proc related to other processes it won’t be able to see what they are). It would be possible for my script to be used as the first step towards making a Postfix installation automatically use a chroot when SE Linux is disabled or in permissive mode, and not use a chroot when SE Linux is in enforcing mode. I’ve probably done about half the work that is needed if this was the end goal, but I have no great interest in such configuration and no time to work on it. I would be prepared to accept patches from other people who want to go in this direction.

Share This

As mentioned earlier, I've uploaded a new Pyroman release to Debian. I've also updated the download at the download page on alioth for the non-Debian users.There is just one single user-visible change (under the hood I switched some Python API so you need python 2.4+ now, which was available in sarge already):This version has a new command line option, "--verification-cmd". This can be used to point to a script file to verify network connectivity. For example, you could try to send a ping to the next router, or you could ssh to another host, have it ssh back and touch a flag file in /tmp to signal success.Similar to the --safe option, it is meant as a safety feature to avoid locking yourself out of your system. But while --safe needs to be used interactively, this new command could be used when automatically activating new firewall rules, e.g. triggered by cfengine or some other configuration management. If the verification command does not succeed, the firewall rules will automatically be rolled back to the previous state.Note that I didn't get around to add IPv6 support yet. It would definitely be desirable to add ip6tables support, but I currently do not have any experience with IPv6, so I'm not sure I'd know how to do things right. Of course I'd welcome any patches.(In case you havn't read about pyroman yet - it's yet another tool to configure iptables firewalls. It puts a thin abstraction layer on top of iptables, but the main benefit is that it uses "iptables-restore" to quickly mass-set all the firewall rules - other tools tend to invoke several hundred iptables processes to achieve the same - and if any error occurs it will both give you a clear indication of which rule caused the error and rolling back your firewall to the previous state.)

Coincidentally, I had the opportunity to poke at a machine that actually does deliberately treat Linux differently in its ACPI tables today. Jeremy was poking at an Acer Aspire One before installing Fedora on it, and Dave noticed that it printing a bootup message indicating that the firmware was testing for _OSI("Linux"). A bit of poking later, and we have the following:

            If (_OSI ("Linux"))
             
                Store (0x03E8, OSYS)
                Store (0x0A, \_SB.PCI0.LPC.S4TM)
                Store (0x43, \_SB.PCI0.EXP2.PXS2.LSMP)
                Store (One, \_SB.PCI0.EXP2.LL0S)
                Store (One, \_SB.PCI0.EXP2.LLL1)
             
            Else
             
                If (_OSI ("Windows 2006"))
                 
                    Store (0x07D6, OSYS)
                    Store (0x06, \_SB.PCI0.LPC.S4TM)
                    Store (Zero, \_SB.PCI0.EXP2.PXS2.LSMP)
                    Store (Zero, \_SB.PCI0.EXP2.LL0S)
                    Store (Zero, \_SB.PCI0.EXP2.LLL1)
                 

Other OSes get the same values as Linux, other than the OSYS field. Now, what do these writes do? They're all to PCI config space, so since the machine in question is a 945/ICH7 machine we have publically available docs. A bit of digging later and it shows that the firmware is disabling PCIE active state link control and programming more conservative timings for entry into the C4 processor idle power saving state. In other words, certain bits of power management functionality are compromised if it detects that it's running anything other than Vista. Weirdly, it also flags the HPET as present but invisible on Linux, but I suspect that's an oversight rather than anything deliberate.

Why would they do this? I've no idea. I suspect it's something to do with the degree of platform validation performed rather than a subtle attempt to degrade Linux's battery life on the hardware (frankly, we do a good enough job of that ourselves right now), but this is exactly the kind of reason we removed _OSI("Linux") support from the kernel. Vendors will do stupid things with it.

I recently bought a new MSI laptop and I am really pleased with my choice so far.

Since with the previous laptop I managed to kill two of my desired features, long battery life and pretty portable, I decided is time to look really well and see what the market has to offer.

I settled on a MSI PR200WX-058EU which has the following:

• built on a Centrino platform
• Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
  
• Intel Corporation PRO/Wireless 4965 AG or AGN
• Intel mobile chipset
• 3GB of memory (yes, I would have enjoyed 4, but it seems the 32 bit barrier still decides hardware configurations)
• 320GB HDD
• DVD+/-RW
• Mobile GM965/GL960 Integrated Graphics Controller
• 12" wide screen (1280x800)
• 1 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
• 8 cell battery by default (long battery life)
  
• 1 USB 2.0 Camera - uses luvc driver
• bluetooth
• 1 card reader
• 3 USB port, 1 HDMI, 1 D-sub 15 connector, 1 PCI Express port, modem port
• fingerprint reader
• an advertised weight of 1.8kg (I weighted it at 2.1kg with the 8 cell battery)
  

In other words a small and mobile powerhouse for which I payed 3800 RON (approx. 1100 ). I'd say not too bad at all.

Thanks to Gon ri Le Bouder and some searches on the internet I concluded that
the brand is not bad at all, and now that I have it I really am sure.

Of course, I installed Debian Lenny on it (I also sent an installation report), and, in spite of the initial problems, I managed to make the laptop work pretty nice, but I am especially excited about the webcam, which works with the linux-uvc driver.


There were some issues, but I managed to fix some them while I have been ignoring some other. The LaptopTestingTeam page for MSI PR200 on the ubuntu wiki was very helpful.
What have I been ignoring?

• it seems that from time to time the battery charge status isincorrect, or acpi report that the AC is plugged in
• headphones don't automatically turn off the speakers
• fingerprint reader is not used yet, but I intent to experiment at some point with it (authentication via the fingerprint would be cool)
  
• the keyboard seems a little bit too hard (but I hope it will loose up with time)
• modem isn't probably working, but I don't think I'll ever try
• there are some issues in gnome-power-manager which cause strange behaviour and grief wrt screen brighness
• sleep doesn't work,but hibernation does
  

What would you do if I'd tell you that the battery lasts 4 hours or even more while the wlan is on and working (browsing and stuff like installing new packages, configs) with the brightness set to minimum?


I am really excited about this and I can say that I think I have found my next generation laptop, so if you're thinking of a cheap mobile powerhouse on which Linux must run, this laptop might be for you.

I find the following to be selling points (for a Linux buyer or others):

• comes with FreeDOS, so no extra money for an OS you don't use
  
• wifi works
• webcam works with luvc
• no big problems during install (the most severe are already fixed)
• long battery life, even when using wifi (4+ hours in browsing+some package installation mode, according to my tests)
• light enough to carry around easily (2.1kg, 2.4kg with charger)
• nice design - some people asked me if I bought a MacBook
• 4 state kill switch for all possible combinations for wifi/bluetooth
• hibernate works with 2.6.24 or newer (sleep doesn't, but I will try a few things later)
  
• there's no mechanical latch for the lid, there is a magnet, so there's no plastic to be broken, the laptop is more robust
• the 8 cell battery is thicker than the regular one, allowing better ventilation
• it seems it doesn't get too hot to put on my lap (still, I am a little afraid of blocking its ventilation due to the fabric of my clothes, so I'll probably try to carry around a hard paperboard or something like that)
• the big resolution 1280x800 (for this screen size) seems to partly compensate for the reduced physical size of the screen (12")
• bright screen

So, thanks again to Gon ri, Debian Installer team, LVM2 maintainers, Ubuntu Laptop Testing team, linux uvc developers, Lilo developers and maintainers, all the nice people who made and still make Debian possible.

It seems I have been wrong about the origins of the Seville Orange joke Rather than Algernon Sidney It would appear to have been quipped by an 18th century Anglo-Irish actor named James Quin as recounted in "Lives of the Players" by John Galt (not that John Galt but this one) in 1831.

Quin once, in the character of Cato, received a blow in his face by an orange thrown from the upper gallery; such a circumstance would have disconcerted many an actor possessed of less presence of mind, but instead of being disturbed, he wiped his face, and taking it up, observed, "It was not a Seville orange."

A proto-version of the joke does date back to Sidney's time. It was made by none less than William Shakespeare in "Much Ado About Nothing" Act II, Scene 1:

DON PEDRO: Why, how now, count! wherefore are you sad?

CLAUDIO: Not sad, my lord.

DON PEDRO: How then? Sick?

CLAUDIO: Neither, my lord.

BEATRICE: The count is neither sad, nor sick, nor merry, nor well; but civil count, civil as an orange, and something of that jealous complexion.

Note Don Pedro is from Aragon which is close enough to Seville for Elizabethan comedy purposes. But while 300+ years is impressive, this joke from Sumeria c. 19th-16th centuries BC is older by far:

Something which has never occurred since time immemorial: a young woman did not fart in her husband's lap.

See The world's ten oldest jokes

I have written a script for Debian named selinux-activate which is included in selinux-basics version 0.3.3+nmu1 (which I have uploaded to Debian/Unstable). The script when run with no parameters will change the GRUB configuration to include selinux=1 on the kernel command-line and enable SE Linux support in the PAM modules for login, gdm, and kdm. One issue with this is that if you run the command before installing kdm or gdm then you won’t have the pam configuration changed - but as it’s OK to run the script multiple times this shouldn’t be a problem. The new selinux-basics package will also force a reboot after relabelling all filesystems. I had tested “umount -a ; reboot -f” but discovered that “reboot -f” causes filesystem corruption in some situations (my EeePC running an encrypted LVM volume on an SD card had this problem). So I now use a regular “reboot“. If no-one points out any serious flaws I plan to ask the release team to include this version of selinux-basics in Lenny. I believe that it will make it significantly easier to install SE Linux while also reducing the incidence of systems being damaged due to mistakes. If you edit the GRUB configuration file by hand then there is a risk of a typo making a system unbootable. The package in question is already in my Lenny repository, see my previous post about Lenny SE Linux for details [1].

• [1] http://etbe.coker.com.au/2008/07/31/installing-se-linux-on-lenny/

Share This

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.

You can approach debconf translation work in two ways: you can be active and seek out packages to translate and update, or you can be reactive and translate and update packages when someone requests it to be done. Usually, nobody takes a purely active or reactive stance; for example, lately I used to react to calls for translation updates, but when I had some spare time I would go translate a couple of new packages. When you work actively, the web page whose URL you need to know is http://www.debian.org/intl/l10n/po-debconf/. There you have links to all languages for which there are translations. Click on yours, and you’ll see a page listing the state of every source package’s debconf template translations for your language. First, you see the partially-translated packages, then the fully translated packages, and finally a list of packages which are not translated to your language. For each package in the first two sections you can download the .POT and .PO files; the names of the packages in the last section just link to a big webpage from which you can download every package’s .POT file. In the top part of the page you have links to other useful pages. An interesting one is the ranking page, which lists all the languages in order of completeness. For working reactively, you need to subscribe to the debian-i18n mailing list, because when there is a call for updates or for translations it is always sent to that mailing list. Also, if there already is a translation for your language, another email will be sent to the translation group’s mailing list, as well as to the file’s latest translator. Calls for translations include information on the deadline and the package maintainer’s preferred methods for submitting the translation. There may also be some notes from the package maintainer. Finally, the .POT file is attached to the call for translations sent to debian-i18n, while the old .PO file is attached to the call for translations sent to the group and the latest translator. Calls for translations can be sent by the package maintainer when the debconf templates have been modified and the translations need to be updated, but they can also be sent by other people for many other reasons. For example, for the last months there’s been a campaign to upload packages for which there were newer translations that hadn’t been uploaded yet, so NMUs for these packages (non-maintainer uploads) were announced, including a call for translations. Also, there was a campaign to review all packages’ debconf templates, make them more consistent, improve their grammar, etc., and a call for translations was issued for every package after the review.

And here, yet another Argentina post before I have to do some work again (like the Entrance Controller needs some love). This time with pictures! :) You can have pretty nice desserts in BA, as this picture with Mark on it proves. I think he will really love me for this post. Really. (It wasn’t actually his dessert :) ).

---

Anyways, this morning we took the opportunity walking over to see the Atlantic Ocean. Damn long way, proven by the next picture (the building marked with that arrow is our Hotel, us standing right beside the beach). Fun thing - Mark was walking outside with a T-Shirt only, while all those Argentinian people use winter clothes. Got him quite a bit of weird looks from all of them. :) Right now we are back, sitting in the first prepared hacklab. Yes, those grey things below the tables are for cabling, so there is a lot of power outlets, should be enough for everybody to get power, without doing long daisy chains. Comments: 1

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

Ben Armstrong opened an ITP for the ATL1E NIC driver, which is found on some Asus EeePC laptops. So, as suggested by Maximilian Attems, I provided a clean patch for this driver, made from a cherry-pick from the linux-netdev 2.6.27 tree. It has been commited into the 2.6.26-1 Debian kernel, which will be furnished with Lenny. What's fun, is that in the mean time, I got a new computer at work. Wait, it's not fun yet. Because what I did not know is that it's made of an Asus P5Q motherboard which runs a NIC needing the ATL1E driver (and now you see it's fun). So I've just upgraded to 2.6.26-1-amd64 and I'm glad that my own work is useful to me (and will be probably be to others as well).

Currently Debian/Lenny contains all packages needed to run SE Linux apart from the policy. The policy package is missing because it needs to sit in unstable for a while before migrating to testing (Lenny), and I keep fixing bugs and uploading new versions. I have set up my own APT repository for SE Linux packages (as I did for Etch [1]). The difference is that it’s working now (for i386 and AMD64) while I released my Etch repository some time after the release of Etch. gpg --keyserver hkp://subkeys.pgp.net --recv-key F5C75256
gpg -a --export F5C75256 apt-key add - To enable the use of my repository you must first run the above two commands to retrieve and install my GPG key (take appropriate measures to verify that you have the correct key). deb http://www.coker.com.au lenny selinux Then add the above line to /etc/apt/sources.list and run “apt-get update” to download the list of packages. Next run the command “apt-get install selinux-policy-default selinux-basics” to install all the necessary packages and then “touch /.autorelabel” to cause the filesystems to be labeled on the next boot. Edit the file /boot/grub/menu.lst and add “selinux=1” to the end of the line which starts with “# kopt=” and then run the command update-grub to apply this change. Then reboot and the filesystems will be relabeled. Init will be running in the wrong context so you have to reboot again before everything is running correctly (I am thinking of having the autorelabel process automatically do the second reboot). For future reference please use the page on my documents blog - I will update it regularly as needed [2]. This post will not be changed when it becomes outdated in a few days.

• [1] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/


• [2] http://doc.coker.com.au/computers/installing-se-linux-on-lenny/

Share This

After a night at Tinchos place, then driving and walking around Buenos Aires a day and finally taking a 5hours bus trip, Mark, Stephen and I arrived in Mar del Plata early this morning, at around 05:30AM. Brr, early. We could checkin to the Hotel at 06:30. During checkin we discovered that Stephen and my birthday are, in absolute numbers, 6 years, 6 months and 6 days apart, ie. 666. And we are managing the evil, I mean, the network for DebConf. HA. HAHA. HAHAHAHAHAHAHAHAHAHAHAHA. Ignoring that - stuff looks pretty nice over here. Most machines are working, most services we (as in admins, not video team) care about are setup or will be ready within the next 2 days, the Hotel stuff is doing the last preparations, it all looks great. There hasn’t been a DebConf that was that prepared, ever. We currently have a local smtp server accessible for everyone here (no direct outgoing smtp, we firewall that), a local OFTC IRC Server (Freenode IRCd is in setup), soon a full (pushed) mirror, preparing an upload queue for ftp-master, a schedule announce bot is also ready to run, most of the building has good wireless covering (and the rest is scheduled to get better soon). And lots of other nice things that are surely there and I just forgot to mention but which we will mention in some wiki page in time for you. (Oh, and make sure to listen to what DHCP tells your machine, all the various services get send to you :) ). Comments: 0