According to Mark Shuttleworth:

The DCC distro doesn't use the Debian kernel, and it modifies key pieces of the infrastructure like the linking system and core system libraries. So it's not really Debian at heart.

According to the DCC 3.0 release notes:

5 [packages] are the LSB 3.0 compatibility environment, which adds LSB 3.0 compliance in such a way that the sarge glibc and pam packages don't need to be modified

It took me a long time to figure out how to read these two statements in a way that wasn't thuroughly contradictory. The DCC dropps in ld-lsb.so linker in for LSB binaries and uses that to make them link to some modified libraries somewhere outside the normal link paths, but that's more like the distro having two hearts (one of which is used only to circulate blood through the very limited set of available LSB binaries) than not being Debian at heart.

---

Mark again:

There is now discussion of modifying many, many more packages, for example to use the Ubuntu X.org packages rather than the Sarge XFree86 packages.

DCC again:

25 [packages] are a backport of X.org from etch.

So if they're using Debian's X.org already, why would they be planning to go to Ubuntu's?

---

Mark:

The DCC distro doesn't use the Debian kernel, and it modifies key pieces of the infrastructure like the linking system and core system libraries. So it's not really Debian at heart.

Mark again:

The DCC kernel and Ubuntu kernel will be very similar if not identical in future DCC releases, and I expect that collaboration will spread to other parts of the system such as X, ACPI etc.

If you think about it, this is in a sense the strangest pairing of statements of all...

Right now I feel motivated to implement a d-bus transport over X11 which would allow me to use all the hardware I have from an ordinary user account while not giving out blanket permissions to all of my users. I doubt that motivation will survive until I get home. :-/

Four years ago I started translating the Mozilla suite into Galician, and from that point on I managed to keep the translation completely up-to-date, even being one of the fastest ones to create translations (when Mozilla 1.0 was released, three translations for it were released at the same time: Chinese, Asturian and Galician), and later expanding my efforts into Firefox and Thunderbird. However, after two years, things started to go wrong: support for translations was starting to fail without warning, there were some undocumented changes to the language pack format and there was a movement to integrate translations officially into the Mozilla organization that would make it extremely inconvenient for me to go on working in Mozilla, so in July 2004 I resigned from the effort and stopped updating the translations. Well, it was not exactly a thing of “oh, now it is not worth the effort", but “those SOBs are taking all my past hard work down the crapper and they were supposed to stop updating the suite so why are they releasing a fucking new version?". And also “I’m here translating this shit and nobody appreciates it so fuck it all” Much angst and stuff, and I not only stopped with Mozilla: I stopped translating pretty much anything else and almost vowed not to translate again. And I made the T-shirt and all (some of you saw it in DebConf 5). During the Christmas break I didn’t have much to do, and it had been very long since I had last programmed for pleasure, so I decided to create a set of scripts for converting Mozilla XPI language packs into a huge PO file and back (days later I was told about translation-tools, but I was in the mood to hack and it worked with a lot of small PO files, which I didn’t want). Then, I imported my old Firefox 0.8 translation, created a POT for 1.0.7 and updated the translation. I may well start making Galician Firefox translations again – but unofficially. There’s already an official Galician team, which intended to start after my resignation but is, apparently, stuck in bureaucratland. Also, some horror stories I’ve heard about make me want not to work officially with Mozilla. Plus, some of the things that made me angry back in the days are still there. For example, the documents about translating Mozilla all newbies are referred to are badly outdated. And there are no new, unified documents. But I intend to take it easy. I will not invest emotionally on this again, because I don’t want to go back to spending a couple of months playing Frozen Bubble while I think bad thoughts about Mozilla developers. Anyway, I’m moderately happy now. I’ve hacked on my own, for pleasure, for the first time in months; I achieved a goal and I’m slowly regaining my motivation to do other stuff. I hope. That was all.

