After xf86-video-ati 6.8.0 got released, George Sapountzis split the old r128 and mach64 subdrivers out of the common ati wrapper. So, starting from 6.8.1, the xserver-xorg-video-ati package only contains the radeon subdriver. The other subdrivers have been moved to their own xserver-xorg-video-r128 and -mach64 packages. All of them just landed in experimental. Your existing xorg.conf should work as before. I don't have any Mach or Rage board, so please test these new packages and report back if they don't work. Note that if your xorg.conf contains Driver "ati", you'll need to keep xserver-xorg-video-ati installed. If you only have the mach64 or r128 package installed, you need switch to Driver "mach64" or "r128" in xorg.conf. On the radeon side, the upstream developers are still very active. The last feature that has been added is Textured Xvideo. The Xvideo extension is usually implemented using the hardware overlay, which basically inserts the video on screen at the very end of the rendering. While working very well, this feature conflicts with compositing managers such as Compiz which cannot transform the Xvideo image. The radeon driver now exposes a Texture Xvideo adaptor which is composite-aware, which means you can have wobbly Xvideo players in Compiz. The Overlay adaptor is still the default since the Textured video isn't considered stable enough yet. To enable it, you can use something like:

    mplayer -vo xv:port=74 foo.avi

Where do I get this port 74 from? Just look at the output of xvattr or xvinfo:

    $ xvattr
    Found Xv 2.2
    Adaptor: 0
    Name: ATI Radeon Video Overlay
     Port: 73
     [...]
    Adaptor: 1
    Name: Radeon Textured Video
     Port: 74
     Port: 75
     [...]
    $ xvinfo
    X-Video Extension version 2.2
    screen #0
     Adaptor #0: "ATI Radeon Video Overlay"
      number of ports: 1
      port base: 73
      [...]
     Adaptor #1: "Radeon Textured Video"
      number of ports: 16
      port base: 74
      [...]

Anatomy of a Murder. David Denby put it best:

Otto Preminger s Anatomy of a Murder, from 1959, is still the best courtroom drama ever made in this country, and, in its occasional forays out of the court, among the finest evocations of place an Upper Peninsula Michigan resort area in the off-season, leafless, underpopulated, alcoholic, and forlorn. James Stewart, in one of his wonderful melancholy late performances, plays a former county prosecutor named Biegler, a lifelong bachelor who now spends his time with a non-practicing lawyer (Arthur O Connell) and an unpaid secretary (Eve Arden), who sticks around for the wisecracks. The movie is leisurely, detailed, realistic, intensely companionable; you get a sense of how people exist at the margins of a profession without losing their dignity.

Although there are some distinctions between a murder defense in the 1950’s in the Upper Peninsula of Michigan and modern-day patent litigation, the essence of trial technique is really not all that different. Highly recommended.

Prosecutor: Lieutenant Manion, wasn’t your action against Barney Quill much the same thing as your action against Miller or the Lieutenant you slapped at the cocktail party — all done in the heat of anger, with a willful, conscious desire to hurt or kill?

Defendant: I don’t remember my action against Quill.

Prosecutor: How long had you known your wife was stepping out with Quill?

Defendant: I never knew anything like that. I trust my wife.

Prosecutor: You just occasionally beat her up for the fun of it, I suppose?

Defense Counsel: There has been nothing established to permit a question like that. He keeps trying to insinuate without ever coming to the point. Let him ask the Lieutenant, did he ever beat his wife.

Judge: I will sustain the objection. Do you want to re-phrase your question, Mr. Dancer?

Prosecutor: No thank you, Your Honor. I’ve finished.

Technorati Tags: Otto Preminger, Anatomy of a Murder, David Denby

Share This

So, sometime over the past few weeks I clocked up ten years as a Debian developer:

From: Anthony Towns <aj@humbug.org.au>
Subject: Wannabe maintainer.
Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST)
To: new-maintainer@debian.org
Hello world,
I'd like to become a debian maintainer.
I'd like an account on master, and for it to be subscribed to the
debian-private list.
My preferred login on master would have been aj, but as that's taken
ajt or atowns would be great.
I've run a debian system at home for half a year, and a system at work
for about two months. I've run Linux for two and a half years at home,
two years at work. I've been active in my local linux users' group for
just over a year. I've written a few programs, and am part way through
packaging the distributed.net personal proxy for Debian (pending
approval for non-free distribution from distributed.net).
I've read the Debian Social Contract.
My PGP public key is attached, and also available as
<http://azure.humbug.org.au/~aj/aj_key.asc>.
If there's anything more you need to know, please email me.
Thanks in advance.
Cheers,
aj
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
On Netscape GPLing their browser:  How can you trust a browser that
ANYONE can hack? For the secure choice, choose Microsoft.''
        -- <oryx@pobox.com> in a comment on slashdot.org

Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).

---

• Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
• Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
• cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
• Played for a sucker, part one: a few months later I was messing around doing QA stuff and fixing bugs and as part of that did an NMU of netbase (which at the time directly contained all sorts of important tools like ping and inetd directly). That went something like:

  From: Anthony Towns
  Date: Sat, Nov 21, 1998
  There are a few bugs accumulating against the netbase package which
  you're maintaining. I was wondering if you'd mind if I made an NMU
  to fix some of them for the upcoming slink release?
  

  From: Peter Tobias
  Date: Sat, Nov 21, 1998
  No, please go ahead ... I'm quite busy right now and I would really
  appreciate any help. Please let me know if you need additional information
  about the package.
  

  From: Anthony Towns
  Date: Sun, Dec 6, 1998
  There's an NMU sitting in Incoming now. It fixes a few bugs, viz:
  [...]
  

  From: Peter Tobias
  Date: Fri, Dec 25, 1998
  due to my current job I don't have much time to work on my debian
  packages. In order to have more time for my other debian packages
  I would like to give away the netbase package. Are you interested
  in maintaining this package?
  

  From: Anthony Towns
  Date: Fri, Dec 25, 1998
  Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
  
  

• ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
• bugs.debian.org: I’m not entirely sure why, but in August ‘99 I decided to start running a script to stop old bugs from being permanently deleted:

  From: Anthony Towns
  Subject: BTS and old bugs
  Date: Tue, 24 Aug 1999 22:33:16 +1000
  To: debian-private@lists.debian.org
  ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to
  developers.
  Since bugs #9705 and #36727 don't seem like being fixed any time soon
  and Darren hasn't managed to convert the BTS to using debbugs.deb yet,
  I've made a little script to stop us from continuing to lose bug
  reports, and am running it in my crontab on master.
  ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in
  ~iwj/debian-bugs/spool/db (except split into sub-directories). When
  the bugs get expired from the BTS, the hardlink in ~ajt remains, so
  the file doesn't get lost forever.
  In the week or so I've been running it, some 500 odd bugs expired [0].
  

  Next month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.
• testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
• Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
• Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
• katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
• debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
• Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.

Hrm, this is going on longer than I’d hoped. Oh well, to be continued!

From the start of the DebianEeePC project, we have used a combination of the irc channel and our wiki site to our great advantage. The DebianEeePC/HowTo/Install document has been actively maintained as we go, serving not only as a good reference for new users, but also for existing users and developers to see where improvements are being made and what is left to work out. Recently, we’ve started using the wiki for task management as well. Patterned after DebianInstaller/Bugs, we now have DebianEeePC/Bugs where we link to reports on the BTS for packages we maintain and our own usertags on packages we don’t maintain. As well, we are keeping a DebianEeePC/Todo to manage our tasks. I see from a search through the wiki that lots of other Debian subprojects keep Todo lists, but most of them have little more structure than point-form lists. A few, though, have structured these pages a bit more carefully. For instance, some of these use tables listing who each task is assigned to, when it was assigned, and when it is completed. Our point-form list is a bit more free-form regarding task assignments. Participants can register their interest in a given task and what they are doing as a subpoint of the task. As for state changes over time, we rely on the revision history on “info” page for people to be able to see state changes for particular Todo items. When something is done, it just gets dropped from the list. I haven’t exhaustively reviewed everyone’s Todo page, but from my brief survey I haven’t seen a couple of things I’ve added to try to help people choose what to do next. The first is to tag items with six difficulty/importance pairs, rating each actionable item from Easy/Urgent to Hard/Wishlist. The second is to state dependencies between items using anchors. It would be nice to see any of you are doing something similar and hear about whether it has worked out well for you. I’m happy with how the irc/wiki combination has helped with project management. In the past with a different project I’ve made an abortive attempt to use the task management system at Alioth, but it just seemed too cumbersome and nobody ended up using it. With the wiki, it appears barriers to participation in task management are sufficiently lowered that everyone is willing to help keep it up. And with irc, we can keep on top of defining and assigning (or more usually volunteering to do) various tasks, and making sure the wiki is kept completely up to date. It takes a bit of discipline to do, but after the habits are established, it gets easier, and the rewards are well worth it.

Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!

