Even though Adrian von Bidder suggests that I'm starting a bit early with the DPL campaigning, I thought I could add a few more thoughts to the blagosphere.

Adrian suggested to make the discussion of our of "vision of Debian" a regular event on debconf - I think it's a nice idea, but that doesn't mean we should keep silent about that topic the rest of the year. I think one of the problems we see in Debian is that we are missing an aim to strive for. We are currently just moving from release to release, while more and more developers have actually lost interest in stable releases. The impression that a common ground like Debian 4.0 is irrelevant seems to prevail, because the people most vocal in our user base usually want to see the newest and shiniest software on their desktop. We have been spending more and more effort to cater to their wishes and have ignored the fact that a majority of Debian-based installations are not run by such people, but by system administrators who do mass roll-outs and neither want nor need the newest X.org with more *bling*.

Ubuntu, the biggest Debian-based distribution, has found its users by packing up new software behind a nice installer, adding some branding elements and then shipping it. Stability is an issue for Ubuntu, but they don't spend as much time as we do on eliminating the last seemingly important bug in some esoteric software package before actually releasing. That observation is the ground for one of my ideas: Our current metric to determine how far testing is away from a release is counting the number of rc bugs - it doesn't matter if the rc bug is X.org crashing for all people or if it is a policy violation in a package with 12 users. Perhaps we should start thinking about a new metric, keeping in mind that for a majority of users, some bugs matter a lot and some matter not at all. With the release of etch, the number of installations of popcon has risen a lot, so for the first time, we have actual usage data that could help us with such a metric. There are a few problems with that approach, though:

• Popcon data is inherently wrong, because single computer installations tend to have popcon, while large installations (like the one in Extremadura) don't.
• A majority of popcon users uses the last stable release, not the one currently in development.
• 3 bugs in packages seldomly used can be more annoying for our users than one central bug - you might be able to find a work around somewhere for something that happens to a lot of people, but a bug only hitting a few users will stay unfixed for a long time.

I don't have more time right now, so the rest of my ideas will follow in the next few days, so stay tuned or add me to your killfile.

Last week I installed Ubuntu Gutsy onto Heather's laptop. While Gutsy seems to be an easy task for most situations, installing it onto a Pentium 366 laptop with 200M of RAM and (particularly) an 800x600 screen was harder than it perhaps should have been. I'm sure that most installations these days aren't 800x600, but the graphical installer in Gutsy seems determined to make this painful. I had to move the toolbars to the sides of the screen, and then I could see the top half of the buttons on each page. It was like the page was sized for 600 vertical pixels, but the designer had forgotten about toolbars and title bars - not that I could see any screens in the process I followed that needed more than 5/6 of that screen anyway. Eventually I got it installed, and it even seemed to run OK once we booted into it. That's "OK for a 200M P366 with an 800x600 screen" though. Looking around at the price of a new laptop made putting up with that sort of performance a whole lot less palatable. The Acer Aspire 5310 (with free RAM upgrade) was $898 at Dick Smith, with a $99 cashback offer. A quick google shows that it's using the Broadcom 43xx wireless which isn't even close to being the best, but can be made to work with Linux. Everything else seemed likely to work, so we bought it. Installing Gutsy on it was nearly trivial, though I had to install bcm43xx-fwcutter on a different PC (my laptop, which is running Debian, in fact) to get the firmware for the WLAN before I could get the wireless working. I'm surprised that Broadcom still don't make that firmware publicly available somewhere, rather than forcing people to jump through the sort of hoops that would get them wanting an Intel chipset next time. Anyway, everything installed very easily, and the laptop is working quite nicely. Strangely neither sound, nor suspend to ram are working out of the box, but perhaps I'll get them going in due course. They're not so important in this case fortunately, but perhaps in due course I'll try and get them working and post some details about it. Much harder has been getting the fabled 'cashback' from Acer. I think I now know what I'm being paid $99 for. Firstly the only way to get your cashback is by registering through a webpage. Heather's first attempt to do this resulted in an error from our proxy about a malformed request, so I got called in. I tried registering using on my laptop, but couldn't even get to the cashback page. I then tried using IE6, with similar results. So perhaps it's my PC? I tried using a different PC, with the same result again! We tried ringing them up, but they were absolutely determined that (even after 20 minutes on the phone) they were not going to accept that information over the phone. So the only way to get the cashback from Acer was via their thoroughly broken website. Even their Contact Acer page is broken in firefox just showing a blank. Firefox users need not apply. Eventually, while spending some time in front of Heather's main computer (which had made it all the way through to submitting their on-line form before failing) I realised that the error she was getting was a proxy error from some in-form javascript submitting an invalid request, so I disabled the proxy, the form finally worked, and I managed to apply for the cashback. Now we just have to send the printed form in, along with some blood from our firstborn, the ashes of my grandmother, various barcodes, receipts and toenail clippings and we're sweet. They say they'll send us some money within 30 days. I think we should maybe frame it or something. I just know I'm going to feel really inclined to take advantage of cashback offers in future. In Other News: DVD Slideshow Meanwhile I've been playing with DVD Slideshow which seems to be just what my parents have been after for a while, so they don't have to keep their favourite photos on the camera to be able to show them off on someone's TV. It's great! At least it is great now after I changed all the calls to ffmpeg to add a 'k' after the bitrate parameter. But that's Open Source Software, I guess. I'll send a patch to them... :-)

Some time ago a friend of my sister in law contacted me and offered his services as a courier for gifts. I had told him that I knew someone in Israel and he was traveling to Sweden. So I contacted Lior with the strange proposal to give me a gift (and I promised to return the favour). A few days later I got a book about Israel from Lior, was very happy and started to ponder what kind of present could be fun and entertaining for him. I ended up going to the supermarket and bought all kinds of special swedish food (and obviously skipped some). I wrote some short notes with cooking instructions and explanations and sent the whole lot back to Israel.

