The Backports Team is pleased to announce the availability of a new suite on backports: lenny-backports-sloppy. Please read carefully before considering using or uploading to it what this entails. The Background You might want to ask: What's that? Let me explain it. During the etch release discussions popped up on the backports list with two clashing groups:

• One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
• others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.

The standing at that time was to accept packages that were in testing after the release, which wasn't etch anymore but lenny. The same discussion started again before the lenny release, and given that we are facing the upcoming squeeze release we started internally to discuss how to noise down these long and tedious discussions, because both groups of people had valid opinions that shouldn't get ignored. So this is where the idea for lenny-backports-sloppy comes from. The Change lenny-backports-sloppy will please the group that is happy to upgrade from lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is meant only for packages from squeeze, even after the release. Technically that means it will get locked down for uploads after the release of squeeze and require manual approval (for e.g. point release update versions, or security updates that happen during the squeeze release cycle), while lenny-backports-sloppy will accept packages from wheezy. Uploading to lenny-backports will have to get approved by the Debian Backports Team after the squeeze release, just like uploads to lenny are currently approved by the Release Team. While lenny-backports-sloppy is created already and working we ask you to not upload packages there without prior discussion with the Backports Team. This is meant to ensure that the Uploader is aware about the expectations that come along with that: The package should have a good chance to get included in the next Debian release aka wheezy, and that the Uploader is willing to look after the package in the upcoming squeeze-backports suite after the release of squeeze to ensure upgradability. In case of questions, feel free to ask either directly on the debian-backports@lists.debian.org mailinglist, or contact team@backports.debian.org privately. We are also pleased to announce that the first upload to lenny-backports-sloppy already happened. From now on you will be able to install Postgresql 9.0 (which is not targeted at squeeze) from lenny-backports-sloppy. How to use If you want to use lenny-backports-sloppy you will have to add both lenny-backports and lenny-backports-sloppy to your sources.list. Backports from lenny-backports-sloppy may depend on packages in lenny-backports.

  deb http://backports.debian.org/debian-backports lenny-backports   main
  deb http://backports.debian.org/debian-backports lenny-backports-sloppy main

About Backports You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in. Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fit your needs, and not to use all available backports. Thanks for reading this far, and enjoy!
Rhonda in the name of the Backports Team

/debian permanent link Comments: 1

The Backports Team is pleased to announce the availability of a new
suite on backports: lenny-backports-sloppy. Please read carefully
before considering using or uploading to it what this entails.
The Background You might want to ask: What's that? Let me explain it. During the etch
release discussions popped up on the backports list with two clashing
groups:

• One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
• others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.

The standing at that time was to accept packages that were in testing
after the release, which wasn't etch anymore but lenny. The same discussion started again before the lenny release, and given that
we are facing the upcoming squeeze release we started internally to discuss
how to noise down these long and tedious discussions, because both groups
of people had valid opinions that shouldn't get ignored. So this is where
the idea for lenny-backports-sloppy comes from.
The Change lenny-backports-sloppy will please the group that is happy to upgrade from
lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is
meant only for packages from squeeze, even after the release. Technically
that means it will get locked down for uploads after the release of squeeze
and require manual approval (for e.g. point release update versions, or
security updates that happen during the squeeze release cycle), while
lenny-backports-sloppy will accept packages from wheezy. Uploading to
lenny-backport will have to get approved by the Debian Backports Team after
the squeeze release, just like uploads to lenny are currently approved by
the Release Team. While lenny-backports-sloppy is created already and working we ask you to
NOT upload packages there without prior discussion with the Backports Team.
This is meant to ensure that the Uploader is aware about the expectations
that come along with that: The package should have a good chance to get
included in the next Debian release aka wheezy, and that the Uploader is
willing to look after the package in the upcoming squeeze-backports suite
after the release of squeeze to ensure upgradeability. In case of questions, feel free to ask either directly on the
debian-backports@lists.debian.org mailinglist, or contact
team@backports.debian.org privately. We are also pleased to annonce that the first upload to
lenny-backports-sloppy already happened. From now on you will be able
to install Postgresql 9.0 (which is not targeted at squeeze) from
lenny-backports-sloppy.
How to use If you want to use lenny-backports-sloppy you will have to add both
lenny-backports and lenny-backports-sloppy to your sources.list. Backports
from lenny-backports-sloppy may depend on packages in lenny-backports.
deb http://backports.debian.org/debian-backports lenny-backports main
deb http://backports.debian.org/debian-backports lenny-backports-sloppy main


Richard Baraniuk gave an interesting TED talk about Open Source Learning [1]. His project named Connexions which is dedicated to the purpose of creating Creative Commons free textbooks is a leader in this space [2]. He spoke about Catherine Schmidt-Jones who wrote 197 modules and 12 courses on music [3], that s a very significant amount of work! He also mentioned the translation of the work into other languages. I wonder how well the changes get merged back across the language divide. We have ongoing disputes in the free software community about whether various organisations do enough work to send patches back upstream, this seems likely to be more of a problem in situations where most of the upstream authors can t even understand the language in which the changes are written and when the changes involve something a lot more subtle than an change to an algorithm. This would be particularly difficult for Chinese and Japanese as those languages seem to lack quality automatic translation. He mentioned Teachers Without Borders [4] in passing. Obviously an organisation that wants to bring education to some of the poorer parts of the world can t have a curriculum that involves $250 of text books per year for a high school student (which was about what my parents paid when I was in year 12) or $500 of text books per year for a university student (which might be a low estimate for some courses as a single text can cost more than $120). Free content and on-demand printing (or viewing PDF files on a OLPC system) can dramatically lower the cost of education. It s widely believed that free content without the ability to remix is cultural imperialism. This is apparently one of the reasons that the connexions project is based on the Creative Commons Attribution license [5]. So anyone anywhere can translate it, make a derivative work, or collate parts of it with other work. I expect that another factor is the great lack of success of all the various schemes that involve people contributing content for a share of the profits, the profits just don t match the amount of work involved. Philanthropy and reputation seem to be the only suitable motivating factors for contributing to such projects. One of the stated benefits of the project is to have computer based content with live examples of equations. Sometimes it is possible to just look at an equation and know what it means, but often more explanation is required. The ability to click on an equation, plug in different values and have them automatically calculated and possibly graphed if appropriate can make things a lot easier. Even if the result is merely what would be provided by reading a text book and spending a few minutes with a scientific calculator the result should be a lot better in terms of learning as the time required to operate a calculator can break the student s concentration. Even better it s possible to have dynamic explanations tailored to the user s demand. To try this out I searched on Ohm s Law (something that seems to be unknown by many people on the Internet who claim to understand electricity). I was directed to an off-site page which used Flash to display a tutorial on Ohm s Law, the tutorial was quite good but it does seem to depart from the free content mission of the project to direct people off-site to proprietary content which uses a proprietary delivery system. I think that the Connexions project could do without links to sites such as college-cram.com. One of the most important features of the project is peer review lenses . The High Performance Computing Lens [6] has some good content and will be of interest to many people in the free software community but again it requires Flash. One final nit is the search engine which is slow and not very useful. A search for engine returned lots of hits about engineering which isn t useful if you want to learn about how engines work. But generally this is a great project, it seems to be doing a lot of good and it s got enough content to encourage other people and organisations to get involved. It would be good to get some text books about free software on there!

