Grisbi is now
available in Emdebian but without libofx. Similarly homebank is in Emdebian (note that homebank-data is also needed and is available), again without libofx.

I'm not convinced that libofx is that much of a loss on an embedded device - especially when libofx and dependencies could add 5Mb to an existing installation - just for the shared libraries!

The screenshots of Grisbi in Maemo gave my the idea of adding grisbi and I've been trying it out on the desktop too. Once I'd tweaked the column widths for the transaction window (hidden away in Preferences), it is quite usable - although I can't see any way of it handling invoices.

My own gpe-cash is not making much progress - the GnuCash objects are just too resistant to use outside GnuCash. It may be easier to create invoices from grisbi/homebank data via CSV and estron.

This is aimed at the more powerful end of Emdebian devices but each package is still 50% smaller in Emdebian than in Debian, closer to 80% smaller if you count the reduced dependencies. The main difference is the use of TDebs.

Christian Perrier and I are planning on working on TDebs during DebConf8 and Extremadura so that bugs and fixes to support TDebs can be implemented in Debian as soon as Lenny is released. Removing translations from the maintainer uploads and translation bugs from the package BTS should make it a lot easier to update translations without requiring an NMU of the entire package (which is complete overkill IMNSHO).

Together with DEB_BUILD_OPTIONS="nodocs" support, TDebs are the simplest way to reduce package sizes and installation sizes in Debian/Emdebian.

(I just wish #448615 could be fixed so that I could get on with preparing patches for packages that install docs without using debhelper.)

I’ve just released pommed v1.18, which is mainly a maintenance release. I’ve added some more USB IDs for Apple external keyboards and relaxed the event devices identification for internal keyboards. pommed will now happily start on a machine fitted with a keyboard+trackpad assembly that normally isn’t found on this model. This can happen when the topcase of the machine is replaced with the wrong part. I expect this situation will happen more and more often as people buy parts from EBay or similar to repair their laptops.

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large. The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education. To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk). Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull). Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work. On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible). The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to. If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages. I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way. With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down. The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation. Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts. The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too. So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before. Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really. The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed. The reason why I believe Linux is the better choice here is long-term support. Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of. The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable. To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did. The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.

You might remember that I wrote a blog entry about my switch to the green electric utility "Lichblick" (Germany) a while ago. I did that purely out of environmental reasons, I didn't want to continue to waste money on polluting and/or dangerous crap such as fossil or nuclear power. Yes, even if that meant a slightly higher price (but I really didn't compare prices much before switching — I was after an environmentally clean solution, not the cheapest solution). Quick status update: the switch went really nice and easy, no downtimes, no hassle. I've been a happy customer for more than 8 months now. Today in my snail mail inbox: a letter from Lichtblick that they're going to reduce the price per kWh from 20.25 to 19.99 (Euro) cents starting July 1st and they give you a guarantee that there won't be any price raises before the end of 2009 (more details also here). Now, that's a positive surprise there. Compare that to 98% of all other energy providers in Germany who have lately increased prices quite a lot for very obscure or non-existant reasons. Yes, I do realize that the reduced costs are not that dramatic, and Lichtblick is using this as a means to impress people and gain new customers. But I fully support them in doing so, the more people are switching to a green energy provider the better, if you ask me. I encourage everyone to consider switching, either to Lichtblick, or some of their competitors (in Germany) e.g. Greenpeace energy, Elektrizit tswerke Sch nau, or Naturstrom AG. There are various alternatives in other countries too, of course.

There are obviously some things we need to remind if we don t want something like the OpenSSL debacle to happen again. It doesn t mean we need to throw stones nor to rush into changing our processes without thinking. However, there are already some things that should be obvious but unfortunately are not.

