On January 26th 2008, the OCaml community has its first meeting in Europe. There was 5 different talks, including one from me. The meeting was pretty constructive and i think some great things should come out of it. In this post, i will focus on the Debian maintainer point of view. The meeting was organized by me, with the help of Garbriel Kerneis and Vincent Balat. I wish to thank Mme Turgis from ENST/ParisTech who has made possible all this to happen. Introduction: I announce the creation of OCamlCore, a SS2L. It will provide commercial support for OCaml and related products. It will also provide community with some resources (including a GForge, a planet, some SCM repository...) For now, i will open administration to Debian people who wish to help (for root rights) and from the whole community for other task (gforge and general administration). For now, i will choose alone who can administrate and who cannot... This is not a very open position, but this server is also for my company. Xavier Leroy give us a nice talk that has let us see some future direction:

• OCaml 3.11 will have native dynlink
• hope to integrate GHC like type system (GADT: Generalized Algebraic Data Types)
• need to work on parallelism, following different paradigm

But above all, Xavier talked about the fact that there is a lack of manpower at INRIA and invited the community to build tools and other things (including a CPAN like distribution) to make the language more widespread. He also stated that a lot of things will stay in place in the name of backward compatibility. OCsigen Vincent Balat has given us a nice talk about OCsigen, a new framework for programming web application. This program is already in Debian and it is at the root of Debian discussion about moving .cm[ao] into libxxx-ocaml package. This new framework allows to program web application using continuation, which should ease a lot of aspect. It also features static type checking, including static verification of the generated HTML pages. GODI I was impressed to see G. Stolpmann coming to the meeting. Unfortunately, i cannot follow the whole talk, since i have some phone call to make, in order to book the restaurant. From what i have seen, it seems that GODI is growing, in term of manpower. They have some issues with OCaml 3.10, because of camlp4 and some packages. At the end of the conference, he was pushing for a more general use of GODIVA. In particular, it requires to have a very uniform way of building software. It should be the foundation of a build standard for OCaml software. In my humble opinion, i don't agree on this point. Basically, its proposal was based on configure/make all, which is too C style way of doing. It is not bad, but just exclude ocamlbuild enabled software. ocamlbuild Nicolas Pouillard has made an introduction on how to use ocamlbuild. I have discovered how it was working, since i didn't have time to work on this topic. It seems a good thing. I hope to be able to try it at some point. The conclusion was about modifying ocamlbuild to allow the use of multiple plugins. For now, the plugin is a separate file which is compiled first and then loaded, as a special case. Nicolas is looking for a full OCaml way to handle this for multiple plugins. OCaml in Debian I have spoken about different aspect of Debian packaging. After a short introduction and some history about OCaml in Debian, I come to some conclusions/problems:

• we have an early integration, which makes Debian handle a lot of packages, but this is due to a long history
• we still are not able to cope with libraries incompatibilities when rebuilding, we only have addressed ocaml package ABI problem
• the debian package management system is not really compliant with the OCaml way of creating libraries, which is our main problem
• native compilation is broken on 3 arches (Xavier Leroy told us that this should be solved for ARM)
• use of Alioth has made us more efficient to integrate packages
• Debian team are working by step: from time to time we begin to integrate a lot of packages, mostly because of some maintainers wishing to integrate a software with a lot of dependencies

Talking with Xavier give me some additional informations:

• ARM is fixed, it should compile with Debian stable on ARM, he explains that the problem is related to the multi ABI flavor of ARM
• he says that we should not have any problem concerning bytecode stripping of executable, if there is still some we should find the OCaml library that triggers this behavior
• I realize that this behavior can be triggered by ocamlmakefile, that still have a "-custom" option
• he promises me that he will send me a simple test to find custom bytecode application (combination of "file X" and a specific string at the end of the file)

