At 8pm on Tuesday, April 10th, I will be giving a talk about Debian to the Long Island Linux User Group (LILUG)

Some more comments on AppArmor, since some people might see my previous post just as being disappointed by seeing it in Ubuntu, and not much work on SELinux. First of all, I should note that I don't have any SELinux systems I'm responsible for anymore. They still run SELinux in strict and are doing well, but I'm no longer responsible for them. So I'm actually pretty much out of SELinux development nowadays. I did some occasional policy merge to monitor policy development, and when I tried VMware, I even setup a SELinux system to check the current state. But I wouldn't call myself an active developer or even user. So I don't think I'm as biased as you might think I am. Some things why I don't trust the AppArmor people:

• their website is incredibly full of marketing blah-blah such as "AppArmor is the most effective and easy-to-use Linux application security system available today" (effective as in what?)
• their Wiki/FAQ states wildly inaccurate things about SELinux such as "To get the full power of SELinux, applications must be recompiled and linked against SELinux libraries." (no, you don't need to recompile and relink all your applications...) - and they even contradict themselves to some extend; on one hand they claim that you don't need to modify applications for use with AppArmor, on the other hand they highlight it as a feature that you can patch your apache for AppArmor to get some more security for embedded interpreters such as PHP. This is pretty much the same as with SELinux.
• they state such misleading things as "every user should give each system an afternoon's test to decide which is a better match for their needs." - sounds good at first sight, but how many admins are able to evaluate the security of a kernel-based security solution such as AppArmor or SELinux in one day? What this actually is, is an encouragement for admins to pick the security solution because of ease-of-use, not because of security considerations.

Instead they should be honest about what AppArmor can, and what it can not do. I don't doubt that it can be used to make exploits with specially crafted PDF files in evince and such simple viewer applications a lot harder, but their security is not as thorough and complete as SELinux. They are potentially vulnerable to some attacks caused by their path name based approach, or that they cannot do MAC for files with unpredictable names such as most of /proc (e.g. /proc/1234/cmdline), any kind of sockets or when file descriptors are passed from one application to another. They should also admit that since SELinux initially assigns file labels by very similar pathname/filename patterns as AppArmor uses, it maybe isn't that much harder to setup in this aspect... In fact, it's much easier in SELinux to add an additional location for font files, since all the application policies don't need to be modified or reloaded, just the new font directory needs to be relabeled. In AppArmor, you'd need to modify an 'abstraction', then reload any policy that depends on this abstraction (you probably can only reload all at the same time, so that's not too hard). To anyone with a tiny bit of computer science knowledge, it should also be obvious that the performance of reconstructing the file path and matching it against a large set of filename globs (AppArmor) necessarily is slower than just using the security label in to the files attributes (SELinux, where this globbing was done once when doing the relabeling); any performance difference that shows that SELinux is slower than AppArmor is probably caused by SELinux doing a lot more security checks than AppArmor. So even AppArmor could benefit from using labeled security... I'm cool with saying that AppArmor is easier to get started with than SELinux, but they need to be honest about the differences to SELinux and the problems with AppArmor.

I just received the latest Dell advert, they are offering a 22 inch monitor with 1680x1050 resolution for $499 including delivery! This is a great deal, I've got the same model of monitor at home (I paid $750 for it almost six months ago) and have been totally satisfied. The same monitor with a $499 price is amazing value.

In the past I blogged about the benefits of larger monitors for software development. Now these benefits are available to most computer users in first-world countries.

Now that 1680x1050 is commonly available I expect to see higher resolution monitors dropping in price, at the $800 and $1200 price-points there will need to be something better than that.

The next development will be new software to take advantage of this. One thing that I have heard of is a window manager that splits the display into two halves (in this case they would be 840x1050 resolution). The benefit of having this configuration (according to the people who use it) is that for maximising a window will make it take half the physical screen. This means that you could have a debugger in one half of the screen and your application in the other, to "maximise" the application would not occlude the debugger. Or you could have a web browser and a MUA each using half a screen.

Of course the same result could be achieved by getting two physical displays, but this requires a graphics card that supports "twin-head" operation, and the purchase price of two displays (which will add up to more than $500).

Splitting a screen into two virtual displays is not something that would suit my working patterns. For a lot of my work I just have a screen filled with as many Xterms as will fit. For the GUI stuff I am happy to manually resize things. Maybe a KDE addition that would allow one "Desktop" to be split while another isn't would work.

A final impediment to splitting the screen is that 840 pixels is not enough to correctly display all web sites (many of which are designed for 1024x768). Maybe if I had a split desktop with an icon on the title-bar of the window to unsplit it for one particular window then it would work.

Another use for a large display is virtualisation. I previously blogged about how to use Xephyr to run multiple X sessions on one display, as Xen is now supported in all Linux distributions and KVM and other
virtualisation technologies are also being developed there should be a lot of demand to have multiple virtual machine GUI displays on one desktop (although you could probably do this by manually sizing the windows).

