In addition to my last post, here some information about the current number of release critical bugs. Yes, it is true, that our official bug tracker lists the next release has still 264 bugs¹. And some wonder, when Lenny will be released. It's a little bit difficult to work with that page, let's look at the unofficial rc bug thingy I already mentioned in my previous post. As you might have noticed it supports several filters mechanism the official bts don't have. At the very bottom of the detailed list you'll see the overall number of the bugs matching your selected filter. So let's have a look at the number of bugs, which are already fixed in the unstable branch and need to propagate to Lenny. Currently that are 118 RC bugs. Of those 264 preventing us to release, 118 are already fixed; the fix just hasn't arrived in Lenny, yet. Okay, but there are still 147 rc Bugs open in both Lenny and Sid. So let's take a look at them. By using the filters at the top, you can calculate, that 19 already have a patch. 14 are marked pending (so they are already fixed, but the maintainer hasn't uploaded the package yet). 15 of these bugs have been reported multiple times and have been merged. Oh, and 3 are about packages in non-free and contrib. Granted, for some of them, there is a patch, but the patch needs to be tested, or the bug has been marked pending by mistake. But still: If you ignore all these types of bugs, there are only 104 bugs left. one-hundred-and-four! Summary: So the only thing left (beside the points I mention in my previous post) to do, is to migrate 118 fixes to Lenny somehow, get the 33 fixes for the probably fixed bugs uploaded, and fix the remaining 104 bugs. Yes, that's still a lot of work to do... So let's get things rolling, shall we? 1: You might further notice, that the current stable release is affected by more than 700 bugs. However many of them are false counts, e.g. when a specific package doesn't build with a newer version of a compiler. The package in the current stable release is of course affected, so there it is kind of buggy. However, we can ignore these kind of bugs, since the newer version of the compiler isn't shipped in the current stable release at all. Those bugs should actually be tagged sid and lenny...

You probably noticed by now, that Debian GNU/Linux 5.0 aka Lenny hasn't been released in September. Well, that's a shame, but very easy to explain: Too many release critical bugs. Well, it's pretty hard to estimate, how fast RC bugs will be fixed, and apparently our release team was a bit too optimistic :( The big question is: What can you do, to help release Lenny at least in this quarter? That's pretty easy: Fix rc-bugs, take care, that the fixed packages are migrated to Lenny, do upgrade tests, document problems in the release-notes. Pretty simple, isn't it? For users Even as a simple user (aren't we all just users?) you may help getting Lenny released. Some things you can do:

• If you are running stable (aka Etch), you could consider upgrading to Lenny and see, if everything works fine. Currently there are no detailed release notes documenting the procedure, so you best way to test upgrades are to:
  1. Make backups
  2. Change your /etc/apt/sources.list
  3. Run aptitude update to get information about new packages
  4. Run aptitude install dpkg aptitude apt script to install the newest package management
  5. Run script aptitude full-upgrade
  6. Exit the environment of the script command, by typing exit
  If something goes wrong / something unexpected happens, please report it. If you already know a specific package, report a bug against that package. If you don't know, please report a bug describing the problem you experienced to the upgrade-reports package. If your problem is something, which can't be fixed properly, but should be documented (e.g. hardware support regressions, packages no longer available) please report a bug against the release-notes package (Bonus points if you not only report the bug, but also supply a paragraph to be added to the release notes).
  The command script will log the entire output of the command in the file typescript. Should something go wrong during the upgrade, please send this file along with your bug report.
  Update: If you upgraded succesfully, you should report that, too. There's a template for upgrade reports, which you can use.
• Speaking of the release notes: You can take a look at the bugs reported against the release notes and see if you can help there, e.g. by writing a paragraph describing a problem.
• Install the package devscripts (you'll need the version provided by backports.org, and run the script rc-alert --include-dists TU --include-dist-op and. You'll get a list of release critical bugs open for one of the packages you have installed. Guessing that you have them installed, because you are using them and are interested in them, you should have a very high interest to get these bugs fixed :)
  You can try to help, by trying to reproduce them and reporting that to the bug report. There are even some easy bugs, where the maintainer hasn't found the time to fix it, yet. Bug 497290 for example didn't need deep technical skills. It just needed someone with some time to collect the needed data for the copyright file.
