Given the recent articles or blog posts that may lead some people to think that dunc bank made people work against Debian, maybe some explanations are needed. Dunc-bank is a single web page that some humourless people may find unfunny, YMMV, but that is nothing else than satirical. There was no conspiracy, undermining work, or power games. People claiming the contrary are just making complete fools of themselves. Really. The people that contributed to dunc-bank, meaning that did report most of the RC bugs in the last month are for some, even disgruntled when it comes to dunc-bank (I'm thinking e.g. of Lucas Nussbaum that did a full archive rebuild and reported many bugs). No, dunc-bank is not the evil masonery club that some depict. The sole thing I think really happened, is that people are nowadays really concerned about QA, and that there is a whole lot of issues that can be tracked automatically, at home (a good ADSL line and a GHz grade CPU is largely enough to do an archive rebuild in a week nowadays). What is really a shame in fact, is that those checks are not performed by Debian for any package, and on a regular basis. The other factor is that I think many people had concerns with etch quality, as many discussions in the past month may have let think that its quality could suffer from the announced release date. Now that this bad joke is now officially a dead-line, I think this is less and less a concern. That said, Yes, I do think some people that usually did good work in debian diminished their work considerably, and that it hurt the release. We lost some developpers (our locales + X-keyboard expert and that's a huge loss), some orphaned a lot of packages, and recent events do show that you can't improvise beeing the libpng maintainer a month before the release, and so on. Yes it's true that recent events and surroundings in Debian^[1] have led people to feel they are strangers to what Debian is becoming. And blaming them for not beeing supportive is very distateful and shocking. When you do pursue actions, that will lead to big changes in the community, then blaming the community members for those changes is a shame. So no, you can't blame the people behaviours (that have been reduced to dunc-bank supporters because that's so easy) for etch beeing late, because you can't blame the direct consequences of an action for beeing the cause of its failure.

That sometimes journalists have obvious reading problems, well, isn't a too new thing. One has to deal with that, e.g. by appending more text to the cited blog entry. If someone inside the Debian community fails for the same is way more disappointing for me. I have never stated that "[I] couldn't compensate this" - that is just totally wrong. I think that dunc-tank helped us with release of Etch, but the help could have been greater if some people wouldn't behave as childish as they do. And I also try to look both ways, and not be singled-minded about it. There is another thing I learned as well during the last 12 hours - people don't appreciate if one tries to summarise openly what happened, and look both ways. Is it so wrong to look in both directions, and not only say "that and that were the improvements"? I thought at least within Debian we don't want to fall the usual management mistake of only speaking about how great everything is, but be honest to ourselfs. People starting to rip only half of the words out, citing them out of the context, and inventing new quotes don't help with that.

Monday morning started with seeing lots of brand new release bugs about attr being broken so bad that "ls -la" failed, and also buildds were affected negatively. As a consequence, I few-hour-NMUed this package back to a sane (i.e. working) state. As any library maintainer, please remember: Whenever you drop a symbol - whichever this symbol is this means: You need to bump SONAME. Or just use library versioning from the beginning. Failing to do so can lead break any program linking to your code, which is especially bad if it is ls and cp. Rest of the day was mostly spent on further libpng-analysis. There is now a nice table on http://ries.debian.org/~aba/png.abis which symbols were exported in which version. We are progressing into resolving the libpng problems now.

