Via Russel Coker. A. Copy the list below to your own journal and Bold the actions you are already taking
Underline the actions you plan to start taking
Italicize the actions that don't apply to you B. Add one (or more) suggested action(s) of your own C. Leave a comment here, so that she can track the meme to your journal, and copy your suggested action(s) back to my master list.

1. Replace standard incandescent light bulbs with compact fluorescent light bulbs - my room has a 12 W bulb. How much watts do you need for lighting?
2. Choose energy efficient appliances
3. Wash clothes in cold(er) water
4. Turn the thermostat of your hot water tank down to 50 C (125 F)
5. Install a programmable thermostat (or turn the heat down over night and when you're out of the house) - it is often sufficient to have the heater go on at like 7 at night and 5 in the morning for an hour each
6. Register with the [Canadian Marketing Association's] Do Not Contact Service to reduce the amount of junk mail delivered to your house. - Substitute MPS.
7. Eat less meat (particularly feedlot beef) - it's a lot healthier anyway. I enjoy the occasional steak, but you actually enjoy any taste more if you have more variance
8. Walk, bike, carpool or take public transit as often as possible - I don't have a car. If I need to transport something big, I borrow one. I do my regular shopping via bicycle or public transit, which saves me looking for a parking space etc. anyway. Also note that when using public transit, you can work a bit, read a book, enjoy some music, ... and you arrive less stressed out than when driving a car.
9. Make sure you know what can be recycled in your area, and try to recycle as much household waste as possible
10. Compost using an outdoor compost bin or an indoor vermicomposter - at my parents
11. Clean or replace filters on your furnace and air conditioner
12. Buy local, organic or fair trade food where possible - tastes much better anyway
13. Reduce air travel - pity that long-distance trains suck in Australia
14. Wrap your water heater in an insulation blanket
15. Use a clothesline instead of a dryer whenever possible - don't own a clothes dryer, hanging up clothes inside near a heater works on cold days - you often can do without ironing, too, by hanging them on a clothes hanger for drying they'll often be reasonably straight. My washing mashine has a program helping at that, too. It uses 40 C and takes just about .8 kWh and is called "easy iron".
16. Plant a tree - pity my trees are dying because of the drought / climate change
17. Buy fresh foods instead of frozen - especially with meat I do really notice a better taste
18. Keep your car tuned up and your tires inflated to their optimal pressure - I don't have or need a car
19. Use biodegradable dishwashing liquid, laundry soap powder, etc. - causes less allergies
20. Drink tap water (filtered if necessary) rather than buying bottled water - our tap water here in Munich is better than bottled water anyway, and it saves you from carrying it, too.
21. Turn the tap off while brushing your teeth
22. Unplug seldom-used appliances and chargers for phones, cameras, etc., when you're not using them - consider to use a master switch for them
23. Plug air leeks and drafts around doors and windows with weatherstripping
24. Switch from disposable to reusable products: food and beverage containers, cups, plates, writing pens, razors, diapers, towels, shopping bags, etc. - especially shopping bags and beverage containers is easy
25. Consider garage sales, Freecycle, eBay, or borrowing from friends/family before buying a new tool or appliance - saves energy and money
26. Reuse bathwater, maybe to flush the loo, water the garden, etc.
27. Make sure your roof is well-insulated.
28. Always wear a jumper/sweater and socks indoors unless it's warm enough outdoors to go without both. - and turn down the heater a bit, it saves a lot of energy and money. Sweater and socks are quite comfortable...
29. Run your vehicle on biofuel/sustainable fuels
30. Set up a grey water barrel to use when clean water isn't necessary
31. Put grey water on your garden immediately without storing it.
32. Install tanks to collect rain-water from your roof for watering the garden, washing your car, etc. (at my parents; we also installed an overflow valve which will automatically redirect overflow water to plants that can always use more water)
33. Don't keep windows open when your heater is on - especially don't keep them half-open. If you want better air, turn off the heater and open the windows for a few minutes completely. This will quickly refersh the air in the room. Then close the window and turn the heater on again.
34. Turn off light that you don't need
35. Stop your engine when waiting more than 10 seconds - for example at train crossings; maybe doesn't apply to Diesel as much because it relies on a operating temperatrue, but I doubt it cools down that quickly
36. Install a solar panel on your roof for water heating - especially in summer or in sunny regions, this will allow you to completely turn off the heater during summer or even most of the year. A solar water heater will easily heat your water to 60 C (on hot days we reach 70 or 80 C), while even keeping your house a bit cooler). It can be installed yourself. At the same time, maybe add insulation to your pipes. If you minimize temperature loss over night, you'll even have warm water left in the morning.
37. Use air circulation for cooling - much cooling can be achieved by having a good air flow, wearing appropriate clothing and avoiding heavy work during the hot hours. Consider doing a siesta and work in the morning and evening
38. Ask your bank for an online-only account - some banks even offer lower fees if you don't use paper-based banking
39. Try to make more use of daylight - that's like free light, you know.
40. Walk and run more - it's healthy, saves you fitness club costs and it saves some energy if you are not using the lift. Walk to the supermarket or fitness club!
41. Use your local recreational facilities - there are probably nice parks nearby where you can go running, maybe some place to go climbing nearby, some pool, ...; this can be an interesting alternative to watching a movie, too
42. Use the refridgerator smartly - don't leave it open when not necessary, and keep the temperature only as low as you need it. Bring all your shopping into the house, sort it, and then open the refridgerator and put it all in in one go, for example.
43. Learn how to cook energy efficient - for example, if you plan ahead you can put frozen foods into the refridgerator to defrost at virtually no power cost. It's also better for the food. Use lids when boiling water; you can also use it often for cooking if you turn down the heat. For rice, I usually put on the lid, and when the water is boiling I can turn the heat off again. With the lid on, the rice will end up cooked just fine. Also pick an appropriate applicance. A real water cooker will be more power efficient for making your tea than putting a small pot on a large flame.

I've been using Debian for about 10 years now. Debian was my first Linux distribution. For about 7 years I've been running a Debian m68k buildd now. For some time now I've been worrying about Debian and its future.
IMHO, there are several reasons to worry about its future.
a) Release cycles.
Funny enough Martin Michlmayr wrote today about Gnome release cycles. Apparently Gnome suffered from similar problems in Gnome 1.x times as Debian still does today. The big difference between Gnome and Debian is: Gnome has actually learned from its mistakes and changed its release model to something better. Really. I don't use "better" very often in conjunction with "Gnome", but in this regard, the Gnome project did really something good.
Debian, on the other hand, suffers more and more from its "release everything for all when it's ready" syndrome. Releases are always delayed, it's a big chunk of work for everyone involved, Debian is losing users because of the delays and so on...
b) Debian as a base for other distributions.
Lately, several distributions announced, that they will use Ubuntu as a base for their own distribution and not Debian any longer.
c) Internal problems.
Debian has many internal problems. Many of them have to do with communication problems. Others with "you can't force anyone to do anything in Debian" ideology. Some with unresponsive persons in key positions. Some problems are a mixture of all the above. Altogether, these problems are causing that many developers are losing their fun in the long run.
d) Flame wars.
Well, actually this could be listed in b) Internel problems as well, but it's a massive problem of itself, so I think it deserves its own section. Flame wars are really time consuming and destructive. I know what I say. Been there, done that.
e) Getting new people in.
It is often said, that there are >1000 Debian Developers. The truth is that many of them are inactive or MIA. There was a proposal lately to find those inactive DDs and handle them accordingly. Given this fact of many, many inactive DDs means, that there is more work for those left. To solve this problem of overworked DDs (it's another truth, that some DDs are very active and have far too many jobs within Debian), Debian needs to attract more people and encourage people to contribute. Currently, it's not that easy for people to contribute, because of bureaucratic formalisms like sponsored uploads and such. Additionally, not everyone willing to help wants to do packaging or other tasks. There is a lot of other work to do like making graphics, organizing booths or other events, etc. Currently those tasks are mostly done by DDs that could better spent their time on developing Debian itself (packaging, porting, ...).

Ok, enough for now. But how can those problems be solved?
ad a)
Martin mentioned in his post about the Gnome Release management, that they changed from "release when it's ready" to time based releases and gained credibility because of this.
I think, Debian would benefit as well from this type of release management. Additionally, every Developer can react to this new method and make his packages fit for the release because he knows "Hey! Just 4 weeks until the release! Let's get my packages ready for it!"
Another problem, IMHO, is the "release all packages for all archs at one time" problem. This lead to the drop of m68k for etch (via some obscure circumstances like a very broken gcc 4.0 version and some strange release criteria, sometimes referenced as Vancouver Massacre).
Someone of the contestants for the new DPL job mentioned in his world domination plan to have a stable release of some basic components every year and having sub-releases for desktop environments (KDE, Gnome, XFCE...) every 6 months. Basically I believe that this is the way to go. You can discuss the time frames, of course. Release a stable base every year or every 2 years? But really, I think this would be the best way to deal with many problems Debian has.
If every 1-2 years a new stable base would be released, everyone could be happy: the admins with long release cycles for their servers, the users with faster releases for their desktops and (maybe) the porters who can (maybe) omit a subrelease of the desktop apps and concentrate on porting the base system if needed. Really. 15000 packages for (let's say) 15 archs is way too much work for everyone.

ad b)
With the above mentioned changes, Debian could re-gain some more market share and users from other distributions like Ubuntu - and be a base for distributions again. The reputation of Debian would rise again, because the releases wouldn't be delayed again.
I think it would be ok for smaller ports (like m68k) to release differently than the main archs (i386, amd64, ppc, arm): if every year a new stable base release would be done, it could be ok for them to skip a release, if necessary. Of course, details must be elaborated more in detail.

