Looks like we (almost) have a candidate: And since that has to be signed: Photographs courtesy of Aurore D.

This is just one problem with a profit logic ruling our health care. It is good to see this investigation start but it feels a little like a kitten fighting a 100 pound gorilla. A little to little and too late.

A few days ago, I asked how to fork a debian package privately. I got some repsonses by comments, e-Mail and other blog posts, and I want to summarize the tools that were suggested. I have not really tried them, just looked at the webpages, the documentation or the sourcecode. I m only including Debian-specific solutions, as using Gentoo might be nice, but is out of scope here :-)I also deleted half the text before saving it, and I hate rewriting stuff, so it might be a bit terse.debtooEddy Petri or tells me about his three year old project debtoo, which wants to bring a Gentoo-like experience to Debian. While it probably provides what I need, it feels too big in that it has a more general aim than what I m looking for. It is not in Debian and not actively developed in the last two years.srcinstEddy also tells me about srcinst, which is a small haskell program written by jgoerzen in 2005. This is more a proof-of-concept that builds a package and all necessariy build-dependencies without using a binary package, but does not allow for patches to be applied. It is in Debian, actively maintained, but not developed, and barely documented (just an IRC log).apt-buildA similar tool and also in Debian is apt-build. This package is created to compile packages for optimization (as it asks half a dozend compiler-flag-questions with DebConf during the installation). It allows the user to apply a patch to the source, but it has to be passed as a command line option, and patches seem not to be tracked. Not much development in the last year, and not much documentation.debpatchNot to be confused with the program in the debdelta package is the debpatch tool by Victor Hsieh which Carsten Hey told me about. Also written in 2005, this comes closest to what I want. For every package you want to modify, you can configure it to apply patches to the source, to add patches to the debian/patches directory or to statically replace files in the generated binary and puts it in a local apt repository. No code yet to track new versions of the packages and no support for pbuilder though. This perl script is not yet in Debian, but is available as a Debian package and seems to have seen some development in the last years. Quick Googleing does not return any user reports; has any already tried this?customdebSomewhat in this direction goes the script that I wrote two weeks ago for a totally different project, customdeb, but it is aimed at binary debian files exclusively, and debpatch already supports replacing files in the binary package.apt-srcAlso a related tool Carsten Hey told me about is apt-src. This tool wants to provide apt-like features for source packages. It allows you to install sources somewhere, upgrade the source and build binary packages from them. It does not really hide the sources from the user and seems to be created for people who want to work with the source somehow. If you have local changes to the sources, it can try to merge them with the new version, but these changes are not kept as a separate patch but only as implicit changes. If that were different, it would seem be a very nice tool. It s written by Joey Hess he abondonned it in 2004. Since then, not much development has happened.debnestYet another approach is taken by debnest, which Peter Makholm took over. Here, you create a full debian source package with a debian/ directory containing a control and rule file etc., but besides the debian/ directory, it contains just the packed sources (.dsc et al) from another package. In your debian/rules, you can specify your changes. I can see no support for tracking new versions of the inner package, but at least this project is maintained and in Debian.Summary I found a few projects that go in a similar direction, and one that seems to fit my needs quite well. All of them are not widely used and in a very early state of development, and it seems to be something people start to work on and quickly lose interest. I m actually surprised that this is not a itch more people had to scratch! I will have a closer look at debpatch when I find the time and maybe, if found useful, see if it can be included in Debian probably after a name change, since we already have a debpatch binary. Or maybe I should try to add support for what I need to apt-src, which seems to be the most advanced of all these programs, although it s unmaintained longer than the others exist.Update: Added apt-src.Update 2: Added debnest;

As eddyp wrote on Planet Debian, there is indeed a tool to roll custom builds of source packages. However, as he also mentioned, it’s written in Haskell, and may be unmaintained. One of the most commonly heard complaints I have received about Debian (and Ubuntu) is that it does not allow for easily rebuilding source packages. So, I’m going to start writing a new debian package builder for this purpose soon. It’ll probably be a package similar to pbuilder, except aimed at end users instead of developers. Here’s my plan of action: Phase 1:

• Interface similar to apt. Creates a build lab based on the current operating system (using lsb_release or similar) using debootstrap if one does not exist, then caches that build lab. A weekly cronjob will be added to make sure the build lab is kept up-to-date. (This would be provided by ’srctool bootstrap’.)
• Installing and building packages; dependencies will be resolved using gdebi. (This is provided by the ’srctool install package’.)
• A configuration file allowing you to specify DEB_BUILD_OPTIONS and other parameters to influence the build.

Phase 2:

• Some sort of policy proposal to add a common debian/rules option for declaring features. So that users can easily rebuild without LDAP support if they don’t want it.
• General hook to note that a package was built with custom CFLAGS etc for reportbug.

Thoughts:

• Is this harmful to Debian? I don’t think it is. Here’s why: most end-users will continue to use aptitude/apt-get and binary packages because they don’t care about building it. The key point here is, most Debian users just want their computer to work. As such, they won’t use srctool.
• The main point for srctool is to allow for easily slipstreaming in patches and custom build options in an easy way. (Also maybe in the future, local bumps if they want newer upstream version than what Debian provides them.)

Anyway, that’s just a project I have planned on the side over the next few months.

I would like to suggest to my readers to ask airplane crews for explanations of their rules. If we can get a larger number of people to inquire about the reasons behind the do s and dont s on airplanes, maybe the airline companies will adopt the practice. In the context of a previous post on the lack of explanation of the motivations behind airline rules, I was utterly impressed when the steward on the Air New Zealand flight from Melbourne to Wellington asked me to turn off my music player so that I would hear when they asked us to evacuate the plane or similar. While I doubt that I would continue to listen to The Flower Kings in an exceptional event, his explanation actually got me to turn off the player, which I had previously never done (rebel me!). I know it s a bit ridiculous, but I was previously so set on the idea of small devices like a music player interfering with the airplane instruments that I failed to see this obvious bit of logic. The steward thus gets my best steward award. When you fly, ask the crew about the reasons for the rules they impose on you, the passengers! NP: The Flower Kings: Unfold the Future

Here's a question that has bugged me for a while, and to which I've never found a satisfactory answer. How do people handle mailing list moderation when they have spam filters active? For instance, I get a lot of spam in the moderation queues for the Apache mailing lists I moderate. Sometimes gmail flags it as spam, and I can't quite say it's wrong... I mean the body of the email that's help up for moderation is often full of spam words. But the moderation message itself isn't really spam. I'm afraid of confusing the filter if I let it through. I guess this is where an open source system might be better, as you could simply put a rule in saying "if it's a moderation email, don't even bother looking at the keywords". Gmail's awfully convenient though... anyone else out there with the same problem?

On the 20th of January (8 days before the start of linux.conf.au) I advertised contest to write blog posts related to computer security for the conference Planet [1]. The aim of the contest was to encourage (by money prizes) people who had no prior experience in computer security to get involved by writing blog posts. The rules permitted security professionals to enter but only for an honourable mention, the money was reserved for people without prior experience. The money that I initially advertised was a fraction of what was reserved for prizes, the idea being that if the contest went well then the prize pool could be easily increased but that if it didn’t go well then there would only be one small prize for someone to win by default. At the time I considered a single entry winning by default to be the worst case scenario. The eventual result was that there was only one entry, this was from Martin Krafft on the point of keysigning [2]. Martin has prior experience in the computer security field which excludes him from a money prize, but he gets the only honourable mention. From a quick conversation with him it seems that his desire from entering the contest was to get his ideas about weaknesses in the keysigning process spread more widely, so this seems like a fairly ideal result for him. I agree with Martin that there are significant issues related to the keysigning process, but my ideas about them are a little different (I’ll blog about it later). His point about people merely checking that the picture matches on the ID and not verifying what the ID means is significant, the fact is that the vast majority of people are not capable of recognising ID from other countries. Other than requiring passports (which differ little between countries) I can’t think of a good solution to this problem. Congratulations Martin! It is a good post and a worthy entry. Now as to why the contest failed. I spoke to some people at the end of the conference about this. One delegate (who I know has the skills needed to produce a winning entry) said that I advertised it too soon before the conference and didn’t give delegates time to write entries. While I can’t dispute his own reasons for not entering I find it difficult to believe that more than a small proportion of delegates had that motivation. The LCA Planet had some lengthy posts by other delegates, and the guy who won second prize in the hack-fest spent something like 20 hours coding on his entry during the conference time (I suspect that my contest had the potential for a better ratio of work to prize money). Also the 8 days before the conference started was a good time to write entries for the contest. One suggestion was that I propose that the conference organisers run such a contest next year. The problem with this is that it’s difficult to say “I tried this and failed, could you please try it too”. If nothing else I would need some significant reasons to believe that the contest has the potential to be more successful before attempting it on a larger scale. If the contest had been backed by the LCA organisers then it might have been more successful, but that possibility seems unlikely (and there is scope for an event to be more successful than mine while still being a failure). The reason that I consider it unlikely that official support would make it more successful is that I first advertised the event on my blog (syndicated to the conference Planet). Everyone who has a blog and attends the conference can be expected to have read about it. I then advertised it on the conference mailing list which I believe had as subscribers a large portion of the people who have enough spare time to create a blog specifically for the purpose of entering such a contest. A blogging contest related to a conference but which had a wider scope (IE not limited to one field but instead covering anything related to the conference) might be successful. If someone wants to run such a contest next year then it’s probably worth doing. Of course I have not given up on the plan of getting more people involved in computer security, expect to see some blog posts from me in the near future with other approaches to this. Suggestions would be appreciated.