I've quickly written a demo application to show how it's done.
The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in the first screenshot. The actual code to the demo application is rather brief.
The main point to keep in mind is that you can't actually reuse the same widget, more than once, at one time. You could reuse it if you'd make sure it's never used more than once at the same time, and keep track of it (you also have to make certain it doesn't get accidentally destroyed along the way!)

What the demo really does, and what libglade allows you to do, is use (parts of) the same interface definition over and over again to build distinct PyGTK objects and add them to the existing interface. At least the PyGTK implementation of libglade, and possibly the native C libglade as well, actually caches the interface definition in case you'd want to reuse parts of it for additional object creation.

Let's have a closer look at how it's done:

import gtk, gtk.glade
class ReuseDemo:
  def __init__ (self):
    self.gladefile = 'glade-reuse-demo.glade'
    self.xml = gtk.glade.XML (self.gladefile)
    self.win = self.xml.get_widget ('firstWindow')
    self.theContainer = self.xml.get_widget ('theHBox')
    self.xml.signal_autoconnect (
                     dict (gtk_main_quit=gtk.main_quit,
                     btn1_toggled=self.toggle1,
                     btn2_toggled=self.toggle2))
    self.buttons = (self.xml.get_widget ('tbtn1'), self.xml.get_widget ('tbtn2'))
    self.childTree = None
    self.win.show_all()

First step is to import the gtk and gtk.glade modules.
The actual demo is in a little class; it's constructor starts by storing the name of the glade file, because it's needed later to construct the additional objects from (even if the caching should mean it isn't really re-read anymore). The xml tree from this file is parsed by pyglade and the window object is retrieved from the first of the two windows defined in it. At this point the window is already a PyGTK object!

The container that needs to have objects added to and removed from is also retrieved and stored as a class attribute. The signals for the two toggle buttons and to allow a graceful exit by means of the windowmanager close button are connected to their handlers, and the two togglebuttons' objects are also retrieved and stored away for later reference. Finally, a variable to hold a reference to the secondary textbox objects is initiated, and the window is shown.

  def toggle1 (self, btn):
    self.toggle (btn, 'txtContent', 1)
  def toggle2 (self, btn):
    self.toggle (btn, 'txtOther', 2)

The two toggle button callbacks call a single method, with the gladeXML tagname for the respective textbox object each one needs to display or remove and an index number for arguments (in addition to the togglebutton object reference that the callback received as it's first argument).

  def toggle (self, btn, tagname, idx):
    self.buttons[(idx%2)].set_sensitive (not btn.get_active())
    if not btn.get_active():
      if self.childTree:
        self.theContainer.remove (self.childTree)
        self.childTree = None
    else:
      objXML = gtk.glade.XML (self.gladefile, root=tagname)
      self.childTree = objXML.get_widget (tagname)
      self.theContainer.pack_end (self.childTree)

The important logic is in the final method. First, the button which is not toggled is disabled or enabled for user interaction, depending on the activated state of the toggled button. Because the indices passed on by the two toggle buttons' callbacks were one-based, while the python tuple that holds references to the toggle buttons is zero-based, the remainder of a division by two of the callback index will automatically point to the button that was not toggled. Alternatively the values 1 and 0, in that order, and thus pointing directly to the tuple indices could also have been used as index arguments for the two callbacks.

The necessity of disabling the other button when one is activated, and therefore two textboxes are displayed, is because the demo isn't written to support displaying more than two textboxes at the same time, but especially removing the correct textbox when three would be visible. If it were extended in that sense, the need to disable the other button would disappear.

Next the activated state is tested; if the button is deactivated, the second textbox is removed from the container and the reference to it removed, while if it's activated, a new object is instantiated from the gladeXML description and added to the container.
Here's where the gladeXML tagnames come in: to recreate only part of the widget tree, and retrieve the actual widget from the parsed tree. Note that you must reconstruct the parse tree here; retrieving the same object from the original parsetree and trying to add it a second time to the container will result in a GTK+ warning (on the console) and nothing being added at all.

That's all there is to it, really. All that is left is to instantiate a class instance and start the GTK+ mainloop:

if __name__ == '__main__':
  ReuseDemo()
  gtk.main()

The second screenshot is an example of how the application might look in one specific state.

A tarball with the glade and python code is available from the sysfs download area.

There’s an interesting discussion about Google Summer of Code going on debian-devel@. The question can be summarized as “Should we allow current Debian contributors to be students in GSOC?“? The GSOC FAQ says:

Google Summer of Code has several goals:

• Get more open source code created and released for the benefit of all;
• Inspire young developers to begin participating in open source development;
• Help open source projects identify and bring in new developers and committers;
• Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think “flip bits, not burgers”);
• Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).

