The second day of debconf went a bit odd. It seemed like, apart from the first session, everything else I attended was at a different time to when it was advertised yesterday. Even my talk had moved and I didn't notice, so I turned up early and was thrown before I started. Maybe more on that later. (Summary: 2 dozen rattling around a large hall, no clock, and I really hate fixed microphones. It dragged.) Anyway, things which I didn't think would conflict suddenly did and things which I thought conflicted didn't any more - but I didn't notice the missing conflicts until too late. I bumped into Sam who seems to be tracking conference sessions on a pad of paper - I've no idea how he's managing that. The SPI half-human half-IRC board meeting was interesting to watch. I also discovered that my typing speed has dropped a little and that it's much harder to copy-type north americans than locals. I still don't know what tune was being whistled when the board stopped talking and started typing.

As part of testing upgrades, I'm trying to build disk images for foreign architectures. debootstrap already has the first-stage second-stage framework for this, but of course you have to be able to boot a system in the target architecture to finish the second stage. I've tried a few ways of accomplishing this.

The first is extracting a kernel from a package and using qemu-system to boot that. Trouble there is that AFAIK there aren't prebuilt initrds and so the root image can't be mounted.

The second option occurred to me that I could use user mode emulation to do the necessary second-stage bootstrapping. You'd still need to be able to chroot into the system, though, and so I tried this out by statically building qemu binaries. This didn't seem to compile too cleanly, but after some searching I discovered that what I was trying to do had already been done over here. Seems like a pretty good solution. Only thing is if I go with this method, it would require those packages as prerequisities which aren't in the Debian repository.

If anyone has any additional suggestions on bootstrapping for a foreign architecture, let me know.

It's day 2 of DebConf and dvswitch is being used by many members of the video team. So I have a pretty good idea of what it does well and what I need to fix in it. The most serious problem is that there's no way to start and stop recording from the GUI. That's actually controlled by starting and stopping the file sink, which runs on a remote machine. Here I have arranged to start it by running a command with ssh in the background, which is stopped by quitting dvswitch or with pkill! The result is that we can record a lot of junk between events, which has to be checked and then discarded, or alternately stop recording and risk missing the next event. Also, we like to number our cameras: 1 for the speaker, 2 for the audience, 3 for slides. But dvswitch assigns numbers to sources in order of connection. I fudged around this by again using ssh to start the sources in the proper order after dvswitch. Despite these and a number of other flaws, it seems that several people have been impressed by the ability to cover talks from multiple angles. I hope this will attract more people to contribute to dvswitch so that it can serve DebConf and other conferences better.

The DebConf video team is using a large number of programs, some common and some of our own, spread across 20-30 computers. Some may be interested to know what this is.

• FAI for package installation and configuration on DebConf machines.
• dvgrab for video grabbing. We are using a variety of DV cameras, but dvgrab works well with almost all of them.
• dvswitch for switching between multiple cameras and files.
• ffmpeg2theora for transcoding to Ogg Theora/Vorbis, both for live streams and for the downloadable files slowly appearing on meetings-archive.
• A small number of scripts for starting the above three programs and recording to files.
• Icecast 2 for streaming. We are currently using the sarge package rebuilt for etch because the server in the etch package is unstable in our double-relayed configuration. (To limit bandwidth use between DebConf and the Internet, we have an internal server for internal use and an external relay that serves as master for all other relays.)
• GeoDNS and a monitoring script to resolve streams.video.debconf.org to the nearest working relay server.
• A newly-developed extension to the Pentabarf conference management system that presents recordings for review. Reviewers match up recordings to events, give the start and end time of the event in the recording so we can cut out extra material, and rate the quality of the recordings and transcoded files.
• A script to import the details of new recordings into the database ready for review, run as a cron job.
• A script to transcode recordings into multiple versions using the timing and naming information provided by reviewers. This spreads the work across multiple servers controlled using ssh (again!).

Most of the custom software and configurations should be included in the debconf-video project on Alioth.

