As I recently bought a NSLU2 ("slug") for 24/7 server usage and random ARM-based development (more on that later), I'm looking for a suitable storage device to use as the root filesystem for a complete Debian system. The requirements are:

• Large enough (>= 1 GB).
• Silent. Hard disks are not an option (no IDE, no SATA, no USB, neither 2.5" nor 3.5")
• As fast as possible.
• USB-attached (the slug only has 2 USB connectors).
• Should live as long as possible.

The last item is the most important. The obvious choice is a USB memory stick, but unfortunately those are flash-based and only survive a certain number of write cycles. Thus I'm looking for something which at least survives enough write cycles to make it usable for a few years... I do know several ways to reduce the number of writes via software, that's not what I'm currently interested in. I'd like to know which storage types will survive the longest amount of time (because of their hardware properties). Some options:

• USB memory stick, obviously. Usually quite slow, but there are quite fast ones (read 33 MB/s, write 22 MB/s), too. Some seem to survive 100.000 or even 1.000.000 write cycles, but that may not be enough. Are there any sticks with more possible write cycles?
• Any other USB-attached (via external USB card-reader if necessary) silent storage type: SD, MMC, Transflash, Memory Stick, Compact Flash, whatever. Does any of those survive more write cycles?
• Any other viable option?

Has somebody else done something like this before and can share some experiences as to which storage type is best suited for such a scenario? I suspect my slug will be mostly idle, but there might also be phases where it runs on 100% CPU and heavy disk I/O for multiple days in a row...

A common criticism of fluorescent lights is the inability to use dimmers, as mentioned in Julien Goodwin's blog.

However with some thought at the time the lights are installed this problem can be solved. The first thing to keep in mind is that an infinite number of levels of illumination (analogue scale) is not really required. In most cases two or three levels should do.

If you have two compact fluorescent lights that use 5W and 10W then you have the options of 5W, 10W, and 15W. If you have a large room to light (such as a lounge room) which needs 30W of fluorescent lighting for full illumination then you could have six 5W globes dispersed and have anything from one to six of them turned on to give different levels of illumination.

Of course if you don't plan electrical work then it's easiest to just use incandescent lights in those areas. As long as the areas that use the most light for the longest time have fluorescent lighting it shouldn't make too much difference.

In response to a post on Planete Beranger, saving energy DOES matter. Sure you saving a few KWh isn't going to make much difference on it's own, but when a million other people do the same it all adds up.

