Older blog entries for mjg59 (starting at number 82)

Linux-hero wrote about how Ubuntu kills your hard drive. The situation is somewhat less clear than you might think from the article, but the basic takeaway message is that Ubuntu doesn't touch your hard drive power management settings by default. In almost all cases, it's more likely to be your BIOS or the firmware on your hard drive.

The script that's executed when you plug or unplug your laptop is /etc/acpi/power.sh. The relevant sections are:

function laptop_mode_enable {
    $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
    $HDPARM -B 1 /dev/$drive 2>/dev/null
That is, when the laptop_mode_enable function is called, we set the drive power parameters. Now, by default laptop_mode_enable isn't called:
if [ x$ENABLE_LAPTOP_MODE = xtrue ]; then
    (sleep 5 && laptop_mode_enable)&
because ENABLE_LAPTOP_MODE is false in the default install (check /etc/default/acpi-support). This means that, by default, we do not alter the hard drive power settings. In other words, the APM settings that your drive is using in Ubuntu are the ones that your BIOS programmed into it when the computer started. This is supported by the fact that people see this issue after resuming from suspend. We don't touch the hard drive settings at that point, so the only way it can occur is if your BIOS or drive default to this behaviour.

If you enable laptop mode, then we will enable aggressive power management on the drive and that may lead to some reduction in hard drive lifespan. That's a fairly inevitable consequence of laptop mode, since it only makes sense if the laptop enages in aggressive power management. But, as I said, that's not the default behaviour of Ubuntu.

There's certainly an argument that we should work around BIOSes, but in general our assumption has been that your hardware manufacturer has a better idea what your computer is capable of than we do. If a laptop manufacturer configures your drive to save power at the cost of life expectancy, then that's probably something you should ask your laptop manufacturer about.

Syndicated 2007-10-25 02:41:14 from Matthew Garrett

Anyway, back to pure Linux stuff. A while ago, the Ubuntu Technical Board were asked to take a look at Automatix. I've finally got around to doing so, and here are my initial conclusions. I'd appreciate any factual corrections, and note that at this point this is my individual opinion rather than any sort of official statement.

Automatix is a combination system configuration/package installation
tool, aimed at making it easy for users to install features like
graphics drivers, media codecs and software not distributed as part of
the Ubuntu distribution. It is provided as a .deb file containing a
python GUI frontend that calls out to a shell backend. The frontend
parses an XML file which contains module descriptions and function
names for installing and uninstalling modules, with these functions
being part of the shell backend. An install module will typically
check whether another package manager is running, and if not either
install a set of debs or download and manually install a
tarball. Uninstall modules generally remove the same software or clean
up the manually installed files.

The following is a list of identified issues with the current version
of Automatix - it is the result of a few hours of investigation, so
may not be complete.

  • Automatix is, in itself, a poor quality package which fails to
    conform to Debian or Ubuntu policy.

    • It is inappropriately flagged as belonging to base
    • Depends on essential packages
    • Has a short description of more than 80 characters and no long
    • Provides no email address in the maintainer field
    • Contains no copyright information in the standard locations
    • Ships a TODO file as a control file
    • Provides no man pages
    • Ships files in /usr/etc
    • Contains many files inappropriately flagged as executable
    • Changelog is in /usr/etc/automatix2/ax_data ?

    These issues are primarily cosmetic and in themselves are unlikely to
    cause any harm to the system.
  • In debug mode, automatix will write files to your home directory as
    root. Again, more of an irritation than anything dangerous.
  • Provides platform-specific data in /usr/share. Potentially an issue
    if /usr/share is shared between multiple architectures, but since
    Automatix is x86/amd64 only probably not a real problem.
  • #!/bin/bash
    #created by arnieboy 
    foo=`gksudo -u root -k -m "enter your password for gedit root access" /bin/echo "Do you have root access?"`
    appears to be an attempt to ensure that the user has sudo rights. This
    will break if timestamp_timeout is set to 0 in sudoers - gedit should
    be run directly from gksudo. This is repeated in more than one
    place. The assumption that sudo will not need to prompt appears
    prevalent throughout the code.
  • catagory_data.xml - nitpick, but should be category
  • "Please NOTE that downloading and installing w32codecs, libdvdcss2
    and other non-free codecs without paying a fee to the concerned
    authorities constitutes a CRIME in the United States of America"

    Somewhat dubious legal advice - the issue has nothing to do with fees,
    and isn't just limited to the USA.
  • Automatix checks that other package managers aren't running at
    startup (by grepping for a static list of application names in the
    proces list), but doesn't enforce this by carrying out any locking of
    its own. This leaves Automatix open to race conditions.
  • if ps -U root -u root u | grep "dpkg" | grep -v grep;
         killall -9 dpkg
    May well leave the system in an inconsistent and unbootable state, and
    is carried out without warning. This is entirely unacceptable and will
    leave a stale lockfile in any case.
  • function reloadnautilus {
           killall -9 nautilus
    Not actually used anywhere, but could potentially lose user
    information without warning.
  • Most install functions contain a sleep statement for no obvious
    reason. They then call dpkg_check, which sleeps again. It's not at all
    clear what this is meant to be doing.
  • Passes --assume-yes to apt-get, which will (as a result) happily
    remove packages without giving the user an opportunity to
    intervene. This is especially bad when removing Automatix modules -
    any package that depends on one of the packages being removed will
    also be uninstalled, even if the package was originally installed via
    something other than Automatix!
  • Has no internal dependency management. Unable to keep track of why
    packages were installed, so prevents the removal of the multimedia
    module because that would remove sections of other modules without
    explicitly removing that module. Installing swiftfoxplugins will pull
    in several plugin packages, but removing swiftfoxplugins will not
    remove them even if nothing else depends on them. Also means that
    package installation and uninstallation have to be manually kept in
    sync - uninstall will not always remove all packages that were
  • Has no concept of file tracking, so will just remove entire
    directories. Makes no attempt to ensure that a user-installed version
    is not already installed in the same location, so effectively assumes
    that the /opt namespace belongs to it.
  • Will remove Ubuntu repository packages in favour of tarballs with
    no warning.
  • Setting ctrl-alt-del to open gnome system monitor will destroy any
    existing user configuration for run_command_9
  • Installing streamtuner will create a world writable directory in
    /opt/ripped with no sticky bit, allowing users to interfere with other
    users' files.
  • mplayerplugin moves totem plugin files to a backup, but does
    nothing to prevent package upgrades of totem replacing them.
  • Only updates the java link after installing new java, not the rest
    of the java alternatives
  • amsninstall installs tls libs that are never removed, copying over
    the ones in the tcltls package. This means that the md5sums in the
    tcltls package will no longer validate.
  • sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1
    is really not
    such a good idea.
  • ln -s /tmp/.esd-1000 /tmp/.esd
    looks like it'll only ever work for
    the first user on the system, and there's nothing to recreate it on
  • sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group
    - assumes that the system isn't using some sort of user directory
  • installs truecrypt suid root - not ideal, given its less than
    stellar security record
  • Unmounts filesystems without checking to ensure that the unmount
  • Deletes lines from fstab and replaces them with device nodes
    rather than uuids.
  • Includes acroread 7.0.9, despite the new Acrobat license appearing
    to grant no right to redistribute.


Automatix exists to satisfy a genuine need, and further work should be
carried out to determine whether these user requirements can be
satisfied within the distribution as a whole. However, in its current
form Automatix is actively dangerous to systems - ranging from damage
to small items of user configuration, through removing user-installed
packages without adequate prompting or warning and up to the (small
but existing) potential to leave a system in an unbootable state.

The current design of Automatix precludes any reasonable way to fix
some of these problems. It is attempting to fulfil the role of a
high-level package manager without actually handling any sort of
dependency resolution itself.

A more reasonable method of integrating Automatix's functionality into
Ubuntu would be for the Automatix team to provide deb files to act as
installers for the software currently provided. These could then be
installed through the existing package manager interfaces. This would
solve many of the above problems while still providing the same level
of functionality.

In its current form Automatix is unsupportable, and a mechanism for
flagging bugs from machines with Automatix installed may provide a
valuable aid for determining whether issues are due to supported
distribution packages or third party software installers.

Syndicated 2007-08-04 03:09:39 from Matthew Garrett

It's kind of odd to see that pointing out that the GPL is incompatible with the CDDL is now enough to get one described as a "GPLv2 is the one true righteous license" person.

I know that a lot of people would love to see DTrace in Linux, in much the same way that I suspect a lot of people would love to see Solaris support as much hardware as Linux does. The fact that we can't cut and paste code from one kernel to the other is a shame, but given that contributing to Linux has never required any sort of copyright assignment it's basically impossible to identify everyone who contributed to it and ask them for permission to relicense. That situation has been pretty clear since long before OpenSolaris was released under the CDDL, so it really shouldn't come as a surprise to anyone in Sun. That doesn't mean that I think the GPL is better than the CDDL or that Linux is the one true OS. Saying that DTrace is under a license that means it can't be incorporated into Linux is a statement of fact, not any sort of judgement.

Syndicated 2007-08-04 02:57:24 from Matthew Garrett

Julian: You don't need autosuspend support to prevent UHCI from generating interrupts - you just need your hardware to be idle. The reason you're getting interrupts is that a USB device wants to send information. There's no way to get this information to the kernel without generating interrupts or polling - and polling is even worse, since it guarantees you'll be producing wakeups even when there's nothing to send.

If you're on a Macbook, the largest number of USB interrupts is probably from the Bluetooth controller. Either hciconfig hc0 down, or load hci_usb with the isoc=0 option. The other Macbook issue is that the trackpad will carry on sending updates even though there's no input - I wrote a patch to fix this, which ought to be in git now. These have nothing to do with the UHCI spec.

Why are C states so important? They allow the CPU to turn parts of itself off. However well designed your CPU, turning parts of the processor off is going to save power. Of course, this can only be done when the system is idle (code doesn't run so well on disabled execution units). It's also inevitable that there's going to be some latency in reenabling these portions of hardware, so you only want to enter them if you know that the processor is going to be idle for a significant (like 20ms or more) amount of time.

In C4 state, a modern Intel CPU will draw somewhere in the region of a Watt. There's absolutely no reason why a modern desktop shouldn't be spending most of its time idle, so we should aim to be hitting C4 as much as possible. It's low hanging fruit, and Powertop lets us identify most of the things preventing us from getting there. Processors are always going to be able to save power if they're idle. It's an entirely worthwhile project.

For what it's worth, the ULV Core 2s will max out at about 10 Watts, which isn't bad - sadly the Macbook Pro contains a T7600, which goes up to 34W. The last-generation Powerbook G4s with 7447As drew in the region of 20 Watts - Apple seems to think its customers prefer performance to low power consumption, and I don't think you can blame Intel for that (especially since you can get an LV 1.6GHz Core 2 Duo with a TDP of 17W, giving you rather more performance than the G4 Powerbook while consuming less power)

Syndicated 2007-08-03 17:29:33 from Matthew Garrett

The Canonical offices are ridiculously swish, with the Dyson hand dryers providing literally seconds of entertainment (and providing something of an aircraft taking off atmosphere).

In other news, I'm now a cube. Since I'm forced to admit that I'm (at best) in my mid-to-late twenties, there will be boozing at my place tomorrow (Friday) from 9ish. It's possible that I won't get there until 10 or so, but I'm sure you'll manage to have fun anyway.

Syndicated 2007-07-12 20:19:29 from Matthew Garrett

The day I stop crying myself to sleep over the free software community is likely to be fairly closely associated with the day when we think OMG-a-girling is even more embarrassing than the fact that there are so few women involved to begin with that someone might think they needed to point it out.

Syndicated 2007-06-13 21:46:31 from Matthew Garrett

Modern Intel SATA chipsets (anything from the ICH6m onwards) can be driven in two modes - one that looks awfully like an old-fashioned PATA controller, and one that conforms to the AHCI specification. Windows deals badly with AHCI, so BIOS authors tend to program them to PIIX mode. Some BIOSes have an option to let you choose which is used, but most don't so you end up stuck with PIIX mode.

This is a bit of a shame, since AHCI supports functionality that isn't really present in PIIX mode. For laptop users, one of the more interesting features is AHCI's link-level power saving. At the cost of some performance, it's possible to save 0.5W or so. There are patches beginning to appear for this, but it's no help to people stuck with PIIX support. Over the past couple of days I've been looking into what's necessary to reprogram the chipset into AHCI mode. The biggest issue is finding some MMIO space for the AHCI registers. Most BIOS authors don't program the AHCI base address register, which means trying to find some spare address space to map it. I've hacked support for this into the PCI layer and added a quirk that attempts to reprogram chips into AHCI mode. It's not really ready for proper use yet, but it'd be good to get some amount of testing to see if there are obvious issues. The code is here and ought to apply to current git. Obviously, you'll need ahci support in your kernel.

Syndicated 2007-06-10 02:11:28 from Matthew Garrett

It seems that I've maligned IBM entirely unfairly. They just forwarded me photographs of how my Thinkpad arrived there.

Perhaps using shipping companies named after explosives isn't such a hot idea.

Syndicated 2007-06-06 16:08:13 from Matthew Garrett

Further stories of customer service despair

Orange have a fairly decent offer for "unlimited" (1GB a month or so) 3G access. I'm a pay monthly customer on an old tariff that's no longer offered, but there's no mention of any sort of limitations there and they seemed happy to add 3G access to my account. Cue two days of repeated phone calls trying to find out why my entirely 3G phone was refusing to connect to their 3G network. After going through being told it was my phone settings, poor reception, something that I could get fixed at my local Orange store or that it was because they'd entered the wrong start date(!), I finally got through to someone who was actually genuinely friendly and helpful and told that I needed a 3G sim[1]. Oh, and that they wouldn't provide me with one because of the tariff I'm on.

Fucking useless telco.

[1] Something that's clearly documented on their website. Oh, wait.

Syndicated 2007-06-01 17:58:02 from Matthew Garrett

Dear IBM,

I appreciate that laptops are awkward to disassemble, something that's even more true of ultraportables. As a result I don't feel especially surprised that you managed to make a hole in my laptop while working on the screen, and I appreciate your offer to reexamine the hardware. What I appreciate less is your requirement that I pay for it to be sent to Scotland for another fortnight so that you can correct your mistake, you cretins.

No love,


Syndicated 2007-06-01 13:40:35 from Matthew Garrett

73 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!