Adopting w3-recs (i.e. experiences in package generation) A week ago or so I decided to adopt w3-recs, a documentation only package aiming to ship recommendations of the W3C in Debian. The previous maintainer (Frankie) step down from w3-recs maintenance since the packaging work was quite boring (add recommendations piecewise as soon as they came out, update them when needed, keep doc-base entries in sync, ...). I didn't want to follow that path and, probably for the first time in my life, the (not so) semantic web has come to the rescue. Starting from the TR automation page, I've found an always up to date index of all Technical Reports published by W3C, enriched with some information about the status of the TRs (draft, candidate recommendation, recommendation, ...) which is in RDF/XML format, and hence machine processable. The final result is that now the w3-recs package is mostly automatically generated via debian/rules target. The get-orig-source target first downloads the RDF index of the technical reports and then downloads all of them via wget (it took me sometime to find the appropriate flags, I've ended up with a award-winning wget command line containing 12 dash switches!). Then, at build time, several derived stuff is generated from the very same RDF index via XSLT: doc-base entries for all the shipped documents (the current grand total is 119 recommendations), a HTML index summarizing the available documents, and other debian/ stuff needed later on in the package build process. The next steps for w3-recs should be automatically split of the package in sub-packages classified according to the corresponding W3C activity, and enrichment of the doc-base entries with abstracts. Unfortunately neither of the 2 kinds of information are provided yet in the RDF index (not so semantic web, after all). Infrastructure deficiencies encountered in the process

• wget is not that good at mirroring: I've been bitten by a lot of undocumented behaviours and bugs (e.g.: undocumented ordering requirements among command line flags, fuzzy timestamping, bugs in a posteriori URL rewriting when a destination base dir is specified, ...). I've found no better alternatives which can basically just mimick what firefox does when you save a "complete" (set of) web page(s) on disk
• dhelp is just completely broken. It is not able to deal with some 100 doc-base entries, it just shows some of them (about 10, do not dare to hope in more) and even trims the title lines. Luckily doc-central is much better. At a times I find myself thinking that I'm the only believer in Debian's doc-base ...
• Oh, and while we are at it: I'm still convinced that having the doc-base hierarchy bound to the menu policy is just plainly dumb

(or: Why Everyone Should Learn Some Basic Programming) I am an organisational disaster area. I just can't remember "event oriented" information (like "I need to do $foo" or "I need to do $bar at $time"). I think I've accumulated such a huge collection of technical trivia that it's taken over the event planning part of my brain -- although, since I've never been able to remember event oriented information, even before I became a computer geek, it's more likely that I was just built without that bit of the brain. So I guess I'm the perfect target market for some sort of external brain pack (a la "Ratbert the Consultant"). I've tried paper-based organisers (the mighty Filofax), a few pre-written apps, and I even bought an SL-C3200 Zaurus a while ago (although, to be fair, that was really just for the hack factor, regardless of what justification I may have given to others at the time). None have worked, for various reasons. I can't grep paper, and Other People's Apps bug me because they've got their idea of workflow, and I've got mine, and when they don't match up (and they never do) I just get irritated -- not to mention the fact that the ubiquitous relational database, while wonderful in some ways, does tend to get in the way of ad-hoc faffing with your data. But this article is a success story, not a rant (gasp!), so it's safe for you to assume that I've got something that's working for me. My method is real simple -- plain text files, managed by vim-outliner and a simple shell one-liner I've named 'pda', which just runs vim ~/pda/$1.otl. At the moment I've got a monster todo.otl, which is my world's todo list, and a deeply underused calendar.otl. I'm also using vim-outliner to do some project planning, which has been moderately successful, although I'm a bit freaked out by the idea of trying to manage a large-scale project using it. The really, really cool part of this whole shebang, though, is that because all of my data is (structured) plain text, writing little programs to parse the data and do funky things with it is dead simple. For example, in my project outlines, I put estimated, actual, and remaining times in for all tasks (a la Joel Spolsky's Painless Software Schedules) so I can keep track of my estimates and where they differ from reality (because one day I'd like to not Suck at estimating times, and feedback is the only way I'm going to do that). So, about an hour's worth of Ruby gave me "estimator", a script that reads all that data and does a pile of mathematical gubbins about how far over my estimate I am so far (or under estimate, if that were to ever happen), the percentage of the project complete (based on the estimates and number of tasks completed), and things like that. Similarly, today I wrote a small script (run out of cron in the wee hours of the morning) to read my calendar and send me an e-mail if I've got anything in there for today. Since I practically live in mutt, a morning e-mail is going to be far more effective than my trying to remember to check my calendar every morning (especially since, at present, I'm not using the calendar as often as I should, so there's even less motivation to check it). This, in my opinion, is why everybody (literally, every single person) should learn to program at some fairly simple level, like learning to read and write. By using plain text and small scripts, I've got a workflow that works for me, and it's cost me less time than I'd spend learning some large pre-written app and putting all my data into it. Being able to manipulate data like this is, I think, a fairly important tool in the modern world, and I don't think it should be left to any sort of priesthood of developers -- it should be as universal as most countries try to make literacy and numeracy.

I'm checking available banking services for work. I'm looking mainly for features like accessible free-software-friendly internet banking, integrated VISA credit card and easy-to-access counter services and I have a preference for mutuals. I did a double-take when the email enquiry reply from Nationwide arrived. It started with the line

"-----BEGIN PGP SIGNED MESSAGE-----"

That's a first. Their key's on my preferred keyservers and everything. Wow. I can't find a page on their web site about this, but it looks intentional. Bank email security has been irritating me for some time. Very few of my customers use GnuPG yet, and even fewer of my providers. Well done Nationwide! (Update: 2007-09-28: 1 comment)

I’ve been so busy lately that I forgot to write about it: Piklab is now in Debian. I don’t know if any of you has done and development with PIC microcontrollers, but it’s not that there was a lot of free programs for doing so. Even now, it might be problematic depending on which hardware you have for programming them. In any case, Piklab is an integrated development environment for applications based on Microchip PIC and dsPIC microcontrollers similar to the MPLAB environment, which makes it easier to develop. It’s a real pity that we cannot consider the newer versions of SDCC as DFSG-free, due some non-commercial clauses, because it is a real nice companion compiler for Piklab.

A new release of xen-shell was made last night, which fixes a couple of minor niggles:

• The --control command line flag simply did not work. Now it does.
• The 'uptime' command works with both new and old Xen versions.
• Shell history persists correctly even on unclean shutdown/exit.

Unless there are great demands for additional features I'm now going to regard this project as complete/finished. Certainly it works well enough for myself and my users. Satisfaction is ...

Like any sensible software developer, I have a close relationship with revision control systems. In my previous job, I was an SCM Engineer (see Software configuration management) which meant I had an even closer relationship than most, since we were running the CVS servers and actively using them to track changes and deployments. We all know, deep down, that revision control systems shouldn’t exist. This kind of thing should be inherent in the design of the operating system, through standard file and filesystem formats. The OLPC interface is making some headway towards that, but for the rest of us, it means using a revision control tool throughout the development process. Unfortunately, even though the tool is expected to be the most-used command on your system, very few of them are particularly easy to use. Thus there’s a large learning curve, and people become religious about their choice since they have invested significant time in using it. Just to spice the mix up, not only will people religiously defend their choice of revision control system, but they’ll do so while actively hating it. In the beginning there was CVS and we all thought that it was pretty good. It was based on the simpler RCS and shared a file-format with it, but introduced control of directory trees and remote operation. Actually, in reality, CVS wasn’t that good. Its command set could be a little strange and inconsistent (e.g. it’s not possible to diff between two dates on a branch); the support for branching assumed that all branches would be merged into the mainline, and only once; and nobody ever really knew how to create a new project in a repository (tip. cvs import is wrong). But we all used it anyway, and we muddled through. It did have some good features; it was simple, fast and pretty reliable–when it did break, you could usually fix the repository yourself. And most importantly of all, we understood how to drive it. And so it was for many years, until Subversion (SVN) came along. Subversion intended to be “a better CVS”, perhaps this goal should have made us suspicious at the time since CVS was already being a pretty good CVS by itself; unfortunately we hated CVS so much we flocked to the new system in hope. In hindsight, Subversion didn’t really improve on CVS much at all. In fact, arguably, the only real improvement was the addition of atomic commits (in CVS, each commit is per-file, so it’s manual labour to work out which change was made to two files at the same time). (Its support for branching, tagging, copying, renaming, etc. were no better than CVS’s when done in the repository by hand.) The cost of this single new feature was a much more complicated interface (with two separate commands), a backend that tended to break down weekly and a lethargic slowness to its operation. Most people I know now justify their use of Subversion instead of CVS by “Subversion is maintained, CVS isn’t” which is a somewhat self-fulfilling justification. While the mass conversion to Subversion, and ensuing disappointment and frustration, was going on; something new appeared on the horizon: Arch. Arch was different, it broke one of the core assumptions of revision control, that of the repository as a cathedral. In CVS, and Subversion like it, if somebody wants to modify your code (even if on a branch) you need to give them access to your own repository. In some cases (especially with CVS), vast access control and permission structures would be in place to ensure proper behaviour. With Arch, you don’t; all you need to give to anyone is read access. Anybody can make their own branch by copying yours and committing to their own copy. This model also necessitated fixing a long standing problem that CVS had; Arch has repeatable (smart) merging. If you merge from a branch, you can merge again later, and again, and again. Arch made this possible through each commit (changeset) having a globally unique identifier; made from the branch’s own globally unique identifier and the changeset number in the branch. Unfortunately while this was a massive step in a new direction, Arch had an absolutely terrible user interface. Its command list was terrifying with over 100 commands, many of which had multiple word names (tla set-tree-version). It exposed too many of its own innards, and expected you to learn them. It also forced baroque file naming semantics on its users and strange policy (though shalt not commit without first running “make clean”). Efforts were made to improve Arch’s user interface through projects such as baz, but they were always to be doomed from the start. We’ve since seen an explosion of new revision control systems; Monotone, Darcs, Git and Bazaar. What’s especially interesting is the commonality between these systems. They are all “distributed” like Arch, though they also all discard the strange “unique branch identifier” convention and instead simply assign a unique identifier to each file or commit. This means that they all support personal branches, and by necessity all support repeatable (smart) merging. So how do they differ, what are their killer features and killer problems? Monotone is all about repository integrity, ensuring that every commit is both authorised and intact. It pays for this with a severe lack of speed. Darcs is based around a “theory of patches”, a branch is not made up of its history but by the collection of patches in it. Unfortunately this often breaks down, and darcs frequently gets stuck calculating even trial and commonplace branch models. Git is very strange to me; its killer feature appears to be the speed at which it can handle very large trees, but the interface is as insane as Arch’s was. It is heavily optimised for the “I only apply patches” development model, at the expense of ordinary development models (it shares an issue with Arch where calculating annotations on an individual file is an expensive operation). What about Bazaar? Its killer feature is that it is designed to work the way you do. The command set is relatively small, and each of them works in the most obvious manner. It also supports plugins so that you can always implement your own workflow. Of all the revision control systems, it’s the only one (that I’m aware of) that supports both distributed and centralised workflows (and lets you go distributed when you need to, e.g. when you’re on a plane). Here’s a few examples of how Bazaar’s command set works the way you do. To start managing some code in bzr:

$ cd myproject
$ bzr init

To add the files, copy in your usual .bzrignore file and just add everything:

$ cp ~/bzrignore .bzrignore
$ bzr add
added foo.c
added bar.c

Check the output for mistakenly added files, adjust .bzrignore and remove the file with bzr rm. A common operation is realising that the commit you’re about to make should really go on a new branch for now:

$ cd ..
$ cp -a myproject myproject-foo
$ cd myproject-foo
$ bzr commit

A copy of a Bazaar branch is a different branch, you can commit to it separately. There’s a bzr branch command for it too (which deals with issues such as bound branches, checkouts, etc.) but it’s nice to demonstrate that Bazaar does what you’d expect even when you don’t use its own commands. Pulling changes from another branch (where you haven’t made any modifications yet) is easy:

$ bzr pull ../myproject

As is merging (when your branches have diverged):

$ bzr merge ../myproject

One particularly nice feature is that after a merge, you see the merge as a single commit and it can be treated as such; but it also has the set of merged commits indented under it–you can examine these as individual commits as well! What’s the downside of Bazaar? Well, it’s not the fastest system (but by no means the slowest), for small to medium sized projects this is never an issue but may be for extremely large projects–fortunately the developers are improving its performance all the time! But that doesn’t matter; it is, honestly, the first revision control system that I don’t hate.

Seriously. Now that we have been using the request tracker for quite some time, it’s even more obvious that the DSA team is not up to its task. Use login “guest” and password “readonly” if you want to check the RT tickets linked in this article. The facts

• 65 public tickets open (and 5 private tickets)
  • Want to help and seek input from DSA? No response.
  • Want to help and you provide patches and/or solutions? Many are still waiting.
  • Security updates? Who cares…
  • Backup of ftp-master (ries)? No reply (though ftp-master stuff is mirrored on merkel)…
  • New alpha machine? No movement despite the fact that we still have no DD-accessible porter machine.
• 68 tickets closed. Here are some unscientific and manual stats (I counted one each time that someone was involved for the work or for closing the ticket):
  • 27 for James Troup (elmo)
  • 26 for Phil Hands (fil)
  • 13 for me (buxy)
  • 3 for Martin ‘Joey’ Schulze (those I manually forwarded him)
  • 3 for Ryan Murray (neuro)
  • 3 for Matt Taggart (taggart)
  • 2 for Josip Rodin (he handles tickets concerning the mirrors until they have a dedicated queue in the RT)

Note that myself and Matt do not have the needed rights to fix most of the tickets, so we provided help on a best-effort basis. Otherwise we would have done more. The communication problem It’s a multi-level problem. Each of the members has some problems with one or more other members. Joey’s behavior has been part of the recurring problems mentioned: he doesn’t use the RT, doesn’t read the DSA email alias and doesn’t follow the DSA IRC channel but he still does stuff very regularly without reporting anything and obviously problems happen. Ryan and James tried to impose him a rule to document what he does, without success apparently. On the other side, as far as I know, Ryan and James also don’t impose themselves to document everything in a central changelog. Joey has refused to provide me an explanation for his behavior. He just reminded me that he holds grudges against James and Ryan because as ftpmasters they didn’t cooperate well with him while he was stable release manager. In general, outside of all personal griefs that they might have, the DSA members do not communicate very much (at least not on their own official channels). Some examples have already been given concerning the request tracker, but it’s not much more effective on IRC. Most of the traffic on the channel is made up by local admins fixing the problems themselves without any intervention by any DSA. I also use the channel to regularly ping some DSA about simple issues and/or stuff that they usually handle. It used to work somewhat but lately fil has been busy (with the kernel summit and other conferences) and I simply got no answer at all… for example I pinged elmo, neuro and fil several times in the last weeks in the hope that they handle the tickets of the security team (#150, #157, #164) without results. There’s room for improvement. The leadership problem The team has no designated leader and every time that there’s a decision to take, they are blocked. Joey wouldn’t communicate and give his opinion, Ryan is extremely requiring and perfectionist, there’s not much room for compromise… A long time ago in a galaxy far, far away, Joey and elmo were friends. It’s even Joey who gave root rights to elmo. Nowadays, it’s rather James that is sort-of leading the team but he’s fed up of the situation and hasn’t managed to get out of this mess. He refuses to take drastic measures by himself because he’s not clearly the leader and doesn’t solicit a decision of the Debian leader (or the project) because he believes that the DSA team is not under the scope of the constitution! This can’t last any further. We’ll have to do something about it. Stay tuned.

I'm pretty sure someone in one of my syndicators was looking for software to send emails in the future from anywhere, but I'm damned if I can find the message. At the time, I was using a homebrew system involving shell scripts and mailx, so I wasn't much help. I'll upload a proper release soon, but I'm happy to upload a second hack of maildelayline here. It requires recent bash, sed, at and a sendmail-like executable. I've deliberately kept it simple to try to make it easier to debug and I dislike needing to install too much for such a simple task. Make a temporary directory, edit the top of the script, then install it on a pipe mail alias (I'd keep the address secret and improbable, like RUbAHy8961: " /path/to/maildelayline" and then save the address in my address book) and send it an email. At the start of the email body, write a pseudo-header with the time, like

"X-Send-At: now + 7 hours"

and follow it with the To:, Cc:, Bcc: and any other headers. Some headers (like from, message-id and threading ones) are kept from the original message, but the Date and Received headers are among those removed. Don't put the X-Send-At in the email header unless you know what you're doing - usually, put it in the body. The X-Send-At field can be any time that your at program understands. If you confuse it, or forget to give it a time, then you should get a bounce message that says something like "garbled time" among other errors. maildelayline is similar to Leave A Message or FutureMe but it sends mail to anyone, autonomously on your own server, from emails instead of a web form. I think it will resend MIME attachments as long as the pseudo-header is in a plain text/plain part and not quoted-printable or base64 or something. It is named after delay lines, which I believe are mostly used in audio effects to repeat a sound after a time delay. Please leave a comment if you find this useful, or if you have an improvement.

While it's cute that atoponce wants to blame #debian for his problems, what he neglects to mention is that I spent some time with him in #debian finding his bug and telling him that his best bet was to watch that bug report because that's the most up to date information available on the problem. Furthermore, I told him how to add a "me too" to the report so that he would be taken care of. I also googled him up a wiki page that explained what GLcore was better than I ever could. And I tried to do it as politely and respectfully as I could.

I'm not sure what more people want from the channel. The #debian policy is that "if you're running sid, you're on your own." The reason is that it's your machine and you're responsible for it. The fact that Aaron chooses to blame other people for his decision to run a development version of a package (and then to not downgrade it when it becomes too problematic) is the kind of frustrating attitude that makes me want to stay away from being active in user support.

Fortunately, #debian is actually a very good channel on the whole, especially in comparison to the past, where some individuals really were just plain mean spirited. It's full of knowledgeable users who are generally willing to help you find a solution to your Debian problem. Sure, they're wrong sometimes, everyone is. And no matter how knowledgeable you are, you're not going to be able to predict that the next upgrade will hose some random guy's system. If you want to run unstable, be prepared for what's in store and learn how to downgrade.

I’m looking (or I’m desperate) for an RSS reader which differentiates between new and unread articles, and can show a count that only includes new articles for each feed. My current reader, Akregator, sort of fulfills the first requirement, but not the second. If you know of one, please let me know. I’m willing to give it a try even if it’s written for another desktop environment than my own, or in a language that I don’t like. If I can’t find one, I will try to go back to rss2email and Mutt. But I really, really, really dislike the management of feeds with rss2email. I would love to have it read a simple text file where feeds are listed in groups, each group has a keyword to add as an email header, and I’m free to add/delete/move feeds in the text file with changes being effective in the next r2e run. Any suggestions on this side?

Progress on most fronts. Life is mostly good thus. Reading email only once a day also helps a lot in remaining sane. If it can be urgent, I have given you my phone number. It seems that Planet Debian has a new meme, namely unveilling replacements for the ion window manager. I'm late to the party as I'm using mine as the example code in the componentisation tutorial to introduce the concepts and language bindings one by one -- obviously I have to make that work with a few languages first. And at the same time, work for a living.

I have a number of friends who are finishing PhDs and then I have those “special” friends who are wrapping up their dissertation and manage to do something else quite extraordinary right at the same time. Shay David is one such friend who is currently wrapping up a fascinating dissertation on the social implications of openness and collaboration in various contexts (software, biology) but is also pushing the boundaries of what we mean by collaboration by helping to create a new vision, platform, medium, tool, and site, Kaltura. As you can read about more on their about page, Kaltura basically lowers the technical bar for video editing bringing the power of editing to anyone, at least anyone who registers for an account. Kaltura provides an easy-to-use tool kit that allows you and others to hack away to create, edit, & mashup videos. In lowering the bar, they are significantly expanding the mind (and actual space) for video collaboration. Some more good news is that Kaltura is soon going to GPL its technology, and they are looking for developers who want to contribute to this exciting project. The project is in PHP and Flex/ActionScript3, if anyone is interested, they should email developers@kaltura.com! Happy (video) hacking…

I am helping to kick off the Decoding Liberation Book Launch Party at the Brecht Forum in NYC. If you are in the area, and are into the politics of free software, do come along. Details also pasted below as their webpage is a little bit of an aesthetic jumble.

The Brecht Forum invites you to celebrate the release of Decoding Liberation: The Promise of Free and Open Source Software, by Samir Chopra and Scott Dexter, published by Routledge in their New Media and Cyberculture Series. October 3rd, 7:30 PM
451 West Street (between Bank & Bethune Streets, New York, NY 10014.
(212) 242-4201
brechtforum@brechtforum.org Suggested Donation: $6/$10/$15
Free for Brecht Forum Subscribers Featuring commentary by Gabriella Coleman and discussions with the authors
and audience. A reception will follow.

(more…)

My previous post about the SFWA falsely issuing DMCA take-down notices [1] has got some reactions, many of which indicate a lack of clear reading of my post. I am not advocating boycotting sci-fi. I am merely changing the priorities for my reading list. There must be at least 10 sci-fi books on my shelf of books to read, so refraining from buying more for a while isn’t going to impact my reading much either. In regard to whether boycots are good or bad, it should be considered that the enjoyment of a work of art is highly subjective. If you don’t like the artist then you probably won’t enjoy the art. Boycots on products for which there are objective criteria of quality are often unsuccessful because the buyers have to make a conscious decision to buy a product of a lower quality or a higher price. I can’t make any objective claim about the relative merits of the work of Cory Doctorow and Jerry Pournelle. But it is impossible for me to enjoy reading Jerry’s work as much as I enjoy reading Cory’s work due to my opinion of the two authors. I have just read a post by Eva Whitley [2] (the widow of Jack L. Chalker - one of my favourite authors when I was younger). She starts by describing Jack’s attitude towards electronic publishing, which sounds quite enlightened. She then notes that Del Rey has the rights to some of his books which are officially still in-print but in practice impossible to get, Baen is still paying royalties but had paid him a large advance so he won’t receive money until the royalties exceed the advance, and some books are out of print but no publisher wants to buy the rights to do a re-print. So it seems that she is not receiving money from her late husbands work partly due to book companies being uncooperative (not printing the books and not permitting others to print them without payment) and partly due to being paid in advance. Eva states that she is happy that the SFWA issued take-down requests for copies of the work of her late husband. That is good and in fact it’s a legal requirement. No-one can legally get copyright laws enforced unless they own the copyright or they are acting on behalf of the copyright owner. She is entitled to authorise the SFWA (or any other group) to act on her behalf in regard to her copyright violations. Neither the SFWA nor anyone else can take action against copyright violations without such permission. Jerry Pournelle has written about the situation [3]. He complains that the site owners wanted the items listed individually. The Wikipedia page about the DMCA [4] makes it quite clear that you must provide such detailed information to get something taken offline, and that the DMCA take-down request MUST include a statement claiming ownership of the material UNDER PENALTY OF PERJURY. If you make a false DMCA claim then you are committing perjury, according to Wikipedia the penalty for perjury in the US is up to five years in prison [5]. Sure any idiot can write up DMCA take-down requests for random stuff on the net and get them acted on (here’s an example of a 15yo idiot who did just that [6]). But if you want to stay out of jail you have to avoid making such false claims. Jerry expresses a total lack of sympathy for Cory Doctorow and other people who have been victims of slander of title [7]. I wonder how he would react if someone started making public statements under penalty of perjury claiming that he didn’t own the title to some of his work. I suspect that he would desire something similar to what he desires to be done to people associated with 9-11 [8]. Finally one thing that I suggest doing to make some additional money from writing sci-fi is to release T-shirts. A basic T from cafepress.com was $7 last time I checked. $11 for a shirt based on a sci-fi book is not overly expensive and gives $4 profit for the author (more than twice what most authors make from a book sale). Shirt sales are unlikely to make as much money as book sales due to lower volumes, but the effort involved in creating a shirt design is not so great. A publishing company may deny an author (or their estate) future revenue by refraining from printing further copies, but unless they also own the trademarks related to the book and deny the author (or their estate) the right to use them then it should still be possible to make money from merchandise. Making money from merchandise is not as glamourous as making money from book royalties, but it can be effective as demonstrated by xkcd.com.

• [1] http://etbe.coker.com.au/2007/09/17/web-scabs/


• [2] http://evawhitley.net/2007/09/08/on-scribd-jerry-pournelle-and-jacks-books/


• [3] http://www.jerrypournelle.com/view/view481.html


• [4] http://en.wikipedia.org/wiki/Dmca


• [5] http://en.wikipedia.org/wiki/Perjury


• [6] http://www.australianit.news.com.au/story/0,24897,21563838-27317,00.html


• [7] http://en.wikipedia.org/wiki/Slander_of_title


• [8] http://www.jerrypournelle.com/war/whattodo.html

Share This

I have just converted a Fedora Core 5 server to a CentOS 5 Xen Dom0 with Fedora Core 5 as a DomU. The process took a little longer than expected because I didn’t have console or network access to the DomU initially. It turned out that /etc/modprobe.conf was configured to have the tg3 device for Ethernet while I really needed xennet to get networking going. The console problem was due to the fact that the device /dev/xvc0 is used for the console in DomU’s and the Fedora Core 5 image was configured for a non-Xen mode of operation. Incidentally it seems a little strange that a default install of CentOS as a DomU will get gettys for /dev/tty[1..6] when none of them seem accessible. After I changed the /etc/inittab file to get the correct name it still didn’t work. It seems that the SE Linux policy in Fedora Core 5 doesn’t have the correct context for the /dev/xvc0 device. semanage fcontext -a -f -c -s system_u -t tty_device_t /dev/xvc0 So I had to run the above semanage command to change the policy configuration, followed by restorecon /dev/xcv0 to apply the change (although once the change is configured it will apply after the next reboot).

Share This

The new house has a prepay electricity meter. My initial reaction was that I'd have to get NIE to come out and replace it with a normal meter, as I have a perception that card meters are awkward and expensive. However some investigation revealed that a keypad meter gets the same 2.5% discount that paying quarterly by direct debit does. The only way to get a larger discount (4%) is to pay a fixed amount monthly by DD. That would still leave the annoyance of having to remember to top up, but it can be done over the phone with an automated system (you get a 20 digit number to key into the meter) and won't turn off supply overnight or at weekends apparently. Plus, and this is the real reason I'm giving it a while before switching away, it has a nice little satellite keypad/LCD unit. Connected to the main meter unit via a 4 core low voltage style cable. Bets on those being power, ground, rx and tx? You can query the meter on various things, some of which are crying out to be hooked up to a Munin plugin. The meter is made by PRI and seems to be a Liberty 1E. PRI have a vague page about comms, but little useful information about how to do anything or if the end user can buy anything suitable. I'll drop them an email, but it might just be a case of trying to reverse engineer the keypad protocol so I can talk it. The processor in the satellite is just a Mitsubishi M38223M which has some serial pins, so hopefully it'll be RS232 at TTL levels and something fairly basic over that. However, before I go about doing this, has anyone else any experience of these meters and care to share details?

A new law is being made in germany, which will make consentual sex between minors a crime, which has to be punished with four years of prison at least, plus ending up in a sexual offenders database for life. I, for one, do not welcome our new taliban overlords.

These two articles explain the situation in full detail (in german).

In other news, it's 102 days until all electronic communication in germany (as in the EU) will be logged for half a year. (Until a terrorist attack happens which was planned for more than half a year...) This includes all emails sent, the location data of all mobile phones, every webpage visited and so on. From everybody. If you are in Berlin tomorrow, go demonstrate. I, for one, do not welcome George Orwells lack of imagination, 1984 looks really pale today. (But it's still a good read.)

My next blog post shall take place in teletubby land again and shall feature smileys as well. Sigh.

There are many situations where multiple DNS names for a single IP address that runs a single service are useful. One common example is with business web servers that have both www.example.com and example.com being active, so whichever a customer hits they will get the right content (the last thing you want is for a potential customer to make some trivial mistake and then give up). Having both DNS names be equal and separate is common. One example of this is the way http://planet.ubuntulinux.org/ and http://planet.ubuntu.com/ both have the same content, it seems to me that planet.ubuntu.com is the more official name as the wiki for adding yourself to the Planet is wiki.ubuntu.com. Another example of this is the way http://planet.debian.org/ and http://planet.debian.net/ both have the same content. So far this month I have had 337 referrals to my blog from planet.debian.org and 147 from planet.debian.net. So even though I can’t find any official reason for preferring one over another the fact that more than 2/3 of the referrals from that planet come from the planet.debian.org address indicates that most people regard it as the canonical one. In times past there was no problem with such things, it was quite routine to have web servers with multiple names and no-one cared about this (until of course one name went away and a portion of the user-base had broken links). Now there are three main problems with having two names visible:

1. Confusion for users. When a post on thedebianuser.org referred to my post about Planet Ubuntu it used a different URL to the one I had used. I was briefly worried that I had missed half (or more) of the content by getting my links from the wrong blog - but it turned out that the same content was on both addresses.


2. More confusing web stats for the people who run sites that are referenced (primarily the bloggers in the case of a Planet installation). This also means a lower ranking as the counts are split. In my Webalizer logs planet.debian.org is in position #5 and planet.debian.net is in position #14. If they were combined they would get position #3. One thing to keep in mind is that the number of hits that you get has some impact on the content. If someone sees repeated large amounts of traffic coming from planet.debian.org then they are likely to write more content that appeals to those users.


3. Problems with sites that have strange security policies. Some bloggers configure their servers to only serve images if the referrer field in the HTTP protocol has an acceptable value (to prevent bandwidth theft by unethical people who link to their pictures). My approach to this problem is reactive (I rename the picture to break the links when it happens) because I have not had it happen often enough to do anything else. But I can understand why some people want to do more. If we assume that an increasing number of bloggers do this, it would be good to not make things difficult for them by having the smallest possible number of referrer URLs. It would suck for the readers to find that planet.debian.org has the pictures but planet.debian.net doesn’t.

The solution to this is simple, one name should redirect to the other. Having something like the following in the Apache virtual host configuration (or the .htaccess) file for the least preferred name should redirect all access to the other name. RewriteCond % REQUEST_URI ^(.*$) [NC]
RewriteRule . http://planet.example.com/%1 [R=301,L] In my posts last night I omitted the URLs for the Planet Searches from the email version (by not making them human readable). Here they are:

• Search Planet Linux Australia: http://google.com/coop/cse?cx=008627835083532581857%3A7j_t83ytzca


• Search Planet Debian: http://google.com/coop/cse?cx=008627835083532581857%3Ak8pyp2qk8lm


• Search Planet Ubuntu: http://google.com/coop/cse?cx=008627835083532581857%3Acexvbhdg9k8

Share This

[Gnaaaaa, sorry Planet Debian for sending a german article to you a few hours ago. I just chose the wrong category for the article. I removed the tag already and the article disappeared from Planet Debian right now; so if you don’t know what I’m talking about just don’t care. To the german readers: it’s just the same article as my previous one, but this time in english. :-)] grml-live is a framework which lets you build a grml/Debian based Linux Live-CD with one single command. grml-live is based on FAI (Fully Automatic Installation) and uses its class based concept: In this example I built a full grml-ISO. All I did was setting the Debian-Mirror in /etc/grml/grml-live.conf to my local one (to save traffic and time) and invoking the following command:

# grml-live -t /grml/grml-live -c GRMLBASE,GRML_FULL,LATEX_CLEANUP,I386 -s sid

About 50 minutes later I have a grml-ISO inside grml_isos at directory /grml/grml-live/ (-t …). It was built using the classes (-c …) GRMLBASE (all the core, essential stuff), GRML_FULL (software selection like official grml provides), LATEX_CLEANUP (clean up some very big LaTeX directories) and I386 (x86-specific packages like kernel). Debian unstable/sid was used as the suite (-s). And that’s it. You want a smaller grml-version using Debian/stable? No problem, let’s do it in shared memory (being very fast, and with enough RAM and mountoptions rw,suid,dev no problem at all): A ‘grml-live -t /dev/shm -c GRMLBASE,I386 -s etch’ and not even 5(!) minutes later I’ve my 135MB small grml: So using grml-live you can build your own, customized Linux Live-CD without having to deal with remastering in detail. Via creating a new class (or just editing an existing one) its easy to include the software you would like to get. So, will the official grml-ISOs become obsolet? No, definitely not. The goal of grml-live is to give the grml-team a buildsystem providing exactly what we need. It should give us the possibility to concentrate on the important and interesting tasks, like: testing, bugfixing, implementing new features, working on the kernel, quality assurance, documentation,… grml-live should work on every Debian based system. If you want to give it a try just grab the Debian package from grml’s repository. The source is available (as usual) via mercurial. Find more details on the grml-live-webpage. If you have any further questions that aren’t answered by the docs yet, have feature requests, bugreports or patches: please let me know.