I was recently checking to see what, if any follow-up there had been from Sun’s ham-handed handling of the Open Solaris Trademark, and I ran across this very interesting comment from Jon Plocher’s Candidate Statement for the Open Solaris Governing Board:

“I also think there was a misunderstanding about what Sun desired when it launched the community (in part) to encourage developers to adopt and use Solaris. My take is that, while there *is* value in getting more kernel, driver and utility developers contributing to and porting the (open) Solaris operating system, there is significantly *more* value in having a whole undivided ecosystem based on a compatible set of distributions, where application developers, university students, custom distro builders and users are all able to take advantage of each other’s work. Put these two things together, and you can see Sun’s predicament. Sun *wanted* a community that empowered application developers, but *got* a community aimed squarely at kernel hackers. Whether you see this as the “kernel.org -vs- Ubuntu” fight, or the “fully open -vs- MySQL model” argument, in my opinion, it all is simply a reflection of the above mismatched expectations.”

So that explains why it’s take three long years to try to get basic open source development tools (such as putting Open Solaris source code in a distributed SCM located outside of the Sun firewall) for Open Solaris. It was never was Sun’s intention to try to promote a kernel engineering community, or at least, it was certainly not a high priority for them to do so. This can be shown by the fact that as of this writing they still are using the incredibly clunky requester/sponsor system for getting patches into Solaris; setting up a git or mercurial server is not rocket science. This lack explains why Linus gets more contributions while brushing his teeth than Open Solaris gets in a week. So if you run into a Sun salescritter or a Sun CEO claiming that OpenSolaris is just like Linux, it’s not. Fundamentally, Open Solaris has been released under a Open Source license, but it is not an Open Source development community. Maybe it will be someday, as some Sun executives have claimed, but it’s definitely not a priority by Sun; if it was, it would have been done before now. And why not? After all, they are getting all of the marketing benefit of claiming that Solaris is “just like Linux”, without having to deal with any of the messy costs of working with an outside community. As a tactical measure, astroturfing is certainly a valid marketing trick. But after three years, the excuse of “just you wait a little longer, we’re just trying to figure this open source community stuff out”, is starting to wear a little thin. Furthermore, if (as Jon Ploncher claims) this was about “empowering application programmers”, why was it that Sun’s first act was to trumpet how wonderful it was to release the Solaris source code under a Open Source license? This only seems to make sense if the Open Solaris initiative was really a cynical marketing tactic to try to save Solaris from being viewed as irrelevant. If that was Sun’s intention, I think it is fair to say that from a marketing point of view, the tactic has been at least partially successful — although as Jon has admitted, the goal of creating a full community with application developers, university students, and so on, hasn’t materialized for Open Solaris. Sun has the dream; the Linux community is living it. However, from business standpoint, I wonder if Sun will really be able to sustain their Solaris engineering team if they will really be doing all of the work themselves, and outside contributions continue at the rate of 0.6 patches per day. After all, the margins when you are selling low-cost AMD servers are much lower than when you are selling ber-expensive SPARC servers. With Linux, we have a major advantage in that kernel improvements are coming from multiple companies in the ecosystem, instead of being paid for by a single company. And given that 70-80% of Sun’s AMD servers are running Linux, not Solaris, it’s not clear how Sun justifies their Solaris engineering costs to their shareholders. Furthermore, if Solaris on x86_64 were to actually take off, there’s nothing to stop competitors from selling Solaris support — except the competitors won’t have to pay the engineering costs to maintain and improve Solaris, so they would be able to provide the support much more cheaply than Sun could. So while Sun’s marketing tactics have kept Solaris alive in some verticals, I have to question how successful Sun will be in the long-term.

Section 5.7.2 of the ACPI specification provides for a method called _OSI. Platform firmware can query for various interfaces, which allow it to tweak its behaviour depending on the interfaces that the OS supports. Linux claims to support the following interfaces:

• Windows 2000
  
• Windows 2001
  
• Windows 2001 SP1
  
• Windows 2001 SP2
  
• Windows 2001.1
  
• Windows 2001.1 SP1
  
• Windows 2006

which all correspond (unsurprisingly) to different versions of Windows. Linux used to be in there, but was removed for reasons I'll get into later.

The typical way in which this feature is used by a platform is by querying each of the interfaces in turn, starting with the most recent a firmware is aware of. After the first match, a value will be stashed somewhere and used elsewhere in the firmware when making certain decisions. An example of this may be only enabling certain devices (such as the HPET) if the OS claims to support Windows Vista.

As I mentioned, recent versions of Linux no longer claim to support the Linux interface. There's a couple of reasons for this. Firstly, some platforms break if they're told that they're running on Linux. It's usually an entirely untested codepath. Secondly, the whole point of the _OSI method is to provide the platform with information about the interface supported by an OS. "Linux" is too coarse grained - we make no guarantees that the interface between the OS and the platform will remain constant. "Linux 2.6.25" isn't all that much better, since distribution patches may alter the behaviour and BIOSes would become specific to a given kernel version. We could have something like "Linux ABI 1" and then bump that every time we altered the behaviour of the kernel in this respect, but this would become unwieldy fairly quickly (what would count as an ABI breaking change?)

