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

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.

Recently it has come up on the LKML and other blogs about how C is not thread safe. The nice piece of example code given is At first glance it seems OK, and I wasn't exactly sure what the problem was until I pulled it apart. GCC is well within its rights to produce the following code (annotated for clarity). This code uses a bit of a trick to avoid a branch around code. It uses the carry flag, which is simple enough to understand when adding. Consider if you are adding 0001 + 1111 you end up with 11111, where the top bit is the carry bit. You can then feed this carry bit into another part of the addition operation if you were, say, using two 32 bit numbers to represent a 64 bit number on a 32 bit system. The trick uses the dual nature of the carry flag as a "borrow" bit; if a < b when a - b then the bit is set. Consider the simplest case of 0 - 1 -- the carry bit is set to indicate to the next operation that a bit needs to be borrowed. Imagine for a moment we have a four bit machine and want to do the 8-bit unsigned operation First we do 0000 - 0001 which leaves us 1111 with the borrow bit set. Then we do 1111 - 0000 but take note that the borrow bit is set, so get rid of the borrowed bit, leaving us 1110. Putting the two together gives us 1110 1111 or 239. Therefore the cmp $0x1, instruction (which is really just result - 1 with no output but setting flags) can only set the carry flag (i.e. borrow a bit) if the value is 0; any other value in result means there will be no need to borrow and the carry flag is not set. Consequently the add with carry (adc) will add one to the result only if the carry bit was set. A neat trick which avoids a jump, but not so much thread safe: if you are interrupted after the cmp but before the mov store you can write back the wrong value. Most people (including me till 5 minutes ago) looking at the code would assume that it was safe on the theory that acquires_count is not touched if you don't have the lock because it is inside the if statement. Interestingly, the Intel compiler does the simpler jump method Frankly I have no idea which one is faster/better (I would guess the second one because you don't always dirty a cache line, but you'd have to measure that against the cost of the branch) but obviously GCC thinks one thing and Intel thinks another and I bet if you put them in a room together you would end up with 3 opinions! I think the major point is that once upon a time it was mostly people writing kernels doing things like accessing I/O ports or other memory mapped areas that needed to be very careful the compiler didn't optimise out (or in) something incorrectly. With multi-threaded C code that problem moves up to the application developer too. A different instruction set can help here. The Itanium version is possibly less prone to this sort of thing because predication makes it faster to implement conditional branches -- any instruction with a predicate that is not set is skipped. The load and add is safe because it will only be done with the lock held. However, if anyone is wondering why Itanium come with such big caches, the difference between the 6 line version and the Itanium version below should answer that. I guess the moral of the story is that multi-threading is hard, but we knew that anyway.

My daughters are perhaps among the first who will grow up seeing much more YouTube than POTV (my newly coined acronym, “Plain Old TV.”) Esther, now 2 , has still never seen anything on a television (recorded, broadcast, or cable). (Havi, a week old today, may not have seen anything at all at this point.) In addition to frequently watching videos from her own blog, Esther loves YouTube. Her most requested videos are embedded below, thanks to the excellent recently-installed Viper’s Video Quicktags. Thus Esther may never know anything but on-demand and user-generated culture. At least those will be her basic assumptions about how it’s supposed to work. It’s possible that this next generation will spell the end of network-scheduled and traditional advertising-interrupted media. I can never understand why anyone would bother to arrange their schedule to watch a show on TV and sit through commercials when they can rent it from Netflix or buy it from Amazon or iTunes and watch it when and how they want — and I grew up, to some extent, with the old TV model. Esther can barely wait for whichever video she wants now. I can’t see her putting up with content on someone else’s schedule as she grows up. Now the videos, as promised (both strong indicators that Esther adheres to the Long Tail theory): Actually, it turns out I didn’t coin POTV. It’s already defined here. Technorati Tags: Culture, Kids, YouTube, UGC

Share This

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 just released new version of Gammu. I expected to have stable release at this time, but some important bugs appeared which forced me to change API. And while I did break this, I also did other API changes which I had longer in my mind. Besides there are lot of fixes in OBEX/IrMC code. Full list of changes:

• Fixes OBEX crash (Debian bug #446923).
• Correctly check various return values (bug #409).
• Fixed several bugs in vCard decoder.
• Removed UCS decoding heuristics, it can not work in all cases.
• Provide at least some basic information from dumb AT phones.
• SMSD now logs also error descriptions.
• SMSD can be configured not to check for security status.
• Correctly handle hard deletes on IrMC (bug #414).
• GSM_ReadConfig now returns GSM_Error instead of just bool.
• Many functions now use size_t for passing size values.
• Backups API now rather accepts format than guessing by filename.
• Increased soname due to API/ABI changes

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.

The talks I proposed for FOSS.in, the major FLOSS conference in India, have been accepted for the Project Days, in the Debian-Ubuntu sessions. Thanks to the event organizers who will sponsor my travel to Bangalore, I'll probably leave as of Sunday Dec. 2nd and attend the entire conference from Dec. 4th to Dec. 8th. During earlier weeks, Sam Hocevar, the Debian Project Leader, also agreed to come to the conference and give two talks there. And, this morning, I had the nice surprise to discover that Lucas Nussbaum, one of our most tireless QA animators in Debian, will also come and give a talk about QA in Debian. So, that should make three French DD attending and, therefore, bring a strong Debian representation in this conference, which is something I definitely find interesting as I invested quite a lot of time and energy last years to increase the Debian presence in South Asia. This will certainly be a great occasion for us to give credit to the few people who contribute to Debian (and related projects) in India, and of course meet them in person. Please check the list of talks to get an idea of talks. Now for the challenge: the organizers expect our slides....by 7 days as of now. I don't know for Sam and Lucas but I have just begun working on one of my two talks (the i18n one, of course...you know: the one with the cute maps....). Would someone have a ready "How to contribute to Debian" talk somewhere? :-)

I have just read Career Development for Geeks [1] by Erik de Castro Lopo [2]. It makes some interesting points about a traditional approach to an IT career. The path I followed for most of my career (after I had a few years experience) was to work as a contractor and happily leave jobs without having anything else lined up. Erik suggests getting Engineers rather than managers to give references, it’s an interesting idea. Engineers can give better references about quality of work, while managers can speak on behalf of their employer (in theory). In practice a sane manager won’t give a bad review for legal reasons so the value of a reference from a manager is probably limited. Of course one problem with reviews is that I have never heard of a recruiting agent or employer actually verifying the ID of a reference. I could be listed on a friend’s CV as a senior manager in a multi-national company (which doesn’t have a major Australian presence) and give a good review and it seems unlikely that the typical recruiter would work it out. For someone with plenty of spare time and no significant assets (no risk of being sued) it could be entertaining to apply for a bunch of positions that they are not qualified for with friends using pre-paid mobile phones to give references. This could be done as a documentary on corporate hiring practices, or to simply try and get the highest paid job possible. Based on observing some former colleagues it seems that little skill is required to get a job and that when people do really badly they get paid for at least a few months. I am constantly amazed when reading reports about so-called “con artists” who commit crimes for what are often small amounts of money. Getting an income significantly greater than average without knowing anything about how to do the work is very common and is never treated as fraud (the classic example was a former colleague who wanted to write his own encryption algorithm but who didn’t even know about binary and therefore couldn’t use operations such as XOR). Erik’s main suggestion for dealing with recruiting agents is to talk about projet management issues (recruiters don’t understand technology). My way of dealing with them has been to assure them that I know it all and tell them to forward my CV to the client. Another suggestion is to learn new skills and diversify your skills. I don’t supoprt this because I believe that the majority of people who read my blog are significantly more skillful than the typical programmer. If an area of technology starts to go out of fashion then it’s the people with the least skills who suffer the most. If you are good at your work and enjoy it then it shouldn’t matter much if people around you are being laid off. Of course to rely on this you have to be working in a reasonably large field. For example if you develop software in a language which has hundreds of programmers then you may be at risk, but if there are tens of thousands of programmers using the language then you only need to be in the most skillful 10% to be assured of employment for the next decade or two. That said there are benefits to moving around, meeting new people, and working on new contracts. One thing you don’t want is to have 10 years of experience which are the same year repeated 10 times! Update: Here is a paper Erik submitted to OSDC on the same topic [3]. Mostly the advice is the same but with more detail and in a better format for reading.

• [1] http://www.mega-nerd.com/Career-dev/career-dev.pdf


• [2] http://www.mega-nerd.com/erikd/Blog


• [3] http://www.mega-nerd.com/erikd/cddg.pdf

Share This

What a week. Most notably, I am still in a state of partial disbelief that my case with Blue Cross Blue Shield is now on a path toward resolution and I don t have do battle with them, or at least in the same vigorous, soul-crushing way I have been engaged in since May (they still have not paid all the bills but at least part of them are resolved). But the very same day that I received the good news about BCBS, I received not so good news from my dermatologist about the black-blue mole that lies right under my left eye. He wants it gone, removed. So my whole fight with BCBS concerned claims over pre-existing conditions related to my moles. My claim was that I never had a problem with them until I had BCBS insurance and that is indeed the case. Soon after I first started having problems, I went on mole patrol and found a suspicious mole on my sister, which turned out to be melanoma. Now whenever I see a dermatologist, they all say, given my family history, given I grew up in the tropics, and given the odd size and very dark color of my mole, that it has to go. In fact the last dermatologist said with the firmest of tones: there is no doubt in my mind that it must be removed. The words stung because, well, I am pretty attached to the mole. I have lived with it for my whole life and it is fundamentally, even if somewhat mysteriously, linked to my sense of self. If it goes, I would feel like a very important part of me would also vanish. On more prosaic grounds, I can t help think that part of the drive to remove such a spot is just part of somewhat unhealthy social trend toward measuring most everything in finer and finder gradations of risk. Given that this mole is on my face and I see my face at least 2x a day in the mirror, I would probably catch anything if it started to change but given our risk society it is unsurprising that every American dermatologist keeps saying it is time to bid adieu to it. Given my background in medical anthropology I can t help conceptualize all this advice within these much larger social trends and then I go back and forth endlessly in my head as to whether I should remove it because it is safe and right and sound or whether I am caving in to somewhat irrational trend toward the risk management of everything. Finally I fear my insurance company again. Though I have a good job and decent insurance, I may not have good enough insurance for what this procedure entails.
Because of the size and location of the mole (large and close to my eye), if removed it must be done by a plastic surgeon. And plastic surgery in the US and plastic surgery in NYC costs a very pretty penny. While I would plan on getting pre-approval for the surgery, I somehow have the feeling that they will not pay the full cost and I am going to be left with another bill. And I am trying to stop the unnecessary onslaught of bills. So should it stay or should it go? I bet that I will lean toward the latter but not without a lot more thoughts, internal cries of resistance, and sense that even if I decide it is the best thing, I will lose a small piece of myself once removed

This blog post is long overdue, but mostly due to spending too much time on Debian Edu (and to little on d-c.org), I haven't got around writing this.

Since about a month an english and a german planet has been set up as part of debian-community.org and is waiting for you to add your feed. Yes, that's right, currently everybody can add any feed. This might change, if/when this is abused, but currently we're still able to operate in good faith :-) Just edit the "list of feeds".

It's also trivial to create planets for other languages, in case you are interested. Just drop by in #debian-community on OFTC and we'll set it up.

And now, back to work, so that I can soon blog about some, as I think, exciting news about Debian Edu.

apt-xapian-index: adaptive quality cutoff I've recently posted:

• an introduction of apt-xapian-index;
• an example of how to query it;
• a way to add simple result filters to the query;
• a way to suggest keywords and tags to use to improve the query.
• a way to search for similar packages.

Note that I've rewritten all the old posts to only show the main code snippets: if you were put off by the large lumps of code, you may want to give it another go. Today I'll show how to implement an adaptive cutoff to get rid of the worse results. Recall that Xapian shows results by decreasing order of quality, and as we pull more an more results out, we reach a point where the matches are so approximated that they look random. This can be a problem if we want to change the order of the result, for example we may want to sort by package size, or by popcon popularity. There are many scenarios in which a really bad match could end up at the top of the results. For most cases, you just want to say "discard all results whose quality is less than 70%". But sometimes you have queries that OR lots of terms, and even your top result, while still being a very good result, may be below the cutoff you decided. Implementing an adaptive cutoff is extremely simple: first, you get the quality estimate of the top result: Then you tell Xapian that you want a cutoff value that is, for example, 70% of that: Finally, you repeat the query. If you want, you can go for bigger result sets, as the cutoff will make it so that if you have lots of results, they will very likely be all good results: This is it. You can use the wsvn interface to get to the full source code and the module it uses. Next in the series: smart way of querying tags.

Linux-hero wrote about how Ubuntu kills your hard drive. The situation is somewhat less clear than you might think from the article, but the basic takeaway message is that Ubuntu doesn't touch your hard drive power management settings by default. In almost all cases, it's more likely to be your BIOS or the firmware on your hard drive.

The script that's executed when you plug or unplug your laptop is /etc/acpi/power.sh. The relevant sections are:

function laptop_mode_enable  
...
    $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
    $HDPARM -B 1 /dev/$drive 2>/dev/null
 

That is, when the laptop_mode_enable function is called, we set the drive power parameters. Now, by default laptop_mode_enable isn't called:

if [ x$ENABLE_LAPTOP_MODE = xtrue ]; then
    (sleep 5 && laptop_mode_enable)&
fi

because ENABLE_LAPTOP_MODE is false in the default install (check /etc/default/acpi-support). This means that, by default, we do not alter the hard drive power settings. In other words, the APM settings that your drive is using in Ubuntu are the ones that your BIOS programmed into it when the computer started. This is supported by the fact that people see this issue after resuming from suspend. We don't touch the hard drive settings at that point, so the only way it can occur is if your BIOS or drive default to this behaviour.

If you enable laptop mode, then we will enable aggressive power management on the drive and that may lead to some reduction in hard drive lifespan. That's a fairly inevitable consequence of laptop mode, since it only makes sense if the laptop enages in aggressive power management. But, as I said, that's not the default behaviour of Ubuntu.

There's certainly an argument that we should work around BIOSes, but in general our assumption has been that your hardware manufacturer has a better idea what your computer is capable of than we do. If a laptop manufacturer configures your drive to save power at the cost of life expectancy, then that's probably something you should ask your laptop manufacturer about.

A while back I posted about a couple of my irritations with GNU Screen. One of my irritations was the failure to reattach to sessions by name, if common prefixes were in use. For example with the following two (detached) sessions:

There are screens on:
        24419.abc       (Detached)
        24395.abcd      (Detached)
2 Sockets in /var/run/screen/S-skx.

The naive "screen -R abc" fails. Yesterday whilst looking over the screen bug list I came up with a patch. It isn't ideal as it introduces a new failure case, but I believe it is a step in the right direction and better than the current situation. See attachment to #361274 for the code. Also I patched screen so that #330036 is now fixed, and the blankerprg primitive works as expected. Finally I closed #317450 (with a version) as it has been fixed since Etch. Fun stuff. In the spirit of completeness I should say I had a stab at #447210 which is tilde (~) expansion in the chdir primitive, but gave up after a while as the code got too messy even for me. The trivial s/~/getenv("HOME")/ approach works fine for the simple case, but dealing with the expansion of strings such as ~foo/bar/ gets messy quickly. I can offer my patch if there is any interest though as a stop-gap measure. Now I'm almost tempted to look over another package's bugs, but I think I'd rather eat pie & drink beer... must. stop. talking. about. pies. Update: Patch for tilde expansion submitted to #447210 - tested and seemed to cover all cases. Now time for beer!

I recently sponsored several uploads, and was asked to sponsor even more uploads, and that got me thinking about our sponsorship workflow. It’s a clear bottleneck in Debian, and discourages many new contributors, which obviously sucks. It’s important to note that the same problems exist in Ubuntu (their equivalent to mentors.debian.net is named REVU). The best way to improve the process would be to have packages of better quality when a DD first look at them. They would be more likely to be uploaded right away, which frees time for other packages. I think that there’s a lot of room for improvement in the current mentors.debian.net implementation. Here is a small list of features I would like to see.

• Integration of some QA tests in mentors, as soon as the package is uploaded:
  • does the package build cleanly?
  • piuparts test?
  • lintian/linda checks?
• Better list of packages awaiting sponsors, with info including:
  • does the package fixes bugs (number of bugs fixed per severity)?
  • is that package already in Debian?
  • is that package a new upstream version?
  • popcon score
  • how long has the package been waiting?
  This would allow potential sponsors to prioritize requests.
• A commenting system, for each package, so comments for rejected packages are not lost, and the next potential sponsor can double-check
• A way for sponsors to mark some sponsorees as “friends”, so it’s easy to find all the requests from people I “trust” (for some definitions of “trust” ;)
• Maybe, a scoring system, where providing good comments on other’s packages would make you win “karma points”, and improve your classification, which could later be used by sponsors to choose what they are going to sponsor next.

The good thing with this whole list of features is that everybody can help. So, if you are looking for a sponsor and want to help solve this problem, start coding now ;) And if you need me to create nicenameforyourservice.debian.net, just ping me. There’s probably some code to steal from svnbuildstat.debian.net, so contacting its developers would be a good idea.

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 recently ranted about Ubuntu not giving much credit to Debian. I have to complete this by thanking the Merge-o-Matic feature which (for a few months now) sends to package maintainers a diff file with the Debian package when a new Ubuntu package is uploaded. This sometimes make it quite easy to spot modifications done by Ubuntu and eventually adopt them. This already bringed me, as maintainer, a few interesting patches for iso-codes, console-data and geneweb. In the case of iso-codes, samba and geneweb, the Ubuntu patch was even reported manually as a Debian bug by a Ubuntu contributor/developer (no later than today, Martin Pitt took care to suggest us to adopt bzip2 compression for iso-codes and Mathias Gug proposed a patch to enable usershares in samba). So, well, even if things can still be improved, many Good collaboration also often happens.