At the end of the presentation, there were some questions. I discover that many people are ignoring the ABI problem with OCaml and its libraries. They seem to discover that it requires regular rebuild of our packages. I also have a discussion about the fact that Debian binary distribution doesn't fit developers need. It seems that developers prefer to have the source of libraries they compile and also the most recent release. But at the same time, people avoid using GODI, which also have the problem of needing to wait for a particular library to be released... After some discussion, I point that some companies prefer to live in a frozen world, which Debian stable can provide. Living in a frozen world helps company developers to have the same environment from the beginning to the end of a project - which can last years. It also help to avoid build environment de-synchronization between company developers. There was also a question about interaction between installed OCaml package and GODI software. I cannot answer it, expect with a "patches are welcome". OCaml on a JVM using OCaml-Java Xavier Clerc explained us how he has achieved running a full OCaml environment on a JVM. This work was pretty impressive, because he was able to compile OCaml top level and provide it as an applet. This is something amazing (and working). He stated also that this should allow to do some binding with java graphical user interface from OCaml. I was pretty busy with a phone call (to a restaurant for the dinner), so i don't have attend the whole conference. Anyway, the project is promising, but it needs to recompile every library using its compiler. I think this is not suited for Debian for now. Workshop The workshop was shorter than it should have been. This is due to accumulated time shift during the day. However, it was pretty interesting, because everybody can talked almost freely. The initial discussion was about the "Unicode situation". This was a question about Unicode in Unison, but there is no real solution about it. For reader information, unison has problem with filename containing UTF-8 char. In particular when syncing two directories which are on two file system with a different encoding on each. Even if the file can be represented on the two file systems, the comparison (between UTF-8 and ISO8859-15) fails. This is because the comparison is a byte to byte comparison. We discuss further the idea of OSR (OCaml standard recommendation) which was briefly discussed in the morning. I think David Teller (who have also done a great part of the IRC retranscription) was very keen on this idea. I invited Nicolas Pouillard to discuss the three following subjects. About camlp4 documentation, Nicolas told people about the he set up. About ocamlfind and ocamlbuild, he went back to the multiple plugin problems. About ocamlbuild and GODI, Gerd, Nicolas and Xavier tried to build a list of what metadata can be shared. This includes list of files to be installed (PLIST in GODI). Concerning the "feedback from the Gallium", Xavier explains that he has done this in the morning (which is true). I think that Xavier implicitly agreed on the fact that if this kind of event happens again, he can do another talk about future of OCaml. Concerning Summer of Code, I just remind that people can write description of Google Summer of Code project in the cocan wiki. Another one remind about Jane St Capital summer of code. Points concerning common interfaces raise the discussion about OSR. The organization of next year events doesn't raise particular interest. I think people would be interested to have one next year, if something comes out of this meeting.

It’s probably impossible to get too much of Bruce Schneier, although I honestly wouldn’t mind if he stopped Friday Squid Blogging. His latest Wired.com article on the false dichotomy between security and privacy is an excellent counterpoint to a recent Lawrence Wright profile in the New Yorker on Director of National Intelligence Mike McConnell. The Lawrence Wright article was surprisingly uncritical, considering the New Yorker’s usual zealous approach. Check out, for example, his description of the “Clipper” chip:

In the nineties, new encryption software that could protect telephone conversations, faxes, and e-mails from unwarranted monitoring was coming on the market, but the programs could also block entirely legal efforts to eavesdrop on criminals or potential terrorists. Under McConnell s direction, the N.S.A. developed a sophisticated device, the Clipper Chip, with a superior ability to encrypt any electronic transmission; it also allowed law-enforcement officials, given the proper authority, to decipher and eavesdrop on the encrypted communications of others. Privacy advocates criticized the device, though, and the Clipper was abandoned by 1996. They convinced the folks on the Hill that they couldn t trust the government to do what it said it was going to do, Richard Wilhelm, who was in charge of information warfare under McConnell, says.

(emphasis added). Compare, for example, EPIC’s Clipper Chip information page. Schneier, by contrast, sees right through the core:

We’ve been told we have to trade off security and privacy so often — in debates on security versus privacy, writing contests, polls, reasoned essays and political rhetoric — that most of us don’t even question the fundamental dichotomy. But it’s a false one. Security and privacy are not opposite ends of a seesaw; you don’t have to accept less of one to get more of the other. Think of a door lock, a burglar alarm and a tall fence. Think of guns, anti-counterfeiting measures on currency and that dumb liquid ban at airports. Security affects privacy only when it’s based on identity, and there are limitations to that sort of approach. Since 9/11, approximately three things have potentially improved airline security: reinforcing the cockpit doors, passengers realizing they have to fight back and — possibly — sky marshals. Everything else — all the security measures that affect privacy — is just security theater and a waste of effort. By the same token, many of the anti-privacy “security” measures we’re seeing — national ID cards, warrantless eavesdropping, massive data mining and so on — do little to improve, and in some cases harm, security. And government claims of their success are either wrong, or against fake threats. The debate isn’t security versus privacy. It’s liberty versus control.

