Lenny has been frozen some four hours ago and still nobody blogged it yet, so I decided to break the news to those who care more about blogs and planets then old fashioned nice mailing-lists :-)

Unfortunatly no word was said about the kernel for lenny, so I asked on #debian-release whether that means, we will release with 2.6.25, which is what's in unstable and testing atm. The answer from a release team member was: no, it will probably be 2.6.26.

Happy polishing!

/me goes back to arriving in wonderful Madrid with wonderful company :-)

The above blog post was written yesterday but due to an user error due to being too tired I didn't manage to post it until now. But as still no one blogged about the freeze... :-)

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.

On Thursday my new InterNode ADSL2+ service was connected [1]. I needed to get a connection with a larger download cap and a better upload speed because one of my clients wants me to transfer some significant amounts of data as well as hosting some Xen DomU’s for him. Strangely InterNode couldn’t offer a regular ADSL service but could offer Naked DSL (which means DSL without a phone service on the same pair of wires). So I now have Naked ADSL 2+[2] although unfortunately the line speed is reported as being 8263/814 Kbps - ADSL2 speed. For the moment this will do, but I’ll investigate the possibility of improving this eventually. Another strange thing about this is that Optus is the carrier for the ADSL line, Telstra is the monopoly telco with the vast majority of local-loop copper pairs so it’s surprising that I end up with Optus owning my copper - the wires in question were used by the previous owner of my house for a Telstra connection! On Friday I converted my network to using the new ADSL link and on Saturday I got my SE Linux Play Machine online again [3]. I could have managed the transition without ~20 hours of down-time for the Play Machine, but as I only get a few logins per day it didn’t seem to be worth the effort of rushing it. Also on Friday I got a new 3G modem from Three [4]. They advertise that the USB or PC-Card modem will cost $5 per month on a 24 month plan, but when I ordered it I discovered that as I have an existing mobile phone plan with them the $5 per month is waived. So all that I have to pay is $15 per month for a 1GB data allowance (which is about the best deal available). A client is paying for this so that I can provide remote support for his network. I had previously written about my search for an ideal mobile SSH client [5], I ended up getting an EeePC 701 which cost $300, an 8G SD card and 8G USB stick (for expanding the internal storage and for moving files around respectively) which cost $83, and now $15 per month over 24 months for net access. That gives a total of $743 for two years of mobile net access. This compares well to the $960 that an iPhone would cost over two years and provides a lot more utility (while admittedly not fitting into a pocket). Dave Hall [6] gave me a lot of great advice about selecting and using 3G modems. He recommended that I get the E220 modem as it’s easy to configure (mine was easy on Debian/Lenny but didn’t work with a Debian/Etch kernel as the necessary driver was not available). Three also sells another model the E169G which is apparently tricky to set up. There was one mistake made in the design of the E220, the cable is installed in such a way that the LED which indicates connection status is going to be face-down when connected to almost any laptop which has horizontally mounted USB ports (which includes all the thinner ones). Here is the PPP chatscript for use with an E220 modem (suggested file name /etc/chatscripts/three):

ABORT 'BUSY'
ABORT 'NO CARRIER'
ABORT 'ERROR'
'' AT
OK ATQ0V1E1S0=0&C1&D2+FCLASS=0
OK 'AT+COPS=0,0,"3TELSTRA",2'
OK AT+CGATT=1
OK AT+CGDCONT=1,"IP","3netaccess"
OK ATDT*99**3# Here is the ppp configuration file which references the above chatscript:
/dev/ttyUSB0
230400
noauth
defaultroute
usepeerdns connect "/usr/sbin/chat -v -f /etc/chatscripts/three"

• [1] http://www.internode.on.net/


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


• [3] http://www.coker.com.au/selinux/play.html


• [4] http://www.three.com.au/


• [5] http://etbe.coker.com.au/2008/07/16/mobile-ssh-client/


• [6] http://davehall.com.au/

Share This

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.

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?

For a week now, I couldn t get rid of this smile on my face (again).

It has been a hard year so far (back to therapy, again, back to medication, again, nasty insomnia, again, depression, again, getting phat as hell, again, my usual stuff, again). This has affected my job, which is the hardest of it all. Not being able to perform well has been troubling me to no avail, destroying my self-esteem.

But I have been feeling slightly better recently, I guess thanks to sunny days and chemistry reactions in (what used to be) my brain. And believe me: slightly better is a huge improvement. But what really put me on a great mood was reading the Wikipedia page on Mar del Plata, the Hotels web sites, the Debconf8 site... and realizing what a HUGE effort the localteam has made. I know they are exhausted, I know they are stressed, I know this week is probably the worst in their life. But the smile they ve put on my face! They have done a huge+great work.