Hmm, it's funny to be asked to blog about something. By mupltiple people. I could talk about an old church filled with a 100+ geeks, an organ played by Keith Packard, wine and cheese from all over the world, etc, but ok, I'll bite: Now that I got it working, Enrico's ept-cache is pretty neat. It found a lot of odd cruft on my laptop, along with some packages you probably don't know about that I'd be happy to chat about. termnet - Simple Telnet replacement for termnetd
grunt - Secure remote execution via UUCP or e-mail using GPG
longrun - Transmeta Crusoe LongRun control utility
iconc - Compiler for Icon, a high-level programming language
dbacl - digramic Bayesian text classifier
icont - Interpreter for Icon, a high-level programming language
bogl-bterm - Ben's Own Graphics Library - graphical terminal
intercal - an INTERCAL de-obfuscator
geotoad - geocaching query tool
libnet-openid-consumer-perl - library for consumers of OpenID identities
libapm-dev - Library for interacting with APM driver in kernel
libtextwrap-dev - text-wrapping library with i18n - development files
libklibc-dev - kernel headers used during the build of klibc
fuzz - stress-test programs by giving them random input
libdebconfclient0-dev - Development files for cdebconf
libslang2-pic - The S-Lang programming library, shared library subset kit
libnewt-pic - Not Erik's Windowing Toolkit, shared library subset kit
gnats-user - The GNU problem report management system (client tools)
libdebian-installer4-dev - Library of common debian-installer functions
mailfilter - A program that filters your incoming e-mail to help remove spam
buici-clock - attractive desktop clock)
atari800 - Atari emulator for X/curses/SDL
hercules - System/370, ESA/390 and z/Architecture Emulator This does make for fun conversations..

IPMI stands for "Intelligent Platform Management Interface", an interesting feature deployed on nowadays servers. I can't forget that question I made some months ago about an extra ethernet port on the IBM server machines we were working with on those days. The answer was quite simple: it is almost of no use at all; at most you can get some stats and diagnostics but it is mainly intended for hardware technicians.

Liars (or ignorants)! Anyway, it is quite useful. It is the IPMI port which can be used for several managements actions (even from the running system) such as power cycle the machine, get some stats, establish a watchdog interface and the like.

Uses?, are they need to be told?. As a first glance you can get reports about the machine from the operating system itself without the need of physical access to the datacenter. You can also restart a machine which is failing to reboot by itself in case you can login one more time in the system. But... even more, you can do all that (and more) from a remote system (don't exhitate, it is password protected, at least, in case you configure it so). So the next obvious uses are for cluster fencing and stonith (shot the other node in the head) without the need of power control hardware.

It is a pity we didn't knew that when we configured the SAP cluster in my previous job despite the serial cable almost did it work. Sure Mr Navas will be interested in knowing about this technology :-)

Oh, a simple example:

# ipmitool -I open chassis status
System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false
Sleep Button Disable : not allowed
Diag Button Disable : allowed
Reset Button Disable : not allowed
Power Button Disable : allowed
Sleep Button Disabled: false
Diag Button Disabled : true
Reset Button Disabled: false
Power Button Disabled: true

Another one:

ipmitool -I open chassis power reset

Ooooooops. Next post after crash :-)

First Draft of the Vim Packaging Policy Available Yay again for DebConf7!! Today the talks I attended were really interesting and in the remaining slices of time I managed to complete ... suspense ... the first draft of the Vim packaging policy \o/. The policy covers packaging of Vim addons and start to tell people about vim-addon-manager. The policy will be shipped in the next upload of the Vim package and is also available on the web. If you're maintaining a package which ships an extension for Vim please have a look, since soon it will be enforced on your package Also an eye from native English speakers will be appreciated, no matter if you speak Vim or not. PS please do not tell bzed about that, he will probably be hating me for "wasting" time on Vim rather then on polishing the first Zenoss package ever

Conversation starting tool

1. Run ept-cache info and make sure that the popcon and debtags data sources are enabled
2. Run ept-cache search -t clean -s t- less