• If you speak a language other than English, you might consider joining the translation efforts. While it is to late to translate the debian-installer or the installation guide to a new language for Lenny (perhaps for the next release then?), you could start translating the release notes to a not yet supported language. If you are willing to do so (which can be quite time consuming, especially in the final phase), please contact either your localization team or the debian doc mailing list if there's no local mailing list.

See? Even as a simple user without deeper technical knowledge you can help us getting Lenny in shape to be released. If you have technical knowledge: Very good! You might want to read the next section, too, and see what applies to you, there :) For maintainers It basically boils down to two things: If your packages have RC bugs open in Lenny fix them and take care, that the fix will propagate to Lenny. If your packages don't have RC bugs open, fix someone else's RC bug. Surely you don't think, the release team will fix the remaining rc bugs, do you? And surely you understand, that your shiny rc bug free packages are kind of useless, if they aren't released? To search for bugs to be fixed, take a look at the unofficial rc bugs thingy. The URL lists RC bugs open in both Sid and Lenny. Obviously they should be fixed ASAP. If no one takes care about these packages, they might be removed from Lenny (if possible). Again: Try to reproduce the bug, try fix it, upload an NMU (or send your patch to the bug report and search for an sponsor). You'll notice, that some of these bugs already have a patch. In that case, your job would be to test the patch, report that to the bug report and offer to sponsor an NMU. Another interesting list is the list of rc bugs open only in Lenny. These bugs have been fixed, but the fix hasn't propagated to Lenny, yet. Normally, the release team will grant freeze exceptions for these packages if possible. However, if the changes to the fixed version are quite grave or the package in Sid depends on a newer package than in Lenny that's not possible. In these cases look out for packages marked as need tpu upload or similar. Oh, and if you could refrain from upload new upstream versions of packages to Sid, you would make all our lives easier. Some reasons:

• New packages won't reach Lenny anyway.
• Upload new packages to Sid makes it harder to get a fix into Lenny should a new bug be found.
• Uploading a new package makes it harder for other packages depending on your package to be migrated to Lenny.
• You are wasting the buildd's time.

And of course you should spend your time fixing rc bugs anyway ;) Update: Rhonda pointed out, that running rc-alert -d TU -o and will limit the output to bugs open in both Sid and Lenny, which is the more interesting list of bugs.

It’s really funny to see how popular things can get, and then totally disappear. Some time ago, there was a TV show on the french TV called “Un an de +”, that talked about what was in the news one year before. It was really interesting to see how quickly everybody can forget stuff that looks so important now. For example, who remembers Second Life? Apparently, it has been on the decline for some time already, according to Google Trends:
Will Facebook be the next Second Life?

Today, an article at heise online claimed, that Lenny is supposed to ship this year, quoting Alexander’s blog entry. While I can’t find a single word in Alexander’s article claiming that we’ll release this year, I’m pretty sorry that just after we failed the first deadline which was obviously too “optimistic”, we get another one which is too short. Two month’s ago I created a pretty simple estimation regarding Lenny’s release by looking at the rc-bugfix-rate of the last two releases and applying them to the current number of rc-bugs. As a result it looked more likely that we release Lenny in June 2009 than in September 2008. Until now, my guess for Lenny’s release still holds, at least the updated rc-graph lies perfectly on the line I’ve created two months ago. While I wish that we’ll release Lenny as soon as possible, I hope that someone will clarify the proposed release date to the media and this time with a more defensive deadline. Some people might actually trust our estimation (I know this sounds silly). And even if everyone knows that Debian notoriously releases too late — we could at least try to propose more realistic dates and update them regularly. Just two weeks ago I still read and heard in the media that Debian will release Lenny in September although it was clear at this point that this is impossible.

With all the effort being poured into Javascript lately, it's pretty evident that that's the way forward. However, there are still some neat things you can do with applets that you can't do with Javascript. For instance, I use the microemulator applet to let people play with a simulated phone on the Hecl web site. Unfortunately, the user experience hasn't that good. While playing around with the code for that site, Firefox crashed a number of times, and I've heard other browsers have trouble as well. No fun. So it is with some satisfaction that I found this: https://jdk6.dev.java.net/plugin2/ It's an updated Java plugin that seems to work much, much better than the old one. Unfortunately it doesn't appear as if it will be in the new Ubuntu, as it was released recently, but I'm quite happy to have something a bit more stable to develop with. You can download that version of the Java SDK or JRE here: http://download.java.net/jdk6/ It's good to see this effort, even if it may be a bit late.

