On Wednesday I saw a group of people wearing nothing but underwear walking through the Melbourne CBD. They were promoting Pants To Poverty which is a UK based underwear company that sells Organic Fair-Trade underpants [1]. The corporate web site seems equally divided between the purposes of selling underpants and lobbying for a variety of social issues including fair-trade, better working conditions in factories, and the abolition of pesticides that kill farmers. The web site itself is worth a look in terms of it s design, for what it does it works really well. When viewing a picture of a model wearing underpants you can scroll your mouse over the picture to see an enlarged view of a particular area of interest. This works really well on a Netbook display (everyone should carry a Netbook with 3G net access when shopping), I would like to see car companies use the same technique for displaying pictures of cars on small screen devices. It s unfortunate that it doesn t just show the full sized images when you use a large display, it would all fit on a 1680*1050 display. The underwear in the UK costs between 10 pounds ($16.40AU) and 15 pounds ($24.60AU) a pair for adults and 18 pounds ($29.52AU) a pair for a pack of three for children. The Little Green Bag Co [2] sells the adult underpants in Australia for $22AU per pair. These appear to be the cheaper items from the range, so it seems that it would be cheaper to order from the UK if you were buying a few pairs. Also if the items you wanted happened to be the more expensive items from the range then you would have to order from the UK. A quick check of the Myer web site shows that even $22 per pair isn t particularly expensive for women s underwear, but it is really expensive for men s underwear. The Australian web site for Pants to Poverty lists a bunch of resellers, but a quick scan of the list didn t turn up anyone cheaper than the Little Green Bag Co. According to the sizing information on the home page of the UK site the largest underpants that they sell are size 14 (in the Australian size range for women which is apparently 78-83cm). According to a variety of news reports the average size of an Australian women is either size 14 or 14-16. Apparently women s clothing is often not made to standard sizes due to the practice of vanity sizing, so it s difficult to determine how these things compare. But it does seem that a significant portion of the women in Australia won t be able to buy products from Pants To Poverty in their size. I don t think that many men will buy from them, $22 is really expensive. So while I think it s great to have a bunch of men and women running around the CBD wearing only underwear I don t think that the future of their Australian business is particularly good. The difference in price between Pants To Poverty products and other underwear would allow you to buy a significant quantity of Organic Fair Trade chocolate or other food.

• [1] http://www.pantstopoverty.com/
• [2] http://www.littlegreenbagco.com.au/

Actually, on second thought, this isn t a farewell. There is no goodwill on either side of this bitter parting. Facebook doesn t care about my privacy or consent, and I don t care about their shady and anti-competitive profiteering. It s over between us. So, here s what I did:

1. made a list of all of my connections on Facebook (via copy and paste from a browser window)
2. confirmed that I have alternate contact information for all of them, either by email or other social media
3. deleted all of my photo albums
4. deleted all of the information from all sections of my profile
5. removed all applications
6. deleted everything under My Links
7. deleted all of my notes (this was tedious, as my blog was syndicated there)
8. followed the WikiHow instructions to delete my account

Obviously, I can t really control whether they hold onto my data in spite of this. This should provide a clear statement of intent on my part, though, if it comes up in future shenanigans.

In the recent Debian Edu versions, the sitesummary system is used to keep track of the machines in the school network. Each machine will automatically report its status to the central server after boot and once per night. The network setup is also reported, and using this information it is possible to get the MAC address of all network interfaces in the machines. This is useful to update the DHCP configuration. To give some idea how to use sitesummary, here is a one-liner to ist all MAC addresses of all machines reporting to sitesummary. Run this on the collector host:

perl -MSiteSummary -e 'for_all_hosts(sub   print join(" ", get_macaddresses(shift)), "\n";  );'

This will list all MAC addresses assosiated with all machine, one line per machine and with space between the MAC addresses. To allow system administrators easier job at adding static DHCP addresses for hosts, it would be possible to extend this to fetch machine information from sitesummary and update the DHCP and DNS tables in LDAP using this information. Such tool is unfortunately not written yet.