This will show you all packages that are not shared libraries or application data, and will show you at the top of the list those packages that you have installed and other people are very unlikely to have installed. You can use that list in case someone asks you "tell me of the cool packages that you use". If you need to improvise a talk at some Linux event, that list could very easily get you started and talking for hours.

Today I was reconfiguring a Cisco 7513 with a RSP 16 and a FastEthernet module inside.
So I did a “erase nvram” and a “reload”. After booting I was surprised to see the following in my Terminal:

Would you like to enter the initial configuration dialog? [yes/no]:
Loading pxelinux.0 from 10.42.10.50 (via FastEthernet4/0/0): !!!
[OK - 13156 bytes] So the box took an IP via DHCP and tried to netboot. (Un)fortunately it only breaks my terminal, so no worries! ;) Linux, Networking, opensource, planet

A question that people often ask about wind power (and was asked in the comments section of my previous post) is what can be done when the wind speed decreases in an area. There are several methods that can be used to address this problem. The easiest option is to simply have wind farms spread out over a large area and interconnects that can spread the load. This greatly reduces the problems but is not a total solution. The next step is to have a series of power plants that can quickly ramp up supply to meet the demand. One good option for this is gas-fired power plants, while they aren’t ideal for the environment they are cheap to build and can react quickly to changing demand. If a gas fired plant is only used when wind speeds are low it should on average be running at a small fraction of it’s peak capacity and use little fuel. Another good option is hydro-electric power which can be turned on quickly, which doesn’t produce any CO2 emissions and is already used widely (about 10% of Australia’s electricity is provided by hydro-electric power). The ideal solution is to have every user of grid power know when the electricity is cheap (when there is a surplus of wind power) and when it’s expensive (when gas or hydro power is being used). Then non-critical services can be run when electricity is cheap. For example you could put clothes in your washing machine and program it to start the wash when electricity becomes cheap, some time during the day there will be a cheap time and the washing will get done. Once consumers know when electricity is cheap (via X10 or similar technology) they can use that information to determine when to use electricity generated from photo-voltaic cells on their roof and when to use grid power. The same technology can be used for heating and cooling of your home or office, turning off the A/C for an hour or so is only going to be a problem in the middle of summer or winter, for most of the year any heating or cooling could be done with cheap electricity. These technologies are all being developed at the moment (I once briefly worked on a system that could be used as a pre-cursor to managing home electricity use for times of cheap electricity).

Share This

Sound Juicer "Little Bit Of Your Song In My Ear" 2.19.2is out. Tarballs are available on burtonini.com, or from the GNOME FTP servers.

