during the ongoing avalanche of posts on Planet and on Debian mailing lists where you ask everyone to be friendly and considerate, you have so far:

• deliberately framed the discussion in a gender-oriented fashion to throw away unjustified accusations of sexism;
• inflated a 85-post long mudslinging thread with my name in the topic (which is the Google version of publicly throwing stones at people);
• vomited on people on an IT news site and helped the site spreading misinformation about the Project;
• shown your own frustration by trying to find hidden sexual references in messages you find offensive;
• and I m probably missing a lot since I m not reading all that crap.

Pretty please. What you mean is Go fuck yourself , but the way you are saying it is no more friendly and actually much more rude. If you meant Go fuck yourself , why not just say it?

• I would have felt better since it s much less insulting.
• You would have felt better since it s really a relief to say it frankly.
• Everyone else would have felt better since this would have ended the discussion instead of polluting the lists with useless wanking.

You are just lying to yourselves if you think your contributions to a flamewar are more friendly than others. As for those starting discussions on the community and on the code of conduct: do you want a community like Ubuntu where everyone can be scornful and prepare lousy tricks, but always preserving the appearances (thanks to a mandatory broomstick), or a community like the Linux kernel, where people say frankly what they think, even if what they think is I hope you were on crack while writing that ? I know which one I choose. I may disagree with their technical development model, but at least they know that a software community is not a group of friends. And that is a sign of maturity.