The problem is that those goals are clearly conflicting:

• If you think that “get useful code written” is more important than “get fresh blood in Debian”, it is stupid to choose students that are not existing contributors to Debian. It’s a much better idea to choose people that already know Debian very well, so they will be very efficient.
• If you think that “get fresh blood in Debian” is more important than “get useful code written”, it is stupid to choose students that are already contributing to Debian. You should choose outsiders, of course.

Another problem is that in the past, some students that were also debian contributors had problems organizing themselves: they used some of their GSOC time to work on their usual Debian tasks, leading to results that were a bit disappointing. But it’s possible that this is mainly a management problem (however, mentoring people takes a lot of time, and only students are paid, not their mentors). How do you deal with that in your project?

The SPI meeting mentioned took place on Wed 27 Feb 2008 1900Z. I've posted the highlights and log to spi-general. I wasn't there because I was moderating the local cycle forum's meeting. It's a little disappointing that the announcement was so late, but at least it happened. It seems very disappointing that correspondence isn't being reported by the secretary, but maybe there's some innocent explanation that will come out now I've asked the question on-list.

$body

With my new VoIP infrastructure in place, I d like to get rid of the softphones and replace them with hardware. An obvious solution, given how I might need to replace my cellphone sometime soon, would be to check out the Nokia E65, which can do VoIP over wireless. I ve previously dismissed the Nokia E-series phones for good reasons, but Nokia had time to improve them, and I know a few people who like the E65. Waiting for the OpenMoko Freerunner is nother option. If you know of other VoIP+Wifi GSM cellphones you can advocate, please let me know. On the other hand, I might just want to get a separate VoIP phone, ideally wireless, to use at home exclusively. The problem is that there seem to be none. I checked out at least two dozens, and they all fall short for one of the following reasons:

• they are Skype-optimised, or don t even support proper VoIP. I see no need to support this.
• they combine VoIP with regular analog telephony, which I don t need. I d rather pay less.
• they are made by big players, who charge more for their brand than the product is worth.
• they come bundled with some VoIP service out there, which smells like lock-in or extra charges.

Thus, I am reaching out to the lazyweb. Does anyone know of a wireless (short-range) phone that can do VoIP at a reasonable price, either based on Wifi, or using an ethernet-connected base station (DECT). I d appreciate a note. NP: Age Pryor: City Chorus

New version of simple todo manager called Ukolovnik has been just released. There are no major changes in this release compared to 0.9, it mostly happened to indicate that this small piece of code has reached some level of stability and wanted level of features.