I just came back from the vet. I left Vi and Emacs there and will pick them up after work, as today they will be spayed and neutered (450 EUR total). I am all shaky inside.
My little cats! (Well, not so little, as Emacs started acting like if she was in heat only a few hours before I had to take a plane for my Holidays, so I guess she is not so little anymore, nor is Vi, who seemed completely fascinated by her new behavior. Anyway, my vet knew this would happen one month in advance, when we were arranging an appointment for the surgery that will be performed today).

Good luck, my babies!

I've added two SELinux on Debian mailing lists on Alioth: SELinux-user and SELinux-Announce. The first one is an open SELinux on Debian user mailing lists, the second will be used for announcements (mostly when something important changes, new stuff is added, something breaks etc.). Every SELinux on Debian user should probably subscribe to the second. Since there aren't that many user, I guess the -user mailinglist will be rather low-volume for some time, and needs love by those who are already running SELinux on their boxes. Current SELinux packages contain some breakages... updates are stuck in NEW right now, and I've written some extra notes to the mailing list: notice about SELinux changes. BTW: On the long run, Debian will likely drop it's current "strict" policy, and migrate to a serefpolicy-based Policy like Fedora already uses. Any volunteers to debconficate the setup process?

So I've been in the US for just over six weeks now, and I thought I'd reflect on the trials and tribulations of bootstrapping oneself in a foreign country. The Social Security Number is the primary key from hell I already had a fair idea of the importance of obtaining a Social Security Number (SSN). So much so, that after dumping our luggage at our temporary accommodation, the Social Security Administration office was the first place Michael and I went to, so we could lodge applications. We subsequently learned from another Australian who was about two weeks ahead of us, that you're apparently supposed to wait ten working days before lodging the application, to allow your immigration records to percolate through the bureaucracy that is the US Government. Our applications were duly accepted without any mention of waiting a bit, but we were sent away with a letter and a tracking number, saying that the SSA had to verify our existence with Immigration (this is despite the fact that we're standing in front of them with a passport with an I-94 stapled in it) and that it would take up to four weeks. So it's been six weeks, and still no sign of an SSN. Enquiries with the office are met with the same response - waiting on information back from Immigration. Apparently it can take up to three months. It's a real shame you can't start the application process when your visa is granted or something, as in order to apply, you need to quote your "alien registration number" (I still chuckle at how the US Government refers to me as an "alien" in all their paperwork), which is the number on your I-94, which you only get when you enter the country. So, whilst the SSN application remains pending, I cannot be paid, I cannot have my health insurance paperwork lodged by my employer, and whilst I'll be covered for health insurance retrospectively, I'm not technically covered right now, if I were to require medical treatment. Going back to how the SSN is the primary key of All Things... Next step is to open a bank account. We chose Citibank, because I've been told it's slightly easier to import money back into Australia with them. Fortunately we were able to open an account sans SSN, but it's called an "NRA account" (NRA standing for Non-resident Alien). We were told that we were only eligible for an ATM card until I had an SSN, yet they mailed me out a debit card about a week after we opened the account, and happily ordered one for Sarah, and a cheque book when we asked after opening the account. About the only thing it seems we can't do at the moment is transfer money back to Australia. No big deal, it's all coming the other way until I can get paid... Driver's licence requires an SSN ideally, so that's out of the question for the time being... Electricity, telephone and cable were all able to be provisioned with an SSN, although I think for credit-rating purposes, again, it is the primary key. We had to pay a deposit for the electricity, which is fair enough. The lady I spoke to on the phone when I got it connected said that they just treated us aliens like teenagers straight out of home with no credit history. I don't have a problem with that. It's just a shame that you can't import your credit history. Getting a cell phone account appears to be nigh on impossible with an SSN though. It was a battle just to get a prepaid SIM card for Sarah's phone, and this makes a great story of how much hoop-jumping is required. We walked up to a Cingular stand in a shopping mall to see what we could and couldn't do. I explained our situation (lack of SSN, lack of credit history, etc etc) to the sales droid, and he assured us it wasn't a problem to get a prepaid SIM card. He proceeded to take about 30 minutes to organise the SIM card. I watched as he entered a dummy SSN into the computer, and used his own driver's licence number. He was clearly battling the computer system to be able to do it. When we got home, and Sarah called up to try and put some credit on the phone with our Australian Visa card, she was told they only accepted credit cards with a US billing address. (So much for Visa being accepted worldwide). So we headed off again to Safeway to purchase a prepaid Mastercard. Funnily enough, when Sarah called up to activate that, she was initially asked for an SSN, so we almost had a dependency loop that we couldn't break, just to get a US cell phone. Fortunately they could cope with no SSN, so she successfully ended up with a prepaid Mastercard, with a US billing address, so she could put credit on her prepaid SIM. From what I can work out, a lot of the places that do request the SSN seem to using the last four digits as an authenticator, much like everyone just uses name and date of birth back in Australia, so I'm guessing for these organisations, I could probably just quote any old number that fit the pattern and they'd be happy. Just so long as they don't go trying to run a credit check against it... Foreign credit cards As I said earlier, a credit card with a non-US billing address is fine for most face-to-face purchases, but an amazing array of mostly telephone transactions will not accept them. Most notable was trying to add credit to a calling card for making international telephone calls. Couldn't be done. So it meant I had to forego any discounts or bonuses for topping up, and buy a whole new calling card. Car insurance and registration I'm not sure how this is going to go yet. Our Prius is supposed to be available around the 18th of January. I'm hoping I'll have my SSN by then, otherwise we'll have to import a heap of money to pay for it. I'm sure you can get insurance and own a car without an SSN, because you hear of people who do driving holidays across the US, buying a car on one coast, driving it cross-country, and then selling it. It might be more expensive, and I again, you can't import your driving/insurance history, so you have to start off at the bottom of the ladder again... In summary, I think you need to have relatively deep pockets to bootstrap yourself over here. You need to be able to function without getting paid for up to two or three months, and you need to understand that credit-wise and insurance-wise, you're going to be back at square-one again, irrespective of how good you might have been in your home country. The sooner you come to terms with these, and appreciate that you are moving to a foreign country, the sooner you can get on with enjoying the experience.