ad c)
There are many internal problems. The most urgent one is "bad communication". Needless to say that it's very important to communicate with your work mates to get your work done. If someone fails basic communication skills (answering questions about the stuff s/he is responsible for) in a reasonable time frame, s/he's simply the wrong person in that position and should be replaced. Of course this interfere with the current understanding of "not being able to be forced to do things" in Debian. People should change their mind about that.
Basically, it's similar to NMUs: if a package maintainer fails to fulfill his responsibilities (fixing bugs), he can either be enforced to fix the problem in that package by a bugreport or he can somewhat be replaced by doing a NMU when he's not fulfilling his duties. If he fails often to get his package into a good shape, he can be replaced permanently by hijacking the package.
Or to give a real world example: If you are holding a honorary post, let's say, you're doing the financial paper work for your soccer club, you can't say "Oh no... I don't have the time to do the tax declaration now or the next month...". That just doesn't work. Either you do your duties on time or you need to step down from that post. Otherwise you would do damage to your club. This is valid for other volunteer organisations as well, like Debian. Do your duties on time or step down from your post.

ad d)
Well, I'm not innocent when speaking about flame wars. Anyway, people can learn and change their mind. Flame wars are really bad in Debian, but it seems to be something like a sport to me sometimes. And usually it needs two parties for a flame war. That's the reason why I believe that expelling a fellow DD because they were involved in some major flame wars in the past is simply wrong. Either expel all parties or none.
A party is not only involved when answering to mails on mailing lists, but also when doing stuff that forces the other party to react - for example by starting a flame war on a mailing list. There's always action and always reaction. Therefore you can't disjoin both and just judge upon one party.
When a mediation is tempted, both parties are required to obey the mediators decision. Of course there should be a fair decision that honors both sides. Both sides have to give in for a successful mediation attempt. If that's not the case, the mediator failed. Not obeying to the mediators decision, because "no-one can be forced to do anything in Debian" (see above), is plainly wrong.
Anyway, most people should know of what I'm speaking here. I think it's plainly wrong to expel developers that have done really great work in the past due to some flame wars. Debian as a community has failed when it chooses this ultima ratio. Debian just proves that it is unable to establish a community where people can work together, when developers are going to get expelled because they thing that a mischief was done to him.
How would you feel and react when someone would play bad games on you? Wouldn't you yell loudly as well?
So, how can something like this be avoided? Maybe a Code of Conduct could help, maybe that CoC wouldn't be necessary when everyone would be nice to anyone and remember that there's a human being each mail with feelings and emotions?
Anyway, Debian needs to abandon flame wars in general.