In 1996 Peter Gutmann wrote a paper titled “Secure Deletion of Data from Magnetic and Solid-State Memory” [1]. In that paper he mentions the fact that the contents of RAM last longer at lower temperatures and suggests that data could be retained for weeks at a temperature of -60C or lower (while 140C causes rapid data loss). The paper also addresses issues of data recovery from hard drives, but given that adequate CPU power for encryption is available recovering data from a disk shouldn’t be an issue unless thee attacker can get the key to decrypt it or crack the algorithm - so disk recovery is not a hot issue at the moment. Recently some researchers at Princeton University have published a paper describing in detail how to chill RAM to make it keep its data after a power cycle and even after being installed in a different computer [2]. This attracted a lot of attention, while Peter’s paper described the theoretical concept (in great detail) the Princeton group showed how to implement the attack using materials that are commonly available. Most of the analysis of this misses some fundamental points. Any suggestion that you can wipe the RAM on power failure or on boot misses the point entirely. If an attacker can chill a DIMM and then remove it from the system then there is no chance for it to be wiped. Maybe if you had security on the PC case to detect case opening (some servers have a basic version of this) such things would do a little good, but it shouldn’t be difficult to bypass in most cases. Another common flawed analysis is to suggest that this is no big deal because sniffing the memory bus has been possible for years. While it has always been possible for government agencies and companies who design motherboards to sniff the bus, for most potential attackers it has been overly difficult. When considering the effectiveness of a security system you should first consider what your threat model is. Who is going to attack you and what resources will they be willing and able to devote to the attack? An organisation that is prepared to use expensive equipment and highly trained people to break your encryption probably has other methods of gaining access to your secret data that are easier and cheaper. The research from Princeton suggests that I could perform such attacks with my spare time and with equipment that is very cheap. I’ve been idly considering doing this to an old PC just for fun! Therefore I have to assume that everyone who has the same amount of skill and money as me can potentially compromise my data if they capture one of my machines. It is still most likely that if anyone steals my laptop they will want to sell it and use the money to buy drugs. I don’t think that I have any data that is anywhere near valuable enough to justify a targeted mugging. But my procedures (in terms of changing passwords etc) in the case of my laptop being stolen now need to be scaled up due to the ease in which data might be compromised. The best way of dealing with this would be to have the decryption keys locked inside the CPU (stored in registers or memory that’s locked in the CPU cache). The possibility of getting a modern CPU to operate at any temperature approaching -60C is laughable, and the CPU is a well contained package that can operate on its own and is difficult to attack. This would make things significantly more difficult for an attacker while requiring little effort (in fact it might be possible to lock data in the CPU cache already in which case a software change is all that is required). Update: A comment by Mike made a good point about CPU cooling. Toms Hardware performed an overclocking experiment (from 3.2GHz to 5.25GHz) and used liquid nitrogen cooling [3]. It might be possible to cool a CPU core to -60C in a reasonably small amount of time. But I still believe that it would raise the bar enough to make it worth doing. Update2: Thanks Jaime for the spelling advice.