These are just some wild ideas, I have no plans to write the code for any of them, so it'll be a matter of whatever is desired by the people who write the code or pay them. But one thing is certain, the low prices of such monitors will drive new research into how to use them effectively. New technology to effectively use large displays will then drive demand for even larger displays (as will the people who just want to get something better and more expansive than their neighbours). I wonder when we will get to the stage when people are satisfied. For basic office applications commodity PC hardware has far surpassed what is needed for people to do their work.

We had a good brunch today. Friends Heather, Damien, Niko, Karine, Sarven, Brigitte and John all came over for some quiche, roasted potatoes, green salad, bread, cheese, wine, beer, asparagus, coffee and papaya. All in all a good time. We'd hoped to walk over to our new house at 4690 rue Pontiac with anyone who wanted to see it. The previous owner was packing the last of his stuff today, and we were supposed to pick up the keys this evening. But we hadn't heard from him by 7PM, so we packed everyone off to home and put the baby to bed. Then he called at 8PM, so I drove over to the new house and had a chat with him while picking up the keys. He had a couple of leftover Bor ale Cuivr es, so we drank them while he showed me around the house. I helped him take the last of his cleaning supplies out to his car, and then I went back inside, to our house. Wow. I just walked around for a little while, turning on and off the lights and looking through the windows and trying to imagine what our life there is going to be like. We're not going to move in for another 2 months, so it seems a little remote. The house felt nice, though. It's on a quiet street in a great neighborhood, and I could tell it was a good place to live. I'm excited to get started with it. tags: house 4690 rue Pontiac homeowner keys

Hey IBM Now that OS/2 has reached its end-of-life, it's time to release as much code as you can out of it under a liberal Open Source license. There are millions of lines of code in OS/2, and I doubt that much of the Microsoft code written in the 80s is still there. IBM talks a mean game about Linux and Open Source (see http://www.ibm.com/linux ), and to a large part they've been pretty true to their word. But having a huge codebase available that could very clearly benefit the Open Source world, and that's not being developed further, is a bad idea. Clear the rights, release the software. Abandonware is a terrible thing to waste. tags: os/2 ibm open source

Spring has arrived in many parts of North America. But in Edmonton, North America’s largest and most northernly city, spring has sort-of-come-but-not-really as it recedes fairly quickly. There will be a day of explosive warmth (you know, a balmy 45-55 F) and of course locals strip down to near nakedness, wearing shorts and, the more flamboyant will don an 80’s inspired cut-off tee. Hot. This sartorial statement says WE are SO ready for the long winter to leave … for good. Despite the collective sentiment, which is probably shared by 99.999999% of Edmonton’s inhabitants, the winter cold, snow, and breeze are indifferent to our deepest pleas and they come right back, making us sport at least a few layers of winter clothes. Within this dance between winter breeze and spring warmth, I have spent most of my time staring at my computer doing everything possible to transform half-baked ideas, hunches, sentiments, and theories into coherent words, sentences, paragraphs, and chapters for my book. I am working on it full-force and am enjoying it more than I have in a year though from time to time I get fed-up, lost, sick of it, and my writing soul descends back, deep into one of Dante’s infernal rings, where I fester with my frustration, convinced that I should have become an organic flower farmer/acupuncturist that I almost became (well not really, but I have always fancied that combination as an ideal and fulfilling career path). Slowly I usually make my way back up, brush off the cobwebs of despair, and proceed anew. Within this highly secluded life of monastic-like repetition, thankfully, I have been enjoying some new things this spring. Once a week I head over to an University of Alberta off-site library facility to pour over archive material for a new project, which I am not going to talk about here (it is super-duper-top-secret) but it has been interesting working at an archive, especially one that is housed in an old Ikea. Since I am one of those right-brained people, I like to listen to music while I work, and lately I have also become pretty obsessed with house & electronic music, mainly thanks to a local DJ, David Stone whose weekly radio show on CJSR, BPM, is simply the bomb. He claims to bring the latest and greatest of electronic dance music from around the world and I think he is totally right. If you like this type of music, do catch his weekly show on Sat nights at 6 PM (MST). I sometimes get a little sad when I listen to some good music or see some stellar performance because it reminds me that what I may one day have to offer to the wider world an academic book and article here and there simply cannot bring the type of joy that musical performance and other creative expressions can bring. While you can listen to songs and over again, a book, if it is really superb, may attract a second or third reading. An academic book or article may at times light an inner light of joy, but let’s face it, it is usually a pretty cerebral light oh’ joy, leaving untouched those part of the brain, soul, heart, where more visceral, mysterious, yet fully self-enveloping feelings of joy reign high (but I am trying my hardest to stick a funny section or two in every chapter to leave a trace of laughter because if I can’t manage that with an ethnography on hackers, I will have failed miserably). Every track David Stone plays is something I want to listen to over and over again and thanks to mplayer stream dump function, I can. And funny enough, is that in the last month software believe it or not has brought me much joy as of late. I have been using free software since 1997 and I used to get A LOT more annoyed no make that a downright frustrated with programs (or lack of programs) than I do now. In fact, now, I am simply stunned whenever I upgrade to a version of a program. For example, Word Press 2.0 is like so much nicer in terms of usability and functionality than 1.5. The same goes for Open Office, the Gimp, and even Firefox, which has some bugs, but is so much better than its predecessors. I once described free software using the well-worn clich as “the gift that keeps on giving. And I think that this is becoming more and more true. And like wine, with the passing of time, these gifts usually get better and better. And like a unexpected present that arrives on your doorstep, these software packages induce some joy, because it is actually pretty neat to see these programs develop and grow into something stronger and more useful; so thanks to those who spend their time hacking away at making and improving this software and thanks to those (you know who you are) who helped with my recent WP upgrade!

