As a brief introduction to this - I first read through the Android code when interviewing with Google for an opening with the Android kernel team. I didn't get the job, and while I don't think anything that follows here is as a result of residual bitterness you might want to take some of it with a pinch of salt.

Anyway. Android is a Linux kernel with a heavily customised user layer that bears little resemblance to any traditional Linux system. I write in C because using pointer arithmetic lets people know that you're virile so this Java-like thing is of little interest to me and I'm going to ignore it and just look at the kernel, because after all that's what I'm paid to be good at.

The short summary of the rest of this post is that I'm not planning on giving up my iphone yet.

The Android kernel source lives in a git tree here. It can pretty much be logically split into two parts - the port to Qualcomm's MSM7xxx series chips and the special Android customisations. A bunch of the MSM7xxx port code has been merged through the ARM tree and is now upstream, and Brian Swetland seems to have been fairly active in looking after that. Full marks to Google there. This code is handy outside the Android world and benefits anyone wanting to run Linux on similar devices.

The Android-specific code is more... interesting.

As I mentioned, the Android application layer isn't Unix in any real sense. The kernel reflects this. It ranges from pragmatic (if hacky) approaches like encoding security policy and capabilities in group IDs that are hardcoded into the kernel through to implementing an in-kernel IPC mechanism (apparently related to the OpenBinder implementation from Palm, but judging by the copyrights a complete rewrite). To an extent, I'm fine with this. Something like Binder is pretty clearly not going upstream, so the fact that it engages in bizarre design decisions like sticking chunks of its interface in /proc is pretty irrelevant. What's more interesting is the code that should be generalisable.

I work on power management, so I'm always interested in what kind of power management functionality and interfaces people want. Plumbers included a nice discussion with someone from an embedded company I can't remember, culminating in us deciding that the existing cpufreq interface did what they wanted and so no new interfaces needed to be defined. Google was going to be an interesting case of a large company hiring people both from the embedded world and also the existing Linux development community and then producing an embedded device that was intended to compete with the very best existing platforms. I had high hopes that this combination of factors would result in the Linux community as a whole having a better idea what the constraints and requirements for high-quality power management in the embedded world were, rather than us ending up with another pile of vendor code sitting on an FTP site somewhere in Taiwan that implements its power management by passing tokenised dead mice through a wormhole.

To a certain extent, my hopes were fulfilled. We got a git server in California.

Android contains something called the android_power driver (ignore the references to CSMI, which is a piece of OMAP-specific hardware for communicating with the baseband - I'm not sure what they're doing in there). As far as I can tell, this is an interface that handles the device being locked and unlocked, and associated powering down of certain bits of hardware. Except it's shit. Devices register device handlers and a level where they wish to be suspended. There's no direct concept of intra-device dependencies so you end up with stuff like:

android_early_suspend_t early_suspend;
android_early_suspend_t slightly_earlier_suspend;

to deal with the fact that the MSM framebuffer driver depends on the MDDI driver having brought the link bank up and so needs its suspend method called before the MDDI driver but its resume method to be called after, and the only way to handle that is to register two methods - the "slightly earlier" one which has a suspend method but no resume, and the "early" one which has a resume method but no suspend one.

Of course, this also means that all of your device runtime power management policy ends up in the kernel. Userspace indicates what state it wants to go to and the kernel decides what's going to get powered down. This kind of coarse grained approach means that as your hardware setup becomes more complex you hit combinatorial explosion. Expressing all the useful combinations of hardware state simply becomes impractical if all you're exposing is a single variable. What would be more useful is the ability for userland to interact with individual pieces of hardware.

The amusing thing is that in many cases Linux already has this. Take a look at the backlight and LCD class drivers, for instance. They provide a trivial mechanism for userspace to indicate its desires and then modify the device power state. It's true that there are other pieces of hardware that don't currently have interfaces to provide this kind of information. And that's where cooperation with the existing community comes in. We've already successfully fleshed out interfaces for runtime power management for several hardware classes, with the main thing blocking us being a lack of awareness of what the use cases for the remaining classes are. But linux-pm has seen nobody from the Android team, and so we end up with a lump of code solving a problem that shouldn't exist.

When Robert Love gave his presentation on Android at Lugradio Live in SF back in April, he talked about how one of the reasons that Google weren't releasing the source for their userland stack until they shipped phones was to prevent it being seen as throwing unfinished code over the wall and then ignoring the community. It's unfortunate that this is almost exactly what's happened with their kernel. Right now the fact that Android is based on Linux is doing almost nothing to benefit the larger Linux community. What could have been a valuable opportunity for us to gain understanding of an interesting problem has instead ended up as yet another embedded vendor kernel, despite all the assurances I got from various people at Google.

