It’s been over a year now since my last proper upload to Debian, and nine months since I announced my intent to put aside working on Debian for a while. With Matthew Garrett’s resignation from Debian, several people have compared it to my own “resignation” from Debian. It has got my thinking about whether I currently intend to ever end my “Sabbatical” and return as an active Debian Developer. I think that the end of my love-affair with Debian started at Debconf last year where several developers treated those of us who also worked on Ubuntu quite rudely. Someone was attacked for wearing an Ubuntu t-shirt at the conference, while someone else was applauded for wearing a “Fuck Ubuntu” t-shirt. That’s where I realised that maybe I didn’t have as much in common with these people as I thought I did. I still don’t understand why Debian singles Ubuntu out for this kind of treatment, we’re still the only derviative distribution that makes all of our patches to Debian available, yet Ubuntu is claimed to not do anything at all. Another example is that Ubuntu is being asked to change the Maintainer field of every package, something no other derivative is being asked to do or has ever been asked to do. Martin Krafft has had some interesting things to say about this strange relationship in the past. If that was the start of my falling out with Debian, I think that Debian considering removing documentation and firmware from the distribution, especially the documentation, was another point I started wondering whether I shared anything in common with the project anymore. Call me strange, but I think that one of the fundamental purposes of a Linux distribution is to be useful to its users. If nobody can use the distribution because it doesn’t support their hardware, and even if it did, all the documentation has been stripped out; I started to wonder what it’s aims are. It became increasingly apparent that the only users Debian was considering a priority were its own developer. And the third thing is simply a matter of Fun. Fun for me, at the moment at least, has been to build a system that fits together extremely nicely with each component doing the right thing. For Ubuntu this has meant being a driving force for it being Linux 2.6 only, with reliance on udev for hardware, etc. Upstart is just a continuation of these goals, getting a system which all “just works”, even if it means throwing out a few things people were previously fond of. All of these things would have been impossible to do in Debian itself. Getting upstart installable required changes to twelve different packages, including sysvinit itself; at a worst case, this would have required the agreement of twelve different maintainers in Debian. It’s often exhausting just persuading one of the reason for the change, persuading a dozen would have been a herculian effort. Perhaps Matthew is right, what Debian lacks is a single leadership. There’s nobody in Debian I could have gone to for approval over the changes I wanted to make, whose decision developers cannot overrule. Ubuntu has such people (the Technical Board and sabdfl), which gives the project an obvious direction instead of a couple of hundred people all pulling in different directions. In a way, I don’t feel that I’ve left Debian. I feel like I was happily going along, only to realise the mob had gone in a different direction and with no easy way of rejoining the group.

