Following my rebuild of all packages using /bin/dash as /bin/sh, we now have a nice list of bugs. Those bugs are cool:

• The relaxed NMU rules apply to them, since they are part of the dash release goal. Which means that they can all be fixed using 0-day NMUs.
• Most of them are really easy to fix. (for many of them, a patch is already provided by Ubuntu)

So, if you want to get involved in Debian development, try to submit NMU patches for those bugs. If you want me to sponsor the upload, please Cc me when you submit the patch. And even if you don’t care about Debian, but only about Ubuntu (which is fondamentally wrong, as everybody knows that Ubuntu is based on Debian), fixing these bugs also helps Ubuntu a lot: all those bugs hurt Ubuntu, since Ubuntu uses dash as /bin/sh by default, and, even if the packages in Ubuntu have been patched, it’s still causing additional work every time a new package is uploaded to Debian, and has to imported in Ubuntu. If you have questions with the process, please ask them using the comments below. Notes:
I use the following process on those bugs, and it’s probably a good idea that you do the same if you intent to submit patches:

• build the package with a chroot using bash
• build the package with a chroot using dash (you can just use a different pbuilder tarball for that). Check that the problem can be reproduced.
• fix the package
• build the new package with a chroot using bash
• build the new package with a chroot using dash
• compare the built packages using debdiff for old_package_using_bash, new_package_using_bash, and new_package_using_dash. If the content doesn’t match, we have a problem.

If you submit NMU patches, please also have a look at the other bugs in the package, or at the lintian output. I don’t mind sponsoring small fixes for non-cosmetic/non-wishlist stuff at the same time.

About a month ago I added symbol version information to the zlib package, allowing dpkg-shlibdeps to calculate more relaxed dependencies for packages using the library. The results have been very satisfying so far - of the 1784 packages depending on zlib1g on amd64:

• 532 depend on zlib1g 1:1.2.3.3.dfsg-1, the version which introduced support for _FILE_OFFSET_BITS=64 and the version which packages that were built before zlib1g had symbol version information will depend on.
• 333 depend on version 1:1.2.1, which predates sarge let alone etch.
• 74 depend on the even earlier version 1:1.1.4-1.
• 843 packages have an unversioned dependency on zlib1g - a quick glance at some of these indicates that (as I would expect) they either don’t actually link against zlib directly or do but don’t use any symbols from it.
• The remaining two packages are the -dev and -dbg packages which have an exact dependency on the library package they were built against.

Of course, zlib is a particularly good use case for this - both API and ABI are extremely stable and most of the changes in interface are in rarely used features - but it’s still good to see it working in practice. I don’t need to worry nearly so much as I would have done previously about keeping other packages out of testing. If you maintain a library written in C I would encourage you to take a look at implementing this, it’s very straightforward. Libraries written in other languages may cause more difficulty. There are some automatically generated symbol files in mole which provide a good starting point (I didn’t use them since upstream already had a more exact list of versions at which symbols were introduced) and support is already present in debhelper. The main things to watch out for when using the mole data are backwards compatible ABI changes which don’t just add new symbols (for example, if new values are accepted by a function) and variations between architectures. Kudos to Rapha l for all the work he’s put into this.