So what kind of interface can we claim to provide? The sad truth of the matter is that most vendors will only test their code against Windows, and that as a result Windows provides the de-facto specification for OS/platform interaction. We could skip claiming to be Windows, but (in the best case) that means that the system will assume it's working with an OS that supports no advanced features. Rather than getting support for brightness changes being handled by the OS, we get stuck with SMM traps and unexpectedly missing time. If we want hardware to work to its full potential, we need to claim to be a recent version of Windows.

Does this mean the entire _OSI mechanism is useless? Not really. It's still useful for providing information about supported functionality. One example used in the spec is whether or not the OS implements the ACPI 3.0 thermal model. Another obvious (but unspecced) example might be whether or not the video opregion spec is implemented in the OS. _OSI strings which explicitly advertise the existence of advanced functionality are something that should be specified and encouraged. What they shouldn't be used for is as a way of advertising lacking functionality, which is effectively the only way that Linux can be usefully interpreted today. We don't want machines to automatically repost their video if they detect they're running Linux. It makes it harder to implement proper kernel-level graphics resume code. We don't want them to suddenly alter their keyboard behaviour, because that probably makes it harder to support older machines that don't have these workarounds.

Message to vendors: If we're not behaving in the same way as Windows does, let us know. We'll fix it. This has the benefit of fixing not only your latest and greatest platform, but also all the older ones that expected the same behaviour. Please don't try to work around our bugs in your BIOS - it just means that we need to special case you forever, and in the long run your hardware won't work as well as it would if we just fixed things properly.

We've received another of the last minute slots (thanks to those organizations which returned some of their assigned slots) to a total of 13 this year.We have received some very good application, and we'll be able to fill these 13 slots easily with very good applications working on a variety of topics.The results will be published on Monday, since there may still be minor changes in which students are accepted or who didn't make it to the top slots.Google Summer of Code 2008