Here at Canonical Towers we have several staff who worship at the altar of Extreme Programming, and as such many of the methodologies and rituals prescribed by that religion find their way into our day-to-day working practices. A few of these came together in an interesting way a few weeks ago, and it was suggested by a cow-orker that I blog about it so he could give the URL to people. The first ritual is that of the sprint, I don’t think this is orthodox XP but rather something inspired from it that we picked up from the Python community. With all of the Canonical developers scattered across the globe mostly working from their own homes, it’s become a useful tool; particularly for the Launchpad team. The basic idea for those that haven’t heard of it is simple, and perhaps obvious; you get a selection of the team together in one place, sit them around the same table with particular goals to complete. In effect it’s highly compressed facetime and high bandwidth interaction to nail those tasks that need it, before you head off again and work at a more sedate pace. The second is directly from XP doctrine and is that peculiar observance known as pair programming, something that is often coupled with sprints. For anybody who hasn’t encountered this before, it’s something I’ve always found rather odd. You get two programmers together, both itching to code, and you take one of them’s laptop away; and you don’t just force them to fight over the keyboard either, the laptop-less soul isn’t allowed to touch it. The theory here is that it frees the deprived individual of the hassle of coding and allows them to direct the programmer in ways that may not be immediately obbious, or alternately think about the next bit of work that needs doing. Another interesting side-effect is it can be an interesting way to learn code you’ve not worked with before, if you’re the one doing the coding and you’re being guided what to do by a sage who already knows it. I have a funny story here, so I’m going to digress from the main stream for a moment to tell it. A few months ago I was working in the London office, Mark had been up all night coding and had then given me responsibility to get his changes landed onto the Launchpad mainline. I’m not that hot on quite a bit of Launchpad, and fade to utterly clueless the nearer the code gets to the web application itself; and when trying to merge the two there were conflicts which I needed Mark’s help to resolve. Now as anybody who’s met Mark knows, he’s a pretty good example of a Type-A personality, yet he suggested that we do a spot of pair programming to get the code in and I’d be the one with the laptop as it’d help me get to grips with the affected parts. This hilighted something I’ve always seen as a problem with pair programming, dealing with it when the a person with the keyboard has a totally different way of working to you. In particular, I’m an emacs user, whereas Mark is a die-hard vim user; but also right down to the working directory I would work from, how I test results, etc. When you’re the one without the laptop, this can be quite infuriating, as you know exactly how to solve a problem and the idiot with the keyboard is dithering about doing things you don’t understand just to get there. If you’re a Type-A personality, you generally snatch the laptop away at this point and do it yourself; or at least you would, if you could drive the strange editor the other person uses. I swear Mark was sulking as he gave the laptop back and let me do it. Anyway, there is some relevance to that and we’ll come to it in a moment. The third and final methodology is the concept of unit tests and more specifically test driven development. For anyone who hasn’t come across this before, I highly recommend it; I was suspicious too when Robert Collins took it upon himself to teach me the true way, but now I’m sold. Simply the idea is that if you have any code that doesn’t have another piece of code in a test suite that checks that it’s working correctly, that code is broken. More particularly unit testing involves checking just one feature or requirement at a time, and stacking them together to test all of the code paths. I’ve actually found that this improves the APIs I design, as I write the code in small blocks and functions to make them easier to test. Test driven development takes it even further, you write the unit tests first, before you write the code they’re supposed to test; usually one or two at a time. Obviously these tests will fail at first, it’s then your job to write as little code as possible to make them pass. If your code isn’t right, you add a unit test that will fail, and modify the code to make it pass. This really comes into its own when you’re fixing bugs later, once you’ve identified the bug you write a test case or two that cause the problem; these will of course fail. You can then modify the code to make them pass, and at the same time be sure you’ve not broken other functionality because of the existing test suite. I’ve also found it really useful for particularly complicated or tricky pieces of code, especially those intricate algorithms that do particularly heavy lifting. So onto the event itself, this was a sprint in our London office to indoctrinate Gustavo Niemeyer with the various projects he’d be working on. The goal for this sprint was decided to start the conversion of HCT to Bazaar-NG, and to do this Gustavo and I would pair program. Now my last experience of pair programming had been that story with Mark (see, it had some relevance) and I knew I’d be just as bad if I wasn’t allowed to have the keyboard. I was also acutely aware that if Gustavo was just sitting by and watching, he wouldn’t get much benefit from it either, so he needed to be actively involved in the coding so he could learn the things he’d be working on. I came to what I thought was a pretty neat, and obvious, solution to these problems. We set up my laptop with the code we’d be working on, and on my display were two side-by-side terminals both running screen sessions. Gustavo then set up two same-sized terminals on his, ssh’d into my laptop from both of them and joined the screen sessions. In the left-hand one he ran vi, and in the right-hand one I ran emacs. Thus we both had keyboards, and both had editors, yet could see each other working and even steal the keyboard without danger of violence. We didn’t just sit side-by-side and code on different things though, that’s not pair programming and is just ordinary programming with a bit of a voyeuristic twist. What we did was: in my terminal I started writing the test cases for the code we needed, it was Gustavo’s job to write the code that would make them pass. We actually added a third terminal in which we could run the test cases themselves; so I could run them when I’d added something that would fail, and Gustavo could run them when he thought he’d made them pass again. This turned out to be a rather fun way to work, and at one point I was almost able to try and convince myself that the code was writing itself to pass the test cases I was writing. It also got me thinking that it’d be really neat to use genetic algorithms to breed code to pass test cases.

