I got the idea for this from Ben Hutchings.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 youB. Add one (or more) suggested action(s) of your ownC. 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
2. Choose energy efficient appliances - I'm documenting the power consumption of my computers
3. Wash clothes in cold(er) water - Colder than what? I suspect this is based on American machines that are controlled by mixer valves rather than using a thermostat.
4. Turn the thermostat of your hot water tank down to 50 C (125 F) - this is a good safety measure anyway
5. Install a programmable thermostat (or turn the heat down over night and when you're out of the house)
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) - For practical purposes I'm vegetarian, with occasional exceptions.
8. Walk, bike, carpool or take public transit as often as possible - I'm writing this on the tram
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
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 - 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
16. Plant a tree - pity my trees are dying because of the drought / climate change
17. Buy fresh foods instead of frozen
18. Keep your car tuned up and your tires inflated to their optimal pressure - also minimise driving. I drive about 5000Km per year.
19. Use biodegradable dishwashing liquid, laundry soap powder, etc.
    
20. Drink tap water (filtered if necessary) rather than buying bottled water - remember the Benzene incident...
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 - the power use is small so I only do this for rarely used chargers.
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 - I've done this for most things, could improve though.
25. Consider garage sales, Freecycle, eBay, or borrowing from friends/family before buying a new tool or appliance - second-hand and refurbished computers are so powerful and so cheap that you don't need to care about the environment to do this.
26. Reuse bathwater, maybe to flush the loo, water the garden, etc.
27. Make sure your roof is well-insulated. - I think it is, but as tenants it's not really our choice.
28. Always wear a jumper/sweater and socks indoors unless it's warm enough outdoors to go without both.
29. Run your vehicle on biofuel/sustainable fuels
30. Set up a grey water barrel to use when clean water isn't necessary - grey water should never be stored. It contains chemicals that are used as food for bacteria.
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.

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

Agi gave me the link on IRC to this rap song for and about nerds. It s like the Beastie Boys rhyming to the BOFH script. I am a fan now.
There is a video on YouTube for raw footage of a performance that CS rapper Monzy gave last summer outside Stanford University s Computer Science building. This footage was shot for the documentary, Nerdcore For Life.

Lyircs and MP3 for Kill Dash Nine by Monzy.

Monzy s blog

Call me picky, but I'd actually like to be able to see my window contents. I just tried Beryl from the official beryl repositories for Debian; and while it started fine, the window contents weren't redrawn. Also memory usage skyrocketed. It was totally unusable, I couldn't get Beryl to draw the window contents properly (and yes, I also tried a clean login into Beryl right away.) I'll try tweaking it some more, but so far it's just not working at all. [Update: after an upgrade to Xorg 7.2, beryl displays window contents. I'll give it another try. However my experience with compiz and beryl so far was rather disappointing: not worth the hassle. I also clarified above paragraph: it's beryl for Debian from the repos as beryl-project.org] [Update: I can stand Beryl for at most 5 minutes... it has rendering artefacts with window shadows (so they are very common), and I consider most of the animations just to be pointless. Configurartion of Beryl is hell... I'm back to my trusty openbox which just totall gets out of my way and lets me do my work.]

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.

For the record, I like the new color of the Iceweasel icon. It is certainly easier to see in the toolbar.

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.

Traveling to a country you've never been to before, walking into a random cafe and being recognised by someone. Something like that happened to me when I was in Barcelona. We didn't have much time to look at things when we were there, since we were mostly either in the meeting or at the hotel. So, when we had a few free hours left before getting on our flight back, we decided to take a little walk around the city. However, shortly after we had left it started raining cats and dogs, so we took refuge into a nearby starbucks. When I was ordering my hot chocolate, a girl walked up to me and asked me
"Do you by any chance study in Hildesheim?"
"Yes ..."
"IIM?"
"Yes ..."
"You're Meike, right?"
"Yes ..."
Turns out, she was an IIM student as well and recognised me from a seminar. I must confess, I didn't recognise her. Shame on me! I was also totally surprised though. Who would have expected ... :)

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.

Last year I was the organizer of the Debian booth at the FrOSCon in St.Augustin, Germany and I was so happy with the conference that I decided to take part in the second invocation of the conference. So I took over some tasks and here I am. The next FrOSCon takes place on August, 25th and 26th 2007 in St. Augustin, near Bonn, Germany. And will again be hosted by the faculty of computer science of the University of Applied Sciences Bonn-Rhein-Sieg in collaboration with the student body and the Linux/Unix User Group St. Augustin. Yesterday the Call for Papers started that will end on June 4th. Everybody is invited to take part and we are happy if we would get flooded by as many Papers as possible to make an even better FrOSCon as last year :).

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.

If you are running a system with ext3/ext2 on top of a LVM partition, or just when you made the partition bigger, you obviously want the file system to grow, too.

Easy, ext2online is the answer:

ext2online /dev/mapper/hdapool-homefilesystem

Unless you run into an error like:

ext2online v1.1.19 - 2001/03/18 for EXT2FS 0.5b
ext2online: group 0, block 2 not reserved

ext2online: unable to resize /dev/mapper/hdapool-homefilesystem

That's when you start googling and find that ext2online is not that online and needs the file system to be unmounted you need to run first:

ext2prepare /dev/mapper/hdapool-homefilesystem 23G

Note that the size there is the desired new target for the filesystem.
So you log off, go to a console, umount the file system (unlucky you if is the root file system, in that case you'll need the rescue mode - does D-I have ext2prepare?), run the command.

Now fsck.ext3 the device, mount it and try again ext2online. Now it should work.

Ken (Chung-chieh) Shan started a blog this year, apparently running on ikiwiki software. Ken is one of those people whom you want to have a blog. The focus seems to be linguistics (generally Ken’s academic field) and “miscellaneous.” Welcome to the blogosphere, Ken.

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.

(yes, I know how to type, but my keyboard is degrading. Apparently, I didn't know how to read yesterday) There were a number of replies to my post about upstart and other init-implementations yesterday. Since it apparently didn't come through properly: yes, I do know about upstart-compat-sysv, and yes, I'm obviously using it. That wasn't the point. The point is that using upstart-compat-sysv is a workaround which allows to migrate to upstart, rather than to support it in parallel. Debian has always been about choice; giving people the choice to use upstart rather than sysvinit and vice versa is something we should do. Ubuntu has chosen to use upstart rather than sysvinit, and that's their prerogative; but Debian as a whole cannot (and will not) make that choice. The point of the exercise was to figure out a way to allow people to say "I want upstart", and bang—everything gets migrated to event.d scripts. But if they then decide that they don't like upstart after all, they should be able to just reinstall sysvinit, and bang—everything gets migrated back to regular SysV initscripts. That currently isn't possible, and upstart-compat-sysv doesn't offer that.

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.

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

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "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."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

• it was dead simple to make a working one
  
• the documentation is really verbose and complete
• there is a default behaviour for every ebuild, even for a minimalist ebuild
• if your ebuild has a special need, the ebuilt can override the default behaviour by redefining the function (target, in debian/rules-speech), but you don't need to, in most cases
• there are some already defined classes which can be inherited to obtain a tweaked default behaviour (imagine typical cmake build system, typical autotools build system, typical kde build system - and iirc, this can include build dependencies)
• all the information about the package is centralized in one file which is human readable from the start, plus that is obvious, or one can understand fast what a field/function/variable means from the start, without digging through the documentation continuously
  

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.

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