• [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html


• [2] http://citp.princeton.edu/memory/


• [3] http://www.tomshardware.com/2003/12/30/5_ghz_project/index.html

Share This

Is XFS that bad? Well, at least with default settings, XFS on Debian seems to be blown away by ext3 completely in terms of speed. I don't mind 1.5x slowdown, maybe even 2x, but 20x is a show stopper. I am already using ext3 for any pbuilder builds, because it's a difference to wait for 30s with XFS, compared to 3s with ext3 to extract the base image. And I'll probably switch to ext3 completely, unless someone finds a way how to fix this.

I recently got burned by this when running Sage on my computer, because it compiles a lot of Python files when started for the first time. Normally it should take roughly 15s, but instead it took 6 minutes on my comp and then it triggered a so far undiscovered bug in Sage, that I reported.

Michael Abshoff, the release manager of Sage, suggested that something is FUBAR (Fucked Up Beyond Any Recognition) on my shiny Debian amd64 sid system running on Intel Core Quad, so I said no way, because I really care about this machine, as I use it for larger finite elements calculations and other stuff (like compiling huge deb packages in parallel, like paraview).

So I offered a bet, that I give him an access to this compter, he finds the problem and if it's a problem in my Debian configuration, I'll write to this blog that I am lame, while if it's a problem in Sage, he will write to his blog that he is lame. And I was smiling to myself, how good I am and that I will have some fun too reading planet.sagemath.org with the top post from Michael saying that he is lame.

But then I remembered my old struggle with cowbuilder and XFS and I stopped smiling. See e.g. this wiki I created half a year ago. Something is FUBAR with XFS and Debian. I also asked on the Czech server Root, that is famous for having a lot of experts willing to share their knowledge, and it was quickly revealed, that the problem is with the "nobarrier" option of XFS (my post is here, but it's in Czech).

First, on that amd64 machine, the above problem was fixed after issuing this command:

mount -o remount,rw,nobarrier /dev/sda3 /home/

(notice the "nobarrier" option). You can read some background behind this on the lkml list. Unfortunately, I also have my laptop, and there I already use this "nobarrier" option, and it doesn't help at all. I just created a new ext3 partition and verified that on my laptop, ext3 is around 10x faster than XFS with nobarrier (that was supposed to fix this). I use the latest 2.6.24 kernel from unstable on both.

Time to move from XFS to ext3 on my laptop? Seems like that. I'll leave XFS on the other machine, because I know some other peole have good experience with XFS and the "nobarrier" option seems to fix the problem there.

But as to the bet, yeah, I am lame and I should still learn a lot from Michael. :)

Since 4 hours, the planet of ocamlcore.org is online. This is the first service provided by ocamlcore.org to the OCaml community. In fact, ocamlcore.org team has decided to release it today, because Erik Castro de Lopo ask a question about another OCaml planet in China. The one in China seems to be gathered through google search... Putting online the planet is also the occasion to test a little application to manage feed subscription: ocaml-planet. This script is quite trivial but it was a good first experiment of managing CGI/sqlite through OCaml. The application should help us to control subscription of feeds. I think this is a better way to subscribe than letting people commit changed planet.conf in some kind of SCM (like we do for planet debian). Once the forge of ocamlcore.org will be online, we will publish the source code of this application. I hope that this planet will be of some help for the OCaml community... http://planet.ocamlcore.org

I have spent one day and a half this week-end at FOSDEM. This was not as great as expected, but mostly because i don't have the time to stay the whole sunday. Next year, I will stay the whole week-end in order to have time to attend all the speak i should be interested in. The beer event was overcrowded, but all the beer i found there was great (in particular the Floris Pear). It was also a great time to have a demonstration of the XO OLPC laptop. This little thing is funny, but i don't get the way the UI should be used. Another bad point, is that the first console allow to login as root by pressing "Enter" (at least on the one i try). I suppose this kind of device is not intended to be secured. I also have time to talk with some Debian people and some other people -- in particular one who was thinking that Windows 2000 is the best ever OS. At least, it means that there were people from different horizons -- and this is a good thing. During Saturday, i spend half of the day in the big amphitheater (Janson). The talk about Tux with Shades (Linux in Hollywood) was impressive, regarding the trailer they show us... The talk about FreeBSD was interesting -- but not impressive as a trailer. I spend Saturday afternoon in the Debian devroom, following all the different talks. I miss the one from MadCoder about managing packages with git... That's a shame because i really want to see this one. Since my train was at 12am on Sunday, i choose to only pay a visit to the different booths. I have the pleasure to have a demonstration of the EeePC on the Debian booth that really please me. I found the UI more easy to understand than the one from XO. Speaking with the person demonstrating the laptop, she explained me that EeePC is more "standard desktop" and XO more "creative desktop". Conclusion: i am not creative ;-) Also talking about everything around talks and the meeting, i think Bruxelles is a really nice city for this kind of events. ULB is not near the center of Bruxelles but there are enough transportation. There was really a lot of people attending FOSDEM, and this is a good thing. I also have the pleasure to find some people from the OCaml Meeting.

I often have a bunch of somewhat crazy ideas, and I don’t have any time available to test or implement them, which is sad. So just in case these crazy ideas would scratch someone’s itch, I’m going to throw them in the wild. I’ve been using git for a few months, now, and used it not only for source code management, but for efficient storage, too. *VERY* efficient. I’ll have to write about that some day. Anyways, while installing pristine-tar, today, I just thought it would be neat to have an equivalent pristine-deb, to store deb files efficiently. I’m pretty sure someone else thought about this possibility, but it’s still better that such ideas come to the ears (eyes, actually) of someone that could implement them. Such a pristine-deb tool could be used to… store packages from snapshot.debian.net. That would reduce the amount of space required for the archive dramatically, IMHO. I’m pretty sure old packages are not requested that much, so they could be generated on-the-fly from a CGI script placed as a GET action, so that urls wouldn’t change. The same could probably be applied to archive.debian.org. It could even save enough space that archive.debian.org could host snapshot.debian.net. But that depends on the average package content and its average evolution, which I have absolutely no idea about. Update: It would also be interesting to have the .diff.gz files in there, too ; it would obviously allow to have an easy view of the contents, such as copyright files, changelogs, and other bits of information available on packages.debian.org. Update 2: Actually, pristine-deb would as easy as storing 2 pristine-tars (one for control.tar.gz and one for data.tar.gz), and a debian-binary file. The .deb can be aggregated with

ar -rc file.deb debian-binary control.tar.gz data.tar.gz

Every since I found out that the first digits of any credit card denote the issuer identifier (i.e., folks can tell who issued a credit card and what type it is just from the first digit or two) I've been annoyed almost each time I have to input credit card information on the web. Any decent credit card system knows that if a sixteen digit credit card number starts with 4, it's a Visa. And yet, each time anyone buys anything on the web, they must select "Visa" from the drop-down box. On a certain level we all know this; People in stores and restaurants never have to select the type of card before swiping. When I'm feeling generous, I imagine this is so that the credit card companies can give an extra reminder that they only accept certain credit cards -- not being able to select a card type in an "essential" input field constrained to multiple choices is a pretty strong reminder. When I'm feeling less generous, I suspect it might be so that the companies can subtly remind us that they have their own brand credit cards that we might like to acquire.

One of the interesting things about Google's Android project is the mix of cultures. There are a number of people like me, firmly grounded in the open source world, who are happy to get something that 1) works, 2) looks to have legs in terms of popularity, and 3) will be open source. Think of a lot of your favorite open source projects when they first launched. "Polished" isn't a word you would probably use to describe them, although it usually happens in later releases (Ubuntu looks better and better, for example). There are also a lot of people who come from a 'commercial' background, who expect to see everything ready and waiting on a plate for them, which isn't a mistaken expectation if you're used to using products from big companies who are staking their reputations on them. They want nice, thorough docs for everything, almost all bugs worked out, and lots of easy to use tools. Android lies in a middle ground somewhere between these two camps, which I think at times makes people uneasy. It's not open source yet. You can't hack it as much as you may want. You can't rebuild it from the ground up. You don't get access to the communication between the developers working on it, and cannot participate in that development. However, there is a promise to open source it that would reflect very, very poorly on Google were it not met and is therefore pretty credible. The developers and many people involved with it certainly seem to "get" open source, and are taking good steps to create a community around Android (a few even hang out in the #android IRC channel on Freenode) that will most likely not take too long to start assimilating interested outsiders once the code is open. In terms of quality, it wasn't bad when it came out, but it was very definitely an "early look", put out there to solicit feedback and change according to it, something that's part and parcel of a release early, release often open source model. On the other side, Android looks to be a big effort from a big company to get into a big market in a big way - it's not a "under the radar" type of strategy that the open source world is often constrained to follow for lack of monetary and marketing resources to do it any other way. This has attracted a number of developers who either don't see or don't really get some of the "open source" aspects of what we have so far: it's still changing! The docs aren't complete! The emulator is still ugly in places! And from their point of view, it must seem odd to getting something that's obviously not a finished product, without crystal clear direction and goals and a roadmap, and without actual hardware only available in the distant (well, in internet terms! - 8 months or so) future. That kind of thing probably isn't done very often in their world, or where it's done, is certainly kept quieter and perhaps restricted to registered developers. They came over to have a look at something that was ready to go, and it isn't, yet. This has caused some disappointment for people who expected to see something ready to go out of the box. Perhaps Google needed to manage their initial communications slightly better in order to manage the second group's expectations more carefully. In terms of us open source folks, I think that what we want is more access, as soon as Google is willing to hand it out. More source code access, but also access to the development process and people. "Real" open source isn't just about the code, it's about being more or less equal participants in a community. Luckily, I think the people at Google get this, which is one of the reasons I'm enthusiastic about Android, even if I wish we didn't have to wait so long for the source code.

Recently, as part of the many antitrust/anti-competition legal actions they’re suffering under, Microsoft released specifications for the old Office binary file formats. As expected, they’re big and complex. Joel Spolsky (a former member of the Excel team) had some thoughts on their size and complexity:

With a little bit of digging, I ll show you how those file formats got so unbelievably complicated, why it doesn t reflect bad programming on Microsoft s part, and what you can do to work around it.

The digging turns up reasons that make some sense: the limitations of older computers, feature creep, a complete lack of attention to the future. But it’s hard to see some of these reasons as “why it doesn’t reflect bad programming on Microsoft’s part”. Carelessness is common, sure, but we don’t call it a virtue because everybody does it. And these are problems that should have been on someone’s radar at Microsoft. It’s one thing for a grunt programmer to hack a feature to meet a deadline; it’s another for the management to simply go along with it, or to not order a rethink when the problems come to light. When you read about hacks like the following, everything sounds nice and reasonable, until you remember what the end result is: that Microsoft Excel doesn’t have a standard format for storing and manipulating dates!

There are two kinds of Excel worksheets: those where the epoch for dates is 1/1/1900 (with a leap-year bug deliberately created for 1-2-3 compatibility that is too boring to describe here), and those where the epoch for dates is 1/1/1904. Excel supports both because the first version of Excel, for the Mac, just used that operating system s epoch because that was easy, but Excel for Windows had to be able to import 1-2-3 files, which used 1/1/1900 for the epoch. It s enough to bring you to tears. At no point in history did a programmer ever not do the right thing, but there you have it.

It may not have been the wrong decision, in the sense that it enabled them to ship, and shipping is everything in some circles. But as a design decision, how can anyone defend such inconsistency? Business information technology was able to move forward in the early ’90s because older document formats like 1-2-3 and WordPerfect were simple enough to import easily into Microsoft Office. Today, when we talk about moving to open-source suites like OpenOffice or online systems like Google Docs, detractors left and right cite the pain of document conversion as a reason to hold back. But if Joel is right about the old binary formats, the pain of transition is like the pain of changing your oil: you can pay now, or you can pay a lot more later. Even Microsoft is having trouble opening its own files from long ago, with “long ago” being a period measured in years, not decades. Maybe you didn’t write anything a decade ago you’d care to read again today; maybe you can’t imagine any of your stuff being worth reading a decade from now. Do you want to take that chance? Thankfully, I was a geek, and kept most of my documents in plain text. Today, I take care to save important documents in formats and encodings designed for the long haul, like Unicode, ODF, and PDF. It helps that I avoid Microsoft software like the plague. (If you think they’ve changed since the bad old days, just surf the web in Firefox on Linux sometime, and see how many badly-rendered pages look much better when you switch their text encoding from Unicode to “Windows-1252″.) If you have a lot of Office documents, even if you’re happy with Office, you might consider whether you care about opening those documents ten years from now, and whether you’d rather take the time to future-proof them while you still can.

Since I've moved to Castlerock I've started using my DG834G to provide my ADSL again, as it was quick to setup and easily found in all the boxes. Up until now I've just been using it with the normal Netgear firmware, but I'm getting to the point where enough of the rest of the house is sorted that I want to think about the network layout. Part of that is enabling IPv6 (I'm with an Entanet reseller these days, and Enta claim to do IPv6), part of it is not bridging the wireless and wired networks (I'd like to be able to trust the wired one a bit more) and part of it is just being able to run useful bits on the router itself. Anyway. I had built up an OpenWRT SVN image last month and tonight I decided was the time to try it, having been putting it off for ages. Epic fail. Managed to get the backup of the Netgear image done fine, eventually got the new image on there, waited and waited and no joy. Wouldn't even ping on the LAN side. Further investigation showed that it would ping for a few seconds when first power cycled and then die. So I had to find my serial console level shifter so I could have a look. All signs point to it failing when loading the wireless or ADSL firmware blobs. Bah. I spent a while trying to get the old firmware back on it; ADAM2 seems really unhappy if it receives unexpected traffic (like, say, DNS requests because my network thinks the router is the DNS server/gateway) while you're ftping an MTD image. I got there, but decided I'd try out my WGT634U setup again, which is what I used in Norwich. Found the frog, fired up the router, changed my old Black Cat details to the new Enta ones and crossed my fingers. At first all appeared well (well, except for no IPv6 PPP; must email Enta to see if they need to tweak settings at their end for my username), but after a while it became apparent that the ADSL connection was flakey; it was resyncing every couple of minutes. Bum. It might just be the frog; I do have another one somewhere, but I ended up just falling back to the DG834G with the stock Netgear firmware ie exactly where I started this evening. I've pulled latest OpenWRT SVN and I see a few kernel/VLYNQ patches regarding AR7, so I shall try another build and see what happens. Epic fail. I shouldn't play with networking on a school night.