Data ordered by entry data is not a data file, and thus not protected by the law regarding personal data files, because it’s hard to do searches in them. I know it sounds ridiculous, but that’s the argument that the highest court in Spain (Tribunal Supremo) has used to prevent the Catholic Church from losing believers. Many children are automatically baptisted by their parents when they’re just babies, without having any decision in that, and thus they names are written down in the Church files^Wlists of baptisted people. That’s the numbers they will use later when asking for privileges for the Catholic Church, and that’s why it’s so important for them that all of us are counted as catholics, whether we are or not believers. Fewer than half of Spanish youth consider themselves Catholic, so it’s important for them to keep appearances to keep their power intact. In Spain thousands of non believers are demanding that the Church cancel their baptism records, in order to annul any official connection with Catholicism. And church leaders in turn have gone to the courts to try to stop parishioners deserting. The Tribunal Supremo seems to be taking a political side with their decision trying to vulnerate non-believers rights to artificially promote the Catholic Church. Apostasy is the formal religious disaffiliation or abandonment or renunciation of one’s religion. The United Nations Commission on Human Rights, considers the recanting of a person’s religion a human right legally protected by the International Covenant on Civil and Political Rights: “The Committee observes that the freedom to ‘have or to adopt’ a religion or belief necessarily entails the freedom to choose a religion or belief, including the right to replace ones current religion or belief with another or to adopt atheistic views […] Article 18.2 bars coercion that would impair the right to have or adopt a religion or belief, including the use of threat of physical force or penal sanctions to compel believers or non-believers to adhere to their religious beliefs and congregations, to recant their religion or belief or to convert.”. Anyway, many religious groups and even some states punish apostates. For Catholics, the word “apostasy” signifies the desertion of faith, which had been one of the three unpardonable sins in the early years of the Church. AEPD, the national agency for data protection, is pondering now whether to appeal against the sentence. I hope they do. There are other legitimate subjects that could appeal against it, too. No one should be forced to belong to a Church they don’t believe in.

It's really quite strange to come across a tool that is incredibly useful, does exactly what I need but of which I was completely unaware. This time it is manpages.debian.net - how long has this been around and why hasn't it been announced somewhere?
The best part is that if a manpage uses a See also section, the references to other manpages get turned into HTML links to the relevant manpage on the site.
Getting a manpage is now as simple as:

http://manpages.debian.net/cgi-bin/man.cgi?query=%s

which makes it trivial to put this onto the epiphany smart bookmark toolbar.
The site supports:

• keyword search via apropos,
• showing manpages from each distribution, default is Sid
• rendering manpages in other formats like PDF
• translated manpages, if the translation exists.
• manpages via section

Thanks to Patrick Schoenfeld for inadvertently leading me to the site - I couldn't find who created the site so step up and be known.
Update
To those making comments on this entry, please note:
I have nothing directly to do with the site, I just found it and blogged about it so don't use my blog as a bug list. Ta. Such comments have been deleted and further comments are now disabled for this entry.