Currently, Nautilus is hardcoded to draw the desktop icon’s captions in white with a black background. This works well for Latin scripts, but for CJK scripts where each character is pretty complex, the captions quickly become a jumble of black and white pixels. Hence the following patch against Nautilus 2.12. It adds a GConf key /apps/nautilus/preferences/desktop_label_shadow, which when set to False prevents the shadows from being drawn. A nice side benefit is that Nautilus then checks the background colour, and draws captions in black if the background is light. Nice. Screenshots later; gotta run now.

--- ./libnautilus-private/nautilus-global-preferences.c.old 2005-11-19 10:58:42.000000000 +0800
+++ ./libnautilus-private/nautilus-global-preferences.c 2005-11-19 11:00:32.000000000 +0800
@@ -404,6 +404,10 @@
      PREFERENCE_STRING,
      NULL, default_font_callback, g_free
     ,
+          NAUTILUS_PREFERENCES_DESKTOP_LABEL_SHADOW,
+          PREFERENCE_BOOLEAN,
+          GINT_TO_POINTER (TRUE)
+         ,
    /* Icon View Default Preferences */
      NAUTILUS_PREFERENCES_ICON_VIEW_DEFAULT_SORT_ORDER,
--- ./libnautilus-private/nautilus-global-preferences.h.old 2005-11-19 10:58:47.000000000 +0800
+++ ./libnautilus-private/nautilus-global-preferences.h 2005-11-19 10:59:35.000000000 +0800
@@ -54,6 +54,7 @@
 #define NAUTILUS_PREFERENCES_SHOW_DESKTOP          "preferences/show_desktop"
 #define NAUTILUS_PREFERENCES_DESKTOP_IS_HOME_DIR                "preferences/desktop_is_home_dir"
 #define NAUTILUS_PREFERENCES_DESKTOP_FONT          "preferences/desktop_font"