1. Shipping a giant diff.gz that contains all changes in one, putting security fixes, policy fixes, bug fixes, cosmetic changes and autotools files at the same level, is not something we should accept anymore. Improvements in the dpkg-source format are much welcome in this direction, but they are useless if maintainers don t use them. Neither a VCS nor a build tool will be able to know which line of the changes is related to which bug. Only the maintainer can.
2. Core packages should all have co-maintainers. This is pretty much stating the obvious, and is much easier said than done. The OpenSSL case is one of the best examples here: Kurt is not one of those who refuses help, but frankly, would you want to maintain that package? Having already maintained packages with messy code, upstreams not understanding at all the needs of a distributor, avalanches of security alerts and randomly-changing ABIs, I can tell you this is no fun like it can be to hack on a desktop environment or a device driver. The only sane reason to do this is that you need the package to work. The only visible result you get from your work is that programs are not randomly crashing.
   I have no magic recipe to propose so that more people help with such packages, and that s where we need to be really innovative. Cross-distribution teams, mandatory co-maintainership on a core package for each DD these (and all ideas I have not heard of) are the experiments we should start now.
3. Patching bad code leads to unpredictable results. What maintainer of a complex package has not introduced a new bug while trying to fix another one? Even when a piece of code is maintained by uncooperative developers, is not commented, uses arcane variable names or is impossible to understand without having contributed 3 winning entries to the IOCCC, it needs to evolve. And in these cases, it is only a matter of time until such things happen.
   Don t get me wrong: I m not trying to put the blame on upstream here. They have contributed very valuable code to the community and their work helped in the considerable widespread of cryptography. It s just that their code is not enough for our needs. If we can t patch it safely (and I m now convinced we can t), maybe we need to focus on alternatives and help them getting used by crypto-related packages. The code in GnuTLS and NSS is not necessarily better, but most (if not all) patches Debian needs to apply to them are build and portability fixes.
4. Unless Debian-specific, 1 patch = 1 bug in the upstream tracker. This should be obvious, but given the number of patches that are never forwarded, it doesn t seem so. You should not only give a chance for upstreams to review the patch, but you need them to track it, and you must give them the chance to review it anytime someone else stomps on a similar issue. If upstream does not have a bug tracker, they probably think their software has no bugs. Which means they are not trustworthy, and we go back to point 3.
5. We need to give more priority to security. Issues in the security team seem now fixed for good and they have been doing an awesome work. There isn t much left to do so that packages are all built with security-hardening features, but it still needs to be done. And there is much more to do so that we can provide out of the box a decent SELinux setup, or, if it turns out unrealistic to do, a decent system hardening setup using another framework. I know the SELinux zealots will jump on their high horses to explain that their framework is better, but the current situation where it is impossible for the average system engineer to setup a Debian-based MAC system is much worse than having a suboptimal setup that already works.

All in all, this incident has a great impact on Debian s image. If we don t react accordingly, adapting our processes and our system to match what our users expect from us and they expect the best they will turn away from us. With very good reasons to do so. Update : It seems OpenSSL does have a bug tracker. Thanks Kurt for pointing me to it.

So going alone to the cinema yesterday was not a first, but going alone and being alone in the room certainly was, and an unexpected one. This was, as far as I know, the premiere in Alicante of Enloquecidas, which is certainly not that of a remarkable film, but which was entertaining enough, and provided some very good laughs. What is wrong with this city?! (Update: hm, seems I’m mistaken about the “premiere” bit. Oh well.)

Cowdancer is activly developed in debian, that's very nice. it's really a cool tool to build packages for unstable but also for backporting efforts. I'm using it on a daily basis to build debian etch packages of lustre. However three days ago cowdancer stopped working with my etch chroot after an upgrade of my unstable system:

dpkg-source: info: building lustre in lustre_1.6.5~rc3-1.dsc
dpkg-genchanges -S >../lustre_1.6.5~rc3-1_source.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: source only upload (original source is included)
chroot: cannot run command  cowdancer-ilistcreate': No such file or directory
W: cowdancer-ilistcreate failed to run within chroot, falling back to old method
 -> Running in no-targz mode
I: using fakeroot in build.
Current time: Sat May 17 12:18:30 CEST 2008
pbuilder-time-stamp: 1211019510
 -> copying local configuration
 -> mounting /proc filesystem
 -> mounting /dev/pts filesystem
 -> policy-rc.d already exists
Obtaining the cached apt archive contents
Installing the build-deps
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
Can't open perl script "/usr/bin/dpkg-architecture": Cannot allocate memory
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
sh: /tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control: Cannot allocate memory
E: pbuilder-satisfydepends failed.
Copying back the cached apt archive contents
 -> unmounting dev/pts filesystem
 -> unmounting proc filesystem
 -> Copying COW directory
 -> Invoking pbuilder
 -> Cleaning COW directory