The lack of public transport in the US causes more problems for the country than just environmental damage. It hurts the economy by making it more difficult for people to get to work. It will hurt the defence forces in the (unlikely) event of an invasion (trains are the best way of moving large numbers of troops, heavy weapons, and military supplies. It also hurts the national interest in decreasing the ability to react to civil emergencies. For example the entire population of New Orleans could have been evacuated in time using a single platform of a European station. If every city had multiple stations that had a reasonable number of platforms and multiple redundant train lines then evacuating civilians and bringing in emergency equipment and workers would be very easy. In the Netherlands train lines often run on top of dikes, this means that the dikes are very strong (if they can sustain the weight of a freight train then they aren't going to be washed away by a wave) and that trains can still operate while flood waters are rising. If New Orleans is to be rebuilt to it's former glory then the Americans should consider a similar design.

Large cars are a temporary issue. As fuel prices rise people will choose smaller cars. Also hopefully people will start to realise that 4WD and SUV vehicles are actually less safe than cars and stop buying them for perceived safety.

The Chinese government doesn't worry about the same environmental issues, however they have more agressive targets for renewable energy use than most countries. It's not a matter of being nice (they aren't), but of looking out for their own self interest. It's a pity that the governments of the US, Australia, and EU countries have not yet done the same - but it will happen eventually.

As for supermarkets using open fridges, if the vent the heat outside the building then it will be just part of the building air-conditioning system. Every adult dissipates about 100W of heat when at rest, when shopping it would be more than 100W. Get 100 people in a supermarket (not the peak business time) and 10KW would have to be removed by the A/C system without counting heat from lights (fluorescent lights dissipate about half their energy as heat, they are much more efficient than incandescent lights but much less than LEDs),
and heat from other machinery.

Finally, if you want to see changes in government policy then join your local Green party!

6 weeks since my last post here, which I guess sums up how busy I am with things, primarily off-line but with a reasonable amount of development work coming out too. Thanks to Radu Spineanu xen-shell made it into the archive, and work has restarted on a multi-dom0 Xen control panel. So far there is a node daemon, a central server, and a shell-based admin tool, all written in Ruby. Coming soon a web-based control panel, implemented in Ruby on Rails. Exciting times.

In previous times, most Linux distributions and other free software projects relied on the XFree86 system. Over the years, the structures within the XFree86 project became were rigid and the project failed to innovate and keep up with the pace of the wider free software community. When XFree86 changed its license in February 2004, the active community and the majority of vendors quickly moved to X.org. X.org is a very active community and they decided to break up the monolithic code base and to adopt a more modern build system. As of X.org 7.0, the project moved to the modular system in which components are developed and released separately. Effectively, the project introduced a development mechanism which features two release mechanisms: individual components can be released as needed and there is an overall release of X.org in which all stable components are put together. These roll-up releases take place every six months.

Version	Date	Months
7.0	2005-12-21
7.1	2006-05-22	5
7.2	2007-02-15	9

Past problems

• XFree86 made only infrequent releases every few years, had no plan, and the project's structures were very rigid.
• The code base was huge and monolithic. It had an archaic build system that few new developers were comfortable with. This made it hard for new contributors to get involved and was bad for testing.

Solutions

• X.org moved from a monolithic to a modular system. This made it easier to perform testing and it made it possible to give contributors write access to specific components.
• The move to the modular system allowed them the introduction of two release mechanisms: individual components can make releases on an ongoing basis and roll-up releases take place every six months.
• The roll-up releases have a fall back mechanism in case a specific component is not ready for release: the former release of this component can be incorporated.

Outstanding problems

• The project needs to work the interface between the server and drivers, so updates to hardware drivers can be released more often than other components.

[UPDATE: I'm closing comments on this post, because the spammers have discovered it -- dnb]

Lars says:

The uncomfortability of Synaptic may be partly due to the fact that it is
a different model from Windows: you get all your programs from one place,
instead of anywhere on the Internet, partly due to just not using Synaptic
much at all, and partly due to Synaptic not being perhaps as easy to
understand as possible. I personally find Synaptic to be very nice, and
use it regularly, but I am biased by having used Debian package managers
for over a decade.

Now, synaptic is a lot nicer for users than scary console frontends like aptitude. But it's really a tool for "power users". Here's a quick list just of what I see when I start it (bearing in mind that my UI design skills suck):

• The "quick introduction" screen that pops up is way too long. The fact that it needs to be so long is already bad.
  
• There's a huge, and I mean HUGE list of sections down the left. What are these? Which one do I look in? For that matter, what is "gnome", and are "shells" programs for the seashore?
  If I want to find software for processing video, do I look in "graphics" or "multimedia"? (and what are these funny "(contrib)" markers?) Which of the huge number of packages in each section do I want? From the point of view of a new user (especially), this categorization is useless, not to mention often wrong or misleading.
  
• The four buttons in the lower-left, which change the display, are a good idea, but they don't say what they do. A label saying something like "Group By" would go a long way here.
  
• I think the version numbers in the main display probably provide too much information for a novice user. They won't really know what to make of them, and if they need the information it can be provided on demand; as it is, it's just one more distraction to sort through while looking for what they really want. The extra space could, e.g., be used to provide more room for the status column (currently labeled "S").
  

So much for superficial observations. There are a few more things that I see that are worth more discussion.

Mechanics of selecting packages

To change the state of a package, you click on the unlabeled little box to its left, then select the correct option from a list containing "Unmark", "Mark for Installation", "Mark for Upgrade", "Mark for Reinstall"...you get the idea. Even if only one option is valid, the menu still appears with all but one option grayed out, and you have to select the one you want.

This is complicated, cumbersome, and surprising. It also introduces terminological confusion, since "Unmark" isn't really what you think of when you go to cancel an installation or whatever.

The best option I can think of here is a pulldown menu (which I believe the GTK+ list widget (god, I almost wrote "control") supports). The menu should default to the current state, e.g., "not installed", and should have options that describe what will be done with the package, e.g., "install", and so on. Only valid actions should appear on the menu. The Package menu should probably adapt in the same way as you select packages. I don't recall offhand how GTK+ menus work, but if possible commonly used commands like "remove" should be closer to the mouse when the menu appears than uncommon commands like "reinstall".

Another choice I can see, if you want to avoid menus, would be something like this: have two checkboxes, one for "install" and one for "upgrade". "install" would be checked for installed packages and not checked for not-installed packages. Checking or clearing it would mark packages for installation or deletion. "upgrade" would mark or unmark packages that were installed for upgrade. Of course, this introduces a redundant column for not-installed packages, which I don't like. It also seems to me that it would be less obvious what's going on for new users. But it would be more efficient for power users (who should all be using aptitude anyway ;-) ).

Progress bar madness

I haven't extensively used synaptic, but several core misfeatures of apt and our archive pretty much guarantee that if it displays progress bars for key operations like loading the cache or updating the package lists, the progress bars either run multiple times (i.e., don't actually tell you how close to finishing you are) or actually go BACKWARDS -- yes, BACKWARDS.

The great package hunt

Maybe the biggest problem is that unless you know what package you're looking for, basically all our package interfaces are useless. There are lots of fancy searching features you could add, but actually a quick test in synaptic suggests to me that this would be going in the wrong direction. Unlike aptitude, synaptic includes descriptions, and searches for stuff users might actually want (like, say, "burn CD") seem to turn up relevant results (i.e., software that burns CDs).

I'm sure the search algorithm could be improved (with inexact matching, better indexing (a package description suffix tree?), etc), but the big problem I see is that you tend to get back several dozen results, many of which are libraries, development packages, command-line software or software that doesn't work; some of the other software is software that can burn CDs but whose purpose is not to burn CDs (e.g., backup software).

How can we solve this? The first thing that springs to mind for me is to use popularity-contest data to weight the list. I know it's not terribly accurate, and it has some skewing problems (stuff in the default install will be favored), but I suspect it would greatly bias the results in terms of software that's useful to many people (using the "recently used" tallies might especially help here).

I don't have many other good ideas on the searching problem; I've seen vague suggestions of counting reverse dependencies, but this doesn't seem like a good metric of useful software to me; trying to extract more information from the short and sometimes inaccurate package descriptions seems like a really hard problem to me. (Google can do cool statistical analysis partly because it has so much data to work with AIUI; even a single Web page typically has orders of magnitude more information than a package description)

Another issue is the problem of finding related software once you've installed one piece. We have "suggests" and "enhances", but they aren't exactly displayed in a prominent or easy-to-understand way by any frontend. I think it might be good to display a clickable list of suggested packages somewhere visible (e.g., at the top of the description box) when the user has selected a package for installation. We could even display a little bar, like on (eg) Amazon: "Debian suggests installing these packages..." ;-)

It might also be interesting (if this is considered acceptable; since the data is anonymous I don't see a problem) to analyze the popcon data to find out what packages are being installed in tandem. I don't know if we have enough information to do it, but it could turn out to be really useful to be able to click on a package and see other packages that are popular with users who installed that package. Going back to online stores again, those "other people who bought 'Types and Programming Languages' also bought 'Introduction to Category Theory'" links are amazingly useful, and something similar would probably be a big help in Debian.

I don't usually do these, but this one could be fun for planet debian:

You Are 20% Nerdy You are definitely not nerdy - in fact, you probably don't know any nerds. You probably care a little too much about your image. No one will know if you secretly watch Star Trek reruns! How Nerdy Are You?

I think most of my few points are linked to debian development... this is partly why the idea of more "social conformance" testing for new maintainers worries me. It could mean I'll always stand out like a bizarre blue-haired hacker.

OpenOffice.org is an office suite offering various integrated applications, such as a word processor and a spreadsheet. Originally developed by StarDivision, StarOffice was acquired by Sun who released it as free software as OpenOffice.org in July 2000. While Sun still maintains fairly tight control over the development of OpenOffice.org, many other vendors, in particular Novell, are important contributors to the project. The project had a fairly long release cycle of about 18 months to accommodate StarOffice, the commercial product from Sun. There were many delays, making it hard for vendors to decide which version to include. OpenOffice.org moved to a three month release cycle after their long-delayed 2.0 release, published 26 months after 1.1. The new release cycle is viewed as a positive development by contributors who get their features and fixes out to users faster. Nevertheless, at the end of 2006 a discussion took place in which a six month interval was suggested. Apparently users didn't want new features every three months and the short interval between releases put a lot of pressure on the QA team.

Version	Date	Months
1.0	2002-05-01
1.1	2003-09-02	16
2.0	2005-10-20	26
2.0.1	2005-12-21	2
2.0.2	2006-03-08	3
2.0.3	2006-06-29	4
2.0.4	2006-10-13	3
2.1.0	2006-12-12	2

Past problems

• The long release cycle of 18 months, bound to the commercial StarOffice product, meant that little testing occurred for a long time because developers believed the release was far away.
• Many changes accumulated during the long development phase, making testing towards the end very difficult, and leading to a big bang' release.
• Features were put in very late, even during the beta cycle, because of the perceived 18 month delay to the next release.
• There was very little code review. The QA team only tested the program.
• Vendors shipped unreleased versions because the significant delays during the 2.0 cycle made planning impossible.

Solutions

• After the 2.0 release, the project moved to a 3 month release interval. This model promises a tight feedback loop with users.
• Because planning is now possible, collaboration between vendors on the same code base is far easier.
• The faster release cycle and more collaboration among vendors has promoted code review.
• Motivation in the project has increased because people see their contributions getting out to users within a reasonable time.
• The release process has become more transparent, allowing voluntary contributors to take a more active part in release preparations.

Outstanding problems

• There are discussions about changing the release interval to six months. There is some evidence that some users do not want new features every three months and that the aggressive release cycle of three months puts a lot of pressure on the QA team.

Finally all the family have been informed, so I can write about it here... Sarah is is 10 weeks pregnant. The news came as a bit of a surprise, because Sarah had been feeling nauseous for a few weeks, and we'd immediately suspected pregnancy, but a total of seven tests all said she wasn't. It was only after comprehensive blood tests, that we got a phone call at 11pm on February 22 from the doctor confirming she was indeed pregnant. We went to see the high-risk ob/gyn (why the feel the need to mash their specialty together like that I do not know...) and it was a bit of a sobering experience. Sarah's cardiologist had previously said that he was okay with her having a pregnancy. Her aorta was larger than it should be, but not too big, so he advised us that if we wanted to have children, we should do it sooner rather than later. Now, we sat before the ob/gyn, and she was very unhappy that Sarah was pregnant, and said that given her history and whatnot that she wasn't happy at all with the situation. She'd brought forward the appointment by a week specifically to tell us this. So that really took the edge off things a bit, at least for me. Needless to say, we're continuing with the pregnancy (and this ob/gyn, at least for the time being). Sarah's been having a bit of an unpleasant time with the all-day sickness, which hopefully will pass by the second trimester. We've got an ultrasound from a couple of weeks ago here. Not much to see really. We've nicknamed the foetus "Squirt" until we know the gender and decide on a name.

The Google Summer of Code is in preparation again. I'll be available as mentor for the Debian project again in 2007. If you are interested in the summer of code, hurry up:

• March 14: List of accepted mentoring organizations published on code.google.com; student application period opens
• March 24: Student application deadline

Yes, about one week left to write and send in your proposal! I'm interested in SELinux and Debtags related projects mostly. Maybe some init stuff or infrastructure, too. But there might be better mentors available for that. Just make a good proposal! SummerOfCode2007 in the Debian wiki, where some ideas are posted. But it'll probably give you higher scores if you come up with something on your own. You might also want to read Planet Debian or the DPL vote platforms for some ideas on things to work on. And of course you can discuss them in our IRC channel or on the mailing lists, there is nothing to be kept secret! Anyway, make sure you write a good proposal. We don't like copy&paste jobs. We want students who are serious about contributing to Debian, the opensource world and about learning how development on this scale works. That want to become an important member of the community. It's about you and the community, not so much about the project or the donation to Debian (we aren't good at spending money anyway, being a volunteer project).

I just read an interesting blog post from December 2005 about the environmental impact of bio-fuels. It makes some really good points that should be studied by everyone who is interested in protecting the environment.

However this doesn't mean that bio-fuels are inherently bad, just that some methods of production are bad.

The blog claims that reusing oil that had been used for frying would cover 1/380 of the fuel used for road transport in the UK. There are some technologies that have been recently invented to process farm and industrial waste into oil, some of which are already in production in the US. The volume of farm waste (and equivalent waste from restaurants) would significantly exceed the frying oil from restaurants and converting waste plastic into fuel would add even more. I'm sure that these sources of fuel from waste would add up to at least 1% of the current transport fuel use.

A better train system has the potential to halve the use of fuel for transport (or better), when living in Europe I never considered owning a car, the trains were so good and the car parking was so bad that it wasn't worth doing. A combination of less cars and the cars being driven less would significantly reduce fuel use.

Hybrid vehicles and vehicles with smaller and more efficient engines could halve the use of fuel again (or better). Diesel hybrid cars that are currently being tested use as little as 1/4 the fuel of current petrol cars. Add further technological improvements such as the six-stroke engine and we could be looking at something better than four times the current fuel economy of cars.

I don't think it's unreasonable to assume that a combination of a good public transport infrastructure, fuel efficient vehicles, and government incentives for using both could reduce the transport use of fuel by a factor of 8. This would mean that fuel produced from restaurant, farm, and plastic waste (which I conservatively estimate at four times the volume of used frying oil) could account for more than 8% of the fuel supplies. The EU wants to have 5.75% of fuel oil to come from renewable sources, it seems to me that this is possible without importing any bio-Diesel from developing countries!

Electric cars could of course significantly decrease the use of fuel oil too. A Prius+ (Prius modified to take mains power) would be an ideal vehicle for me. I rarely make long journeys and rarely make multiple journeys in one day so I could use mains power most of the time. I estimate that with a Prius+ I would use no more than two tanks of petrol a year.

Then of course there's the issue of market protection. It seems that every first-world country has a farming lobby that convinces the government to pay them to produce more crops than they can sell at market rate. Instead of subsidising food that is sold to other countries such government money could go towards subsidising development of bio-fuels. The US subsidy of corn production is a classic example of this, corn syrup can be easily fermented and distilled to make fuel - much better than eating the nasty stuff!

The Linux kernel project has seen major changes to its development and release strategy in the last few years, in particular since the first stable release of the 2.6 series in December 2003. This series was opened almost three years after the 2.4 series in January 2001, which many felt was too long. A problem that resulted from the long interval between major releases was that vendors had to back- and forward-port a lot of patches. Nowadays, major development happens on the 2.6 series and new releases are published every three to four months. This new development model has faced much controversy. While some people, in particular developers of the kernel, claim that the new model is working very well, some users are worried about the number of significant changes and lack of stability in the kernel. Andrew Morton, a lead developer, has expressed several times that he believes the kernel is getting buggier.

Version	Date	Months
1.0	1994-03-14
1.2	1995-03-07	12
2.0	1996-06-09	15
2.2	1999-01-25	31
2.4	2001-01-04	23
2.6	2003-12-17	35

Past problems

• Because of the long release cycle, many changes accumulated. It was hard to get the development stable and there were few testers.
• Features got out very slowly because of the long release cycle.
• Hardware support and crucial features had to be backported to the latest stable kernel.
• Vendors backported many features to their own releases. The code base from different vendors diverged a lot from each other and from the official development version.

Solutions

• New versions are now released every two or three months. There is a two week merge window after each release during which new features are accepted; subsequently, the focus is on stabilization.
• There is now a steady flow of code into production and many people get to test the new code.
• Features get out more quickly.
• Vendors can directly work with current releases and get their changes into official versions easily.

Outstanding problems

• There is no long-term stable version based on the 2.6 kernel. This is being addressed with Adrian Bunk's 2.6.16 long-term maintenance tree but whether it will have a big impact remains to be seen.
• Regressions between versions are introduced more frequently. Better control and tracking of regressions are needed.
• The Bugzilla bug tracker needs to be integrated better into the development process and it would be helpful to have a QA person. In January 2007, Google announced that they're looking for a kernel QA person who'd work together with Andrew Morton.

GNOME provides a complete desktop environment that is easy to use. The project experienced major problems, such as delays, during its 1.x series and in particular during the preparation of its 2.0 release. GNOME introduced time based releases after its 2.0 release and has significantly improved release management. The project has published time based releases every six months for a number of years now and is considered as the reference model for a good implementation of time based release management. They have shown that it's possible to set and meet deadlines in volunteer projects and to release on time.

Version	Date	Months
1.0	1999-03-03
1.2	2000-05-25	15
1.4	2001-04-02	10
2.0	2002-06-27	15
2.2	2003-02-06	7
2.4	2003-09-11	7
2.6	2004-03-31	7
2.8	2004-09-15	6
2.10	2005-03-09	6
2.12	2005-09-07	6
2.14	2006-03-15	6
2.16	2006-09-06	6
2.18	2007-03-14	6

Past problems

• The main goal of version 2.0 was to change internal interfaces but after more than a year of work the project felt they had to deliver more user-visible changes, therefore leading to delays.
• Developers were disappointed with delays and that their work was not available to users.
• It was not clear what was going on. Developers constantly had to ask about the release status.
• Freezes were announced and people worked towards them but then they were delayed. Freezes also often came unexpectedly.
• Vendors had deadlines but the GNOME schedule was unpredictable. Vendors did not know whether they should aim for the next version or focus on the previous version and backport fixes.
• Vendors had to backport many changes to a version that the GNOME project considered as old.

Solutions

• The project introduced a rigorous schedule promising a release every six months.
• There was a core team so few people had to agree to the introduction of a schedule.
• GNOME introduced policies to keep the development tree fairly stable.
• The project introduced the idea of reverting: if a feature was not ready on a certain cut-off date, it would be taken out again.
• The project gained credibility because releases were actually performed on time.
• The schedule allowed vendors better planning, and hence vendors could implement their features on the main development tree.

Outstanding problems

• The six month schedule has been successful in the delivery of incremental updates. There are some concerns whether this release cycle makes the project less innovative and ambitious regarding major changes that would lead to GNOME 3.0.

Theses days, I've been looking for a way to have crypto-containers in Debian. I wanted something easy to use, easy to move but still quite secure, which wouldn't require root access to the box, and as an option could use my gpg key.

I looked closely at two projects:

* cryptsetup/luks

The nice thing is that you only have one file containing all your crypted filesystem, it uses the Linux unified key management system (luks), and you are able to use a gpg key to crypt the data. I didn't tried it yet, because there are some drawbacks which I find really important. It uses multiple commands for every operations (creating the container, mounting and unmounting it).

For creating the crypto container you need to:
- create the file
- use it as a loop device (root access)
- initialize the container
- open the container
- create a filesystem on it
- mount it

Each time you want to mount it, you need to:
- create the loop device from the file
- open the container
- mount it

It surely can be wrapped, but that may be difficult to deploy. And you need root access for all operations (you can mount/umount without it using fstab, pmount or things like that, but still it's using privilegied access). And the major drawback, I think, is that the container size is fixed. You choose it when you create the initial file which you'll mount as a loop device. I don't know if there's a way to extend it after creating crypto-container, but anyway it'll need to be manual.

* encfs

encfs is fuse-based, so it doesn't require anything, beside fuse support in the kernel and your user belonging to fuse group. No need to root access nor anything. You create the container with only one command, then mount or umount it with only one command too. You can add and remove files from the container without asking yourself about disk usage or something, because the container is "expanded" (see after) when you add files, automatically.

There are two drawbacks in encfs, for me:
- crypto-container isn't a file, but a folder, with files and folders using crypted filenames but real size. (more or less, because you can use options to modify it but you won't hide a 20MB file for example). It's less secure than a one-file crypto-container where you can't determine how many files there are in it (and with crypsetup/luks, you won't be able to determine how much space is used in the container as the size is fixed anyway). It's less easy to move around, put on an usb key or transmit. You can tar it, yes, but you lose the comfort.
- you can't use a gpg key

In the end, I guess I'd like something like .dmg OSX Disk Images, which can be encrypted. They are really easy to use, as far as I could have seen. Maybe not so secure, but this is a bruteforce attack against master password (1024 bits RSA key), not against 128bits aes key of the container.

Anyway, I've setup an encfs folder here, but am still looking for something wich would improve the situation.

The design is now agreed with the weavers, but unfortunately I misunderstood the price-list, so the prices I've been quoting for hand-sewn 8-yard kilts, and machined lady's 4-yard kilt-skirts were too low -- the correct prices for those and a couple of other things being:

Hand-sewn, 8 yard kilt:	£420.00
Machined, 4-yard, skirt-kilt (lady's):	£237.50
Machined, 6-yard kilt:	£270.00
Waistcoat:	£113.00

I'm sorry about quoting prices without making absolutely sure they were correct, the reason was that I was quoting the prices for standard weaves from stock, and it turns out that the custom weaves are more expensive. That said, note that the machined kilts are £80.00 cheaper than the previously quoted price (for hand-sewn), and that these are perhaps more appropriate to the use to which many of us will be putting the kilts anyway (hand-sewn are really an evening dress item, after all) Even so, I'll probably still fork out for the full 8-yards, on the basis that my dinner jacket is falling to bits after 20 years wear, so I need something new anyway. In case you're wondering what on earth I'm talking about, this has been discussed elsewhere. Just to make sure there are no other nasty surprises, if you are of a more rotund nature, you may find that it will take some extra material to encompass your circumference -- as an example, a 7 yard machined gents kilt will cost an extra fiver to stitch, and an extra £25.00 for the yard of cloth, so will come in at £300.00 rather than the usual £270.00 Confused? Well, so was I --- The designer's sending me a fuller price list, which I will ensure than anyone on the list of currently interested people is fully conversant with before we put the order in, so don't panic that I'll spend your money without giving you a final chance to come to your senses ;-) I hope that doesn't result in everyone changing their minds, but I'll understand completely if it does. Alternatively, you could decide that this is an opportunity to save yourself £80.00 by opting for a machined kilt (which AIUI are still made to measure, but just have proportionately less work and material in them) Anyway I'll post any further developments here so as not to continue spamming the lists. So, if you're interested in getting hold of any of the above despite the new prices, and have not yet told me you need to mail me now! -- the order will probably go in at the end of the week.

... this is the problem

I just casually saw Norbert post about the ion3 querelle. This a very unfortunate example of collapsing interactions among upstreams and maintainers. My general advice (but for suggesting to use wmii or dwm instead of ion3 :-)) is avoiding packaging of development branches, but this is a decision which sometimes is difficult to take: some programs seems in development for years and stable releases could result largerly unusable or limited. Surely our - and generally speaking any distribution - release cycle and maintainance are not adequate for many on-the-edge software out there.

When upstreams releases [a]periodical milestones, those could be packaged, but upstream will not support them: we have already our problems in supporting regular releases for security independently by upstream for mainstream programs, without adding pieces of casual crap around.

Packaging a casual snapshots is out of question IMHO, but for using it in sid/experimental, so I can understand the upstream opinion, because many users report problem to upstream instead of maintainers. I see definitively no silver bullet anyway, but for maintainers' capability of understanding what should be packaged or not and opening an unbreakable communication channel with upstreams to be up-to-date in respect with upstream roadmap.

The GNU Compiler Collection (GCC) is a compiler suite which supports a number of programming languages, such as C and C++. It is a very important development tool and is the standard compiler among free software projects. GCC was quite stagnant in the middle of the 1990s until the EGCS project formed. EGCS took over development of the official GCC in October 1998 and instituted rigorous processes, such as high levels of peer review, and created a steering committee which has the power to appoint maintainers and make important decisions. In theory, the project follows a time based release with an interval of six months. In practice, the project has released only one new version every year in recent times.

Version	Date	Months
3.0	2001-06-18
3.1	2002-05-15	11
3.2	2002-08-14	3
3.3	2003-05-13	9
3.4.0	2004-04-18	11
4.0.0	2005-04-20	12
4.1.0	2006-02-28	10

Past problems

• The GCC project suffered from a closed development style in the past: few people could make code changes and the mailing list was by invitation only.
• There was a long time between releases and development snapshots, which contained bug fixes and features, were not available to the public.
• When development opened and picked up, significant code changes were often made which required a long stabilization phase.

Solutions

• The project moved to a more open development style and established a steering committee which has the power to appoint new maintainers and make important decisions.
• The development process was divided into three stages in order to coordinate code submissions and keep the development tree reasonable stable. Major changes that developers wish to make during stage 1 and stage 2 have to be proposed on the project's wiki. Proposals are reviewed by the release manager who also assign a sequence to proposed projects which says when they can be applied to the development tree.
• All patches are peer reviewed on the development mailing list and need approval before they can be applied. The steering committee appoints maintainers who can approve patches that touch particular areas. There are maintainers for the C front-end, various port maintainers, and maintainers for other areas.
• Each development stage lasts two months, theoretically yielding a release every six months. A regular release cycle ensures that it is not the end of the world if a feature does not make it into the following release.

Outstanding problems

• The release manager is busy and has not pushed the release forwards as much as would be possible.
• The branch criteria may need revision to make it easier to create a branch which leads to the next stable version. At the moment, the branch criteria is to have 100 or less regressions on the development tree. However, this number may include regressions that are also present in previous releases, which makes it fairly hard to reach this criteria.

I added the edit comments plugin to this blog. After you leave a comment, you’ll have about 12 hours to come back and make changes. Authentication is based on IP address. It’s surprising that so few blogs implement such functionality, given how common it is to leave embarrassing typos or misspelled URLs in comments. One patch is needed for the plugin to work with the latest Wordpress release. Specifically: $location = add_query_arg('jal_edit_comments', '', $_SERVER['HTTP_REFERER']); needs to be changed to: $location = add_query_arg('jal_edit_comments', FALSE, $_SERVER['HTTP_REFERER']); I’m sure this will be added to the mainline source soon. I had to fish the fix out of the 300+ comments on the page for the plugin. In other “this blog” news, I simplified the sidebar appearance and made all the long lists collapsed by default with CSS. Hopefully it renders well on all browsers. Lately, I’ve come to doubt the utility of “lists in sidebars” at all. Perhaps a person’s latest content preferences (books, film, music) aren’t that interesting after all. Incidentally, since I made the transition to Wordpress, I’ve found it much easier to keep this blog active. Less time spent on administrative issues, and the web-based (rather than ssh–>vim) posting just makes a lot more sense these days. Comment spam is virtually nonexistent. I can get an entry up in five minutes on the train in to work without hassle. Wordpress has also greatly reduced server load (perhaps because I had an inefficient blosxom setup). I recommend it. If you are already a Wordpress user, as a public service announcement I’ll repeat the announcement from about two weeks ago: Wordpress 2.1.1 may be dangerous:

Long story short: If you downloaded WordPress 2.1.1 within the past 3-4 days, your files may include a security exploit that was added by a cracker, and you should upgrade all of your files to 2.1.2 immediately.

Using XMPP4R, I did some stats about Jabber clients usage on the Apinc Jabber server, which hosts im.apinc.org, jabber.fr, and many more using virtual hosting. I already did similar stats in March 2006 and September 2005. The poll was done by sending jabber:iq:version to online users, around 1:00 PM (french local time, most of the users are french). 1343 clients were pinged, and 1315 answered, which is better than last year (1145 answers). Of the 1145 jids that answered last year, 368 were also part of the poll this year (I don’t know if this is good, or not enough). Systems:

• GNU/Linux: 43% (2006: 38% ; 2005: 34%)
• Windows: 35% (2006: 37% ; 2005: 34%)
• Mac OS: 16% (2006: 18% ; 2005: 23%)
• Unknown: 4 (2006: 5% ; 2005: 6%)
• Others: 0% (12 clients ; 2006: 0% ; 2005: 1%)

Clients:

• Psi: 24% (2006: 28% ; 2005: 28%)
• gaim: 22% (2006: 25% ; 2005: 25%)
• Gajim: 12% (2006: 5% ; 2005: 3%)
• Kopete: 11% (2006: 7% ; 2005: 7%)
• iChatAgent: 9% (2006: 13% ; 2005: 18%)
• libgaim (Adium): 5% (2006: 4% ; 2005: 3%)
• Pandion: 4% (2006: 4% ; 2005: 2%)
• Miranda: 2% (2006: 2% ; 2005: 1%)
• BitlBee: 2%
• neos: 1%
• Unknown client: 0%
• Exodus: 0%
• Imendio Gossip: 0%
• Jabbin: 0%
• Spark IM Client: 0%
• Trillian: 0%
• JBother: 0%
• jabber.el: 0%
• JETI: 0%
• JAJC: 0%
• Class.Jabber.PHP: 0%
• Jabberwocky: 0%
• Tkabber: 0%
• Gush: 0%

(all clients with at least one reply are listed here) I also did some stats on the Linux distros. With 566 Linux users, one can consider that statistically signifiant.

• Client answers with the kernel version, not including distribution information: 62%
• Debian: 14%
• Ubuntu: 12%
• Gentoo: 2%
• Unknown distros (not provided by the client): 2%
• Fedora Core: 1%
• Arch Linux: 1%
• Mandriva: 1% (despite the fact that most users are french!)
• Slackware: 0%

(Other distros are below 5 replies) The Debian/Ubuntu situation is interesting. Debian is not dying, even on the desktop ! The server is hosting jabber.ubuntu-fr.org, so the results are biased towards Ubuntu. Update: it seems that Psi reports “Debian GNU/Linux (testing/unstable)” even when running on Ubuntu. This is the case for ~5% of linux users. To server admins: if you are running a large jabber server with jabberd 1.6, it’s easy to give me the right to get the list of online users, so contact me if your are interested in me doing your users stats. It would be interesting to see if users from different servers/countries have different behaviours. I’m not sure if it’s possible with ejabberd and other servers.

Yes, that’s it, I’m finally Debian developer. I would like to use this post to say thanks to everyone who helped me to achieve this goal since I applied in 2005-10-05, here we go! Thanks to…

• Ricardo C rdenes, the man who linked me to Debian development world and, of course, my advocate.
• Moray Allan, my responsible AM.
• The NM Staff (Myon, HE, Ganneff, Elmo…)
• My usual sponsors: Ricardo, Ana, Amaya, Mones, Gunnar….

I hope to write an small report about the NM process with my impressions and opinions soon, so stay tuned. By the way, if you are planning to join Debian and you’re able to meet me, I’m offering GPG key signing since today :) Finally, thanks to all my #dudes!