• [1] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [2] http://madduck.net/blog/2008.01.28:on-the-point-of-keysigning/

Share This

No Debian content here. Just like last year I decided to watch one of the largest sport events in the USA - the final game of the National Football League Super Bowl XLII (roman numerals are different for the sake of it ). I came to like the Japanese take on American football, so I watched the Superbowl last year and was appalled at the lack of any entertainment value in the game. I was told that it was one the worst Super bowls ever, so I gave it another try. Just like last year the American football looks to be very lawyer-friendly: bundles of complex rules and exceptions. The game could have been much simpler. Like for example, a lot of rues come from the fact that the game timer almost never stops. It is good for TV companies as they can plan their broadcast times better, but horrible for the stop-go game like the American football is. Just stopping the timer on every point the ball is stopped like they do in final seconds would cut out a lot of rules. Playclock and all. Rules on use of timeouts and stuff. Of course the game time would need to be adjusted down a bit. Now you have 4×15 minutes of ‘game’ where at most 20 minutes of that is in action. That game time is a lie - most of the time people are just standing around. Terminology irks me quite a lot. Why is it a “1st down” when there have been two “1st down”s just a few minutes ago? Something along the lines of “down counter reset” would be much clearer. And what is cryptic “1st & 10″ doing in the middle of the screen? It would have been much clearer if that info would be split: “Downs: 1/4″ and a measuring arrow between the ball and the yellow line with “10yd” written on it. And then there is an obscured “two in two” or “two for two” or “two in O” phrases which apparently means the same as “two 1st downs out of two tries” in the context. Can’t the commentators be a bit more elaborate and actually say the units of measurement? “Giants strength first tonight”? How about “in the lead”, English anyone? The camera placing editing is just horrible - the camera direction is switching all the time and that is confusing as hell. In normal football when professional camera teams are working, you always get all the shots from one side and even one general angle. If for clarity reasons a camera shot from other side is needed (usually in a replay) they always say that the image is from the reverse side in large letters on the screen. Here a lot of close-up shots were all over the place and even rotated around inside one shot! That might look fancy, but is just crappy camera work and editing. Then commentators start talking walls of numbers and walls of names. Unless you know by hearth who plays at what position, there is no way to understand what those people are saying. Than is just sloppy commentary. Is FOX incompetent in all possible ways? Then again the funky rules came into play just at the end of the first quarter - I have no idea why the ball was moved to the end line. Apparently the defender did or didn’t something. Did not see anything worth penalizing the team like that at all. They dropped the term ‘pass interference’ later on. Isn’t interfering with the pass the whole point of the defense play in this game??? Lawyer game, I’m telling you. And later on, pulling on guys arm while he is catching and being tackled apparently is just fine. And holding is illegal??? On the big penalty on the Giants the judge could have just said that the ball is out of bounds. Giving a 10yd penalty for such a minor thing is just ridiculous. The halftime show was kind of meh. Staged to extreme, but no soul nor sense. And what were all those people doing on the field? Isn’t that bad for the grass? And the commercials .. Average at best. Horrible at worst. For example a government commercial saying parents to protect their prescription medicine to .. help out your neighborhood drug dealer??? Oh and does anyone still doubt that media is controlled by republicans after that Coke commercial where the democrat is portrayed as bald and ugly and the republican is portrayed as the nice guy going for the compromise. And then they both Segway into the sunset? Brainwashing and prejudice embedded in a Coke commercial !?! WTF is going on in USA !? The 12-man-on-the-field penalty in the 3rd quarter is another legalese bullshit in the game. It is clear that the extra player had no effect on the game so it is just ridiculous for the judge to penalize the team for that. A couple small penalties were given for Patriots as well, judge bias was not as prevalent as last year. The camerawork stayed the same through the game - confusing, flashy and sloppy. Other cameras are in the shot line all the time. The game however did compensate for that all. The 4th quarter was very nice and exiting. I had no idea of the teams before the game, but I did like the Giants more - they just seemed to have more will and soul in their game. So I rooted for them since the 2nd quarter and it was very satisfying to see them win the game in the final seconds. Summary: good game, great final quarter, horrible coverage and crappy sideshows (adverts and halftime show).

