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

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

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

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

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

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

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

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

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

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

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

Lars says:

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

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

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

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

Mechanics of selecting packages

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

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

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

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

Progress bar madness

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

The great package hunt

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

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

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

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

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

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

Brain Handles did a test to see if Google indexes Javascript-generated content (for simple scripts). It doesn't. So if you are doing a heavily Ajax-based web page, you are (still) risking to prevent Google from indexing your contents. (Note that for two prime Ajax examples this doesn't matter: GMail and Google Maps. One doesn't have any public content anyway, the other no text.) Please use Ajax only sparingly. It's a dirty workaround for shortcomings in interaction capabilities of HTML and web browsers, not the ultimate solution to all our web problems. Two consequences:

1. For now you can hide content from being indexed by Google by putting it into Javascript code. Note that it will be missing for non-Javascript-enabled browsers then, too.
2. There might be a business opportunity in running Javascript in a Crawler to obtain additional text to index. This is best when integrated with the Javascript interpreter, to e.g. index text changes as they are generated. And this could also be used to detect e.g. sites with annoying commercials (popups), fraud sites or sites which try to run browser exploits or that try to cheat on search engines by e.g. doing a Javascript redirection.

We're happy to announce that the LinuxBIOS project will have the possibility to take part in this year's Google Summer of Code™ (GSoC) program. coresystems GmbH was accepted as a mentoring organization for the GSoC and will mentor all LinuxBIOS-related projects. There is a GSoC page in the LinuxBIOS wiki which collects a few ideas for student projects, among others:

• Booting Windows and other Operating Systems in LinuxBIOS
• Port Grub2 to work in LinuxBIOS
• SCSI booting in LinuxBIOS
• CMOS Config / Device Tree Browser Payload
• LinuxBIOS graphical port creator
• Open Firmware payload for LinuxBIOS
• GNUFI or TianoCore payloads
• Boot OpenSolaris, FreeBSD, NetBSD, OpenBSD or other free OSes
• Improve Linux as a BIOS

Feel free to post more ideas and wishlist items to the LinuxBIOS mailing list. If you're interested in applying for a project, you need to hurry up. The deadline is March 24, 2007!

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

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

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

Via Universal Hub, retail employee fired for blogging. This is not uncommon, but notable in that the blog had no work-related content nor, apparently, was it done on work time:

Drew started his own personal blog. On it he did not mention Mercenary, did not link to Mercenary, did not sell or offer any products or services that might be construed as competing with Mercenary. It just wasn’t about Mercenary. He didn’t even use his own name. His boss learned about the blog when coworkers passed around the posting with the adorable photo of his newborn son. His boss then fired Drew by leaving him a voicemail that Drew picked up when he got home from the hospital.

Although my employment law is rusty, I doubt the employee has a colorable claim against his previous employer. (Private employment is generally not subject to any First Amendment protections.) Any change here is going to need to be more cultural than legal. Ten (maybe even five) years from now, I suspect people will wonder what all the fuss was about. (Some have suggested that the blogger was actually fired for having a baby. If that is true, it likely would be actionable.) Technorati Tags: Blogging, Employment, Free Speech

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

My Thinkpad has started to run hot recently. If I do anything CPU intensive then it will heat up to >80C and then turn itself off. When idling it seems to stay at about 60C when the ambient temperature is about 24C.

It used to not be like this, a couple of years ago I cracked a GPG pass-phrase by using my Thinkpad (as well as a few other machines) to run a brute-force attack lasting a few months. So a couple of years ago I could run at 100% CPU time for months on end and now I can only do that for a few minutes.

It seems that my Thinkpad may have accumulated dust in it's fan from years of running 24*7. I run my Thinkpads 24*7 so that they can download email and large files while I'm asleep, because Linux suspend options have been lacking until recently, and because I use my laptop for a large portion of the day.

The problem I am having is similar to what I had with a previous Thinkpad. Are Thinkpads unable to handle 24*7 operation?

Well, we've been back in the country for about 2 months now. I figure it's about time to write about what's been going on lately around here.

The big controversy is about the county jail. Apparently the county is sharply divided about this. People are angry. Profanity has been uttered at county commission meetings. Some people want to build a new, larger county jail because the current jail has been overcrowded for years. Some don't see any problem with the current situation. Others want to close our county jail entirely and pay other counties to house our prisoners, saying that we usually have less than 6 prisoners total.

Yes, in all seriousness, the county is all abuzz about our jail where a population of 6 means overcrowding.

The weather has been getting warmer and that means an increase in traffic. Today I met two cars on the roads near our house -- one in the morning and one in the afternoon. That's a new single-day record. Usually I don't meet that many vehicles in a week.

And our local high school boys' basketball team made it to the state tournament for the first time since the late 80s. That was quite something. It's probably been years since our school had one of their games broadcast live on the radio. And probably about that long since any local business bothered to advertise on the radio. It even got mentioned in a sermon at church. (They took 4th in the state -- congrats!)

I also have prepared this helpful chart for you explaining a few differences about living out here.

Item	City	Country