Also, it looks like it will be a smaller event this year, I managed to count the assistants and I came up with 180, approx, and not all of them simultaneously. I must confess EDI was a bit too big for me to handle, so was MEX. I believe I will be able to spend more quality time with fellow debconfers, which I value a lot in this sort of events.This is precisely why I only attend the Debian room during FOSDEM, I cannot seem to enjoy getting out there in the (huge) crowd of attendees.

Anyway, I am smiling while typing this, and believe me: I look silly :)

I can t wait to meet the wonderful Debconf crowd again, specially my Argentinian friends.

See you in MDQ!

So as I've said before, this week is crazy but I have managed to upload nvidia-graphics-drivers with a RC bug fix and new legacy upstream 96.43.07 that supports 2.6.26. 71.86.06 will be uploaded later today. As far as testing goes I think I'll need some hinting and maybe a freeze exception once the kernel for lenny is decided on so I can create the appropriate kernel modules. Man all those kernel modules is gonna be a a pain. At least I have Internet at my new house now.

KVM Utility

Gunnar Wolf made an interesting post about KVM today which is timely. He points to a simple shell script for managing running instances of KVM which was a big improvement on mine - and so is worth a look if you're doing that stuff yourself. Once I find time I will document my reasons for changing from Xen to KVM, but barring a few irritations I'm liking it a lot.

Chronicle Theme Update

I made a new release of the chronicle blog compiler yesterday, mostly to update one of the themes. That was for purely selfish reasons as I've taken the time to update the antispam protection site I'm maintaining. There have been some nice changes to make it scale more and now it is time for me to make it look prettier. (A common theme - I'm very bad at doing website design.) So now the site blog matches the real site.

ObQuote: Resident Evil

My advisors just told me my grade for my final thesis I handed in two weeks ago: a 1.0 (which is the best possible grade here).Well, they've been quite clear about this being the likely result before, since the thesis worked out very well, with a publication on a good conference and such. So right now I'm looking forward to continuing this research and doing a PhD degree. Right now, this would be my favorite option, if I manage to get a position at the university.

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.

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

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!

LUGRadioLive 2008 by sheilaellen (cc-by-2.0) One aspect I didn’t mention in the LugRadio Live Event Review was how old-fashioned it seemed in some ways. I guess I’ve got used to seeing conferences experimenting with various web2.0 toys like live-blogging, feedback walls and so on, or the excellent live video streaming of DebConfs, but it was a bit of a surprise to find myself the only person in the audience who connected to the IRC channel from the event. One possible reason for that was that the wireless network was a bit difficult, or at least that was what I was told. I felt quite smug with my 3G smartphone IRC client (which I’ll blog about later) until Rufus Pollock mentioned the 800+ patents involved in 3G. Damn - I guess I hate freedom. In one way, I guess it’s appropriate if the network wasn’t up to the task. Broken networks were a regular feature of early ALUG meetings, as the end of this email hints. Web2.0 was there a little bit. There was a facebook page (which I accidentally spammed while travelling to the event), flickr:lugradiolive and a twitter link of #lugradiolive - but how does that work? There’s no user called lugradiolive and you can’t have usernames containing # Update: twitter:#lugradiolive (thanks to Dave Briggs for the explanation in a comment). Anyway, seeing as there will be another LUG Radio Live, maybe we can arrange something more interactive but free-software-friendly for 2009? More reviews I’ve read: davee: Lugradio-in makes me feel good , Peter Cannon: The party’s over for LugRadio Live and No’: Lugradio Undead - but why aren’t more people writing about this event? There seemed to be enough there. Or are they out there but I’m just not seeing them?

Thanks to the Virtuzzo developers for forward porting the OpenVZ patch to 2.6.26. It uses a lot of the already merged namespace features (For interested peoples linux-next carries interesting sysfs patches). The openvz upstream merge statistic is impressive. The namespace solution allows low overhead, while still running multiple Linux distributions in individual containers on the same box. Control over the network vitalisation is gained as a resource management for CPU power, I/O bandwidth and disk space. Live migration including snapshotting is possible too. The Debian 2.6.26 Linux images will feature not only better Xen vitalisation support, kvm port to new archs, but also an opvenvz flavour. Please don't forget to install proper vzctl userspace support as the correct dependencies have not yet been added. Supported archs will start with both x86 and the ia64 archs. Tomorrows linux-2.6 Debian trunk snapshots will already build openvz. Thanks for your feedback. P.S.: 2.6.26 is the targeted kernel for Lenny, we hope to convince Debian installer people to pick it up soonest - 2.6.25 is a not so bad backup plan as release hasn't fully approved 2.6.26 before extensive unstable testing.

Friday morning was not much fun compared to the rest of the weekend. I rushed to the bus stop only to wait in the rain for ten minutes. All of a sudden a bird decided to dump its crap on me, leaving me with no jacket and only one pair of pants for the whole weekend. And then, just to top it all, the bus driver failed to see me - meaning I had to wait twenty minutes for the next bus. It quickly became much better once we got to Oslo; picked up a friend at the airport, met up with some other people at the train station, bought a tent and even managed to get on the train to s in time. During the weekend I learned that Kock sf l ny l is super cute, that Norwegian girls speaking Swedish sounds funny, that I should bring more warm clothes next time and to stay away from birds in the future. There’s a lot of moments that I’m never going to forget. Like spending four hours putting up a tent, the Danes dropping their pants, the free-beer-button, the moomin laptop and, of course, Duckers in a girly Outracks shirt. And there’s also one moment I won’t forget - but would like to; being hit on by a drunk, Finnish guy (Hi Sauli!) who wouldn’t take no for an answer. I must admit that I missed the wild compo because sleeping on the floor seemed like a good idea at the time. Even though every bone in my body hurt the next morning, I don’t regret it. Maybe I’ll just blame that on free alcohol and the organizers being late with the compos. I did have a great time with awesome people. The party was everything I hoped for and more.

Emma Jane Hogbin gave a presentation on the gender gap in free software at Lugradio Live this weekend. One of the central messages was that a great deal of how to avoid putting women off computing can be distilled down to "Don't be a dick". This ties in well with Mako's restatement of the Ubuntu code of conduct as "Be excellent to each other" (a wonderful phrasing which demonstrates that Bill and Ted's Excellent Adventure is the most philosophically worthwhile film that Keanu Reeves has ever appeared in, and certainly not The fucking Matrix) and led to my 5 minute rant on why I hate the Linux community slightly later in the day, but does leave a certain problem. What standards are used to define whether given behaviour is dickish or not? The comments here show that there's disagreement even within a single sub-community of the larger free software world. Ben suggests that the reaction to perceived inappropriate behaviour is perhaps even more discouraging than the original behaviour, suggesting that bitching about things that offend you is dickish behaviour in and of itself. How do we decide whether someone is being a dick or helping the community? Is lack of tolerance a form of exclusionary behaviour?