You know the problem? Something happens, and all your systems go down—scheduled or otherwise. When you boot them up, one box is faster than the other; and as a result, some network mounts don't really work correctly. While this doesn't really happen at work, I've seen it after a power failure at home. I thought this was a feature that Windows had but Linux doesn't. I really should've known better...

wouter@country:~$ mount
/dev/hda5 on / type ext3 (rw,errors=remount-ro,commit=0)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)

(...)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
automount(pid15173) on /autofs type autofs (rw,fd=5,pgrp=15173,minproto=2,maxproto=4)
wouter@country:~$ ls /mnt/stuff

(lots of private data snipped...)

wouter@country:~$ mount
/dev/hda5 on / type ext3 (rw,errors=remount-ro,commit=0)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)

(...)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
automount(pid15173) on /autofs type autofs (rw,fd=5,pgrp=15173,minproto=2,maxproto=4)
goa:/stuff on /autofs/stuff type nfs (rw,addr=192.168.119.23)

And after I wait a minute, that last line is gone. Automounters are cool. And not too hard to set up, either, if only a bit confusing at first. My /etc/auto.master contains the following (not counting commented-out examples):

/autofs	/etc/auto.autofs --timeout=60

I then need to have a directory /autofs, on which the automounter mounts a special filesystem if it's started; this is the "automount" in the above mount output. The autofs needs a second automounter map, which looks like this in my case:

cdrom	-fstype=iso9660,ro,nosuid,nodev	:/dev/cdrom
stuff	-fstype=nfs			goa:/stuff
camerab	-fstype=vfat,ro,umask=133,dmask=22 :/dev/disk/by-id/usb-GENERIC_USB_Storage-SDC_200606191719424ND-0:1-part1
floppy	-fstype=auto			:/dev/disk/by-id/usb-Y-E_DATA_USB_Floppy_Drive

Occasionally, yes, from the above lines it can be inferred that this indeed also works for my USB floppy drive, my multicardreader, and my CD-ROM drive. Finally, I need a symlink into the automount filesystem, like so:

wouter@country:~$ ls -l /mnt/stuff
lrwxrwxrwx 1 root root 13 2007-10-23 19:21 /mnt/stuff -> /autofs/stuff

et voila: if I now try to access anything below /autofs/stuff, the automounter kicks in, transparently mounts the filesystem, and without any further delay or ado, I can get at my files. Well—unless the server is down, that is.

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.