I just filed Intend-to-package bug number #416996:

* Package name    : stereo
  Version         : 2.0 beta
* URL             : http://www.mono-project.com/Stereo
* License         : LGPL
  Programming Lang: C#
  Description     : Mono (.NET) extension for running
                    multiple applications

Stereo is an extension to the Mono (.NET/C#) platform for running multiple applications at the same time. As you probably know, C# is a language using a bytecode, called CIL: Common Intermediate Language. Using code in an intermediate language has benefits for platform and operating system independence (Java is the most prominent example of this approach), however it also means an overhead when running the applications. Various approaches have been tried to remedy these effects, such as JIT (just in time) compilers translating the bytecode to native code when needed. Applications running based on such bytecodes tend to use more memory than regular applications (for example, they need to keep the compiled code in writeable memory, whereas regular applications can use shared read-only memory for this), and you probably have heard many people complain about the memory usage of Java and .Net applications. Some people even claim the Linux .NET platform is called "Mono" because you can run at most one such application at the same time. That how "stereo" was born: an extensions to run two (or more) applications in the same mono environment, thus reducing the memory overhead significantly, and making it useful for more people. Future versions should even be able to run Python (using IronPython) and eventually Java applications in the stereo runtime. It is also planned to add support for multiple user operation. So eventually, it will be able to replace your whole system. The project will then also change it's name to Multics, to reflect it's unique multi-user capabilities. At least if we get enough funding by Dunc-Tank, who is currently sponsoring all our development efforts.

Man, I totally missed the announcement that Netscape.com now supports OpenID. This is pretty great -- Netscape is probably the biggest OpenID consumer on the Web, after Technorati. And Technorati only uses OpenID for a few limited purposes. Good news for Netscape.com and for OpenID. tags: openid netscape consumer

Science of Sleep I just finished watching The Science of Sleep. I liked the animation, and the writing -- the ambiguity of the sleeping state and the waking state. And I like Gael Garc a Bernal. But I also realized that films about people on the brink of mental illness are really distressing for me. Otherwise, it was a good movie. tags: science of sleep film

Speaking of sleep I've been finding the Nokia N800 really difficult to use as a mobile computer -- or, rather, as a mobile toy. I haven't been getting as good WiFi coverage with it as I'd like, when taking it around, so it's not that fun to play with. I took it to the bank so I'd have something to do while waiting in line, and I couldn't get a network connection. So yesterday I imported my OPML feed from Sage into the RSS reader on the N800. I figured that even without connectivity I'd have something to read on the computer. But my feeds (about 20-30; is that a lot?) slowed down the N800 to a crawl. When I rebooted the machine, it got in the same boot loop it had problems with before, and wouldn't start. I had to re-flash the hard drive again, but luckily this time around I had a recent backup. Unluckily, it doesn't seem to want to restore the backup. It's frustrating. tags: n800 opml boot

AFD So, there's not one but two April Fools Day articles on Wikitravel. Last year, we had an excellent guide to San Serriffe posted, but I think this year's joke guides to Earth (for aliens) and Hell (for everyone) are pretty good, too. tags: april fools day wikitravel

Had a great time at DemoCampMontreal2 tonight. There were a ton of people there, the demos were great, and the bar at the SAT was open for business, so it was possible to drink beer and watch demos. There were all very solid projects with lots of interesting stuff going on. My favorite aha! moment came from Hugh McGuire showing off Collectik, his new social-podcast-aggregation platform, when he demo'd how he uses the site, and I realized that that's how I want to organize my podcast listening, too. I also liked Kakiloc, a location-oriented social networking site. They let you tell your friends what you're doing and where you are, and the friends can see it on the Web, by SMS, or through IM. Sound familiar? Yeah. Kakiloc's advantage is that they have more geo-oriented interface, and some extremely powerful rules that trigger activity when you (say) get close to someone in your circle of friends. However, I think in a world of Worse Is Better Kakiloc is going to have a hard time making a sale. Twitter already has the mindshare in this market, and the network effect makes it more valuable for people to stay with the popular platform. I also really dug the films from OpenSourceCinema.org, although they skirted the "demo" concept pretty scarcely. One thing that was neat was that the OSC Web site was built by a real-life barn-raising: Sylvain Carle put out the call for some help, and people convened on his house to build the Web site. Cool idea. All in all I had a really good time. DemoCampMontreal2 worked out well. tags: DemoCampMontreal2 kakiloc collectik opensourcecinema

Bait and switch So, on the way out the door to DemoCamp, I grabbed a handful of loonies out of my bedside change basket for the parking meters downtown. When I got to SAT, though, I realized that the "loonies" I'd brought were in fact Sacagawea dollars. I'd gotten them as change from the ticket machines on the Las Vegas monorail. Doh! Fortunately, downtown Montreal parking meters take credit cards, so I was OK. tags: loonie sacagawea parking meter monorail

Feisty Upgraded to FeistyFawn on Wednesday. Worked fine, nice smooth upgrade (who expects that?). Nothing revolutionary, but the software works well. tags: feistyfawn ubuntu upgrade

My little pictures-downloading tool just got a new feature: instead of relying on an automounter, it can now invoke pmount itself. That makes it easier to setup. It also allows you to unplug the camera as soon as the program is done running; no more waiting for the automounter to unmount it after a timeout. The Synchronisation scripts for digital cameras page has been updated accordingly.

Hard to believe it's already time for DemoCampMontreal2 tomorrow night (Thursday, March 29, at the SAT). I had a pretty good time at the first DemoCampMontreal back in February, despite my demo going belly-up a few times. It was a good space and a fun time to talk. I think the BarCamp page on DemoCampMontreal2 has some good info, too. Check out Fred Ngo's writeup of DemoCampMontreal2, including a fancy photo of yours truly demoing in February. It looks a little like BarCampHell, but in a good way. tags: barcamp democamp montreal DemoCampMontreal2 fred ngo me

Big day Today's our big day -- we're closing on the house at 4690 rue Pontiac tonight at 7. We just got in from Las Vegas last night, but we headed out to the bank this morning to get a cashier's check for our (very large) down payment and dot the t's and cross the i's for the mortgage. Lots more running around today, but we go to the notaire tonight, and we'll have some sort of paper certifying us as homeowners sometime tonight. Shom-pan-yah to follow. tags: house buying closing 4690ruepontiac

Open Web Design One really great Open Content (or is it Open Source...?) resource that I don't pay enough attention to is the Open Web Design repository. It's a collection of very nicely done Web designs, delivered in convenient packets of HTML and CSS. They make very nice templates for "skins" of blog engines, CMSes, or even wikis. It's a great complement to the tons of Free Web software available out there (most of which is quite skinnable, and most of which has execrable default themes). My favourite part is that all the designs are dedicated to the public domain or made available under the liberal Creative Commons Attribution 2.5 license, which makes them honest-to-goodness Free Culture per the Definition of Free Cultural Works. I'm going to be using one of these Web designs to clean up my kinda bland home site. It could use a bit of editing. tags: web design design open content skins themes

Thanks Mark, Allegra, No ma and Anoushka Thanks to Mark and family for the congratulations on our new house. We signed the papers tonight, and it went surprisingly smoothly. Our seller is a fascinating guy who started the animation lab at Ubisoft, so we enjoyed getting to talk to him in between onslaughts of legalese and flurries of signatures. In other good news, I guess the gang is coming out for RoCoCo. Wow! That'll be pretty fun. Good thing we'll have two houses then. tags: mark house rococo ubisoft

Life sometimes goes in a funny direction, like a full circle d j vu: 20 years ago, I was studying Technology of Computerized Systems (a combination of electronics and programming). Now, 20 years later, I'm starting a dream job as the Business Development Manager of Artec Group and their core business is you guessed it exactly that. The really cool thing about Artec, from a Free Software advocate's point of view, is that they contribute firmware and drivers for their products to LinuxBIOS and the Linux kernel. At this point, my initial tasks will focus on marketing and selling Artec's flagship OEM product, the ThinCan. What is the ThinCan? Actually, you're already familiar with one iteration of the product: the Linutop is a branded ThinCan, delivered with a custom hardware configuration, plus custom casing artwork designed by Fr d ric Baille of Linutop SARL and loaded with Fred's favorite Xubuntu configuration. In the Linutop's case, their business model is to fill the market niche for a simple Internet surfing platform that fits 80% of average people's daily computing needs, so the hardware configuration they ordered reflects that. Still, as several readers of this blog noticed, the "Linutop" could make a fantastic thin client and, sure enough, that was the main purpose behind the ThinCan's original design; it sells well in the Fortune-500 market as an RDP client running under Windows CE. However, until recently, there simply wasn't much demand for a contemporary X11 terminal solution based on the ThinCan. That is, until LTSP took off, thanks to the contributions of Edubuntu and similar educational Linux distributions. Sure enough, someone spotted the opportunity and contacted Artec to order a branded ThinCan iteration with Etherboot and PXE support, which they call the Linuterm. By the way, for those who need a really cheap OEM thin client, I've got a great spring clearance offer for you:

Artec has about 500 pieces left of their older DBE60 ThinCan model, based on the AMD Geode SC2200, and we're selling them at 100 euro / piece, plus VAT and shipping.

The DBE60 is configured with three USB 1.1 ports, one parallel printer port, one 100baseT Ethernet port, one VGA port (up to 1024x768 @ 16bpp 60-85Hz or 1280x1024 @ 8bpp 60-75Hz) and one 1/8" stereo audio output jack. Its BIOS provides Etherboot support and its motherboard is populated with 64MB of RAM and 32MB of Stratoflash. It comes delivered with a European AC adapter. The Geode SC2200 is fully supported by the Linux kernel with the sole exception of a missing ALSA snd-scx200, but this could easily be ported from AMD's deprecated OSS driver and X.org support is provided by the "nsc" driver.

Minimum order size is 10 pieces. Contact me via my full name (unaccented, with one hyphen and one dot) at artecgroup.com quoting this special offer.

PS: someone was asking if that DBE60 special is also available in the aforementioned Fortune-500 configuration. It indeed is: add 16 euro / piece for the Windows CE 4.1 license with an RDP client.

Just uploaded simple-cdd 0.3.0 to experimental, as a simple-cdd user since Sarge days, I've helped a lot Vagrant with Etch support that required a huge amount of development due to the d-i and debian-cd changes. Thanks for those who helped us with testing and patches!

If you're lost, simple-cdd is a limited though relatively easy tool to create a customized debian-installer CD. It supports multiple install profiles for your CDD project (We can ask your user which to install, you can simple have one or preseed it); You can preseed the packages that will be installed as you can do using d-i; i18n support for those who want custom Debian localized images; multiarch support; postinst support for profiles; simple-cdd-profile udeb take care about extra packages installation, it doesn't need tasksel.

So say we all!

I just voted :) Dunno yet if that worked, but if not, I'll manage... as I'm pretty tired I decided to vote one plattform, not person, the same as NOTA (as I really think those ideas won't do Debian any good, quite the contrary). Maybe I'll change that in a few days, dunno yet.

Due to being quite busy with work the last days or rather weeks, this was my first act as a DD, which I couldn't do before. I'm still using my guest-alioth account and due to the freeze (yay!) no uploads yet.

Quite to the contrary (not really, but I find it very ironic) I've build my first rpm yesterday :-) I ported fai to fedora... more on this soon.

Since a week ago debian-community.org runs on its own server, currently managed by three admins with fai. The webpage is still static html, but ikiwiki should be up on the weekend, in some free minutes I already looked into it and played with it on the new machine. I'll write a more detailed blog entry about this when it's ready.

The Children’s Online Protection Act, or COPA, requires website operators who provide commercial material that could be “harmful to minors” to verify their users’ age, for example, with a credit card. The statute was immediately challenged as unconstitutional under the First Amendment. A preliminary injunction against enforcement of the law was upheld by the Supreme Court, which remanded the matter for factual development as to whether filters could accomplish the same purpose while interfering less with free speech. (Ironically, the ACLU found itself in the unusual position of arguing for Internet filters in this case.) It was just about one year ago that the Government sought to enforce a subpoena against Google for records of user queries and URLs stored in Google’s database. The court granted the motion with respect to stored URLs but not queries in Gonzales v. Google. It was never quite clear what the Government would really do with the data or why they pushed so hard to get it after receiving what they needed from other search providers. (The U.S. apparently argued Google’s search results would “add luster” to its analysis). In any case, the statute has now finally been held unconstitutional. As Ed Felten insightfully points out, unlike in previous instances where courts have struck down Internet speech regulation, in his opinion, Judge Reed did not provide a roadmap for Congress to try yet again to enact a law that would pass First Amendmend muster. Maybe Congress will leave the issue alone for a while:

Two things make the judge s ruling relatively roadmap-free. First, it is based heavily on factual findings that Congress cannot change things like the relative effectiveness of filtering and the amount of HTM material that originates overseas beyond the effective reach of U.S. law. (Filtering operates on all material, while COPA s requirements could have been ignored by many overseas sites.) Second, the alternative it offers requires only voluntary private action, not legislation. Congress has already passed laws requiring schools and libraries to use content filters, as a condition of getting Federal funding and with certain safeguards that are supposed to protect adult access. The courts have upheld such laws. It s not clear what more Congress can do. Judge Reed s filtering alternative is less restrictive because it is voluntary, so that computers that aren t used by kids, or on which parents have other ways of protecting kids against HTM material, can get unfiltered access. An adult who wants to get HTM material will be able to get it. Doubtless Congress will make noise about this issue in the upcoming election year. Protecting kids from the nasty Internet is too attractive politically to pass up. Expect hearings to be held and bills to be introduced; but the odds that we ll get a new law that makes much difference seem pretty low.

I'm proud to announce the next DemoCamp that we're holding in Montr al. DemoCamp Montreal 2 (Fran ais) is a gathering of people, both in high-tech and not, to see demonstrations given by people doing cool stuff. Anyone is welcome to show up and we've got some interesting talks lined up. I'll be there to take photographs again and to chat with people about the projects they've been tending. It should be an exciting and interesting evening. How do you attend? DemoCamp Montr al 2
Thursday, 29 March 2007
18:30 20:30
Societ des arts technologiques
1195 boul. St-Laurent
Free admission ( Sign up Upcoming.org Google Maps ) I hope to see you there!

Dear Lazyweb, I was asked if I could easily setup a system with the following characteristics for a sport club:

• A server in the office room (= locked) hosts the music library
• Two clients (for the two training rooms) are connected to the server
• Each rooms' client can select it's own music (preferrably using a touch screen), pause, play and pitch.
• Trainers can create, save and recall playlists for their class
• It should be possible to associate additional metadata to the music, such as measures-per-minute speed information.
• If possible trainers should be able to generate playlists remotely using a VPN connection; however it needs to be ensured that they cannot download the music this way (the sport club has a license for music use in training classes, but obviously not for anything else)

Two setups I was considering:

• NSLU2 and some USB disks as storage
• DAAP on the NSLU2 for music serving
• Rythmbox, Banshee or maybe even iTunes as client

This would likely require the least effort. It doesn't offer the playlist features I wanted (or only partially), and there are some access control limitations. No remote access. But for example the clients could even be Windows boxes I wouldn't have to deal with myself.

• Full linux server, maybe NSLU2 would be fast enough?
• Two MPD instances running there, streaming the audio to the clients
• Clients with a small GTK or Web UI to control MPD instances on server

Has better playlist sharing capabilities, and the web UI could probably be used remotely, too. But MPD doesn't allow extra metadata such as BPM information, it would need to be modified. Much more work. Maybe some solution using XMMS2 or VLC would also be possible. And the ideal solution would allow some pitching. Do you have any recommendations for me? Please send them via EMail to erich AT debian DOT org. IMHO, the key factor will actually be the UI for the trainers. It should allow them to easily locate a song when needed, or put a couple of songs into a playlist to use during their class. Carzy DJ mixing capabilities aren't needed; party evens will likely have a real DJ around. This setup is solely meant to help the trainers getting their music ready in no time. Right now there are always issues with cables gone missing, CDs in the wrong covers, CD readers not reading certain CDs, etc. pp. And after all CDs have a pretty bad usability; you can't reorder songs easily according to your needs, and you'll often have to switch CDs. Having the music on a harddisk and using playlists can offer some good improvements here. So instead the UI should allow easy searching of tracks, easy access to a large number of playlists and such key functionality. Note that this is just an idea floating around so far; I don't know if it will become reality sometime. Adding some PCs to the rooms, eventually even with a touch screen, is some expenditure; that money might be better spent differently.

John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven't yet converted the primary SCM repository for e2fsprogs to use git (yet), I've reached an opposite concolusion from John, and yet, I can't really argue with his observations.

The main reason why I've come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has "more legs" than hg, and with the release of git 1.5.0, it became clear that the git community was willing to work on these particular shortcomings, which is why I started working on it and making plans to migrate e2fsprogs to use git. The main reasons why I think git is more powerful is that not just that it supports lightweight branches inside a single repository (although I really do like that a lot since it makes it a lot easier to run multiple experiments in parallel and switch back and forth between them), but also because git is much more Unix-like; there are lots of tools that enable scripting for either new git extensions or for ad-hoc shell pipelines that you can't really easily do in hg without breaking into Python.

But git definitely does have shortcomings, and John is on the mark with most of them. Git's documentation is very poor. Part of the problem stems for tutorials that were written to work with older versions of git (don't try using anything older than git 1.5 if you are a git newbie; git 1.4.x is far more user-hostile) or were written for use with systems built on top of git 1.4.x, such as Cogito. (I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git.) The tutorials that are distributed with git 1.5 are much better, but they clear do need more work.