Check this before leaving homeTraffic report, so you can avoid the big 5-car pileup on the InterstateWeather report, so you can avoid the roads that are impassible if it rained last night You might comment on this when you get home in the eveningThree of the cars in the daily 5-car pileup were on fire and there was gas on the roadway and helicopters everywhere and you drove right past itSomeone drove down our road at night Always yield to...Trains, school busesEscaped cows and those trying to catch them Neighbors will be mad if...You are blaring loud music at 3AM Monday nightYou notice the gate to their pasture is open and you don't tell them Neighbors will not notice if...A car drives by at nightYou are blaring loud music, anytime Minor everyday dangersManiac drivers, drug dealers, Taco BellCow pies, electric fences, thistle infestations Seasonal events that prolong commute timeIndianapolis 500Harvest Bank tellers ask you...What your account number is, and could you give them a photo ID with thatHow your remodel has been coming Bank presidents...Never spek to youAsk about your brothers Distance from house to mailbox...50 feet or less1 mile or less Your car is sporty if...It can do 0-60 in a respectable timeIt can do 0-60, then slow back to a stop, before leaving your driveway Power flickers duringHurricanes and tornadosWind Water meters read byComputer or city employeesYourself; you write the reading on your payment stub each month, if you are lucky enough to qualify for a water service Free meals attainable by...Using a 2-for-1 couponAttending the annual business meeting for your electric company A good time for fundraising is...End of year so people can get a tax deduction on that year's taxesJust after harvest Fundraising benchmarks include...We have less than the price of a new house to raise!We have less than the price of a new combine to raise!

The intel video driver in Debian 'experimental' didn't work for my laptop. All I got was a black screen. This apparently is related to modesetting on 1400x900 screens, and is in upstream BTS as bug #9076. Anyway, if you are facing this issue, you can either downgrade to the intel driver from Debian unstable, or download the source code and apply this diff:

--- xserver-xorg-video-intel-1.9.92.orig/src/i830_display.c
+++ xserver-xorg-video-intel-1.9.92/src/i830_display.c
@@ -121,1 +121,1 @@
-#define I9XX_P2_LVDS_SLOW_LIMIT         112000
+#define I9XX_P2_LVDS_SLOW_LIMIT         90000

(the patch will probably be garbled by the blog. Just find that line and change the value to 90000.) Then recompile and you should have a working intel video driver again.

The book SE Linux by Example has been reviewed on Slashdot.

The issue of Perl scripts was raised for discussion. It is of course true that a domain which is permitted to run the Perl interpreter can perform arbitrary system calls - it can therefore do anything that SE Linux permits that domain to do. This is in fact a demonstration of how SE Linux does the right thing! If you want to restrict what can be done when executing the Perl interpreter then you can have a domain_auto_trans() rule to have Perl run in a different domain.
Restricting Perl (as used by one particular program) is actually easier than restricting a complex application run by users such as Firefox. Users want to use Firefox for web browsing, local HTML file browsing, saving files that are downloaded from the web, running plugins, and more. Granting Firefox access to perform all those tasks means that it is not restricted from doing anything that the user can do.

A claim was made that a novice users would not understand how to use SE Linux. The fact is that they don't need to. I know many novice computer users who are running SE Linux systems, it just works! It's more advanced users that have to learn about SE Linux because they configure their machines more heavily.

The essential difference between path-based access control and Inode based access control is that the standard Unix commands to control file access (chmod, chown, and chgrp) all operate on Inodes. If a file has 1000 hard links then I can restrict access to all of them via a single chmod or chcon (the SE Linux command that is comparable to chmod) command. AppArmor does things differently and implements an access control model that is vastly different to the Unix traditions. SE Linux extends the Unix traditions with Mandatory Access Control.

Granting different levels of access to a file based on the name of the link which is used is a horror not a feature.


I wrote this as a blog entry rather than a /. comment because my lack of Karma means that less people will read my /. comments than my blog.

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

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

Past problems

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

Solutions

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

Outstanding problems

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

I was away in Philadelphia over the past week for the annual Drosophila meeting. My boss presented our work, and I shared a poster about it with the postdoc in the lab. I was constantly running from talk to talk and from poster to poster, trying to soak up as much as I could. I also got to meet a fair number of famous people, which was pretty awesome. It's not every day you get to meet a Nobel laureate, but that's why you go to these things. We got a lot of good feedback on our work, and we've basically gone in to overdrive to try and get the paper (which will be my first one) submitted.

Since I've been back, I haven't had any significant time to do Debian work, mainly because I've been in the lab or just taking care of life stuff almost non-stop. I managed to sneak in some time to tweak the XSF wiki pages, but the rest of the team has been handling things in my absence. I wish I could report on what they've been up to, but I haven't looked at any non-personal email for the past week.

Finally having a chance to check planet Debian today, I'm excited to see Martin's various posts about the release management for different free software projects. Obviously that's been the major thorn in our side for a while now, and while we're improving we can obviously do better. I'm looking forward to a post-mortem report and discussion from the release team about what the next steps we need to take are. I have my own ideas of course, but the release team has a much wider field of view than I've been able to achieve.

Off to see the Shins tonight, hopefully they're as good live as I've heard.

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

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