• [1] http://www.ted.com/talks/lang/eng/richard_baraniuk_on_open_source_learning.html
• [2] http://cnx.org/
• [3] http://cnx.org/member_profile/Catherine
• [4] http://www.teacherswithoutborders.org/
• [5] http://creativecommons.org/licenses/by/2.0/

Debian s testing distribution is where Debian developers prepare the next stable distribution. While this is still its main purpose, many users have adopted this version of Debian because it offers them a good trade-off between stability and freshness. But there are downsides to using this distribution and the Constantly Usable Testing (CUT) project aims to resolve those. This article will present the project and the challenges involved to make it happen. About Debian unstable & testing Debian unstable is the distribution where developers upload new versions of their packages. It happens frequently that some packages are not installable due to changes in other packages or due to transitions not yet completed. Debian testing, on the contrary, is managed by a tool that ensures the consistency of the whole distribution: it picks updates from unstable only if the package has been enough tested (10 days usually), if it s free of new release-critical bugs, if it s available on all supported architectures, and if it doesn t break any other package already present in testing. The Release Team (RT) controls this tool and provide hints to help it find a set of packages that can flow from unstable to testing. Those rules also ensure that the packages that flow into testing are reasonably free of show-stopper bugs (like a system that doesn t boot, or X that doesn t work at all). This makes it very attractive to users who like to regularly get new upstream versions of their software without dealing with the biggest problems associated to them. This is all very attractive, yet several Debian developers advise people to not use testing. Why is that? Known problems with testing Disappearing software The release team use this distribution to prepare the next stable release and from time to time they remove packages from it. Either because it s needed to ensure that other packages can migrate from unstable to testing, or because they have long-standing release-critical bugs without progress towards a resolution. It also happens that they remove packages on request of the maintainers because they believe that the current version of the software cannot be supported (security-wise) for 2 years or more. The security team also regularly issues such requests. Long delays for security and important fixes Despite the 10-day delay in unstable, there are always some annoying bugs (and security bugs are no exceptions) that are only discovered when the package already has migrated to testing. The maintainer might be quick to upload a fixed package in unstable, and might even raise the urgency to allow the package to migrate sooner, but if the packages gets entangled in a large ongoing transition, it will not migrate before the transition is completed. Sometimes it can take weeks for that to happen. This delay can be avoided by doing direct uploads to testing (through testing-proposed-updates) but this is almost never used, except during a freeze, where targeted bugfixes are the norm. Not always installable With testing evolving daily, updates sometimes break the last installation images available (in particular netboot images that get everything from the network). The debian-installer (d-i) packages are usually quickly fixed but they don t move to testing automatically because the new combination of d-i packages has not necessarily been validated yet. Colin Watson sums up the problem:

Getting new installer code into testing takes too long, and problems remain unfixed in testing for too long. [...] The problem with d-i development at the moment is more that we re very slow at producing new d-i *releases*. [...] Your choices right now are to work with stable (too old), testing (would be nice except for the way sometimes it breaks and then it tends to take a week to fix anything), unstable (breaks all the time).

CUT s history CUT finds its root in an old proposal by Joey Hess: it introduces the idea that the stable release is not Debian s sole product and that testing could become with some work a suitable choice for end-users. Nobody took on that work and there was no visible progress in the last 3 years. But recently Joey brought up CUT again on the debian-devel mailing list and Stefano Zacchiroli (the Debian project leader) challenged him to setup a BoF on CUT for Debconf10. It turned out to be one of the most heavily attended BoF (video recording is here), there is clearly a lot of interest in the topic. There s now a dedicated wiki and an Alioth project with a mailing list. The rest of this article tries to summarize the various options discussed and how they re supposed to address the problems identified. The ideas behind CUT Among all the ideas, there are two main approaches that have been discussed. The first is to regularly snapshot testing at points where it is known to work reasonably well (those snapshots would be named cut ). The second is to build an improved testing distribution tailored to the needs of users who want a working distribution with daily updates, its name would be rolling . Regular snapshots of testing There s general agreement that regular snapshots of testing are required: it s the only way to ensure that the generated installation media will continue to work until the next snapshot. If tests of the snapshot do not reveal any major problem, then it becomes the latest cut . For clarity, the official codename would be date based: e.g. cut-2010-09 would be the cut taken during September 2010. While the frequency has not been fixed yet, the goal is clearly to be on the aggressive side: at the very least every 6 months, but every month has been suggested as well. In order to reach a decision, many aspects have to be balanced. One of them (and possibly the most important) is the security support. Given that the security team is already overworked, it s difficult to put more work on their shoulders by declaring that cuts will be supported like any stable release. No official security support sounds bad but it s not necessarily so problematic as one might imagine. Testing s security record is generally better than stable s one (see the security tracker) because fixes flow in naturally with new upstream versions. Stable still get fixes for very important security issues sooner than testing, but on the whole there are less known security-related problems in testing than in stable. Since it s only a question of time until the fixed version comes naturally from upstream, more frequent cut releases means that users get security fixes sooner. But Stefan Fritsch, who used to be involved in the Debian testing security team, has also experienced the downside for anyone who tries to contribute security updates:

The updates to testing-security usually stay useful only for a few weeks, until a fixed version migrates from unstable. In stable, the updates stay around for a few years, which gives a higher motivation to spend time on preparing them.

So if it s difficult to form a dedicated security team, the work of providing security updates comes back to the package maintainer. They are usually quite quick to upload fixed packages in unstable but tend to not monitor whether the packages migrate to testing. They can t be blamed because testing was created to prepare the next stable release and there is thus no urgency to get the fix in as long as it makes it before the release. CUT can help in this regard precisely because it changes this assumption: there will be users of the testing packages and they deserve to get security fixes much like the stable users. Another aspect to consider when picking a release frequency is the amount of associated work that comes with any official release: testing upgrades from the previous version, writing release notes and preparing installation images. It seems difficult to do this every month. With this frequency it s also impossible to have a new major kernel release for each cut (since they tend to come out only every 2 to 3 months) and the new hardware support that it brings is something worthwhile to many users. In summary, regular snapshots address the not always installable problem and changes the perception of maintainers towards testing, so that hopefully they care more of security updates in that distribution (and in cuts). But they do not solve the problem of disappearing packages. Something else is needed to fix that problem. A new rolling distribution? Lucas Nussbaum pointed out that regular snapshots of Debian is not really a new concept:

How would this differentiate from other distributions doing 6-month release cycles, and in particular Ubuntu, which can already be seen as Debian snapshots (+ added value)?