It is true that the many of the man pages in git are lacking, and John's criticism of the fact that many man pages do not list all of the options that they take, but rather refer to other man pages is on point and accurate. It has gotten better (take a look at the git-diff man page from the git 1.4.x days, and laugh or cry, depending on your point of view) but there is still much work to be done. In practice, the better way to use the git man pages is to skip past the options section, and take a look at the Examples section. This shows a number of ways that a particular command might be used, just as a Unix master might say, "Grasshoper, see how you can use awk to do all of these amazing things."

I do take issue with John's assertion that git's philosophy has been to make life easy for the central maintainer, and not to pay much attention to the needs of individual contributors. That may have been Linus's development priorities but with Junio having taking over maintenance, there have been a lot of improvements in git 1.5.0 to make life easier for people who are tracking remote repositories and making changes, in particular the git remote command.

The most interesting observation which John made was the non-intuitive semantics of git-format-patches, and I did find it interesting that one commenter posted a solution which made perfect sense given other git commands, and yet didn't work. Obviously the person who posted the comment didn't bother to try it first, probably because in most other places git is actually pretty consistent; but git-format-patch is one of the places where most painfully is not. I view this as a bug that should be fixed, and fortunately I think it can be fixed without breaking the git-format-patches is currently being used. (The problem is that it doesn't use the standard notation so it is more convenient in the common case of how it is normally used, where the end point is not specified and is always the the tip of the current branch. I believe we can avoid the UI surprise by making git-format-patch use the standard revision range parsing if parameter contains the ".." or "..." operators. I'll have to try to prepare a patch which does this and see whether it gets accepted.)