A recent news item is the “hacking” of the Yahoo mailbox used by Sarah Palin (the Republican VP candidate) [1]. It seems most likely that it was a simple social-engineering attack on the password reset process of Yahoo (although we are unlikely to learn the details unless the case comes to trial). The email address in question had been used for some time to avoid government data-retention legislation but had only been “hacked” after she was listed as the VP candidate. The reason of course is that most people don’t care much about who is the governor of one of the least populous US states. Remote attack on a mailbox (which is what we presume happened) is only one possible problem. Another of course is that of the integrity of the staff at the ISP. While I know nothing about what happens inside Yahoo, I have observed instances of unethical actions by employees at some ISPs where I have previously worked, I have no doubt that such people would have read the email of a VP candidate without any thought if they had sufficient access to do so. If an ISP stores unencrypted passwords then the way things usually work is that the helpdesk people are granted read access to the password data so that they can login to customer accounts to reproduce problems - this is a benefit for the customers in terms of convenience. But that also means that they can read the email of any customer at any time. I believe that my account on Gmail (the only webmail service I use) is relatively safe. I’m sure that there are a huge number of people who are more important than me who use Gmail. But if I was ever considered to have a reasonable chance of becoming Prime Minister then I would avoid using a Gmail account as a precaution. There is a rumoured Chinese proverb and curse in three parts:
May you live in interesting times
May you come to the attention of those in authority
May you find what you are looking for [2] In terms of your email, everyone who has root access to the machine which stores it (which includes employees of the companies that provide warranty service to all the hardware in the server room) and every help-desk person who can login to your account to diagnose problems is in a position of authority. Being merely one of thousands of customers (or millions of customers for a larger service) is a measure of safety. As for the “interesting times” issue, the Republican party is trying to keep the issue focussed on the wars instead of on the economy. The problem with basing a campaign on wars is that many people will come to the conclusion that the election is not about people merely losing some money, but people dying. This could be sufficient to convince people that the right thing to do is not to abide by the usual standards for ethical behavior when dealing with private data, but to instead try and find something that can be used to affect the result of an election. Mail that is not encrypted (most mail isn’t) and which is not transferred with TLS (so few mail servers support TLS that it hardly seems worth the effort of implementing it) can be intercepted at many locations (the sending system and routers are two options). But the receiving system is the easiest location. A big advantage for a hostile party in getting mail from the receiving system is that it can be polled quickly (an external attacker could use an open wireless access-point and move on long before anyone could catch them) and that if it is polled from inside the company that runs the mail server there is almost never any useful audit trail (if a sysadmin logs in to a server 10 times a day for real work reasons, and 11th login to copy some files will not be noticed). One of the problems with leaks of secret data is that it is often impossible to know whether they have happened. While there is public evidence of one attack on Sarah Palin’s Yahoo account, there is no evidence that it was the first attack. If someone had obtained the password (through an insider in Yahoo, or through a compromised client machine) then they could have been copying all the mail for months without being noticed. It seems to me that your choice of ISP needs to be partly determined by how many hostile parties will want to access your mail and what resources they may be prepared to devote to it. For a significant political candidate using a government email address seems like the best option, with the alternative being to use a server owned and run by the political party in question, if you can have the staff fired for leaking your mail then your email will be a lot safer!

• [1] http://gawker.com/5051193/sarah-palins-personal-email-account-hacked


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

Share This

Things:

• I'll be speaking at the UKUUG Linux conference in Manchester this November.
• The ACM have chosen my article on power management from Queue last year as a shining example of such things, and republished it in Communications where you may now peruse it at your leisure. Fanmail may be sent to the usual addresses.
• I'll be in Boston from the 7th to 11th of December, and New York from the 11th to 15th. I will be endeavouring not to break any bones in the process. Might actually ensure I have travel insurance this time.
• I'll be presenting at LCA next January. Current plans involve spending a week in Melbourne afterwards and a few days in San Francisco on the way back.

Things I want to do:

• Visit Iceland. It sounds like it might be relatively cheap soon.
• Make this I C code work.
• Get dynamic power state switching on ATOM-based Radeons working. This probably involves actually plugging the card in.

One ongoing problem with TCP networking is the combination of RPC services and port based services on the same host. If you have an RPC service that uses a port less than 1024 then typically it will start at 1023 and try lower ports until it finds one that works. A problem that I have had in the past is that an RPC service used port 631 and I then couldn’t start CUPS (which uses that port). A similar problem can arise in a more insidious manner if you have strange networking devices such as a BMC [1] which uses the same IP address as the host and just snarfs connections for itself (as documented by pantz.org [2]), this means that according to the OS the port in question is not in use, but connections to that port will go to the hardware BMC and the OS won’t see them. Another solution is to give a SE Linux security context to the port which prevents the RPC service from binding to it. RPC applications seem to be happy to make as many bind attempts as necessary to get an available port (thousands of attempts if necessary) so reserving a few ports is not going to cause any problems. As far as I recall my problems with CUPS and RPC services was a motivating factor in some of my early work on writing SE Linux policy to restrict port access. Of course the best thing to do is to assign IP addresses for IPMI that are different from the OS IP addresses. This is easy to do and merely requires an extra IP address for each port. As a typical server will have two Ethernet ports on the baseboard (one for the front-end network and one for the private network) that means an extra two IP addresses (you want to use both interfaces for redundancy in case the problem which cripples a server is related to one of the Ethernet ports). But for people who don’t have spare IP addresses, SE Linux port labeling could really help.