I assume that I was sung songs when I was little, but I don't really remember them. I do remember my mom singing "You are my sunshine" to me (but only the chorus, as she thought the first verse was too sad. I'm glad that she never heard the remaining creepy stalker verses from the O Brother soundtrack). Angie will sing lullabies that she remembers, but she's the oldest of three kids, whereas I'm the youngest of two by five years.

So all this to explain why at 4am I was singing Leif to sleep with songs from The Dances of Universal Peace. Walking in circles singing them reminded me that I haven't been to the dances in a while. They're on the second Tuesday of the month here in Montr al.

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.

South-by-Southwest is well and truly over now. I had a really good time. I don't have quite as much fun at general-Web conferences as at wiki-specific conferences, but I think it's also healthy for me to look outside my own narrow niche every once in a while and see what other people are doing. I think overall the conference was pretty great, although I don't feel like the passion of 2006 was here in 2007. I will say that I find it disconcerting that there are so few wiki people at SxSW. I think there should be considerably more, and I'm going to urge some intelligent and thoughtful people to come to Austin next year and get on panels. Practically every aspect of blogging gets covered at SxSW, but mine was the only wiki-specific panel this year. We're taking a week on the coast near Galveston to recharge batteries and get our work lives back on track. Then it's off to Las Vegas for the IA Summit. Maj will be in the conference area -- I'll be baby-sitting at New York New York or something. tags: sxsw07 austin wiki galveston las vegas

Dear LazyWeb Two questions:

• N800 movies. What ffmpeg or mencoder or transcode parameters should I use to convert video to run on the media player on my Nokia N800?
• Zip code of Canada. In the US, when you try to charge a tank of gas using pay-at-the-pump, frequently you're asked for the ZIP code of the billing address of your credit card. But if your residential address is in Canada (or anywhere outside the US), you don't have a ZIP code attached to the card. I usually go inside to the cashier and pay there, but I wonder: is there a special code you could use (like "00000") that means "I don't have a US ZIP code"? If not, why not?

Thanks for any answers (see Contact for how to get them to me). tags: lazyweb n800 zip code credit card canada

Twittering again It seems like Twitter is waking up from its own SXSW07 hangover and sending out the thousands of backlogged twits that weren't delivered at the right time. I don't think in the age of EC2 any public Web site should go AWOL due to too much traffic. Twitter suffered just the kind of surge that EC2 (and S3) are there to solve. tags: twitter ec2 sxsw07

I've made a tiny update to DBus inspector, which works around the Tracker issue causing a segfault for many users (especially Ubuntu users, where Tracker seems to be part of a default install now?) Anyway, it should be working with the Python DBus bindings from GIT, but since they aren't released yet (or in Debian), I've added a workaround. If any service containes "Tracker" and your python dbus version is at most 0.80.2, it will just skip this service. I don't know if it's also Trackers fault that dbus-python segfaults. Download DBus Inspector Sorry, no homepage yet. Still waiting for repository and account creation on Gnome.org, which seems like a good home for it.

edos-debcheck reports that the emdebian toolchain for alpha built from gcc-3.4 cannot be installed on i386 (and possibly amd64) when the repository also contains the toolchain for gcc-4.1:
libstdc++6-dev-alpha-cross (= 3.4.6-5): FAILED
The following constraints cannot be satisfied:
libstdc++6-dev-alpha-cross (= 3.4.6-5) depends on libstdc++6-alpha-cross (>= 3.4.6-5) libstdc++6-alpha-cross (= 4.1.1-21)

Yet there is no problem with these for arm or other architectures (except possibly s390). In the main Debian archive (native build), g++-3.4 depends on the gcc-4.1 version of libstdc++6. http://packages.debian.org/unstable/devel/g++-3.4.

$ edos-debcheck -explain -failures -check libstdc++6-dev-arm-cross combined

reports no errors.
('combined' here is a result of appending the Packages file from Debian to the Packages file from Emdebian although the Emdebian repository is slightly behind my own data. I'll sort out the update tomorrow.).

The repository can only contain one version of libstdc++6, just like any one system can only install one version (at least in /usr/lib):
$ reprepro list unstable libstdc++6-alpha-cross
unstable main i386: libstdc++6-alpha-cross 4.1.1-21
unstable main amd64: libstdc++6-alpha-cross 4.1.1-21
unstable main powerpc: libstdc++6-alpha-cross 4.1.1-21

By building separately, the emdebian cross-build has a dependency on 3.4.6-5 and despite the >=, edos-debcheck reports that the dependency cannot be satisfied.
$ dpkg -I /var/emdebian/debian/pool/main/g/gcc-3.4/libstdc++6-dev-alpha-cross_3.4.6-5_all.deb grep Depends
Depends: gcc-3.4-base (= 3.4.6-5), g++-3.4-alpha-linux-gnu (= 3.4.6-5), libstdc++6-alpha-cross (>= 3.4.6-5), libc6.1-dev-alpha-cross (>= 2.3.5-10)

The next cross-build of gcc-3.4 on i386 for alpha needs to use the version of libstdc++6 from the repository instead of making an older version via dpkg-cross. Not sure why this only affects alpha cross-builds.