Ben, Erich and Russell bit - Why shouldn't I?

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. Shame - I cannot comment on this, as I'm no a LiveJournal registered user. And I don't intend to be either.

1. Replace standard incandescent light bulbs with compact fluorescent light bulbs
2. Choose energy efficient appliances - always a criteria when I have a choice. Not always the dominant criteria, though
3. Wash clothes in cold(er) water
4. Turn the thermostat of your hot water tank down to 50 C (125 F) We have a on-route boiler (calentador de paso - any translators? :) ), it only heats when the hot water pipe is active. Of course, it burns much more intensely than a tank, but still, I feel it's an overall saving
5. Install a programmable thermostat (or turn the heat down over night and when you're out of the house) - Pfff... Artificial weather in Mexico City? Don't be silly! ;-)
6. Register with the Canadian Marketing Association's Do Not Contact Service to reduce the amount of junk mail delivered to your house. - Would love to.
7. Eat less meat (particularly feedlot beef) - Nadezhda is a vegetarian, I seldom eat meat
8. Walk, bike, carpool or take public transit as often as possible
9. Make sure you know what can be recycled in your area, and try to recycle as much household waste as possible - In this country, recycling is a lot. We hand-recycle some things, but of course, at a very artesanal level
10. Compost using an outdoor compost bin or an indoor vermicomposter
11. Clean or replace filters on your furnace and air conditioner
12. Buy local, organic or fair trade food where possible
13. Reduce air travel
14. Wrap your water heater in an insulation blanket
15. Use a clothesline instead of a dryer whenever possible
16. Plant a tree
17. Buy fresh foods instead of frozen (Frozen food uses 10 times more energy to produce)
18. Keep your car tuned up and your tires inflated to their optimal pressure
19. Use biodegradable dishwashing liquid, laundry soap powder, etc.
20. Drink tap water (filtered if necessary) rather than buying bottled water - And not only because of the environment - huge price difference!
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
23. Plug air leeks and drafts around doors and windows with weatherstripping - I guess this applies to places with heating/AC
24. Switch from disposable to reusable products: food and beverage containers, cups, plates, writing pens, razors, diapers, towels, shopping bags, etc. - As much as possible, of course. Or try to reuse those meant to be disposed.
25. Consider garage sales, Freecycle, eBay, or borrowing from friends/family before buying a new tool or appliance

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.

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.

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.

Yves-Alexis Perez writes a bit about Debian and crypto-containers, comparing cryptsetup and encfs. The comparison is decent enough, except that it's fairly trivial to get cryptsetup to integrate into the whole gnome-volume-manager stack and have a dialogue pop up when you insert an encrypted USB stick or similar. Sure, it's mounted by a root process, but I wouldn't claim it's any kind of insecure because of that. What did really catch my eye was the line near the end:

[...] but this is a bruteforce attack against master password (1024 bits RSA key), not against 128bits aes key of the container.

Well, according to conventional research, a 1024 bit RSA key is about as strong as an 80 bit symmetric key. A semi-recent RSA paper confirms this too. And to the best of my knowledge, there has not been found weaknesses in AES which lower the effective key size.

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.

... or why PHP sucks so much?

It is quite common (at least for me) finding abused web applications on shared hosts around. The most typical case is finding some kind of IRC bot running as www-data and a few unauthorized files around used for phishing, cross-site scripting or what else. That motivated me to try playing with mod_chroot in order to minimize the possibility of webapps abuse from our friendly kiddies^Wcrackers. Mod_chroot is a nice tiny Apache module whose purpose is the confinment of webapps within a limited tree, where nothing but a few files and dirs are available to try exploits and abuse badly written code.

Unfortunately, I found that mod_chroot poses one major problem (among others, see its CAVEATS doc): the sucking mail() function is not working out of the box, because PHP folks - God knows why - decided to implement that stuff by calling a local /usr/sbin/sendmail program within a shell call. The most sane option is simply ignoring the issue and living happy with a disabled local mail() function. A nice solution in that case is using a PEAR Mail module, which is able to send mails via SMTP in much more elegant way. Unfortunately, there are quite a good number of morons out there, and that could be not a viable option if you are the system administrator of a bounce of shared hosts which are exposed to those morons, who absolutely need a working mail() function.