Read the whole essay. And send it to your mother, as well. Technorati Tags: Schneier, Privacy, Security

Share This

I live in a cooperative living group, and during the fall semester a person who we’d invited to live with us who is a dwarf and relies on a scooter for most of his transportation decided he’d like to move in. Unfortunately, while he can get out of his scooter and come inside by himself, we had no stepless entrances such that he could bring his scooter inside to protect it from the angry Cambridge winter. Mmm, frozen batteries. So, we’re a coop and we maintain the house ourselves—so we decided to build one, of course. A ramp up to the back porch! Nevermind the fact that we need to sink four-foot foundation holes in the ground in January. We got started right away at the beginning of IAP, while people were still trickling back into town from all over the country. First we surveyed out where the posts should be sunk: Then it was time for excavating the holes where concrete would eventually be poured. This involved a power auger of DOOM: It’s advertised as a 2-man tool. Two 200-pound construction workers, that is. We had to put four people on it plus one person with a shovel clearing dirt to make it manageable, and even then it was a pain. There’s a delicate rhythm you have to get into to avoid getting the bit stuck—DOWN. UP. CLEAR. And inevitably there are rocks and roots that have to be dealt with. We lucked out with a fairly warm weekend to do the digging on, but on the first day we still had to deal with a couple inches of frozen ground: There was also some fun stuff involving having to clear away our (frozen) mulch containers and use a concrete cutter on a weird old concrete pathway that used to run through the same area: Next we mixed and poured concrete: And placed hardware in the concrete to hold the posts: Framing: Eventually it became functional, woo: And done! (except for metal handrail): This all took place over the course of about three weeks. And now our scooter-bound housemate can bring his wheels inside! The house still isn’t totally accessible to wheelchairs/scooters, but at least the first floor is. It really brings me pride to see things like this go from start to finish here. We can do it! This guy who is moving in has really influenced my life—he’s really good at making people feel comfortable talking to him, and for me it’s gone from “wow this is awkward, I have no idea what to say” to “talking to a person with different physical abilities and characteristics seems normal”. And that’s made me a better person.

Tomorrow (January 28th), I'll be in Munich for this: http://www.mobile-monday.de/web/guest/android Unfortunately, the event filled up super fast and I barely managed to squeeze in, so there are probably no spaces left. Still, if anyone would like to meet up afterwards, send me an email soonish. If you managed to get in, and would like to see a demo of Hecl, let me know, because I'd like to have the chance to show that off some too! Hopefully it will be a valuable experience. Android is a pretty convincing system in many ways, but of course has yet to fully come into contact with reality, so I'm curious to meet some of the people involved and hear about it from them. I really hope it doesn't end up being a rehash of information that's available on the web, as it's a two hour drive from Innsbruck.

Thanks to those 2 comments. Although placing Xft.dpi: 96 in my ~/.Xdefaults did not help, but I managed to do it through the appearance control center applet. I had to purge the gtk-qt theme engine because it was freezing the dialog and setting it via gconf-editor didn't work as expected.

I had to fight with my fonts this morning but here's my configuration. Maybe it'll be useful to anyone:
DejaVu sans book 12
96 DPI
greyscale smoothing, subpixel slight RGB.

I'm not yet satisfied but it's more usable now.

Thanks Phaeronix for the help too. read more

According to a notification of trade on the Oslo B rs market, Nokia has made an offer for Trolltech of about 843 million Norwegian kroner , around 104 million. What this could mean for GTK+ is anyone’s guess. I’d expect at least that Nokia’s competitors that use Qtopia (like Motorola, Panasonic and Sony) are probably a little worried at the moment. Maybe there’ll be impetus for OSSO to move over to Qt, or maybe there’ll be internal competion at Nokia between a Qtopia stack and a GTK+/X11/Freedesktop stack. Maybe Qt will become more closed as Nokias pushes its advantage, or maybe it’ll be more open as development becomes less dependant on non-GPL license revenues, or maybe it’ll just stay the same. An interesting left-field move in this space is OpenMoko moving over to EFL, but on a primarily GNOME/Freedesktop stack. EFL is certainly much more capable than GTK+ in producing flashy UI’s on limited hardware. I”ve also heard of some companies writing UI’s in Flash using Gnash. I also wouldn’t be suprised if we start seeing embedded hardware running Mono and Moonlight at some point. Maybe one day we’ll have a GTK3 with DOM-like two pass event system and a cairo backend that renders totally on the GPU. One thing’s for certain, there’s a hell of a lot of competition on the toolkit front and it will only grow.

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.

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.