A scandal has been brewing in Latvia over the last half year and yesterday the activity spiked shocking the media and some IT people in the country. I ll go back and explain what happened first, what is happening now and why this could have a heavy impact on IT and journalists in Latvia. At the end of last year, there were rumours that the IT system of Latvia s Internal Revenue System was hacked and millions of documents had been downloaded by multiple organizations. Shortly thereafter more details on the glaring security hole became public (after it was closed). There is a full electronic interface to give all reports to the IRS electronically (at http://eds.vid.gov.lv) and as part of that system you could also view and export monthly report summaries about your organization into XML and PDF files. After the system checked that you are authorized to access the report, you were redirected to the URL to actually download the report by report ID (as a single param in a GET request). Unfortunately, report IDs were predicable and the script that gave the reports for download did not check if you were authorized to get that report. It did not even check if were logged into the system. There were suspicions that the authorization was disabled on purpose to allow to leak data on purpose, but apparently it was an error of forgetting to disable debug code in production environment. The error was discovered only because the firewall administrator noticed an unexplained stable increase of traffic, especially during night hours when typically the traffic fully stopped. Apparently a single hacker (who later identified himself as Neo to the press) discovered the flaw and wrote a script to just try all possible report ids and get as much data out as possible. This had been going on for months, before someone noticed. After the flaw was discovered and a bit of time passed, Neo made his first move he published the list of top salaries in a governmental company, that clearly showed that the top leadership of this company failed to cut their salary by 40%, like everyone elses during harsh budget cuts of 2009. He stripped the names and ids of the specific employees, but named the company which made it pretty easy to figure out who was who. The society was outraged that the top managers in a government owned company failed to comply with the strict pay cut that everyone else in government had to endure. But after a few weeks the outrage subsided and no action followed from the government or law enforcement. Neo continued to release documents detailing salaries of top managers in different Latvian government companies. And each time after short outrage, nothing happened. Neo gave an interview where he said that he was disappointed in the passivity of the Latvian people in face of such blatant injustices. After a few month Neo went silent, promising to return before parliamentary elections this fall. However, this week a new development shocked everyone in the middle of the night two police SWAT teams went into action: one detained Ilm rs Poik ns, a researcher in artificial intelligence at the University of Latvia s Computer Science department and another raided the home of a Latvian TV journalist Ilze Nagle who interviewed Neo. Poik ns confessed of being Neo the next day and was released (with travel restrictions, pending trial) today. Politicians reacted immediately opposition demanded the resignation of the Interior Minister over such blatant disregard of freedom of press and another politician (who is also a famous lawyer) Aleksejs Loskutovs volunteered to defend Neo pro-bono (on Twitter, no less). Almost all Latvian online media have the arrest of Neo and the raid on the home of a journalist as main stories of the day. As a legal titbit, we also know that Neo is being charged with breaking statutes 145 and and 244p2 of the criminal law. Statute 145 is hard to find applicable in this situation as talks about actions done by people authorized (..) to access [private] information . Statute 244p2 will also be hard to pin down as it mentions influencing system resources of (an IT system) and if such action caused severe harm . It looks like the first part talks about at least a DoS attack (which did not happen in this case) and also there was no measurable harm from these leaks. Also Neo was careful to strip all personally identifying information (such as names, social security numbers and addresses of the employees in question), so it will be hard to pin him on that. Also no actual breaking or other modification of an IT system occurred. And no specialized software was used beyond a trivial script such as :

for i in range(0,7000000):
    wget('https://eds.vid.gov.lv/getRep.aspx?id='+str(i))

A lot of commentators on the Internet likened the situation to walking trough an unlocked door and stealing something. I think that analogy is very incorrect there was no door, and nothing went missing after the action. I came up with a different analogy there was this corridor with a lot of doors in IRS, locked steel doors. You were instructed to go to a room with a specified number and given a key to that room to unlock it and see your secret info. However, that corridor opened out to the street on one end, oh and also the walls of the rooms with all the secrets were transparent. So Neo walked into the corridor, looked at some of the secrets, wrote them down (to remember them better) and then went out and discussed the worst examples abuses of power he saw. In the end IRS had to learn their lesson if you have to put naked photos of yourself on the Internet (or something equally embarrassing), then make damn sure you password protect that, but if you don t then don t cry that someone hacked you and stole you pictures. What other people think:
http://freespeechlatvia.blogspot.com/2010/05/neo-released-under-restrictions.html We ll see how the story develops soon.

The last few days a new boot system called systemd has been introduced to the free software world. I have not yet had time to play around with it, but it seem to be a very interesting alternative to upstart, and might prove to be a good alternative for Debian when we are able to switch to an event based boot system. Tollef is in the process of getting systemd into Debian, and I look forward to seeing how well it work. I like the fact that systemd handles init.d scripts with dependency information natively, allowing them to run in parallel where upstart at the moment do not. Unfortunately do systemd have the same problem as upstart regarding platform support. It only work on recent Linux kernels, and also need some new kernel features enabled to function properly. This means kFreeBSD and Hurd ports of Debian will need a port or a different boot system. Not sure how that will be handled if systemd proves to be the way forward. In the mean time, based on the input on debian-devel@ regarding parallel booting in Debian, I have decided to enable full parallel booting as the default in Debian as soon as possible (probably this weekend or early next week), to see if there are any remaining serious bugs in the init.d dependencies. A new version of the sysvinit package implementing this change is already in experimental. If all go well, Squeeze will be released with parallel booting enabled by default.

For various reasons, I chose to leave Ubuntu 10.04 LTS using OpenSSH 5.3p1. The new features in 5.4p1 such as certificate authentication, the new smartcard handling, netcat mode, and tab-completion in sftp are great, but unfortunately it was available just a little bit too late for me to be able to land it for 10.04 LTS. I realise that many Lucid users want to make use of these features for one reason or another, though, so as a compromise here's a PPA containing OpenSSH 5.5p1 for Lucid. I intend to keep this up to date for as long as I reasonably can, and I'm happy to accept bug reports on it in the usual place.

I volunteered to manage the Debian booth on the Linuxtag 2010 in Berlin. I asked for booth members a few weeks ago on debian-events-eu and debian-user-german - but unfortunately there aren't that many helpers listed at the organisation wiki. So if you attend the Linuxtag or the Debian Miniconf please lend Debian a little bit of your time and apply for the debian booth. You don't have to be a Debian Developer for that, an interested user is enough. I'll plan the booth in a way that nobody will be alone at the booth ;).

• Chromium browser is now available from experimental, the package name is chromium-browser. Install chromium-browser-l10n if you want it localized.
• KDE 4.4.3 and Qt 4.6.2 are now available in unstable. More information.
• The Debian GNOME team is working hard on uploading GNOME 2.30 to unstable. It s almost there, and the delay has mostly been due to the need to coordinate the library transitions. Check out its status here!
• Debconf, the annual Debian developers meeting, is seeking for sponsors and donors to help covering the costs implied by this event. If you are interested in becoming a sponsor please contact us at sponsors (at) debconf.org, or if you want to make a donation please read here.
• Debian gets ported to Ben NanoNote, a copyleft hardware micro notebook developed by Hong Kong startup company Sharism at Work. More info in their announcement and in the how to.

Facebook recently launched the "Like" function, which basically can be embedded into arbitrary web sites. Naively, it does two things:

1. Provide a "Like" button for sharing the web site
2. Show you how many other users like the web site

Sounds good, doesn't it?But now reconsider: even when you don't use the "Like" function, facebook is in fact notified of which web sites you visit!.Encouraging you to "share" content with friends is the hanger for this function. This is what makes web masters install it on their sites: they expect to get some extra traffic from your friends, so they just add it.But whether you like it or not, it basically allows Facebook to track your complete web viewing habits. And it's the target web site that opts in, not the user! Combined with all the personal information Facebook already has on you, this is a major privacy concern. Combining this information might even be illegal in some countries (but probably not in the US where Facebook lives, privacy unfortunately has a low role here).The best workaround currently is to blacklist Facebooks "Like" function using some kind of AdBlock, for example using this element filter:

IFRAME[src^="http://www.facebook.com/plugins/like.php"]

But in general, we should try to make this kind of data aggregation illegal without explicit consent and force Facebook to make this an opt-in feature. Political work needed here ...P.S.: Make sure to check if your AdBlock actually blocks and not just hides. As far as I can tell, WebKit Adblock, including Chromes, only hide ads. Firefoxs AdblockPlus seems to be more powerful.P.P.S.: yes I've read the claim that Facebook doesn't track. No wait, all they basically said was that they are not going to announce at F8 they will be selling web surfing behaviour based ads to their customers. They actually did NOT state (or guarantee) they will NOT use data mining on this data. Just that you probably will not be able to buy eyeballs based on rules such as "has visited/liked disney.com" ...P.P.P.S.: I've been told that facebook.com/widgets/like.php also needs to be blocked, since some sites use this URI scheme. And of course, Privoxy and similar privacy-increasing proxies are a useful addition, too.

I've previously written about some of the implementation details of runtime PCI power management. One of the key aspects for PCI devices is that the PME line on the device be able to generate a wakeup event. Unfortunately, it turns out that since Windows makes no use of this functionality at present, some vendors have started failing to wire this up. This is problematic because the device itself still announces PME support and will even raise a PME signal when it gets woken up - but it's pretty much screaming as hard as it can and nobody's listening because somebody's replaced the air with cheese.

Bother, etc.

The obvious question is what to do next. We could poll all the PCI devices every second or so to see if there's a PME status register that's been set. This would be reasonably cheap (we're going to wake up at least once a second on x86 anyway, so it makes no real difference to power consumption) but would introduce obvious latency in the wakeup path. This would be fine for certain types of situation (you're probably not going to be too sad if your SD reader takes a second longer to notice a card insertion) but not others (if an sdio wireless card generates a wakeup interrupt then we really ought to do something about it in a more sensible timeframe). A second is to force users to pass a boottime argument to enable this at all. That kind of sucks.

The third possibility is limited to a subset of hardware, but does allow the introduction of some kind of elegance into what would otherwise be one of those nightmarish scenarios that makes me consider taking up farming instead. If we can trigger a PME ourselves then we can test whether the line is connected. This doesn't appear to be possible on SDHCI but the spec for firewire makes it look like we can do it there - one of the interrupt sources is the port enable/disable register, and we can hit toggle that ourselves. I haven't actually tested this yet, but if it works that would let us make this determination.

It's depressing that doing anything interesting with power management is still heavily determined by what Microsoft have bothered to implement - to the extent that on some machines (hello, Thinkpads) there are no GPE methods at all for PME signals and you don't get runtime power management at all. The only thing that saves us is that (a) it's pretty hard to be able to screw up stuff that's already all glued into one chip package, so integrated stuff like USB should be fine anyway, and (b) PCIe does this as part of the normal traffic stream so there's no way to get that wrong. Unless you're still missing the GPE methods for the signals (hello, Thinkpads) in which case you get nothing unless the native PCIe signalling works. I suspect that we can always force that, so there's some hope yet.

In summary, then: dispassionate.

Steve Jobs has published an interesting article about Flash [1]. He criticises Flash for being proprietary, this seems a little hypocritical coming from Apple (who s the only competitor for Microsoft in terms of being the most proprietary computer company) but is in fact correct. Steve advocates HTML5 which is a better technical solution to a lot of the things that Flash does. He claims that Apple users aren t missing out on much, but I think that sites such as Physics Games [2] demonstrate the benefits of Flash. I think that Apple s attack on Flash is generally a good thing. HTML5 web sites will work everywhere which will be a good incentive for web designers to fix their sites. I also think that we want to deprecate it, but as it s unfortunately popular it s useful to have tools such as GNASH to use Flash based web sites with free software. Microsoft has belatedly tried to compete with flash, but it s Silverlight system and the free but patent encumbered Linux equivalent Moonlight have very little content to play and will probably disappear soon. As an aside the relentless determination of GNOME people to force the MONO project (including Moonlight) on it s users convinced me to remove GNOME from all systems that I run. OS News has a good analysis of the MPEG-LA patents [3] which are designed to prevent anyone making any commercial use of H.264 which includes putting such videos on sites that contain Google advertising! These patent terms are so horrible that they want to control video streams that were ever encoded with them, so you can t even transcode a H.264 stream to an open format without potentially having the scum at MPEG-LA going after you. This is worth noting when examining Apple s actions, they support MPEG patents and therefore seem happy to do anything that reduces the freedom of their customers. Apple s 1984 commercial has been proven to be a lie, it s Apple that wants to control our freedom. Charles Stross makes some good points about the issues related to Apple and Flash [4]. He believes that it s all part of an Apple push to cloud computing and that Apple wants to own all our data at the back-end while providing a relatively reliable front-end (IE without all the anti-virus nonsense that is needed on the MS-Windows platform. Cloud computing is a good thing and I can t wait for the Linux support for it to improve, I support a number of relatives who run Linux and it would be a lot easier for me if they could have the primary storage for everything be on the cloud so that I can do central backups of user data and they can use their own data while visiting each other. I think that a network filesystem that is similar in concept to offline-IMAP would be a really good thing, I know that there are some filesystems such as AFS and CODA that are designed for wide area network use with client-side caching but as far as I am aware they aren t designed for the type of operation that offline/caching IMAP supports. Matt Brubeck has given a good status report of the work porting Firefox to Android [5]. He notes that the next version of Fennec (mobile Firefox) will have Electrolysis the Firefox one process per tab feature that was first implemented in Google Chrome [6]. I think that the development of Fennec and the one process per tab feature are both great developments. Matt also says One of my personal goals is to make Firefox compatible with more mobile sites, and to give web developers the tools and information they need to make their sites work great in mobile Firefox. I ll write much more about this in future articles , that sounds great, I look forward to the results of his coding and to reading his blog posts about it!

• [1] http://www.apple.com/hotnews/thoughts-on-flash/
• [2] http://www.physicsgames.net/
• [3] http://www.osnews.com/story/23236/Why_Our_Civilization_s_Video_Art_and_Culture_is_Threatened_by_the_MPEG-LA
• [4] http://www.antipope.org/charlie/blog-static/2010/04/why-steve-jobs-hates-flash.html
• [5] http://www.advogato.org/person/mbrubeck/diary.html?start=120
• [6] https://wiki.mozilla.org/Electrolysis

One interesting feature in Active Directory, is the ability to create a new user with an expired password, and thus force the user to change the password on the first login attempt. I'm not quite sure how to do that with the LDAP setup in Debian Edu, but did some initial testing with a local account. The account and password aging information is available in /etc/shadow, but unfortunately, it is not possible to specify an expiration time for passwords, only a maximum age for passwords. A freshly created account (using adduser test) will have these settings in /etc/shadow:

root@tjener:~# chage -l test
Last password change                                    : May 02, 2010
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7
root@tjener:~#

The only way I could come up with to create a user with an expired account, is to change the date of the last password change to the lowest value possible (January 1th 1970), and the maximum password age to the difference in days between that date and today. To make it simple, I went for 30 years (30 * 365 = 10950) and January 2th (to avoid testing if 0 is a valid value). After using these commands to set it up, it seem to work as intended:

root@tjener:~# chage -d 1 test; chage -M 10950 test
root@tjener:~# chage -l test
Last password change                                    : Jan 02, 1970
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 10950
Number of days of warning before password expires       : 7
root@tjener:~#  

So far I have tested this with ssh and console, and kdm (in Squeeze) login, and all ask for a new password before login in the user (with ssh, I was thrown out and had to log in again). Perhaps we should set up something similar for Debian Edu, to make sure only the user itself have the account password? If you want to comment on or help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org. Update 2010-05-02 17:20: Paul T tterman tells me on IRC that the shadow(8) page in Debian/testing now state that setting the date of last password change to zero (0) will force the password to be changed on the first login. This was not mentioned in the manual in Lenny, so I did not notice this in my initial testing. I have tested it on Squeeze, and 'chage -d 0 username' do work there. I have not tested it on Lenny yet. Update 2010-05-02-19:05: Jim Paris tells me via email that an equivalent command to expire a password is 'passwd -e username', which insert zero into the date of the last password change.

update: 20100503: It's been brought to my attention that there might have been a regression in one of the libraries, mesa, maybe, so that master might not be as reliable a reference point for this guide. so, just in case, here are the commit hashes that were used from the different projects:

• dri2proto: c34ce137fdb21fc9a52bb8d5a0c25e3c5d79e687
• drm: 6293152eb065016a2e5e4fcd047c2db5c2fb0f36
• linux-2.6 (nouveau master) f108a544dbc9b64b0b42cfc6e21bc4f5ffd38998
• mesa: dd3b98bdf67df9a5b1127bf7d50bbb6691597bfb
• xf86-video-nouveau: 13c10430ba8f7b0edff3ad8aae4a97672eea4a8f

for the non-git-savvy: git checkout -b mybranch <hash> we now return to your regular broadcasting... A week or two ago I figured it was about time that I took the plung and tried out the latest nouveau drivers from experimental on my laptop. Unfortunately, it meant bidding adieu to compiz (apart from the bling it does actually provide some pretty damned useful features). I thought I'd give it a shot at least for a while on principal, since I've always had to think of the nvidia drivers as a necessary evil, and their lack of proper xrandr support is really, really annoying. Since then I haven't noticed any problems, apart from the following message after every suspend/resume:

[  931.213239] Uhhuh. NMI received for unknown reason 80 on CPU 0.
[  931.213240] You have some hardware problem, likely on the PCI bus.
[  931.213242] Dazed and confused, but trying to continue

No idea what's causing it, but otherwise the system is stable and functional. If anyone knows what can be done about this, I'd appreciate hearing from you. My graphics card, by the way:

01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)

In the time since then, the nouveau driver has made its way into unstable, and a lot of distros (ubuntu, fedora, ...) are even using it as the default driver. So before going any further with the 3d/compiz stuff, I highly recommend that you get the packaged version working first. This will not only make sure that the basic driver works, but it will also make recovery/rollback a lot easier. Since it's all packaged in the standard repositories, it's not much harder than installing a few packages and editing a few files... so come on give it a try Getting the 2d driver working in Debian sid Really, this is so easy it's hardly worth writing up, but i'm running with the -v flag this morning... Make sure you don't have any reference to nvidia in /etc/modules or other places that might cause it to be automatically loaded. Then remove the proprietary glx bindings, which would otherwise interfere with the nouveau driver.

sudo apt-get remove nvidia-glx

Next, you'll need to install a kernel that includes updated drm support. Normally this would require a kernel >= 2.6.33.1, but the debian kernel maintainers have graciously backported this code to the 2.6.32-4 kernel package. note this isn't the default kernel version in testing/unstable at the time of writing so you have to explicitly install it along with the nouveau driver.

sudo apt-get install linux-image-2.6.32-4-amd64 xserver-xorg-video-nouveau

If you are already running this kernel and using the proprietary nvidia drivers, via module-assistant or otherwise, you /might/ need to uninstall them first. On my system I left them installed in the old kernel version but did not install them on the new kernel version. Required xorg configuration I don't believe that nouveau is picked by default if available at the time of writing, so you have to have the following in your xorg.conf:

sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Device"
    Identifier     "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
    Driver         "nouveau"
EndSection
EOF

This was all I needed to do, apart from rebooting into the new kernel. For those who don't want to venture outside the packaging system, this is about as far as you can go for the time being. Though really, if you're bothering to read this far along, you're probably more interested in what comes next Getting 3d working (without voiding your distro warranty) So I thought I'd give the 3d-accelerated gallium a go. Their wiki page certainly makes one think twice, but at this point I was seriously fiending to get my bling back (well, the compiz scale plugin, anyway) and figured it wouldn't hurt too much to try. Via google and trawling around in various forums I found a number of how-to documents for getting Gallium3d on debian/ubuntu systems, but most of them recommended doing things in a way that wasn't easily reversible and that could totally hose your system in a not-so-hypothetical worst-case scenario. It's pretty hard to roll back a make install done into /usr, for example, and subsequent package upgrades can leave your system even worse off as they will probably clobber half of what you just did, leaving the other half totally broken. And if you have a laptop which requires the gui for networking (i.e. network-manager), then fixing/rolling-back the changes is not entirely trivial, since you'd likely have to re-download the various drm/mesa/xorg packages. So enter the tried and true unix utility stow (apt-get install stow, of course). stow is a utility that lets you install software into arbitrary folders, and then manage the system-wide installation of the software via a farm of symlinks pointing at the installed location. It's probably more well known among the sysadmin crowd than the desktop user crowd, but it's incredibly useful for the task at hand as it will let us easily install multiple copies of different software in a way that's very easy to update and/or roll-back. RTFM stow(1) for more information. So, on to the juicy stuff... Install needed software, remove problematic packages, setup, etc At least on my system, I had to remove libdrm-dev to keep things from accidentally linking against it instead of the updated version that we install later on below. There's probably a way to override this with CFLAGS but I figure this is simpler.

sudo apt-get remove libdrm-dev
sudo apt-get install stow build-essential xorg-dev git-core libtool mesa-common-dev automake autoconf 
mkdir ~/nouveau

Compile a linux-2.6.34 RC kernel

cd ~/nouveau
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f nouveau git://anongit.freedesktop.org/nouveau/linux-2.6
git checkout -b nouveau-master nouveau/master
make menuconfig

Enable device drivers -> staging drivers -> nouveau. Make any other changes you might want to make (I just took defaults for everything else).

make deb-pkg

The linux-firmware-free debian package ships some of the same stuff from the generated linux-firmware-image package. I decided to opt for the upstream firmware, though I'm not sure that this is necessary:

sudo apt-get remove linux-firmware-free
sudo dpkg -i ~/nouveau/linux-image*.deb ~/nouveau/linux-firmware-image*.deb
sudo update-grub

Install a copy of dri2proto

cd ~/nouveau
git clone git://anongit.freedesktop.org/xorg/proto/dri2proto
cd dri2proto
./autogen.sh --prefix=/usr/local/stow/dri2proto-20100428
sudo mkdir -p /usr/local/stow/dri2proto-20100428
sudo make install
sudo stow -d /usr/local/stow dri2proto-20100428

Install a cutting-edge version of libdrm

cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/drm/
cd drm
./autogen.sh --prefix=/usr/local/stow/drm-20100428 --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-20100428
sudo make install
sudo stow  -d /usr/local/stow  drm-20100428

Likewise for mesa

cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa
./autogen.sh --prefix=/usr/local/stow/mesa-20100428  --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
make
sudo mkdir -p /usr/local/stow/mesa-20100428 
sudo make install
sudo stow -d /usr/local/stow mesa-20100428

And now the xorg driver...

cd ~/nouveau
git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/
cd xf86-video-nouveau
./autogen.sh --prefix=/usr/local/stow/xf86-video-nouveau-20100428
make
sudo mkdir -p /usr/local/stow/xf86-video-nouveau-20100428
sudo make install
sudo stow -d /usr/local/stow xf86-video-nouveau-20100428

Configuration Configure xorg to look in alternate location for xorg modules and set up DRI

sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Files"
    ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection
Section "ServerFlags"
    Option "GlxVisuals" "all"
Endsection
Section "Device"
    Identifier     "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
    Driver         "nouveau"
EndSection
EOF

I've /heard/ that disabling TV out is a necessity on some cards, though I haven't seen this myself:

sudo sh -c "cat > /etc/modprobe.d/nouveau.conf" << EOF
# not entirely sure this is necessary, but heard it helped with vsync
options nouveau tv_disable=1
EOF

Finally, the one thing that can not be done in /usr/local is making the nouveau DRI driver available. From what I could tell the path that mesa uses to find the DRI libraries is hard-coded (corrections welcome). Since you won't already have this file (otherwise, why would you be following along here?), just drop in a symlink to the file in /usr/local:

sudo ln -s /usr/local/lib/dri/nouveau_dri.so /usr/lib/dri/

Finally, reboot, and hope for the best Riding the bleeding edge: how to upgrade later on Again, stow really shows its usefullness here. Using drm as an example case, upgrading an individual component would look something like:

cd ~/nouveau/drm
git clean -dfx
git pull
today= date +%Y%m%d 
./autogen.sh --prefix=/usr/local/stow/drm-$today --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-$today
sudo make install
sudo stow -d /usr/local/stow -D drm-20100428
sudo stow -d /usr/local/stow  drm-$today

Note how the old version is still installed, so you can switch components around pretty freely. Abort! Abort!: How to roll back changes In case your system becomes totally unusable, or you've decided that you just want to go back to the safe and cozy world of what's provided by the debian packages, simply do the following:

• Remove the ModulePath directive from your xorg.conf
• Remove the nouveau_dri.so symlink from /usr/lib/dri
• Possibly(?) boot into your previous kernel (I read grumblings about ABI breakage on lkml which might mean that you can't use the same libdrm with the old/new drivers, though I haven't had to find out).

Assuming that you're using the nouveau driver from unstable, this should be all that is necessary. Conclusion Overall impression I am very, very happy with the resulting setup. I was led to believe that this whole thing was much more unstable and unusable than it actually is! While there are certainly some glitches and missing features, I feel comfortable enough using it that I don't have plans to switch back. But if I find myself in a situation where I can't use the new setup, rolling back shouldn't be a problem either. I figure I'm happy with what I have now and it will only get better. What works, at least to a "kinda works" level.

• A standard compiz installation
• Basic 3d support
• Xvideo
• Display port switching with fn-F7 (but see below)
• Suspend/Resume (most of the time, anyway)

What still doesn't work

• Suspend/Resume doesn't /always/ work, I wouldn't call it 100% reliable anyway
• I've had an occasional graphical lockup of the system requiring reboot
• Switching display ports only partially works (one of the two displays will usually be corrupted, though the other will work ok).
• Docking and undocking combined with suspend/resume and switching displays seems to trigger some hard lockups.
• Haven't tried extensive use of 3d-apps yet.
• Graphics glitches/artifacts
• A number of things will make compiz crash. When this happens it automatically falls back to metacity, so it's not a huge problem--just pretty annoying.
  • gnome-display-properties
  • using the compiz "Resize Window" plugin with "Normal" (change it to "Rectangle")
  • switching from lcd to external monitor will sometimes cause it to crash
  • I would guess other plugins might be problematic as well, though at least what I had enabled previously seems to work okay.
• Any kind of GPU power saving features (graphics card runs pretty hot, anyway).

Further reading, references

• DRM installation guide
• Kernel modesetting tips
• Gallium3D howto
• Tips for lockup recovery
• An earlier ubuntu how-to

Thanks A couple shoutouts to those who helped me with this on the way:

• all the developers involved in the respective projects... a big Thank You!
• ymanton, mwk, calim, paerley on #nouveau for helping me troubleshoot kernel/libdrm issues.
• KiBi on #debian-x for all the work getting nouveau into unstable.

Feedback / Corrections Unforunately, I've had to disable comments for the time being due to overwhelming quantities of spam. So please drop me a line via email or on IRC (seanius on oftc/freenode).

People s the deadline is fast approaching. Don t worry though, the best ideas come under deadlines and your proposal need not be lengthy. So get those typing hands out and submit a proposal (a few sentences suffices) for a presentation! The annual Debian conference is being held in NYC this year. First time
setting foot in the imperial empire. Are you doing something related to
free software that might be interesting to share, show off or talk about
at Debconf? I bet you are! We are looking for art installations,
performances, movie screenings, maybe you are wanting to host a
roundtable/panel discussion, coordinate a workshop (you dont have to
know the subject deeply to do this!). I know the deadline is soon, but don t let that scare you. The
submission requirement bar is very low, and we are flexible! here is the submission information: [1] ********************* Calling all potential contributors to DebConf10! One more week until
the final submission deadline! The DebConf team is excited to announce that we are now accepting
proposals for contributions to this year s Debian conference! We
invite you to submit proposals for how you would contribute until the
deadline: soon There are many ways you can contribute, you could present a technical
paper, host a panel discussion, put on a tutorial, do a performance,
an art installation, a debate, host a meeting (BoFS, or Birds of a
Feather Session), or other possibilities that you devise. This year we
are also accepting proposals for tracks=E2=80=94a thematic grouping around a
particular subject, and people to coordinate those tracks. If you are
looking for ideas of things that you could contribute, or have ideas
for things that you would like to see happen at DebConf, have a look
at the Contribution Brainstorm[0] page. DebConf talks will be broadcast live on the Internet where possible,
unless otherwise requested. Videos of the talks will be published on
the web along with the presentation slides and papers. =3D=3D Step 1. Submit Proposal =3D=3D Proposals should provide an overview of your proposed contribution,
similar to an abstract, and be no more than 600 words. Since
contributions can cover a range of issues, please describe what your
proposal covers, be it political (Free Software, law, advocacy,
access, etc.), technical (d-i, OpenPGP, etc.), social (Debian
structures and groups). It s okay to hit all three of these. Your
proposal should also include some information on why you re qualified
to present, or coordinate this topic. For example, you can include
links to posts you have made to Debian mailing lists or other material
that indicates your qualifications. Proposals and their abstracts will
be accepted until May 1st, 2010, 23h59 UTC. To submit your proposal, go to Penta[1] and register as an
attendee. Once you are registered, there is a Submit a proposal
link. You will see your proposal on the site. You can choose between
different presentation types. If you are unsure what type you should
use, please read our glossary of definitions[2]. If it s not there for
some reason, or you have questions, please contact us immediately at
mailto:talks@debconf.org. =3D=3D Step 2. Committee Review =3D=3D The review committee for this year will make its decision by May 1st,
2010. All correspondence will be done by email. =3D=3D Step 3. Paper Submission =3D=3D Like last year, we are asking for papers to be submitted along with
the presentations. A full paper is optional, however we strongly
encourage you to submit one if possible as we intend to provide
written information along with transcripts of the sessions for later
viewing. Having written papers in advance will allow us to get
translations done to help non-native-English speakers feel more
comfortable with the topics presented. Papers are due by July 1st,
2010, and should cover the topic in reasonable depth (3 pages A4 text,
plus pictures and diagrams). We will use LaTeX to typeset the
proceedings. Please submit your paper formatted in LaTeX. Should you
be unfamiliar with LaTeX earlier submission in plain text is also
fine. =3D=3D Step 4. Live Presentation =3D=3D Longer presentations may have a break in the middle and should include
workshop items that directly involve the participants. If using slides
or any other presentation, please consider that your audience will
consist of people who use free software, and your choice of
application to prepare and display the slides should reflect this if
at all possible. =3D=3D Fine Print Publication Rights =3D=3D DebConf requires non-exclusive publication rights to papers,
presentations, and any additional handouts or audio/visual materials
used in conjunction with the presentation. The authors have the
freedom to pick a DFSG-free license for the papers themselves and
retain all copyrights. The presentations will be recorded, and may be
broadcast over the Internet. Any copies of the presentation will be
made available =3D=3D Failure to Submit =3D=3D In the event that a deadline is missed we reserve the right to revoke
any offer to present. =3D=3D About DebConf =3D=3D The annual DebConf conference is a technical and social forum for
Debian developers, sponsors, affiliates, and friends. It allows
various groups within Debian a chance to come together, network, and
share their work. Until we see you in the big city,
DebConf Talks Team [1] introduction written by Micah Anderson

Face it: technology fails. Sometimes. Sooner or later.Statistics are a nice way to fool people, because they can't interpret the numbers properly. And usually this is done to make things sound less risky than they really are. But it's just too easy to lie with numbers. Say, they risk of a major incident at a plant is less than 1% (per year). Sounds good, doesn't it? But if you have 100 plants, that means it will happen about once a year. Make that 1000. Or even more.There are currently around 440 nuclear reactors in use for electricity. Probably some more the IAEA doesn't know about. There are definitely extra reactors in various military vehicles including unmaintained russian submarines. So make that 500. So looking forward to the next 200 years, we want to make sure things are not likely to happen at a rate of 0.001%. Unless our atomic plants are way more than 99.999% secure, we're likely to see a major nuclear accident sooner or later.Which brings us to a totally differnt scale when we look at photovoltaics or wind power. There are just so many more of these plants, that you can bet on some of them failing completely every day. The good news about these plants is that their damage potential is just so much lower. They might be as much as thousandfold more likely to fail than a nuclear plant. And there are probably a thousand more, too. But even if we completely underestimate the risk they just don't do as much damage even in the worst case. Much unlike a nuclear meltdown or such an oil spill. I bet noone would have thought of oil drilling being this risky. After all, it has been done for years.So how is your risk assessment of nuclear power? Is it less risky than oil drilling?

Last month I joined Mozilla as a UI engineer on the Fennec (Mobile Firefox) project. Firefox is already available for Nokia's Maemo platform, and now a group of Mozilla programmers are porting it to Google's Android OS. This Tuesday they made an early preview build available for public feedback. Until now, the only people working on Firefox for Android were platform developers getting the back-end code to build and run. This week was the first time most other people including me got to try it out. We front-end developers and designers are now starting to adapt the user interface to Android. (The preview build used the look and feel of Firefox for Maemo, designed for rather different hardware and software.) Because we are an open source project, we like to share our work and hear your feedback even at this early stage of development. While I wasn't directly involved in the Android development effort, I spent some of my spare time this week talking to users via Twitter and our Android feedback group. Here's what I heard, in rough order of importance to users, plus some information on our future plans.¹

• Zoom and multi-touch: Pinch zoom gestures are coming! We are reviewing a patch for animated multi-touch (pinch) zooming on Qt-based devices, and testing similar code on Android. (Current Maemo devices have no multi-touch, so we use the volume buttons to zoom. That code hasn't been ported to Android, so only double-tap zoom was working in the preview build.) We also had some requests to fit text to the screen when zoomed in, like the Android browser. Today Brad Lassey and Ben Stover released the Easy Reading add-on that does exactly that. We might make this a built-in option in Fennec once it is fast and reliable enough.
• Menu and Back buttons: The preview build did not handle Android's standard hardware buttons, but code is now checked in to support the back button and the menu and search buttons. We still need to do some UI work to make good use of these.
• Size: I didn't anticipate this problem, but in retrospect it should not have been a surprise. A ten megabyte download (over 30 MB installed) is not huge for a desktop browser, but it's hefty for a mobile app especially on Android, where apps are saved to limited onboard memory. Even worse, users reported that our Fennec build did not work with the feature in some custom Android ROMs to move apps to the SD card. Shrinking Fennec is possible, but not trivial. Some of the library and toolkit code in our build is probably unused and could be removed. And we could try minifying our Java Script source, like many websites do. Mozilla's Android developers also hope to fix the problem with SD installation. It will be nice someday when app storage on Android is as plentiful as it is on other mobile platforms.
• Hardware compatibility: There are a lot of different Android phones out there. Some of them won't run Fennec because they still have Android 1.5 or 1.6. We hope this will be fixed by the hardware vendors soon, since we currently rely on some Android 2.0 APIs. Other devices failed for different reasons, possibly related to insufficient RAM or incom patible OpenGL APIs. We will need to optimize Firefox's memory footprint on Android, and test on a wider selection of devices, perhaps with help from Firefox users.
• Keyboard problems: There were many problems with the software keyboard working intermittently or not at all, especially in landscape orienta tion. There were also prob lems with Shift and Alt keys on some hardware keyboards. I haven't heard any news about of these bugs, but we know we need to fix them quickly.
• Speed: Strangely, we had some users calling Fennec slooooooow and others calling it fast as hell (and those tweets were sent just one minute apart)! Once a page is loaded, Fennec is pretty speedy. It's faster than the Android browser in some areas, and slower in others. But it's definitely choppy while a page is still loading or complex scripts are running. To fix this, our next major release of Fennec will include Elec trolysis. This gives Firefox a multi-process architecture much like Google Chrome, and ensures that the browser always stays responsive. Electrolysis requires many changes to our code, so it may be a couple of months before it appears in usable Fennec builds. In the mean time, Mozilla is working on many other performance improvements. This work will also speed up Firefox for desktop computers I've been using the FF4 nightly builds, and they are already much snappier than the Firefox 3.5 I was using before. We've also checked in some simple changes to improve perceived speed, like better feedback when pages start loading.
• Crashing bugs: Users were generally forgiving of crashes and other obvious bugs, to be expected at this stage of development. We will of course fix any such bugs as fast as possible.
• Add-ons: We're just starting Fennec 1.1 beta testing, and most of our add-ons are not yet updated for version 1.1. Unfortunately, the timing means that many add-ons were not available to our first Android previewers. This should be fixed over the next few weeks. I believe add-ons are the biggest advantage Firefox has over other mobile browsers. For the first time on a mobile phone I can easily customize the browser to scratch my own itch. (See my first Fennec add-ons, Read Later and Show Image Title.) And there are many great add-ons from other devel opers to choose from.
• User interface: Most of the feedback on our UI was positive. Users told us that panning to reveal the toolbars felt natural and easy. I think Madhava and Sean have done a great job with the design. This will get even better as we take advantage of Android features like the hardware buttons, integration with other activities, voice input, and the notification bar.
• Flash: Firefox for Maemo supports plugins like Flash, although enabling Flash does cause performance problems on some sites. (We are working on fixing that with major changes to our graphics code.) Flash is not yet included in our Android builds, but it will be supported eventually.
• Web site compatibility: Fennec renders almost all pages the same as desktop Firefox. Users did report problems entering data on some pages, and found that most sites do not have mobile versions targeted at Firefox. One of my personal goals is to make Firefox compatible with more mobile sites, and to give web developers the tools and information they need to make their sites work great in mobile Firefox. I'll write much more about this in future articles.

We don't have a regular schedule yet for releasing new builds on Android. Once we get the code merged and automated build servers configured, we'll publish nightly builds of Firefox for Android alongside our Maemo and desktop nightlies. Later this year we will have alpha and beta versions, and hopefully a stable release. Until then, you can follow @MozMobile or Vlad (@vvuk) to hear about any new previews.

1. Please remember I am still new to the project, and cannot speak for the whole team. This is a personal blog, not a Firefox roadmap!

For some years now, I have wondered how we should handle laptops in Debian Edu. The Debian Edu infrastructure is mostly designed to handle stationary computers, and less suited for computers that come and go. Now I finally believe I have an sensible idea on how to adjust Debian Edu for laptops, by introducing a new profile for them, for example called Roaming Workstations. Here are my thought on this. The setup would consist of the following:

• During installation, the user name of the owner / primary user of the laptop is requested and a local home directory is set up for the user, with uid and gid information fetched from the LDAP server. This allow the user to work also when offline. The central home directory can be available in a subdirectory on request, for example mounted via CIFS. It could be mounted automatically when a user log in while on the Debian Edu network, and unmounted when the machine is taken away (network down, hibernate, etc), it can be set up to do automatic mounting on request (using autofs), or perhaps some GUI button on the desktop can be used to access it when needed. Perhaps it is enough to use the fish protocol in KDE?
• Password checking is set up to use LDAP or Kerberos authentication when the machine is on the Debian Edu network, and to cache the password for offline checking when the machine unable to reach the LDAP or Kerberos server. This can be done using libpam-ccreds or the Fedora developed System Security Services Daemon packages.
• File synchronisation with the central home directory is set up using a shared directory in both the local and the central home directory, using unison.
• Printing should be set up to print to all printers broadcasting their existence on the local network, and should then work out of the box with CUPS. For sites needing accurate printer quotas, some system with Kerberos authentication or printing via ssh could be implemented.
• For users that should have local root access to their laptop, sudo should be used to allow this to the local user.
• It would be nice if user and group information from LDAP is cached on the client, but given that there are entries for the local user and primary group in /etc/, it should not be needed.

I believe all the pieces to implement this are in Debian/testing at the moment. If we work quickly, we should be able to get this ready in time for the Squeeze release to freeze. Some of the pieces need tweaking, like libpam-ccreds should get support for pam-auth-update (#566718) and nslcd (or perhaps debian-edu-config) should get some integration code to stop its daemon when the LDAP server is unavailable to avoid long timeouts when disconnected from the net. If we get Kerberos enabled, we need to make sure we avoid long timeouts there too. If you want to help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

I ve been asked by the Debconf 10 talks team to coordinate a Debian Enterprise track at the upcoming Debconf 10 conference. I m really excited about this, and I could use your help. From my standpoint, this all started with a BOF proposal looking at better coordination and what is missing in Debian enterprise integration. The track will also include talks and other events on what exciting things are happening with Debian in the enterprise. I need your help in the form of suggestions for talks, panels and the like (especially if you would be willing to give the talk or coordinate an activity). We re under a fairly tight deadline; ideally proposals would be in by May 1, but if they are not, it s still definitely worth discussing with me. From my standpoint, topics include:

• Managing groups of machines together
• Working with Active Directory
• Open source answers to the use cases of Active Directory if you aren t a Windows shop
• Responses especially in the form of working code or ideas for getting there to my concerns about how we re letting Microsoft drive the evolution in the enterprise
• Federated authentication, authorization and personalization
• Integrating with asset tracking, ERP, and other enterprise processes and how Debian fits in.
• Bringing enterprise players into the community as contributors to the project

Obviously, many other things could fit in and I d be interested in your ideas as well.

Getting close now. Sarah had another ultrasound yesterday, just to check things. Unfortunately I couldn't be there due to a self-inflicted scheduling screw up. Apparently you could see hair on the ultrasound, so I'm a bit bummed to have missed it. The baby has "dropped", so that's good. Her head's still down, and she's swallowing, so that's all good too. Weight-wise she's now in the 38th percentile. We're booked in for a C-section on the 14th, unless she comes of her own free will between now and then (which is what we'd prefer), in which case our OB will allow an attempt at a VBAC. Our OB is reluctant to allow the pregnancy to go past 39 weeks, given prior history and Sarah's heart, and they don't induce for VBACs, so it's going to require some planetary alignment to avoid a C-section. The whole heart thing still being an issue was only a fairly recent discovery for us. Sarah's cardiac surgeon had told us we could go forth and have as many kids as we wanted, but it turns out the fine print in that statement is that while the previous aneurysm has been repaired, she has an undiagnosed connective tissue disorder, so there's no telling what might happen with the rest of her aorta in the future. So her OB is just doing what a good high-risk OB should do, and being extra paranoid, on two fronts. So we've got a couple of weeks to try and convince our daughter to come more than a week and 2 days early. I don't think we have statistics on our side, unfortunately (although I had a surprisingly hard time finding concrete statistics on delivery dates relative to due dates for first-time deliveries versus subsequent deliveries).