After a few googling around, I did find that many people had the same problem, but none found (or explained) a working and neat solution for a working mail() implementation, so I'm writing some notes about that. My implementation is based on a nice tiny program (mini_sendmail) which has the great advantage of not requiring a configuration file or a spool directory to work. It also works without suid bit on, which is a good thing as well. It is statically compiled by default, so it simplifies things a lot. In order to have mail() working you need also to install a (statically compiled) shell, e.g. bash-static as sh under the /bin directory of your chroot tree (a more tiny shell would be appropriate). I commented out the silly username autodetection code in the mini_sendmail.c source, because it creates some problem within an empty chroot tree (it failed with a "can't determine username" message with or without the /etc/passwd file available).

Now, the next step is using an entry like

sendmail_path = /usr/sbin/sendmail -t -fwww-data@your.domain -s127.0.0.1

in your php.ini file. You can also use another IP address if your SMTP server is not your localhost or you used some more exotic routing setup. Having a suitable /etc/hosts is also useful. A final trick is adding a var/lib/php4 or what ever directory is required to store PHP session files. No other files should be required in order to have all working. Of course, you have also to use inet sockets for any required connection (e.g. mysql) but this is typically the default in etch. I would also suggest to add only ad hoc statically-compiled binaries within the chroot tree when required, else you will need to store all required shared libs: in that case you will need to find binaries requirement by using ldd and chroot to find loading/running errors by means of an usual trial-and-error cycle.

Dell is doing a survey on their upcoming Linux offers. But "Debian" isn't on their shortlist of preinstalled Linux versions. There is an "other" option though we can use. Please tell Dell that Debian is nice on the Desktop, too. It's not a server-only distribution... P.S. Let me point out, that I'm running Debian on a Dell Inspiron.

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.

[ Warning: Long post follows ]
Just today, I read that H01ger is happy he can wear just a T-shirt somewhere in Northern Germany. Well, from my point of view, much the opposite has happened. And I'm not just happy - I'm fucking proud!
About four years ago, Nadezhda went almost every weekend to hike to the mountains with the Grupo de los Cien people. I'll sidetrack a bit to speak about them: Grupo de los Cien is a group of mountain lovers (no relation with the enviromentalist group which later took the same name) that, since the 1950s, have built and maintained the high mountain shelters in Central Mexico. It is a group, by the way, with which Nadezhda fell completely in love - and now it's up to me to find out why ;-) But lets go back to the main topic.
Almost every week, she came back delighted and loaded of energy from a mountain hike. Almost every week, I told her I wished to go with her, of course, if they went to a simpler route. Of course, lugging around over 130Kg of humanity is no easy deal. And, after over a year and because of many problems that came together at once, she stopped going to the mountain as well. She always kept an eye on their friends, but so far had not been able to return to the mountain.

Ok, so last week she heard the group was organizing volunteers to go fix the Ayoloco 2 shelter. She signed up, and invited me. I was afraid, but accepted the challenge - Of course, full of fear.
Being this a historical event (at least in my life), I cannot but offer you some of the photos I took. And, yes, I've just started playing with Flickr. Lets see if it works for me ;-)
Saturday, 5 AM, we woke up. 5:50AM, we met part of the group near Daniel's house, in Condesa. 7 AM, we were having a nice breakfast (tamales and coffee, yum!) in Amecameca, still 28km from La Joya. From Amecameca, we went to Paso de Cort s, where we met the rest of the group, and from there we went by a little, bumpy and unpaved road until La Joya. Somewhat around 20 people started the hike at around 9 AM.


According to Google Earth, La Joya (just South of the Iztacc huatl - white woman or sleeping woman in N huatl) is at 3995m - And, of course, to start at that altitude is not easy. The air is very thin, and walking a little bit too fast quickly makes you feel the blood pumping, trying to get some more oxygen. I often remembered how my Bolivian friends behave in Potos , walking slowly even when in a hurry :)