[RV Heraclitus SE Asia voyage: blog photos] The past few weeks, we changed our route to visit an uninhabited island (aka Ko Pulau Island) said to be "National Geographic, man" by some Americans we met in Kupang. On the way to Ko Pulau Island we saw a large school of pilot whales and dolphins, a humpback or other whale close to shore, a blue starfish and hot water vents nearby on the same mostly dead reef, a flock of birds feasting on a dense school of fish, a manta ray, a bonfire on the beach shared with the kids of Rote (who we swapped roast banannas and coconuts with), a clean hull and renewed sea-sickness. At Ko Pulau Island, we saw a long white beach made of small bead things instead of sand, with surf at either end and reef in between, a green lagoon with islands being eaten away at the base, a monkey-head rock, pink coral, reef fish, sea urchins, various pieces of flotsam washed up on the beach (flip-flops, a light-bulb, bottles, wood, burnie-beans, nautilus shells, a seabird egg, a dead seabird and other crap), sunset over the ocean with golden cirrus in the sky, turtle nests, tracks and hatchlings scurrying off into the water, Indonesian fishermen in need of water and turtle eggs, tidal pools with the occasional crab, ghost crabs darting towards the water, a pandanus stand, a small cave surrounded by discarded turtle eggshells, spinifex, hermit crabs, scrambling lizards, sunburn and other things. Later in our voyage, we saw a big lone flying fish, land looming mountainous on starboard, TNI, gratis reef fish, water buffalo and threatening rain clouds. The next major stop was a bay on the south side of Sumba, black cliffs to port and an eroded hillside to starboard. There, we enjoyed the excellent snorkeling against the cliffs and off the beach, birds calling from the forest, wasps - shiny blue and otherwise, meeting roaming cows in the forest, forest fungi and other sights. We met some fishermen and drove through the forested slopes toward a nearby city. On the way, we visited an Indonesian village and saw their traditional animist temple, ample baby pigs & dogs, tons of kids trying to get in photos, satellite dishes and graves in front of houses. Unfortunately, I crashed once we reached the hotel, missing eating and night life, but I did enjoy the sights from the windows of the cramped 4WD we were in. We headed for the 9.8 knot passage of Selat Sape, complete with eddies, currents, a barracuda and the steep slopes of a silent volcano. Since there, we saw an increasing number of interesting and curious Indonesian vessels, fish traps, the grey shapes of dolphins swimming in the aqua water under the bow, a floating sandal, a school of mahi-mahi jumping out of the water, a misty night, numerous schools of feeding fish, entangled luminescent trails left by dolphins swimming in the phosphorescent water beneath the bow, flashes of lightning in the distance, our first rain since Cairns, the associated storm, Jack the fisherman (a mast hallucination) and other things. Our next stop was Kalimunjava (north of Java, Indonesia), more than half way to Phuket. We spent a week there, watched lightning, collected rain, visited the local school, dived and snorkelled on the magnificant reef with some really nice university students (hi Lely, Dudu, Jaos and others) from Java who were doing a study on the corals and hiked up the steep slopes of the island. From there we ambled past Borneo, towards Bintan, near Singapore, experiencing the first non-calm seas in ages, dolphins in the storm, floating lines of debris, big barges, container ships and megatankers, a fancy, shiny yacht, fishing vessels with 50,000 lights, Rain Drop and it's egg (child of Rain the gecko), amazing cloudscapes at sunrise, throughout the day and at sunset on the way. Amazingly, we met the 8 (Infinity, the new PCRF vessel) one find day in the South China Sea on their way to Bali. Eddie saw them from 5 miles away and knew almost straight away it was them. Michelle came on board and a lone daytime cumi (squid) swam between us as we parted. Before we arrived at Pulau Bintan (near Singapore), we saw seasnakes and a palm tree floating and lots of wind and rain. We will probably arrive in Thailand by January and I'm thinking of passing thru Sydney on the way home, so let so please mail me if you want to meet up.

Yay! We've now moved. It was a crazy rollercoast of up late Friday night with workmates, up early Saturday morning for the cable guy to install the new Internet connection, rushing to get the washing machine repaired so that it wasn't full of water. That done, we decided "hey, let's see if we can find movers". We found a set for Sunday morning, so stayed up late Saturday (well, Angie stayed up late. I passed out and got up early) packing. The movers showed up Sunday morning and refused to do the work, even after we agreed to their price change. We managed to find other moving to take our stuff Sunday afternoon, and spent the evening shuffling things around enough so that we could sleep.

By that point I was caughing, sneezing, headachy, and such, and generally feeling run over. Apparently multiple days of physical activity and low sleep is now enough to totally take me out. Suck. I'm still sniffling, but I'm generally thinking straight now.

But yay, we're moved! The cats even seem to have forgiven us already.