Disappointing.

First, let me make one thing clear. This isn't constructive criticism. This is just criticism. It's directed at software that's so wrong-headed that there's no way to make it significantly better, and everyone involved would be much better spending their time doing something else instead of trying to fix any of what I'm about to describe. It's not worth it. Sit in a park or something instead. Meet new and interesting people. Take up a hobby that doesn't involve writing shell scripts for Linux. You'll be happier. I'll be happier. Everyone wins.

Anyway. I wrote about Automatix some time ago. It died and the world became a better place. More recently it's been resurrected as something called Ultamatix. In summary, don't bother. It's crap. And dangerous. But mostly crap. Again, I'm going to utterly ignore the UI code and just concentrate on what it runs.

• function cleanup {
  echo "Cleaning up..."
  sudo apt-get autoremove --assume-yes --force-yes
  }

  In other words, "Remove a bunch of packages that might have nothing to do with anything Ultamatix has installed, and don't ask the user first. Oh, and assume yes when asked whether to do anything potentially damaging". This gets called 103 times in various bits of Ultamatix.
  
  
• Oh, notice the sudo in there? Ultamatix is running as root already. Despite this, there are 429 separate calls to sudo.
  

• #Test O/S 64 or 32 bit...
  architecture=`uname -m`
  targetarch="x86" #Set 64-bit machines to download 32-bit if no options are set
  if [ "$architecture" != "x86_64" ] && [ "$architecture" != "ia64" ]; then
      architecture="x86"
  else
      architecture="x86_64"
  fi

  It turns out that ia64 is not especially good at running x86_64 binaries. Never mind, eh?
  

• rm -rf $AXHOME/.gstreamer-0.10
  gst-inspect
  sudo gst-inspect
  

  Which translates as "Delete any self-installed plugins, run gst-inspect as root in an attempt to regenerate the plugin database, really run gst-inspect as root in an attempt to regenerate the plugin database". The flaws in this are left as an exercise for the reader.
  

• sudo apt-get --assume-yes --force-yes remove --purge

  Used 111 times. Will remove the packages it installed, but also any other packages the user has installed that happen to depend on them. Without asking.
  

• sudo cp /etc/apt/sources.list /etc/apt/sources.bak
  sudo echo "deb http://ppa.launchpad.net/project-neon/ubuntu hardy main" >> /etc/apt/sources.list
  sudo apt-get update
  if !    sudo apt-get install --assume-yes --force-yes amarok-nightly amarok-nightly-tools amarok-nightly-taglib
  then
          AX_fatal "An apt-based error occurred and installation was unsuccessful";
  fi
  echo "Restoring sources."
  sudo cp /etc/apt/sources.bak /etc/apt/sources.list
  sudo apt-get update

  The good news is that it backs up your sources.list before breaking things. The bad news is that it's still utterly horrifying.
  