• Correctly read the album artist (#393707)
• Don't set empty track titles (#435964)
• Fix a11y on the play/pause button (#364371, Patrick Wade)

4:30am and I can't sleep... which in a way is good since it gave me some time to think about the script I posted yesterday and how it could be generalized into a simpler and far more powerful dcmd script which just expands any .dsc/.changes argument found in the command line:

elegiac$ dcmd scp -C /tmp/1/dasher_4.4.2-1.dsc romain@yeast:/tmp
dasher_4.4.2.orig.tar.gz                      100% 8728KB   4.3MB/s   00:02    
dasher_4.4.2-1.diff.gz                        100% 5231     5.1KB/s   00:00    
dasher_4.4.2-1.dsc                            100% 1259     1.2KB/s   00:00    
elegiac$

Its only limitation is that the .dsc/.changes must be local in order for Python to parse it.

elegiac$ dcmd sha1sum dasher_4.4.2-2_amd64.changes                                                   
87cd6eb29d5f54c1547b2bf7531a0e303dbc2fa3  dasher_4.4.2-2.dsc
70d0729c8955309efa230832cf5e82bd5e28cf7c  dasher_4.4.2-2.diff.gz
a5c15d3e6c3b297897651e9a5aa40451c73b2420  dasher-data_4.4.2-2_all.deb
68383058289fb41cdf19d57225afafafd4032719  dasher_4.4.2-2_amd64.deb
481e2008ad78be0721335634954dbe3a0439914b  dasher_4.4.2-2_amd64.changes
elegiac$

Sound useful?

PS: Christoph, I know that dput supports scp and rsync, but it requires a host definition in ~/.dput.cf, and works only on .changes files.

I’m now already 9 days in Edinburgh (started writing this at day 5 already :) ), and all of them have been days of “get up at 8h, breakfast, goto Teviot, work until 23h, go back to Hostel”, with some short breaks in Teviots Bar and for Lunch/Dinner. Sounds stressful but actually was (mostly) a lot of fun, preparing the network, setting up all the core servers together with two other admins while at the same time getting a lot of request to change various parts of our Conference Management System Pentabarf to fit some peoples need at various places. The airline managed to get me to EDI, together with a few other Debian people on Friday, 8th June, around noon, where Mark (mhy) Hymers did wait already, so I didn’t need to take a bus to get into the town. On the way to Teviot I also remembered some of the places from back when we did the Venue visit for the DC7 decision. But not many, of course one forgets a lot over the time. At least I was able to remember some food places, which is always a good sign. :) At Teviot we met with Stephen (sgran) Gran to (unsorted list) have some food, unload the car, think about the way to get our uplink to our server room, check into the hostel - and whatever else we did at that day. Next day, officially called Setup day, we started to get two cables from our server room to the place our uplink is - you can see them if you go to the left site of Teviot. (The other two got there a bit later). After that we started with the setup of the network, which is pretty nice this year. We have a lot of sponsored machines that are doing various tasks, a nice network layout involving a lot of vlans to seperate stuff and a lot of (good) crack. What, you dont want to listen to boring details? Ok, here they come: - The main machine is, again, called Homer. Connected with a 2Gbit link to our master switch. It does those little things noone needs, like firewall, local mirror, dns, nagios, routing between various nets we have here, the schedule bot, etc. - There is also a Marge, who is the central point for the whole wireless network, running chillispot to have authentication for it. - Barney is used as a storage server for the video team, having some 1.5TB (raid5) space for the video data. It has 2 additional disks, 500G each, to copy data on and get them home to a video team after the conference. - Our streaming master machine at DC7 is called Lisa, and does not more than streaming for all the local clients and sending the stream out to our streaming master somewhere in the internet which then relays it to our streaming servers kindly offered by a lot of admins all over the world. - We also have Bart and Maggie, which serve as public build boxes for the attendees, where Maggie even runs a distcc open to the whole local network. - You can add the same amount of servers to this list which all do various tasks for the video team. This stuff is all glued together by a set of managed switches building our core backbone, running a number of vlans to seperate the different network segments. Which actually works quite nicely, as even at the time some expert managed to plug a cable into the same switch twice (yay, loop) - the only affected network part was that where he was in. The rest of the conference didn’t even notice it - until all of the admins jumped out of the admin room at once, looking for that fuckup. :) Sounds like crack? Probably is, but is a nice setup all together, and it was fun to set it all up together with Mark and Stephen, the two main admins for this conference who designed most of the whole structure and are the ones that really know it. I already “volunteered” them for the next DebConf to help as admins and really hope they decide to do it. Later on during DebCamp we also had Peter (weasel) Palfrader joining the local admin team. His main work here is related to the video team by hosting the geodns setup for the streaming and by running a local nagios to check the things we need to check. This enabled us to simply tell everyone Use streams.video.debconf.org:8000 wherever you are and you will get to the right server for you. Explaining this in a short way basically goes as “a monitoring tool keeps track of which servers are up and only enables them to resolve. Our geodns server then replies with the right server IPs, depending on in which region of the world you are.”. Which means streams.video.debconf.org will resolve to the local streaming server lisa while you are here, at the same time resolve to a number (those that are up) servers in Europe if you are in Europe or to those in the US if you are there. Nice. (And while I’m already blogging - I do hate my laptops suspend, err - I mean non-suspend mode. Somehow it got worse in the last days, sometimes needing multiple minutes (like 10) to decide to suspend to disk, and the suspend-to-ram still wont work. I should really get someone here that knows this stuff having a look at it. :) ).