We first went down a little valley, then up. The first portion of the hike was on soft, wet sand, with some grass (what we call zacate - Strong, hard grass, not what you commonly see in a garden). I soon learnt that was a blessing, as it was by far the easiest part. Then we went up a steep and quite rocky area - It started getting tricky for somebody not used to trusting his own feet. And it was steep, yes. This was the first time (of many, of course) I started thinking whether I should head back.

We reached what I foolishly thought was the summit, only to find a steeper, longer way to go. It started getting common to find little deposits of snow/ice (I don't know the exact term in English - it's called aguanieve in Spanish, literally snow-water. [[Update]: Thanks to the now-DD H01ger, I now know that aguanieve in English is called sleet]. I understand it's a bit harder than snow, but still much lighter than hail). We crossed a completely rocky section - No sand to hold the rocks to their place. That meant being extra careful (and thus, extra slow).

But just afterwards, in case it was not enough, Mother Nature answered my pleads for some sand - we crossed a section made exclusively of loose sand. And, please, if you have ever walked upwards on sand, imagine doing so at over 4000 meters. I was taking so much care of how and where I stepped that I strayed not more than 5 meters down of the path the group was following - Being able to climb back to the right path was really not easy. This was the point that not only I was thinking about heading back, but I'm sure Nadezhda thought I would abort the mission. She cheered me up, took some pictures of me as soon as I got out of the sand trap, and we were able to move on.

After the sand, some more rocks, and we started feeling the chilly wind. We entered a cloudy region - Humidity does get the coldness into your bones! We could not really see where was the rest of the group, so we proceeded the best way we could. Fortunately for Nadezhda and me, just behind us came the very experienced Mario Corsalini and led us. And, yes, we finally saw the Ayoloco 2 shelter.

I was by then exhausted, after some four hours of ascent. I ate one of my apples - The sweetest apple I have tasted so far. After resting a bit, and realizing I was almost frozen (we were at 2 Celsius under, with constant chilly, humid wind)... Then I started working with the guys, reinforcing the shelter, while Nadezhda and some other people painted the inside with. People started eating - of course, I joined them. And, after some time up there, we started going back down. Miguel ngel, a volunteer in the Izta-Popo park, walked a good portion of the descent with me, giving me tons of help and tips. Thank you, thank you, really. The descent is, of course, much easier - We were chatting most of the time, and we made only around two hours back. The weather was quite nice on us - We had some aguanieve falling every now and then (yes! Yes! many of you guys have heard/read me bitch on how I had never seen snow falling before - Ok, this is not exactly snow, but I think it qualifies as my first experience ;-) ), but aguanieve does not make you wet, as it bounces off the clothes. When we approached La Joya we started having some light rain. We hopped in the cars, and then the rain really began.
But even if this was not enough: Grupo de los Cien was celebrating the 83th birthday of one of its senior members, Poncho Rico. No, being 83 years old is not an excuse for skipping this memorable hike.

We went to Anatolio's house, very close to Amecameca, and had a delicious dinner, cake and drinks.
Nadezhda: Thank you. So, so, so very much. Thank you for being so patient with me, for dragging me up the Sleeping Woman. Thank you for getting me into this so very important and beautiful experience. I hope this will be the first of many. There is still a very long way for me to go before I'm really up to the challenge, but believe me: This will not be my last time on the mighty mountains.

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).

random(ideas);

Yes... we can too!

Recently I saw somewhere a link to Google Video about a very nice video: How Open Source Projects Survive Poisonous People (And You Can Too). So please, if you didn't see this go and watch it now: http://video.google.com/videoplay?docid=-4216011961522818645. It is a little bit large (~50 min) but I found some nice information from real experiences that could really help to improve our communication inside Debian. So, for the curious and impatient, it is a Google TechTalk with Ben Collins-Sussman & Brian W. Fitzpatrick, SubVersion Developers, based on their experiences they show situations that can drain Project resources and they gave valuable tips, ideas and directions on how to protect the "Attention and Focus" of the Project. It is very interesting to find a lot of factors and points that we can see from time to time on Debian. Don't get me wrong, I'm really not whining, I don't think that whining would solve any problem (except if you are a 6-month hungry child), but I would love if it could give us some momentum and maybe a starting point to leave aside some old unresolved issues, giving a chance to new ideas! Which basically means, keep working together to keep building the best Operating System. :-) (But doing that with even more fun for even more people). We can too! On a totally unrelated note: my primary MX is back for quite some time, I should report that earlier, anyway, sorry about the lack of posts, thanks for your attention and see you soon. Over.