• [1] http://en.wikipedia.org/wiki/Baseboard_management_controller


• [2] http://www.pantz.org/hardware/ipmi/ipmiconflictwithrpc.html

Share This

Apologies to anyone bored of this topic but it is something I have been thinking about recently. You have people commenting on why Banks are special and need government funded bailouts. Others arguing that the Free market is not dead. We have even have a few solutions from some people within the Free Software community. I think the first thing is to identify who should lose, and who should win.

• Investors should lose.
• Customers should win.

Much of the annoyance about the rescue from ordinary people is that it seems that investors are not losing (enough). They took some risks, those gambles failed, and now everyone else is paying the price. If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff -- another word for investors -- would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?. So let's apply the same set of outcomes to banks.

• Borrowers would win, since they are living in a mortgaged house.
• Investors lose, since no one will buy their shares (no matter how cheap they are)
• Tax payers win, since they are not rescuing a particular industry sector

But hang on, you rightly ask, - a bank has the title deed (a mortgage is a promise to pay amount X over Y year in return for the deed) - why would customers (depositors), realising a bank is no longer viable, since remove their funds I think that those two issues can be addressed fairly simply. The government would guarantee all depositors money. Customers never lose. They never have to worry about their funds. For banks, who enter into administration, the standard laws about possession should apply. If a borrower is utilising (living in) the asset to which the bank has title for over Z years (where Z equals 5 or 7), then the possesor now owns it outright. That is plenty of time for a bank to either be bought, have the underlying asset value recalibrated, or to completely go bust. All without a detrimental effect.

It is nice to see someone apologising for their planned failure to consider Linux users. It's ridiculous that they even have to. It seems to me that these people have spent way too much effort on making the logo and menus scroll in from the left and right of the screen, and not enought effort on the actual functionality of their website. I fail to understand what benefit they have gained from using the Pizza UI for their logo & menus (yes, really) rather than using simple links - or CSS-based menus, if they needed fancy. The page layout doesn't actually need anything more than simple text links. The logo (thankfully) does nothing after it's page-load scroll. For extra 'fail' marks they substitute graphics when I initially arrive with Javascript disabled (and wearing my tinfoil hat) but the graphics give me the appearance of a menu without actually performing a useful function. The user-interface situation gets worse later, when I am taken through five successive screens to upload and classify some new media. It seems that in order to bore people who are foolishly trying to upload their home movies over "poorband" they attempt to display a progress bar. A better approach would be to ask me all of the questions about the media I am uploading on one single page and let me get on with something useful. This might be news, but it seems that such an interface could be done in plain HTML, and wouldn't actually require me to enable javascript for a site which is riddled with cross-site scripting flaws. Since it's the school holidays at the moment we took advantage of Te Papa's excellent institution of "Late Night Thursday" last week and visited the other end of the website in person. My disappointment in the website was then entirely eclipsed by my disappointment in the real-life part of the exhibit. The "walk on the map and see photos of the area" component was decidedly clunky, with no clear feedback between stepping on a tile and media appearing on the wall In fact it seems most tiles don't actually do anything, and there are only a few small screens in the walls to display the images. The "postcards blowing in the wind" gimmick amused the kids for about 20 seconds, tops. The 'wall' was quite a lot more successful, amusing me and the kids for nearly half an hour, though we're unlikely to go back next time we're there. There were plenty of annoyances also, in particular that it doesn't appear to use the full resolution of uploaded photos, the interface is slow and it is difficult to see what you are doing at times. It's good that they've started practising their apologies, firstly targeting the small (but geeky :-) segment of New Zealanders who are Linux users trying to help them out by providing them with free content. Now I am looking forward to their further apologies to larger groups of justifiably annoyed people, culminating with the ultimate one, where they apologise to all of the taxpayers of New Zealand who funded this incredible waste of money. I can imagine that something interesting could be done with a lot of media of New Zealand and now that Te Papa has started to amass a collection in this way, perhaps they will.