ad e)
Well, I've already written a little bit about this problem above. There are many tasks in Debian that doesn't need technical excellence of packaging details - instead it needs excellence in social skills. Something that many technically focussed people are missing. Debian needs to become more attractive to those kind of people that are good at this non-technical issues and encourage them to join the project - and not to frighten them away by a very technical and bureaucratic procedure like the current NM process. Those kind of people won't wait some years to be actually being able to do work. They will just go on and find a place where their skills are better welcomed.


Ok, that's for now, I think... it's been a long post and therefore I've used folding for it.

Conclusion:
Well, not a nice one. Debian needs big changes in its structure and the candidates for the upcoming DPL elections identified some of them and put them on their agenda for their DPL period (if they win, of course). But the history showed that none of the past DPLs had really the power or the will to push big changes and made hard decisions. So, after all everything will stay as it is now. Nothing will change for the better, I fear. Users will leave Debian because of its stale release cycles, more and more Debian-based distributions will change their base to Ubuntu and Debian will become more and more irrelevant over time instead of being a strong participant in the free software world.

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.

In a previous entry, I explained how you can be assimilated to an Ubuntu developer without even being an official Debian developer, and of course without prior notice. I am now quite ashamed: I have just discovered that this was already discussed some time ago (read: months before my post), and led to the following results:

• If the package is in universe or multiverse, the Maintainer field will be set to Ubuntu MOTU Developers

• If the Maintainer field is modified, the old value will be saved in a field named XSBC-Original-Maintainer