hacking at debconf Zenoss Stefano reported about the work on the Zenoss packages yesterday, now I m proud to be able to present the first screenshot from Zenoss, freshly installed by using dpkg -i. There s still a lot of work waiting for Fabio, Stefano and me, but it s great to see the first results. It s really great to work together with them, here on the Debconf. I m really happy that I can be here. At the moment we re waiting for Sean Finney no arrive, as we have some questions about dbconfig-common. hacklab pano 3 Again, here s another pano from the hacklab 1, taken yesterday evening. Sorry for the bad stitching, didn t have the time to fix it, but I hope it ll still give am impression of the great atmosphere here in the Teviot.

Right, so as announced I finished my thesis this week. Its translated title is (if anyone want to know)

"Design and Implementation of a Model for the Retrieval of Free/Libre Open Source Software using a Case-Based Reasoning System".

Writing it certainly was an educational experience but I am still happy it's done now. Especially the last weeks where rather unfunny, more so since about ten days before my deadline we had a massive heat wave here in Lower Saxony. Now that it's done I am still waiting for enthusiam to kick in. So far weariness still prevails. Maybe also because finishing my thesis does not yet end my studies. We also have to do written and oral examinations which will take place in July and after. So at the moment I spend my days mostly sleeping and trying to muster up enough wanderlust for my trip to DebConf7. (At the moment the prospect of traveling long distance with trains and cheap flights and then be surrounded by a few hundred happy people is still rather daunting.) Anyway, in order to give an impression of my last weeks and months and to sum this all up, a list of random notes, taken during the last weeks, of what I learned while writing my thesis:

• 6 months are NOT a long time!
• 10.000 chars are not enough to model a Debian package description
• 50 chars are not enough to model a Debian package name (YES, THAT MEANS YOU, libmaypole-plugin-authentication-usersessioncookie-perl!)
• osi.org does not belong to the Open Source Initiative but to Ontario Swine Improvement (Ontario Swine Improvement (OSI) is an industry-run organization dedicated to providing swine improvement and genetic products, programs, information and expertise. Our goal is to help Ontario pork producers achieve competitive advantages and excellence in the global market place.)
• I must not procrastinate.
  Procrastination is the mind-killer.
  Procrastination is the little-death that brings total obliteration.
  I will face my thesis.
  I will permit it to pass over me and through me.
  And when it has gone past I will turn the inner eye to see its path.
  Where the thesis has gone there will be nothing.
  Only I will remain.
• Dr.-Ing. Roland Bless rules! (So does his LaTeX class for theses.)
• Working without internet is possible. It is even better than working with internet. Simply leave gaps where you need to look up stuff and fill them in in the evening.
• Losing half a litre of blood does not impair my fitness for (brain) work.
• Working with version control requires a minimum of intelligence attention. Unfortunately mostly so when ending work (dead tired) and when beginning to work (dead tired).
• Side effects: Insomnia, itchy area on left leg, belly aches, little blisters on the sides of my fingers, headaches, slight but constant petulance.
• "I know what I want to say, getting it on paper is the least work." - WROOOONG!
• German is such a crappy language to write scientific texts in. Special greetings to the generic masculine. Gah!
• When the cat's writing her thesis ...
  The fun time's over now, darling ;)
• "I have don't really like proof-reading your thesis in PDF, can't you just send me the Word file?" is not what you want to hear from your proof reader.
• Good: Debian, vim, subversion, LaTeX, bibtex, evince, xpdf, pdftk, PostgreSQL, OpenOffice.org, dia, gimp, phpESP, tea, coffee, ramen, chocolate, electric fan, eating at the uni's cafeteria twince a day, raw cornflakes straight from the box, frida (my trusty laptop), power naps, pizza, people understanding my true problems, the freedom to burry myself in my work and absolutely and utterly neglect anything else until I am finished.
• The flat can look worse. Much!
• Bad:
  • The FSIL (student council for teaching students) belt grinding(!) tables on the balcony in front of the students' working rooms.
  • People trying to be nice and asking how it's going with the thesis.
  • Fellow students greeting me with "Hey still here?"
  • Our evil DPL blogging about his highly addictive monsterz just when I got to work.