It is nice to see someone apologising for their planned failure to consider Linux users. It's ridiculous that they even have to. It seems to me that these people have spent way too much effort on making the logo and menus scroll in from the left and right of the screen, and not enought effort on the actual functionality of their website. I fail to understand what benefit they have gained from using the Pizza UI for their logo & menus (yes, really) rather than using simple links - or CSS-based menus, if they needed fancy. The page layout doesn't actually need anything more than simple text links. The logo (thankfully) does nothing after it's page-load scroll. For extra 'fail' marks they substitute graphics when I initially arrive with Javascript disabled (and wearing my tinfoil hat) but the graphics give me the appearance of a menu without actually performing a useful function. The user-interface situation gets worse later, when I am taken through five successive screens to upload and classify some new media. It seems that in order to bore people who are foolishly trying to upload their home movies over "poorband" they attempt to display a progress bar. A better approach would be to ask me all of the questions about the media I am uploading on one single page and let me get on with something useful. This might be news, but it seems that such an interface could be done in plain HTML, and wouldn't actually require me to enable javascript for a site which is riddled with cross-site scripting flaws. Since it's the school holidays at the moment we took advantage of Te Papa's excellent institution of "Late Night Thursday" last week and visited the other end of the website in person. My disappointment in the website was then entirely eclipsed by my disappointment in the real-life part of the exhibit. The "walk on the map and see photos of the area" component was decidedly clunky, with no clear feedback between stepping on a tile and media appearing on the wall In fact it seems most tiles don't actually do anything, and there are only a few small screens in the walls to display the images. The "postcards blowing in the wind" gimmick amused the kids for about 20 seconds, tops. The 'wall' was quite a lot more successful, amusing me and the kids for nearly half an hour, though we're unlikely to go back next time we're there. There were plenty of annoyances also, in particular that it doesn't appear to use the full resolution of uploaded photos, the interface is slow and it is difficult to see what you are doing at times. It's good that they've started practising their apologies, firstly targeting the small (but geeky :-) segment of New Zealanders who are Linux users trying to help them out by providing them with free content. Now I am looking forward to their further apologies to larger groups of justifiably annoyed people, culminating with the ultimate one, where they apologise to all of the taxpayers of New Zealand who funded this incredible waste of money. I can imagine that something interesting could be done with a lot of media of New Zealand and now that Te Papa has started to amass a collection in this way, perhaps they will.

I just got back from the OpEd project/workshop. In short, it was worth every penny and if you are interested in writing an OpEp and riding the public debate bandwagon, this is the perfect place to start. Why? Well, first because the world of punditry and debate needs more diversity and women and this project is fundamentally geared toward getting more women into the system and in a no nonsense, accessible, inspiring, and yet utterly pragmatic fashion. First, if you don’t know the stats concerning women, they are depressingly dismal. For example, 9 out of 10 submissions are from male writers and 88% of published pieces are from male authors (and this is matched by all sorts of other disturbing figures about the lack of women non-fiction writers, TV producers etc). In the OpEd field, the main problem, in short, is that women are not even trying. Today’s full-day workshop was enlivening and engaging. Catherine Orenstein, the founder and dynamic leader of the project, dusts away a lot of the mystery of this writing genre and equips participants with some basic skills and tactics to get you started (then, in my opinion, it takes a fair bit of work and persistence to master, just like any type of writing but it is not rocket science either). What I like most about the project is its utter pragmatism. Cathy knows that once there are enough women in the system, the project can close shop, for it will be other women who will take over the reigns and inspire other women to write them (and informally mentor them as well). It is well known, for example, that once there is a critical mass of women, let’s say in the work place, then these women are the point people for recruitment so that the company does not need to actively recruit women. I have heard this argument before and have had a number of personal experiences that confirmed this fact. Last year, for example, a student from my department was organizing a conference and he could not, for the life of him, find any female speakers or discussants, despite asking a number of them who declined because of other commitments. He had ran out of options, that is, until he talked to me. In less than a minute, I rattled off like 5-7 other possible choices and within a day, we had 2 on board. It is clear that women know other women (and many are friends) so the best person to go to to tap into are other women. In terms of the actual writing of an OpEd, I am not sure I will be writing one anytime soon in so far as I need to really pump out a few more academic articles as the future of my jobs depends on them. But I may write a draft version of one that I will hammer into finer shape if a timely news event arises. Otherwise, I look forward to spending more time on this genre, especially once my book is done and know that if I am going to stay in academia, I will for sure make space for this type of thinking and writing. Finally if you are interested in attending one of the public, women-only seminars and you know me, let them know you learned about the project through me, and you will get discount.