Indeed, Jon Downland is right, the way Debian behaves these days is not very glorious, we are reflecting a pretty bad image. I don’t know if Ubuntu can be a good example for us (because we don’t have the same priorities), but I know one thing: Debian is completely hijacked by that thing we call “money”. We have to face the reality, as soon as the money came into the game, Debian has lost a point. I cannot predict if the DPL made the good choice when he decided to launch Dunk-Tank, but I can tell that now that it’s done, people have to face a very big mess. And I really hardly see how that will help us to release etch in time…

For the project that I’m dealing with at work I wanted to be able to authenticate devices in a two stage process. Stage 1 should authenticate the device to the network (via an x509 certificate) and then Stage 2 should authenticate the user who possesses the device with a username and password. Unfortunately none of the methods shipped by default with FreeRadius will support this sort of configuration.

• EAP-TLS supports mutual certificate authentication between the server and the client but does not allow for a second stage to verify the username and password
• EAP-TTLS and EAP-PEAP both support mutual certificate authentication between the server and the client followed by a second stage password verification, however the current FreeRadius implementation doesn’t let you require a client certificate. If one is present it will use it, but it is just as happy to continue on without one, which is not ideal for my circumstances.
• The remaining EAP- methods don’t support certificates at all, so they’re not even an option.

A quick skim through the FreeRadius source code revealed that it wouldn’t be too hard to add support for requiring client certificates with EAP-TTLS and EAP-PEAP. The following patch adds a new configuration option to the tls section of eap.conf which if set to true will require the client to present a certificate before authentication will succeed.

• freeradius-require-tls-client-cert.diff

Example eap.conf

eap  
                default_eap_type = ttls
                timer_expire     = 60
                ignore_unknown_eap_types = no
                cisco_accounting_username_bug = no
                md5  
                 
                tls  
                        private_key_file = $ raddbdir /certs/radius.key
                        certificate_file = $ raddbdir /certs/radius.pem
                        CA_file = $ raddbdir /certs/cacert.pem
                        dh_file = $ raddbdir /certs/dh
                        random_file = $ raddbdir /certs/random
                        # This is the new option
                        # If set to no, or missing, client certificates are
                        # not required for EAP-TTLS or EAP-PEAP
                        require_client_cert = yes
                  
                 ttls  
                        default_eap_type = md5
                 
         

Linux seems to run on more and more embedded systems all over the place. Nice example I learned about recently: Linux running an ALDI "Pfandautomat" (German)... Yeah, I have no idea how to translate "Pfandautomat" (container deposit?). There's a video (Flash) on the site. A screenshot is here.

Joey Hess from Debian has come up with a pretty nifty analysis of thread patterns in email. This is a great example of the geek technique to transform what seems like chaos (and can surely be experienced as such) into something more categorical, segmentable, and thus manageable.

I had a few comments on my last so I decided to write a new post about it.

Firstly in regard to Elspeth's comment. I agree that children should wear glasses if necessary. That part of my entry was not clear, I was trying to make the point that I can understand children not wanting to wear glasses because they think it's uncool. But adults should make decisions on more important things such as what is best for their eyes. There are real reasons for needing eye surgery, if without glasses your vision is so bad that you are legally blind then an ophthalmologist may recommend surgery for that. In cases of extreme vision problems apparently a combination of surgery and glasses is required for good results. I also think it makes sense for people who need surgery for their work, for example athletes such as Tiger Woods. Looking cool is not a real reason for surgery, especially not for the small increment of coolness that some people believe is associated with not wearing glasses.

All operations involve some risk. Risk to your vision is not worth a small amount of convenience and possibly looking cool. Besides, it's widely regarded that people with glasses are more intelligent! ;)

Shintaro mentioned that there is a risk of retinal damage from being short-sighted. What I want to know is whether the risk of that can be alleviated if you wear glasses all the time? If you wear your glasses everywhere except in bed, in the shower, and in the sento, does that stop this problem? Maybe I should try and wear my glasses for more than the ~15 hours a day that I currently do.

