Big week for me in and around the media. Huzzah for fame and fortune!

Web 2.0 APIs I'm really happy that an article I wrote for Linux World on Web APIs for software development was published. Called Ten Web 2.0 APIs you can really use, it covers the APIs available today that are really useful for more than just gee-whiz mashups. I'd covered a few of the services when I did a story for LW on the Web 2.0 Summit, so Don Marti asked me to follow up with a full rundown on the world of Web APIs right now. tags: web2.0 api web api linuxworld article

Wikitravel on the AP wire On the other side of the media lens, Wikitravel is one of the sites featured in an article on the API wire by Anick Jesdanun called Travelers contribute to online guides. Although the article covers a lot of other travel sites, and even has some sour grumpiness by proprietary travel guide publishers, I think it's very favorable to Wikitravel. tags: wikitravel ap anick jesdanun travel guides

Thanks, Tom Also, it was nice of Tom Brown from Stuffopolis in talking about his OpenID Podcast to say that the OpenID extension for MediaWiki is "excellent". Gawrsh! tags: openid stuffopolis tom brown mediawiki excellence

Just for the record!

[*.cloud.*]

Alive. Birthday. Happy. Sad. Changes. Freeze. Packages. i18n. Ideas. Plans. University. Life. Family. Mother. Notebook. Frieds. DebConf. DebConf7. Edinburgh. OLS2007. LI. OpenBeach. Work. Free. Freedom. Debian. Brasil. Sorry. Smooth. Standards. Ideas. Core. Philosophy. Beliefs. World. Creed. 24. Translations. Organization. pt_BR. NMU. l10n. Past. Present. Future. Notes. Messages. Kind. Patience. Friendship. Fellowship. Party. Meeting. Food. Discussion. Debate. Cry. Try. Fix. Solve. Together. Alone. Team. Workgroup. Fast. Again. Just. Me.

Thanks: peretto and enerv.

Many people have recently posted in Planet Debian regarding the use, usability and usefulness of having comments enabled in blogs, of using comments as the right way for following discussions, of dealing with spam, and so on.
I'm sorry I'm not linking to more of them, but I'm too lazy to look them up. This is one of the down-sides of not using comments - Ideally, if I were interested on commenting on a topic, I would just leave the comment on the blog that started it. It goes somewhat against Joey's logic of posting both the comment and the posting itself - Of course, we all want everybody and their dogs to read our comments, don't we? And, given we know that (most of) our target readers regularly follow Planet Debian, we continue ranting on our personal blogs (as I'm doing now). Besides, that will rank our page higher. We all want Google to love us, right? Of course, following discussions on a bunch of blogs is not optimal, as it's easier to miss parts of it (hey, would somebody volunteer on writing threading support for Planet? It'd have to be multidimensional, as postings often refer to different threads... Bah :) ). Besides, many of us are syndicated on different planets (and many people read our blogs as individuals as well), so many of my postings start with a stupid amount of background information so the martians understand the terrans. But still, here I am, writing a post that provides nothing but a braindump, serves no purpose, and links to your posting. So there, the world is not ideal. QED.
As always, MJR rants against captchas (and yes, thank you, you have commented on my blog that most captchas are trivially crackable by automated means). They do reduce spam, but they are REALLY not a strong barrier against it. I have thought of some ideas, or thought about implementations for other ideas I've read here and there, but I'm too lazy to implement them on my blogging software. I could switch, but I happen to like Jaws. I would like to contribute to making it better, but have had a permanent lack of time for a long time already :-/ I do get swamped by spam comments, and every now and then mass-delete whatever looks like spam (hundreds to thousands of comments, for crap's sake!), but anyway... It's not too important for me. I like having comments on my entries, but sometimes a long time must pass until I even read them (I read my own blog syndicated via the Planets, on a RSS reader).
BTW, Lucas: I used to have trackbacks enabled. The amount of spam, and the control I have over spam in my blog, makes me favor comments against trackbacks. My trackbacks used to be so wildly abused that it almost made me cry. I hope it is not your case :)

In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit. After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it. Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem. Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges. First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.) Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system. What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too. How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them. What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how? First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you re distributing software for ‘Linux’ then it won t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily. Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow? No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right. To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop. The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences. Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place. Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it. Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with. We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it. However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too. Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets. Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done. Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!

When you are on some abuse list from an ISP you propably know these kind of things: you get copyright/intelectual property/whatever infringement alerts from various institutions every now and then. I won't try to guess if they themself are actually downloading all the data to verify the content, or maybe even put it into the peer to peer networks to see who is going to download it. Nevertheless, sometimes there are quite funny companies with their alerts out there. One of those is the ESA—the Entertainment Software Association. The following is an excerpt of one of their mails stripped down to the relevant parts:

From: esa-no-reply@copyright-compliance.com
Reply-To: esa-no-reply@copyright-compliance.com
-----BEGIN PGP SIGNED MESSAGE-----
[key 0x9E9658B85A10FEEC unavailable]
[...]
ESA believes that its members' rights in such entertainment software products
are entitled to the full protection of the intellectual property law as well as
other relevant laws of your country.
[...]
Please inform us whether you will remove or disable access to the Infringing
Material as requested.
[...]

Given that they say in their headers that they don't want reply, both in the From and Reply-To, they still request information about the actions taken in their mail body. Yes, there is a different mail address listed in the body too, though that's not how mail programs work, do they...
Then for added authentity they pgp signed their message. Though, I wasn't able to find a server on which this key is available, and there is no hint in the mail where to get it from. Quite trustworthy, isn't it. It adds that the whole mail says that it's a template, though states that they are "entitled to the full protection of [...] relevant laws of your country". One starts to wonder if they are at least remotely aware to which countries they are mailing... P.S.: On a side note, their second listed MX record doesn't seem to feel responsible for the domain—it simply sends you a 551 5.7.1 relaying denied when one would try to deliver there. Adds to the impression that the ESA is nothing but entertaining...

For those who've been hiding under a rock for the last few months: dunc-tank is the (controversion) project that was founded by the current DPL, Anthony 'aj' Towns. Controversial, because a lot of people feel that this goes against the spirit of Debian; and that by paying some Debian people and not paying others, we're creating a two-class system that we'd best avoid. And probably a bunch of other arguments, too, but that's not what this blog post is about. Me, I've been staying rather quiet in the whole debate. It's not that I don't have an opinion; rather, I haven't been voicing it, mostly because my thoughts on the matter are rather convoluted, and I'm not sure I can put them in words pretty well. But since the debate seems to be going in circles, and since I think that I might be able to help it out, I'll try anyway. If that doesn't bring the debate any further, well—can't blame me for trying. Do I think that paying people to do work on Debian is necessarily a bad idea? No, not at all. Quite to the contrary; by paying people to work full-time on Debian for a while, we will increase the amount of work that's being put into Debian, which can only be a good thing; and I can only applaud aj for trying to get this done, since it should be obvious to anyone involved that by proposing this, he only had Debian's best interests (i.e., improve our distribution) in mind. The obvious question, however, is who we'll be paying. After all, while I don't think it's necessarily bad to pay people, I do think that with money, you introduce the possibility for corruption; so at the very least, it should be strictly checked what exactly happens with the money that's being spent. Accordingly, the way in which you pay people—your whole set-up and procedures—should have a number of safeguards. Which brings me to my next point. Do I think that dunc-tank, as a project, is a good idea? No, not at all. Quite to the contrary; and I have a number of reasons for that. First, I don't think that deciding by committee who can get paid and who can't is the way to go forward. A committee will always be biased, no matter how diverse its membership. Even if you could find a committee that would not be biased—an impossibility by definition—then there will still be people who will not agree with the committee's decision. Are they right not to agree? Not necessarily. Is it bad to create such controversy if it could be avoided? Sure as hell. Moreover, by creating a project which populated by Debian people and which has the sole purpose of paying Debian people, it's fairly possible to create the impression as if all other ways to get paid to do Debian work would be unsound; that if a developer accepts money for Debian work without going through the committee, he's somehow doing something morally wrong. This would be very bad indeed; I know for a fact that there are cases of people paying Debian Developers to work a few days on a certain package so that a certain bug which impedes their business is fixed, or so that a certain version of a random package which this company is using, is uploaded into the archive. I've done this myself in the past (although I can't disclose more, since the person who paid me requested to remain anonymous); I know of at least two other Debian Developers who've done so as well. So what's the alternative? Not paying people is one, but it would not necessarily be the best. One alternative, which the FreeBSD people have been doing, is just "no organization at all". People who want to get paid just put up a web page with the amount of money they would like to have, and it's up to the community to decide whether their request is valuable enough for it to actually be paid. To some extent, this is also what the Dunc-Tank committee is doing, except that as FreeBSD does it, there is no committee in between. The problem with this approach, however, is that if we all go ahead and ask for money at the same time, it'll not only make us look like a bunch of beggars; it's also very likely that nobody will actually be getting any money, because there's so many "good causes" to choose from that there might not be enough donations to fund them all. Another proposal was one made by Manoj Srivastava, before word got out that dunc-tank would be started (or about at that time). As it was made on the debian-private mailinglist, I can't say much about that; suffice to say that I feel his proposal was overly bureaucratic, and had problems that were similar in nature to the problems I feel exist with dunc-tank. So do I have any answers which might get us a way out of the current status quo? Nope, afraid not. But allow me to make this final observation: In early 2005, a bunch of people decided that Vancouver was a nice place, and travelled there. As it happened, they were all Debian people. What a coincidence. Since they were all there anyway, they decided to talk a bit about Debian, and as a result, came up with some plan for its future. This plan, too, was rather controversial. When I initially read the first few paragraphs, I suddenly fell upon this paragraph which seemed to say that "we suspect we won't be releasing with anything but i386, amd64, and powerpc for etch". Things suddenly turned kinda red from then on. And it wasn't the wine that I hadn't been drinking. I could imagine that what I felt back then is somewhat similar to what some other people felt when they first heard about the suggestion to pay people for Debian work; and this realization is the reason why I haven't been dismissing their arguments or thoughts, much like I've seen other people do. However, I cannot say that I feel the current crisis to have many parallels with the Vancouver one; this is mostly because in the current case, people on both side of the argument seem to be building up walls around themselves, to help them ignore whatever the other side was saying. In contrast, when someone suggested something which had the potential effect of throwing most of the hard work I'd been putting in for Debian during the last five years now down the drain, I went to talk with them—after the heat had cooled down, anyway. Unfortunately for me, the result is exactly the same; for all my effort, I haven't been able to prevent m68k to be kicked out of the release; and to say I'm not happy about this would be an understatement. But at least this way the port has been given a fair chance; if I hadn't been talking to the people on the other side of the argument, I would still be talking about Steve Langasek as if he were the devil himself, and m68k would probably have been kicked out of Debian—along with a bunch of other architectures. At least I got that bit fixed. I guess what I'm saying is that people, rather than farting in eachother's general direction, should be working together in finding a compromise. Sure, that means making concessions, and agreeing to something you'd rather not agree to. But at least this way, the thing you have to agree to isn't as bad as what it could be. And trust me, people will do the stuff you don't want them to do, with or without your agreement. Hell, they've already started. Whoa, long post. I'll stop preaching now.

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.

Thanks to Ricardo Fernandez we have a great new and consistent artwork for our ice-lizard applications. For icedove they will land with the next upload … so here some screens.

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

Jono Bacon wrote a long blog entry on Planet Ubuntu about his vision of freedom, and how it applies to the proprietary drivers. This is a good opportunity to write sthing I wanted to write for a long time. Ubuntu’s bug #1 is “Microsoft has a majority market share“. Well, I think that this should be of severity minor or wishlist, not critical. A better bug #1 would be “our priority is our users” (does it ring a bell ?). I find it far more important to improve the satisfaction of people already using a Linux distribution, than to try to convince others to use it. Most users of Windows have very good reasons for using Windows, like proprietary applications that have no equivalent in the Free Software world. I don’t think that “Linux doesn’t have a 3D desktop” is the major blocker for people not using Linux. Windows doesn’t have a 3D desktop. Many Mac OS X users don’t use the 3D features. I haven’t felt the slightest need to try a 3D desktop, and I’m using GNOME/metacity, so the jump wouldn’t so hard to make to compiz. I’m not saying that a 3D desktop is not a good idea. Of course, it would be nice to have LiveCDs that just work and start a 3D desktop, so we could show off at conferences. But I haven’t even bothered to google for such LiveCDs. Sometimes, proprietary drivers are more needed on Linux, for example for people who bought a Wifi card without checking first if it was supported. But I don’t think that 3D graphic drivers are that important. I still hope that Ubuntu will not ship proprietary software by default, and that Ubuntu will try to help the free drivers instead. Update: I forgot to close the comments when publishing this entry. They are closed now, but trackbacks are open if you want to write your own blog about this (I don’t think it’s necessary, all arguments have been reharsed many times already. Ah, and for the records, the free ati driver works perfectly fine and fast (using MergedFB) in my dual-screen setup (2560*1024), with xv on both monitors.

YouTube suddenly seems a lot cooler than I thought it was. Anyone speak ASL?

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.

Movie trailers linked from IMDB now apparently require you to watch an unrelated advertisement before the trailer starts. And here I thought movie trailers were advertisements…

At the main train station in Munich, at the subway level there is a big screen showing ads and miscellaneous information to capture the attention of the waiting passengers. These screens are pretty nice, they show some comics, random facts, some headlines, weather forecast and similar things. In their "bits & more" computer tips section they today showed the URI for some linux application finder. (That is not at all specific to germany, so I doubt they paid for being mentioned) I was really surprised to see a Linux software page mentioned on such a high visibility place; stuff there is usually targeted at the total computer newbies. Now if this isn't a sign that Linux is becoming mainstream...

That would solve so many problems. LaTeX is still unbeaten in terms of print quality. It's really powerful. Since I've been using it, if started to really despise Writer and Impress. latex-beamer slides look just so much better than any PowerPoint presentation I've ever seen. However, it's far from easy to use. The syntax is a pain, and I don't think it's a feature that you can actuall program in this language. Similar things hold for BibTeX - there are so many things to do wrong there that will go a long way unnoticed. I've recently helped a friend to fix some BibTeX files. It was a pain, there was so much wrong in there... for example URLs. People noticed that they can't just always copy URLs in there, because some characters are special to LaTeX. But instead of using the \url macro, which would also have solved linewrap problem, they started doing the most obscure things (and of course they did not read the FAQ we wrote for them or asked how to do it right), for example adding whitespace to enforce line wraps, replace _ and & with whitespace etc., wrap uppercase chars in - an awful mess. The same thing with the author values. They just wrote "First author, second author" without considering that this might be interpreted according to the common "Last Name, First Name" scheme: e.g. "van Damme, Jean-Claude". (The correct syntax is "First Author and Second Author and Author, Third" - use "and" for separating even when you have more than two authors.) XML is better here. It's rules of escaping are generic and application-independant, and thus you'll have much more tools that know how to do it right, and you only have to learn it once, not for each application. The structuring also comes in handy:

  <authors>
    <author firstname="Foo" lastname="Bar" />
    <author firstname="Gnarf" lastname="Quux" />
  </authors>

is a bit more to write, but it avoids parsing errors. And with good utilies it's not particularly hard to write. Now don't point me to XML-FO. I know about formatting objects, the paper I submitted to the eXtreme Markup Languages conferences was done with FO. It's just that they don't come anywhere close to LaTeX in terms of print quality, the only OpenSource implementation I'm aware of didn't make much progress (but they seem to have released a rewrite in the meantime) and was lacking important features, and MathML has a horrible syntax mess (apart from Apache FOP not having MathML support). XSLT also has an annoying syntax. Too verbose and totally unreadable once you do things that are a bit more complex than the simplest examples. I wish we had something that gives a similar print quality to LaTeX, that uses some XML format (or something similar structured and easy to parse, like Xcerpt data terms, but thats basically equivalent to XML, just a bit more compact; Lisp S-expressions and OEM are other examples) that allows the easy creation of third party utilities and does away with all the black magic involved... Yeah, IMHO it's really time for a rewrite of LaTeX with a modern language design. And a large, unified standard library; plain LaTeX sucks, you can barely use it without extras such as url, hyperref, latex-beamer. [Update: yes, I'm aware of bibtexML, but it's just as bad, you still need hacks such as "the C language" or using "and" to separate multiple authors. I'm also aware of docbook and docbook to latex converters; that definitely is a workaround, but doesn't solve the real problems] (Comments in my blog are intentionally disabled. So if you want to voice your general dislike of anything with XML, abuse your own blog!)

Are comment-less blogs missing the spirit of blogging?

It seems to me that the most significant development about blogging is the idea that anyone can write. Prior to blogs news-papers were the only method of writing topical articles for a mass audience. To be able to write for a news-paper you had to be employed there or get a guest writing spot (not sure how you achieve this but examples are common).

Anyone can start a blog, if there is a community that you are part of which has a planet then it's not difficult to get your blog syndicated and have some reasonable readership. Even the most popular planets have less readers than most small papers, but that combined with the ease of forwarding articles gives a decent readership.

It seems to me that the major characteristic that separates a blog from an online newspaper is the low entry requirements, anyone can create one.

Every news-paper that is remotely worth reading has a letters column to publish feedback from readers. Of course it's heavily moderated and getting even 50% of your letters published is something to be proud of. But it does create a limited forum to discuss the articles that are published.

It seems to me that creating a blog and denying the readers the ability to comment on it is in some ways making the blog less open than a news-paper column. When such blogs are aggregated in a community planet feed it seems that they go against the community spirit. It also drives people to make one-line blog posts in response, which I regard as a bad thing.

The comments on my blog are generally of a high quality, I've had a few anonymous flame comments - but you have to learn to deal with a few flames if you are going to use the net, and people who are afraid to publish their real name to a flame don't deserve much attention. I've had one comment which might have been an attempt to advertise a product (so I deleted it just to be safe). But apart from that the comments are generally very good. I've learned quite a few useful things from blog comments, sometimes I mention having technical problems in blog posts and blog comments provide the solution. Other times they suggest topics for further writing.

There are facilities for moderated blog comments that some people use. If you have a really popular blog then it's probably a good idea to moderate the comments to avoid spam, but I'm not that popular yet and most people who blog will never be so popular. At this time blog moderation would be more trouble for me than it's worth.

In conclusion I believe that the web should be about interactive communication in all areas, it should provide a level playing field where the participation of all individuals is limited only by time and ability. Refusing comments on blogs is a small step away from that goal.