Some time back, I wrote up our current best practices in the Stanford central UNIX support group for managing Debian servers, and some time before that, I wrote up some notes on useful Debian package build tools. Both of those pages had become hopelessly out of date. Over the past week, I've been revising them, and they should now reflect reality somewhat better. Notable in the changes to the build tools document is a switch from debarchiver to reprepro. I haven't finished doing that migration for my personal repository, but I'm most of the way through and hope to be able to pull the trigger fairly soon. I like debarchiver and have used it for years, but reprepro supports a pool structure and package migration between distributions, both of which are killer features. We're going to be switching to reprepro for Stanford's internal archives as well, although probably not until sometime in November or December. I also moved the documentation I had for packaging individual scripts into a separate document and updated it to reflect the fact I use Git now instead of Subversion. Most of the details here are fairly straightforward and obvious, but I find it useful to read through something like this and see how someone else approaches a problem. Maybe someone else will find bits of it useful.

While incorporating some of the podlators fixes into the Perl that will be released with lenny, Niko Tyni found more problems with the current implementation. I'd written the test suite to force the output encoding on the file handle used by Pod::Man and Pod::Text, but pod2man and pod2text weren't doing that, and hence the output wasn't properly encoded. I'm finding Perl's Unicode support very tricky, particularly if I want to support the PERL_UNICODE option that adds input and output encodings on all file handles. I can't use encode before output because PERL_UNICODE encoding layers will then double-encode. The approach taken in this release is to force the appropriate output encoding on the output file handle (possibly destroying caller state). This works, but it's ugly. Pod::Text had another problem. Its historic behavior is to copy the input encoding to the output, but doing that with properly-tagged UTF-8 POD input means printing out wide characters in the internal encoding, resulting in Perl warnings. This version now, in the absence of the utf8 option, forces the output encoding to match the input encoding if possible. This seems like the best compromise and matches its historic behavior. pod2text now supports a --utf8 option since it's now useful to force a different output encoding. I wanted to get something out to stop the bleeding, but there are a few problems with the current approach. As mentioned above, I'm forcing file handle encoding layers, which may destroy encoding layers created by the caller that were intentional. This implementation also depends on PerlIO support, which is an optional Perl feature and not always enabled. I think the right long-term approach is to probe for PerlIO support, and if present, use it to check the encoding layer on the output file handle. If PerlIO is not set, or if no encoding layer is present, I can safely use encode before output, which doesn't mess with the file handle state and is much cleaner. If PerlIO is present and an output encoding is set, just trust that output encoding (although if the utf8 option is set and the output encoding is something else, it may be a good idea to throw a warning). I'm not sure when I'll have time to implement this, though, since it will require another reworking of the code and more testing, and I'm behind on a number of other projects. In any event, the current version will work for most people in most cases. You can get it from the podlators distribution page.

I received some feedback on my previous BeID post, where I explained how to log in to a remote system by use of your digital ID card. Philip and Guy both claim it possible or likely that the crypto keys on eID cards are stored on a system of the government somewhere and that you therefore should not be using them. I find this to be jumping the gun a little. Security is always a trade-off; indeed, if you want to hide stuff from the government, then using eID-based authentication might not be a very good idea. However, there are other cases where eID-based authentication really is the correct option; and it is nice to know that this kind of thing is possible. Security always is a trade-off; and if you make an informed choice, there's nothing wrong about giving someone else access to your server. The fun bit is that Philip actually advocates carrying a clear-text printout of a list of still-valid passwords. Now that, I feel, is unacceptable, security-wise. Personally, I'd rather use a smartcard that only some secret government agency might be keeping copies of rather than a list that any random thief might make use of. The question really boils down to this, I think: how likely do you think it is that someone else will be able to get at your password by guessing or stealing it?