Of late I have been:

• Tracking the progress of #413926 and the fate of Wordpress in etch.
• Celebrating 3 years in the NM queue.
• Working on Debian Live. Check out my test environment. Daniel Baumann is currently rewriting make-live and I have begun a new project which I like to pretentiously call the Universal Web terminal. :)

• Fistognosticated - Ella Baila
• Ellen Allien - Crosstown Rebels
• 4twenty - Wenn der Beat rollt
• Don Choa - La verit blesse
• Ricardo Villabos - Fiezheuer Zieheuer
• J rgen Paape - Take this
• Oliver Hacke - Baked Bean Mix
• Henrik Schwarz - Leave my head alone brain rmxs
• Ellen Allien & Apparat - Bubbles
• Tiefschwarz - Issst (Nathan Fake remix)
• Lina - I'm not the enemy

Yeah i've danced all night in Florence on Ellen Allien sounds, explains why she shows up twice - great djane. :) Meike, thanks for this funny "meme". By the way out of lazy web how did you fix the blosxom timezone toppost trouble? (urggs got title year wrong) update: *doing* *doing* *doing* everywhere ;)

We need to send out invitation letters for people needing a Visa to come to DebConf. And we really need to do this soon, as a Visa application process can take months. So it needs to be done real soon now.

So if you have some spare time (I don't) and care about people coming from countries needing a Visa to visit UK, please read this thread.

As I understand it (which might be wrong or inaccurate) the Debian UK or DebConf Ltd. people want more feedback from UK visa officials outside the UK. I'm sure there is better information how you can help in this thread, if not, please ask.

Another good day at South by Southwest. I had the night out last night, so I stopped at the Frogdesign Party for a while to see people and have some beers. I left to try to see Douglas Coupland's new movie, Everything's Gone Green. As a speaker I got a "gold" pass, which means I get to go see some of the films in the festival, but by the time I got to the theatre, it was at capacity. Too bad! Over to Club de Ville to see old friend Ben Cerveny, then trying to catch up with Niko, then an early night getting home. This morning I went to see Identity Woman (Kaliya Hamlin) talk about OpenID at the identity panel. It was a good discussion about identity and privacy, and I also got to meet Scott Kveton in person, too. Mike Linksvayer was there too, which was nice; it's great catching up with such a sympatico person. This afternoon I watched the incredibly valuable Everything You Always Wanted to Know About the Mobile Web...but Were Afraid to Ask. Great practical information for people willing to give mobile a try. I came away enthused and ready to make wikitravel.mobi a reality. Best of all was seeing Ben on his panel about virtual identity and avatars. Ben's got a talent for identifying the most intellectually stimulating thread in a conversation and following it with gusto, so it was really cool to see him talk on stage. tags: sxsw07 austin douglas coupland identity woman mobile web ben cerveny

La Traviata We stopped in for dinner at La Traviata, an Italian restaurant on Congress that Maj had heard good things about. The menu was nice but not too friendly to us pescevegetarians; we were excited when we heard that there was a seafood special that night. But the waiter came back to tell us that they weren't available. After we ordered, I heard the waitress behind me saying to her very big table, "...and we have two plates of the mahi-mahi available..." I stopped our waiter when he came by, and he was sheepish. "The chef was keeping those two plates for this big party." Oh. Our food was great -- I had a mushroom fettuccine, Maj had a grilled salmon with greens -- and we forgot about it. But the waiter came out later and said, "I talked about it with the chef and we want to extend our apologies. We should offer the specials to every customer equally. The chef wants to offer you dessert on the house." OK, sounds good. It doesn't take much to make up for a mistake, especially in the restaurant industry. La Traviata had good food, a really nice building, and great service up until then, but going that extra mile to make up for a mistake -- a debatable mistake I probably would have never thought about again -- gained my trust. More restaurants -- no, more businesses -- should have service like that. tags: la traviata austin italian restaurant

Blog review roundup I wanted to quickly shout-out to people who mentioned my talk at SXSW (Talks/SXSW07) in their blogs:

• Mike Linksvayer, SXSW: Commercialization of Wikis.
• Angela Beesley, Commercialization of wikis. I hope she saw that she was thanked at the end!
• Liz Henry, SXSWi panel on commercialization of wikis. The canonical notes, better than my own.
• Adam Darowski, SXSWi: Commercialization of Wikis. Adam's doing some wiki projects himself, and he found the talk helpful. Great!
• Mathieu Ouellet, Commercialization of Wikis. I hadn't seen Mathieu's great travel/tourism blog before, but it's bookmarked now. Great reading.

I'm really glad to see so much positive response to the talk. I worked really hard on it, and the subject is obviously very dear to my heart. It's great when your work pays off and people appreciate it. tags: sxsw07 me talk blogs wiki

Wiki BOF We're having a Wiki BOF lunch tomorrow at the 4th-floor coffee lounge. It should be fun. Thanks for announcing it, Liz! tags: wiki sxsw07 bof flock together

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

So, that was the debate. Now I can stop and read the answers properly. It was a bit disappointing that one candidate (gustavo) didn't appear, one was late (sjr) and one withdrew on the day of the debates (svenl). I guess I'll see what explanations are submitted. The debate opened with a fairly gentle question, asking for introductions. Makes sure the process is working, I guess. Generally inoffensive, but Anthony Towns's answer is puzzling: shouldn't he have documented stuff during the last transition if he thought it lacking? If he's re-elected, there won't be a transition, so any documentation would be based on year-old memories... he's giving an argument for electing someone else! The communication question got a variety of responses. Not sure that Wouter Verhelst's aim of better team communications is achievable, but maybe it is - don't know without more communication from people who aren't currently communicating well! Not sure whether Steve McIntyre is arguing for diplomacy and politeness or the truth of the Sapir-Whorf hypothesis, which is more worrying. Releases. Oh! Releases. Aigars Mahinovs's plan to release less often is interesting, but is it realist or defeatist? None of the candidates seem keen to give NM the radical revision that I think it needs - the median time in DAMnation is longer than the median time for the whole of the AM-led review, contrary to what Wouter Verhelst seems to claim later (line 754). About the only reforms suggested are Anthony Towns making permissions more gradual and Steve McIntyre's (IMO scary) social conformance test. Each of the candidates sees a slightly different thing as debian's biggest problem, although some of them overlap. Maybe this is the axis that differentiates the candidates most? Also, a full range of "code of conduct" views seem to be there: from it being a good idea, through leaving it for others to try, to being opposed. Then it was onto the buck-passing round. Another communication question brought some similar responses and this absolute gem from Aigars Mahinovs:-

"A technical solution to a social problem - a cron job that will send the email every two months, 6 text files with a template saying that nothing has been done and I just need to remember to write something good into those files before they are sent."

I like that idea! A few technical questions brought some interesting reminders about work that is actually already underway, but maybe not very visible, then there was a question about other distributions. Predictably, most of the focus fell on Utnubu and other derivatives, with a few mentions of Gentoo too. The targetted questions brought a few amusing replies: at least one candidate seems to say that they won't pursue a past comment if elected, while Anthony Towns seems to see the new FDL and CC licences and GPL'd Java as personal achievements. The cage fight (or open discussion, as it is more usually known) spent most of its time emphasising and clarifying points from earlier. It only seemed to be at the end when it cut new ground, with questions about demographics and $10million. Finally, closing summaries again showed the differences of approaches and views. Then that was that and the participants logged off into the night...

• The debate
• The audience
• The sources