I consider myself a fairly creative thinker but not even close to outrageously creative. I do have a few friends that fit that later category and one of them is my ex-roommate, Zack Brown (of kernel traffic fame. After many, really too many months of not seeing him, I met him for dinner last night under very snowy NYC conditions and as is always the case, he opened our evening meeting with an unusual and compelling story (and I usually am skeptical of his claims but my skepticism is most often totally unwarranted). Last night, his declaration was the following. He let me know that he has been working on a game, since before we met in 2001, which I was never knew about, and just recently all the pieces and this is metaphorical and literal for there are many pieces in the game have come together and has filed a patent for the game (news to me that you could patent a game). After thinking about it for 7 years(!!!), he has invented a game that I have to say looks stunningly interesting Crumble. It is simple in its rules and format but the strategy is quite demanding and complex. It is requires deep thought but also, it seems, a very visual mind. If you are interested in following its development and marketing (he is looking for manufacturers), you can keep track of developments on his blog. If you are a daring and patient soul (who can refrain from sneezing and laughing) you can make your own pieces and play sooner. And if you work at Google (NYC office) apparently, people are already playing, so you can join and Crumble Away!

I consider myself a fairly creative thinker but not even close to outrageously creative. I do have a few friends that fit that later category and one of them is my ex-roommate, Zack Brown (of kernel traffic fame. After many, really too many months of not seeing him, I met him for dinner last night under very snowy NYC conditions and as is always the case, he opened our evening meeting with an unusual and compelling story (and I usually am skeptical of his claims but my skepticism is most often totally unwarranted). Last night, his declaration was the following. He let me know that he has been working on a game, since before we met in 2001, which I was never knew about, and just recently all the pieces and this is metaphorical and literal for there are many pieces in the game have come together and has filed a patent for the game (news to me that you could patent a game). After thinking about it for 7 years(!!!), he has invented a game that I have to say looks stunningly interesting Crumble. It is simple in its rules and format but the strategy is quite demanding and complex. It is requires deep thought but also, it seems, a very visual mind. If you are interested in following its development and marketing (he is looking for manufacturers), you can keep track of developments on his blog. If you are a daring and patient soul (who can refrain from sneezing and laughing) you can make your own pieces and play sooner. And if you work at Google (NYC office) apparently, people are already playing, so you can join and Crumble Away!

Just saw the LF announcement:

http://video.linuxfoundation.org/category/video-category/-linux-foundation-video-contest

I love the effort, and I'm sure people will do great work, but there's a problem here. There needs to be *two* contests. The first, with the award that they propose, should be the serious one - The one that might get rolled out to suits and businesses everywhere, that we'd be proud to show off on our corporate web sites.

Then there's the second category. The "too honest" ones that get made for the equivalent "I'm a Mac" / "I'm a PC" ads and wind up on YouTube and email attachments. Not so much fan fiction as fan honesty. =)

I'm thinking start with a focus on a keyboard, crusted with Doritos and possibly an ashtray beside it, zoom out to a couple people playing Quake or Tetrinet or something that clearly haven't washed in days, zoom out, show that this is a dorm room. The room next to it (with cutaway walls and what not) has someone composing an email saying that either Gnome or KDE sux0rs. Further out, two floors, more rooms: Some people lit just by the glow of a CRT, decorated by Debian and Gentoo logos, maybe a vague outline of some porn on a monitor. The zoom out picks up to show ESR writing another book, maybe another ELER comic being written, someone "upgrading" their home wiring, various people arguing, one shower in the building total, and finish the zoom out and fade in the facade to the building: All shiny, glass and steel with a front door with a business person leading a tour past it saying "These are the Linux Development Labs, where all the magic happens. It's closed to visitors right now (points to goth in the back with a laptop who's probably running kismet), except you - you're welcome in." And then fade in the letters "We are Linux"

The soundtrack to this should be a background hum, just at the edge of what a TV speaker will play for volume. Queue in fifths and octaves during the zoom out, fade in some drum and base, some Simcity type of background talking and open up the chord as the words fade onto the screen.

(This is fiction, people. Noone expects another ELER)

After two and half months of development, new Gammu stable release is out. Since last testing version there are only minor changes in vCard export, but full changelog since 1.21.0 is quite long:

• Disable ATOBEX for Motorola V180.
• vCard can now store caller group and private flag (bug #269).
• vCard now stores location and memory type.
• Add ID for Nokia 6131 NFC (bug #775).
• Better skipping of corrupted messages in AT (bug #768).
• Autoload 6510 module if phone is S40 (bug #767).
• Add ID for Nokia 6500s (bug #770).
• Add automatic detection of Nokia phones (bug #770).
• Catch error when calls can not be deleted (bug #738).
• Better documentation of addnew (bug #734).
• Fix detection of OBEX capability on older Siemens phones.
• Try to detect wrongly formatted CMGL reply (bug #771);
• Handle phones which fail to report supported charsets.
• Fixed encoding of WAP indicator messages.
• Support for photos in vCard (bug #227).
• vC* saving now protects against buffer overflows.
• Drop own crosscompilation support, rely on CMake one.
• Also standard CMake parameters used when possible (eg. BUILDSHAREDLIBS).
• Search does not create thread for non existing devices.
• Fixed possible crash when backing up ringtones.
• Fix possible race condition in searching.
• Fixed invoking of CMake with output to custom directory.
• Compile on platforms where ssize_t does not exist.
• Fix detection of towlower on some compilers.
• Make Bluetooth compile using BCC.
• Fix compilation if strtoull does not exist.
• Compile on platforms where intptr_t does not exist.
• Fixed compilation in BCC (see changes above).
• Check whether compiler supports FUNCTION.
• Reimplement locking and add tests for it.
• GSM_SetDebugFileDescriptor now accepts flag whether file descriptor can be closed (bug #749).
• Soname change due to API breakage (see above).
• Fixed compilation on Mac OS X, thanks to Juan A. Bertolin for testing.
• Script gammu-config can now also work with whiptail.
• Minor fixes in gammu-config script.
• Extra spaces from connection or device name are now stripped.
• Automatically reinitialize FBUS connection if it is dropped.
• Disable OBEX with Motorola Z6c, it is broken (bug #746).
• Refresh manufacturer information on second init of AT (bug #746).
• Always get charset information on AT phone initialization.
• Better handling of OBEX switching for Siemens phones.
• Fix flags for 2630 and 3109c (bug #752).
• Fix handling of caller groups and picture IDs (bug #752).
• Properly set calendar location while adding (bug #747).
• Sign Windows binaries during build.
• Detect long FM station names (bug #727).
• Add ID for Nokia 2630b.
• Handle properly very long lines in vcards (bug #728).
• Do not build and install locales if gettext is not compiled.
• Increase number of calendar entries (bug #725).
• Leak free test runs.
• Support backup of phone phonebook from Siemens (bug #732).
• Properly handle GetNextMemory on Siemens (bug #732).
• Save textual category to backup (bug #737).
• Enable dashboard testing using CTest/CDash.
• Add option to do coverage analysis.
• Properly handle debug file closing.
• Add test case for debug logging.
• Fix decoding of some SMS messages from Nokia phones (bug #735).
• Hack for (still) unknown error code (bug #733).

You can download from usual place: http://cihar.com/gammu/, Binary packages will be available soon in all usual places (Debian Unstable, OpenSuse build service, Ubuntu PPA repository).

I am quite sad to announce that I am discontinuing Adept development for good. Since Kubuntu will be changing its default manager to KPackageKit (I wish everyone involved good luck), I have no further motivation to work on Adept at all. I have mostly done the 3.0 overhaul since Jonathan Riddell is my friend, and I like to make my friends happy. However, since this is no longer a factor, and my time is likely better invested elsewhere, I am giving up altogether. Of course, if anyone steps up for maintainership, I will happily delegate Adept to them. It is in a relatively good shape these days, I hope. I will keep the source (darcs) repositories around as long as reasonably possible. If you are interested in taking over, even despite the Adept userbase declining sharply in near future, please drop me a mail. With Adept goes also libept, a more general-purpose library for working with APT. I will be around when people need me to fix it, but won t add anything on my own. I am not even sure what is Enrico s status on libept, but probably just consider libept as good as orphaned, too. On a more personal note, this closes a long (very long) chapter in my free software life. I d like to thank everyone involved with it, there have been many of you. Moreover, this apparently cuts the few remaining ties I had to KDE development community I will miss you. well, maybe one of those days UPDATE: No, this does not mean I am no longer friends with Jonathan. I don t know why, but already two people managed to read it that way. To put it in hopefully less ambiguous words: The fact that Jonathan is my friend is no longer a factor just because he does not need Adept anymore. Hope that helps.

It's not really "news" that Dr. John Ousterhout is no longer the Tcl leader, that happened years ago, but it's finally been formalized: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/99e2693293b3c945/f4932ae01d74f8e1#f4932ae01d74f8e1 And people at large have taken notice, something that doesn't happen with Tcl very often. What I think is actually interesting about it is to consider the governance models for various programming languages. It seems that Tcl is something of an exception to the "benevolent dictator" model prevalent in the world of scripting languages. Python still uses this, with Guido van Rossum being the "BDFL", or Benevolent Dictator For Life). Perl used to, with Larry Wall, although I'm not up to date on what they do now. Ruby has Yukihiro "Matz" Matsumoto. The really big, established, popular languages like C, C++ and Java have committees that run them, although even there, the original development was often by small teams or individuals. What about other languages, like Lua, Erlang, Scala, Clojure, Haskell, OCaml, and so on and so forth? Which governance model is in use? How does it help or hinder the language's growth and adoption?

I'm pleased to make Emdebian Grip unstable available - a smaller, binary-compatible, Debian without manpages, without unwanted translation files (uses Emdebian TDebs) and without package documentation. The current packages will be migrated into Emdebian Grip testing in due course and then be released alongside Lenny.
Emdebian now has two flavours with Grip taking the intermediate position in terms of size whilst retaining full compatibility with Debian. Grip "cherry-picks" packages from Debian but retains the unchanged Debian sources - the main binary and library packages will exist but -dev, -doc and -dbg packages may well be missing, as well as some of the more unusual OR dependencies).
I've just converted my Acer Aspire1 (i386) - running XFCE - from Debian Lenny to Emdebian Grip:
607 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 184MB of archives.
After this operation, 278MB disk space will be freed.
Yes, update 600 packages and have nearly 300Mb more free space - that's a 400Kb space saving per package, on average. Gaining 90Mb more free space than the total size of the download is nice too. Comparisons are after using 'sudo apt-get clean' to remove downloaded archives:
Debian Lenny:
/dev/sda1 7.1G 1.2G 5.6G 17% /
Emdebian Grip (unstable)
/dev/sda1 7.1G 919M 5.8G 14% /
I make that about 25% smaller and not all packages installed on the machine have been "gripped" - (about 100 remain, many of which I should probably remove anyway).
Method: See http://www.emdebian.org/grip/index.html.
Add the Grip source to /etc/apt/sources.list.d/
deb http://buildd.emdebian.org/grip/ unstable main
$ sudo apt-get update
$ sudo apt-get install grip-config
This is a very important stage - Emdebian Grip is still in development and with the Lenny freeze, a few wrappers and helpers are needed to allow smooth migrations between Debian and Emdebian - grip-config is Architecture:all and contains the relevant scripts. (grip-config is Priority: required so debootstrap picks it up by default - this also means that grip-config cannot be part of Debian.) grip-config also includes the same key as the emdebian-archive-keyring package used by all Emdebian repositories.
Only after grip-config is installed should you use:
$ sudo apt-get dist-upgrade
Note that this is a complete replacement, including libc6, apt, coreutils, dpkg and (on i386) the stock kernel. As such, it can take a while to complete the installation once the download is complete. (As ever, if the kernel is updated, ensure you reboot before you next suspend to disk - even the minimal "gripping" changes to the kernel package may confuse grub when deciding whether to use the suspended image.)
A few packages are currently behind Debian Sid (notably ncurses) and I'm working on the scripts to enable full update automation.
One other problem is that /usr/share/locale/locale.alias has also disappeared which compromises localisation support right now but that's fairly easy to fix. (langupdate is also missing so there is no effective localisation support right now - I need to cross-build langupdate for the grip architectures.)
Note that this test install adds the Emdebian Grip repository to the existing Debian sources and relies on the em[0-9] version suffix to implement the upgrade - packages that are behind Debian get left at the Debian versions, you can also use normal pinning.
$ apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://buildd.emdebian.org unstable/main Packages
release v=0.1,o=Debian,a=sid,l=EmdebianGrip,c=main
origin buildd.emdebian.org
500 http://ftp.uk.debian.org sid/main Packages
release o=Debian,a=unstable,l=Debian,c=main
origin ftp.uk.debian.org
Pinned packages:
I've done some testing with debootstrap and a chroot works too - it should be possible to ally these packages with the normal Debian installer because there is no point "gripping" udebs that are already v.small and the packages that actually get installed are dictated by your choice of mirror. debian-live should be gaining support for Emdebian Grip in due course.
If someone fancies trying a test installation by choosing http://buildd.emdebian.org/grip as their mirror in d-i, let me know.
(Installing Grip is likely to result in further size gains as the Grip repository data does not support Recommends, so you don't have to try and get d-i to not use recommended packages).
Emdebian Grip (unstable) is now available for 7 architectures:
i386, amd64, arm, armel, mips, mipsel and powerpc.
(amd64 is only supported for debugging purposes, most of my development machines are amd64.)
Please report any and all bugs to the buildd.emdebian.org pseudo-package in the Debian BTS.
If you want more packages added, set up a Debian machine or chroot with all the packages you need (and only the ones you need) and send the
complete output of 'dpkg --get-selections' to the debian-embedded mailing list. Alternatively, file RFP bugs against buildd.emdebian.org at wishlist severity.
To see the current list of packages, use the search support
Headline packages:
coreutils, perl, python, apt, dpkg, grip-config, XFCE, debhelper, make, devscripts, sylpheed, iceweasel, drivel, xchat-gnome, gpe-tetris,
totem-gstreamer, liferea, thunar, evince, seahorse, gthumb, libsqlite3, pilot-link, python-gnome2, lua, tcl, gcc-4.3, binutils, libmysqlclient15off.
Currently, very few -dev packages exist in Grip. I'll make the emdebian-grip package available on Grip itself in due course so that new and bespoke packages can also be "gripped".
I'm migrating the current packages to Emdebian Grip testing soon and I'll be making a release of Emdebian Grip 1.0 (based on Debian 5.0 "Lenny") as well as Emdebian Crush 1.0 (based on Debian 5.0 "Lenny"), alongside the main Lenny release.
Finally, note that Grip is binary compatible with Debian - indeed, the binaries themselves are untouched - but bugs that appear in Emdebian Grip must only be filed against the buildd.emdebian.org pseudo-package. Right now, reportbug is not part of Emdebian Grip because I need a way of telling reportbug to only use the pseudo-package.
The main usability improvements will come in the development of Emdebian 2.0 (based on Debian 6.0 "Squeeze") - please consider Emdebian 1.0 as a "developer release", think back to what things were like with Slackware 1.0 or Debian buzz, rex or bo.
P.S. there is no concept of a release-critical bug in Emdebian Grip (at least, not yet) - the 1.0 release will happen as soon as Grip testing is in sync with the released Lenny (no matter what). Please do not file any bugs against buildd.emdebian.org with higher severity than important, it will just annoy people trying to fix RC bugs in Lenny.
If you are a maintainer in Debian and you inadvertently receive a bug report listed as 'found' in a version that ends in em[0-9], please reassign to buildd.emdebian.org, at severity no higher than important. Thanks.

My pretty old removals rss feed is now also moved to the new /rss/ location directly within FtpMaster hands. The old location has a permanent redirect, but please update your feedreader to the new one, which is http://ftp-master.debian.org/rss/removals.rss

I am somewhat under the feeling that the Debian project is currently facing a critical moment of its history. The development momentum has slowed down a lot during last months (approximately since Debconf and even more since October. I feel just like we're facing a moment where either we release Lenny (which is technically a great progress over Etch and, being a little bit more than 18 months after Etch, well suited wrt "modernity")....or we delay it for several months and will suffer more and more from the long freeze process (remember sarge). The momentum is then very likely to continue moving elsewhere (should I say Ubuntu or did everybody understand already?). And now we have to vote about firmware blobs, a proposal that popped up because a few (*very* few) vocal folks who (in my opinion) live on a planet that has no connection with the real world, think that we should triple check the freeness of each and every bit that is likely to be run on a Debian machine. Moreover, the proposal is worded and was pushed in a way that all (but one) options that would allow us to release lenny will need a 3:1 majority, which is obviously very hard to achieve (and as, there are several such proposals, the vote will be spread out among all of them). So, those folks who make the release of lenny their priority are now facing an interesting tactical choice: how the ..... should we vote for this to happen? I personnally did choose to vote this way: 5462371. Yes, I ranked "reaffirm the Social Contract" after everything, which makes me sad....and I blame the play on words by the zealots who pushed that proposal for forcing me to do this. I think this is the best "tactical" choice for those (and I hope we are a strong majority) who still make the *release* of the best possible and most possibly free operating system their priority. Believe me or not: if we don't release lenny soon, we will die slowly and rot peacefully. We will rot being 150% free and proud to be 150% free on our little planet, outside the solar system and the real world. *This* is the choice we are facing. Ah, and before I forget: film at 11, of course. PS: no comment system on my blog (I don't want to deal with spam and put complicated systems there). Please comment in public in your own blog. I very much prefer this over private comments which will be mostly ignored.

I'm a fairly big fan of the Rails web development framework; it uses a programming language I quite enjoy using, and deals with the "bureaucratic" overhead of writing a web application with minimal fuss, leaving me to think about the things that matter -- my application's functionality. To achieve this wonderous feat[1], Rails has a healthy injection of magic in the codebase, to do all sorts of interesting things, like autoload missing constants, and make intelligent guesses about what I want to happen in various situations. The problem comes when you want to reuse this magical code for something else. I'm working on a project at the moment where a bunch of the utility functions that are in the ActiveSupport gemlibrary would come in real handy. Well, that's OK, it's a separate gemlibrary from the rest of Rails, I'll just load it into my app, and I'm away. Or... not. The problem is that it would appear that a lot of the magic in the library is mandatory. Regardless of whether I want your constant autoloading magic, I've got it. I also can't just easily pick-and-mix the parts of the ActiveSupport library that I want, because there's all sorts of dependencies between the different chunks of the code that aren't expressed the "right way" -- everything gets loaded in the top-level active_support.rb, rather than being depended on by the files that need the classes. This is arguably a bug in ActiveSupport, but it's not something that's likely to be real high on anyone's annoyance list (since in practice ActiveSupport is a part of Rails, and when you use it in Rails it works Just Fine). So, to all programmers: magic is great, but be careful about excessive magic. In particular, don't make magic happen in places that the user didn't ask for, and allow people to turn off your magic when it's counter-productive to their purposes.

---

[1] This feat becomes more and more wonderous to me every time I look at the other available web development frameworks out there, especially ones in other languages. Despite having Rails to rip offtake inspiration from, they still seem to require a lot of boilerplate to achieve their goals. While there's a limited amount of boilerplate stripping you could do for a C program, Python people keep telling me that their language is just as powerful as Ruby -- and yet all the Python web framework usage I see is chock full of unnecessary cruft.

Init Seven has once again established themselves high on my ranking of awesome service providers. After battling and not resolving the problems with crap nVidia hardware, I was ready to return the server to Transtec, despite having invested a full day of work into it. Having a machine in a rack across town, with the looming danger of simple network traffic taking out the network card along with the bridged IPMI remote console (thus requiring me to head out to the colocation centre each time there was a problem) was just not going to justify the expense for the server. Init Seven connected a second switch port to my VLAN, which now allows me to hook the IPMI card directly to the LAN. This does not solve the problem with the sub-zero-quality crap manufactured by nVidia, but at least it makes it possible to resurrect the machine remotely, until the problem with the hardware has been addressed and dealt with by the forcedeth driver. And if that is not possible (due to nVidia pile of shit), then the last option is a separate network card attached to the riser card slot. In related news: Transtec was quick to proxy to the Supermicro s support (the motherboard manufacturer), and within a few hours, I had a newer forcedeth.c file. I compiled the driver, which seemed to handle larger packets just fine at first. Unfortunately, just as my hopes were up, the problems came back even with the driver from Supermicro. Back to start, do not collect any money. Regardless, I ve been impressed by Transtec s support level so far. Yes, I did purchase a five year express warranty extension, but it wasn t very expensive, definitely nowhere near the price for a real SLA. And yet, my requests to date have each been answered within a day at most, including such extravagant things as them providing doanloadable floppy images of the BIOS update, which Supermicro only distributes as Windows .exe file. Now if only they (and everyone else) would stop shipping nVidia hardware NP: AC/DC: Dirty Deeds Done Dirt Cheap

Many many (great) additions/clarifications have been made the Geek Girl list in the comments about geek representations in mainstream media. Two of the most important additions/comments were 1) “One glaring omission is Lisa Simpson” (Could not agree more ) 2) “Gadget was a mouse, not a chipmunk!” Also, for those that may not know, here is Nerd Girls, which I have written about in the past and really deserves to be part of this conversation. I have added some more comments and thoughts but below in the comment section.

As the Australian government wants to show how well they understand technology, they have started a blog about the “Digital Economy” [1]. So far they have hundreds of comments, most of which just tell them that their censorship ideas are wrong. In what may be related news, Barack Obama has announced details of some of his plans [2]. He will spend money on improving net access (something that the Australian government could learn from) and on improving schools (which will probably be about as effective as putting lipstick on a pig). I really hope that we don’t have someone in his administration deciding that improving schools requires censoring the Internet for the entire population (people tend to turn their brains off when it’s time to think about the children). He is also allocating money to road building (a stupid idea when cars are becoming increasingly expensive and world fuel supplies are running out - he should be building train and tram lines). But his idea about improving the energy efficiency of federal buildings is a really good idea, that will lead the development of technology that everyone can use to increase efficiency. He also wants to “modernise” the health-care system by moving to electronic medical records - this seems unlikely but I guess that all spending on IT is somehow good for those of us who are involved in the computer industry. One of his advisors has realised that there are economic benefits to really fixing the health-care system, so there is some hope that it will get fixed [3]. The FLOSS Manuals project has released a document about circumventing censorship systems [4], I expect that many people will be using them before the government even gets their Chinese-style filter installed (if they ever do).

• [1] http://www.dbcde.gov.au/communications_for_business/industry_development/digital_economy/future_directions_blog


• [2] http://www.politico.com/news/stories/1208/16258.html


• [3] http://tpmelectioncentral.talkingpointsmemo.com/2008/12/daschle_fixing_health_care_top.php


• [4] http://en.flossmanuals.net/CircumventionTools

There is quite a bit of software whose upstream authors decide that, as they are already using Git for development, the main distribution channel should be GitHub - This allows, yes, for quite a bit of flexibility, which many authors have taken advantage of. So, I just registered and set up http://githubredir.debian.net/ to make it easier for packagers to take advantage of it. Specifically, what does this redirector make? Given that GitHub allows for downloading as a .zip or as a .tar.gz any given commit, it suddenly becomes enough to git tag with a version number, and GitHub magically makes that version available for download. Which is sweet! Sometimes it is a bit problematic, though, to follow their format. Github gives a listing of the tags for each particular prooject, and each of those tags has a download page, with both archiving formats. I won't go into too much detail here - Thing is, going over several pages becomes painful for Debian's uscan, widely used for various of our QA processes. There are other implemented redirectors, such as the one used for SourceForge. This redirector is mainly meant to be consumed by Debian's uscan. Anybody who finds this system useful can freely use it, although you might be better served by the rich, official GitHub.com interface. Anyway - Enough repeating what I said on the http://githubredir.debian.net/ base page. Find it useful? Go ahead and use it!

I received a new laptop, a Dell Latitude E4300. I was a bit anxious with its level of support on Linux, because it only recently started being shipping, and it s full of recent Intel hardware. Also, with lenny being frozen for 5 months, we are currently a bit behind regarding hardware support. I installed lenny on it, as I usually run testing+APT pinning. What I m describing here is what is unsupported in lenny out of the box. Wireless:
Needs a 2.6.27 kernel (iwlagn driver), Lenny only has 2.6.26. Downloaded from the kernel team s unofficial repo. Firmware isn t packaged in Debian (firmware-iwlwifi needs an update). Needed to download it from Intel. Graphics:
Intel device, unsupported with lenny s driver (but vesa works surprisingly well, oI only noticed that I was using vesa when I tried to play a video and found out I had no xv support).
Works with experimental s Xorg and the experimental intel driver, but that Xorg needs some polishing. The evdev driver now handles all inputs, so the keymap has to be configured differently (as usual, #debian-x people were very helpful). Suspend/Resume:
Works out of the box using pm-utils. No need for quirks. All in all, it was easier than I expected, and support will probably be perfect for lenny+1/2 ;)

There is again some ongoing debate about Ruy gems and how to integrate them cleanly into the operating system. Let s put aside the fact such tools are useful on Windows and MacOS which don t have decent packaging systems. This is not a reason to dictate stupid requirements for other operating systems. Still, even without that, gems, eggs and the like are great tools for development; tools that developers can t work without today. They allow to easily setup a development environment with everything needed, at the latest versions. However they were not meant for integration and production environments, and will never be suitable for them. We re living in another world indeed: a world where servers must be up 24/7, where security issues flood your inbox every day, where you need dozens of servers running the very same software. This world is the Earth. Python eggs and Ruby gems were designed for the same target audience and with similar requirements; as such, they share the same deficiencies when it comes to other audiences:

1. They replace the operating system s packaging tool. This is very nice to not wait for the packagers when you want the latest development version, but you lose track of what is actually installed. In production, you need to know exactly what s installed and at what version. You also need to know what you will need to update in case of a security issue.
2. They install packages automatically on the system. This is really the biggest WTF; there are some reasons to do that to begin with, but they are all wrong.
3. They use a specific file format. This requirement comes mostly from the Windows world, and it really makes no sense on Unix. It makes it much harder to integrate complex applications using components in different languages.
4. They ship all files at the same place, happily violating the FHS and making it even harder to integrate with other things.

Python tools (setuptools and easy_install) have shifted their philosophy and brought a few small improvements which allow us to easily work around issues 1-3. These tools now include all you need to build a development environment in any directory that will not have an impact on the system packaging, making a clear distinction between the two targets. Furthermore, the metadata is shipped separately and can safely be included in a distribution package. Similarly, modules will not be installed automatically on your system. I have yet to see such a move from Ruby developers. However, what we are still missing is something along the lines of dh_make_perl: starting from a CPAN module, it will generate a clean and working Debian package in a few minutes. There have been some similar attempts for Python, but nothing as efficient. And I am certainly guilty of not having done something in this area, as one of the most knowledgeable of issues we encounter while packaging Python modules. As a note, I should add the underlying issue behind all of this is still the same: the NIH syndrome. Developers are reinventing the wheel, engine and transmission. Which is not that bad per se, but by not looking at existing solutions for the problem of making a car move, they are inventing a square wheel, a steam-powered engine and a superconductor-powered magnetic transmission. For example, while trying to fix the 4th of items listed earlier and they are really willing to fix it and several more general issues, setuptools developers forgot to look at the existing solutions:

• API versioning in /usr/include/package-X.Y
• ABI versioning of libraries
• Build/install-time requirements gathering using an extensible format with pkg-config
• Automated generation of config.h containing all system-specific macros (including paths), with autoconf
• The Mono Global assembly cache which solves some of the specific issues of interpreted languages

Certainly, the existing tools are everything but perfect, and not necessarily suitable for Ruby and Python, but some of the design ideas behind them are clearly the good solutions to some of the issues of software development and integration. Adapting these ideas to radically different languages is going to take more time than just throwing other layers of symlink farms.

I received quite some comments on my rant about Ruby on Rails a few days ago; I guess I must have received some inbound link on a ruby-fanboy-website or some such. Most of it is just bashing me since, I'll admit, my post wasn't very constructive (and which according to my policy of only blocking spammers I've not moderated away), some of it just posits another opinion about packaging (which is valid), and one Eric Anderson gave a good and constructive set of arguments that I just have to reply to. First of all, yes, I hate RubyGems more than I hate Ruby on Rails. However, Ruby on Rails is the major success story in the Ruby community, and the main reason why people use that language; it's not unfair to say that I won't use RoR because of RubyGems. But perhaps I should've been clearer. Anyway. Eric mentions that RubyGems "solves two problems that other packaging systems are not addressing": the ability to install two versions of the same library, and the ability to install a single package on multiple operating systems. Well, first of all, the latter one simply is not true. There's CPAN.pm, which does much the same thing as RubyGems; but much of CPAN can be easily turned into a Debian (or RPM, or whatnot) package. The few cases where it can't, you're usually dealing with a broken CPAN package, anyway. There are similar things for Python (egg), and, heck, even TeX (CTAN). The fact that other scripting languages have proper and working packaging systems only outlines that there really isn't an excuse for the horrors of RubyGems. Second, the fact that you even need to be able to install multiple versions of a library really shows that there's a problem with your development ecosystem. C, Perl, and Python programmers are used to stable APIs, and prefer not to change their APIs all that much. Most packaging systems reflect that preference, and deal with incompatible API changes the way they should: as the exception, rather than the rule. The people in the Ruby ecosystem clearly have a different opinion on that, which probably results in the difference in packaging system requirements. Personally, I prefer the non-Ruby way—I'll leave the discussion about "what happens when you need to do an urgent security update of one of your libraries but the API has changed three times since you last looked at it and now the library update breaks your application" as an excercise to the reader. In closing, I'd like to reply to this one sentence that Eric put in his comment:

And of course there is no reason software cannot start as a gem (for people close to the ruby community) but as it's popularity increases packages can be created that are more tightly integrated into the native package manager.

Well, in an ideal world, he'd be right: there would be no reason. Unfortunately, in the RubyGems world—which is far, far away from an ideal world—the fact is that packaging RubyGems in a sane way so that they'll integrate with the rest of a Debian system is simply impossible. You simply cannot currently go from a gem and create a package out of that, because of how gems are done. That, more than anything, was what I was objecting to. I can understand that many Ruby developers do not care about this much; that they are used to RubyGems, and that they can geet anything they need using that system. However, they should understand that different people have different preferences, and that packages for systems other than RubyGems is going to be necessary if their software is to become popular beyond the select set of people who care enough about Ruby. I personally know of plenty of people (myself included) who prefer things to be installed as operating-system level packages on the Linux systems they install; and even if it's not your personal preference to do things that way, you should at the very least not stand in the way of those who do.

Thanks to some unexplained comments on some oldish entries on my blog, I found -with a couple of days of delay- Rubigem is from Mars, Apt-get is from Venus, in Pelle's weblog. And no, I have not yet read the huge amount of comments generated from it... Still, I replied with the following text - And I am leaving this blog post in place to remind me to further extend my opinions later on.
Wow... Quite a bit of comments. And yes, given that the author wrote a (very well phrased and balanced) post, I feel obliged to reply. But given that he refered to me first, I'll just skip the chatter for later - I'm tired this time of day ;-)
Pelle, I agree with you - This problem is because we are from two very different mindsets. I have already said so - http://www.gwolf.org/soft/debian+rails is a witness to that point.
But I do not think the divide is between sysadmins and developers. I am a developer that grew from the sysadmin stance, but that's not AFAICT that much the fact in Debian.
Thing is, in a distribution, we try to cater for common users. I have a couple of Rails apps under development that I expect to be able to package for Debian, and I think can be very useful for the general public.
Now, how is the user experience when you install a desktop application, in whatever language/framework it is written? You don't care what the platform is - you care that it integrates nicely with your environment. Yes, the webapp arena is a bit more difficult - but we have achieved quite a bit of advance in that way. Feel like using a PHP webapp? Just install it, and it's there. A Python webapp? Same thing. A Perl webapp? As long as you don't do some black magic (and that's one of the main factors that motivated me away from mod_perl), the same: Just ask apt-get to install it and you are set.
But... What about installing a Rails application? From a package manager? For a user who does not really care about what design philosophy you followed, who might not even know what a MVC pattern is?
Thing is, distributions aim at _users_. And yes, I have gradually adopted a user's point of view. I very seldom install anything not available as a .deb - and if I do, I try to keep it clean enough so I can package it for my personal use later on.
Anyway... I will post a copy of this message in my blog (http://gwolf.org/), partly as a reminder to come back here and read the rest of the buzz. And to go to the other post referenced here. And, of course, I invite other people involved in Ruby and Debian to continue sharing this - I am sure I am not the only person (or, in more fairness, that Debian's pkg-ruby-extras team is not the only team) interested in bridging this huge divide and get to a point we can interact better - And I am sure that among the Rubyists many people will also value having their code usable by non-developers as well.