• I'll do it after I handed in the thesis.
• I'll see a doctor about it after I handed in the thesis ...
• I should commit much more often (svn that is)
• How come there are so many extra 'i's in your thesis?" Because it's Linux!
• Sense of time is overrated.
• Print shop guy is mean.
  A = Me, overtired, having formatted and doing last changes to this document the whole night through and on until 20 minutes before the printing appointment.
  B = Print shop guy
  
  B: You know that's not A4 ...
  A: WHAT?!
  B: Yea, it's too big.
  A: WHAT?! But, but, I ... That can't be!
  B: I'm telling you, it's too big. See, 0.3mm too long and 0.12mm too wide
  A: ... *death stare*
  
  
• The examination office is now located in the fourth floor in the building next to the post office at the Hindenburgplatz.
• Tolimar is the most patient and understand guy I've ever known.
  Thank you!
• 6 months are SUCH a long time!

The Caps lock key is quite useless, most people agree with me here. So I configured my system to make the Caps-Key a general control key: Caps-E starts a terminal, Caps-t lists my tomboy notes, Caps-Down selects the next workspace, Caps-2 selects the second workspace. For the workspace switching commands, there are also variants with Shift that move the current window, so that Shift-Caps-Down moves the window to the next workspace, Shift-Caps-3 moves the window to the third workspace and Shift-Caps-2 does nothing.At first I thought it was a misconfiguration, but upon closer inspection I found out: As soon as Shift and Caps are pressed, all keys in the line F1-2-W-S-X, as well as the key are not registered, not even by the kernel, it seems. Is this some old legacy problem with PC keyboards, when the bits of a key code were hardwired in the keyboard? And is there a way around it?

As I wrote in past, one of targets in next stable Gammu release is to have much better support for Motorola phones. The biggest problem with them is that Motorola separated AT commands in two separate subsets and each can be issued in different phone mode. I just hacked support for this into Gammu, so basic operations with Motorola phones should work. If you have Motorola phone, I'll welcome you to test new code. Just download current snapshot or use subversion to get latest code, compile it and run against your phone.

Okay, so with the “Bits from the DPL” talk that Sam and I shared now out of the way, that hopefully means finishing off the whole dunc-tank thing won’t imply any more conflicts of interest, potential or otherwise. And since we’ve now had the post-etch release team report, there shouldn’t be much to wait around for. I’d been kinda hoping to be able to come to debconf with a pre-prepared report of similar quality to the debconf6’s final report (or debconf5’s for that matter); but while I was going back through the discussion threads, it just got harder and harder to find a way of writing the report that didn’t seem like it’d just inspire the same arguments again. I think that’s avoidable – I know some of the people who were against the way dunc-tank ended up have indicated there are other approaches they might support, and it ought to be possible to summarise the dunc-tank experience in a way that lets us have a better idea what to do in the future based on that experience, than have the same disagreements we’ve already had. Anyway, my best guess is to try crafting the report via blogging or put it on a wiki or something. Anyway, there are three things that I thought we could usefully have in a report that wouldn’t devolve into the same old arguments (after all, if we at least have new arguments, that’s some sort of progress!). First of all is trying to have a real understanding of what happened with etch – getting a release out is complicated with lots of potential blockers beyond just “release management” work: d-i, kernel, toolchain, CDs, builds, bug tracking, whatever. Presumably dunc-tank only ever had a chance of removing release management as a blocker, and since we can’t redo the etch release while changing parameters like dunc-tank or Vancouver, at least having as clear as possible understanding of which blockers happened when, and what other influences might have been important the release process seems like a good way of understanding the influences that were and weren’t important, so we can have a better idea what to do in future. I’m figuring a reasonable structure might be something like:

• Release blockers between July 2006 and April 2007
• Analsyis of bug discovery/resoution rates between July 2006 and April 2007
• Comparison of major statistics for etch with previous releases (freeze length, etc)
• Comparison of etch with Ubuntu’s edgy release (October 2006, roughly the time dunc-tank started), and feisty release (April 2007, roughly the same time as etch’s release)
• Summary of other release timliness projects: Vancouver proposal, release assistants, BTS version tracking and changes to RC bug monitoring, transition monitoring through the entire release cycle, binNMU changes, improvements in experimental support, BSP marathons
• Summary of release quality projects: DFSG-free content, LSB support, security support for testing, QA meetings, piuparts runs, whole archive rebuild testing

The theory is that the above should provide the information to make a good judgement of what (if any) effect dunc-tank (or the other projects) had on the release, without implying a preconceived conclusion of whether dunc-tank’s “good” or “bad” or whatever. As well as looking at the release stuff in some depth, it seems to me to be pretty sensible to do a report on how dunc-tank worked financially. Anyone doing any similar sort of “let’s raise funds, then spend them on free software” is going to have similar issues in getting publicity, collecting funds, and actually spending them, no matter how they end up deciding on the harder questions of deciding who or what to fund. There’s not a lot to say there, and I don’t think there’s much that’s controversial there either, but there are a few problems and approaches to solving them that are worth reporting on. I think that’s about as far as you can get trying to cleverly avoid the controversy though. And presuming we rule out the idea of choosing a position on some of the controversial questions and advocating for that (“dunc-tank was good, paying release managers was awesome, we should do it again for everyone!”), the best idea I’ve had so far is to just try summarising some of the controversial questions that remain open, which Debian, or dunc-tank, or whoever can then address in whatever way we like – by GRs, or further debate, or more experiments, or leaving it to other people to do for us, or whatever. So having the questions and some of the arguments for various answers and summarising what happened with dunc-tank seems like a plausible way to go. The questions I’ve got:

• Is paid work compatible with volunteer work?
  • How the release managers and assistants reacted to doing volunteer work while someone was paid to do similar work
  • Other developers – some donated; others resigned or reduced work
  • Dunc-bank and QA initiatives
• How much distance should there be between Debian and whoever’s funding development?
  • Involvement of DPL and high-profile developers
  • Involvement of SPI
  • Statements from press reports about the relationship
  • Votes to support/endorse/recommend against
  • Donors being confused as to where to donate funds
• How should work or developers to be funded be chosen?
  • Potential for favouritism
  • Potential for misalignment with Debian’s goals
  • Choosing based on least controversy or most benefit
• How should paid “volunteer” work be priced?
  • Covering living expenses?
  • Comparable rate to similar proprietary/commercial development?
  • “Market” rates?
  • Full-time versus part-time work
  • Contracts versus prizes or bounties or rewards

No promises as to whether they’re the best questions, the best sub-points, or that we’re going to be able to come to an answer on any of them. :) Anyway, that’s my theory so far, no I need to grab some lunch before the next lot of talks – feel free to mail me, or talk to me in person, or blog responses or whatever…