Command /bin/sh -c pdebuild "--pbuilder" "cowbuilder" "--" "--basepath" "/var/cache/pbuilder/etch.cow" failed

After some research I found that a change of cowdancer (something related to .ilist) is responible for this issue. After that I asked on #debian-devel if someone else had this problem and were told that removing an re-creating the chroot will help. But that results in the same error msg. After that I decided to wrote a bugreport against cowdancer, since this is in my eyes a major defect in this software to do not support the latest stable release. I filled this report as RC Bug and got very fast a answer:

severity 481344 wishlist
retitle 481344  provide cowdancer etch backport
[ ... ]

I think this is the wrong way to fix a problem in unstable with a backport of a software. Providing a fallback for older debian releases would be the better way. Is anybody else having this problems?

(Well we haven't even gotten on the plane yet) I'm pretty sure that this is the first time I've flown British Airways. Sarah and I are off to Zurich via London, and when we rocked up at the airport to check in, we couldn't get seats together. We're sitting in the middle seat in front of each other. We were quite taken aback by this, as we've done a fair bit of flying together and never had this happen before. We mentioned this to the customer service person when we dropped our bags off, and she told us the reason was because they have online check-ins, all the seats go from people checking in online. They only seat people together with infants, in parties of three, or in a wheelchair. She went on to say all the airlines are like that. Not in our experience. So once we got through security and into the BA lounge, I thought I'd try again and see if we could get reseated. The customer service person in the lounge had a quick glance at the computer, and told me there was nothing available. There was no attempt to re-seat other passengers travelling alone, or anything. It looked like she based her inability to do it off the available seats. I'm just really surprised.

Here in this library, next to a couple computers available to query the catalog, a sign reads:

Do not connect your laptop to these jacks. You may loose all data in your computer.

If I wasn’t a computer-savy person, I’m completely sure I would’ve thought: “They’re bluffing.” And then shit happens, because they’re not. (Oh, but then of course the sign is not 100% honest either.)

This post is to some extent a fall-out of the recent discovery of a serious flaw in Debian's openssl and openssh packages. However, as Raghavan will confirm, a weaker version of what is said below was part of our discussion two weeks ago. Moreover, there are earlier posts on this topic in this blog.There are times when I wonder why I am so involved with computers ... this is clearly one of those times.

कर्मण्यैवाधिकरस्ते मा फलेशु कदाचनkarmaNyaivaadhikaraste maa faleshu kadaachana

This is a phrase from the भगवद गीत (bhagavad giit) which has been stuck in my head for the last 30 odd years. It roughly paraphrases into

Do something because you think it is worth doing not because of what you hope to achieve by doing it.¹

The above maxim is a good one but is sometimes a cop-out. Moreover, it provides no basis for actually making ethical choices.Ethics comes from one's interactions with the communities one is a part of. There are (roughly) two communities that I am a part of in the context of computers:

• the FOSS community; specifically, the Debian community.
• the IMSc computer community

I take these in turn below.

Debian and FOSS communitiesBy its own standards, the Debian community has suffered a massive failure ... and by these same standards it has reacted extremely well to this failure.I feel shame and blame. Why have I been ignoring RFH#332498 all these days when it shows up in the output of wnpp-alert? Here I am, a mathematician with some understanding of the issues, not helping out! Three years ago I even gave a short course of lectures on implementations of crypto; the source of openssl and openssh were used as examples. Excuses like, "I don't know anything about library packaging" and "I need more time!" (who doesn't) seem too weak now.At the same time, I feel a sense of solidarity with the Debian (and more widely FOSS) community as it tries to pull out of the resulting mess. The resilience that allows us to laugh wryly at ourselves is IMHO admirable.As Steve Kemp wrote: "[When we look back we will see that] we did good".

IMSc computer communityThe IMSc computer setup was built by volunteers and was genuinely a community when I joined this institute in 1996. It has since then broken into users, system administrators and the computer committee. As Indira Gandhi would have said: "This is a world-wide phenomenon", and as was the case when she said it, my response is: "That doesn't make it a good thing!"

When I speak about this fractured IMSc community below it is in generalities. There are certainly individuals who rise above the shards.

I have been promoting the use of FOSS and more specifically Debian at IMSc ever since I got here. While explaining the pragmatic aspects like cost and security, I have also tried to emphasize the freedom and community aspects of FOSS use. When the latter are not understood or accepted, the former are easily blown away.This year I made an attempt to get the Computer Committee to invite users to choose² their own computers and the software that ran on it, but it turned out that no one really wanted this. Users just wanted to buy "fancy toys", the administrators just wanted to make their life simple and CC members just wanted the power to dictate what people bought.³I also made an attempt to get our users to educate each other on the use of computers for their work --- first through the establishment of a wiki and then through the "No-Excuse" mailing list.⁴Unfortunately, the fractured IMSc computer community sees computers and software as expensive commodities --- with some combination of fear, greed and irritation. In any case, there is no feeling of being part of a larger community that is trying to solve (certain types of) problems.

A wise man once said:

With great freedom comes even greater responsibility.

This may explain why we prefer being dictated to by proprietary vendors and computer committees that "buy stuff for us". We are afraid of the responsibility that comes with freedom.Another much quoted quote is:

If you are not part of the solution then you are part of the problem.

The FOSS community (actively) invites people to join-in in solving problems. This participation (which can be at a level of one's own choosing) is the source of one's freedom in free software. The IMSc community just wants मा-बाप सर्कार (maa-baap sarkaar) to fix their toys.

A decisionThe IMSc computer community was tied to Debian and FOSS after the break-ins into our system in the early 2000's. At that point, I was instrumental in installing a security infrastructure based mainly on Debian. This led to my greater involvement with FOSS and Debian and also to the greater "infiltration" of Debian and FOSS into IMSc computers.From the "commodity" point of view at IMSc we have come a full circle since most users will have to "do a lot" so that the IMSc computer LAN emerges unscathed from the crisis created by the Debian openssl flaw.From the "community" point of view at Debian we have spiralled out and even this major whirlpool will not drag us back in.It is no longer possible (for me) to straddle the circle and the spiral in an attempt to widen the former; I'm taking the "outward radial vector"!

---

1. To this sentiment I have often added "do it because it's fun". ↩
2. ... and be willing to justify their choices of course.[WGFCEGR] ↩
3. OK! I'm exaggerating a bit! ↩
4. No-Excuse is an acronym for Novice and Expert Computer Users. The blurb says:

   Now that this list exists there is "no-excuse" for novices to remain in-experienced or for experienced users to claim that something is "too hard to explain to a novice"!

   ↩

I believe that the Red Hat process which has Fedora for home users (with a rapid release cycle and new versions of software but support for only about one year) and Enterprise Linux (with a ~18 month release cycle, seven years of support, and not always having the latest versions) gives significant benefits for the users. The longer freeze times of Enterprise Linux (AKA RHEL) mean that it often has older versions of software than a Fedora release occurring at about the same time. In practice the only time I ever notice users complaining about this is in terms of OpenOffice (which is always being updated for compatability with the latest MS changes). As an aside, a version of RHEL or CentOS with a back-port of the latest OpenOffice would probably get a lot of interest. RHEL also has a significantly smaller package set than Fedora, there is a lot of software out there that you wouldn’t want to support for seven years, a lot of software that you might want to support if you had more resources, and plenty of software that is not really of interest to enterprise customers (EG games). Now there are some down-sides to the Red Hat plan. The way that they run Fedora is to have new releases of software instead of back-porting fixes. This means that bugs can be fixed with less effort (simply compiling a new version is a lot less effort than back-porting a fix), and that newer versions of the upstream code get tested. With some things this isn’t a problem, but in the past I have had problems with the Fedora kernel. One example was when I upgraded the kernel on a bunch of remote Fedora machines only to find that the new kernel didn’t support the network card, so I had to talk the users through selecting the older kernel at the GRUB menu (this caused pain and down-time). A problem with RHEL (which I see regularly on the CentOS machines I run) is that it doesn’t have the community support that Fedora does, and therefore finding binary packages for RHEL can be difficult - and often the packages are outdated. I believe that in Debian we could provide benefits for some of our users by copying some ideas from Red Hat. There is currently some work in progress on releasing packages that are half-way between Etch and Lenny (Etch is the current release, Lenny will be the next one). The term Etch and a half refers to the work to make Etch run on newer hardware [1]. It’s a good project, but I don’t think that it goes far enough. It certainly won’t fulfill the requirements of people who want something like Fedora. I think that if we had half-way releases of Debian (essentially taking a snap-shot of Testing and then fixing the worst of the bugs) then we could accommodate user demand for newer versions (making available a release which is on average half as old). Users who want really solid systems would run the full releases (which have more testing pre-release and more attention paid to bug fixes), but users who need the new features could run a half-way release. Currently there are people working on providing security support for Testing so that people who need the more recent versions of software can use Testing, I believe that making a half-way release would provide better benefits to most users while also possibly taking less resources from the developers. This would not preclude the current “Etch and a half” work of back-porting drivers, in the Red Hat model such driver back-ports are done in the first few years of RHEL support. If we were to really follow Red Hat in this regard the “Etch and a half” work would operate in tandem with similar work for Sarge (version 3.1 of Debian which was released in 2005)! In summary, the Red Hat approach is to have Fedora releases aimed at every 6 months, but in practice coming out every 9 months or so and to have Enterprise Linux releases aimed at every year, but in practice coming out every 18 months. This means among other things that there can be some uncertainty as to the release order of future Fedora and RHEL releases. I believe that a good option for Debian would be to have alternate “Enterprise” (for want of a better word) and half-way releases (comparable to RHEL and Fedora). The Enterprise releases could be frozen in coordination with Red Hat, Ubuntu, and other distributions (Mark Shuttleworth now refers to this as being a “pulse” in the free software community [], while the half-way releases would come out either when it’s about half-way between releases, or when there is a significant set of updates that would encourage users to switch. One of the many benefits to having synchronised releases is that if the work in back-porting support for new hardware lagged in Debian then users would have a reasonable chance of taking the code from CentOS. If nothing else I think that making kernels from other distributions available for easy install is a good thing. There is a wide combination of kernel patches that may be selected by distribution maintainers, and sometimes choices have to be made between mutually exclusive options. If the Debian kernel doesn’t work best for a user then it would be good to provide them with a kernel compiled from the RHEL kernel source package and possibly other kernels. Mark also makes the interesting suggestion of having different waves of code freeze, the first for the kernel, GCC, and glibc, and possibly server programs such as Apache. The second for major applications and desktop environments. The third for distributions. One implication of this is that not all distributions will follow the second wave. If a distribution follows the kernel, GCC, and glibc wave but not the applications wave it will still save some significant amounts of effort for the users. It will mean that the distributions in question will all have the same hardware support and kernel features, and that they will be able to run each others’ applications (except when the applications in question use system libraries from later waves). Also let’s not forget the possibility of running a kernel from distribution A on distribution B, it’s something I’ve done on many occasions, but it does rely on the kernels in question being reasonably similar in terms of features.

• [1] http://wiki.debian.org/EtchAndAHalf


• [2] http://www.markshuttleworth.com/archives/150

Share This

I'm convinced by The Argument for Posting Ahead [Network Blogging] so why didn't I set it up for my recent trip? Well, a while ago, I had a bit of an email discussion with Steve about delayed posting features for Chronicle which I think ended with the addition of chronicle-spooler to the released files. I initially suggested ignoring a post when its Date is in the future, like Wordpress does, but I think that wouldn't be backwards-compatible and isn't as flexibile as it could be. chronicle-spooler works by moving files from a spool dir into a live dir. I'd forgotten how much it confuses me when files on a "static" site start moving themselves around. It means I have to merge before upload, which isn't a big change, but still annoying. So, I've added the following lines to chronicle to skip entries with a Publish header in the future:-

--- chronicle-2.7/bin/chronicle.orig	2008-05-15 10:13:55.000000000 +0100
+++ chronicle-2.7/bin/chronicle	2008-05-15 10:13:43.000000000 +0100
@@ -607,7 +607,8 @@
         #  Read the entry and store all the data away as a
         # hash element keyed upon the (unique) filename.
         #
-        $results  $file   = readBlogEntry($file);
+        my $result =  readBlogEntry($file);
+        if ($result)   $results  $file   = $result;  
      
 
     #
@@ -1479,7 +1480,7 @@
     my $tags    = "";    # entry tags.
     my $body    = "";    # entry body.
     my $date    = "";    # entry date
-    my $publish = "";    # entry publish date - *ignored*
+    my $publish = "";    # entry publish date
 
     open( ENTRY, "<", $filename ) or die "Failed to read $filename $!";
     while ( my $line = <ENTRY> )
@@ -1527,6 +1528,14 @@
      
     close(ENTRY);
 
+    # MJR - embargo stuff until its publish date.
+    # Steve recommends using chronicle-spooler,
+    # but I want uploaded files to stay where I put them,
+    # else I get my local copy confused.
+    if (($publish ne "") && (str2time($publish) > time()))  
+    	return 0;
+     
+
     #
     #  Determine the input format to use.
     #

I think that's compatible with chronicle-spooler, too...

And today, I finally turn 30. I've been grumpy about this day getting closer and closer for the last three or four years, which have passed in front of my eyes with me nearly not noticing. The last year has had more downs than ups, and at times has been quite dark. I feel things are slowly getting better, and I spend more time looking forward than back, which certainly should help. Tomorrow I'll hold a small party at home with some friends, but the big and proper event will be in September, when five or six people in our colla, born in 1978, will celebrate our 30^th birthday, in a massive, weekend-long party already dubbed La festa dels excessos. You shouldn't miss this one! Thanks to the many people who have phoned, texted or emailed me already. It reminds me that I'm surrounded by people who love me and were there when I needed them.

If you're a French person and were guessing what I have to do with the most famous French union, you've just been tricked. CGT stands for California Guitar Trio, a band of three virtuose guitar players. We attended their French gig yesterday night at 'Le New Morning', a famous jazz club in Paris. They came and played with Tony Levin who is, for the skilled music amateurs, one of the top world's bass player (*the* top for me). That was an amazing concert and great experience. Just try to imagine Pink Floyd's 'Echoes' played by 3 (electrified) acoustic guitar players, just after a 'Prelude and Fugue' by J.S. Bach, played cyclically (one note per player in round-robin order....a playing method invented by Robert Fripp and the League of Crafty Guitarists). That plus Bohemian Rhapsody, several pieces of their own and a stunning composition by Tony Levin where he proved that he *is* really a virtuose bass player..:-) I was just stunned, indeed....and, of course, also enjoyed a lot the presence in a very small club of Uncle Tony who I saw many times until now, but only in big arenas in all Peter Gabriel concerts I've attended since about 1980. CGT will play tonight (15th) on Milan, tomorrow in Roma, on 27th in Toronto, 31th in Rouyn-Noranda (Quebec) and a few times with friends during the Quebec Summer Festival. Then, they'll play in many places in California and all over USA. If you love eclectic music, just go listening to them. So, yes, CGT rocks!

How do you see this message in python2.5 changelog:

* Add README.db4 describing the db4.6 -> db4.5 change (Steve Greenland). Closes: #469770.

when apt-listchanges has been broken by the db4.6 -> db4.5 change ?

I usually don't blog about uploads to the Debian archive but since I don't know any similar software in Debian I do in this case.
nitrogen is a wallpaper selection and setting tool with both a graphical (with image preview) and text based frontend to set wallpapers and restore them later.
That's nothing special, there are some tools doing that.
But nitrogen also provides great multihead and xinerama support and is the only tool in the archive I know that is able to set different wallpapers to different monitors!

From the description:

nitrogen is a graphical wallpaper utility that can be used in two
modes, browser and recall.
Some of the things to look for in nitrogen are:
.
- Multihead and Xinerama support (setting different wallpapers for each monitor)
- Recall mode to restore wallpapers via startup script
- Uses freedesktop.org standard for thumbnails
- Can set GNOME background
- Command line set modes for script usage
- Inotify monitoring of browsed directories

Check it out

Dear Daniel, It looks like you are referring to my post, though you got my name wrong so that wasn’t immediately obvious. Of course this is far worse than the 2003 compromise in terms of the direct, known and quantifiable impact it has on our users. I don’t think I stated otherwise, so I hardly see why your post starts with “I disagree”.