I enjoyed both getting the present, reading the book and picking a present for someone I regard highly. I would like to recomment this as a fun game within Debian: If you know someone traveling abroad find out if there is a DD (or Debian contributor) around at the destination and send a present to that person. This kind of love bombing is low cost and lots of fun and creates bonds parallel to those of the Web of Trust. Try It!

Today, it's been two years I'm stuck in the NM queue. I've registered on oct 24, 2005, because Sam Hocevar told me that it could last a little, so if I was interested I should register early. I wondered for a long time if I should resign on this two years birthday, but I dropped this eventuality. I still want to be a Debian Developer, and if I resign I don't think I'll really want to still work on Xfce packages. But on the other hand I wouldn't really like to use an Xfce not packaged by me (no offense, but I guess I'd still want to hack on it) and I don't think I would be able to be on another distro. So I'm still there, sitting in NM queue, waiting for the next step. The only required step to be accepted as a Debian Developer is to have its gpg key added to the debian keyring (then an account is created on debian boxes, there's a -private subscription etc.). This is done by a team, called DAM, "Debian Accounts Managers". Because at one time they had a lot of work, they could not examine each candidate and decide if he was a potential good Debian Developer, so people imagined the NM Process: some volunteers would help them asking questions to candidates, then write a report, so DAM would only have to read it and decide if it was ok or not to create an account. I've already passed this step. I am "DAM Approved". One could imagine that, if the Debian *Accounts* Managers reviewed and approved my application, the account creation should follow. But no, the next step (according to NM pages) is "DAM creates account or rejects application". The problem here is that there is no "DAM Team", responsible for Debian accounts, but various people which are not really equivalent in this team. This is really a problem in Debian, where teams aren't really a "team". Not every team I guess, but in some cases one can trust a team to do a job. Debian is a volunteer organisation, so people think nobody can be forced to do a job if he doesn't have time to it. I'm fine with that, real life can be really time-consuming sometime. But my opinion is that teams may have to be forced to do their job. If nobody in the team has time, fine, it means somebody should join the team. But the team itself shouldn't fail, and this should be the only thing visible from outside: the "team", and the team actions. There are some proposition about this on lists at the moment, but I don't really know how it'll end. It's not easy doing social stuff, there's a lot of people involved, with many different views. But sometimes the consensus is *not* findable, and sometimes, somebody has to decide. That's why why need team leaders, and that's the project leader role. I guess people are quite opposed to have a "strong" leader in a volunteer organization, and I don't have concrete proposals but I really thing team management is not really perfect and a lot of people (users and developers) suffer from that (not only NM applicants, I mean) and from "elephants". As I said, I have no good solution, nor even concrete proposals (except "sometimes we need a leader to make decisions") but I really think there are things Debian (as a project) needs to improve.

After Ubuntu and Fedora, it’s time to regularise your Debian installation. Please help us by providing evidence to fight piracy.. Breaking News
Hundreds of Debian customers provide evidence to help FBI and China s Public Security Bureau crack $2 billion global software counterfeiting syndicate. The svg file.

awesome developement is in a very good shape. We're now more than half way on the 2.0 road. The contributors base is increasing, since there's now 2-3 people regularly sending patches, so this is very good, and the (still small) users base is increasing smoothly. The awesome core code is step by step rewritten in a better and more generic way. The next big work is tabs implementation, that I am still postponing right now because of the core which is not ready to handle. It needs to become even more generic to not break everything by adding such a feature. I still hope to release awesome 2.0-rc1 by the end of november.

Is it a sign that Sam should post the next Bits? ;-) I particularly like Marc's idea of a “liaison officer” to the other distributions in the Debian crowd. Can't say anything about that buildd and architecture issues, not knowing enough. Force-feeding the core teams more members is obviously a bad solution, but it's equally obvious that the current state of affairs should not continue. The “Vision of Debian” stuff should probably become a regular session at Debconf (based on the idea that face to face discussions are better than electronic ones, and that Debconf is truly the official meeting point for Debian, and that all important people should come to Debconf.) Only losely related to how to deal with child projects: there are two solutions: lock them out or outrun them. (Somewhere I can't remember I read something like this.) Obviously, we don't want to lock them out. So ... I should get working. Gah. It always comes back to me not doing enough for Debian. Sorry, folks.