+#define NAUTILUS_PREFERENCES_DESKTOP_LABEL_SHADOW               "preferences/desktop_label_shadow"
 /* Display  */
 #define NAUTILUS_PREFERENCES_SHOW_HIDDEN_FILES         "/desktop/gnome/file_views/show_hidden_files"
--- ./libnautilus-private/apps_nautilus_preferences.schemas.in.old  2005-11-19 11:04:30.000000000 +0800
+++ ./libnautilus-private/apps_nautilus_preferences.schemas.in  2005-11-19 11:06:17.000000000 +0800
@@ -321,6 +321,20 @@
     <schema>
+      <key>/schemas/apps/nautilus/preferences/desktop_label_shadow</key>
+      <applyto>/apps/nautilus/preferences/desktop_label_shadow</applyto>
+      <owner>nautilus</owner>
+      <type>bool</type>
+      <default>true</default>
+      <locale name="C">
+         <short>Desktop label shadow</short>
+    <long>
+     If set to true, then Nautilus will draw shadows for the desktop icon's captions.
+         </long>
+      </locale>
+    </schema>
+
+    <schema>
       <key>/schemas/apps/nautilus/preferences/desktop_is_home_dir</key>
       <applyto>/apps/nautilus/preferences/desktop_is_home_dir</applyto>
       <owner>nautilus</owner>
--- ./src/file-manager/fm-desktop-icon-view.c.old   2005-11-19 10:53:43.000000000 +0800
+++ ./src/file-manager/fm-desktop-icon-view.c   2005-11-19 10:58:01.000000000 +0800
@@ -532,7 +532,7 @@
    fm_icon_view_filter_by_screen (FM_ICON_VIEW (desktop_icon_view), TRUE);
    icon_container = get_icon_container (desktop_icon_view);
-   nautilus_icon_container_set_use_drop_shadows (icon_container, TRUE);
+   nautilus_icon_container_set_use_drop_shadows (icon_container, eel_preferences_get_boolean (NAUTILUS_PREFERENCES_DESKTOP_LABEL_SHADOW));
    fm_icon_container_set_sort_desktop (FM_ICON_CONTAINER (icon_container), TRUE);
    /* Set up details */</schema>

First of all, thank you DebConf5 organizers! You guys did a fantastic job in providing the opportunity for both DDs and non-DDs alike to meet face-to-face with each other. Debian definitely is alive and kicking! So it is with great disappointment to see articles like this (”No Way For Linux To Replace Proprietary Software”) when I came back to Hong Kong. It’s an op-ed piece in a local newspaper by Charles Peter Mok, and begins by attacking last week’s Evans Data report for lacking objective data, therefore the conclusion reached (OSS adoption is speeding up) is too far-fetched. This is followed by (translation to English mine):

In fact, due to their love of open source systems (sic), open source supporters often are shallow when it comes to analysis and reaching conclusions, and confirming their subjective wants become their priority; of course, open source critics, like the Microsoft Windows camp and Sun Micro’s Unix camp, sometimes do the same thing.

Maybe he takes the /. crowd too seriously? Anyway, he then essentially translates the month-old SG Cowen report as an example of an objective argument… actually the translation is rather dubious. For example, the report only said “Linux seems to be hitting a limit” (via BusinessWeek); he translated that as “Linux’s development has reached the stage where it’s facing piling limitations”. What a nice and objective extrapolation! Moving on, he uses the report to reach the conclusion that (again translations mine):

… whether Linux will still enjoy considerable growth, or the red light has been lit, is at the moment too early to say. Enterprise and personal users who use proprietary software such as Windows are still the majority.

Thanks for stating the obvious, Charles. So where’s the objective argument that supports the title of the article?

I’m still arranging things, but it’s looking very likely that I will be at Debconf5…