Russel blogs about write intent bitmaps, which are an option in the Linux Software RAID subsystem, which works somewhat like a journal on the RAID level: every time you write to the array, you first mark the bits you're going to write to as dirty, then write them, and then mark them as clean again. This allows the RAID subsystem to have to check much less in case of a system crash, where normally the system would have to run a full array rebuild. He'd suggested this before on the debian-boot mailinglist, and when I read that post, it seemed to make sense. However, after reading his blog post, I'm not so sure anymore. In his words:

The down-side to this feature is that it will slightly reduce performance. But when comparing the possibility of a few percent performance loss all the time and the possibility of a massive performance loss for an hour or two after a crash it seems that losing a few percent all the time is almost always the desired option.

I vehemently disagree there. Performance is irrelevant in case you have a large server park; in that case, adding another server to the park is relatively cheap—you don't run hundreds of servers on a small budget, and besides in these days of virtualization, often migrating a service from one physical server to another isn't very hard. However, this isn't true when you're talking about small businesses, or (especially) home servers. When I have a choice between high loss of performance in case of something which happens only rarely (in my experience, the Software RAID subsystem is pretty good in recovering from a power loss without having to go through the RAID rebuild, leaving only kernel crashes and similar) or a small but continuous performance loss on my home server, there is no doubt in my mind that I will choose the former. First, my home server is a Thecus N2100, which, while powerful enough to run a number of services for my home network, is not a very fast system with somewhat low resources in comparison to some other systems; and even a small loss of performance is probably noticeable. Second, the speed of recovery which the RAID subsystem uses (and, hence, its performance impact) is manageable through the files /proc/sys/dev/raid/speed_limit_max and /proc/sys/dev/raid/speed_limit_min. Obviously lowering the speed of the RAID rebuild will make the process take longer; but if performance matters that much to you, then lowering the rebuild speed can be an option. Finally, sometimes the RAID subsystem chooses to go through a lengthy check of the entire array; it would be interesting to know whether using the write intent bitmap feature disables this too. I suspect this is not the case, and if so it would seem as if enabling this feature would cost some performance for little benefit: in normal situations these checks happen far more often than actual RAID rebuilds; so the most important source of performance loss would not be handled at the cost of extra performance loss. In closing, I guess the right answer to this question is that it's a trade-off; that choosing the right defaults should be done by upstream (to avoid confusion), and that the user should be given the possibility (somehow) of enabling or disabling this option in defiance of the defaults at install time (perhaps only in d-i's expert mode)

This weekend has been an interesting mix of activities. Mostly I've been tweaking my mail filtering service now that it has more users it is more interesting to do that. The basic process of mail-scanning is pretty simple, but there are some fun things in the mix which make it slightly more fiddly than I'd like. The basic recipe goes something like this:

• Accept mail.
• Validate the mail is addressed to a domain hosted upon the machine.
• Do the spam filtering / magic (many steps missing here)
  • If the mail should be rejected archive it to a local Maildir folder and bounce it.
  • If the mail should be accepted then forward it to the destination machine.

The archiving of all rejected messages is a big win. It means that if there is a mistake in the handling of any mail we could undo it, retraining the spam database etc. It also provides, via a web page/rss feed, a way for a user to see what a good job the filtering system is doing - by saying "Here's what you would have had ..". Today I switched the way that the archived mail is displayed via the Web GUI. Previously I used some nasty Maildir parsing code, but now I'm running IMAP upon localhost - so the viewing of messages is a lot more straightforward. (via Net::IMAP::Simple.) More interestingly, to most readers I'm sure, today I managed to take a new Kite out for flying. A cold and windy day, but lots of fun. There was beer, pies, and near-death! This was also the second weekend I carried out some painting of my front room. At this rate I'll have painted all four walls of the room in less than two months! (The last time I painted a room it took approximately six months to complete. Move furnuture & paint one wall. Wait several weeks, then repeat until all walls are complete!)