Finally an anonymous poster noted that they didn't know anyone else who had an optical migraine. My ophthalmologist mentioned that it's rare to have a migraine that only affects the vision and nothing else. I feel fortunate to have it like that, the list of other migraine symptoms sounds very unpleasant. Of course only having had it once I can't be sure that next time it will be the same. I might get the nasty symptoms next time. :(

However one problem with what I experienced is that it came on suddenly with no warning. It would be very unpleasant to suddenly lose central vision while driving (I would have to hope that the ability to react to objects without consciously noticing them works well). Fortunately I have only been driving about 300K per month in recent years and I can probably reduce this. So the chance of it happening while driving is quite small.

It’s been a while since I’ve written about the LSB here, so I figured I was overdue to give an update. In short, it’s been a great year. Highlights include: » All major distributions, including Asianux, Debian, Mandriva, Red Hat, SUSE, and Ubuntu, are either already certified to LSB 3, in the process of certifying, or planning to certify their next version (see our list of expected distribution coverage for LSB 3). » A number of ISVs (independent software vendors), including MySQL and RealNetworks, are in the process of certifying applications to LSB 3. For ISVs, LSB certification means fewer distribution specific packages without sacrificing distribution coverage (take a look at the MySQL download page for an example of how crazy it can get). For users, LSB certification means greater application availability with a minimum of hoops to jump through. Expect a lot more announcements about LSB certified applications in the coming months. » We’ve put together a solid roadmap for the LSB going forward. The LSB aims to provide a “highest common denominator” across the various Linux distributions—in other words, to provide a single target for ISVs writing or porting to the Linux platform, where “the Linux platform” is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run. To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, … compliant distributions). We’ve made great strides toward these goals in the past few months. To satisfy the “easy mapping” requirement, each major version of the LSB now corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the current generation (Red Hat Enterprise Linux 5, SUSE Linux Enterprise 10, etc.), LSB 4.x corresponds to the next generation (RHEL 6, SLE 11, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions. At a high level, then, the LSB roadmap looks something like this:

LSB 3.x (2006-2008)	LSB 4.x (2008-2010)
Asianux 2.0 Debian 4.0 (”etch”) Mandriva Corporate 4.0 Red Hat Enterprise Linux 4 & 5 SUSE Linux Enterprise 9 & 10 Ubuntu 6.06 LTS (”dapper”) […]	Asianux 3.0 Debian “etch” + 1 Mandriva Corporate 5.0 Red Hat Enterprise Linux 6 SUSE Linux Enterprise 11 Ubuntu LTS “dapper” + 1 […]

» Speaking of the LSB roadmap, we’re hard at work on LSB 3.2, to be released Q2 2007. The short list of new features include the addition of Perl, Python, several freedesktop.org specifications for desktop interoperability, CUPS, HPIJS, ALSA, and more. For LSB 4.0, we’ll be uplifting LSB Core to GCC 4.1 and glibc 2.4 and looking at two longstanding issues, the addition of Java and a packaging facility for ISVs, among many other things. The roadmap will be posted for public comment shortly. » We’re making it easier than ever to build portable applications using the LSB. We released the LSB SDK (Software Development Kit), which bundles everything a developer needs to write or port to the LSB, with LSB 3.1. We’re building something called the LSB Application Testkit, which aims to be the LSB’s validator.w3.org, an easy to use tool that developers can use to test for application portability. And we quietly launched a beta version of the LSB Developer Network last month. » In July, we hired Till Kamppeter, making linuxprinting.org, the de facto standard repository of Linux printer drivers, an FSG project. We’re adding both distribution neutral printer drivers (delivered, naturally, as LSB packages) to the linuxprinting.org foomatic database as well as an API that third party printer management tools can use to install and update printer drivers. We also plan to extend the LSB certification program to cover printers in addition to distributions and applications. If all goes well, you’ll be able to look for the LSB Certified mark on a printer at the store and know that it will work on your distribution of choice in the not too distant future. » Last, but certainly not least, we’re embarking on an exciting new project in partnership with the Institute for Systems Programming at the Russian Academy of Sciences to build the next generation LSB database and test suite infrastructure. The new system will interlink the various moving parts that make up the Linux platform to an unprecedented degree, providing upstream developers and distribution vendors a powerful set of tools for coordinating their work and improving the quality of the platform, as well as giving ISVs a more efficient way to provide feedback to both parties. This is a key tool for enabling the backward compatibility guarantee mentioned earlier, and it will also vastly improve the coverage and quality of the LSB tests, an area where we’ve been criticized in the past (our goal is 75% interface coverage by LSB 4.0). More details here. I’ll drill down on all of these topics and more in the coming months. In the meantime, you can keep up with the latest at the FSG and LSB by visiting the FSG web site or by signing up for the FSG newsletter (sorry, no RSS feed yet, though I’m told we’re working on it). Finally, if you’re interested in participating in the LSB project, join the lsb-discuss mailing list or the IRC channel #lsb on irc.freestandards.org, where the bulk of LSB development happens.

With the ever increasing number of trolls, the average developer has no more time to maintain his packages. Motivating him to work on his packages instead of reading debian-vote is a hard challenge.

Here comes BAD-tank, which is the way to:

• motivate developers to work on their packages in the best interest of users;


• motivate users to get interest in what developers do;


• find a way for possible sponsors to spend their money in a useful manner.

BAD stands for Bribe Assisted Development. The idea is to add a new field, named XC-Bribe, to the control file. The field must contain the amount of money the maintainer requires for an upload, with a ISO-4217 currency code. For example, the maintainer might add:

XC-Bribe: EUR 50.00

to require 50 to get the package uploaded.

Then, the package shall be uploaded to the BAD-tank FTP queue. The related sources and binaries will be automatically put into a private area, while the .changes remains public. Users can then read the .changes and decide whether they want to contribute to this upload. BAD-tank accepts Visa, Mastercard, AmEx and PayPal. When the amount of the bribe is reached, the package is automatically uploaded to the Debian ftp-master queue, and the developer is credited with the bribe.

There are a few packages that provide headers or libraries for platforms that there is no Debian port to, prominent examples being mingw32 and Palm. Usually, there aren't more than just a few libraries for each, so that in real world scenarios, you end up adding a fair bit of stuff on your own. Now, wouldn't it make sense to define these as "cross-only" architectures, split out the runtime into the new arch, and use dpkg-cross to install them. For this to work, we need cross-architecture dependencies; mingw would depend on libkernel32-dev for mingw32, and I'd patch libz to compile out of the box for it, because this is usually the first library I need.

Hello (ikiwiki), World!\n ikiwiki succeeded where other competitors failed: convincing myself to set up a blog. This is the unavoidable "Hello, world!\n" post. Thanks Joey for this valuable piece of software, I love the subverted wiki concept and I('m starting to) like also the markdown syntax. Still, the experience in setting up the blog has not been painless, here are some rough edges I haven't yet addressed with ikiwiki (IOW dear lazyweb section from now on):

• working offline and then commit is fine, but I would have loved the usual draft->publish release cycle of many blogs. More generally I'm missing a way to hide pages in ikiwiki. Ok, hiding stuff it's not in the wiki spirit, but it is definitely in the spirit of VCS to commit as often as possible to avoid losing work!
• markdown syntax is not supported per default in the current vim in unstable. I found a vim syntax extension for markdown, ... /me is going to add it to the vim package in unstable (or at least to vim-scripts, not sure yet).
• when writing post offline the "preview" feature is desirable as much as it is when writing online. Thus my first setup involved running ikiwiki on my laptop and then sync the result on the machine serving the page. Unfortunately, ikiwiki seems to be meant to be run on the final machine (for example: the ikiwiki.cgi is a arch specific code generated for the machine executing /usr/bin/ikiwiki). My current solution is then to run ikiwiki both on the machine I use to write posts and on the machine serving this blog ... better ideas?
• a couple of minor nuisances (the dates at the bottom of posts shown in Italian format, and all links in the RecentChanges page broken if I dare rebuilding with --rebuild). But hey, I know, it's free software, I'll eventually try to come up with a patch for these!

Again and nonetheless, kudos to Joey for ikiwiki, it rocks!

As you might know I publish some of my photos in my photoblog and on flickr under a Creative Commons license. A very cool example of the so-called remix culture "happened to me" recently — one of the photos I posted on flickr was used as album art for a music CD, namely J. D. Warrick's "Going, a. The Leaving". Btw., if you want to learn more about remix culture, Creative Commons etc. I can really recommend Larry Lessig's Wizards of OS 4 Keynote titled "The Read-Write Society" (OGG video: 144 MB, MP4 video: 224 MB).

TerrorBullGames has just released the board game War On Terror. The first I heard of this was a short article in a local news paper about how much the game has offended some people (quoting someone who was injured in the London bombings). A co-creator of the game Andy Thompkins said "We accept that some people think this is in poor taste and may see it as puerile. But we would say that launching an illegal war on Iraq is in poor taste".

It's not as if profiting from terrorism is anything new. Governments in Australia, the UK, and the US have profited from it at the ballot box and also used it to stifle opposition parties to get unpopular legislation approved. An example of this is the attempts of the Bush regeime to legalise torture, see the Washington Post and The Age (Australia).

Shortly after 9-11 almost every computer company that had anything to do with backups or disaster-recovery was advertising heavily. Oil companies have done particularly well with high prices, they would have done even better if the plans for Iraq had succeeded.

TerrorBullGames appears to have an aim to draw attention to the lies of politicians, which makes them better than everyone else who has profited from 9-11. Maybe if they draw enough attention to the bad things that our governments are doing they can influence the results of elections, and we can get governments that don't promote terrorism.

Here's a review of the game.

Taking a look to one of the IRC channels where I’m habitual, I found an URL to a Debian wiki page, where people is adding their names because they will have problems to attend Debconf7 in the planned date. By chance I’m in this set, exams are planned for this date. Please consider add yourself to this list if it is impossible for you attend DebConf7 in June.

Recently in my (physical) mailbox: SELinux by Example by Frank Mayer, Karl MacMillan, David Caplan. The most recent and up-to-date book about SELinux I know about, written by some of the most involved and knowledgeable people in the field. From what I've read until know it seems to be a really in-depth and easy to understand introduction, and what's more important, it covers the practical aspects of how you use, configure, and administer SELinux in real deployed systems. This should make an interesting read...

This is my first post in Debian Planet. Last sunday I was asigned an AM, zobel. He's a very helpful guy. It was a great birthday gift because I didn't expect to get an AM so fast, NM is know for being a long process. I've begun to work in the first steps of P&P questions already although I'm not going as fast I'd like because I've hitten by tons of TODO tasks just after finishing exams but I hope to get more involved in the Debian community and development quickly.

During Debconf5, I voiced the opinion that all Debian packages with a priority Standard or higher, as well as packages with a high Popularity Contest rating and development packages with a priority Optional or Extra that many people rely upon for development work, ought to be team-maintained as a matter of Policy. I justified this by pointing out that Debian's Social Contract puts our users among our key priorities, which implies that keeping the packages that our users value the most in excellent shape ought to be the embodiment of this value, and that the best way of meeting this goal is to enforce a policy of team maintenance and easy NMU for those packages. While my own packages are rather modest contributions to Debian's pool and few of them rate anywhere close to the top in popularity, I honestly feel like practicing what I preach is the best example I could give. Another reason is that several business ideas that I'm working on are monopolizing my time, which means that I'm not as available as I would like to be to participate in Debian. I however see this situation as only temporary, which is why I have not orphaned my packages. Instead, I am soliciting Debian Developers to come as co-maintainers. Interested parties should check my QA page for packages that might interest them and contact me for details. Thanks! PS: in case this wasn't obvious, the whole point of enforcing team maintenance and allowing NMU on non-RC but annoying bugs is to avoid unresponsive lone wolf maintainers who let tons of bug reports pile up on their packages without fixing them or even acknowledging them. Ubuntu avoids this by allowing anyone on their development team to chip in, while Debian still clings on to each maintainer's absolute reign over their packages, which leaves users of neglected packages completely in the dust.

I am nearly done with the marathon move. After a small hold-up in Canadian customs (for no apparent reason except I got a border official who had incorporated the role, a full 110%), my stuff is here, unpacked, and in decent order. In between unpacking, I have been able to experience some of Edmonton–from the nightlife to its administrative face (signing up for health insurance and a Social Insurance Numbers, for example, both of which were easy as cake) and I have to say E-town gets a far far far worse rap than it deserves. Ok, the weather is nothing to swoon over, and it is already getting far colder than I am used to but bracketing that detail, it is a pretty neat city. Now I tend to like the mid-size cities (Minneapolis, Madison, Philadelphia, Portland are some of my favorites in the U.S) over the mega-gargantuan-city and Edmonton fits this bill with just under a million people. And perhaps it is also just that I am digging some Canada-wide features (affordable and immediate health care, licensed cafes, a saner pace of life, the pleasant and earnest character of many folks) but there are Edmonton-specific attributes that are pretty nice too. Before I get to them, it is worth noting that every time I have told people that I was going to Edmonton, they would either: 1) admit that they did not know exactly where it was and thus could offer no opinion whatsoever (and I was one of those folks until I looked on a map) or 2) blurted some negative reaction like: “do you really have to go there!” though most of those people had never been, but had a sense of its northernly location. Perhaps my favorite reaction came from a blackberry forum where we posted a question about good data plans in Edmonton/Canada. Most of the replies stuck to the topic, but one person decided to spew his unadulterated thoughts on Edmonton:

i feel sorry for u going from NYC to Edmonton “Edmonton sucks” you’ll be happy to go back to NY..
You go from a city that has life to a dead one.. from having good bb plans to sh*ty ones.. hope your getting paid good

Ok, admittedly, the data/cell phone plans are lackluster but I think this person either has had some terrible times in Edmonton (and holds an unhealthy grudge), has never lived in NYC or has a warped sense of what the good life in a city means. Sure NYC is an amazing place, and is my likely future home, so I am not going to trash it but, like any city, it has its shortcomings.. like unfordable housing But time will tell as to how I feel about Edmonton after the winter. Perhaps when it reaches freezing temperatures, it does turn a leaf, and become dead but then you hit the mountains, no? But for now I am digging the HUGE pine trees, rivers, and ample sun of E-town.

Just a quick update for SELinux in etch. With Manoj picking up work on it again (you might have noticed the large influx of new SELinux related packages these days, bringing our toolchain up to date again), and rjc having setup a SELinux development box for me, we're actually making some progress on SELinux for etch now. Uwe Hermann also blogged about SELinux on Debian recently. There are tons of small nuisances with SELinux on Debian left. I've started filing bugs and tagging them with the "selinux" usertag. It's in the details. For example mawk and gawk both try to ioctl any file they read as if it were a serial terminal. Which of course causes SELinux to log an audit error, since the init script or whichever was calling awk didn't have the permissions to ioctl a config file. Then there is /dev/xconsole - it's created by the syslogd init script (shouldn't maybe this be handled by udev), it's barely used by anyone, and SELinux policy upstream wants to keep it in the xserver policy, and claims its main use is to be able to feed it the output from programs started by the window manager (instead of .xsession-errors). Which is a seriously broken design, since it's not multiuser capable. Anyway, our current options are to

• diverge from upstream in policy, putting xconsole into logging policy
• make xserver an mandatory policy module
• convince the syslogd maintainer to disable xconsole by default
• convince upstream to at least split it out from the xserver module into a separate xconsole module and make that mandatory

Of course I was quickly flamed for filing a bug against exim stating that there currently is no SELinux policy for it, and people thus will have to use postfix or sendmail instead. But heck: people trying out SELinux on Debian will run into this problem, you know. I'd certainly prefer people to use exim instead of sendmail (I'm more of a postfix guy), but unless someone writes a policy for exim, people can't use it with SELinux. I have no idea how exim works (where its queues live, expected behaviour and so on), so I can't write a policy. Now to start a real flamewar - how about making postfix the new default MTA for Debian with etch? /me runs and hides.