So basically git does have short-comings, yes, but people will come out in different places about which tools is best for them, and that's OK. Actually, I think the ultimate solution for this problem is to build a bidrectoinal hg/git gateway. There are tools that will export from hg to git, and vice versa, and they are actually pretty sophisticated. I don't think it should be that painful to create a tool that does incremental exports in both directions, maintaining state so that the right thing happens when a commit gets made on the git side, and gets exported into hg, or vice versa. Ultimately I think that's the best solution, since that way people can use whatever tool they want, and still contribute and development as first class citizens. This is the main reason why I've held off on converting e2fsprogs to git (although I have made some private test repositories which I'll use to take advantage of git's superior annotation and query/log utilities); I don't want to make a git repository of e2fsprogs public until I'm sure that a bidrectional gateway tool won't require me to make any changes that affect the commit-id's, since that would invalidate any work that people have done that was based on a clone of the coverted git repository.

I have a rough design for how to do the bidirectional gateway, but the issue is finding time to implement it. Anyone with free time looking for a project? If so, contact me. I probably should have written this up as a potential Google Summer of Code project, but it's too late for this year. Oh, well.

There are times when you want to track the bleeding edge of a particular project, and having a new laptop is often one of those moments... I've recently bought an HP Compaq nx6320 and while most of it is working, one of the reasons I got it was because of Keith Packard's work on the RandR extensions for X. Well, I was definitely seeing this bug but with a small patch I can get the latest (experimental) packages for xserver-xorg-video-intel to work, and now with a few magic tweaks to my xorg.conf I can make my desktop expand to another monitor when I unsuspend at work, and contract back to just the laptop screen when I resume somewhere else. The Magic Expanding X Config First of all, when I got the driver to actually work, xrandr explained to me that my maximum resolution was 1400x1400:

Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400
VGA disconnected (normal left inverted right)
LVDS connected 1400x1050+0+0 (normal left inverted right) 305mm x 228mm
   1400x1050      60.0*+
   1280x800       60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