However, packages where my name appears either in the Maintainer or in the XSBC-Original-Maintainer field still “belong” to me in Launchpad (see https://launchpad.net/~julienv/+packages for example).
However, I am not responsible for the bugs of these packages (see https://bugs.launchpad.net/~julienv/+assignedbugs) Now that my blog is syndicated on Planet Debian, I ask it again:

Am I supposed to look on Launchpad for bugs reported against the packages I maintain in Debian?

Obviously, if a bug wasn’t reported by a Debian user, it might mean nobody suffers from it, but fixing it could avoid future bug report anyway (except if this particular bug is very specific to Ubuntu). In order to improve the Debian maintainers’ work, I think it would be great that the PTS integrates the bugs in Launchpad in a simple way. This would allow us to easily subscribe to the bugs, and eventually get a notice if the bug is fixed, or at least allow us to be aware of the issue.

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.

Erich Schubert comments on the issues relating to getting big changes into Debian. This is something that I had also noticed. I started work on SE Linux in Debian in 2001 and continued it actively until 2003 when I joined Red Hat. Less than a year after I joined Red Hat there was a Fedora release with SE Linux fully integrated and shortly after that there was a release with SE Linux on by default. The reason for this was that Red Hat management supported the idea of SE Linux and everyone had to accept it. There was no option for a package maintainer to refuse to support SE Linux.

Recently in a discussion on debian-devel one DD (who I won't name in this blog post) advocated removing SE Linux support from dpkg. I then asked him whether he had the same attitude towards non-executable stack
(Exec-Shield/PaX/OpenWall), Poly-Instantiated directories, and PIE executables. When he expressed interest in having those features I pointed out that one of the enemies of security in Debian is the fact that every person controls their little area and has no requirement to work towards common goals (apart from the most obvious ones of making the system work).

This means that instead of having a little cooperation from other developers anyone who wants to get a significant change included will have to fight hundreds of battles.

SE Linux is a classic example of this. Debian could have had SE Linux support long before Fedora, but instead it gets it long afterwards.

The same battles occur with regard to all the other security measures I mentioned (and some others I didn't). We could made Debian the most secure Linux distribution, there are many people who have the skills and the interest in doing so.

If you want features such as exec-shield, then you are missing out - largely because the people with the skill and time to work on them are too busy fighting trench-warfare rather than actively coding.

Now while I strongly object to most incarnations of the "you can't force a volunteer to do anything" meme that infects Debian I do agree that we can't force developers to write new code. We can however strongly discourate an antagonistic attitude towards new features. If someone proposes a feature
that you don't plan to use but which doesn't hurt you then there's no reason to attack - you can just ignore it. If someone sends in a patch that adds a feature which is requested by many people but you personally don't use, then if it has little or no down-side (linking against a couple of shared objects as is the case for many SE Linux enabled programs provides no measurable overhead) and the code is good it should be merged!

The real problem is that some DDs are more concerned about what is best for them personally (in the most short-term manner) than about what is best for the users.

The aim of Debian is to integrate software produced by other projects to create a complete operating system based on free software. In recent years, the project has faced increasingly delayed and unpredictable releases. Most notably, the release process of Debian 3.1 was characterized by major delays. Initially announced for December 1, 2003, the software was finally released in June 2005: a delay of one and a half years. Since then, the project has made a number of improvements to its release process.

Version	Date	Months
1.1	1996-06-17
1.2	1996-12-12	6
1.3	1997-06-02	6
2.0	1998-07-24	14
2.1	1999-03-09	7
2.2	2000-08-14	17
3.0	2002-07-19	23
3.1	2005-06-06	35

Past Problems

• Release management was not very organized and release updates were posted only infrequently. Because of this and the lack of a roadmap, freezes were often announced out of the blue.
• Due to the unorganized nature of the release, several new and unexpected blockers were found during the release process, leading to delays.
• The unexpected delays meant that software was frozen for a long time, in the case of Debian 3.1 for over a year. When this release was finally published, many components were already out of date and would often not meet user demands.
• The fact that Debian has experienced significant delays with several of its recent releases has led to problems with the image of the project. There is a perception that Debian is slow and cannot meet deadlines. This is also associated with frustration in the developer and user community.

Solutions

• The project has implemented better release management structures. In particular, Debian moved from a single release manager to a team during the 3.1 release cycle. The release is now handled by two release managers with the help of several release assistants.
• A release date for the next release was set well in advance and there is more planning.
• Release announcements are sent more frequently and various information sources have been implemented through which developers can stay informed about the release status.
• Release targets have been defined better and there is a distinction between blockers and goals. Only blockers hold up the release whereas goals can be postponed for a future release. For example, the XFree86 to X.org transition and the integration of AMD64 support were blockers, while LSB 3.1 compatibility and SE Linux support were only goals for Debian 4.0.
• The release team has shifted the responsibility of achieving targets to specific developers and teams. There are also better criteria now defining these responsibilities. For example, criteria have been published that architectures need to fulfil for inclusion in Debian 4.0 and there is a page indicating the status of each architecture.
• The release team is increasingly giving encouragement to developers to help out with software packages and bugs which normally do not fall into their domain.
• A staged freeze has been implemented according to which software is frozen in stages according to its importance. The toolchain and base system are frozen earlier than the majority of package. The majority of software is now frozen when most blockers have been resolved.
• The use of the experimental repository has been promoted to make sure that the main development repository is in a good shape most of the time.

Outstanding problems

• Developers still need to be convinced that targets can be met, that deadlines are real and that Debian can release on time.

I was the maintainer of minit for some time, and spent some time adding some runit-like functionality to minit I then called "enitdir". It worked similar to runit (IIRC, maybe it was a different init). Basically you had a directory for each runlevel, which contained symlinks to all services supposed to be running. There is a symlink called "current" or something pointing to the current runlevel. enitdir monitored this symlink and the directories contents via dnotify, so it supposedly was both very fast and efficient at noticing changes there. Switching runlevels was as easy as "ln -snf current foobar"; starting and stopping services worked by removing the symlinks in the current runlevel or manually calling minit (for non-persistent changes, restarts, etc.) (I think I never uploaded a package with any of this, the minit packages remained really close to upstream. I intended to do a fork/rewrite named enit, but never got around to it. Many of my ideas are addressed by upstart.) However this didn't solve some integration issues. First of all, not all packages back then were using invoke-rc.d; this should be a lot better nowadays. But the major issues lie within handling multiple inits on one system. There is a hook that applications could use to prevent init scripts from running (which might be the answer to Wouters iniscripts post). It's called "policy-rc.d". However there are some things wrong with this approach: it doesn't really support the installation of multiple inits or handles the problems of switching between inits in any way. Basically, the moment we need to switch inits (and thus service startup/stopping behaviour!) is during reboot. While the old init is still running, any start/stop operations MUST still use the method appropriate for the current init system. Otherwise, major bugs can occur, especially with smarter init systems that respawn services. E.g. the user runs "apt-get install sysvinit mysql-server". Lets assume sysvinit has a debconf prompt 'make me the default init' and the user says yes. Next mysql-server is upgraded, during which it calls the sysvinit way of stopping the service (i.e. /etc/init.d/mysql-sever stop), then does some dangerous things to the database, then restarts the server. However, a smart init such as minit (when equipped with appropriate service files) will notice the mysql-server process dying and immediately restart it (notified by kernel, efficient and fast) while the upgrade script is still messing with the database files. Boom, there goes your database. I guess you got the point. So we probably need a smarter invoke-rc.d script. It should support

• init detection - figure out which init is running, e.g. by comparing the inode of /proc/1/exe to the inode of /sbin/init.* (current init doesn't need to be named /sbin/init, but note that this magic might break on upgrades. Fallback to readlink(/proc/1/exe) maybe?)
• different init behaviours. The current policy-rc.d hook is pretty much a yes/no hook. Instead it should call the appropriate init-specific invoke tool.

Such an invoke tool could then for example look like this:

if [ -e "/etc/enit/service/$1" ]; then
    enitctl start $1
else
    /etc/init.d/$1 start
fi

You get the idea, having the policy script figure handle compability for services that don't have an appropriate service description for this init system yet. (Yes, s/start/$2/ or something, above is pretty dumb, but helps bringing my idea over).

Maks: You're welcome! This is not actually my current playlist or top 10 (or top 11) though. It's really just the songs that put most strain on said pneumatic thingy by having a rhythm that is on the one hand catchy enough to make me bounce along and on the other hand slow enough to be "doinged" with an office chair. (NOFX's Don't call me white is a good example for a totally undoingable song. The classic punk rhythm generally is just way too fast to be rendered on an office chair without stopping to type. Thinking about it, I guess Ska sucks by Propaghandi roughly marks the line between doingability and undoingability) The word creations in this post are especially dedicated to Clint. A surreal salute!

I have a Debian wish for lenny:

• define and deploy a standard way of packaging software, that can be used for like 90% of packages. (It doesn't 'have' to be CDBS, it can be something 'better' for a reasonable definition of better. CDBS is the closest of the packaging tools I've tried so far, I've had single line package scripts with CDBS for many packages)
• Put the maintainer scripts into version control, it should be something with a central repository, but that of course allows maintainers to easily do a local branch. Especially for backports. Maybe SVN with SVK is okay.
• Use a standardized patch system along with a toolchain, quilt-like
• Link this patch management to upstream watching, so that patches applied upstream can automatically 'disappear'

Why do we really have to make a distinction between NMUs and maintainer uploads? I agree that we need to have someone (which can be a group) be responsible for packages and need to keep track of that to detect unmaintained packages (as well as to have someone track bug reports). With this central repository, we could have NMUs committed to the packages directly, and make contribution easier in general. For example, right now transations are usually added to a package via a bug report. The maintainer then needs to go through these bug reports (and some packages have so many open bugs I doubt the maintainer has a real overview over them; so he might easily miss some easy to fix ones), extract the patch and apply it to his package after review. With this central patch tracking system, the translators could just commit the translation change to the package directly, and it will end up in the next upload automatically. (Note that I'm not trying to force all packages to be maintained this way. I agree that for some packages it's not really appropriate. In general it should be left to the maintainers discretion. However I guess many team-maintained packages are handled in a similar way already, and I'd like to use that for my packages as well, even when not having Co-Maintainers. I'm also aware that when fixing security issues, you might not want to make your changes world visible immediately. This can however be done using SVK if we end up using SVN, for example.) Some rationale for this suggestion:

• Promotes team maintainance
• Offers another easy way of contribution (especially for sponsorees)
• Better change and version tracking
• Standard way of packaging makes NMUs and adoption easier
• Makes it easier to work on many packages when needed (e.g. new GCC version fixes, porters, translations, upstart support, SELinux support, Python, all kinds of transitions)

In fact I think that other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes. Anyway, just my € 0.02 [Yes, I'm aware that this was covered in the DPL debate, but IMHO the point of different packaging preferences falls a bit short, and probably needs to be addressed first, before being able to have a central VCS for all packages. Also I think we should be able to find a common VCS we can all live with, or at least 90% of packages.] [And yes, I'm aware that this is a controversial topic that can easily start yet another flameware. But we need to find a way of keeping flamewars down anyway...]

I've started using Yahoo Pipes today, and it's pretty cool. I wouldn't go so far as to call it a "milestone in the history of the Internet", but there are a few interesting use cases. Say for example if you're an avid reader of Planet Debian and you don't like the French Revolutionary Calendar, then you can use Pipes to filter out entries whose title matches a French Revolutionary month and enjoy a 100% revolution-free Planet. Or you could split matching entries into a separate feed, or just use regexp replacement to translate them into something else, etc. The possibilities are endless.

There's also a handy Babelfish module, so you can create a pipe that takes Planet Debian, translates it to French, then back to English. Hours of fun!

Creating a simple SE Linux policy module is not difficult.

audit(1173571340.836:12855): avc: denied execute for pid=5678 comm="spf-policy.pl" name="hostname" dev=hda ino=1234 scontext=root:system_r:postfix_master_t:s0 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file

For example I had a server with the above messages in the kernel message log from the spf-policy program (run from Postfix) trying to run the "hostnme" program. So I ran the following command to generate a .te file (SE Linux policy source):

dmesg grep spf.policy audit2allow -m local > local.te

The -m option to audit2allow instructs it to create a policy module. The local.te file is below:

module local 1.0;

require  
      class file execute;
      type hostname_exec_t;
      type postfix_master_t;
      role system_r;
 ;

allow postfix_master_t hostname_exec_t:file execute;

Then I used the following commands to create a policy module and package it:

checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod

The result was the object file local.pp and in intermediate file local.mod (which incidentally can be removed once the build is finished).

After creating the module I used the following command to link it with the running policy and load it into the kernel:

semodule -i ./local.pp

As the first step in moving my automated d-i install testing away from the dilab and over to emulation, I've added support to the d-i regression tester (digress) to use qemu for serial-console based CDROM installation tests. It was fairly straightforward to do that, since digress already supported bochs and hercules. I don't currently have an enourmous fast machine I can run qemu on. Actually, all of my servers, including my only amd64 server, have xen on them, which isn't ideal in combination with qemu (no kqemu..). So I thought I'd put this out as a howto, in the hope that lots of people will set up their own automated tests. If you do, please mail me and let me know, and I will aggregate all the tests together into a nice status page. Here's how to set it up:

• sudo apt-get install qemu subversion libexpect-perl expect lockfile-progs
• sudo apt-get install kqemu-modules-2.6.18-4-686 # or similar, using unstable
• sudo modprobe kqemu
• svn co svn+ssh://svn.debian.org/d-i/trunk/scripts/digress
• Now edit digress/schemes/qemu/common, and set ISO to point to the CD image you want to test. You may also want to tune QEMU_DISK_SIZE, QEMU_EXTRA_PARAMS, STAGE_1_MAX_TIME, STAGE_2_MAX_TIME, and USER_PASSWORD. digress's README has more details about all the config options.
• Also edit digress/schemes/qemu/d-i, and change "url=kodama" to control where d-i will download its preseed file from. Until qemu bug #414342 is fixed, it can't support colons or slashes in the url to the preseed file, so the example is taking advantage of the default url guessing in d-i, which will look in eg http://kodama/d-i/etch/./preseed.cfg. Put in your hostname and set up a preseed file. digress/preseed.cfg is a reasonable starting point.
• To start a test, run ./test-harness qemu d-i
• The test will proceed automatically; digress will hit Enter at any prompts. Your preseed file should take care of any other choices.
• To cron the test, run cd ~/digress; ./daily-tests qemu d-i (be sure to update the CD image too). This will drop logs into digress/logs, and if you put that directory up on the web, I can produce a nice status page.

(Wonder if I should make a package of digress?) A few ideas for things to test:

• netinst iso
• businesscard iso
• netboot mini iso
• true netboot (qemu -boot n)
• gnome desktop install
• kde desktop install
• xfce desktop install
• web server install
• lvm
• raid
• small disk
• lowmem
• amd64
• lilo
• all kinds of fun combos of the above, like lowmem gnome+web server install on lvm

I listened to my YP-U2 quite a bit on my recent travels. It worked fairly well. On my return, I remembered that I had a few comments to post from my old YP-U2 upgrade problems article... David Weinehall wrote:

"FWIW, my YP-U2 also has problems playing some oggs (nothing low bit-rate about them though; they're encoded with -q6); this is with version 1.418 of the firmware =/ On Samsung's site there seems to be a new version (1.43) available; too bad they don't mention what has been fixed."

dann frazier commented:

"Links/discussion about ogg support in these device can be found here: http://wiki.xiph.org/index.php/Talk:PortablePlayersSamsungYepp#YP-U2 I had to use a friend's Windows computer to do the upgrade :("

Erik Rossen writes:

"I have a Samsung YP-U2RZW (code for YP-U2, with Radio, 1GB of space, White case) that I bought today. The firmware version is "1.41 EU" according to system/system.var. And playback of medium quality OGG (44100 Hz, ~160032 bps) has serious stuttering problems. The latest firmware available on the UK Samsung site is 1.43. I too would love to know what files to copy to system/ (or wherever) so that I could do the upgrade from Linux, but I am probably going to end up booting WinXP for this task."

Scott Testerman comments:

"I don't have one of these players, but I wonder if this post is of any help to you? http://err.no/personal/blog/tech/2006-12-13-22-25_Samsung_Z5F.html"

Interesting, but sadly, the YP-U2 upgrades I have don't include a dat file. I wonder if this is what Samsung's support engineer was trying when he told me to copy all the files to the device's root. Does anyone have more info? Last time I chased Samsung about their promise of Linux upgrade instructions, I was asked to phone back in an evening when the member of staff who promised would be there. I still haven't had time to do that (there are other things to do most evenings - why won't they call me?). As far as I can tell, Samsung's Linux upgrade support sucks. I've bought a few Samsung devices and been fairly happy (far better than Canon, for example), but if I buy one again, I'll expect upgrades not to work.

Problem:
accessing a PostgreSQL database from OpenOffice.org base under Debian.

Solution:
apt-get install unixodbc odbc-postgresql
# odbcinst -i -d -f /usr/share/psqlodbc/odbcinst.ini.template
$ cat /usr/share/doc/odbc-postgresql/examples/odbc.ini.template >> ~/.odbc.ini


1. Set connection parameters in ~/.odbc.ini (username, password, host...)
2. Check "Connect to an existing database" from the oobase Database Wizard, select ODBC, click on "Browse".

At this point your PostgreSQL database should be listed among the available data sources.
Yay!

I recently wrote an article or two about distributed version control systems.

I've been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.

However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.

So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn't (or isn't very well). Also, git is complex to pick up for me, and I certainly don't want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it's had for awhile, and I couldn't find even one advantage of it over Mercurial. So off I went with Mercurial.

I quickly learned a bit of a philosophical difference from Darcs to Mercurial.

Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.

It is exactly this Darcs behavior that permits both is excellent "darcs send" feature (still unmatched in any other VCS), but also causes its hang problems.

I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.

It is easy to get started with Mercurial. The mq system -- similar to quilt or other patch-management programs -- is really quite an amazing hybrid between patch management and version control. I frankly don't see any need for other patch-management tools anymore.

Mercurial has a "patchbomb" feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.

I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I'm going to keep my personal code in Darcs for the moment because "darcs send" is still easier than "hg email", but that may change before long, depending on how my experience goes.

I'd encourage others to give Mercurial a try. The community is also very nice and helpful.

I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.

In a recent article I explained some of the mechanics behind putting together the schedule for XTech 2007. We've just added new visualization features to Expectnation that make proposal choice easier, and I thought I'd show some examples from the XTech 2007 review voting. Sparklines, devised by Edward Tufte, are thumbnail sketches of data that succinctly convey patterns. When Nat Torkington used sparklines to show reviewer voting patterns for OSCON program committee, it seemed a helpful addition to make to Expectnation. The profile of each reviewer is interesting — are they a harsh marker, or liberal with the top grades? — but sparklines really come into their own when drawn per proposal. Here are some small screenshots from this year's XTech voting, anonymized of course.
High flyers Reviewers are pretty unanimous about this proposal, as 4.0 is the top grade in our scoring system. The lack of variance suggests that I ought to ensure that all the assigned reviewers put in their scores — this could be just one person voting.  These next two are the pretty typical distribution for highly graded proposals: mostly top marks and a few average ones.  Middle rankingSome of the more interesting trends show up when the scoring isn't biased to either the top or bottom ends of the scale.  The reviewers are unanimous about this paper's soundness. It's not made anyone go "wow", but there's nothing to grumble about either.  This proposal clearly polarises opinion, and is such stands a better chance than the unanimous 3.0 above. Perhaps the subject matter or approach is controversial or timely.
Another proposal that divides the reviewers' opinions. It's also worth me checking here that I don't either have a pathologically strict reviewer, or at the other end, a reviewer with a wild passion for the cause this paper advocates.  Low scoring The quality of submissions is usually so good that I don't give low graded proposals much attention, but the sparklines could alert me to potential oversights. This proposal seems to polarise opinion between "rubbish" and "ok", so it's interesting to me to check out the subject matter and see if I'm missing something with potential.  These proposals were not received at all well.In summary, I'm delighted to find a solid practical application for sparklines. My thanks to Nat Torkington for the inspiration. 

After asking for useable CA Software, I have finally settled on using EasyRSA. This is what I did to come across the packaging shortcomings of EasyRSA in Debian. Storing your CA Be sure that your CA is stored in a secure place. Don’t store it online, and make it accessible only to yourself. In my opinion, storing the the CA in a cryptoloop container file on a small 32 MB USB stick is a good idea. Cryptloop is rather easy today and available in the stock Linux kernel. I commonly use grml-crypt to manage the crypto loopback stuff:

sudo grml-crypt start /media/usb4/cryptoloop $MOUNTPOINT

Gotcha: don’t confuse sudo’s “password” prompt with grml-crypt’s “Enter LUKS passphrase” prompt, the cryptoloop password won’t bring you anywhere on the sudo prompt. Preparing the CA directory For the CA, create a dedicated directory in the mounted cryptoloop file system. You’re originally supposed to copy the entire EasyRSA directory tree in there, but I’d recommend to only link the files from your system’s EasyRSA directory to automatically take advantage of distribution updates. You’ll need at least these links:

lrwxrwxrwx 1 mh mh   56 Dec 25 23:23 openssl.cnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
lrwxrwxrwx 1 mh mh   52 Dec 25 23:22 pkitool -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool
lrwxrwxrwx 1 mh mh   60 Dec 25 23:23 whichopensslcnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf

ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf .

Configuring your CA The only thing you cannot link is the vars file which contains your CA’s local settings:

export EASY_RSA=“$(pwd)”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=$($EASY_RSA/whichopensslcnf $EASY_RSA)
export KEY_DIR=“$EASY_RSA/keys”
# Issue rm -rf warning
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus.de”
export KEY_EMAIL=“mh+easyrsa-mh-openvpn@zugschlus.de”
export PKCS11_MODULE_PATH=“dummy”
export PKCS11_PIN=“dummy”

Comments have been removed from this file. Better copy the file from /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars and edit it to your needs. I added the two PKCS11 variables since you won’t otherwise be able to issue certificate requests. Creating the CA Next, decide on a shell instance where you will do most operations, and source vars in there. Next, run /usr/share/doc/openvpn/examples/easy-rsa/2.0/clean-all. If you do this in a directory of an already-in-use EasyRSA CA, you’ll need to restore your backup. To actually initialize the CA, run pkitool --initca --pass. If you do not give the --pass parameter, you’ll create a CA that can issue certificates without asking for a passphrase, which might not be a brilliant idea. Choose a reasonably secure pass phrase. Creating Certificates - the simple and suboptimal way You can now simply proceed to create an arbitrary number of pairs of “private” keys and associated certificate by simply calling pkitool <clientname> and/or pkitool --server <servername>. Depending on your security policy, you can mandate the private keys to be protected by a passphrase (adding --pass to the command lines), but you’ll have the expense of being asked for the passphrase every time you start a new openvpn daemon. Creating Certificates the Right Way I have put the “private” in quotes since the keys created this way are not really private: The key was created on the box hosting the CA, was stored on the local (crypted) file system and needs to be moved to the target system via a secure channel. Doing so the right way is harder than expected, so it is usually the better way to keep the private key really private by creating it directly on the target system. On the target system, you need OpenVPN installed, and openssl. After the certificate was created, you can remove openssl again. Creating a private key is part of a key-pair generation process that also leaves a certificate request. The contents of the certificate request is public, and you can safely move it to the CA box and convert it to a certificate by signing the request. You only need to make sure that nobody exchanges your target system’s certificate request for her own before you sign it as you might end up certifying a wrong identity. For the rest of this document we’re going to assume that you have ssh access to the target system and have verified the ssh host key, so that you can be reasonably sure to be connected to the right system. To create a certificate request, you can use this script, which I have called create-easyrsa-cert-req:

#!/bin/bash
set -u
TMPDIR=“/tmp”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=“/usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf”
export KEY_DIR=“$TMPDIR/keys.$$”
mkdir -p $KEY_DIR
export KEY_SIZE=1024
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus”
export KEY_OU=“$(hostname --fqdn)”
export KEY_EMAIL=“mh+$(hostname)-ovpn-cert@zugschlus.de”
export DEBUG=1
umask 077
if [ “$ 1:-foo ” != “server” ]; then
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr $(hostname)
else
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr --server $(hostname)
fi
mv $TMPDIR/keys.$$/* .
rm -rf $TMPDIR/keys.$$

When called without parameters, it creates a certificate request for an OpenVPN client certificate, and when you call it with “server” as parameter, it will create a server certificate request. In any case, it will leave two files in the current directory. They are named after the current host name, and have the extensions .csr and .key. The .key file is your private key. keep it private! The .csr file is the certificate request which you can now move to the keys subdirectory of your CA directory via scp or other means such as an USB stick. To do the actual signing, invoke pkitool --sign <hostname> and enter the CA passphrase. You can ignore the error message that there was no .key file to chmod. Gotcha, when signing a server certificate, use pkitool --server --sign <hostname>. Move Certificate to the target host You can now move the certificate to the target system. Since you’re probably going to need the root certificate and the certificate revocation list as well, you can move the .key file (if created on the CA system), the .crt file, and ca.crt to the target system. These files are public, so there is no need for a secure channel. Revoking Certificates Since an OpenVPN server’s only means of authentication is to check whether the certificate presented by a client is signed by the “right” CA, the only way to revoke VPN access is to revoke the certificate. This is also done on the CA system by calling /usr/share/doc/openvpn/examples/easy-rsa/2.0/revoke-full <client-name>. This creates a crl.pem file which contains a list of all revoked certificates. You need to have a mechanism to distribute that list to all systems that might need it, and it is recommended to have this automated. Remember, if you do not distribute the .crl file, the systems are not going to know about revoked certificates.