Ben Fowler writes about the issues related to nuclear power in Australia. He spends 8 paragraphs discussing the issues on the “Right” side of politics - of which 6 concern the an Australian nuclear weapons capability and then spends 3 out of 5 paragraphs related to the “Left” side explaining that he thinks that everyone who opposes nuclear power is a Luddite. Ben didn’t bother providing any links or statistics to back up his claims, so I’ll assist him in analysing these issues by providing some facts that we can discuss. In March Spain had wind power provide 27% of all electricity (making wind power the main source of power for the country). I blogged about this at the time. While Spain has an ongoing program of building new wind power stations the majority of wind turbines in Spain are quite old (the Model T of wind power) and not nearly as efficient as modern turbines that would be installed for Australian power plants. The Danish government has announced plans to use wind power for 75% of their electricity. Denmark has a much smaller land area than Australia, which means that generating so much electricity from wind power is more technically challenging for them than it would be for us. A larger land area means that when one area has low wind speeds other areas can be used to provide power. For home electricity generation wind turbines have not yet been proven to be practical. The linear speed of the blade is determined by the wind speed and the rotational speed is therefore a factor of the wind speed divided by the radius of the blades. This means that smaller turbines have higher rotational speeds which causes more noise (bad for getting council approval), also to avoid turbulence a wind turbine will ideally be some distance above the ground (8 meters is good) which again gives problems when getting approval. The O’Connor Hush Turbine is supposed to solve the noise component of this problem. It will be interesting to see whether home based wind power becomes practical in future - if so I would like to get an O’Connor turbine on my house! Home solar power has been proven to work well, in the form of both solar-electric and solar hot water (I know several people who have been happily using them for years). You don’t get cold showers when the sun isn’t shining, you instead use gas or electricity to heat the water (it’s a standard feature in a solar hot water system). Also your home electricity doesn’t go off when the sun stops shining, you have batteries that are charged during sunny times to run things overnight, and when they get flat you pay for power from the grid. It is quite realistic to stick solar power systems on every roof in the country. The added cost to the process of building or purchasing a house is negligible and the benefits include having electricity when mains power is unavailable (NB water is used in generating electricity from coal or nuclear power plants so a bad drought will eventually become a time of limited mains power). Even the smallest home solar electric system will produce enough electricity to power a fridge and freezer 24*7 so it’s a very useful backup for essential power. The government is subsidising the installation of solar electric systems, so it seems that they expect everyone to get one eventually. Dr. Ziggy Switkowski (the main advocate of nuclear power in Australia) says “the introduction of a carbon tax could make nuclear power the cheapest option by the 2020s”. In consecutive paragraphs Ben derides “carbon trading” and claims that nuclear power is “practical”. Unfortunately the main advocate of nuclear power in Australia does not believe that it is practical without a carbon tax. Ziggy also states that it would take at least 15 years to complete a nuclear power plant, unfortunately we don’t have the luxury of waiting for 15 years before starting to try and reduce the damage that we are doing to the environment. The Stern report makes the economic consequences of inaction quite clear. I am not a Luddite. I oppose nuclear power because of the risks related to accidental release of radioactive material and the routine release of radioactive material as part of the uranium mining process, and the dangers related to long-term storage of nuclear waste (let’s not assume that Star Trek science can make it all non-radioactive). Nuclear power is not cost effective for Australia and will take so long to develop that it won’t save us from the serious economic damage predicted by the best scientific models as presented in the Stern report. For large scale power generation wind power works now, can be easily implemented and has no hidden costs or risks. There will never be a Chernobyl type accident with wind power, it is inherently a safe technology. For small scale power generation (something you can add to your home) solar power works well, is not expensive (when considering the price of a house and especially when the government subsidy is counted) and has the potential to seriously reduce the amount of carbon dioxide produced.

Share This

After having been here in Edinburgh for about a week now and not having blogged about it, I'm starting to feel slightly guilty about it. Only slightly so, however. I did figure out that the wireless on my PowerBook doesn't work with 2.6.21, whereas it seems to (flakily) work with 2.6.18. Yay broadcom. Not. Anyway, life here in Edinburgh has been fun so far. Mostly. I had a bit of Mao-playing, some bit of "putting faces to names", a bit of Scotch-tasting (of which I still need to remember taking one (1) bottle home for $BROTHER who really likes the stuff), and a bit of getting-so-drunk-I-woke-up-not-yet-completely-sober-and-decided-it-might-be-nice-to-find-my-bed-again, too. Like I said, mostly fun. The guy puking on my luggage last night wasn't fun, but at least he managed to puke most of it right next to my luggage. But I'll still have some laundry to do, I guess. DebCamp to me isn't about being productive, so much as it is about meeting people and getting to know the environment. But I still managed to do some work on nbd-server, which is now at version 2.9.3 (plus some patches stolen from svn) in Debian. That helps, too. In an hour or two, I'll be doing my m68k got kicked out of etch!?!?! Oh noes! BoF. The schedule already lists 11 people who will be attending, so that's cool. Let's hope we get something productive out of it.