After a few amazingly efficient days at home, working on netconf (but not getting to where I wanted) and preparing the presentation I deliver on Thursday at LCA 2008, and tying up other loose ends, I found myself in front of a television set Friday morning to witness the beginning of Federer s defeat in the Australian Open half finals. Unfortunately, I had to leave at the start of the third set and no-one in the airport knew of the game, so I had to call a friend from the plane to get the final result: 7:5, 6:3, 7:6, Djokovic won. I like Federer, and enjoy the Swiss fandom from everywhere, but his tennis wasn t up to his normal level, a true shame. Djokovic has been my favourite for about a year now, so I am excited by the result, but it would have been better to see a bit more of a battle between the two. I trust he ll win on Sunday and cross my fingers! It kind of bites to arrive in Melbourne on the day of the finals, knowing that I would have had a chance to get a ticket and could have travelled a day earlier. Oh well So I am sitting here in a crap Bangkok Internet cafe, finishing off my presentations. In addition to the netconf talk, I am also talking twice at the Debian Miniconf on Monday: first, the State of the Debian project address , which I agreed to do very short notice but knew that I could count on my colleagues to help (don t read the thread before the talk ); second, I also have a slot to talk about version control systems and Debian packaging, a topic that has been on my mind for almost three years now, resulting in elaborate workflows and many discussions. It s also becoming more and more of a hot topic for the entire project. I am tired. We landed at 5:30 and I was shattered, not having been able to shut an eye throughout the ten hours of flight. Fortunately, they let me into the lounge in the arrival area, where I crashed in one of their slumber rooms and got close to four hours of sleep, successfully ignoring the chatter from outside why did Thai Airways lay out their lounge in such a way that the slumber rooms are right next to the staff rooms with the squeaky doors? One thing about living in Asia, where space is scarce, is that people here never seem to mind about noise and sleep through anything. So I did too. I took a shower, ate some breakfast and headed into the city. I was impressed by the new Bangkok airport Suvarnabhumi , which definitely is a step up from the old, horrific one. However, I tend to doubt their claim that they could scale from the current 45 million passengers per year to 110 million. The walkways are too narrow, there are way too few toilets around, and immigration is painfully slow despite the large number of open alleys. Now in downtown Bangkok, I am biding my time. I have been here a few times before and have a number of routine stops, such as visiting the retail manager of the Jim Thompson Company, a loveable lady who speaks fluent English and is very fun to talk to. I met her during my last trip to Southeast Asia, but have since not been in touch. I now plan to head to a massage place, where they deliver merciless (and thus excellent) Thai massages, and then on to some market or Chinatown for food. I ve been training myself on chili ( Thai chocolate ) consumption for this moment: to walk up to a food stall, order a curry, and answer Thai hot when they ask for the degree of spicyness, given that I m a foreigner. At midnight, my plane leaves for Melbourne to arrive on Sunday afternoon. I have little clue as to what awaits me. I ve been to quite a number of conferences, but always perceived LCA to be somewhat special. I am definitely looking forward!