This topic is actually one of the issues discussed in the Geek Social Fallacies, but here's a nice easy example. Would tolerating planet posts encouraging the eradication of the Jewish population be inclusive or exclusive? I suspect that most people would agree that it wouldn't be acceptable behaviour, which leads us to the next question. Why? There's two obvious arguments here. The first is that at a community level we have some form of rough moral consensus that advocating genocide is Just Wrong, and so criticising Nazis is obviously the right thing to do. The second argument is more pragmatic than philosophical - alienating millions of people in order to avoid alienating hate groups could be considered to reduce our potential contributor base in an unfortunate way.

I'm a fan of the second argument. The example I gave is emotive and relatively recent history has resulted in people tending to be pretty uniform in considering genocide to be a bad thing, but many other cases aren't clear cut. What I consider to be objectification of women is seen by others as appreciation of natural beauty. What I think of as sexist jokes are perceived by others as acceptable humour. When I advocate intolerance of certain behaviour, people are going to see me not having enough tolerance. So we end up in a situation where people make the "We should all just get along and be tolerant of each other" argument, which sounds fine but is fundamentally flawed in one significant way.

Advocating tolerance excludes the intolerant.

The reason people fail to see this is that it doesn't sound like a flaw. If you ask people whether we need to support intolerance, the immediate answer is probably no. But by advocating exclusion of intolerance, you're excluding all those who have good reasons to be intolerant. You're excluding the women who don't want to feel that the community sees them as a pair of breasts attached to some legs. You're excluding the ethnic groups who would prefer to avoid racist slurs or ethnic stereotyping. Telling anti-fascism protestors that they're being intolerant isn't likely to endear you to them. Advocating tolerance is telling the intolerant that they're wrong and should just deal with whatever it is that makes them unhappy.

So, ironically, tolerating certain types of intolerance is probably required in order to avoid alienating many potential contributors. That means some way of deciding what kinds of behaviour are acceptable and which are unacceptable. In the absence of either pre-existing community consensus or some philosophical breakthrough that allows unambiguous determination of the "rightness" of a given action, I'm going to suggest that we look at it from a pragmatic viewpoint. How many potential contributors do we discourage by criticising a certain type of behaviour? How many do we discourage by tolerating it?

The fallacy of the completely inclusive community is the idea that it includes everyone. The reality is that a certain level of social exclusion is required in order to include a wider range of people. So don't criticise people purely for criticising someone else's behaviour - make an argument for why that behaviour benefits the community. And when you see behaviour that you think discourages others, call people on it. Even if nobody's behaviour changes as a result, you're sending a signal that not everyone in the community agrees. Sometimes all people want is to know that there'll be some people on their side.

But, above all, try not to be a dick.