In Lucas s eyes, CUT becomes interesting if it can provide a rolling distribution (like testing) with a constant flux of new upstream releases . For him, that would be something quite unique in the Free Software world . The snapshots would be used as starting point for the initial installation, but the installed system would point to the rolling distribution and users would then upgrade as often as they want. In this scenario, security support for the snapshots is not so important, what matters is the state of the rolling distribution. If testing were used as the rolling distribution, the problem of disappearing packages would not be fixed. That s why there have been discussions of introducing a new distribution named rolling that would work like testing but with adapted rules, and the cuts would then be snapshots of rolling instead of testing. The basic proposal is to make a copy of testing and to re-add the packages which have been removed because they are not suited for a long term release while they are perfectly acceptable for a constantly updated release (the most recent example being Chromium). Then it s possible to go one step further: during freeze, testing is no longer automatically updated which makes it inappropriate to feed the rolling distribution. That s why rolling would be reconfigured to grab updates from unstable (but using the same rules than testing). Given the frequent releases, it s likely that only a subset of architectures would be officially supported. This is not a real problem because the users who want bleeding edge software tends to be desktop users on mainly i386/amd64 (and maybe armel for tablets and similar mobile products). This choice if made opens up the door to even more possibilities: if rolling is configured exactly like testing but with only a subset of the architectures, it s likely that some packages migrate to rolling before testing when non-mainstream architectures are lagging in terms of auto-building (or have toolchain problems). While being ahead of testing can be positive for the users, it s also problematic on several levels. First, managing rolling becomes much more complicated because the transition management work done by the release team can t be reused as-is. Then it introduces competition between both distributions which can make it more difficult to get a stable release out, for example if maintainers stop caring of the migration to testing once the migration to rolling has been completed. The rolling distribution is certainly a good idea but the rules governing it must be designed to avoid any conflict with the process of releasing a stable distribution. Lastly, the mere existence of rolling would finally fix the marketing problem plaguing testing: the name rolling does not suggest that the software is not yet ready for prime time. Conclusion Whether CUT will be implemented remains to be seen, but it s off for a good start: ftpmaster Joerg Jaspert said that the new archive server can cope with a new distribution, and there s now a proposal shaping up. The project might start quickly: there is already an implementation plan for the snapshot side of the project. The rolling distribution can always be introduced later, once it is ready. Both approaches can complement each other and provide something useful to different kind of users. The global proposal is certainly appealing: it would address the concerns of obsolescence of Debian s stable release by making intermediary releases. Anyone needing something more recent for hardware support can start by installing a cut and follow the subsequent releases until the next stable version. And users who always want the latest version of every software could use rolling after having installed a cut. From a user point of view, there are similarities with the mix of usual and long term releases of Ubuntu. But from the development side, the process followed would be quite different, and the constraints imposed by having a constantly usable distribution are stronger: any wide-scale change must be designed in a way that it can happen progressively in a transparent manner for the user.

This article was first published in Linux Weekly News. If you want to see more articles like this, join Flattr and click on the flattr button below every article that you like.

21 comments Support my work

My network blocks SIP on 3G, so when I start using its 3G service after leaving a wireless network my N900 goes absolutely crazy about not being to connect. Although this is a specific annoyance I have, it's a general problem with loads of similar cases, such as "I only want my work jabber/skype/MSN/etc. account enabled when I'm at work". So, I wrote a small daemon and a fun UI to make this easy. It's actually really simple: once you configure which connections accounts should listen for, it uses libconic to listen for connect/disconnect events and enables and disables accounts as appropriate. You should also be able to override its actions temporarily without it clobbering your setting.
A sneaky peek at the UI. See if you can guess where I've been visiting recently. I think the UI is pretty easy to use, and should cover most use cases. I just uploaded it to extras-devel. It's called Automatic Connections.

I've recently returned from ICFP 2010 (International conference on functional programming). This was the second time I went there, and like last year, it was a very interesting conference. This year, I've even managed to do one keysigning with a fellow Debian Developer (hello Sylvain!) While there were many talks, I only mention a few key ones, that I have found very cool. Note: I'm a layman in this field. The text below is my own interpretation of the talks and contains many errors and wrong facts corrections are welcome! Workshop on ML I wasn't present at this workshop, but other people pointed me to this very cool talk: Mirage project The abstract, to be found at http://www.cs.rit.edu/~mtf/ml2010/program.html#Program (search for Mirage), says:

Our framework, dubbed Mirage, extends the Objective Caml language with I/O extensions and a custom runtime to emit binaries that execute as a paravirtual operating system directly under Xen. The custom run-time is significantly simpler than a general-purpose operating system, with a static single-process 64-bit address space, and "zero-copy" I/O that works directly with the OCaml garbage collector. As a result, Mirage applications exhibit significant performance speedups for I/O and memory handling versus the same code running under Linux/Xen.

It's extremely interesting, IMHO. You write your code as a more-or-less normal OCaml program, but you compile it with this special tool-chain, and you boot it directly on ton of Xen, as a domU, without the intermediate OS. The project Git repo is at http://github.com/avsm/mirage, and that links a bit older presentation (http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf) which IMHO is a required read for anyone interested in cloud-related stuff. ICFP proper ICFP, the main conference, is as usual, full of math, designed to scare people away. Err, I mean, designed to tell about new developments in this field. The papers are gathered in this reddit post: http://www.reddit.com/r/haskell/comments/dji4v/papers_from_icfp_2010/. XenServer The paper http://anil.recoil.org/papers/2010-icfp-xen.pdf describes the XenServer project, and more specifically the management interface, which is written entirely in OCaml, by a team of ~10 people. They also have a bit of bin-packing code (http://xenbits.xen.org/xapi/xen-api.hg?file/95b9e4f1b9dd/ocaml/xapi/binpack.ml), but much simpler than the ganeti-htools project on which I'm working (no balancing or similar). On the other hand, it is interesting to see that they committed themselves to write the entire management suite in OCaml, as opposed to our Python plus just a few bits of Haskell. I envy them, very much so The fun tidbit was how stable they found the OCaml tool-chain. In three years, they had just one bug related to this (the tool-chain), a segfault due to wrong formatting code in the handling path of a seldom-triggered Python exception, which led to a %s to be translated as is to C code, which meant printf got the wrong specifiers. So in an OCaml project, a serious bug was due to lack of type checking in string formatting in a Python component Overall I have found interesting parallels between their experience and my own with Haskell; from is this language/tool-chain stable enough for use to concerns about using FP for a significant project (but of course, orders of magnitude difference between their case and mine). Super-compilation There were two papers on this topic; one at ICFP proper and one at the Haskell symposium. If I understood things right, super-compilation is the opposite of lazy evaluation. But let's start a bit back. First, programs written in a functional languages contain many pure function. Pure functions, being side-effect-free, exhibit many interesting properties, and one of them is that they permit decoupling of the computation of a value from the declaration of such computation. One technique derived from this is lazy computations. Lazy computation means that even though you write y = sin(x) + 1, the actual call to sin and the increment is not actually done until you need the actual value of y (not just for storing it in y, that is). Super-compilation is the opposite of this. While laziness postpones doing a computation to as late as possible, in the hope it won't be needed at all, super-compilation runs the actual computation way ahead of time, even before the program starts, that is at compile time. Since programs use input data at runtime, which is not known at compile time, the trick is to pre-compute as much as possible at this stage, given incomplete information; and the papers showed that it's possible to pre-compute much more than you'd usually believe. Optimising compilers already do some form of CAF (constant applicative form) optimisation, but the techniques presented in both papers are going beyond simple CAFs. The details are in the papers, and are complicated, but one simple example is converting this:

ones = map inc [1..]

(note that is an infinite list, and you don't want to fully compute that at any time, neither at compile nor at runtime), into:

ones = [2..]

The details on how this is done depend on the exact super-compilation implementation, and not all implementations can do the same optimisations, but in the presentations at this ICFP the idea was to split things into static/non-static parts, and build on that, or to do partial evaluation, etc. The result is that super-compilation shows significant increases in speed (in some synthetic benchmarks up to 80%), with a few benchmarks not being sped up at all, but most are. The downside is an explosion in code size, as many more things are pre-computed. Still, as a research topic, this is very interesting. My own paper Surprisingly, it seems I survived giving my talk (just an experience report, not actually fancy stuff like the rest). Either the people actually found it interesting (less likely), or they were very polite (more probably). Anyway, the paper is on the papers page (shameless self-promotion) (if you care). Haskell symposium This is co-located with ICFP, and is more practical than ICFP (which is, as I said, way too much math). The papers are again available on reddit: http://www.reddit.com/r/haskell/comments/dkzn4/papers_from_the_haskell_symposium_2010/. Orc: Concurrent Orchestration in Haskell How to easily write code for synchronising concurrent work? As an example, how complicated is to solve this problem:

[from the Orc literature] we might wish to contact two airlines simultaneously seeking price quotes. If either quote comes back below a threshold price, say $300, then let's buy a ticket immediately. On the other hand if both quotes exceed the threshold, then buy the cheapest ticket. Additionally, buy a ticket if the other airline does not give a timely quote, or notify the user if neither airline provides a timely quote.

Now, in my experience, this would require manual management and synchronisation of threads, and for example in Python the early abort of querying the price from airline B if airline A returned a good price would be non-trivial; in addition, adding two extra conditions would be again not a simple composition of rules. In Orc however, it takes all of 10 lines of code to do this, safely. I won't copy the code here, see the paper for details, or the API docs. And the best part is, this is just a cabal install orc away! I'll be very interested to see how I can use this in practice, as it is seems indeed a very powerful library. Nikola: Embedding Compiled GPU Functions in Haskell Interesting project. Using almost 100% Haskell code, and it marshalls the data to/from the GPU; in the example given, the performance is as good as hand-written CUDA code of course, this doesn't happen in all cases. It it's interesting how they manage to compile the GPU-related code to actual object code at Haskell compile time, which makes it transparent for the user. Given the prevalence of high-speed GPUs, this could be a nice way to utilise them without learning yet another language (or two, since NVidia and ATI have different stacks). They've also developed some interesting techniques (e.g. manual control of sharing, to prevent inlining) as part of their project. Scalable Event Handling for GHC This is a paper co-authored by Johan Tibell of Google Switzerland and Bryan O'Sullivan of Real World Haskell fame. Very interesting serving 20K QPS from a Haskell process while having 16K+ idle clients connected:

[ ] the performance of the epoll back end does not begin to fall off significantly until we have 50,000 idle connections open.

The talk started with the idea that we're on the path to serving 10 clients from a single machine, and how to improve Haskell's I/O manager to achieve (almost) 10 concurrent clients. The slides (which I don't have a link for) were a bit more cool on numbers than the paper. Oh, and this will come with GHC 7.0, for free An LLVM Backend For GHC The eternal fight to get better than the C backend in other words, to not have to translate Haskell to C It is interesting to see how many languages target LLVM nowadays, as opposed to plain old C via gcc. A fun trivia item was that, according to the author, there are many features in LLVM that are not actually used by 90% of the languages targeting it (e.g. the garbage collector) (if I heard correctly in the talk). The results are interesting, although not too much overall speedup is gained; this seems to be due to the hard-to-optimise Cmm intermediate language inside GHC. In any case, a few benchmarks get more than 10% speedup, even in the current form. This will also come in GHC 7.0, although not enabled by default; probably needs to mature some more Conclusion I've enjoyed this conference a lot, and I've learned a lot from it. Given that many of the talks are about research topics, it's harder to apply them in day-to-day work, but I think the pay-offs will be long term rather than immediate.

When I took over man-db in 2001, one of the major problems that became evident after maintaining it for a while was the way it handled subprocesses. The nature of man and friends means that it spends a lot of time calling sequences of programs such as zsoelim < input-file tbl nroff -mandoc -Tutf8. Back then, it was using C library facilities such as system and popen for all this, and I had to deal with several bugs where those functions were being called with untrusted input as arguments without properly escaping metacharacters. Of course it was possible to chase around every such call inserting appropriate escaping functions, but this was always bound to be error-prone and one of the tasks that rapidly became important to me was arranging to start subprocesses in a way that was fundamentally immune to this kind of bug. In higher-level languages, there are usually standard constructs which are safer than just passing a command line to the shell. For example, in Perl you can use system([$command, $arg1, $arg2, ...]) to invoke a program with arguments without the interference of the shell, and perlipc(1) describes various facilities for connecting them together. In Python, the subprocess module allows you to create pipelines easily and safely (as long as you remember the SIGPIPE gotcha). C has the fork and execve primitives, but assembling these to construct full-blown pipelines correctly is difficult and error-prone, so many programmers don't bother and use the simple but unsafe library facilities instead. I wrote a couple of thousand lines of library code in man-db to address this problem, loosely and now quite distantly based on code in groff. In the following examples, function names starting with command_, pipeline_, or decompress_ are real functions in the library, while any other function names are pseudocode. Constructing the simplified example pipeline from my first paragraph using this library looks like this:

pipeline *p;
int status;
p = pipeline_new ();
p->want_infile = "input-file";
pipeline_command_args (p, "zsoelim", NULL);
pipeline_command_args (p, "tbl", NULL);
pipeline_command_args (p, "nroff", "-mandoc", "-Tutf8", NULL);
pipeline_start (p);
status = pipeline_wait (p);
pipeline_free (p);

You might want to construct a command more dynamically:

command *manconv = command_new_args ("manconv", "-f", from_code,
                                     "-t", "UTF-8", NULL);
if (quiet)
	command_arg (manconv, "-q");
pipeline_command (p, manconv);

Perhaps you want an environment variable set only while running a certain command:

command *less = command_new ("less");
command_setenv (less, "LESSCHARSET", lesscharset);

You might find yourself needing to pass the output of one pipeline to several other pipelines, in a "tee" arrangement:

pipeline *source, *sink1, *sink2;
source = make_source ();
sink1 = make_sink1 ();
sink2 = make_sink2 ();
pipeline_connect (source, sink1, sink2, NULL);
/* Pump data among these pipelines until there's nothing left. */
pipeline_pump (source, sink1, sink2, NULL);
pipeline_free (sink2);
pipeline_free (sink1);
pipeline_free (source);

Maybe one of your commands is actually an in-process function, rather than an external program:

command *inproc = command_new_function ("in-process", &func, NULL, NULL);
pipeline_command (p, inproc);

Sometimes your program needs to consume the output of a pipeline, rather than sending it all to some other subprocess:

pipeline *p = make_pipeline ();
const char *line;
line = pipeline_peekline (p);
if (!strstr (line, "coding: UTF-8"))
	printf ("Unicode text follows:\n");
while (line = pipeline_readline (p))
	printf ("  %s", line);
pipeline_free (p);

man-db deals with compressed files a lot, so I wrote an add-on library for opening compressed files (which is somewhat man-db-specific, but the implementation wasn't difficult given the underlying library):

pipeline *decomp_file = decompress_open (compressed_filename);
pipeline *decomp_stdin = decompress_fdopen (fileno (stdin));

This library has been in production in man-db for over five years now. The very careful signal handling code has been reviewed independently and the whole thing has been run through multiple static analysis tools, although I would always welcome more review; in particular I have no idea what it would take to make it safe for use in threaded programs since I generally avoid threading wherever possible. There have been a handful of bugs, which I've fixed promptly, and I've added various new features to support particular requirements of man-db (though in as general a way as possible). Every so often I see somebody asking about subprocess handling in C, and I wonder if I should split this library out into a standalone package so that it can be used elsewhere. Web searches for things like "pipeline library" and "libpipeline" don't reveal anything that's a particularly close match for what I have. The licensing would be GPLv2 or later; this isn't likely to be negotiable since some of the original code wasn't mine and in any case I don't feel particularly bad about giving an advantage to GPLed programs. For more details on the interface, the header file is well-commented. Is there enough interest in this to make the effort of producing a separate library package worthwhile? As well as the general effort of creating a new package, I'd need to do some work to disentangle it from a few bits and pieces specific to man-db. If you maintain a specific package that could use this and you're interested, please contact me with details, mentioning any extensions you think you'd need. I intentionally haven't enabled comments on my blog for various reasons, but you can e-mail me at cjwatson at debian.org or man-db-devel at nongnu.org.

Recently, Google started changing the web in some interesting ways. A lot by contributing code. It started with projects such as the Chrome web browser, which quickly achieved a market shares over 10%, which is more than Apple Safari and Opera together.And the good side, Chrome did not actually add "yet another incompatible platform", but by being closely related to Safari (or more precisely WebKit), it is not that different.Other stuff that belongs into this category is the Google Web Toolkit and the closure compiler (which essentially is a JavaScript code checker and optimizer).But recently, Google goes a step further. They started tackling internet file formats. First they proposed a new Video codec known as WebM or VP8. Now they extracted an image format out of this codec, known as WebP.There is some serious doubt on the quality, the images do appear to be a bit blurry and lose details. I concur with JPEG even being a bit better, despite the block artefacts. The blurry results of WebP are not really convincing.The h.264 based image looks best to me, but H.264 is patent-encumbered for all I know, so we might not see this new format in wide use until 2028. This already ruled out other image formats such as JBIG or FIF. Or look at audio formats: we're still using MP3 everywhere, because everyone tries to push another patent-encumbered audio format that the others are not going to adopt. So MP3 remains the only thing widely accepted (Ogg Vorbis is nice, but it looks as if companies such as Apple are not going to adopt it, probably because they have interest in other formats. Maybe the Ogg Vorbis support in Chrome will help here on the long run).In particular, why would you pay royalties for a tiny bit of image quality, given the constantly sinking prices of bandwidth? The H.264 patents may make a difference on video data, they probably won't pay of for still images.Given that WebM is sometimes claimed to be a simplified H.264 (minus the patent issues?), WebP probably is as good as we can get to the H.264 based quality without running into the same patent issues?But enough on the image data. There is one thing, I'd really like to see Google change on the web. The worst thing about the web is called JavaScript (or more accurately, ECMAScript). There is just so much wrong with this language that we really need to replace it ASAP.Some things that are wrong with JavaScript:

• The syntax is about as crazy as Perl, anything could be valid code.
• There a lot of syntax quirks and oddities. Try to test for a variable storing an Array ...
• It lacks any reasonable Standard Library - which is a key strength of modern languages such as Java, Python, C# - and which is why everbody is using one of the thousand JavaScript frameworks such as Dojo, Mojikit, Google Closure Library, Prototype, jQuery, MooTools, Yahoo UI Library, ...
• Due to the lack of standard functionality, the JavaScript development cost is a lot higher than needed, development time is bad for the triviality of most JavaScript tasks, and the file size is even worse than JPEG vs. WebP ...

So my biggest wishlist item of Google to contribute to the Web via Chrome and Firefox is a new web scripting language. As much as I love python, the whitespace syntax of Python doesn't work for the web (we need to be able to store complex statements in HTML attributes without newlines), so we'll have to look for something else. Maybe Ruby will work?

So the exoplanet Gliese-581-g has a name: Zarmina!. Steve Vogt, who led the discovery team, named it after his wife. Good move. About time we named these things. Although personally I think GL 581 d, its neighbour, has a better chance of being habitable. Everyone is assuming Zarmina is tidally-locked: that is, it has one side facing the star at all times. This would mean that while one side of the star is scorching hot, the other freezing cold, all you have to do is go to the "Terminator", the part of the planet in continuous dusk (or dawn) to find a nice climate. Not necessarily so: it can be in orbital resonance like Mercury, which rotates in a 3:2 ratio. A better idea is to look below any oceans, if it has them, for life. Either way, this Gliese 581 is the direction to point a TPF at. Tags names, exoplanets

shapado.debian.net Since a few hours, a Shapado instance for Debian is available at: Shapado is a Question and Answer (QA) website, meant to provide user support to the community, by the community. Another way of seeing it is as a skill exchange website: users can ask questions about stuff they don't know and other users, possiby more expert on that topic, can answer those questions; everyone can then use peer review to evaluate and sort answers. Several proprietary web applications are based on the above notions and have proven useful for user support in several contexts, including other Free Software distributions. Shapado on the other hand is Free Software released under AGPL; as such it's the best match to give a try to something similar in the context of Debian. Shapado has also a couple of other niceties, e.g. offers login via OpenID and supports questions/answers in multiple languages. Will it work for us?
Will it not?
It's up to the community. This kind of user support works when it reaches a critical mass of both "newbie" users in need of help and of "expert" users willing to help them. No matter your category, give it a try: go to the website and look around, you'll probably find a question to ask, a question to answer, or an answer to evaluate. Acknowledgements

• the Shapado developers
• Patrick Aljord for hosting support
• Fernando C. Estrada and Luis Uribe for admin / moderation work (by the way, they are looking for help)
• Jorge Castro for pinging me about this idea

---

Update: add mention of multi-language support

For some time, I've had this idea brewing for how the 'net would work without DNS. Initially I was mostly thinking of how to get rid of the dark side of the registrar business, but it appears that maybe it could help with security in general too. It may not be feasible at all, or I may have forgotten extremely crucial points. I'm not a DNS guru, so bear with me and consider this as a thought experiment. This is, however, a proposal for how the Internet could be made truly decentralized, or acentric. Made so, because it currently is very centralized on at least two counts: the DNS is an inherently hierarchical structure of authority; and so is the situation with the SSL certificates used for securing websites. Let's start with DNS, if you will. Basically, the idea is to replace the current Domain Name System, which is centralised in nature (even if subdomains can be delegated) with a fully decentralised system with no central authority. The point of current DNS is to map names to IP addresses in a unique way. It currently works by registering a this name is managed by such-and-such server, ask for details at such-and-such IP address message. Of course, since there's only one namespace (or a limited number thereof, if you consider that TLDs are different namespaces), there needs to be a central authority to resolve conflicts, because some names will be more popular than others. I propose to start with a cryptographic key pair (think GPG key). Anyone can create their key pair; we assume that it's extremely unlikely for two people to generate the same keys, and that it's also very hard for two people to generate keys with the same fingerprint. By (being the only one) knowing the secret part of a key, I am the authority on what can be signed with it. I could for instance sign records that say that www points to this set of IP addresses, and smtp points to that other address. Within my area of authority, which is to say within my domain. Which is identified by the fingerprint of my key pair. What do we have so far? A mechanism that allows in a decentralised way to verify who's authoritative on the F5566852EB92BD779CF137190EA756B5144843F5 domain . In DNS terms, more probably F55...3F5.some-tld. Now let's publish the signed records on a decentralised peer-to-peer network. I'm not up to date with the latest trends in that domain, but I think something like Gnutella or Freenet would qualify, since it doesn't need central hubs but only an initial list of nodes, and it does automatic discovery of new nodes. Projects such as the FreedomBox (name likely to be changed) will probably help with that. Anyway, when looking up www.F55...3F5.some-tld, the resolver gets the signed record (and the public part of the key) from the P2P network, checks the signature, and uses the contents of the record to determine the IP address. No central or delegated registry involved at any point. Lesser risk of a single point of failure, which means better resilience against outages. Also, a better resilience against DNS-based censorship, be it promoted by non-democratic states or by greedy corporations. Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly easy name to remember or transmit. But the string of hex could be presented to the user in some other form easier to recognize for people without geek super-powers. My favourite would be the bibi-binary representation, but I'm told that the bubble-babble method works equally well. It would still be unreasonable to expect people to remember such names, and especially to type them into their web browsers or e-mail agents. A possible solution to that would be to use a short form, such as 144843F5 (or its bibi-binary equivalent), complemented by a visual representation of the full fingerprint such as the one SSH does. That pair could be displayed on business cards, email signatures, glossy brochures, advertisements and so on, and allow users to just type the strange word or flash the 2D barcode, check that the funny picture matches (in case the strange word returns several results), and get the website they want. Which they can of course bookmark under a name they can remember, probably even the same name that everyone else uses to bookmark that website. And nothing precludes convenient directories mapping names to full URLs (like search engines currently do) as long as users check that the visual representation of the site they go to matches what they've seen elsewhere. That elsewhere could, of course, take advantage of the natural web of trust that emerges in of GPG-using communities. If I'm directed at a website whose key I don't immediately recognize, then I can see who trusts that key to be legitimate (by checking the signatures), and who trusts them, and so on. Ultimately, the decision is mine to make, and mine only. In any case, once I know what URL I want to visit, I can be sure this DNS replacement will give me the right IP address (or addresses). DNS servers replying with advertisement sites instead of correct ones, and DNS-based filtering, will be things of the past. Of course, having the right IP address only solves the attacks on the DNS part. Eavesdropping can also happen by diverting traffic at the IP level. But we have a trustable way to know information related to a domain, so let's use it: the signed record can also contain the fingerprint of cryptographic keys (SSL or SSH or whatever). So we can be sure we're actually talking to the correct server, rather than to some man-in-the-middle spy. With the same guarantees of correctness as the ones for the DNS, backed by the web of trust and out-of-band validation. Again, we get rid of the hierarchy of certification authorities , some of which have been known for helping organizations get at the (supposedly secret) data people exchange over the net. To summarize: with this scheme, if I know the site I want to access is F55...3F5, then I can be certain that a) I get the right IP address for it and b) I'm actually talking to it. And nobody in-between can intercept the traffic, if the site is properly administrated and its private key is kept secure. And from the site admin's point of view, there's no need to trust DNS registrars and SSL certification authorities not to fool around with the data, or blackmail me into paying increasing fees for keeping my URL working or my SSL key certified. There's still the problem of the allocation for the IP addresses themselves, but two major parts of the centralized and hierarchical net can be gotten rid of. There are proposals attempting to fix part of the problems already, but they're incomplete. DNSSEC only solves the authentication of DNS records, not the centralisation problem. Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details). This is of course only a rough draft, full of technical considerations yet certainly not exhaustive. I've thought about it though, and I believe there are no theoretical problems with the implementation of such a scheme (apart for the handling of expiration and revocations, probably). The main obstacle to mass-adoption I can envision is the UI part, and the entrenched habit of just typing a keyword into a search engine and implicitly trusting its results, then blindly trusting the website itself; but even if mass-adoption isn't reached, I can't see anything wrong with giving those who want to be careful a more secure Internet.

Being a buildd admin means one gets to sign successful build logs so that the built packages get uploaded from buildds to the archive, but that also includes filing bugs for packages which fail to build from source (Build-Attempted). Once that done, they can be marked as Failed, usually with a reason. A few words plus a bug number is usually convenient, so that people (maintainers, possible NMUers, other buildd admins) browsing https://buildd.debian.org/status/ can just click the bug number to reach the BTS. There were a few packages in Build-Attempted for alpha, for which I reported some bugs yesterday, which explains the crossing lines on the following graph: (That s an edited version of the buildd stats for alpha.) One has to be careful while filing bugs, since the severity depends on the target architecture(s) for which the package is failing, but also on its already being built there. Mostly, that boils down to serious for regressions (no longer builds) on release architectures, important otherwise. The only exception I m applying is packages failing on all architectures due to obviously missing build dependencies, since they can t be built again, even on the single architecture they re available for (and we want to guarantee that doesn t happen, we want to be able to binNMU them). There are currently no packages in Build-Attempted for alpha, kfreebsd-amd64, kfreebsd-i386, and sparc (architectures I take care of), but I m going to have a look at other architectures as well, since having portable software and reported (FTBFS) bugs sounds like a worthwhile goal.

xserver-xorg-video-intel There s a previous episode regarding this driver, but let s try and get a short summary regarding UMS (User Mode Setting, old-fashioned) vs. KMS (Kernel Mode Setting, new but also Linux-specific): upstream moved from UMS+KMS to KMS only (that means a single code base and allegedly fewer bugs). UMS vs. KMS timeline:

2.9	2.10	2.11	2.12	2.12+legacy	2.12+shadow	2.13
UMS+KMS	KMS	KMS	KMS	KMS+UMS	KMS	KMS

In order for UMS introduced back into 2.12+legacy to be useful for the ever-buggy i8xx chips, those were blacklisted for KMS in the i915 module as of linux-2.6 2.6.32-21. The plan didn t quite work out, so we moved to the shadow version, relying on KMS again. At that point, we asked for the removal of the kfreebsd-* binaries, since they were unusable. Kernel timeline:

k 2.6.32-20	2.6.32-21 k 2.6.32-23	2.6.32-24 k
KMS	KMS + blacklist for i8xx	KMS

Quick summary:

• You want to use the latest kernel from sid, with the latest -intel driver from sid as well. (That holds for other drivers as well.)
• You may want to check whether kernel bugs are fixed in experimental s kernel.
• You may want to check whether driver bugs are fixed in experimental s driver package (2.13). Feel free to open a bug upstream if there s none for your issue already, optionally telling us about it (through a bug in the BTS which can be marked as forwarded there).

libdrm Due to nouveau s ABI changes, libdrm s compatibility (for nouveau users) is a funny subject. Nouveau users are expected to have the following in mind (README.Debian is there already in the xserver-xorg-video-nouveau package).

2.4.21-1~squeeze3 (sid)	2.4.22-1 (experimental)
nouveau 0.15	nouveau 0.16 aka 1.x
2.6.32 k 2.6.33	2.6.34 k

We carry a big ABI-revert patch in our 2.4.21 package so that we get the bugfixes of that version while still using the 0.15 interface, which is what we have in the sid kernel for now. If we need more stuff from 2.4.22 for squeeze, we should be able to cherry-pick them, or even adjust the ABI-revert patch quite easily. For now (and in experimental anyway), the 2.13 version of -intel is going to depend on libdrm 2.4.22, but cherry-picking fixes should be easy; making it build against sid s 2.4.21 shouldn t be hard either. xserver-xorg-video-openchrome It s now possible to start X with the openchrome driver again, thanks to Nethanel s feedback on #597379, but that doesn t mean it s usable for real unfortunately, since users still report frequent crashes.

I recently spent a little time adding support for isohybrid images to d-i. isohybrid is a tricksy boot sector hack that allows copying a CD image direct to a USB stick and booting it. I used it in anger for the first time yesterday, and it worked so well compared with the old method of booting d-i from USB sticks that I feel I need to blog about it so others can enjoy the fun.. The documentation on the web site has not caught up yet, but this is already usable with current d-i daily builds. For now only in the netboot mini.iso. That can be written directly to a USB stick or USB disk to make it boot d-i.

cat mini.iso > /dev/sdX

The netboot mini.iso is so named because it's functionally identical to netbooting d-i. Except without the need to set up a tftp server. Besides being a 16mb download that will fit on even your oldest USB stick, another advantage to using the mini.iso is that you don't even need to use a separate USB stick to boot the installer. You can write the mini.iso directly to the same disk that d-i will be installing to! (Particularly handy for installing debian to USB disks.) (This is also very handy for d-i development and testing, since a mini.iso can be written out to a USB key about as fast as a test machine will post..) adding firmware I also arranged for there to be a second partition on the mini.iso. The firmware partition is most easily accessed by unplugging and replugging the drive after writing the mini.iso to it -- then it will show up as /dev/sdX2 (or "Firmware" in a GUI). If you need to add firmware to d-i, you can just mount it and extract the firmware tarball into it. d-i will then automatically find, use, and install the firmware. isohybrid with other Debian CD images All this will also work with other larger Debian CD images, but we're not yet building the larger images with isohybrid, due to issues with jidgo. However, you can just run isohybrid yourself (from the syslinux package) on the CD image you download, and if it's got a recent version of d-i on it, d-i will be able to find and use the hybrid CD image after booting. That doesn't add the firmware partition to the image. If you need to do that, you could use this script.

A new month has just begun, it s again time for a few suggestions of free software projects to flattr. This is Flattr FOSS in action. Enough said, let s start with my suggestions:

1. The battle for Wesnoth is a great turn-based tactical strategy game (I spent countless hours on it a few years ago). It s been a long time I have not played on my computer, but opensource games should be encouraged. Lack of good games is one of the few recurring complaints that come back from people trying out Linux for the first time. And The battle for Wesnoth is a very active project, so there s no reason to not support them.
2. Shutter is the next-generation tool to take screenshots, it s quite popular at least in Ubuntu and it can easily replace the default gnome-screenshot application. You can apply various effects on the fly, and upload the resulting pictures directly on image hosting sites (Flickr, Picasa, etc.).
3. Awesome is a highly configurable window-manager for X. I use it as a tiling window manager (windows are arranged to always fill the entire screen). Its configuration file consists of LUA code so it s for power-users mainly Julien Danjou started Awesome but he has also written many other small nifty tools, discover them in his Flattr profile.
4. Sparkleshare is a new collaboration tool that will transparently synchronize a folder between several computers/persons and inform you in real-time of changes. Under the hood, it uses public Git hosting sites (like Github or Gitorious) to store and exchange the data. In some aspects, it s like Dropbox s shared folders. You can also read Linux Weekly News review of it.
5. My last suggestion is to support Harald Welte and his projects. Click here to see his Flattr profile. He is someone in the free software world. First of all he s a famous kernel hacker, he wrote much of the firewalling code (known as netfilter). He also initiated gpl-violations.org and ensured that the GNU General Public License was respected when he found out companies that failed to meet the terms of the license. Lately he has been reverse-engineering the whole GSM stack pointing out security problems as he discovers them with the goal to provide a free implementation of everything (first results are in projects OsmocomBB and OpenBSC). Isn t that impressive?

That s it for this month. By the way, did you tell your friends how easy it is to support free software with Flattr? Share this article with them and let them join Flattr FOSS too. No comment Support my work

I today deactivated my Facebook account. It was some effort, because I had developed some Facebook applications, and their page to reassign them to a different developer was broken (actually the whole application edit page was broken).I have always been a "responsible" user, keeping good control over my data, and usually just posting stuff that I'd tell anyone anyway. Facebook has also always been some kind of "marketing" tool for me, being able to support some friends by inviting people to go to their events etc.However, there are plenty of reasons to abstain from Facebook:

• They track you on millions of web pages via the like button. See earlier posts on how to block some of this tracking.
• They collect tons of data on you even when you do not join, by collecting data on you via your friends email accounts, phone books etc. For example it has been shown that, when one of your friends uses Facebook for iPhone, then Facebook already has collected your phone number.
• Facebook is flooding you with information that is entertaining at first, but actually quite useless. (e.g. who became 'friends' with whom). FBpurity is a good way to remove much of the trivially useless information.
• Facebook is a huge time sink if you are not responsible, e.g. refrain from using all the games, use FBpurity to filter our cruft etc.
• Facebook is giving you the impression of having lots of friends and of being social - while in fact, you are probably even spending less time with your actual friends than ever before.
• Facebook is a great tool - for mobbing. You can easily tell things to everybody except a certain person. Invite them all to a party, but hide it from the target until its over, then brag on how great the party was. And so on - and in fact, that is what happens to non-Facebook users already; this is the kind of social pressure that made Facebook so big.
• Facebook is a lot about bragging rights. Having the most friends, the coolest photos, the best links, the prettiest girls posting on your wall.

Facebook makes things easier, but also a lot more shallow. When someone took note and remembered your birthday, there was some effort involved that shows that they cared. With Facebook reminding people to greet, what is a birthday greeting on Facebook more than an automated message? It's about as personal as the annual christmas card by some large company. Face it: the "social" part of the "social web" is pretty shallow.As you can see above, I've been caring about these issues for some time; I post selectively, I filter much of the tracking, I don't use their games. With my Hiatus, I want to further improve, in particular

• use my spare time for useful projects instead of reading trivialities posted on Facebook. There is just so much tiny stuff that you could do with your time instead.
• spend more time with my true friends
• be more self-aware of my time use in general
• remind people that they know people outside of Facebook, too

After being noticed in blog comment about another theme for phpMyAdmin, I started to look for other hidden contributions for phpMyAdmin and I was surprised how many people did not even try to submit their code upstream. Have you ever considered trying to contact upstream? Quick search on SourceForge.net revealed: VisualMCD for phpMyAdmin

An Add-on for phpMyAdmin which enables user to create PDF Schema and Relation with a simple click and mouse moves. No more fastidious typing of table coords needed to create the PDF Schema.

Even though the SF.net history says it was released 440 days ago, it is actually dated back to 2003 and it obviously is not compatible with current code base. Also we have similar feature for few years now, so it was just duplicated effort. phpMyAdmin theme: Paradice

Paradice is a Theme for the popular web-based database administration tool phpMyAdmin. You will find the development version here. All official releases will be made by the phpMyAdmin project.

This theme is just developed externally, but you can get it from our themes page phpMyAdmin persian project

phpMyAdmin persian project

Something what seems to be dead from beginning. Anyway if you want to translate, please use our translation server. MySQL Form Generator pour PHPMyAdmin

C'est un outil pour crr un site autour d'une base. Un gnrateur de formulaire. Sur base d'une DB Mysql.Projet prvu pour tre intgr PhpMyAdmin.mysql -> formulaire HTML+javascript avec le code PHP pour trater les soumissions de donnes.

Something we still don't have in phpMyAdmin, however the project is inactive for more than year. pmahomme

Clean, modern and easy to use phpMyAdmin theme.

Theme which started this search, however it seems to fail for me right now. phpMyDesigner

Plugin for phpMyAdmin. PhpMyDesigner is a tool written in PHP and Ajax. This CASE with WEB interface. ( MySQL )

This actually does not fit into this blog, because it is one of projects that got merged and are now part of our code base. phpMySchema

phpMySchema is a tool written in PHP for generating an ERD or otherwise graphical view of your MySQL databse over the web. It is being developed to be used as a standalone script and as a module for phpMyAdmin.

Generally it looks like an interesting addition, however we can quite well compete with this after this year's GSoC, which added ability to export schema in various formats.

Filed under: Phpmyadmin 0 comments

For once, not using that journal entry title to talk about my own. Someone posted a pointer to an opinion piece looking at productivity differences between the US and Germany to a private hierarchy I read. I know productivity numbers like this are somewhat disputed, but I don't want to get into that. What I'm more interested in is the analysis. Whether or not the US does significantly better or worse than other countries in this regard is hotly debated, but what isn't is that the length of typical work weeks for employees, particularly in IT, is not going down. Fifty or a hundred years ago, it was common to expect that the growth of automation would mean more leisure for humanity. There was, at the time, some argument over whether that would be a good thing, but it seemed to be a trend. This didn't happen here. The above article argues that the amount of vacation that US employees take is going down over time. And in IT it's common to hear about 50 hour weeks (or 80 hour weeks in startups). Little of that promise of increased leisure from modern technology seems to have happened in the US, although it seems to have happened somewhat in Europe; about all we managed was to get down to a 40-hour work week, which is now honored in the breech for a lot of exempt employees. And that was seventy years ago. Most of the scientific research that we have available is quite clear that working longer hours causes diminished productivity. Standard time management advice is to focus more and work in shorter intervals. Hours of unfocused work are considerably less effective than much shorter periods of focused work, recovery time is vital, and forcing oneself to work long hours leads to bad decision-making. Even in less cerebral and more repetitive work, such as some assembly line work, we've known for many decades that working longer hours leads to more accidents and more bad decisions, and there the costs of an accident are often much higher. So, why are we so dead-set on doing the exact opposite of what available evidence says is the best way to work? I think this is to some extent a Rorschach blot question: you're going to see the answer in this that fits your pre-conceived notions about what's dysfunctional about US workplaces. I rambled elsewhere about my own pet peeve: the overwhelming focus on money and short-term profit and cutting cost, which I think leads to a lot of the nasty employment abuses in the US. But here I want to raise a different point: as the article says, we work long hours because that's what we're measured on and rewarded for. We work unproductively for many of those hours partly because it's impossible to be productive for that many hours. We get used to feeling intermittantly unproductive at work; it becomes normal. And in many jobs, particularly in IT, we don't measure ourselves by results because we have no idea what a reasonable level of results actually is. Management gets a lot of blame for failure to manage by results rather than by artificial measures like attendance and time worked (or tickets closed, or hours logged against customer requests, or similar trivially manipulatable and artifical measures). But I think this goes deeper than management. I think even we ourselves, with as good of knowledge as anyone could possibly have of what our jobs are and what good results look like, don't have a clear idea of how much to expect from ourselves on a daily basis. I know from time management exercises that I wildly mis-estimate tasks and don't have a good feedback loop to get better at estimates. I also tend to plan towards maximums rather than the average. If I have a very good day, I try to work at that level and hold myself to that level of work, rather than trying to find a long-term average. And my perceptions about what results constitute good results vary wildly based on the most recent events and surrounding context (such as whether a project is late), even though I know that my basic work capacity is not going to change significantly because a project is late. If we want to change how we measure work, I think this may be the place to start. We can't ask managers to measure us by results if we don't even know what that measurement would look like. I'm going to start asking myself some new questions: What is the average amount of work I can get done in a day? What's the standard deviation? Is there some way that I can measure this over time so that I'm not fooling myself based on circumstances or temporary surges of productivity, since my day-to-day productivity seems to have a lot of "noise"? What realistically constitutes finishing a week's worth of work? When am I "working" but not accomplishing something, and more importantly, why am I doing that? What broke when that happens? I'm firmly convinced that one of my personal breakthroughs in time management will happen when I can stop "working" when I'm not being productive. Whenever I manage this (rarely, right now), I both find I needed the break and find that I can return far more productive than I was before I took the break. But usually I continue to "work" unproductively, clocking hours without creating results, and feel both guilty about the lack of results and even less productive. That's the trap that I think this article is pointing at.

Around three years ago I've migrated my stuff to Subversion from GNU Arch. Last year I migrated most important/alive things to Git. Unfortunately not all, so I still needed to host SVN server on my own. I think it's now time to get rid of it :-). In past weeks I've moved most Debian packaging stuff to some team/collab-maint repositories (being it Git or Subversion), because I really don't see need for hosting that stuff on my own. The remaining repositories are mostly historical (with single exception of StarDict dictionaries conversion tools) and nobody will probably care if they are gone. Ah and there are some dead projects as well which were never finished and will never be :-). Anyway svn.cihar.com is going to disappear soon and nobody will miss it.

Filed under: Coding Debian 0 comments

Just to give you an idea of how much I can procrastinate: 16 years after I first said I would start doing so, I have finally bit the bullet, and started taking Tennis classes. Of course my physical condition, after more than 10 years of not doing any sport in a structured manner, is terrible; and as a result, my muscles are complaining to me almost every day now. I'm sure that's something which will diminish over time, as I shape up. At any rate, I'm enjoying it, and it seems like I'm not doing too bad. We'll see. In slightly-related news, I finally stopped procrastinating on my latest NM. Sorry 'bout that.