I spent the entire week at the SambaXP conference in G ttingen, Germany. The conference is the annual conference of the community of developers, contributors and users of Samba. I general call it "my annual german pilgrimage" as I attended all seven editions of the conference, the only FLOSS conference I attend on my work time, as my daily work involves quite a lot of uses of samba. This year featured a workshop or training session held by John Terpstra, longstanding FLOSS evangelist and member of the Samba Team for over 10 years, and Karolin Seeger, the brand new release manager of Samba. This has indeed been an incredible opportunity to have discussions with them about the packaging work for Samba. Actually, the work we did in the last 3 years to bring Samba Debian packages in a very good shape (when I don't screw up) is much appreciated. I think these days have been another opportunity to keep that link very closed. I have been impressed by the promising work of Karolin with respect to the preparation of the release and the very serious way she has to do that work....as well as her very friendly, while still discreet approach to technical discussion. Some work was done on Samba package bugs, though less than usually (the remaining ones are harder and harder to tackle!). I mostly work on Debian packages as well as .deb packages prepared by Sernet (the services company that organises the conference and employer of some Samba Team members), as these could some day become the packages provided by the Samba Team. Talks at the conference were pretty interesting, to keep connected with Samba 3.2 and 4.0 development. News from Andrew Tridgell about exchanges with Microsoft (yes, The Evil) and access to MS documentation, are very promising. The collaboration between Samba developers and Microsoft enginneers is now working well again, at the engineers level (as Tridge says: "lawyers are away, now, we can talk at the engineers level and restore the link that existed in the early 90's"). I also could measure the progress of the Openchange project whose ultimate aim is to provide a complete Microsoft Exchange replacement solution. They currently have working MAPI libraries and an Evolution plugin for Exchange is under development, while the bricks to build a server are patiently being put together. Good discussions with Julien Kerihuel, the lead (and French) developer and manager of the project. Jelmer Vernooij and I also settled the final plans to get Samba4 packages in Debian. I proposed to make a first upload to experimental, but quite soon to upload to unstable, the point being a largest as possible exposure of that code, so that upstream developers (Jelmer himself, Andrew Bartlett and a few others...) get as much feedback as possible. That upload will not be targeted for lenny (we'll block it from entering testing). For that reason and also because Samba 3 and 4 will certainly coexist for years, the source package will be named "samba4". Expect more news quite soon. And final conclusion of that week: I've also been delighted to be able to visit Alex and Meike in Hildesheim, as well as Andreas in Wernigerode. It's always a great pleasure to see longstanding Debian friends. At the beginning of the week, I planned to see *two DD and finally, at the end of the week, I can tell I've seen *three* Debian developers, finally!

Rick Falkvinge (leader of the Swedish Pirate Party) has written his predictions about an economic crash in the US [1]. Predicting that the US economy will crash is no great stretch, it’s gross failures seem obvious. The Pirate Party [2] is a one-issue political party that is based on reform of intellectual property laws. It derived it’s name from the term Software Piracy [3] which originally referred to using software without paying for it, but in recent times has been broadened in scope to cover doing anything that copyright holders don’t like. The term “Piracy” is deprecated in the free software community based on the fact that it’s unreasonable to compare armed robbery and murder on the high seas (which still happens today and costs between $US13,000,000,000 and $US16,000,000,000 per year [4]) with copying some files without permission. But that battle has been conclusively lost, so it seems that the mis-use of the term “Piracy” will continue. The majority of the acts which are considered to be “Piracy” are well accepted by the community, the acts of the music industry in taking legal action against young children have only drawn more public support for the “Pirate” cause. Such support is increasing the changes of the Swedish Pirate Party getting a seat in parliament at the next election, and has caused the major Swedish parties to change their positions on IP legislation. Now Rick’s background related to Intellectual Property issues causes him to analyse the IP aspects of the current US problems. His claim is that the US economy was trashed during the Vietnam war, has been getting worse ever since, and that the US position on IP legislation is either intentionally or accidentally helping to finance the US while it’s production of useful things is steadily decreasing. He also claims that some multi-national financial customs (such as using the US dollar for the international oil trade) is propping up the US currency and effectively allowing the US government (and the US residents) to borrow money from the rest of the world. Dmitry Orlov’s presentation titled “Closing the ‘Collapse Gap’: the USSR was better prepared for collapse than the US” [5] provides some interesting information on what happens during an economic collapse. He also has some specific advice on what can be done (by both governments and individuals) to prepare for an impending collapse. However he doesn’t mention some issues which are important to people like us (although not as important as food, water, and shelter). On my document blog I’ve got a post with some ideas of how to run an Internet Infrastructure after a medium-scale collapse of the economy as we know it [6].

• [1] http://www.falkvinge.com/2008/03/why-us-is-collapsing.html


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


• [3] http://en.wikipedia.org/wiki/Software_piracy


• [4] http://en.wikipedia.org/wiki/Pirate


• [5] http://www.energybulletin.net/23259.html


• [6] http://doc.coker.com.au/internet/running-net-after-collapse/

Share This

Some come, others kind of go.

I warmly welcome the new 19 developers (great female ratio there!) and humbly ask the rest of us to support the new blood carriers. If they made it through this, they are surely worthy of our cause and will probably accomplish a lot more if us, the old farts, make it easier for the ones to come in the future.

Where do I join the Debian elderly club?

One thing that's been bothering me since quite a while is the fact that apt and friends are not very verbose when things go wrong. Usually that's just fine; if a package can't be installed, there isn't much you can do about it anyway. However, for those of us who have to maintain buildd machines, a message like the following is not very helpful:

ome packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
  kdelibs4-dev: Depends: kdelibs4c2a (= 4:3.5.9.dfsg.1-2) but it is not going tobe installed
                Depends: libarts1-dev (>= 1.5.0) but it is not going to be installed
                Depends: libavahi-qt3-dev (>= 0.4) but it is not going to be installed
                Depends: libopenexr-dev (>= 1.2.2-3) but it is not going to be installed
                Depends: libqt3-mt-dev (>= 3:3.3.5) but it is not going to be installed
E: Broken packages

If you're not convinced, let me tell you that the culprit is libopenexr2ldbl. If you've noticed that libopenexr2 is not mentioned anywhere in the above output, you understand why I hate this. Usually, figuring out this stuff requires you to manually walk the dependency tree, which is silly. So today, I finally spent some time to sit down and write a couple of perl scripts to help me with that:

wouter@country:~/code/perl$ ./cache-packages Packages 
Reading data... done (20492 packages). Closing cache... ready. Have a nice day!
wouter@country:~/code/perl$ ./check-dep-waits 
kdelibs4-dev
checking dependencies of kdelibs4-dev
 checking dependencies of kdelibs4c2a (= 4:3.5.9.dfsg.1-2)
   checking dependencies of kdelibs-data (>> 4:3.5.9.dfsg.1)

[... copious output snipped ...]

  checking dependencies of  libopenexr2ldbl (>= 1.2.2)
libopenexr2ldbl is not available in any version

So, there. Obviously the "Packages" file in the first command line above came from a Debian mirror. The "cache-packages" script writes a file "~/.packages-dbm", which contains an MLDBM tiehash of all the packages, indexed on package name. If you have no clue what that means, just remember that it parses the Packages file into something my laptop can load in a split-second rather than requiring 45 seconds to open and parse the Packages file. Once you've ran that, you can call 'check-dep-waits' as many times as you want, that is, until the Packages file is outdated and you need to download a new one. The second command will just sit and wait. On the first line, you give it a piece of Depends: information, and it will parse that and see whether the dependency can be resolved. There's a lot of output; but given how I want to verify dependencies, I thought I'd rather have too much than too little information. If there are version numbers involved, this script will call dpkg --compare-versions to do the actual verification, so I don't have to watch policy for any possible changes, which is helpful; but it does mean that it'll only work on a Debian machine. The code is available for download at http://comp.uter.be/perl-Packages, FTWCA buildds. Update: While on the train, I realized that I'd totally forgotten about virtual packages. That's now been fixed; if you downloaded the code before, you may want to re-fetch it...

Is this traffic or congestion? This is one of those Friday Afternoon Projects - it's been put off all through a busy week because it's unpaid, I'm not completely sure how to approach it and now my arms hurt like hell from travel jabs which are making it hard to concentrate! So I'm going to float it on here... I've been asked to brief a meeting next week about that group's current web site and its problems. I'm not linking it yet to avoid insulting/embarrassing them. The site looks OK, but doesn't rank well on search engines and doesn't allow much member participation. I need to explain why that's a bad thing and how the site's technical choices have led to that. I'm not directly pitching for TTLLP to get any work (because I'm a member of that group, it might be a conflict of interest and we're pretty busy anyway - even our own site needs work on some of the points I'm going to mention), but I don't want to be unhappy if we're asked to implement my recommendations. I've got a usual outline that I follow, but my presentation's time is limited, so I'd like to ask you: what about this is important and what isn't? If you give me useful feedback, I'll put you in the Acknowledgements with a backlink and I hope the briefing will be shared pretty widely over the next few months. The current plan is to start with a basic explanation of how search engines rank pages, as far as we can tell, referring to PageRank Explained Correctly with Examples, by Ian Rogers as well as the shorter official summaries from the dominant search sites at Yahoo, Microsoft and Google. Then I go through a quick evaluation of the site against the basics of validation, accessibility and robot-friendliness, followed by a couple of SEO-style checks of its current rankings and inbound links. Next is a bit different because I have access to some of their web access stats: I summarise what we know and suggest some other stats they've probably not considered and why they're useful, along the lines of Dave Briggs's measures of blog success. Finally, I suggest ways to improve the site. The top tip will be to take control of the site hosting and stop using the cheap and cheerful donated server that makes all links except the front page point to another domain. I'll probably suggest a mix of free and open source software tools to power it. If they don't want to move it all yet, I'll suggest running a second site for member participation, using tools like Wordpress, NoseRub and so on. What do you think? Plan for success, am I missing some tricks, or am I setting myself up for a lynching? Let me know with a comment or email, please.

Last night I thought of a few gadgets which I’d like to have, and although I’m pretty sure you should be able to get hold of them, I had trouble finding anything that looked quite right:

• Alarm clock which makes coffee: I can’t be the only one who finds it hard to bootstrap my days because I have to get out of bed and make the first coffee of the day before I’ve had any coffee. My parents had a machine which was an alarm clock which made tea (very noisily) at the appropriate time in the morning. Surely there should be a similar device which can display the time and make (at least passable) coffee instead? Be it an alarm clock with a sideline in making coffee, or a coffee machine with a built in timer. I’ve noticed some of Gaggia’s bean-to-cup machines claim to have 24-hour clocks, but does that mean they have a timer function? We just don’t know.
• Decent watch with USB storage: I found some watches online last night which had USB storage built in, some with a little USB connector that folded out, some with a mini/micro USB connector on the side, with the idea I could store (maybe parts of) my GPG and SSH keys on it, and maybe a bootable Debian installer/rescue system. The thing is, I have a reasonably nice Timex Expedition watch at the moment which I quite like: it has an electro-luminescent analog display for the middle of the night, and a digital bit for the date, alarms and multiple time-zones. The USB-enabled watches I saw didn’t look that great as watches, but I might be wrong. Does anyone have a watch that features USB storage that doesn’t compromise too much on the watch functionality? Maybe I should just give up on this one and go for the rugged USB stick on the keyring approach.
• Video output over USB: I have a reasonably new HP 2510P laptop which I also use as my main machine at work with a docking station, TFT, keyboard, mouse, etc. However, as a machine for watching DVDs or other videos on at home, it’s a bit on the small side. I have an olde-worlde big flatscreen TV at home (which is not as good as Christian’s flat-screen blueray surround sound movie set-up, but I think I retain the moral high ground on taste in films), but my laptop doesn’t have any video out. Is there a USB 2.0 widget which produces composite or S-Video output which I can feed to my TV, that will work with Linux, or should I just get a scan converter of some sort so I can use the VGA output?

So, answers on a postcard…

nion argues about the new Dilbert.com website now using flash instead of GIFs. Well, he hasn’t looked right: Dilbert.com offers now flash and static images. And the last ones are now much easier than ever to view or fetch, because Dilbert.com now has RSS feeds. Ok, at the moment, the feed seems broken respectively empty, but I have the last week of Dilbert comics in my feed reader. In colour! Additionally Dilbert.com is opening its archive. (The link to the blog post currently broken, too.) Back to 2001 is said to be available now, the reminder is in the works The new Dilbert.com site worked fine yesterday but seems to have some problems today. But I expect that they will fix that soon. :-) Noticed it btw. because the inofficial Dilbert feed from tapestry included a broken image yesterday. (Works fine now, but no new comic in that feed today…)

I've been on holidays for one week now, breaking my usual workflow. Well, that allowed me to rest and to think about what I'd like to do and things I need to handle during next weeks. The urgent things this next days will be my primary server replacement. It is currently dying, and I already had to change its power supply twice in a month. Unfortunately, I'm now at a point where I do not have any spare piece so if things go wrong again, I'm screwed. I need to collect some money and buy a new server, or maybe get a server if someone have an old or spare one to give me, I do not know yet. On the awesome front, I'm about to release awesome 2.3, which will be the final minor release of the major branch 2. This will lead me to work on awesome 3 at a slower rate and a cooler pace. Then, the thing I do not have to hurry for is awesome 3. There's no big problems in awesome 2, and the xcb-util stuff are not stabilized yet. After my gentle yelling on XCB mailing list, it seems that things will move but will slowly. So I do have time to make things right and do what I want on that branch, making bugfix release on awesome 2 if needed. You can read more about futur on my last post about awesome. All this should give me some more spare time to work on the upcoming Debian release, lenny, which I'd like to work on. Two years ago (my god, time flies), we've done good work with the french cabal squashing critical bugs and I'd like to go back on this and squash asses again.

Wouter points out a mistake in one of my blog posts which was based on old data [1]. My original post was accurate for older distributions of Linux but since then the bug in question was fixed. Normally when writing blog posts or email I do a quick test before committing the text to avoid making mistakes (it’s easy to mis-remember things). However in this case the bug would dead-lock machines which made me hesitant to test it (I didn’t have a machine that I wanted to dead-lock). There are two lessons to be learned from this. The most obvious is to test things thoroughly before writing about them (and have test machines available so that tests which cause service interruption or data loss can be performed). The next lesson is that when implementing software you should try not to have limitations that will affect user habits in a bad way. In the case of LVM, if the tool lvetend had displayed a message such as “Resizing the root LV would dead-lock the system, until locking is fixed such requests will be rejected - please boot from a rescue disk to perform this operation” then I would have performed a test before writing the blog post (as it would be a harmless test to perform). Also on occasion when I really wanted to resize a root device without a reboot I would have attempted the command in the hope that LVM had been fixed. A bug that deadlocks a system is one that will really have an adverse affect on users, both their habits in future use, and the probability of them using the software in future. A bug (or missing feature) that displays a warning message will have much less of a problem. From now on I will still be hesitant in using lvextend on a LV for a root filesystem on any machines other than the very latest for fear that they will break. The fact that lvextend will sometimes work on the root filesystem and sometimes put the machine offline is a serious problem that impacts my use of that feature. Most people won’t be in a position to have a bug or missing feature that deadlocks a system, but there are an infinite number of ways that software can potentially interrupt service or destroy data. Having software fail in a soft way such that data is not lost is a significant benefit for users and an incentive to use such software. I’ve put this post in the WTF category, because having a dead-lock bug in a very obvious use-case of commonly used software really makes me say WTF.

• [1] http://www.grep.be/blog/en/computer/cluebat/actually_you_can

Share This

I have never seem so many people at fisl. Seriously! All the rooms were crowded, all the time same as the expo and the user-group area. Our official counter were stopped at 6667 participants, but that is just because we ve taken the registration database off-line in order to process new registrations on-site. By the end of fisl all the numbers will be summed up, but I heard rumors of 7 thousand people! Awesome! I spent this first day mostly in the TVSL room. We ve had problems with the network all day long. PUCRS technicians and our link providers personnel were trying to figure out where the problem seems to be. Being stuck with a non-functioning stuff, to me this day was mostly a sequence of frustrating attempts to get over the blockage. By the end of the day I was told that they were close to a solution It reminded me of our second year trying to stream fisl, as was best told by Fluendo s Thomas ... This just leads me to an unavoidable conclusion: our network sucks! I had to hear from a Brazilian friend who lives in Europe how wonderful her Gigabit network is grrrrrrr Bored as I was, I went walking around. That, surely, were the best part of fisl so far: meeting old friends. I had the most pleasant chat (yet quick) with Otavio Salvador and Felipe van de Wiel, both friends of long time. I took some pictures of the crowd: And, since I was not available in the morning, when the huge crowd was arriving, I took a picture of a picture taken by Marlon of this initial moments: (It is not really clear in this picture, but beyond the red gates there were as many people as inside)

A few months ago, I had shown a chart with per-5k-segment paces of my prior marathons runs (or at least those for which organisers had 5k splits). Since then, I ran two more: New York in November and London last Sunday. I have updated the charts to show both of these: A few things stand out:

• New York (in orange with small squares) clearly was my steadiest run, with very little variation and that nice burst at the end where the pace dropped below 7min/mile for the finish;
• London (in yellow with open circles) was allright, but with a noticeable drop around kilometers 30, 35 and 40 -- but then the second-best finish.
• I really cannot pace myself at the start: The two most recent races had the fastest start, including the hot and humid Chicago 2007 marathon (in light blue with circles)

In case anybody is interested (C'est bien toi, Christian, non?), the R script is available and I will be taking questions by email as R may not be obvious at first if you haven't used it.

For the second year in a row, I didn't vote in the DPL election. Not because I have lost interest in Debian affairs but because nothing is really going on that demands my attention. All three of the candidates who ran this year were eminently capable of representing of Debian and its ideals, all three had more or less the same vision for the role of DPL (IMO. See here for platforms,) and all three are, as far as I know, nice people. Organizational and social problems that previously existed have been fixed. The only problem I have with Debian these days is a lack of time but I can hardly expect the DPL to do anything about that. However, a recent post from Lucas reminded me that there is one group for which all is not fine and dandy. Given that this is the same complaint that has been made for atleast five years nows, one has to wonder why it remains singularly unfixable? Well I don't know but this delegation makes me confident that we will finally see the end of this last bottleneck too. Joerg is the one who sped up NEW package processing and I am sure he will have account creation humming along in no time. I sympathize with the frustration people stuck in NM feel, but I would like to remind them that Debian acts the way Winston Churchill observed the United States does:

"Americans can always be depended upon to do the right thing—after they've tried everything else."

I’ve just read an interesting post on TomsHardware.com about a solar powered PC [1]. It describes all the steps involved in creating a modern high-performance low-power computer. They have a lot of interesting information. One surprising fact (from page 3) is that the PSUs tested (both for AC and DC input) were more efficient when idle (I expected the greatest efficiency to be when under load). An AMD processor was chosen due in large part to the fact that chipsets in suitable motherboards used less power. For the CPU itself Intel had a competitive offering but no matching motherboard was power efficient enough (from page 7). Page 8 documents how using a cooling fan (instead of passive cooling) reduced the power requirements of the CPU to such a degree that it always saved power use overall. Why do CPUs take less power when they are cooler? Page 9 mentions that a small passively cooled video card can draw 88.5W when idle! That sucks pretty badly, it seems that having a video controller integrated with the motherboard is the way to go if you want to save power. It’s interesting to note how much energy can be used by RAM. Page 13 shows that the difference between 2*1G and 2*512M can be as much as 3.4W and that the difference between different brands of RAM for the 2*1G can make as much as 1.2W difference. Their final system drew 61W when idle, my latest 64bit system takes 52W when idle [2] (which compares to the 38W of their system without a monitor), so we are talking about 9% of system power being saved by using less RAM or 3% being saved by using a different brand of RAM. The summary of hard drive power use on page 14 is interesting, the fact that 2.5 inch laptop disks use less power than 3.5 inch desktop disks is hardly surprising, but the difference when idle is very surprising (apparently one of the 3.5 inch disks spends 8W on turbulence and friction in the bearings). It’s unfortunate that they didn’t compare any of the server-class 2.5 inch disks, it was about 6 months before the article was written that HP announced that in future they would cease shipping 3.5 inch disks and only use 2.5 inch disks (I wonder if this is related to all HP’s recent work on server cooling). Rumor has it that many server class 3.5 inch disks have platters that would fit into a 2.5 inch case because at high rotational speeds a larger diameter platter would not be strong enough. The information on DVD power use on page 15 is quite shocking. From now on when I install machines as servers which don’t have a need for for a CD-ROM drive I’ll remove the drive prior to deployment. Even if it saves only 0.47W then it’s still worth doing on a machine which uses less than 40W! An additional benefit of this is that it might speed up the boot process as the system won’t need to check for a bootable CD. It’s unfortunate that most computer parts don’t have published documentation on how much power they draw. Even if you don’t want to run on solar power there are still significant benefits to saving electricity (including reducing the noise from cooling fans and heat problems in summer). If technical data was published then people could make informed decisions about which parts to buy. Update: Changed the percentage savings for different types of RAM to be based on the system power use without the monitor. I’m most interested in saving power for servers and for idle desktops (running a desktop machine 24*7 is pretty common) so most of the time the monitor will be turned off. It’s interesting to note that they power their system uses is about the same as a P3 system and could be less if they used a different hard drive.

• [1] http://www.tomshardware.com/2007/09/13/hardware_components/


• [2] http://doc.coker.com.au/environment/computer-power-use/

Share This

It's time for me to stop complaining about the commercialisation of SourceForge and vote with my code. I'm leaving for brighter, bluer pastures at Alioth.

Query Object Framework is first (libqof1). The others will follow. I'm leaving because of unusable mailing list archives, impossibly slow web pages and wiki and the general amount of work involved in the SF interface. I'm gaining sane mailing lists, a friendly and usable ikiwiki and a simpler (although very similar) interface.

I'm also migrating most of those packages to subversion. With so many other changes, it's not exactly a problem to add cvs2svn into the mix.

Now, of course, this does not mean that these upstream packages suddenly become Debian-only or Debian-native. It does mean that I have a chance of encouraging new developers to join the team by providing the kinds of services and support that people need when starting off with a new project. (I suppose the one thing I don't yet have is an IRC channel. Not sure if it is worthwhile but I'll see what happens.)

QOF will form the basis of the support available for each of the other projects - all will share the same low-volume QOF-devel mailing list and QOF Wiki as provided by Alioth. I'll also migrate QuickList because I'm looking at restarting development on a stalled project allied to QOF and which could provide missing functionality in QuickList. I did look at Gaby in this mix but a botched Gtk1->Gtk2 transition that ended up with two incompatible forks running different parts of the original codebase put me off completely (and neither of the forks actually worked). (Some packages deserve to be dead upstream.)

I'm looking for new blood, fresh faces and a new desire to take these projects forwards. The driving force is data freedom - creating data-driven applications that are completely agnostic to where and how the data happens to be stored. It is user data, it should be as free as the source code that wrote it. Who cares what format it is in? Let's get it into a format that some other program can use and make use of the existing data instead of duplicating it all the time. (The observant will note that my old haunt of GnuCash is stubbornly ignorant of the merits of a decent import/export implementation that actually covers more than 50% of the data in the application. No wonder I took the chance to sponsor homebank.)

DWI Data With Interaction (aka DUI -- Data Under the Interface) is what can provide the missing interfaces. It'll take a while to get it back up to date and available in Debian but it can provide the link between data and interfaces. GNU/Linux users should be able to design an interface purely on the basis of the data that it needs to handle and not care one jot about how that data comes from one free software app and goes on to the next free software app. QOF is gaining a connection to libgda which means that data can go to and fro between a whole range of databases and file formats. Homebank and pilot-qof can gain new data inputs (and possibly outputs) by utilising the existing import/export support in new ways via DWI/QOF (as libqof2). That can give a complete interface for all PIM and financial data for a typical SOHO user and all based on SQL-type queries so that every stage of the process can be tweaked and optimised according to user requirements at runtime.

(Where does Emdebian come into this? Well, many people like me need to record and process PIM/financial data on the move so Emdebian means that those users can have the same data processing on their handhelds as on the desktop. Smaller apps to capture the data quickly and efficiently whilst on the move; larger apps to refine, optimise and filter the data on the desktop entirely under user control but with a simple, scriptable, interface based on runtime queries so that the user can do exactly the same conversions tomorrow with new data but none of the configuration. Easy!)

Is this groupware ? No - it is personal, ultimately flexible and entirely customised for particular users by the users themselves. It's about small niche markets, about independent business people with bespoke and highly specialised requirements. No one is going to spend time writing their reports in Scheme or Haskell, because they are the only people who need that particular report. Instead, that individual user needs to be empowered through a simple and intuitive interface to take a piece of data from one source, correlate it with a static piece of data from individual configuration sources, calculate a result according to a third piece of data from a completely separate source and combine them all into a new set of objects that can be used in other queries. It's about preparing invoices from Palm data, it's about handling customer accounts for a one-man company or handling a stocks and shares portfolio for a partnership. Ultimately customised, ultimately flexible and completely format-agnostic.

These are the kind of applications that hold people back from GNU/Linux migrations - bespoke applications that are developed for just a few small companies or just a few situations. Free software finds it hard to provide those apps because free software depends (currently) on someone else being motivated to write a bespoke program and that person rarely understands the niche. This is a chance to put the development into the hands of those with the motivation to do the work, by making the development process more WYSIWYG.

The question is: Can we come up with a better name for DWI, dear lazyweb?

"DWI is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade."
http://dwi.sourceforge.net/

The big appeal is that DWI is database-agnostic - it only cares about the data structure, not the file format. Ally that with QOF which provides data-centric SQL-based queries and conversions between objects (including combining elements from one object into one or more other objects without having to hardcode the connection between the objects at compile time) and we have an interesting and powerful combination of engines, frontends and backends that are all data-centric.

Please, if this sparks your interest, join the QOF-devel mailing list, have a play with the ikiwiki at http://qof.alioth.debian.org/ and have a go with the code. This whole area is begging for development but it is just so far from being usable by the target audience at this stage. There is a lot of programming to be done by current developers before the principles can be let loose on the masses.


This is about working between existing projects and between distributions - no longer dedicated to a single application, platform or file format, no more tunnel vision. Work on the edges of existing applications (and indeed projects), remove the sharp edges of applications that should work together but can't. The majority of the code in these libraries and applications is already stable and mature. Like so many parts of free software, it is time, IMHO, to put aside our egotistical devotion to the one-true-executable and come up with an actual solution.

Bah! I'm beginning to sound like a PR exec instead of a dedicated geek. What does it take to motivate people and get things done around here?

This week I'm in Mountain View for the X Developers' Conference, where I gave a presentation on things graphics drivers have to care about in order to make suspend/resume work reliably. Various people suggested that I write up an explanation of the current situation, along with some best practices for manufacturers.

One of the major differences between the ACPI specification and the older APM specification is that saving and restoring hardware state is generally left up to the operating system, with the firmware playing a much more passive role. Linux is now able to handle this state restoration for the majority of hardware, but we still have issues with graphics. Modern graphics hardware can be hugely complicated, which to a large extent we've been able to ignore because the platform will initialise it on boot. Many X drivers know how to switch a card from text mode to graphics mode (and vice-versa), but that's not adequate.

What can make this situation even more awkward is that the ACPI specification makes no guarantees about what state the hardware comes up in. It may still be in PCI D3. It may be powered up, but the registers may all be zeroed. It's even valid for the hardware to come up in text mode. A driver has to be able to deal with all of these situations.

So far, we've mostly tried to deal with this situation by running chunks of the video BIOS with applications like vbetool. This is hacky and often works badly - in some cases, it won't work at all (nvidia rewrite the entry point to their video BIOS after boot, in order to prevent situations where someone attempts to POST the card and it tries to jump to bits of the system BIOS that no longer exist). The only long-term option is for the kernel to handle the graphics suspend/resume. There's several levels at which this can be supported:

• Able to restore text mode. This is basically adequate right now, since the kernel enforces a virtual terminal switch around suspend/resume.
  
• Able to restore arbitrary video mode. In the kernel modesetting world, we want to be able to go straight into the mode that we're running X in, in order to reduce screen flicker. This would probably still be surrounded with a VT switch out of and into X.
  
• Able to jump straight into X. Right now, on x86 the process freezer will prevent X from running until after all of the devices have been resumed. As we move to a model where we remove the freezer and expect drivers to be able to block userspace tasks, we hit a pretty obvious problem with X - right now it hits the graphics hardware directly, rather than going via the kernel. With nothing to block it, it'll hit the hardware while it's still in an undefined state and then become very unhappy. This can't really be fixed until X does all its hardware access through the kernel. For now, we can inhibit X by leaving the VT switching in place.

Since 2.6.25, i915 and later Intel hardware can manage basic mode reprogramming without requiring any external assistance. The radeon kernel modesetting code is also heading in this direction, and we ought to be able to manage something there before too long. The nouveau developers are heading towards the stage of being able to do native mode programming, so there's some hope of progress there as well.

It's not all plain sailing, though. Vendors can wire up hardware in different ways. AMD and Nvidia hardware provides scripts in the ROM that, in theory, abstract this away. The downside to this is that we'll have to put the interpreters for these scripts in kernel space, though this is probably needed for kernel modesetting work anyway. Even then, it's possible that we'll need workarounds for specific pieces of hardware that don't quite behave as we expect them to.

As far as making graphics work over suspend/resume, we have a pretty good idea where we are now (failing on anything other than modern Intel hardware), where we need to be in the future (triumph, huge success, cake) and how to get there (?). However, hardware manufacturers can still help.
Chipset vendors:Tell us how to reinitialise your hardware. If that involves parsing BIOS tables, then please let us know how to do that. Expecting us to jump into your ROM and execute x86 code is ok if that's genuinely the only way to do it, but for any modern hardware that's clearly not the case.
System vendors:Try not to alter your system behaviour too wildly. Requiring magic register writes in order to light up the VGA output does not classify as value add. Please don't have your firmware program text mode directly - we're trying to get away from that. And do not attempt to detect that you're running on Linux and alter your system behaviour. If it's possible for you to tell that you're not running on Windows, that's a bug in Linux. If you rely on that bug, you will break. I'm not joking here in the slightest. The closest thing to a "standard" interface between an OS and the hardware is whatever Windows does, and we're basically aiming for bug-for-bug compatibility there.

Readin Sam's announcement, I thought “finally!”. I am now, however, deeply disturbed by Joerg's reaction to his delegation. This way, I have a very strange impression on what's happening. Didn't Joerg know that Sam was going to delegate him? Of course, this is not legally relevant, but I do not feel that this is how it should happen. (Mark the difference: this is not about somebody being forced into a team that doesn't necessarily welcome the new member, but about the proposed new member being forced into a decision in this way.) On balance: please do it. The situation reminds me of the Debian kernel team when it changed from Herbert Xu to group maintainership, which now works quite nicely afaict. But obviously, there is no guarantee that things will work out nicely, and there might be serious friction as well. OTOH the new DPL publicly stating that he supports this decision should be a Good Thing™