Last night, after dropping a package from a control file, I was wondering why my package.install file for the remaining package seemed to be ignored (upstream installs a bunch of stuff that I don't want installed in the Debian package; the symptom was all that junk was making its way into the package). Turns out it comes down to the following logic in CDBS: i.e. if there is only one package, then by default install in debian/package. Therefore whatever make install does is what you end up with in your package. Although I can see the reasoning behind this, it wasn't what I wanted since I need the package installed into a temporary location (i.e. debian/tmp) which then uses a .install file to pull out only those files I want. The solution is simple, override DEB_DESTDIR to $(CURDIR)/debian/tmp/ in rules. I hope this saves someone the half hour or so I spent investigating why my install file was "corrupt"!

This year at Linux.Conf.Au there was a student party sponsored by Google. The party was held in a bar and lots of free drinks were provided. This was fine for the university students, but for school kids it was obviously lacking. Some people point out that it’s “quite legal” to run a party that excludes children, the point however is whether it’s desirable to exclude them. Also the concept of a state where laws dictate all aspects of your life to a degree such that obeying the law is the only possibility is fortunately restricted to science fiction. Another common fallacy is when people point out that we should be grateful for Google’s sponsorship. As far as I am aware Google doesn’t insist on any particular conditions for sponsoring a party. If the conference organisers were to request a party at a more child-friendly venue (for example a restaurant - which if licensed could serve alcohol to adults who desire it) then I doubt that Google would refuse. Being grateful for Google’s sponsorship is entirely unrelated to the issue of whether their sponsorship money was spent in the best possible manner. My interest in this topic started at LCA 2007 when I heard complaints from young delegates who were excluded from the Google party. This year the Google party (a different event from the “Google student party”) allowed everyone to attend and issued coloured wrist-bands to indicate whether the person had shown suitable ID to be served alcohol. The Google party was inviting for all and I believe that it was a significant improvement over last year (more attention was paid to serving food than alcohol). I have suggested that at future events some tables be reserved for people who aren’t drinking. As a general rule people enjoy being around people who have consumed a similar type and quantity of mind-altering substances (something I learned from my friends in Amsterdam). There is of course demand for serious drinking, and it seems impossible to satisfy people who want to do serious drinking at the same party as people who won’t or can’t drink at all. If there is not going to be an official party that is suitable for U18s then I’ll arrange it and pay for it myself. The consensus of opinion seems to be that less than six U18s are not worth catering for (one of the common objections to my suggestions is that there may be only four or five U18s). I can pay for a party for that many people which (in terms of food and non-alcoholic drinks) compares well with whatever Google might offer for the drinkers. The rough idea is that U18s will have free food and non-alcoholic drinks. The venue will be some suitable restaurant (is there a Pizza hut or similar near the next LCA?). The party will be open to parents and delegates who are >18 and don’t plan to drink (but I’m sorry I can’t afford to shout you). Opportunities to learn about cool Linux stuff will abound (I expect that a number of knowledgable Linux people who can teach some interesting things will be interested in attending). If I’m paying then children who aren’t delegates will also be welcome to attend, but their parents would have to pay for their food/drink. But this is merely a matter of budget, if it was to be an official event or there were other sponsors then this might not be the case. What I would like right now is expressions of interest from young people who plan to attend the conference and from parents (who plan to attend the conference or whose children will attend). If it looks like there will be a suitably large number of people interested in this then the conference organisers may decide to make it an official event. Also comments from adults who would prefer an alcohol free event (whether it be due to medical reasons, religion, or choice) would be of interest. It’s all about the number of people who will attend.

Share This

A person that I deeply respect and who is very know in Latvian IT society recently said that he often uses a quote of mine in his presentations. I completely forgot that I ever said that, but it sounds very much like what I would say, so I wanted to write it down so that I do not forget about it again:

90% of the people do not understand copyright, the other 10% simply ignore it.

Heh, I must have been optimistic. There is no way that so many people actually understand copyright. Note: most Debian Developers and FLOSS developers in general are an exception to this rule, but sadly comprise such a small percentage of the population that it means very little from a public policy perspective.

Due to the lack of entries so far I am amending the rules. It is no longer required that an entry be on the blog of the person who submitted it. Being on any blog that is aggregated by the conference Planet will do. This is known as a “guest post“. All it requires is that you email the post content to a blogger who you trust and they post it crediting you as the author. Guest posts are fairly common among serious bloggers, a google search will surely give more information.

Share This

As written earlier, I'm switching build system for one of my projects. In the end, I decided to roll my own. Yes, another build system out there. The general idea is to combine the strengths of automake and MSBuild, and take them to new extremes by not compromising where they have (that makes my build system a tad inflexible though). Automake's biggest strength is that it is descriptive, rather than imperative, and while it allows for rules to be entered directly to allow for some flexibility, this is usually the point where the Makefiles that are produced become unportable. But in general, the idea of having a tool deduce what exactly should be done to transform a set of input files into a set of output files is a good one, I think. From MSBuild, I stole the idea of making an explicit distinction between higher-level integration projects ("solutions" in their lingo) and actual build projects. Build projects only have one (main) output, which usually is a program or a library, and several auxiliary outputs (development files, translation templates, ...), while integration projects coordinate the build process (for example, if one of the build projects builds a tool, all projects using that need to be re-run if the tool is rebuilt, but only then. Automake's biggest downfall is stuff that is not explicitly supported. One of my projects uses IDL extensively, which leads to quite a lot of explicit rules supporting different ORBs. If I wanted to teach automake about that, I'd have to understand lots of perl code that emits code fragments that, when combined, will do the right thing. In a way, automake is a compiler, but based around the idea that since we start out from a Makefile compatible syntax, just adding things will magically work. Where it doesn't, special cases are invented, such as for libtool support, but stacking special cases is really difficult. MSBuild, on the other hand, leaves a lot to be desired when it comes to project-to-project integration. There is no way to tell it "publish these include files under the such-and-such directory for use by other projects", rather, you are expected to have the project using them explicitly reference your project in the include directories. If a project uses includes that reference includes from yet another project, it gets worse. Milestone 1 is going to be when the main binary can build itself on Windows and Linux.

The first of my talks at LCA 2008 gave me a chance to talk about the current state of the Debian project, which got me my first LWN.net coverage with a photo, even (subscribers only for now, the article will become public on 7 February). Thank you, Jonathan Corbet, for a very good article which nailed all the main points! Slides are here. I agreed to this talk on short notice because I like to talk about Debian and was honoured by the chance to represent the project in this form. I would not have been able to do it without plenty of helpful input from colleagues in the last few days. Since I didn t get a chance to display the final slide with the acknowledgements during the talk, I would herewith like to thank specifically Andreas Tille, Michael Banck, Kevin Mark, Josip Rodin, MJ Ray, Cyril Brulebois, Stefano Zacchiroli, Frans Pop, Moritz M hlenhoff, Russ Allbery, Steve Langasek, Luk Class, Andreas Schuldei, and Christian Perrier. No guarantees for the completeness of the list. The talk ended in an open discussion on how Debian could improve. I took notes and shall forward them to the project mailing list, once I get a chance. Thanks to all the participants, as well. Update: during the talk, I mentioned that there was no security support around the time of the etch release. Thanks to Moritz M hlenhoff, who spotted my error: that should have been sarge . The problems with security support had long been resolved by the time etch was being prepared, and this was in (large?) part thanks to Moritz. Sorry for the screwup! I also called Linux to tend towards multimedia more than one might like. I should not have made this comment as a representative of the Debian project, and I probably did unjust to the Linux kernel in whole. This is entirely a personal issue, I have a number of problems with Linux memory management, scheduling, and some other points relevant to production use. I ve had some of these problems for years, but they seem never to get fixed, while development is fast-paced. Then I look at some of the work being done and I wonder what the priorities are. Regardless, I should not have made this comment and I apologise for it.

Maybe someone can shed some light on these outstanding questions about airplane safety. The Thai steward earlier made it perfectly clear, with a straight face, that our safety is their priority, but so far, no-one of the crew could give me the answers:

• why do window shades have to be opened during take-off and landing?
• why do tables and leg rests have to be stowed away during take-off and landing?
• why can t I recline my seat during take-off and landing?
• why do they shut down the in-flight entertainment during take-off and landing and force you to watch advertisements and map views? Are those less likely to cause interference?

I ll stick to those airplane-specific ones for now. I have another set of questions about certain airport rules on the ground. I feel that the world would be a much better (and safer) place, if those making the rules would actually let us know what these rules are trying to accomplish. Update: I ve received plenty of responses. Thanks! Most responses explain questions 1-3 wit reference to the critical nature of take-off and landing. Leaving the windows open helps people orient themselves in case of an emergency and that people from the outside can get in at the right spot, tables and leg-rests are obstacles during an evacuation, and the seats are designed to absorb shocks, but won t work so well if they aren t upright. One person argued that entertainment during the critical phase of take-off and landing is distracting in case of a problem, but I am somewhat unconvinced. I have not received another I must say that none of these responses are surprises. I guess my main point is that airlines might want to consider making these things public, rather than just instructing people about the rules. It would make me happier to comply anyway.

Your new door to the world the slogan for Bangkok s new Suvarnabhumi airport tries to get people to stop-over on their trips between Europe and Asia. The airport s webpage claims that the airport currently handles 45 million passengers per year, but that it would scale up to 110 million. I don t see this happening, at all. Today, leaving for Melbourne, I waited for an hour in the security queue, as four flights were leaving concourse E (which has 10 gates) at once: around 500 passengers were queueing to be scrutinised for explosive liquids and other stuff a real terrorist would never consider smuggling on a plane via the standard passenger processing theatre in four lines behind four security checkpoints (in fact, that s how I confirmed my estimate: around 30 seconds per passenger (I timed it), it took me one hour, that s 120 passengers per queue, so about 500 total, at once). Four lines, one hour? 45 million passengers. 110 million passengers? Six lines (there isn t much more space), so 200 passengers per line, 1:40 hours? My new door to the world? Bangkok? Of course, this is in large part because of idiot passengers. While I was waiting in line, they came three times (every 20 minutes) to empty the garbage can where potential terrorists have to dump their drinkable explosive fluids. We ve had this ban for over 1 years, for crying out loud! Sure, some people don t (get to) fly a lot and a few may really not have heard about dangerous liquids yet (I felt really sorry for an elderly couple who had to ditch pretty much all their toiletries leaving Zurich for Madrid and wondering how they would survive there), but then at least open your eyes and turn on your brain, please. Unfortunately, the typical Bangkok/Southern Thailand tourist probably hasn t got brain cycles left between walking and carrying luggage. If you don t believe me, stop-over in Bangkok and look around: anything with legs in shorts and flip-flops probably fits right in, any obscenely and annoyingly loud group as well. For instance, this circus of 10 en route to London, who joined the end of the queue (read: about 1 hour to go) after their flight s final call with millions of shopping bags. They furiously tried to raise hell, but failed and probably missed their flight. Observing all such episodes around me made the hour go by fast I also had ample time left before my gate would close. There was one situation, however, that made walk over and complain to the supervisor (the one with the walkie-talkie): a couple from Canada were similarly faced with the final call for their flight to Toronto and walked straight up to the top of the lines outside the ropes. After a short discussion, one of the security attendants escorted them to the gate without subjecting either their bags or bodies to the ever-secure screening process. The supervisor (the one with the walkie-talkie) didn t speak English. All she did was smile and make motions with her hands which suggested that I should join the end of the queue. As I said before, I don t believe that the (minimal) added security we have at airports today corresponds to or justifies in the slightest bit the shit we have to go through these days to be airborne. However, if you make rules, then stick to them and don t open gaping (= inviting) security holes. Fortunately, the Canadians later had to surrender their weapons of plane destruction since, on every gate, another party of security attendants glove-hand-searched every bag a second time, with the previous security checkpoint no 100 metres behind. I don t see Suvarnabhumi as a successful or scalable airport. If Bangkok wasn t such a great place ?to kill a few hours (especially compared to e.g. Singapore), or the (best) entrance to Southeast Asia, I d probably avoid it in the future.

It's interesting to compare the "marketing features" of proprietary version control systems and the FOSS equivalents. For example, I happened to stumble across SourceGear Vault, and I have to say that the feature list, as given, doesn't impress me particularly. When the most impressive features you can think to mention are things like "All repository data is stored in a SQL Server database" and "the checkin operation is atomic", I'm thinking you're probably not a serious competitor against some of the truly state-of-the-art systems that are commonly used in the open source world. Based on the advertised features, I'd say that Vault probably doesn't compare favourably to SVN, let alone bzr or darcs. Overall, I don't think we're doing so badly in the innovation stakes. <grin>

Robert A. Heinlein: Starship Troopers (Putnam, 1959)
Paul Verhoeven (director): Starship Troopers (TriStar, 1997) The trouble with movies is that they fit only a short story. You can make a terrific movie out of a short story, but I have never seen a movie made of a novel that was at the same time good and faithful – most movies made of books fail in both. The novel Starship Troopers chronicles the evolution of a high-school kid into a mobile infantry officer in a world which had seen modern democracies fail and be replaced by a veterans’ rule (veterans of also noncombat and civilian service, not just military) – Juan Rico gets in just to impress a girl, and maybe to get to vote some day, goes through boot camp, makes combat drops from orbit as a private and then as a NCO, gets opted for officer training and by the end of the book is a competent officer, helping his old drill sergeant who had found the prize. Along the way we get political sermons (now I know where John Ringo got his tendency to have characters lecture on politics!), some interesting characters and just a hint of romance. The movie paints in broad strokes and primary colors. The first half of it is in fact a fairly decent redesign of the book as a movie, though I did not like at all how much in the face the romance (and two interconnected love triangles!) was played. Johnnie Rico gets in to impress a girl, goes through boot camp, makes some combat drops – And then it transforms into a horror movie (and loses any resemblance with the book). They make a combat drop, Lieutenant Rico drops his mission and goes rescue his girlfriend (the two triangles having been – eliminated by now) and totally misses his old drill sergeant finding the prize. Allegedly, the director never finished reading the book. Well, it shows. In the book, Rico would have been hanged by the neck until dead, dead, dead well before the end of the movie just for striking a superior officer; in the movie, everybody just shrugs it off. The book is an enjoyable military story, the founding father of a subgenre consisting of lots of newer books; the movie is just silly. If you have seen the movie, read the book. Don’t bother the other way around.

We have a problem with our tools in Debian, and it's this: Above the core tools in dpkg-dev, and the nearly core tools in debhelper and devscripts, and the many different -- but all slowly converging -- revision control systems, there is the potential for infinite cruft to pollute the source package. Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem. The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because

1. making the leap from a special-purpose, poorly-designed hack to a general-purpose tool is hard
2. getting the project to standardise on a tool is hard
3. a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with

So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument. Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on. Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them. At this point I see this as a huge, potentially killer problem, that is making Debian development become worse with every passing year. But I have no real solution. Obviously pointing out that tools are obsoleted or bad doesn't work; we still have dozens of packages using yada, which everyone agrees is horrible. That doesn't bode well, does it? One partial solution is to design a category killer, and get it embedded in acknowledged core tools. That's what I have tried, and so far, failed, to do with an evolutionary change to the Debian source package format, which I'd hope would give people a reason to stop using dpatch, dbs, and their ilk. As noted, this approach is Hard.

---

For now, I have no interest in being on a team that requires I use any of the following things:

• dpatch
• dbs
• quilt
• Any similar system that is used to move all patches to under the debian/ directory.
• Any system that nests the actual original upstream .tar.gz inside an .orig.tar.gz.
• yada
• cdbs
• Any similar system that obfuscates debian/rules.
• Any special script that is required to be used to build a package as a wrapper around dpkg-buildpackage.

This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.

---

PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different. PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)