Just went back from today’s roundtable discussion on “IPR Issues and Open Source” hosted by the National 863 Project. It was well attended, with major software companies as well as experts from MII, MOST and the academia. In particular I found the talk by Peking University’s Dr. Zhang most enlightening — they have done extensive research on almost all open source licenses (including CDDL), as well as the impact of software patents on open source. Unfortunately I’ve learned today that China has already granted software patents. Even more sadly is the fact that most participants viewed software patents as ‘inevitable’, as a thing that Chinese companies need to deal with as they join the global community. I told them about the various software patent backlashes around the world, especially in Europe; and also asked them to ponder the question of whether software patents, as currently implemented by the US, is a sensible and logical thing for China to move towards. Hopefully this will get them thinking…

1. What is Preventa?

Preventa is a port of the Debian and GNU userland to the Minix 3 kernel and libc. Hence an alternate name is Debian GNU/Minix (but I won't use that unless it becomes an official Debian port. See below.) 2a. Why is it called Preventa?

It's a riff on the last attempt at porting Debian to a non-Linux kernel which was called Nexenta. 2b. Why is it called Preventa?

Because if it becomes an official Debian port, it is probable that the sheer number of release critical bugs caused will prevent Debian from ever releasing again. 3. Is this an official Debian port?

Currently Preventa has no official connection to the Debian project. In the future? Perhaps if there is some interest. I'm not persuing that angle right now. 4. Does Preventa suffer from licensing problems like Nexenta?

No, the Minix kernel and libc are BSD licensed. 5. So why are you doing this?

Like many people, I used Minix when I studied operating systems in college. I am interested in trying the new version but I am more comfortable with a GNUish environment rather than the BSDish one that Minix provides. This led me to wonder how hard it would be to port Debian and in general, how much work goes into a new Debian port. Maybe I might be able to write some articles about the experience. Other than that there is no practical reason really. 6. How can I help?

At the moment I am just doing this for my own edification so I'm not looking for help. This will undoubtedly change if I get stuck. 7. What does the port entail?

I will attempt to port dpkg, apt, and the Debian base system plus a few other odds and ends I feel I need. I will use the Minix kernel and libc (unless GNU libc turn out to be easy to port which I suspect it won't.) Basically Preventa will have the same kind of features as the official Minix3 distribution. If I have to patch anything I will offer it back to the Minix and/or Debian maintainers if they want it. 8. Where can I keep abreast of your progress?

I will blog about it. As soon as it is somewhat usable, I will release the results (including source of course) to the public for people to use as they wish. 9. what does ast and the Minix community think about this?

I haven't told them yet. I should do that soonish. 10a. Hi, I'm from OSNews and I don't like Preventas' green on black theme. And the file manager is totally unintuitive.
Uh, that's the command line. Minix doesn't support the X window system yet. 10b. Then I dub thee "not ready for the desktop."

Aieeee!

2006, what a lovely year! Not. I heard its a custom, that at the start of the new year, one looks back at the past one. So I did, and wasn't impressed at all. Mind you, the same happens each and every year, so it is no suprise, really. For the past year, I have been rather inactive, I should have gone on an extensive vacation from Debian a long time ago, around May, when I quit my last job. I intend to rectify that as soon as I manage to dig up my GPG key. Most of my packages will get officially orphaned too, as I lack the time and motivation to work on them - no news here, either, as this is the case since early last year. Lets see what I did on the free software front in the past year or two... One of my most succesfull projects was CCZE, a log colouriser. Needles to say, the idea is not mine. The crap implementation, the most messy and bad code I've ever written, is mine, though. It hasn't seen an update since I don't know when. Nor will it in the foreseeable future. The only thing that could help the codebase, is a rewrite, which I had been planning since 2003, and not a bit of code was committed ever. In the meantime, new programs appear, whose logs could be colourised, new demands arrive, but the project has been dead for good. Once, Thy was the software I was most proud of. I really loved it, and spent most of my time hacking on it. Those times are past, new, similar software appeared, that surpassed my beloved HTTP daemon in nearly every respect. I don't believe thy has any place among todays similar projects. This, I truly regret, I had great fun developing Thy. But as everything, even good things must come to an end. Back when I worked for a company that was into this media streaming business, I contributed a few bits and pieces to GStreamer, but all the "grand ideas" I had, and wished to make reality, never happened. Looking further back, I can't notice any significant contribution I made.. except maybe one, a very small one.. Even nowadays, I can't stop feeling a little proud, when it crosses my mind. Some may know, most probably don't, I acted as an application manager for Debian, and for a little while, I like to think I wasn't that bad at that job. For a little while... Anyway, during this, I had the pleasure to work with Daniel Stone. Heh, those were good times! I hope, that what we've done there, was of at least a bit useful. Meh, enough of this. My projects failed, I didn't have the neccessary resources to make some of my dreams come true. All I need now, is a break, a break so I will not feel bad about things I do not have time for. I'll let them go, as I should have done ages ago, that's best both for them, and me. Until a time I feel I can contribute back something, for all I received from the free software community, I'll take a vacation. From time to time, I'll be hanging around on IRC, but my activity will be as low as it was during the past year. Good bye, and thanks for all the fish! P.S.: Yamm, my over-sized tamagotchi expressed interest in maintaining me in Debian. If, by any chance, he'd take over my computer, and expressed his wish to run for DPL-ship, please, by all means, stop him. Thank you.

During the last two months, I taught an elective course on introductory functional programming. The nominal target group was third-year information technology undergrads, but in practice the student body consisted of everything from second-years to almost-done masters students. All had taken at least a year’s worth of general programming courses (taught in Java most recently, earlier in C++), a full semester’s worth of data structures, a half-semester of automata and grammar theory and some mathematics. I have enough teaching experience (been teaching two courses a year since 2002) to know my faults. My biggest fault is that I routinely underestimate the difficulty and laboriousness of tasks I set for my students. My second biggest fault is that if I am not careful, I can easily revert to reciting reference material, that is theoretical definitions, instead of giving a tutorial. I am better at avoiding the latter fault than the former, although when I have little time to prepare, the latter fault will, too, manifest itself. Knowing these faults, I tried to plan this course so that there would not be such trouble. Reading Baen books, I have learned a military saying: Battle plans never survive contact with the enemy. I found myself in a similar situation: my course plan did not survive contact with the actual teaching situation. The broad outlines of what I was going to teach held mostly. Other than that, it ended up being a very different course than I had originally envisioned. I started by giving a crash course on Haskell IO: how to write simple text-line-based interaction in Haskell. The idea was to introduce early the part of Haskell that many people think is hard but is actually quite easy, by explicitly drawing on the students’ imperative programming background. After IO, I ended up trying to give the students a broad, working knowledge of pure functional programming in Haskell, starting with first-order list processing and further discussing topics like parsing, persistent data structures, higher-order list processing, et cetera. I found that it was hard to give any of the topics proper room time-wise, as the basic concepts of functional programming are somewhat circularly related. At this time, the students complained that the course is hard, and many dropped out. They shouldn’t have; we had covered the main topics of the course in half the time. I could then use the rest of the time to go over the topics again from a different point of view, and give them time and tools to integrate it all to their own internal know-how databases. In the latter part of the course, on the surface we discussed Haskell metacircularly, but that was mainly a tool to reinforce the stuff done earlier in the course. Of course, my exercises were a little on the harder side. I ended up lowering official expectations about how much of the exercises the students were expected to solve, and that seems to have helped. Of the 20 people who took the first exam, 18 passed. The advanced course starts in a week or two.

Aggregation the G way.
I've been using the magic of RSS (and Atom) to keep up with Planet Debian, blogs of my friends, tech news and posts to an anime fan forum for the past several months, however one little problem bothered me - the forum has a lot of posts (sometimes more then 5 per minute) and an RSS feed of only last five items. That means that I had to have my RSS aggregator (Liferea) open at all times, so that I do not miss any posts. However keeping my laptop on and online at all times is quite bothersome, so I started looking for solutions.
I tried Google Reader however I didn't like it much - I like to see more of my feed. There is too much screen space wasted for all the wrong reasons, one can only see 5 items at the time (which is quite a hassle if you have 500+ of them), a lot of info I would like to see is not there (which blog did this come from???), some strange html conversions, ...
Now I have found my solution. It is a combination of rss2email and GMail. I have a computer that I always keep on and online (it could be a server, but in my case it is a simple workstation). I installed rss2email there, added all my feeds to the database there (hint: export feedlist from Liferea and do a bit of grep/sed magic), moded config so that all mails come from a single address, all have a custom identifiable header and all are HTML mails without any transformations. After that I configured cron to launch "r2e run" every half an hour and "r2e run 22" every minute (where '22' is the id of the feed of that anime forum). At Gmail side I simply filtered all mails from rss2email into a separate label and archived them (so that they do not clutter my inbox).
Now when I want to reed my feeds, I go to the last message of the RSS label in my Gmail, open it, read it, star it if I need to look at it later and then press "k" to get to the newer message. After I am done reading I usually go and remove RSS label from read messages, so that they do not appear in this labels "folder" and are only saved in Archive. If I start running out of space, I will simply search and delete old RSS items then.
Most of the screen space now is devoted to the message, I can see all the fields I want to see (source, author, topic, content, pictures, URLs) and I can manage messages by hundreds. Also being able to search both your mail and your rss feeds at the same time is neat.
Yesterday I did a little improvement to this scheme. The forum that I read has the title of every message made of "author: topic", so every message is a separate conversation in Gmail. I decided to try to use the conversation feature of Gmail and did a little modification to rss2email so that if the message is from this forum, then everything up to the first semicolon is cut from the title and inserted as a part of the name of the sender. In the end the subject of every message contains only the topic of the corresponding thread in the forum and thus all messages from one thread are neatly grouped together as a single conversation. At the same time every messages From: looks like "$forum_name $author " so that I can still see who wrote what in the forum.

If you re selling anything, there are three kinds of people out there: those who will buy from you, those who might buy from you, and those who will never buy from you. It s not cost-effective to try to shut down the third group, and there s a word for unpaid use by the second group: marketing .

From On Selling Art, by Tim Bray.

Abridged to remove irrelevant conversation…

< Czesiu> Btw, udev recommends at least 2.6.12 kernel, which is not shipped
in Debian.
< Md> so far the upgrade procedure is “upgrade your kernel, reboot,
upgrade udev”
< Md> Czesiu: yeah, nobody had told me this yet, you know?
< dilinger> you can either go the lvm route, and make up some kernel APIs to
match again, or you can go the ndiswrapper route and make some incredibly
strict dependencies so that people are sure to upgrade kernels and udev
in parallel.  both solutions suck.
< Czesiu> Md: you sound quite sarcastic :)
< wildfire> why not just have a udev-compat; which conflicts which newer
kernels; and make udev conflict with older ones
< Md> dilinger: a future udev version will refuse to install on anything
older than 2.6.12, so this will reduce the potential for brokeness
< Md> the /dev/input/mice problem has been unexpected, if it cannot be fixed
I will make the next package require 2.6.12
< dilinger> the best solution, imo, is to have udev 0.5x and 0.62 allowed
to be installed in parallel, and have a wrapper script that determines which
to use when it’s run
< wildfire> hmm, dilinger, that does sound pretty clean
< Md> dilinger: the configuration syntax is subtly different too. this is
not really possible
< Md> wildfire: yes, until you start looking at how to implement it 
< dilinger> Md: sure it is; /etc/udev05x for the old version or something
< dilinger> /etc/udev for the new version
< wildfire> md, but that’s someone else problem ;-)
< Md> dilinger: keeping them in sync is hell
< dilinger> no kidding, but that’s what maintaining stuff like this requires
< Md> so far, it appears to be too much complex to be justified
< Md> if upgrades will happen to be more complex than we currently know then
I will reconsider this
< dilinger> are you kidding?  i think the number of people whose systems
are breaking is pretty good justification
< Md> dilinger: only because the package currently is not refusing to run
on older kernels
< idnar> Md: but if the package fails to run, isn’t that likely to cause
breakage too, since your /dev won’t look like it normally does?
< Md> idnar: it will refuse to be installed or upgraded, like it’s currently
happening if you are using a kernel < 2.6.8
< dilinger> Md: what about doing something insane w/ devfs/
< dilinger> and devfsd
< Md> dilinger: ?
< idnar> Md: ah
< dilinger> depend upon devfsd, if the kernel is older than 2.6.12, have it
mount devfs over /dev and run devfsd instead of runing udev
< Md> different configuration syntax, different semantics, no HAL/hotplug
support. basically, I can’t see why you could think about this
< dilinger> because it would allow things to *work*
< dilinger> even if it doesn’t have the same config syntax
< dilinger> it could spit out a big warning upon startup
< idnar> suddenly switching the user to devfs would likely cause all sorts
of unknown breakage
< Md> if the kernel is older than 2.6.12 people will not be able to install
a newer udev, so this is not relevant
< Md> please try to look at the whole picture
< dilinger> people are going to want to reboot into older kernels and have
their /dev in a sane state
< dilinger> the running kernel isn’t the only one they may be using
< Clint> yeah, i’m not using the running kernel
< Md> dilinger: then udev will automatically disable itself. the current
experience shows that users are not bothered by this
< dilinger> Clint: quiet over there :P
< dilinger> Md: the user experiences around here don’t seem to match what
you’re saying, otherwise i wouldn’t even be mentioning it
< Md> again, this is not how future versions will work
< dilinger> let me put it another way
< dilinger> it would be a very good idea to future proof udev against such
incompatabilities now
< Md> tell greg k-h, now me :-)
< dilinger> because i’m sure things will break again
< Md> anyway, you persuaded me. I will upload right now an updated package
which refuses to be installed with old kernels
< Md>   * Kernels older than 2.6.12 are not supported anymore.
< Md>     If detected, the package will refuse to be installed.
< Md>     If the running kernel is downgraded after the package has been
< Md>     installed udev will disable itself at boot time.
< Sesse> Md: whoa
< joshk> that’s ridiculously stupid if you as me
< Md> this is what was going to happen in a few releases anyway
< Clint> joshk: coredump immediately
< Md> BTW, I suggest that concerned people read this before continuing
http://sourceforge.net/mailarchive/message.php?msg_id=12236847
< joshk> breaking support for anything but the very latest kernel (which
isn’t even in debian yet!) is dumb. you break everyone’s desktop because
hal stops working
< joshk> (one particular example)
< Md> joshk: people can keep the old udev until the upgrade, nothing breaks
< Sesse> Md: *g*
< joshk> don’t grin at Md, it makes him think we’re in agreement

Audioscrobbler is an awesome service that tracks what you’re listening to, makes that play history public and generates statistics, suggestions, and links to other people with similar tastes to yours. It’s got growing pains, certainly: It’s a big ol’ Java servlet, and the server admin needed to edit and recompile the servlet to add a new client ID for my “QLScrobbler” plug-in for Quod Libet. Apparently there are some isolated cases of database corruption as well. But all in all, it’s a useful concept, and it wins on that merit. This is all a big plug for the Debian Developers user group on Audioscrobbler, which, once more than 10 members join, will get charts generated so people can see what developers listen to while breaking their favorite packages.

(AOL!) [ 7 ] Choice 1: Jonathan Walther
[ 1 ] Choice 2: Matthew Garrett
[ 1 ] Choice 3: Branden Robinson
[ 5 ] Choice 4: Anthony Towns
[ 3 ] Choice 5: Angus Lees
[ 2 ] Choice 6: Andreas Schuldei
[ 6 ] Choice 7: None Of The Above I haven’t been doing too much Debian work lately, but I think I’ll be uploading discover1-data and abiword soon. I will have to find a big chunk of time if I hope to do any kernel or d-i work.