I have previously posted about the difference between using a chroot and using SE Linux [1]. Theo de Raadt claims that virtualisation does not provide security benefits [2] based on the idea that the Xen hypervisor may have security related bugs. From my understanding of Xen a successful exploit of a Xen system with a Dom0 that is strictly used for running the DomU’s would usually start by gaining local root on one of the DomU instances. From there it is possible to launch an attack on the Xen Dom0. One example of this is the recent Xen exploit (CVE-2007-4993) [3] where hostile data in a grub.conf in a DomU could be used to execute privileged commands in the Dom0. Another possibility would be to gain root access to a DomU and then exploit a bug in the Xen API to take over the hypervisor (I am not aware of an example of this being implemented). A final possibility is available when using QEMU code to provide virtual hardware where an attacker could exploit QEMU bugs, an example of this is CVE-2007-0998 where a local user in a guest VM could read arbitrary files in the host [4] - it’s not clear from the advisory what level of access is required to exploit it (DomU-user, DomU-root, or remote VNC access). VNC is different from other virtual hardware in that the sys-admin of the virtual machine (who might be untrusted) needs to access it. Virtual block devices etc are only accessed by the DomU and Xen manages the back-end. The best reference in regard to these issues seems to be Tavis Ormandy’s paper about hostile virtualised environments [5]. Tavis found some vulnerabilities in the QEMU hardware emulation, and as QEMU code is used for a fully virtualised Xen installation it seems likely that Xen has some vulnerabilities in this regard. I think that it is generally recommended that for best security you don’t run fully virtualised systems. The remote-console type management tools are another potential avenue of attack for virtualised servers in the case where multiple users run virtual machines on the same host (hardware). I don’t think that this is an inherent weakness of virtualisation systems. When security is most important you have one sys-admin running all virtual machines - which incidentally seems to be the case for most implementations of Xen at the moment (although for management not security reasons). In ISP hosting type environments I doubt that a remote console system based on managing Xen DomU’s is going to be inherently any less secure than a typical remote console system for managing multiple discrete computers or blades. I have just scanned the Xen hypervisor source, the file include/asm-x86/hypercall.h has 18 entries for AMD64 and 17 for i386 while include/xen/hypercall.h has 18 entries. So it seems that there are 35 or 36 entry points to call the hypervisor, compared to 296 system calls on the i386 version of Linux (which includes the sys_socketcall system call which expands to many system calls). This seems to be one clear indication that the Linux kernel is inherently more complex (and therefore likely to have a higher incidence of security flaws) than the Xen hypervisor. Theo’s main claim seems to be that Xen is written by people who aren’t OpenBSD developers and who therefore aren’t able to write secure code. While I don’t agree with his strong position I have to note the fact that OpenBSD seems to have a better security history than any other multi-user kernel for which data is available. But consider a system running Xen with Linux in Dom0 and multiple para-virtualised OpenBSD DomU’s. If the Linux Dom0 has OpenSSH as the only service being run then the risk of compromise would be from OpenSSH, IP based bugs in the Linux kernel (either through the IP address used for SSH connections or for routing/bridging to the OpenBSD instances), and from someone who has cracked root on one of the OpenBSD instances and is attacking the hypervisor directly. Given that OpenSSH comes from the OpenBSD project it seems that the above scenario would only add the additional risk of an IP based Linux kernel attack. While a root compromise of an OpenBSD instance (consider that a typical OpenBSD system will run a lot of software that doesn’t come from the OpenBSD project - much of which won’t have a great security history) would only lose that instance unless the attacker can also exploit the hypervisor (which would be a much more difficult task than merely cracking some random daemon running as root that the sys-admin is forced to install). Is the benefit of having only one instance of OpenBSD cracked due to a bad daemon enough to outweigh the risk of a Linux IP stack? I’m sure that the OpenBSD people would consider that a better option would be OpenBSD in the Dom0 and in the DomU. In which case the risk of damage from a root compromise due to one badly written daemon that didn’t come from OpenBSD is limited to a single DomU unless the attacker also compromises the hypervisor. When working as a sys-admin I have been forced by management to install some daemons as root which were great risks to the security of the system, if I had the ability to install them in separate DomU’s I would have been able to significantly improve the security of the system. Another flaw in Theo’s position is that he seems to consider running a virtual machine as the replacement of multiple machines - which would be an obvious decrease in security. However in many cases the situation is that no more or less hardware is purchased, it is just used differently. If instead of a single server running several complex applications you have a Xen server running multiple DomU’s which each have a single application then things become much simpler and more secure. Upgrades can be performed on one DomU at a time which decreases the scope of failure (which often means that you only need one business unit to sign-off on the upgrade) and upgrades can be performed on an LVM snapshot (and rolled back with ease if they don’t succeed). A major problem with computer security is when managers fear problems caused by upgrades and prohibit their staff from applying security fixes. This combined with the fact that on a multiple DomU installation one application can be compromised without immediate loss of the others (which run in different DomU’s and require further effort by the attacker for a Xen compromise) provides a significant security benefit. It would be nice for security if every application could run on separate hardware, but even with blades this is not economically viable - not even for the biggest companies. I have converted several installations from a single overloaded and badly managed server to a Xen installation with multiple DomU’s. In all cases the DomU’s were easier to upgrade (and were upgraded more often) and the different applications and users were more isolated. Finally there is the possibility of using virtualisation to monitor the integrity of the system, Bill Broadley’s presentation from the 2007 IT Security Symposium [6] provides some interesting ideas about what can be done. It seems that having a single OpenBSD DomU running under a hypervisor (maybe Xen audited by the OpenBSD people) with an OpenBSD Dom0 would offer some significant benefits over a single OpenBSD instance.

• [1] http://etbe.coker.com.au/2007/08/22/se-linux-vs-chroot/


• [2] http://kerneltrap.org/OpenBSD/Virtualization_Security