This is the first of the two "larger" reports during the release management funding experiment. I suppose I don't need to be more specific about what I did in detail - my blog postings in http://blogs.turmzimmer.net/en/debian/etch-rm/ cover that already. The thing that ate most of my time are the release critical bugs. While it is possible for me on normal days to fix one bug every few days, it was now possible to fix a couple of bugs per day. This sounds rather good, but at the same time took away most of my time for other things I should have also worked on - that even involved blogging about my work. (Also in looking back that was still a good decision to work so much an release critical bugs - it would have been just more convenient if that wasn't necessary so much.) Looking back, I started with improving tools. I think that this was a good decision, good tools make work easier - and also, everyone can use the better tools, so they multiply their benefit. And e.g. the structural changes I did to bts.turmzimmer.net to allow "show also related bugs" were so deep that I probably wouldn't have been able to do them, unless I reserve a couple of hours in a row. In other words, being able to explicitly set some time aside for Debian which is not eaten up by the daily routine tasks (which involves reading quite much mail, BTW), is a good thing. So, looking at the status changes during the time I spent full-time on release issues I think it worked well. Of course, not everything is perfect, but there is a clear improvement. On the other hand, there was a large disadvantage of the whole experiment: Some people who used to do good work reduced their involvement drastically. There was nothing I could do about, and that happened way before I started full-time on release, but on the global picture that still counts. So, as a first summary, I am happy with my own involvement, but that doesn't necessarily apply to the full experiment. Update: There are media rumours floating around that "[Etch has] been delayed because some developers have deliberately slowed down their work". This doesn't reflect what I said. I just noted that the dunc-tank experiment has positive and negative effects, and we shouldn't watch only one side - whichever that side is. The reasons for the release being delayed from the original planned date has other reasons, please read the mails on debian-devel-announce for details (also all linked on http://release.debian.org/). And, I'm quite happy with the involvement of most Developers in the release. (And this paragraph isn't part of what this blog posting should be about really, but as it is cited, it is still here ...)

I am about 2/3 over with my haul from Edmonton to San Juan, PR (laying over in the beautiful JFK) and am too tired to blog anything much of substance but do check out Furious Season’s impassioned and excellent commentary on the recent NYTimes article (and this one )that reveal how Eli Lily knowingly downplayed the risks of Zyprexa. And if you read the second article, you will find out what Viva Zyprexa means. Here is Eli Lily’s press release, which I have included on the next page as these things tend to vanish… Statement from Eli Lilly and Company: Response to The New York Times Article from December 18, 2006 December 18, 2006 INDIANAPOLIS, Dec 18, 2006 /PRNewswire-FirstCall via COMTEX News Network/ — Eli Lilly and Company (NYSE: LLY), vigorously objects to the characterization of company practices in a New York Times article based upon selective documents illegally leaked by plaintiffs’ lawyers. “At Lilly, we do not engage in off-label promotion - as alleged in The Times article,” said Dr. Steven Paul, Lilly’s executive vice president, science and technology. “Lilly is committed to the highest ethical standards and to promoting our medications only for approved uses. We have clear guidelines and extensive training for our sales representatives to help assure that they provide appropriate promotional information that is within the scope of prescribing information approved by the FDA.” Lilly works to bring Zyprexa to physicians who are confronted with the need to diagnose and treat serious schizophrenia and bipolar disorder wherever they practice. * About half of medical care for serious mental illness takes place in a primary care physician’s office. This is due to the fact a large number of people in the United States have no access to a psychiatrist or do not seek psychiatric care. * Our experience in mental health has taught us that primary care physicians are asking for education on severe mental illnesses, since they see many of these patients in their offices. * We believe that it is absolutely appropriate to discuss Zyprexa and its indicated uses with primary care physicians in the interest of meeting a critical medical need. * It is important that the public understand that physicians can and do prescribe medications outside of their approved indications to meet the needs of their individual patients. “While it is accurate to say that mental illnesses like schizophrenia and bipolar disorder begin early in life — with a higher prevalence during early adolescence and childhood — it is simply untrue to assert that these diseases somehow end — and therefore prescribing for them ends — in young adulthood,” added Paul. “To dismiss the devastating impairment of these disorders throughout a patient’s life is wrong. “Bipolar disorder and schizophrenia are often treated in the offices of primary care physicians. In fact Lilly did research with primary care physicians and found that they were challenged in making the diagnosis of bipolar disorder. Many primary care physicians appreciate the educational outreach Lilly provides in mental illness,” he added. The Times failed to mention that these leaked documents are a tiny fraction of the more than 11 million pages of documents provided by Lilly as part of the litigation process. They do not accurately portray Lilly’s conduct. As part of Lilly’s commitment to patients and healthcare professionals, many high-level Lilly physicians and researchers — along with researchers from outside Lilly — were engaged for a number of years to study the issue of Zyprexa and diabetes. Leaked documents involving these discussions do not represent an accurate view of company strategy or conduct. Lilly deplores the illegal release of select confidential documents. This illegal and selective disclosure of incomplete information will cause unwarranted concern among patients that may cause them to stop taking their medication without consulting a physician. This is the unfortunate result we saw when plaintiffs’ lawyers aggressively advertised about Zyprexa in recent years while searching for clients. Lilly, a leading innovation-driven corporation, is developing a growing portfolio of first-in-class and best-in-class pharmaceutical products by applying the latest research from its own worldwide laboratories and from collaborations with eminent scientific organizations. Headquartered in Indianapolis, Ind., Lilly provides answers — through medicines and information — for some of the world’s most urgent medical needs. Additional information about Lilly is available at www.lilly.com. C-LLY Zyprexa (olanzapine, Lilly) (Logo: http://www.newscom.com/cgi-bin/prnh/20031219/LLYLOGO ) SOURCE Eli Lilly and Company Tarra Ryker, +1-317-276-3787, mobile: +1-317-332-7502, or Marni Lemons,
+1-317-433-8990, mobile: +1-317-532-7826, both of Eli Lilly and Company http://www.prnewswire.com Copyright 2006 PR Newswire. All rights reserved News Provided by COMTEX

On Friday night I followed up on Matthew’s ITP and attended his and Daf’s party. This was the first time I had seen the OLPC prototypes and woah, they’re pretty small . Daf and I decided to make flapjack which went down really well. On Sunday^WSaturday Daniel, Rob (Kendrick) and Lesley came over to Cambridge and we went to the Free Press for lunch with Rob (McQueen) and Daf and two of my friends from college. That was followed by more flapjack and very tasty coffee at the Collabora office. At popular request (ONE!) the recipe for my flapjack is: Melt 125g of butter with 150g of dark brown sugar and two tablespoons of oozy golden syrup over a low heat. Stir it. When melted add two teaspoons of ground ginger and remove from the heat. Add 200g of porridge oats (for a more crumbly less toffee flapjack use 250g). Stir in a handful raisins (or sultanas, or both). Dollop into a greased baking tin (use the wrapper from the butter) and bake for around 20 minutes at 180 C. Score whilst still warm to ensure that it can be broken.

Well, this is first post. I have managed to migrate my blog over to Ikiwiki, including all the historical posts. The reasons for migration was that development on my older blogging mechanism, Blosxom, entered a hiatus, though recently it has been revived on sourceforge. I like the fact that IkiWiki is based on a revision control system, and that I know the author pretty darned well :-). One of my primary requirements for the migration was that I be able to replicate all the functionality of my existing Blog, and this included the look and feel (which I do happen to like, despite wincing I see from some visitors to my pages) of my blog. This meant replicating the page template and CSS from my blog. I immediately ran into problems: for example, my CSS markup for my blogs was based on being able to markup components of the date of the entry (day, day of week, month, etc) and achieve fancy effects; and there was no easy way to use preexisting functionality of IkiWiki to present the information to the page template. Thus was born the varioki plugin; which attempts to provide a means to add variables for use in ikiwiki templates, based on variables set by the user in the ikiwiki configuration file. This is fairly powerful, allowing for uses like:

    varioki =>  
      'motto'    => '"Manoj\'s musings"',
      'toplvl'   => 'sub  return $page eq "index" ',
      'date'     => 'sub   return POSIX::strftime("%d", gmtime((stat(srcfile($pagesources $page )))[9]));  '
      'arrayvar' => '[0, 1, 2, 3]',
      'hashvar'  => ' 1, 1, 2, 2 '
     ,

The next major stumbling block was archive browsing for older postings; Blosxom has a nice calendar plugin that uses a calendar interface to let the user navigate to older blog postings. Since I really liked the way this looks, I set about scratching this itch as well; and now ikiwiki has attained parity vis. a vis. calendar plugins with Blosxom. The calendar plugin, and the archive index pages, led me start thinking about the physical layout of the blog entries on the file system. Since the tagging mechanism used in ikiwiki does not depend on the location in the file system (an improvement over my Blosxom system), I could layout the blog postings in a more logical fashion. I ended up taking Roland Mas' advice and arranging for the blog postings to be created in files like:

 blog/year/month/date/simple_title.mdwn

The archives contain annual and monthly indices, and the calendar front end provides links to recent postings and to recent monthly indices. So, a few additions to the arch hook scripts, and perhaps an script to automatically create the directory structure for new posts, and to automatically create annual and monthly indices as needed, and I'll have a low threshold of effort blogging work flow for blog entries, and I might manage to blog more often than the two blog postings I have had all through the year so far.

I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that’s actually not the case. Also last week, the build daemon named “cats” stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to arm@buildd.debian.org. And I do not speak about build daemons building nothing. All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen. As arm@buildd.debian.org is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages. Yes I agree that real machines would be better, but I don’t have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named “netwinder“, you may think to that again. Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.

mpbeventd v0.9 is out featuring audio support, based on code contributed by Romain BEAUXIS. Starting with this version, the initial backlight level setting is optional (see config file). I’m opening a DBus branch based on this version; the goal is to have graphical clients reacting to the events sent through DBus, and eventually integrate with standard tools (HAL and gnome-power-manager have been mentionned). If you have on opinion on that and want to help (ie, you are an mbpeventd user), feel free to contact me. If enough people are interested, I’ll move mbpeventd on Alioth.

Once you’ve had a taste of EVDO (presently offered only by Verizon and Sprint), it’s hard to imagine not having it. Like cell service, you quickly forget what it was like not to be online always everywhere. (It’s a great example of our rising “baseline” standard of living). Recently, I switched to an embedded EVDO card on a new laptop (running Windows for reasons beyond the scope of this blog entry). It worked for a couple of days, and then I started getting mysterious “error 913” messages when trying to connect. After trying all the solutions that seemed obvious to me, I contacted Verizon Wireless Tech Support as suggested by the error message, which otherwise provided no information about error 913. Perhaps surprisingly, Verizon Wireless Tech Support didn’t really know what error 913 was either. After a few minutes, I was escalated to second level tech support. They had me reboot. Then they had me reinstall the card controller software. The second-level tech support person put me on hold to speak with whatever higher level tech support she had access to. Then they had me delete the EVDO connection from the dial-up networking control panel and re-create it. None of these things worked. So she said I should just return the laptop to the store and get a new one. It was perhaps the best example of the three “R’s” of Windows Tech Support I had ever experienced: reboot, reinstall, replace. This may perhaps be the only cost effective way of providing such support. I persisted, though, as I was pretty sure there wasn’t a hardware issue given that all the diagnostics were coming up without error. I would rather not return a perfectly good laptop just because we couldn’t figure it out. I was also suspicious because I had seen several instances of precisely this problem popping up in message boards, and the tech support person herself told me that she had recently been unable to solve the same problem with another customer. It just didn’t have the symptomology of broken hardware. After a few more minutes of speculating about why this might happen, the tech support person said she had an idea, and asked me to try to reconnect. Since then, it has worked perfectly. As I understand the problem, my account was enabled for unlimited “roaming” EVDO access, but did not actually have authorization for “non-roaming” (i.e., within the network) access. Thus the connection was rejected. There are several things wrong with this picture. Why didn’t the EVDO access manager software provide an error message that actually indicated that the connection was refused for lack of authorization? Why didn’t anyone at Verizon know what error 913 was? Shouldn’t Verizon have a checklist for such issues that includes “check to see if the subscriber is properly signed up”? (For that matter, why did my account spontaneously lose non-roaming access?) These are just a few questions that come to mind. I hate to beat on Verizon, since I’ve done it three times before, but it’s almost like they’re just asking for it. Maybe it’s time they rethink their organizational strategy.

As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.) One of the quotes I’ve had queued up for a long time is this one from Jon Udell:

I have a confession to make. Sometimes, when I m trying out an unfamiliar open source component, I cheat. Even if the software I m working on will deploy to Linux, I ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.

He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows. Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes. In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script. Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable. Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now. Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev. Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs? At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.) After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer). Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.) Oh, well. At least I didn’t have to check for viruses! Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used. Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things. However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively. Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…