• Using a password that's related to your person or someone near you, or is based on a dictionary: rather likely. There are scripts out there that will guess these passwords. Don't use them.
• Using a printout of a list of one-time passwords: somewhat less likely (they can't be guessed by script), but still not very hard (wallets get stolen by the hundreds every day, and it usually takes a while before one notices)
• Using smartcards with keys generated by someone else: somewhat unlikely (there may be a few people who know my private key, but one can't be sure of that; and, color me naive, but I tend to trust the government to abide by its own laws—for the most part—laws that prevent this kind of behavior)
• Using strong password: rather unlikely, provided you take care of them.

What I mean by that last bit is that you should always generate your passwords with a tool that generates fully-random passwords ('pwgen -s', for example), and never write them down in cleartext anywhere. That of course makes it slightly hardish to memorize them; what I do is to store the password encrypted to my GPG key on my laptop, and I memorize the password by changing it on a remote server that I need to access fairly often (Debian's systems will do), but leaving my GPG passphrase and laptop password as is for the time being. Every time I need to log in to the remote server, I first try to remember the passphrase. If I can't remember it, I look it up in the encrypted file (again taking care not to store the file on disk). Once I start being able to log in to the remote server without having to look it up in the file, I change all my other passwords. This process usually takes a few weeks. Then, the only way someone can get my password is either by coercing me or by killing me and disecting my brain. And then still. Unfortunately, in the real world, I realize that many people do not wish to go through all this trouble just to get a secure login, and instead just choose a weak password. I guess that's why I think the next best thing might be slightly better than using strong passwords...

The students in my Hacker Culture and Politics have now been at the question of politics and ethics in the world of hacking for over a month. I think a pretty solid foundation has been built and now we are getting into much nittier grittier issues, like intellectual property law. The latest entry is on IP and provides an excellent sense of what we talked about and what we covered in class and in the readings. I am excited to see the class blog develop, if nothing else, because it gives a pretty good sense of the topics we cover and what conversations we have. I used to find it frustrating to have classes literally vanish away after they were done and yet so much labor and time had been put in them! This type of blogging is important as it can provide a tangible and somewhat fixed medium for capturing and preserving what happened (and then free you from having to save boxes of notes that you can collect during college). I know there were a number of times I really really wanted to recall something from one of my undergraduate classes, but since I had finally thrown away the big old boxes of notes and readings from those days, there was no place to look. It was just not practical to lug my boxes of notes from place to place, move to move especially when I only wanted to take a look every few years for maybe one thing. With this type of blog, there is a record of what happened for everyone to share. That said, I am faced with a problem when I teach this class again. Since we provide what I think is a pretty decent account of what we are doing, I will most probably have to put down the blog for a period of time when I am teaching it again though of course the syllabus and readings will also change to some degree.

The students in my Hacker Culture and Politics have now been at the question of politics and ethics in the world of hacking for over a month. I think a pretty solid foundation has been built and now we are getting into much nittier grittier issues, like intellectual property law. The latest entry is on IP and provides an excellent sense of what we talked about and what we covered in class and in the readings. I am excited to see the class blog develop, if nothing else, because it gives a pretty good sense of the topics we cover and what conversations we have. I used to find it frustrating to have classes literally vanish away after they were done and yet so much labor and time had been put in them! This type of blogging is important as it can provide a tangible and somewhat fixed medium for capturing and preserving what happened (and then free you from having to save boxes of notes that you can collect during college). I know there were a number of times I really really wanted to recall something from one of my undergraduate classes, but since I had finally thrown away the big old boxes of notes and readings from those days, there was no place to look. It was just not practical to lug my boxes of notes from place to place, move to move especially when I only wanted to take a look every few years for maybe one thing. With this type of blog, there is a record of what happened for everyone to share. That said, I am faced with a problem when I teach this class again. Since we provide what I think is a pretty decent account of what we are doing, I will most probably have to put down the blog for a period of time when I am teaching it again though of course the syllabus and readings will also change to some degree.

The Omelette Post by Atul Chitnis provoked a lot of discussion and Christian Perrier's response explains the objections clearly. I disagree with them both in different ways. Hence this post. Atul Chitnis is not known for his politeness (unfortunately, like many in the FLOSS community). In such cases, it is best to try to understand the (positive) intent behind the words written rather than concentrate on the words themselves --- the current kabab mein haddi seems to be "low-hanging fruit". I agree with Christian that finding, analysing and fixing bugs ranks up there along with writing programs; especially since many of today's programmers continue to be ''bug-generators'' in the sense of (and in spite of) Dijkstra's article. My reading of the Omelette Post is that hacking should take precendence over talking at FOSS.in 2008 --- a sentiment that I find quite palatable and even tasty! So let's see if we can have a Debian Workout at FOSS.in 2008.