TV disconnected (normal left inverted right)

Using a few clues from Ross Burton I managed to get that "maximum 1400x1400" to increase. The trick is to add a "Virtual" setting for screen size into your "Screen" Section, like so:

Section "Screen"
        Identifier      "Default Screen"
        Device          "Intel 945GM/GMS/940GML"
        Monitor         "Laptop Panel"
        DefaultDepth    24
        SubSection "Display"
                Depth           24
                Virtual         2680 1050
        EndSubSection
EndSection

The downside of this is that if you set the width greater than 2048 (as I have here) then DRI won't work, so you won't get 3d stuff. I guess I can manage without ice-cream, just so long as I get my cake! Once I have the "Virtual" setting, when I resume at the office I can:

xrandr --output VGA --mode 1280x1024 --pos 1400x0

And then when I resume somewhere without the external monitor, I can:

xrandr --output VGA --off

Quibbles All of these features are kind of under development, but Xorg 7.3 will support this stuff, and then Gnome and suchlike will have to start thinking about how to deal with it. The dynamic screen changing is not something these environments are completely ready for. One example is that while I know that monitor is always on the RHS of my docking station, X wants it to be the primary monitor and Gnome moves both panels onto that screen. Perhaps that's not a choice that can be made automatically. Someone who had an external keyboard plugged into their docking station might want the opposite behaviour, and there is certainly no way the environment can magically know whether that monitor is left or right of my laptop screen. Eventually I expect that Gnome will recognise this monitor, and will make the panels and location automatically set the RandR environment to match the way I set it last time. It is also somewhat annoying that I have to actually choose the virtual size. No doubt this configuration will disappear in due course and it is not really surprising to see it for something which is admittedly quite bleeding edge! I noticed at LCA that Keith had his own screen set for a Virtual size of 2048x2048, and now I know why: that's the maximum size that is supported for DRI, so if I expand my desktop onto a 1280x1024 screen I'm going to have some overlap. In fact I could almost configure my external monitor to be above my normal screen and use it that way, but it would feel pretty weird I think. In the meantime I've gone back to "blank screen" for my screen saver which admittedly is currently the only application for 3d acceleration on my desktop. Remaining Problems with this Laptop The only outstanding issues for me with this laptop are:

• Suspend/Resume to RAM does not work (I use suspend to disk)
• Fingerprint Sensor does not work (AuthenTec say Linux support will be available later this year)

That's about the best Linux compatibility I have had for any of my last five laptops within a month of buying it. Most of them have had much more significant stuff less supported even after three years of use!

This article got me thinking about some new ways we could dramatically improve Debian. We had a lot of success in the past because good packaging helps people get over the fearful hump of installing and setting up new software in order to learn it. We're great at that, and the battle is pretty much over there.

Afterwards though, I don't think we're so good at helping our users through the scary parts. We include a lot of documentation, but that's not really cutting it any more. I set out to work on X because the scariest thing for a lot of users is getting X up and running, and I wanted to help them (and myself!) do it. We still don't have that nailed, but it's in the pipeline, so I think the next stage will be to help people do cool things with X that they wouldn't have done before. In the past, this would have involved doing things like setting xrdb settings, but these days such things aren't really useful. I'm going to continue brainstorming this, but to this end I've started a page on the wiki that's expressly for helping users get over some of the more difficult and interesting things that people might want to do with, or to, X.

Currently the only tip is on building packages using upstream's git HEAD and our own packaging, but I'm looking to put more stuff up in the nearish future. While we haven't been maintaining it so well, the XSF FAQ has a lot of these sorts of tips too.