• [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4993


• [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0998


• [5] http://taviso.decsystem.org/virtsec.pdf


• [6] http://shell.cse.ucdavis.edu/~bill/virt/virt.pdf

Share This

Yoe seems to believe I see a cabal in Debian. Let me assure you: I don't - and if there would be a cabal, I would be part of it. I've seen most of Debian, played around with NM, the release team, have seen how our buildd network works (or, in the specific case of today: mostly works) and have close contact to people in all other core teams of the project. I still haven't seen a sign of a Cabal.

I believe that there are "clusters" of people who work better with each other, simply because they have known each other for years and developed trust, but that's nothing I would actually mark as problem. I do the same. Many of our core people have too much work to do, mostly because getting a job well done is usually reason to give you more tasks until your performance becomes abysmal. That doesn't mean that they are bad people or do bad things intentionally, but often, they don't allow people to help them - the usual reasoning is "new people need training, training needs time, time is what I don't have => no new people". Obviously, that argumentation is flawed in the long run.

Anyway, on to the more technical details:

• The real reason for not adding new architectures is that not one of the people able to do so cares enough to do it. That doesn't sound as nice as "I don't really know why we don't do it", does it?


• I haven't asked the security team to support backports, and I won't. volatile isn't under the supervision of the security team and works just fine.


• Most porting machines aren't "down", they are "locked down". See the list of Debian machines (which is, BTW, seriously out of date). Hardware failure is something completely different (though we might want to think about using Debian funds to replace broken machines, if needed), but restricting access is a sign of an overloaded team of system administrators.


• Dictating how a team should be changed is usually not a good way to do things - but there isn't another. A few of our core teams have failed to solve their problems on their own. Debian's job now isn't to stand by, watching and saying "He, that's bad. Maybe they'll fix the team in the next decade". Also, there are people experienced with the tasks of these core teams who are not part of them - you might want to use their experiences.


• With my release team and unofficial buildd network hat on I will tell you that adding one buildd maintainer for those architectures that only have one at the moment would improve the situation a lot. Please don't assume that I only talk about stuff I have no idea of. Sometimes I actually know about things!


• I don't think that we need to change our position regarding the GFDL, but I do believe that we should work on our relation to the FSF. Debian is the biggest free-as-in-free-as-in-free-speech distribution on the market, so the FSF should actually be interested in working together with us. Still, that doesn't happen, so we should perhaps start by having a discussion what the problems of each of these organisations is in the eyes of the other.

And, FWIW: I do hate conspiracy theories too. They come to life because people usually want to see the "bigger picture" - even if there is none and all of the weirdness in their environment can be explained by chance, human error and unknown social problems. And as I said - I don't believe there is a group of people making decisions that seem bad for Debian. I just believe a lot of people try to do their best for Debian - but they fail on a regular basis.

I’ve been asked for my opinion of senatoronline.org.au which claims to be Australia’s only internet-based political party. The claim may be correct depending on what you consider to be “Internet based“. Here is a copy of their platform from their web site:
Senator On-Line is not aligned to any other political party it is neither Liberal nor Labor. Senator On-Line ( SOL ) is a truly democratic party which will allow everyone on the Australian Electoral roll who has access to the internet to vote on every Bill put to Parliament and have its Senators vote in accordance with a clear majority view. We will be running candidates for the upcoming federal Upper House (Senate) elections. When a SOL senator is elected a web site will be developed which will provide:

• Accurate information and balanced argument on each Bill and important issues


• The vast majority of those registered on the Australian Electoral roll the chance to have their say by voting on bills and issues facing our country


• A tally of all votes which will then count in Parliament

Each person on the Australian Electoral roll will be entitled to one vote and only be allowed to vote once on each bill or issue. SOL senators will have committed in writing to voting in line with the clear majority view of the SOL on-line voters. Senator On-Line will enable broader community involvement in the political process and the shaping of our country. If you like the concept, please register your details and tell others about SOL.
Now at first glance it sounds like a good idea, the Liberal party (which is similar in all the bad ways to the US Republican party) has demonstrated what happens when a party gets away with entirely ignoring the wishes of the voters. But there are three significant problems with the Senator Online idea. The first is the issue of providing “Accurate information and balanced argument on each Bill“. We have seen many media outlets claiming that there is a debate about global warming (the debate ended years ago, the vast majority of scientists have agreed that global warming existed for a long time) and now the same media outlets are claiming that there is a debate about whether it will cause any harm to us in the near future (ignoring all the dams that are running low). One of the aims of the democratic process is that representatives who spend all their time working on politics can fully analyse the issues and also gain access to resources that are not available to the average citizen, thus being able to make better informed decisions. The next problem is that it can degenerate into mob-rule. The idea of having a tabloid TV show being able to directly control votes in the senate is not an exciting one. The final problem is how to ensure that each citizen gets the opportunity to have exactly one vote, solving this requires good security and identity checks involving viewing photo-id. The checks used for voting (merely asserting your name and residential address) might be considered adequate for an election, but are grossly inadequate for online voting where one false registration allows many false votes. I think it would be more interesting to have a populist party started that campaigns for the issues that have the most impact on the majority of citizens. Issues such as the fact that a couple on the median income can’t afford the median house price [1], the lack of job security that is caused by recent industrial relations legislation, the price of health-care, and the fact that any car which is affordable on a single median income (after money is spent on rent and other basic living expenses) will lack basic safety features such as air-bags. While the Green party has decent policies on these issues they have many other policies to consider. A party that solely concentrated on allowing more people to have decent health care, not risk losing their job, own their own home, and drive a safe car would get a lot of interest from people who don’t normally take much notice of politics.

• [1] http://etbe.coker.com.au/2007/08/06/housing-prices/

Share This

I request assistance with maintaining the dctrl-tools package. There are several tasks that could use more manpower (in no particular order):

• Writing test cases
  One could mine the BTS for past bug reports and create regression tests for them.
  One could use standard black-box and white-box testing techniques to generate general tests.
• Writing documentation
  The whole suite of tools could use a unified tutorial manual on how to best use it. The current documentation is reference material in the man pages.
• Internationalise the man pages
  Use po4a?
• Swatting the BTS wishlist entries
  I’ve kept the BTS clean of actual bugs pretty well, but there are a number of wishlist reports still outstanding.
• Take over maintaining the debian/ directory
  If you commit to maintaining it (and I trust your judgment), you’ll get last say in that part of the package (including deciding what helper to use).
• Whatever you wish
  Discuss on the dctrl-tools-devel mailing list first though.

Eventually I’d like to pass the package on to competent successors, but I have too much emotional attachment to the package to do that without a transitional period where I still retain a veto on what goes in the package. I also have some ideas for future tools that I’d like to be
able to concentrate on, and having co-maintainers might allow that. The package is now under Git in collab-maint. See the new README.Debian for information and a push-access code of conduct.

A short program I wrote has searched the web and revealed many names for frailty:

• Frailty, thy name is Abbey.
• Frailty, thy name is Astronaut
• Frailty, thy name is a Tag Cloud.
• Frailty, thy name is Bingles
• Frailty, thy name is Blog.
• Frailty, thy name is Brand Loyalty
• Frailty, thy name is Browser.
• Frailty, thy name is Carelessness.
• Frailty, thy name is Carl.
• Frailty, thy name is Doctor.
• Frailty, thy name is Eleanor
• Frailty, thy name is Emo.
• Frailty, thy name is English.
• Frailty, thy name is Facebook.
• Frailty, thy name is Falco.
• Frailty, thy name is Female.
• Frailty, thy name is Fide.
• Frailty, thy name is Filmmaker
• Frailty, thy name is Francine.
• Frailty, thy name is the Gaming Press.
• Frailty, thy name is Gates.
• Frailty, thy name is Genius.
• Frailty, thy name is the Global Laser Tag League Council.
• Frailty, thy name is Hamlet.
• Frailty, thy name is Harry.
• Frailty, thy name is Horse.
• Frailty, thy name is Human.
• Frailty, thy name is iPod.
• Frailty, thy name is the Love of Ready-Made Congregations, and Ready Built Churches.
• Frailty, thy name is Machine.
• Frailty, thy name is Man.
• Frailty, thy name is Mankind.
• Frailty, thy name is Marriage.
• Frailty, thy name is a Misnomer.
• Frailty, thy name is Old Age.
• Frailty, thy name is Outsourcing.
• Frailty, thy name is Phrailty.
• Frailty, thy name is Pigeon.
• Frailty, thy name is Ryan.
• Frailty, thy name is Sceptre.
• Frailty, thy name is Sci-Fi.
• Frailty, thy name is Solana.
• Frailty, thy name is Tehran.
• Frailty, thy name is This.
• Frailty, thy name is Typepad.
• Frailty, thy name is US.
• Frailty, thy name is Weakness.
• Frailty, thy name is Whining.
• Frailty, thy name is Woe.
• Frailty, thy name is Worm.

It eliminated a few as well:

• Frailty, thy name is certainly not SIRO.
• Frailty, thy name is not Jane.
• Frailty, thy name is not Me.
• Frailty, thy name is not necessarily Viola.
• Frailty, thy name is not Woman.

Reporters Sans Frontiers (AKA RSF AKA Reporters Without Borders) has an interesting document about blogging [1]. They are specifically focussed on blogging as a way of reporting news. Their definition of a blog states that it is “a personal website” (there are many corporate blogs run by teams) and that it contains “mostly news” (most blogs that I read contain mostly technial information about computers and any “news” is mostly about the author). They also describe a blog as being set up with an “interactive tool” - most blogs are written using web-based tools, but some are written with plain text and a compilation system. Some of their technical information is simply wrong. For example they say that RSS “alerts users whenever their favourite blogs are updated” (this can be done through RPC notification which then requires RSS to pull the data - but a user will almost always have a tool polling their favourite RSS feeds). Their section listing the various options for blogging platforms mentions LiveJournal, Blogger, and MSNSpaces but doesn’t mention Wordpress.com which seems to be a serious omission (although it does mention civiblog.org which is a useful hosting resource for grassroots political campaigning). But these are minor problems, they are reporters primarily not programmers. Their document gets interesting when it gives links to pages about blogging ethics. One page that was not directly linked (presumably because it mainly concerns non-journalistic blogging) is Rebecca Blood’s document about blogging ethics [2]. She gives a brief coverage to conflicts of interest and gives most space to the topic of maintaining a record of changes. One thing I have been considering is having a separate instance of Wordpress for documents that change [3]. This way regular blog posts (such as this one) can be relied on to preserve a list of changes (any change other than correcting a typo will be documented) so if you link to a post you can rely on the original intent being preserved. But for posts which have ongoing value as live documents they will be kept current without a significant change-log. Items that go into the main blog would include commentary on news and predictions, and the document blog would contain technical information about Linux, the science-fiction stories that I will eventually write, etc. When I wrote my previous blog post about this issue I was mainly considering technical issues, but when considering the ethical issues it becomes clear that I need a separate blog (or other CMS) for such things. The site etbe.coker.com.au needs to be a reliable record of what I wrote while another site such as docs.coker.com.au could contain live documents with no such record. The essential factor here is the ability of the user to know what type of document they are seeing. Another really interesting point that Rebecca makes is in regard to known bad sources. Sometimes a known bad source can produce worthy data and is worth referencing, but you have to note the context (which among other things means that if the worthy data gets any reasonable number of hits it may get replaced by something entirely different). If a blogger cites a reference on a known bad site and explains the reason for the reference (and the fact that the nature of the site is known) then the reader reaction will be quite different to just a reference with no explanation. As a contrast to Rebecca Blood’s document the cyberjournalist.net code of ethics [4] covers the traditional issues of journalistic integrity, “public interest” etc. One interesting issue that they raise (but apparently don’t address) is the definition of “private people“. While it is generally agreed that movie stars and similar people deserve less protection as they have chosen to be in the public eye the situation regarding bloggers is less clear. Is a blogger with a high ranking on technorati.com in a similar position to a Hollywood star when it comes to privacy? A claim is sometimes made that blogs are unreliable because they can change (based on the actions of some bloggers who change posts with no notification and turn sections of the blogsphere into a swamp). Magazines and newspapers are held as an example of unchanging content and people who publish online magazines sometimes express horror at the idea of changing a past issue. The fact is that newspapers and magazines never changed past issues because it is impossible to recall hundreds of thousands of printed documents that are distributed around a country or the world. When it’s possible to fix old issues (as it is online) then the requirement is to document the changes not keep bad versions. It probably would be a useful feature for a blogging package to have the ability to display (and link to) old versions of a page. This would allow the users to easily see the changes and anyone who references a post can reference a particular version of it. In some situations it may make sense to use a Wiki server instead of a Blog server for some data to preserve the change history. Maybe I should consider a wiki in which only I have write access for my documents repository. No-one seems to cover the issue of how to deal with fiction. Obviously for a blog such as 365tomorrows.com (a science-fiction blog) it’s assumed that all content is fictional unless stated otherwise. The problem comes when someone includes fiction amongst the non-fiction content of a blog. I recently unsubscribed from a blog feed when the author revealed that what appeared to have been a diary entry was actually a fiction story (and a poor one at that). If your blog has mostly non-fiction then any fiction must be clearly marked, probably including the word “fiction” in the title and the permalink would be required to avoid all potential of confusion. For my documents CMS/blog I am considering having a category of “fiction” and to use the category name in the permalink address of each post. Of course science-fiction is sometimes obvious as fiction, but to avoid problems with fiction that is set in current times I think it’s best to clearly mark all such posts. The old-fashioned media seems to have dealt with this, tabloid womens magazines (which almost everyone reads occasionally as they are often the only reading materiel in a waiting room) traditionally have a fiction story in every issue which is clearly marked. Another type of blogging is corporate blogging. I wonder whether that needs to be covered separately in an ethics code. One thing that the three documents about ethics have in common (as a side-note in each) is the fact that the personal reputation of the writer depends on their ethics. If you are known for writing truthfully and fairly then people will treat your posts more seriously than that of writers who lie or act unfairly. There are direct personal benefits in acting ethically. The RSF document claims that the sole purpose of ethics standards is to instill trust in the readership which directly benefits the writer - not for any abstract reasons. Whenever ethics is mentioned in terms of writing there is always someone who claims that it can’t be enforced, well many people in your audience will figure out whether you are acting ethically and decide whether they want to continue reading your materiel. I wonder whether Planet installations should have ethics codes and remove blogs that violate them. In conclusion I think that a complete code of ethics for blogging needs to have some IF clauses to cover the different types of blog. I may have to write my own. Please let me know if you have any suggestions.

• [1] http://www.rsf.org/IMG/pdf/handbook_bloggers_cyberdissidents-GB.pdf


• [2] http://rebeccablood.net/handbook/excerpts/weblog_ethics.html


• [3] http://etbe.coker.com.au/2007/09/30/blogging-and-documents/


• [4] http://www.cyberjournalist.net/news/000215.php

Share This

I’d like to make somewhat more visible what some of you already know, that I have bipolar disorder. I was diagnosed a bit more than a year ago. I’m doing this mainly because I think visibility matters. First and most important, because in my experience it can be helpful and comforting to hear about other people whose names you recognize that can relate to your situation. And second, in case it helps a tiny bit in detabooizing mental ilnesses and their drugs. (But fortunately geek circles seem to need less of that than other, more prejudiced environments.) On a more personal note, I can’t but be grateful after six months of straight euthymia, during which I’ve regained control of my life, written code, attended events, and retaken long term projects. I also feel, after many years, less fearful of the future. And finally, let me add I can’t imagine having made through it without one particular friend, who doesn’t even read this blog. Should everybody be so lucky.

Belatedly, as promised, here are the questions from the floor at last week's half-year meeting of the Co-operative Group Kennet and Avon area. All errors and omissions are mine, of course.

How do we defend against demutualisation and private equity attacks?

Our rules are now written so that demutualisation would require assets to be transferred to other co-operatives. Please comment on other ways to the current constitutional review consultation.

How can ordinary members get informed and involved in running the group?

Get items into network, call the regional office.

The consitutional review should give more power to meetings and make it easier for motions and binding promises.

will forward this to the review.

Why did the group secretary suddenly leave?

The job had changed post-merger, with different responsibilities.

How can we stop the payments to voluntarily-retiring directors?

The area has made its point. The chief executive of CooperativesUK will look into this and there was a congress motion to look into this issue.

There's been no mortgage advisor in one local bank branch for months. Is this indicative of the bank's attitude to mortgages?

No, it's disappointing. Please send details to the area secretary.

Please can we use geographic numbers instead of the expensive 0845 for the membership enquiries?

Will forward and ask for a geographic number.

Is the constitutional review being rushed?

It's streamlined because the merger gives a pressing need, but we want member input.

Can we or do we promote credit unions in-store?

Yes, we can and do promote them to members already. Can set aside some space in-store if needed.

Does the co-operative travel insurance discriminate against over 75s?

will forward the answer when we have it.

The top management post-merger are all from United: is this a take-over?

no, 2 executives had clear intentions to retire already and the lower levels are more mixed.

Which? gave the co-operative food a D for organic produce: why and what will we do about it?

Report from today's Guardian not yet seen. Expect to respond in next few days. The report may have compared convenience stores with larger stores.

Will ex-United travel agents become the co-operative travel stores?

Yes. There's a big big change coming, to be more of a community travel agent, restructured, with more phone and internet options.

Is the energy-saving policy to include refrigeration, lighting and IT?

This is a top goal, to improve refrigeration and lighting control. It saves the earth and saves money. Nearly all electricity is already "greener" electricity.

Do we own the freehold on the land previously occupied by a store at Shirehampton?

Yes. Only a non-food retailer will be allowed in.

Why do elected representatives have to retire at 70 if still capable?

Please submit comments on it to the constitutional review?

Why was there no transport from Weston-super-Mare?

Will check the office records for requests.

Anyone see these themes appear at other meetings? Any comments on these themes?

Some people did ask me to add a “tech” category to my blog, and randomly post about useful little things that help making life easier. Well, Im not making a dedicated category for it, but one where I will put all my not-strictly-debian related “tech” content in. Up to now my blog only knew a debian category… :) Well, so the first thing i have a little to write about is clusterssh. It is similar to dsh, with the difference that clusterssh opens an xterm for every host you want to control, while dsh simply takes one commandline and executes it on the remote host(s). This way clusterssh allows you to step in and control a single host, if that one needs a little extra action, while keeping the connection to all other hosts open. After you are done with the extra action - just go back to control all hosts at once. Very helpful if you edit configuration files, and one hosts needs a little different value, while most stuff is the same. Or doing security upgrades and find out one of your colleagues was so “clever” to install an extra package which now makes aptitude want to remove half of your system. You can step in and fix the situation and then simply continue with all hosts. Usage of clusterssh is pretty simple - after you installed it type

  cssh machine1 machine2 machine3

and clusterssh will open 3 xterms and one control window. Whatever you type into that control window is then send to all 3 machines. As you can see in the picture I first executed one command on both hosts, by typing it into the CSSH window, and then selected one host directly, typing a command only this host sees. Now, we are all lazy, so lets make cssh easier to use. Noone wants to type hundreds of hostnames all the time. Luckily clusterssh has a concept where you map tags to servernames. If you are the admin of your machine and want to setup such a mapping for all of your users you edit /etc/clusters, if you just want to do it for yourself edit $HOME/.csshrc. Actually - do not edit it, but run

  cssh -u >$HOME/.csshrc

and edit the generated file. Ignore all of the config stuff for now, defaults are nice and good. Go to the bottom and add something similar to the following lines:

 clusters = foo bar
 foo = miau wuff:2222 root@milk:98 root@elsewhere
 bar = root@miau:443 web@ftp:443

Replace with hosts you can actually login to. The above defines two set of hosts, foo and bar. Now all I need to do to login to the defined machines is to type

 cssh foo

and clusterssh will open 4 xterms and login to the machines. At work I usually have up to 200-250 machines open with clusterssh, so it can handle large numbers of hosts at once. In such cases you might want to consider adding the -G parameter to the commandline, to not get clusterssh to resize the xterms. A last thing I like to do is - give the xterms opened by clusterssh a different layout. My window manager is setup to draw all my terminals maximized and also has some other settings that do not really help clusterssh terminals . But there is a simple way round this. Edit the following options in your .csshrc to look similar like

terminal_allow_send_events=-xrm '*.VT100.allowSendEvents:true'
terminal_args=-class CSSH

This will put all xterms into the class CSSH. As your normal settings usually apply to class XTerm this already ignores them. If you want to setup some more things, like a blue background and red foreground in CSSH windows, just add the following into your $HOME/.Xdefaults file (or do whatever steps your window manager might like to configure such things):

CSSH*background: Blue
CSSH*foreground: Red

Activate with xrdb -load ~/.Xdefaults, done.

short package update Didn't find the time to blog lately, so here's the very short summary of (hopefully) all news regarding the more important packages I take care of: gimp-plugin-registry / gimp-refocus gimp-plugin-registry is at version 0.4.2-1 now, including several updates and new plugins since my last blog entry. Also I've moved the refocus plugin into gimp-plugin-registry - now gimp-refocus is only a transitional package, which will install gimp-plugin-registry. gimp-refocus will be removed from Debian before Lenny will be frozen. As it was not shipped with Etch there's no need keep the transitional package in the release. gpsd Successfully hijacked gpsd, the new upload fixed a lot of bugs, including one old RC bug which was the reason why gpsd was removed form testing. If you're using gpsd please check the packages in unstable - comments appreciated. If you've used libgps form the gpsd package before, you'll have to look into the libgps-dev and libgps16 packages now. Bugs against packages using the library were filed in time. Also I plan to get a beta version of 2.35 into experimental during the next weeks, which will come with a more or less completely rewritten NMEA layer and a lot of fixes and improvements. radiance Finally integrated in Debian! Development of radiance started in 1985 and is still actively developed, but nobody every thought about including it in Debian. I'll blog about radiance later, in the meantime please read this wikipedia article. viking Today the latest version 0.9.3 was uploaded to unstable. Most important addition: Realtime GPS tracking, using gpsd. If you're interested in OpenStreetMap, geocaching or any other fun with GPS devices, take a look into viking.

I have just read an interesting post speculating about the possibility of open source hardware [1]. To some extent things have been following a trend in that direction. Back in the bad old days every computer manufacturer wanted to totally control their market segment and prevent anyone else from “stealing their business”. Anti-competitive practices were standard in the computer industry, when you bought a mainframe you were effectively making a commitment to buy all peripherals and parts from the same company. The problems were alleviated by government action, but the real change came from the popularity of PC clones. White-box clones where every part came from a different company truly opened up the hardware development, and it wasn’t all good. When running a simple single-tasking OS such as MS-DOS the problems were largely hidden. But when running a reliable multi-tasking OS such as Linux hardware problems became apparent. The PCI bus (which autoconfigured most things) reduced the scope of the problem but there are still ways that white-box machines can fail you. Now when I get a white-box machine I give it away to members of my local LUG. My time is too valuable to waste on debugging white-box hardware, I would rather stick to machines from IBM and HP which tend to just work. Nowadays I buy only name-brand machines, all the parts were designed and tested to work together - this doesn’t guarantee that the machine will be reliable but it does significantly improve the probability. Fortunately modern hardware is much faster than I require for the work I do, so buying second-hand name-brand machines (for less money than a new white-box machine) is a viable option. The PCI bus [2] standard from Intel can be compared to some of the “Open Source” licenses from companies where anyone can use the software but only one company can really be involved in developing it. One significant impediment to open hardware development is the proprietary nature of CPU manufacture. Currently there are only a few companies that have the ability to fabricate high-end CPUs so projects such as OpenRISC [3] which develop free CPU designs will be limited to having their CPUs implemented with older technology (which means lower clock speeds). However this doesn’t mean that they aren’t useful, tailoring factors such as the number of registers, the bus width of the CPU, and the cache size to match the target application has the potential to offset the performance loss from a lower clock speed. But this doesn’t mean that an OpenRISC or similar open core would be ideal for your typical desktop machine. If companies such as Intel and AMD were compelled to fabricate any competing CPU design at a reasonable cost (legislation in this regard is a possibility as the two companies collectively dominate the world computer industry and it would be easy for them to form a cartel) then designs such as OpenRISC could be used to implement new CPUs for general purpose servers. Another issue is the quality of support for some optional extra features which are essential for some operations. For example Linux software RAID is quite good for what it does (basic mirroring, striping, RAID-5 and RAID-6), but it doesn’t compare well with some hardware RAID implementations (which actually are implemented in software with a CPU on the RAID controller). For example with a HP hardware RAID device you can start with two disks in a RAID-1 and then add a third disk to make it a RAID-5 (I’ve done it). Adding further disks to make it a larger RAID-5 is possible too. Linux software RAID does not support such things (and I’m not aware of any free software RAID implementation which does). It would certainly be possible to write such code but no-one has done so - and HP seem happy to make heaps of money selling their servers with the RAID features as a selling point. Finally there’s the issue of demand. When hardware without free software support (such as some video cards which need binary-only drivers for best performance) is discussed there is always a significant group of people who want it. The binary-only drivers in question are of low quality, often don’t support the latest kernels, and have such a history of causing crashes that kernel developers won’t accept bug reports from people who use them, but still people use them. In the short-term at least I expect that an open hardware design would deliver less performance and in spite of the fact that it would have the potential to offer better reliability the majority of the market would not accept it. The production volume of electronics gear is the major factor determining the price so it would cost more. I think that both IBM and HP provide hardware that is open enough for my requirements, they both have engineers working on their Linux support and the interfaces are well enough documented that we generally don’t have any problems with them. Both Intel and AMD and the major system vendors are all working on making things more open, so I expect some small bug significant improvements in the near future.

• [1] http://www.raiden.net/?cat=2&aid=315


• [2] http://en.wikipedia.org/wiki/Peripheral_Component_Interconnect


• [3] http://en.wikipedia.org/wiki/OpenRISC

Share This

Sometime in August, I said I would watch the Inbox Zero talk later on that day. Well, I finally did today. And I'm ready to mass-murder my (now not so) fat inbox folder and start from scratch, and becoming a good boy. In fact, I've been on probation for a few weeks. While I wasn't watching the talk (which is pretty insightful and fun, and useful if you also have these horrid mail handling problems) I did roll up my sleeves a few times and worked on reducing the problem. After a few rounds of fighting, things were looking slightly better. I deleted TONS of spam which still was sitting in there. I deleted entire threads of list mail which for some reason wasn't being filtered properly. I archived a lot of random, misc email. I even replied to some job offers, for a change. I fixed my .procmailrc a little to get rid of lots of useless stuff that appears in my mail. It got better, but not entirely better. I went from the 6600~ which was probably the figure when I said Enough! to around 2580. It's still a lot, and I can still get rid of a lot more with easy pattern searches in mutt. The good news is that, for the first time in ages, the number of emails in the mailbox has stayed stable for more than a month. I tell you: I'm proud! So Merlin gets asked in the talk what to do when you've been a naughty boy for a long time, and you've ended up with this HUGE mailbox you can't handle anymore. His answer was what some people suggested in blog comments: put it aside, start from zero. Merlin calls it mail-DMZ, and that's probably what I'll do in a few hours, admittedly with a sentiment of guilt deep in my chest. And from that point, I'll have my mailbox be a TODO list. Delete. Defer. Delegate. Respond. Do. Simple! Other Planet Debian participants like joeyh commented that something that really helps is reducing the number of times you poll for email. For me, that means

set daemon      1800            # Pool every 30 minutes

when it was 5 minutes before. I hope I won't find myself issuing awaken commands often... I remember when, more than five years ago, having more than 100 mails made me feel bad and go cleanup. After some vacation, it went up to 150. Then Christmas came along, 300, until I found myself nearing 7000 last summer. Before moving my junk to a demilitarised mailbox, I'm having some fun replying to some email. The first one in my mailbox is from a member of a Catalan "Mallach" family.

From: Conchita Broquetas <familia_mallach_broquetas@yahoo.es>
Subject: Hola!
To: jordi@sindominio.net
Date: Sun, 17 Jun 2001 16:55:17 +0200 (CEST)

who discovered there was a "Jordi Mallach" other than his brother in the Internet. Apparently we had an exchange on where our families came from (Mallach is all but a common surname... anywhere, and my family has always wondered where it came from). So that's more than 6 years ago. I think I'd love to get a reply to some email sent by me years ago which has been sitting for years in a mailbox, because "I need to reply to this sometime". I think the Mallach-Broquetas are getting one tonight. If you think I'm dumping random thoughts on a vim buffer, it's probably due to me feeling sad today. Sorry, but I feel like typing, and I don't have a typewriter with me. Speaking of sad, nothing beats the next email which sat for some dramatic 6 months in my messy inbox until I found out in the worst of the possible scenarios. Let's go back to late February, 2004, when I had no job, and I didn't have a clue on what to do with my life.

From: Mark Shuttleworth <mark@hbd.com>
Subject: New project to discuss
To: Jordi Mallach <jordi@debian.org>
Date: Sun, 29 Feb 2004 18:33:51 +0000
[...]
I'm hiring a team of debian developers to work full time on a new
distribution based on Debian. We're making internationalisation a prime
focus, together with Python and regular release management. I've discussed
it with a number of Debian leaders and they're all very positive about it.
[...]

I'm not sure if I totally missed it as it came in, or I skimmed through it and thought WTF?! Dude on crack or I just forgot I need to reply to this email , but I'd swear it was the former. Not long after, no-name-yet.com popped up, the rumours started spreading around Debian channels. Luckily, I got a job at LliureX two months later, where I worked during the following 2 years, but that's another story. I guess it was July or so when Ubuntu was made public, and Mark and his secret team organised a conference (blog entries [1] [2] [3] [4] [5]), just before the Warty release, and I was invited to it, for the same reasons I got that email. During that conference, probably because Mark sent me some email and I applied a filter to get to it, I found the lost email, and felt like digging a hole to hide for a LONG while. I couldn't believe the incredible opportunity I had missed. I went to Mark and said "hey, you're not going to believe this", and he did look quite surprised about someone being such an idiot. I wonder if I should reply to his email today...