Since 3 weeks, half of my worktime (but i don't have worked that much, due to another real life occupation) has been dedicated to setting up a meeting for the OCaml community in Paris. This is the first public meeting about OCaml in France. It will be located at ENST (Telecom Paris) on January, the 26th 2008. This should be an occasion for the european OCaml community to meet in the real life and to discuss the hottest current topics of OCaml. I hope that this meeting will help people to begin creating a more consistent community around OCaml. In fact, the community already exists -- but it will be a time to meet several members that has never meet before... More information and subscribtion

New Gammu testing version is out. Besides fixing there is important feature for people finding proper flags for not supported phones - you can do it now without recompiling Gammu! Full list of changes:

• Phone features now can be defined in configuration, so there is no need to modify common/gsmphones.c for testing different settings.
• Config file loading behaves more consistent in lookup. In some cases it can now find different configuration file.

You can download from usual place: http://cihar.com/gammu/.

• The Future of Ideas is now Free
• Looking for Cash? VCs Have More Than Ever
• 3 at Normandy
  I love how technology enables people to do stuff like that.
• Lyons-Dubai
  I live there (Lyon, not Dubai) and I'm not sure it's worth the trouble.
• Buns
• SimCity goes free software
  Woo-hoo!

I've just rolled up release 0.1.0 of r (pronounced littler). A few changes made it into this release:

• A new option -l (with long form --packages) to load packages into the R session. This is useful when you have data-processing one-liners as it does away with the explicit library(foo) inside your actual R expression. For added bonus, library() is wrapped in a suppressMessage() call.
• The --no-restore option is now passed to the embedded R session.
• Argument handling was improved / corrected for a corner case.
• Output shown by --help was improved.
• The manual page and README were updated accordingly.
• The datasets package will now be autoloaded.
• Two minor fixes went into bootstrap, the wrapper around autotools and friends.
• The cache-clearing part of the R package updater example update.r was improved.
• We added some comparisons to Rscript in the timing tests.

As usual, our code in our svn archive, on my r page, and in the local directory here. A fresh package is in Debian's incoming queue, and Jeff's littler page at Vanderbilt should reflect the new release soon too.

While analysing the pole setters in our internal bouncers-Hitlist i found that some of them run a mail2news-Gateway.

The problem is: our Mailinglists leave Mail-Headers mostly untouched, and so headers like X-Trace or X-Complaints-To are passed through without modifications.

If a mail containing those headers is handed over to inews (as in INN) it rejects it, and the bounce comes back to us:

<XXXXX@XXX.com>: Command died with status 1: "/usr/bin/maildrop". Command
output: inews: cannot send article to server: 441 Can't set system
"X-Complaints-To" header inews: article not posted

so people: fix your systems. if you do more with listmail than dropping it somewhere make sure that the bounces your system produces go to someone who can fix it. We (as in listmasters) normally simply unsubscribe those.

btw: we talk about 18181 bounces since 08.2004 in this case.

after neglecting her for over four months I took "felicidad" (my western guitar) out of her case tonight. at the beginning of today's date she was quite "desafinado" but after a few minutes of tuning we started to have a nice session.

& it's amazing that my fingers (although they have lost the thick skin on the fingertips) still remember more or less what to do with the strings.

• look (ferrara buskers festival 2007)
• listen (last CD)

For the last four years, I have left my life and home to return to my mother’s far more precarious and fragile life in Puerto Rico. I do so to visit. But I also do so to give her caretaker, Milagro, a much needed break. I returned on December 18th and found my mother nearly in the same state as she was in October. Far worse than a year ago, but she still struck me as my mother, if nothing else because she knew I was her daughter. Over the course of a week, all of that changed. After a series of howling fits, by the end of my first week there, she no longer knew she was my mother. While I knew this would eventually happen, I was still caught off guard. You see, prior to my arrival, and since my last visit in late October, she asked me on the phone, and my sister and Milagro in PR, *nearly everyday,* when I was coming back. So even though she asked when her daughter, who she knew lived and worked in the city of New York, was coming back over and over again for 8 weeks, this seemingly hard-wired thought quickly vaporized thanks to what is a disease of the brain, but what strikes experientially as a cruel disease of the soul and personality. So while 2007 was overall a pretty good year, it is also the year when in certain respects my mother died, at least for me in so far she has morphed into someone remarkably different from the person I once knew. Now she only remembers small scraps of her life. She knows she is from Russia, she knows that she lives in the Casa de Vera (which she thinks is her bed), she knows she loves the dog, she knows that she had parents (and she would like to return to them but does not know where they are), she knows she has a good friend who is a painter (I think she had a massive crush on him if she still remembers him and not me but otherwise, everything is so twisted, so jumbled or so gone, it is beyond stunning. She certainly knew I was around and helping for she got upset when she knew I was leaving, often bursting in tears, asking me to take her to New York. But she just knew me as Gabriella from Nueva York who brought her novio bueno to PR and not as anyone else. It is certainly not easy to see this, to experience it day in and out but it is what it is and there is no running from it. Logistically it is also beyond hard to take care of my mom. To get her to eat, to calm down after one of her morning fits (she always, always, always had a raging fit in the morning, the afternoon and evenings being far more calm periods), to convince her to wear her dentures (which is the only remedy to stop her from spitting all over the place), to dress her, to deal with her in the middle of the night, often twice, are all extraordinarily challenging. Very quickly, your waking hours fill up with seemingly endless tasks and this I guess is, in some respects, a hidden blessing; there is just a lot less time to ruminate over how all of this, frankly, sucks. It is only later, late at night, early in the morning, or on the plane ride home where the darkness of her life would set deeply into my own. It may be obvious why this state and experience is tough but there are two parts that I find particularly rough. If my mother’s state is one of near total chaos and entropy, there is one thing that is utterly clear. She knows she is suffering and she wants out. On particularly bad days, she would mutter or sometimes yell loudly that she wants to die and would ask for the medicine that would accomplish this. She would even sometimes call me mala for not giving her this medicine. It is certainly not the case that everyone with Alzheimers goes through what my mother does. Apparently, some experience the illness quietly and peacefully. This is so not the case for my mother, who lived a particularly hard yet vibrant life. Donning a difficult personality, she lived lived as fully as she could and it is clear that as life leaves her, she would rather not be around to experience what is a cruel exorcism of self. Thankfully, she is not constantly or not even mostly in a suicidal state. I think she at times forgets how lousy she feels and rather enjoys the rather limited life she has. And at this point, I just hope that she continues to have calm or even happy moments. The second surprise concerns my own memories. My mother has had this rare form of Alzheimers, Posterior Cortical Atrophy, for at least 6, possible 7 years now, though we only received the official diagnosis 2003, which is the year when when I first started to write the occasional post about my experiences with her. In 2003 and 2004, she was pretty functionally in tact and it has only been the last 2.5 years when the persistent decline has set in, whittling her capacities and memories to what seems to be a bare minimum. But because her presence and reality is nothing short of totally enveloping and drowning, I am starting to lose my own memory of my mother prior to her illness. If Alzheimers robs people of their memories, I have come to realize, that if you are not careful, it is a thief that can also rob your own memories. I think it is for this reason that I have become so attached to my mother’s stuff her furniture, her paintings some of which I have taken back with me. They are material vehicles that transport me back to the past when my mother was in a different state and place. Now it is clear that if the challenge is to deal with the emotional toll this illness causes, it as much summoning the will and performing the labor to retain and recall my older memories of her.

mutt-patched: sidebar keybindings mutt-patched it's really cool, thanks Myon for advertising it. Actually I've tried it only in the hope that it could solve bug #459739 (don't bother trying: it doesn't), but I'm now liking it, especially the sidebar patch. Unfortunately it lacks default keybindings for moving the sidebar cursor (why the heck: since the sidebar is enabled by default, am I supposed only to look at it?). Here are mine, in case someone wants a "plug and play" configuration for her .muttrc:

zack@aquarium:~$ cat .muttrc  tail -n 6
# mutt sidebar settings
bind index,pager \CP sidebar-prev
bind index,pager \CN sidebar-next
bind index,pager \CO sidebar-open
macro index,pager B '<enter-command>toggle sidebar_visible<enter>'
color sidebar_new yellow default

They are basically a subset of those proposed on the homepage, but I did not like changing the default semantics of b. See also bug #459725.

Here is something I wrote some while ago, hope this will be useful for some World of Warcraft p(l)ayers. Has no other relation to Linux or Debian, except it works on it flawlessly. Also note that 2.3.2 patch went live last week. It is not a secret anymore that mages of all talent specs will be getting a present when patch 2.3.2 hits the live realms - the Ice Block will be available from any friendly mage trainer for a nominal fee. Currently this spell requires a whopping 21 point investment into the Frost talent tree. With patch 2.3.2 Ice Block will become trainable to all mages, Ice Barrier will take it’s place in the talent tree and a new awesome talent - Icy Veins will take the place of the Ice Barrier, so that even frost mages have a new toy to gain in this 2.3.2 mage winterly fiesta. While there is a significant proportion of mages that are frost for PVP or grinding survival purposes, a large proportion of mage population have never used Ice Block or haven’t used it for a while. For that reason, the rest of this article (after the break) will explore all the great uses of Ice Block, that all of you can look forward when patch 2.3.2 hits the live realms (or sooner, if this article convinces you to re-spec frost :)). So, what does the Ice Block do? When you cast the Ice Block, it purges you from all debuffs and releases you from all snares, you get frozen solid into a large block of ice (same look as hunter’s ice trap) and for 10 seconds you are immune to all damage, but unable to do anything - no moving, casting anything, no bandages, nothing. Getting rid of: Ice Block is a buff, so you can get out of the Ice Block by right-clicking it off at any time. Another way for keyboard-addicted mages is to press Ice Block keybinding button again (after the global cooldown is done). Enemy shamans can purge it off you and priests can mass dispel your Ice Block in PVP. Cooldown: the Ice Block is on 5 minute cooldown, which can be ended early using the Cold Snap talent from the mage frost tree. To prevent mages casting two ice blocks back to back by using the Cold Snap, Blizzard added the Hypothermia debuff (in 2.1) that prevents you from casting the Ice Block 30 seconds after the last cast. The main use of Ice Block is to survive pulling aggro in groups. While we all know that “good mages don’t draw aggro”, experienced players can easily show situations when drawing aggro is not mages fault and surviving that can be the difference between a wipe and a win. When Ice Block is used, your threat is NOT reduced, so you need to stay inside the Ice Block at least until you are under 130% of the tanks threat. After you Ice Block, the mob will run to the next person on the threat list. If your tank is dead, Ice Block will send the mob to another DPS or healer giving you a couple seconds to nuke it when it will be running back to you again. I have seen a few bosses loose their last 2-3% of health running between mages with Ice Block and hunters with Feign Death after a unfortunate death of the main tank. Ice Block is a great way to get rid of almost all debuffs that exist in the game: warlock DoTs, stuns, snares, polymorph, mind control … Even boss debuffs go away in a snap - Garrote from Moroes, Demonic Chains from Illhoof and many more deadly debuffs are no threat to a mage with an Ice Block ready. Ice Block can be used as an alternative to Slow Fall if you’re out of Light Feathers. Just do not cast it too high in the air - if the 10 seconds tick by and you haven’t hit the land yet .. you could as well kiss 10% of your durability goodbye. When solo grinding there is noone to draw aggro from you, so the mobs will continue to beat on your personal icy sculpture, however during that time your Water Elemental or other battle pets could be dishing some damage, your cooldowns will tick down and also you will also regenerate some mana inside the Ice Block. The Ice Block could thus make the difference between your death and Frost Nova+Blink+Blizzard and their death. Have you had some fun experience with Ice Block? Leave a comment so that others could repeat it too!

If you follow online discussions of programming languages, you'll occasionally see articles about language X "dying". It is, however, a bad metaphor, because the "life cycle" of a programming language is different from single biological units, of which you can definitely say at some point "He's not pining ... this is an ex-parrot!". Once a programming language is widely deployed, it simply won't up and disappear from one day to the next. Too many people and companies depend on it, and replacing it is difficult enough, that the "switching costs" will keep it in place for many years. The obvious example is Cobol. This effect works in favor of languages that are not "the new thing", and means they will probably not truly cease to be used for many, many years. On the other hand, it's also pretty easy to tell which way the wind is blowing and get an idea of what's hot and what's not. Java got hyped a lot in the past, now it's Ruby. Scala is beginning to get hyped some, so is Erlang. Careful observers can spot the rise of languages as they hit the early stages of the technology adoption lifecycle. By paying attention to what's going on in the wider world, it's also possible to see when languages are used less and less for new projects, and solely kept on for the legacy systems. I think this is what most people mean by "dying", but of course it creates confusion, because it's clear that the language is still utilized. In some cases, I think it may be possible that a language continues to be more widely adopted, yet still seems to lag behind, simply because other languages are being adopted at a significantly higher rate. So what it's really about is two factors: how widely deployed is the language in any given moment, and, perhaps more importantly, the rate of adoption - is it accelerating or slowing down? Are more people jumping on the bandwagon, or is the language being used less by innovators, early adopters, and new projects? You need both those coordinates to understand where a language is at - it may be huge but declining, small but on its way up, or a niche language that never achieved widespread usage that isn't catching on any more. The last one is the one you'd probably want to be wary of. The first two will probably be ok as long as you understand what you're getting, and the type of user or organization you are matches where the language is at in its lifecycle. I think that perhaps those interested in discussing these things seriously ought to find some good terms to use. "Forth's rate of adoption is declining" doesn't sound as exciting as "Java is dying!" though. "Fortran's diffusion is decelerating" doesn't have much of a ring to it. Any other ideas?

After four or so months, it's time for another Hecl "checkpoint". Those who are seriously interested really ought to be getting Hecl from subversion, however, it's a good idea to tie up the loose ends every now and then, and put something that's easy to fetch for the casual user. https://sourceforge.net/project/showfiles.php?group_id=122383 This release contains a number of interesting things:

• Alpha support for Java integration. For example:

  java java.lang.System sys
  set ms [sys currentTimeMillis]
  

• Alpha support for Google Android. This utilizes the Java integration system above heavily. What sets it apart from just writing code in Java is that on top of the building blocks, I've started to write little bits of Hecl code to make common things very straightforward, layering on top of the Java API.
• Numerous fixes in the code, documentation, and build system.

Bits from the Debian i18n meeting (Extremadura 2007)

From December 12th to December 15th, Junta de Extremadura hosted another one of the Debian Meetings; five i18n guys shared ideas, food, buses and fun with the Debian KDE maintainers. We would like to thank Extremadura for hosting us during the Hispalinux Meeting 2007, the event was held at Universad de Derecho (Law University) in Caceres, Spain.

These are the minutes, results and notes from our work, it is a brief description but hopefully complete of what we have done and what is still missing/pending.

Thanks to Cesar (cek) we had the chance to work on churro (i18n.debian.net) locally; the server is still running a 2.4 kernel because of some "tick" problems with 2.6 series, the last one tried was 2.6.21 and we should try newer ones, in order to support upgrades and not get stuck with 2.4, we hope Cesar will find time to test new Debian kernels.

First, let me introduce everybody to the services, robots and resources being hosted by i18n.d.n:

• MoinMoin wiki for local and simple reference documentation, it contains all the links to the below resources. (http://i18n.debian.net/wiki/)
• Pootle experimental server
• dl10n scripts, aka dl10n robots (codename Lion), these scripts are responsible for the status of pseudo URLs used by some translation teams, by the Project Smith and by the NMU Priority List for i18n NMU Campaign
• Synchronization of the i18n material used by the Debian website to generate translation statistics about PO and PO-debconf
• Generation of Compendium PO files per-language
• Different types of statistics
• Other non user-visible services like a full source mirror for stable, testing, unstable and experimental, used by the scripts and robots.
• DDTP, Debian Descriptions Translation Project
• DDTSS, The Debian Distributed Translation Server Satellite, a web front-end for DDTP, now integrated to DDTP to use the Database back-end instead of the e-mail interface.

And, at some point, we found important to state clear the acronyms and names used in related DDTP projects/tools:

• DDTS, Debian Description Translation Server, this is the main "back-end" used in DDTP, it tends to be the interface between translator tools (present and future ones) and the database;
• ddt.cgi is a CGI interface that is able to provide info for specific packages or translations, including diffs, related packages and active/inactive descriptions.
• DDTC which is the old (and still functional) command line client for DDTP.

We took the chance to organize a few things on churro, old accounts were cleaned out and removed, we moved from /org to /srv and got more GBs of space to the "playground". Old files were also removed and some are schedule to deletion on early 2008. With the reallocation of /org we also find some more space to /home and /var, we reorganize some of the links on the web space (specially to remove services from people's accounts), and we changed the mirror script to also synchronize the Packages and Contents files.

Grisu and Martijn worked mainly on DDTP and DDTSS integration. DDTSS now provides statistics for stable, testing and unstable, we are also working with Debian Med to provide support and infrastructure to a specific audience, like packages related to Medicine. The conversion to talk directly with DDTP/DDTS database also provided:

• Fetching new translations is almost instantaneous and marks translation as requested (avoiding duplicated works via the e-mail interface).
• After sufficient reviews occurred, the upload is instant
• Committed DDTS / DDTSS / DDTP website generation into SVN
  • Added READMEs for the above directories

DDTSS now announces the user using authentication because of its integration with the Database backend used by DDTP. Quick trivia: DDTP is now a compound of 25 languages occupying 18 GBytes.

A few days before the meeting we had the offer to use "AUTOBYHAND" to upload a package with the Translation-* files. The package is now called 'ddtp-translations' and we worked during the meeting to create scripts to build the package and to test it on the archive side. This approach allow Debian i18n Team to upload new translations and remove old ones (or inactive ones) without bother FTP Master Team. Special thanks to Anthony Town, he has been working with us to prove tips, fixes and info on how to produce the package and the scripts. The code is available in the debian-l10n SVN under pkg-ddtp-translations:
http://svn.debian.org/viewsvn/debian-l10n/pkg-ddtp-translations

In our case, "BYHAND" processing consists of a simple tarball of the main,contrib,non-free /i18n/Translation-*, we decide to work on a set of scripts to make it easier to create new packages (ddtp-translations) in a consistent way and keeping debian/changelog up-to-date. We also made some suggestions to the script what will run on the archive side to check the tarball structure, base on the examples of debian-maintainers and debtags (tags-override).

One of our initial targets for the meeting with regards to Pootle and Debian was to try big PO files per language, fortunately, Nicolas and Friedel were able to increase Pootle performance enough to get a few languages from DDTP loaded in Pootle. Using the upstream Pootle-diet branch, which uses a database back-end for the generation of statistics, the time to browse the DDTP POs of a language (~20.000 files) went down to a dozen of seconds.

Speaking about Pootle, Friedel gave us a good picture of what is coming next in terms of Pootle's development. There are improvements planned in the areas of permissions and rights delegation, as well as file management (for projects and templates). Improved management of terminology projects is also planned.

Improvements in the QA capabilities of the translate toolkit and Pootle are planned to help with the "false positives" of the pofilter checks. Better reuse of existing translations will become possible by using better translation memory techniques. There is also work planned on formats and converters involving, for example, XLIFF, TMX, TRADOS and WordFast.

Another pending task for quite a while was the CVS migration to SVN, it is now done, with a new layout. Commits to the CVS were disabled and every single script or resource depending on CVS should be changed to use SVN. For now, we are publishing (via HTTP) the status files generated by the pseudo-urls robots until we can fix the scripts to re-enable the commit of the files. You can find them here: http://i18n.debian.net/debian-l10n/status/

We are pretty happy with the changes and results of the work during those days, but we still have some items pending on our TODO list:

• More advertisement and usage information about PO Compendiums
  There are two use cases are identified:
  
  • Filling new PO files.
  • QA work to find inconsistent translations.
  Maybe Eddy would love to do that? :-)
• Extend the duration of the statistics history. (Nekral)
• Debian packages of the services running on churro
  • DDTP (Grisu)
  • DDTSS (Martijn)
  • dl10n (Nekral)
• DDTP: add some scripts to handle packages with version in the description (e.g. kernel and kernel modules) (Martijn)
• DDTP: Standard generation of the translation tarballs (faw)
• DDTP: document the bracketed stats on the main page (faw)
• DDTC: should be updated to match the current features. Documentation to ease integration with procmail. (Nekral - low priority)
• Implement mail service for translation teams with their own robots (e.g. Dutch) (faw)
• Collect data from http://www.debian.org/devel/website/stats/ (Nekral)
• http://www.debian.org/intl/l10n/po/,
  http://www.debian.org/intl/l10n/po-debconf/
  are built based on the churro material. It would make more sense to build these statistics on churro (Nekral)
  • We could "fork" the page and add some fancy new features on these pages (Nekral)
  • Add information from the coordination page to indicate that a translation is ongoing. (Nekral)
• Pootle: missing review indication. Hard with PO back-end. (Friedel)

There are a couple more reports to be sent but they are more focused on i18n specific questions, tools and plans for 2008. So, probably those will be sent only to debian-i18n mail list. If you are interested, please, stay tuned. :-)

Posted on d-d-a: http://lists.debian.org/debian-devel-announce/2008/01/msg00002.html
And a big thanks to Nicolas François (aka nekral), he helped me a lot making notes, preparing the text and reviewing it; and was patient enough to wait for the report while I was solving some personal problems.

Friday's predominant weather is forecast to be heavy rain
Saturday's predominant weather is forecast to be sunny
Sunday's predominant weather is forecast to be light rain
Monday's predominant weather is forecast to be heavy showers
Tuesday's predominant weather is forecast to be heavy rain

Oh well. In a fortnight I'll be heading to Linux.conf.au to discuss why suspend to disk doesn't work, can't be made to work in its current form and that everyone who thinks it currently does is under some form of mass delusion. Friday, 11:30. Be there or be listening to one of the other fine presentations that day. If it rains there, I may be upset.

An article by Sam Varghese appeared on ITwire today, entitled linux.conf.au: What is Novell doing here?:

A GNU/Linux system does not normally load modules that are not released under an approved licence. So why should Australia’s national Linux conference take on board a sponsor who engages in practices that are at odds with the community? What am I talking about? A company which should not be in the picture has poked its nose in as a sponsor. Novell, which indicated the level of its commitment to FOSS by signing a deal with Microsoft in November 2006, will be one of the supporting sponsors for the conference.

Novell was also a minor sponsor of the 2007 conference, and Sam wrote an article in January expressing similar thoughts, which included this quote from Bruce Perens:

“I’d rather they hadn’t accepted a Novell sponsorship. It wasn’t very clueful of them, given Novell’s recent collaboration with Microsoft in spreading fear and doubt about Linux and software patents,” Perens said.

Ultimately, I think that’s a mistaken view. Linux.conf.au is what it is thanks to the contributions of four groups:

the organisers

who create the conference, get a venue, organise a schedule of events, help the speakers and attendees to get there, and generally make it easy for everyone to just get immersed in cool Linux stuff

the speakers

who provide the core of the schedule, the reason for attendees to go, and a core depth of awesome technical knowledge and ideas

the attendees

who fill in the organisational/content gaps that the organisers and speakers miss, who make for fascinating corridor and dinner conversations, who make side events like the miniconfs, the hackfest or open day interesting, and who pay the rego fees that lets the conference happen

the sponsors

who provide a chunk of money to fill out the conference budget letting us commit to venues and events earlier (when we might otherwise have to wait to see how many people come), and let us do extra things that registration fees alone wouldn’t cover

Obviously sometimes you have to exclude people from participating, but that’s mostly only if they’re actually causing trouble for the event. For sponsors, that pretty much means trying to interfere in the conference itself, or not paying on time. Otherwise, if you’re contributing to the conference, and not causing problems, you certainly should be recognised for that, as far as I can see. For me, the same thing would apply if Microsoft was offering to sponsor the conference – if they’re willing to contribute, and not cause problems, I’m all for it. If they happen to not be doing anything constructive in Linux-space anywhere else, well, it seems perfectly fine to me to start contributing by helping make linux.conf.au awesome. In Microsoft’s case that would be hard, because all the people going “oh my gosh, Microsoft, Linux! Wolves, sheeps! Hell, snow!” along with possible mixed messages from Microsoft and our long-term major sponsors HP and IBM about the future of Linux and whatnot could really distract us from all the cool technical stuff the conference is fundamentally about. I don’t think there’s anything Microsoft could offer to justify that much disruption, but having more of the world’s software companies involved in free software would probably be worth a bit of hassle, if the disruption could be minimised. Ultimately, I guess my disagreement comes down to these couple of comments from Sam’s article:

Asked whether it was right that Novell should be allowed to be a sponsor for a conference such as this - which, in my view, is a privilege - […] […] Novell, obviously, is hoping that, as public memory is woefully short, it will be able to wriggle its way back into the community. Providing such leeway is, in my opinion, a big mistake.

In my opinion, the ability to contribute to open source isn’t a privelege, it’s something that should be open to everyone, including people who’ve made mistakes in the past: and that’s precisely what the “free” in free software is all about. OTOH, if you want to see who’s been participating most in the Linux world lately, you’re much better off looking at the list of speakers than sponsors. Novell (or at least SuSE) folks giving talks in the main conference this year seem to include John Johansen and Nick Piggin. Interestingly, the count of HP folks seems a bit low this year, with only two that I can see, which leaves them not only merely equalling Novell/SuSE, but beaten by both Intel and Catalyst. Tsk! I guess we’ll have to wait and see if that changes when we can see the list of attendees’ companies in the booklet this year…

(Disclaimer: I work for MIT Information Services & Technology blah blah blah I am a student blah blah these are only my words and do not represent the opinion(s) of my employer.) Way back in the day in 1983, MIT started something it called Project Athena, which had the goal of investigating how computers could be used to enhance education at MIT. This project became the origin of such pieces of software as the X Window System and Kerberos, as well as a campus-wide network of workstations all running similar software. In 1991, Project Athena ended, but the Athena system continued on, taken over by MIT Information Systems. It’s 2008, and Athena still exists at MIT—walk into a computing cluster, and chances are all the machines will be running Athena software. (Unless that particular cluster has been taken over be Athena’s evil sibling, often referenced as “WinAthena”, which often seems to be maintained by no one, and whose existence is sometimes denied by those who maintain and support Real Athena. Not many machines have suffered this agonizing fate, luckily.) Unfortunately, as the years have progressed recently, fewer and fewer resources have been put into the development of Athena. In many ways it is no longer on the cutting edge of things as it has been in the past, though it is certainly still useful. Some students these days, however, even think of Athena as only “their MIT email” or maybe use it occasionally to print something in a cluster on the way to class. I’ve seen people grow frustrated and storm out of a cluster due to things like instructions for using a flash drive that involve more steps than just plugging it in. While on the one hand it’s easy to laugh at people for a lack of patience or being open to a computing system that is not either Windows or Mac and perhaps a bit more complicated on the surface, on the other hand, some of these things really should just work by now, and on other UNIX-based systems they do—but Athena has lagged behind. When you log into an Athena workstation for the first time, you are confronted with what looks like this: That’s GNOME 2.8, and it looks kind of like the GNOME 2.8 default but uglier. When you look under the hood, there are pieces of the system that obviously originated in a time where nothing better existed and so something new had to be created—the “xlogin” login system doesn’t support PAM, and the login path involves a hairy maze of scripts that perform various tasks. Under the hood, the base OS is currently RHEL 4 or Solaris 10. I still can’t remember what the right options are to feed RPM whenever I need some information that I think I should be able to get from it. These things were once necessary but today just look crufty. Some people have tossed around the idea that everyone has a laptop these days and thus clusters are uselessly expensive, but it’s been met with a lot of resistance. I’m all for progress, but I use clusters all the time! They’re one thing that makes it an easy choice for me to have a really portable laptop, because when I really need computing power or screen space on campus away from my room, there is always a cluster nearby. They’re also nice isolated places that can be associated with “work mode”, which is good for productivity. Beyond all this, Athena provides a common platform that all technical classes can depend on, from providing standard and specialized academic software to standing as a baseline of “make sure your code works on this before handing it in because that is how it will be graded”. At any rate, things are finally happening on this front. Athena can’t stay RHEL 4 forever—while AFS allows non-system software to be easily updated for all machines without requiring any OS release, hardware moves on and compatibility is lost, and the rest of the world is coming up with new awesome things that Athena machines are missing out on. A student group that I am vaguely involved with, SIPB, took the early initiative with this and created DebAthena, which takes stock Debian and Ubuntu and allows it to closely resemble an Athena environment. We even run a campus Linux dialup using the packages. (I won’t claim to have done much work on DebAthena myself because, well, I didn’t.) Amazingly, the Athena release team has decided to work with the SIPB on the next release of Athena. So, what I really just wasted over 600 words prepping for is to say that Athena 10 will be based on Ubuntu. This is only relatively new news, but I am lame about finishing blog posts. There are a variety of reasons why Ubuntu was chosen over Debian. Some of them are lame and some of them are not. Even so, I am excited about this prospect—and it should be possible to peripherally support Debian in such a way that was not possible with Athena 9.4. I really like Athena. Even coming to MIT with a background in Linux there has been a steep learning curve, though, and I think that things could be better. Lots of people here have their first encounter with a ‘nix system in the form of Athena, and we should strive to make that experience as good as possible. I’m kind of skeptical on the expected release date of this upcoming summer, but as long as it happens soon it will be a big step forward. In some ways it’s kind of sad that I’m excited about a big part of a research institution catching up with others—but inertia is a strong force, and dealing with thousands of workstations is no trivial task. I kind of long for the exciting days of creating new big pieces of free software like X. I bet I imagine those days as being better than they actually were.

The other day, I had an interesting problem, regarding Apache, the LocationMatch directive and regular expressions. I'll put it here, so I'll be able to find it again... Actually it was a quite simple problem: A simple web page, where all web pages are protected with a password. No big Problem: Use a <location /> and AuthType basic, problem solved.... or isn't it? Some documents might be needed to be available without the authentication... for example robots.txt... or the funky custom error document, which explains how to get the authentication data, in case the authentication fails. Looking at the documentation, found a solution: LocationMatch exists, where you specify a regular expression, which must match, for the following configuration to apply. What isn't mentioned in the documentation, that the obvious solution... something like <LocationMatch !"^/(robots.txt my401handler.html"> doesn't work. See apache bug 10932. Needed quite some time, to find this out... Luckily Meike found the bug report above, which has a workaround for that problem: Use <LocationMatch "^/(?!robots.txt my401handler.html)"> Oh... and if your customized error handler references some pictures or style sheets, don't forget to add them to the regular expression above, too.