Firstly, I haven't been following debian-devel as closely as in recent months and some things have passed me by. Secondly, I am rather pre-occupied with my own small world of Embedded Debian. One result of this is that I wasn't really paying attention to arguments over the source package format and took longer than I expected to respond to a request to take a look at tslib - a touchscreen library for embedded devices. When I did start work on it I managed to upset Joey Hess by implementing dpatch support which he had recently decried as unhelpful. I also added some extra fuel by getting myself in a two-and-eight over svn-buildpackage and it's broken bias towards native packages.
I happen to disagree with the idea that maintainers should alter upstream files directly, merely relying on the .diff.gz or some weird $RCS runes. Instead, I seek to ensure that the .diff.gz contains no changes outside the debian/ directory. I'm not happy keeping the entire upstream source in yet another RCS (for any reason) and would much rather make updates to my Debian packages by simply copying the debian/ contents into an unpacked pristine upstream source (preferably via uscan). I find it really useful to simply check out the latest CVS/SVN/$RCS, dump debian/ into place and call 'debuild' when testing various upstream development issues. Maybe this is because I have relatively few Debian packages that need debian/patches/* and certainly few that need more than a couple of patch files. It certainly has a lot to do with my embedded work where I need to make changes to the contents of debian/ to make an Emdebian package whilst retaining the same upstream code as is used in existing embedded projects like Open Embedded and Familiar. I don't want to be chasing changes through the upstream source - I want all the changes in a single place so that I can create Emdebian patches against the Debian source. (I'd rather not have patches in the Debian source at all but this is only realistic for either my own packages or those released as part of GPE for various embedded-native compatibility reasons.) I certainly do not want any Debian $RCS to be lumbered with yet another set of upstream sources that will always be out of date compared to the real upstream sources.
I am also a great fan of CDBS - much to the horror of some in Debian - primarily for one very simple reason, it cross builds so easily. Considering my workload, it should not be a surprise that the ability to support cross building without requiring any changes to the Debian package is incredibly persuasive when selecting a build system for a package of my own. debhelper really is woeful at cross building - each package needs customised cross building support painstakingly devised and tested, making script-based mass bug filing impossible. CDBS shows that with a little wrapping, debhelper can support cross building in a clean and completely non-intrusive manner.
This means I can concentrate on those changes that are actually important - the changes that provide the benefits of cross-building and justify the effort of actually cross building the entire dependency chain: the ability to fully control Debian-specifics like "Essential: yes" and to disable, modify or adapt components of any package such that the installed system has a fraction of the dependencies of the Debian version of precisely the same package. TDeb support is good too but that can be implemented against any build, it doesn't need to be a cross build.
Sadly, the end result of all this for tslib is that it will be removed from collab-maint very soon, Joey does not wish to be associated with the new version because although it includes some features which he is happy to see implemented, my use of dpatch and the hacks I had to devise to workaround svn-buildpackage do not fit with his workload patterns. Once tslib is removed from collab-maint, these hacks become redundant and I can use my normal packaging methods. Equally, his methods (in particular the lack of debian/patches/*) do not fit with my workload patterns and although I do not have as many packages as Joey, I have enough (when the 200 Emdebian source packages are also considered) to make the issue into a blocker. The new version of tslib uses the upstream SONAME and adds a -dbg package so it will spend some time in NEW. I am also likely to migrate it to CDBS once removed from collab-maint.
I suspect these issues will be revisited during discussions at Fosdem 2008 where I'll be presenting two talks - one in the Debian developer room and one in the Embedded developer room. Feel free to harangue me if you feel strongly that there is a sane way of cross building that does a better job than CDBS.

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.

This week has mostly involved me getting my live mail filtering site up and running with a guineapig or two. This uses a custom user interface to allow users to manage the filtering settings for an entire domain:

• spam filtering.
• virus scanning.
• greylisting.
• sender/recipient whitelisting.
• DNS-based blacklists

In terms of implementation this is an SMTP proxy which is built upon the qpsmtpd framework. I've got both the user interface and a collection of plugins reading all data from an MySQL database. The practical upshot is that if you use the service you'll get less spam, and anything that has been rejected will appear in an online browsable quarantine for a period of times allowing you to view mistakes/rejected mails. Any mail you didn't want, providing you've got the spam-filtering plugin enabled for your domain, you may send back to be trained as spam. It scales nicely, doesn't appear to have lost any mail ever in real-world testing, and could be useful.

Anyone who knows me, even remotely, knows that I have a huge beef with the American health insurance industry, which was greatly magnified after my own unpleasant run-ins with them over the course of the last two years. But of course while the insurance industry is certainly a ruthless predator and thus deserving much of the blame, they are not the sole culprit in sustaining what is a lousy health care system for Americans. A key player, I think, are American doctors, and I would now like to spread that beef patty of disgust to them, especially since they are now the one’s giving me problems dealing with the final portion of BCBS bill. The story is indicative of lager issues and problems that center on the problematic silence “spoken” by doctors. To make a long story short, BCBS of NJ was not ponying up some serious cash (at least for me) for 2 mole surgeries because they were claiming it was pre-existing condition. After having the public relations director email me (thanks to that post) and a lot of research and letters etc, it was more or less resolved. Soon after they overturned the pre-existing “bs” (and I am not talking blue shield here), they promptly started to pay all sorts of bills (and I even got money back from doctors I had paid). But there is one pesky $1600 bill that lingers like a bad smell and the question is why? I am not entirely sure but my interactions with my ex-dermatologists, Affilated Dermatology in NJ, I think reveal some important lessons as to why and how the medical establishment are complicit. Basically, BCBS is telling me that it looks like they have been double billed because the cost is exactly the same for two procedures that are also exactly the same. I explained that I had did indeed have two surgeries on my scalp (they were really close to each other) and they let me know that the provider needs to call back and send information that clearly shows there were two surgeries. This actually seems somewhat legitimate and potential mistake (and it is not like medical billing is known for their lack of mistakes and integrity either). So I call Affiliated Dermatology and while I would say they have been patient, in so far as patiently waiting for my money, they have been completely unhelpful in any meaningful sense to help me getting this resolved. Now, given how difficult it is to deal with the health insurance industry, I understand they can’t provide fine-tuned, fine-grained personal attention. The health insurance industry engages in some real hefty politics of foot dragging and well, there are so many foot soldiers at doctor’s offices to keep up with the web of knots that the health insurance constantly entangles us in. With that caveat in place, they can however do two things: 1. Inform you that you can contact the Department of Housing and Insurance and start some sort of formal complain process. 2. Give you some small clue as to whether the doctor has sent any of the additional requested information (they are usually mum, or enigmatic, or totally confusing with regards to that) so you know what the heck is going on. So a few days ago when I was speaking with health insurance person at the dermatology office, she claimed there was nothing else she could do about this last bill. Every time she calls BCBS, she claims that they claim it is a problem with being a pre-existing condition, and I was like “how can that be when that has been cleared and every other bill, and there were many, has been paid?” And then she also said that there has never been this confusion before where 2 surgeries look like one, blah blah and blah (and in retrospect, I forgot to tell her that my double surgery, according to the doc, was in fact highly unusual, because they would usually do them on two separate days because they were so close to each other. They made an exception because I was literally on my way to Canada and begged them to do so but anyway). Ok, so there I was bickering with this woman and feeling stuck between a rock and a hard place. Finally I let her know, point blank, that they have been remarkably patient with the billing but totally unhelpful in, well, helping me out. I let her know that they should let people like me know, for example, that they can file a formal complaint against the health insurance company and this would at least get the ball rolling. I then let her know that I had no other option but to file another complaint with the Dept of Banking and Insurance and they would just have to wait for that, at which point, she all of a sudden became more helpful. She suggested that we can do a three way call to resolve this. Well there you go. Why did it take a heated 15 minute conversation topped with a threat to get what I think actually makes perfect sense? Get the 3 parties involved on the phone with each other so as to all get on the same damn page about what needs to be done (not sure if BCBS will agree to this… at which point I will pester the public relations director again and in the end, I think this was resolved because he was sick of my emails). Now, why why why why why why are doctors and their staff so unhelpful? I think that main answer is they are overwhelmed and don’t have the staff to deal with the enormous amount of foot dragging and coy tactics deployed by the health insurance. That said, there are 2 things worth mentioning that I think don’t paint a very flattering picture of many American doctors. If you pay attention to your medical bills (and you always should), it is immediately evident that the doctors and hospitals get paid LESS, sometimes a lot less, if the health insurance company foots the bill because of the pre-arranged negotiated rate. So there is an actual incentive on that side of things to get paid via the consumer as opposed to the health insurance company. Now. I am sure that there are health care economic studies and reports justifying this strangeness but that does not make it right either. There is a clear incentive in place to get your green dollars, as opposed to those of the insurance company. Second and this is a much bigger issue, is that I think that for any meaningful change to happen, we need the active support of a large percentage of the medical community, especially doctors. If they are mum, or actively opposed to health care reform (as was the case when the AMA helped derail the Clinton effort at instituting universal health care in the 1990s), well then it becomes all that much harder for the general populace and the politicians to initiate real change. Doctors are the ones, after all, with the moral weight and capacity to make claims that can STICK. If they are saying this system negatively impacts how we care for the ill, it is a system that is is immoral, well, one should listen to them as they are the ones, after all, who dedicated their LIFE to healing the ill, right? Yes? No? Maybe? So their silence is nothing short of grave. The good news is that it seems like more doctors are on board than ever before clamoring for change in the right direction, but we need a lot more to come aboard… A number of years ago, I wanted to write a controversial and critical article that claimed hackers are more ethical than doctors. I thought it would be fun to claim that those who are usually seen as ethical (doctors) are less so than those that are usually portrayed as bad-as* unethical tricksters. Some people were offended by this because doctors deal with the great burden of life, death, sickness, and thus suffering while geeks and hackers are “just” geeking out on their computers. True. But at least a cadre of hackers have sustained a social realm and a real ethics–free software–in order to guarantee their own autonomy and also create the conditions for what is right for software. Doctors, on the other hand, do not carry the torch of ethics as they should. While individually I am sure they deal with a oodles of difficult ethical choices and decisions, it is about time they they turn as a collective to the larger structural conditions that seriously cause a lot of harm to millions of Americans, especially the droves of uninsured. They have the moral weight to do something about it and it is about time they carry their weight in this battle and take some burden of suffering off others.

Zack's pam-hooks module got me thinking that the whole "start stuff at user login/logout" thing should be simplified a huge lot. Currently, there are just too many mechanisms depending on the user's shell, ?dm, distribution, session manager/desktop environment etc. Should this be a topic for the freedesktop.org people (or is it already - it might fit into Portland in some way)? A standardized way to hook into session setup/teardown might also be good for security: if there's only few ways to get stuff started at login, that means fewer places to look where malware could be hiding. Of course, it also means that said malware can spread more easily, being more independent of the user's desktop environment.

It seems to me that the Asus EeePC (a $AU499 ultra-light laptop with only flash storage) would make a decent router. Often full desktop PCs are used as routers because they run the most common software and have standard interfaces. There have been dedicated router devices with flash for a long time, but without the ability to connect a standard monitor and keyboard they were always more difficult to manage than general purpose PCs. Also dedicated routers have limited RAM and storage which often does not permit running a standard OS. According to the best review I could find [1] EeePC has a minimum of 256M of RAM, a Celeron-M CPU (32bit Intel), and a minimum of 2G of flash storage. This hardware is more than adequate to run most server software that you might want to run (my current router/firewall/server has 192M of RAM). It could run a web server, a mail server, or any other general server stuff. It comes pre-loaded with a modified version of Debian so you get all the Debian software (which incidentally means more pre-packaged software than is available for any other distribution). Bigger versions are common, I believe that the $AU499 version has 512M of RAM and 4G of flash - I’m not sure that I could even obtain a lesser EeePC in Australia. The up-side of flash is that it doesn’t take much power as having a low power device in whatever confined space ends up housing your router is a good thing (the EeePC is listed as using less than 20W no matter what the load and idling at as little as 14W) and that it doesn’t tend to break when dropped or have any moving parts to wear out. The down-side of flash is that a sufficient number of writes will destroy it. Obviously swap is not a suitable use for a flash storage device. But a small mail server (suitable for the needs of a home or a small office) should be fine with it. Squid is commonly run on router devices, to run it on an EeePC I would be inclined to buy 1G USB flash device for the cache, then if Squid’s use destroyed the flash storage it would be easy to spend $20 and buy another. The EeePC has three USB ports and a built-in Ethernet port. I believe that the minimum number of Ethernet ports for a firewall is three, this means either one for the uplink, one for the DMZ, and one for your LAN, or two for uplinks (with a redundant uplink) and one for the LAN. The three USB ports allow using two USB Ethernet devices to provide the minimum three Ethernet ports and one for USB flash storage. One notable advantage of using a laptop as a server is the built-in UPS (the laptop battery). Many people have put old laptops into service as servers for this reason, but usually an old battery gives no more than about 30 minutes of power, while a new EeePC should be able to last for more than 3 hours without mains power. Using a second-hand laptop as a server is usually not viable in a corporate environment as laptops are all different. Repairing an old desktop PC is easy, repairing an old laptop is unreasonably difficult and often more expensive than replacing it. The low price of the EeePC makes it easily affordable (cheaper than some of the desktop machines that might be used for such a purpose) and the fact that it is purchased new at such a price means that you get warranty support etc. It seems to me that a significant disadvantage of using an EeePC (or anything other than a real server) for a server task is that it lacks ECC RAM [2], but as I’m not aware of any device sold for the purpose of running as a low-end router or sold at a price-point such that it could be used as a low-end router which has ECC RAM I guess that’s not a big disadvantage for that purpose. But the lack of ECC RAM and the lack of useful support for RAID does make it a little less suitable for use as a mail server. Finally if you are going to run a VPN then it would be handy to be able to secure the hardware against malicious activity when the office is closed. An EeePC will fit nicely in most safes… Please let me know what you think about this idea. I’ll probably start installing some such machines for clients in the near future if ASUS can keep up with the demand.

• [1] http://www.hothardware.com/articles/Asus_Eee_PC_Full_Retail_Review_Showcase/?page=1


• [2] http://etbe.coker.com.au/2007/07/15/desktop-machines-and-ecc-ram/

Share This