• #since we have root we need to discover normal username so we can create the shortcut & set proper permissions
  NU=$(cat /etc/passwd | grep 1000 | cut -d: -f1)
  sudo chown $NU:$NU "legends_linux-0.4.1.43.deb"
  sudo chmod +x legends_linux-0.4.1.43.deb
  sudo dpkg -i legends_linux-0.4.1.43.deb

  List of fail:
  1. Assuming that the user has uid 1000
  2. Chowning a deb to the user for no obvious reason (hint: a user can delete root owned files that are in the user's home directory)
  3. Making a deb executable for no reason whatsoever
  4. Assuming that user information will be in /etc/passwd
  5. Not just, say, passing the user's name to the application IN THE FIRST PLACE

• sudo apt-get --assume-yes --force-yes install f-spot dvgrab kino devede gtkpod-aac ipod gnupod-tools libgpod-common
  libipod-cil libipoddevice0 libipodui-cil libhfsp0 hfsplus hfsutils libipod0

  If only we had some way of saying that libraries used by programs should automatically be installed when a program is. Wouldn't that be great?
  

• echo "Adding mediabuntu repository"
  sudo cp /etc/apt/sources.list /etc/apt/sources.bak
  sudo wget http://www.medibuntu.org/sources.list.d/hardy.list -O /etc/apt/sources.list.d/medibuntu.list
  ...
  echo "Restoring sources."
  sudo cp /etc/apt/sources.bak /etc/apt/sources.list

  Yeah. that'll help.
  
  
• The Swiftweasel install that checks your CPU type and then has some insane number of cut and paste code chunks that differ only by the filename of the tarball it grabs. Rather than, say, using a variable and writing the code once.
  
  
• The cutting and pasting of the same code in order to install swiftdove.
  
  
• Code that installs packages differently depending on whether they happened to be in your home directory to start with or whether it had to download them for you
  

• if !    DEBIAN_FRONTEND=kde sudo apt-get --assume-yes --force-yesinstall virtualbox

  No, I didn't remove any spaces from that.
  

• #create directory incase they installed it elsewhere, no sense in scraping all thier games
  sudo mkdir /usr/local/games/WoP/ 2>/dev/null
  ...
  sudo rm -R /usr/local/games/WoP/ 2>/dev/null

  What, create a directory and then immediately delete it? How is this useful in any way whatsoever?

There's almost certainly more. I got bored. The worrying thing about this is that the Ultamatix author read my criticisms of Automatix and appears to have attempted to fix all of them. The problem with this is that there's clearly a complete lack of understanding of the fundamental problem in several cases. For example, one of my criticisms of Automatix:

sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group

- assumes that the system isn't using some sort of user directory service.

and the Ultamatix response:

Fixed...Got rid of Virtualbox

Except exactly the same problem is present at other points in Ultamatix, as noted above. Taking a bug list and slavishly fixing or deleting all the bugs isn't helpful if you then proceed to add the same bug back in 24 other places. In that respect, it's even worse than Automatix - the author's managed to produce a huge steaming pile of shite despite having been told how to avoid doing so beforehand. He may be no newbie to programming, but if not it's a perfect example of how experience doesn't imply competence.

Don't install this package. Don't let anyone else install this package. If you see anyone advocating the installation of this package, call them a fool. There's absolutely no excuse whatsoever for the existence of this kind of crap.

Minor update:
The above was looking at 1.8.0-4. It turns out that there's a 1.8.0-5 that's not linked off the website. There's no substantive difference, but some of the numbers may be slightly different.

Things that made me happy today:

Roller disco

Things that made me unhappy today:

The human race

• My LCA presentation is now up here. Grab it now to see what the critics are already describing as a roaring rampage of revenge, or possibly that's something else. It's so hard to tell with these modern haircuts.
  
• This cafe makes up for lack of direct support of the Burmese rebels by playing the Katamari soundtrack.
  
• Since I'm hanging around Haight, I'll be here from about 7, heading to food at some point afterwards (probably 8ish) and probably back to the pub after that.
  

MESSAGE ENDS

Slides for my presentation on the Linux suspend to disk implementation are here. The presentation itself should be linked off the programme at some point, but for now here's a representative preview slide:

Partial OLPC unboxing:



Please plug adult into electricity supply before use



Warning: OLPC may make children cry

As much for my reference as anything else. Am I missing anything obvious I ought to be at? April-June seems oddly empty, which I guess gives me an opportunity to actually sort my life out. OLS loses on the basis of the beer in Portland being better than the beer in Ottawa. Posting does not imply a contract. Attendance of Matthew may go up as well as down. Statutory rights are unaffected.

26th January - 3rd February: Melbourne for linux.conf.au
3rd February - 10th February: San Francisco
11th February - 15th February: Cambridge
16th February - 20th February: Boston (dates not finalised)
21st February: Cambridge
22nd February - 25th February: Brussels for FOSDEM
26th February - ?: Cambridge
3rd March: Viva
Early March - somewhere vaguely around October: London
16th March - 19th March: Recife for Bossa (tentative)
7th July - 12th July: Istanbul for GUADEC
21st July - 25th July: Portland for Ubuntu Live and OSCON
10th August - 16th August: Mar del Plata for Debconf
17th September - 19th September: Portland for Plumbers Conference
Somewhere vaguely around October - indefinite: San Francisco

A conversation at lunch today inspired me to work on a quick estimate of the amount of power wasted on animation and Flash-laden MySpace profiles. My conservative estimate is somewhere in the region of 320 kiloWatts, which is much less than I'd have expected. This is probably skewed by me carrying out the test on a laptop - I'd guess that it'll be worse on desktops, but I need to do some more testing to be sure (ideally involving a Watts-up and a serial connection so it can be done without a ridiculous amount of pain). By changing a couple of assumptions it's quite easy to get it up into the megaWatt range, but we're still talking "That's quite a pile of money" rather than "That's a sizable proportion of the US electricity output".

Interestingly, the vast majority of the extra CPU usage (and therefore electricity) seems to be down to Flash. Improving its performance would be a pretty big step in reducing overall power consumption, especially given the number of websites running flash adverts. Want to save the world? Turning off Flash might be a surprisingly good step.

I've written up my methodology and results here - I'd be interested in any feedback.

I've spent the evening poking at the panel display that seemed to ship on some of the Philips Freevent desktops (some sort of abortive rebadging exercise). It's a TriGem part with a USB vendor ID of 0x0aa8 and product ID of 0xa001. It has four 7-segment numbers, a volume display and miscellaneous legend indicators. There's also some bizarre spinning circle thing that seems to be under programmatic control, but I haven't figured that bit out yet. It takes bulk writes of 16 bytes to endpoint 1, and the following format seems to be enough to drive the informational display.

The lack of any real free-form text support means it doesn't really fit into the LCDProc model, so I'm not really sure what to do with this. I'm sure I'll come up with something at some point. All the Windows driver does is cycle between showing hard drive space, memory and cpu frequency, though the hardware's obviously designed for showing the time as well (oddly, there's a separate clock at the top of it that works without a driver - I really don't think I want to know how that works). If anyone's got a similar device with a larger array of functionality, I'd be interested to hear if the remaining bytes do anything.

Bytes 0-7	Don't seem to do anything - perhaps on systems with more lights?
Byte 8	Bits 0-4: Volume lights 3-7
Byte 9	Bit 0: GHz light Bit 1: CPU light Bit 2: HDD light Bit 3: Mem light Bit 4: Mute light Bit 5: "Vol" light Bit 6-7: Volume lights 1-2
Bytes 10-13	Bit 0: Lower horizontal bar Bit 1: Left lower vertical bar Bit 2: Right lower vertical bar Bit 3: Middle horizontal bar Bit 4: Left upper vertical bar Bit 5: Right upper vertical bar Bit 6: Upper horizontal bar Bit 7: GB light (byte 10), colon light (byte 11), decimal point (byte 12), MB light (byte 13)
Byte 14	Doesn't seem to do anything
Byte 15	Must be 0x01

Neil:

The vast majority of your criticisms are unfounded. Nvidia contribute code to the open driver for their network hardware (see the commits) - you don't mention what version of Debian you're actually running, but if it's etch then it's hardly surprising that new hardware isn't supported terribly well. Try a more recent kernel. It's not clear what you expect HP to have done here - used older hardware to make sure Debian worked?

"the graphics don't work with standard Debian kernels and the standard Debian 'nv' driver" - this seems fairer. No 7000-series IDs have been added to the nv driver for some time, and 7150 is clearly missing. Naughty nvidia. No biscuit. But, again, hard to see what you wanted HP to do here - you bought a machine with an nvidia graphics chipset, and you're surprised that the open support is poor?

"I'll still need some firmware for the bcm43xx wireless card - and it is that firmware that made my previously ultra-reliable iBook into a flaky, power hungry psycho-beast." - no. Given that the firmware runs fine on non-Linux platforms, it's pretty clear that it's the (entirely open) driver that's at fault. Which is hardly surprising, given that it's had to be reverse engineered due to Broadcom providing no specifications whatsoever, but blaming vendors for using proprietary firmware is a bit much. Do you have the source for your CPU microcode? Your BIOS? The firmware that's in flash on your other wireless cards? Your hard drive? As a community, we haven't been sending a strong message to vendors that we want open firmware. Acting shocked that they then don't provide it is alarmingly unreasonable.

"GNOME doesn't yet work because of the proprietary crap" - the only proprietary crap you need is the graphics driver, and it's unlikely (though possible) that it's breaking GNOME. Perhaps you have another bug?

"I didn't think companies were still producing crap of this pitiful standard - HP: you stink" - this might at some level be linked to the fact that you paid 500 pounds, and as a result you got something made from cheap parts. That's not HP's fault. Their consumer hardware isn't designed to work with Linux. It's hardware that's designed to be as cheap and shiny as possible in order to appeal to home users who are then going to use it to download films and porn and animated mouse cursors in order to ensure that all their private data get sent to Russia. If it's supported by Linux then that's a happy coincidence. If not, then who cares?

Never mind. It's likely that your laptop is one of the machines that has some debugging hardware on io port 0x80, and as a result Linux's use of that as a delay port (despite the hardware's acpi tables claiming it as a motherboard resource) is likely to cause the machine to deadlock randomly if you do things like try to read the hardware clock or nvram. That's likely to cause you more problems than HP's use of Nvidia graphics.

Friday's predominant weather is forecast to be heavy rain
Saturday's predominant weather is forecast to be sunny
Sunday's predominant weather is forecast to be light rain
Monday's predominant weather is forecast to be heavy showers
Tuesday's predominant weather is forecast to be heavy rain

Oh well. In a fortnight I'll be heading to Linux.conf.au to discuss why suspend to disk doesn't work, can't be made to work in its current form and that everyone who thinks it currently does is under some form of mass delusion. Friday, 11:30. Be there or be listening to one of the other fine presentations that day. If it rains there, I may be upset.

I submitted my PhD thesis today, which means that (other than a viva some time next year and whatever corrections that may bring) I'm done with the past four years of work. Consequently, I'm looking for a job - long term I'm looking at moving to the US, with a marked preference for San Francisco (with Boston and Portland as backup options, but fairly significant preference for being in the city rather than some outlying village), but I'm also up for short term stuff.

Even shorter term, I expect that I'll be spending the evening at home and working through the excessively large number of bottles of wine that have piled up. Do feel free to drop in.

Further to Iain's discussion of clocks on the desktop, I present to you:

Clocks.



(Note: Not actually KDE)

Seth Oster, executive VP and chief communications officer of the MPAA, told Ars that the notice came over the Thanksgiving holiday when their offices were closed. "As soon as we came back and discovered that there had been someone who had raised some concerns, we removed the software," Oster said. "Anytime anyone raises any reasonable concern we look at it because we take copyright very seriously at the MPAA." He also denied Garret's assertions that the ISP was involved in the takedown, saying that the MPAA chose to take the toolkit offline.

(from Ars)

The bit about Thanksgiving is basically accurate - I contacted them at 15:52 Pacific time (23:52 GMT) on Friday the 23rd of November, saying that I'd take further action if things hadn't been fixed by close of business on the following Friday (the 30th). While I'm happy to accept that this might have cost them Friday and Monday (if the MPAA are the sort to offer a 5 day long weekend), that's still 4 business days of response time. I telephoned them on Friday morning (around 10AM Pacific time) and was told I'd get a call back shortly. By Saturday it seemed likely that this wasn't going to happen, so emailed the ISP. At 19:13 Pacific time on Saturday, I received an email from the ISP informing me that they were going to contact Paul Egge at the MPAA. There was an ISO available from the MPAA site until at least 09:22 Pacific time (17:22 GMT) on Monday the 3rd of December, which had been removed by 23:00 or so GMT (the next time I checked).

So, to summarise. The infringing material was still available the best part of 9 days after the original notification was sent. At least 4 of those 9 were business days. The material was not removed until after I had contacted the ISP and they had informed me they were going to contact the MPAA. Further interpretation is left to the reader.

Before takedown request:


After takedown request:


MPAA don't fuck with my shit.

(And yes, I did attempt to contact them by email and phone before resorting to the more obnoxious behaviour of contacting the ISP. No reply to my email, and the series of friendly receptionists I got bounced between had no idea who would be responsible but promised me someone would call back. No joy there, either.)

(Context)

Fathi: While Splashy still requires a framebuffer, it's going to break suspend/resume on various systems. In the bright shiny future of kernel modesetting this ought to stop being an issue, but that's going to take several years. Having the kernel try to write to video memory before you've had an opportunity to do anything to reinitialise it is just asking for trouble, and the kernel can't usefully do that itself right now.

As often seems to be the case, my internet at home vanished shortly after I arrived in Portland. Remote debugging (hurrah for flatmates) revealed that the modem would come up, start a PPP session and then OOM around 30-40 seconds later. This was kind of odd, since running ps in a tight loop showed that it wasn't the PPP daemon that was taking up all the extra RAM. Once we'd pretty much ruled out userland, that left the kernel. Limiting the value in /proc/sys/net/ipv4/ip_conntrack_entries brought stability back, but left us wondering why it had suddenly broken (and, of course, made it difficult to actually route anything...). /proc/net/ip_conntrack showed a bunch of ssh connections. Lots of ssh connections. All coming from one machine inside the network, but targeted at a large number of machines with roughly consecutive IP addresses.

At this point, I remembered a party a month or so ago. One where I'd created an account on the TV machine to let people upload stuff to play. An account I'd cunningly called "media", giving it the highly secure password of "media". I blame vodka from Ikea.

You can guess where this is going.

Unplugging the TV machine resulted in everything rapidly returning to its normal state. I'm sure there's some sort of important lesson here, but I'm sure I don't know what.

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)&
fi

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.

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
    description
    
  • 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?"`
  sudo gedit $NAUTILUS_SCRIPT_SELECTED_URIS

  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;
     then
       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
  installed.
  
• 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
  boot.
  

• sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group

  - assumes that the system isn't using some sort of user directory
  service.
  
• installs truecrypt suid root - not ideal, given its less than
  stellar security record
  
• Unmounts filesystems without checking to ensure that the unmount
  succeeded.
  
• 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.

Conclusion:

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.