I think we can push harder and be more clever about giving our users and ourselves cool things to do with Debian beyond packaging. The XSF move to git opened up the opportunity to easily track the X.org HEAD with the Debian packaging, and I think that sort of thing is indicative that we can be clever about enabling people at all stages of the development process, not just through the packaging itself. If you guys have any ideas for more X tips you'd like to see documented, please edit that wiki page or at least drop me or debian-x a mail so we can write it up for you. I want to see how far we can push this.

This is what I just wrote on Mark’s blog about Ian’s move to Sun:

“To some extent I m quite excited by what this might mean for OpenSolaris going forward, but Nexenta have been pushing the OS/Debian (or Ubuntu, more accurately) integration kick for some while without actually seeming to get any (public) traction within Sun
I ve also been disappointed by how little Ian seems to be in touch with how linux development works these days, but that s mostly from what he s been writing in public, rather than any particularly interaction with him, so hopefully that s not a fair summary.
I really hope that Sun can actually make this work.”

I thought I’d expand on this a bit, especially in light of my past moaning about Solaris and the installer and package management in the installer specifically.
What I really, really want, is a modern OS, which has an easily extensible and controllable installer, with good visibility and debugging infrastructure, which is very easy to manage on a grand scale - by which I mean hundreds or thousands of machines up to date, secure and consistent. At present, Ubuntu comes closest:

• d-i is a superb installer that is very easy to drive in an automated fashion – far easier than either kickstart or jumpstart in my opinion, even though both have been around far longer!
• People say apt-get, but that rather misses the point – or rather, it’s the icing on the cake. As most Debian or Ubuntu developers will tell you, the real strength of packages on the platform is in the underlying metadata, and the well maintained and enforced packaging Policy.
• Every packager is a specialist – more or less, if you’re packaging something in Ubuntu or Debian it’s because you use it, either professionally or personally, and have an interest in, and knowledge of, making it work as well as possible.
• The FHS – until my $PATH on Solaris is shorter than the next Harry Potter tome, Ubuntu has this won hands down.

However, there are some definite areas where Ubuntu or Debian (or Linux in general) struggle compared to Solaris – the sheer engineering resources that Sun can throw at a problem, and the talent they have available to them do result in fantastic results when they correctly identify a problem space. They also “own” Solaris – there’s no need for them to try and build awareness of a problem, and the correct solution, over a number of disparate communities.
ZFS and DTrace are the hackneyed and obvious projects here, but from a sysadmin perspective I think FMA, while far less sexy, is one of the best things Solaris10 has. And this is what I mean when I say operating system visibility.
The integration of Zones is also far better than Zen on Linux can offer currently, although both Red Hat and skx are working hard to fix this.
I’m really looking forward to the day when I get an OS that solves all these problems…