Many Linux fans know that Debian Stable usually already lost the “b” when it’s being released. ;-) What seems not so well known (especially not by some DesktopBSD Marketing guy at last year’s LinuxDay.at :-) is that there is really a lot of people who really like this “stale” software collection — because it’s rock solid — especially compared to the ports in FreeBSD or DesktopBSD *evilgrin* which unnecessarily follow every new feature upstream introduces. This is really annoying in a server environment where you want as less changes as possible when updates are necessary due to security issues. My personal favourites here are Samba and CUPS. *grmpf* Although I belong to those people who run Debian Stable even on brand-new hardware, I sometimes have to use the newest beta or alpha versions of some software to get it even only running. And doing so is fun but feels strange somehow, though. Currently I follow the pre-releases of three software makers quite close, due to a new laptop: At the beginning of last semester I bought a brand-new Lenovo ThinkPad T61 (2,2 GHz Intel Core2 Duo T7500, 4 GB RAM, 160 GB HD, 1440x900 14” Widescreen) without preinstalled operating system (possible thanks to the ETHZ Neptun Project) and installed — of course — 64-bit Debian Stable on it. While the Debian Installer from Etch worked fine even on such new hardware, not all features worked out of the box because some components were just too new. So the first thing I did was installing 2.6.22 from Backports.org, quickly moving farther to vanilla 2.6.23. Nearly everything I needed worked except the wireless network card. It needs the iwlwifi driver which is officially in the Linux kernel starting at the upcoming 2.6.24 (said to be released during the next few days). So I run 2.6.24 pre-releases on the laptop since the first release candidate, always eagerly waiting for either the next RC or the final release. (And 2.6.24 looks impressively stable to me — even since the early release candidates. :-) I even got the fingerprint reader working for login and sudo (but not xscreensaver) using libthinkfinger backported to Etch from Debian Experimental. I’m just not sure if this is a good idea since the back of the screen already has enough of my fingerprints on it. ;-) The next software of which I’m currently running an alpha version is 64-bit Opera 9.50 (aka Kestrel, available at snapshot.opera.com) because no earlier Opera version is available for 64-bit Linuxes. Here I had different experiences: The builds from October and November were already quite stable, but since December it crashes usually several times a day. At work I also run the 64-bit Opera on my workstation, but stalled updating it when I noticed that it became so unstable. So my Opera at work has currently an uptime of nearly four weeks — and would have probably more if I hadn’t rebooted my workstation in Mid-December. Somehow this hunting for new versions and eagerly waiting for every new (pre-)release makes me really fidgety sometimes. And my understanding for people doing this for there whole userland or even operating system has grown, but I still prefer to have stale but stable software on all my productive machines, even on my laptop — just with some few and handpicked excpetions. The third but less thrilling thing I’m following are nVidia drivers for X. Since the free nv driver of X.org doesn’t support (and not only just doesn’t know) my graphics card yet and nouveau isn’t ready yet, I run the binary only and closed source driver from nVidia, waiting for that one release which supports Xen since I really would like to run a Xen guest with Debian Unstable for testing purposes and package building on my laptop. Until then I have to content myself with the much more unwieldy QEMU respectively KVM. Anyway, I’m very happy with the T61 and Debian Stable and can easily connive at the few not (yet) perfect issues like missing Xen support by nVidia, broken ad-hoc mode in the wireless card, no internal card-reader (as announced in the Neptun specifications) and no native serial port. Some useful links regarding the subject of this post:

• Linux Weather Forecast
• Opera Desktop Team
• Nouveau: Open Source 3D acceleration for nVidia cards
• ThinkWiki

Now playing: Jean Michel Jarre — Rendez-vous à Paris

I really appreciate that you've written tests for your software; it raises the chances that you're not a screaming moron by a few points. However, please understand that you may not be the last person on earth who may wish to benefit from the test suite, and DOCUMENT HOW TO RUN THE FUCKING TEST SUITE. I'm currently into my third hour of trying to work out what precise set of dependencies and incantations is required to make your test suite run. Bonus hate is available for that subset of these people who reject patches that don't come with suitable additions to the test suite.

That's how I'm passing this week. What? No, I'm not getting married. It just feels like my body isn't quite sure whether it wants to be sick or not. On monday, I got down with influenza, mostly in the stomach area. Not only does that hurt and feel awfully bad, it also involves your yesterday's lunch reversing direction halfway through the digestive system, and finding the wrong way out. Some people call that puking. Being restless, doing nothing, I tried to do some work for Debian. Bad idza. Now usually, when I get sick, I get really sick. For one day. The next day, I can work again. That doesn't mean I'm at my best, but at least I can handle some stuff. So on tuesday, I went to work, since I had this appointment on wednesday and I still had to prepare some stuff for that. I made the mistake, however, of not dressing warmer than usual. With my body still recovering, and with the extra bad weather in the evening, I caught a bad cold. So on wednesday, I stayed at home. Lucky for me, customer had asked to postpone the appointment on wednesday to thursday, since he wasn't going to get everything ready in time otherwise. Me, I was still feeling the leftover sickness from the influenza, and now this cold was tearing me down. But as before, after one day I felt much better, so I thought I'll just dress much better this time, go to that appointment, and make the best of it. I figured it couldn't be that bad. Except that in a data center, the temperature is optimized for computers, not for sick human beings; and nobody cares about the noise, or about the fact that trying to yell above said noise isn't a very good idea if your voice is having issues because of some virus. I guess the only nice thing that happened this week was that nice lady on the train who gave me a clean handkerchief when my own was... well... you don't want to know. Tomorrow, I guess I'll just stay in bed. And on saturday, and perhaps even sunday, too. Get this week over with.

I don't know why some people always shout censorship when it's about what is acceptable behaviour and what not and about what things people want to be assosiated with and with what not. (Must be some relative of Godwin's law (the original, not the "you lost" usenet-variant)).

I personally do not care only little about what happens in irc-channels I'm not in. I don't know what happens in this this special channel starting the discussion, and I don't believe any anedotically examples can make a big difference. (Humans err, sometimes in tone, and even some hundred examples of wrong tone in some backyard alone is nothing I care much about, as long as it is nothing that would be a criminal offense if done in more public places).

What I absolutely dislike is any form of communication forum - especially those that could be associated with me - to be declared as a place where foul behaviour (to which I count sexism) is acceptable and even worse to be accepted as norm. (Why didn't anyone shout "censorship" at the "Love it or get the fuck out of here"? Perhaps there is some correlation between views of the world I don't understand).

By the way, there are places where I feel personally offended as a victim of sexism by a statement like "men are pigs". For example in a discussion about sexism. (I know, I know, it might not be sexism according to some definitions, but I see no reason to not use the word or not dislike it just because the forcing into gender roles is done by members of the same sex as opposed to to members of the opposite sex.)

The story seems to have started with Damog supporting sexism and xenophobia in Debian, followed by Bernhard’s comment about that not being tolerable under Debian’s flag. Aigarius replied kinda shocked that stopping verbal abuses and violence would be censorship. AJ clearly explained the reasons why that shouldn’t be tolerated in Debian, but Aigarius seems to keep thinking that poor jerks are being discriminated when they’re not allowed to insult us. Wouter seems to be tired of the whole topic. Am I missing any chapter? Now my turn: We are on the right way. Since the Debian-Women project started, we have being able to achieve a friendly and non-sexist environment inside Debian, which is something that I’d really like to keep. It doesn’t really mind that a couple of people try to go back to a hostile environment. Trolls just do exist, I guess, but they are not representative of the general feeling of the people inside Debian. Damog, I won’t get the fuck out of here, like it or not. It seems to me that it’s just a couple of you who are happy to be in such an aggressive environment as the one you’re promoting. For what I know, most of Debian people are happy to live in peace. You don’t have social life? You don’t like it? That’s your problem, dude, but don’t ask us to leave ours. I respect you, you know I have always done. I’m just very disappointed with your comment. Really. Making fun of other people’s problems and traumas is simply bullying. I hope you think about it. For the rest of Debian, keep up the good job. Right now my feeling is that the level of sexism, racism, ageism, homophobia, hostility and unfriendliness in general inside Debian development’s world is below the average in the Free Software world. It’s nice to be there, and I’m really proud of belonging here, which is something I cannot say about every group in Free Software. I’d like to keep it that way. Sorry for the aggressiveness in this weblog entry.

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

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

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

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

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

It is not uncommon to run a Linux system with a kernel that was compiled for another distribution. One reason for doing this is the difficulty in compiling and testing a kernel to make sure it will do what you require. It’s not THAT difficult for someone who knows what they are doing, but if someone else has already done the work then it seems like a waste to re-invent the wheel. Sometimes it’s an issue of a driver that one distribution supports but not another, copying the entire kernel package from another distribution may be easier than compiling a new kernel with the extra driver. Sometimes it’s a kernel bug, if distribution A has fixed the bug and distribution B hasn’t, then it’s often easier to install a kernel package from distribution A when running distribution B. Another reason for running different distributions with the same kernel is Xen. If you have a Dom0 which hosts instances for different distributions as DomU’s then running the same kernel on all of them can make it easier to manage. Unfortunately it’s not uncommon for different distributions to have different kernel feature sets. One example I’m currently dealing with is the fact that the Debian/Etch kernel is compiled with CONFIG_AUDITSYSCALL disabled while RHEL and CentOS require it. So if you run a RHEL or CentOS system with a Debian kernel (EG running a Debian Xen server with a RHEL or CentOS DomU) then you see messages such as the following in your logs. crond[7824]: pam_loginuid(crond:session): set_loginuid failed opening loginuid The loginuid feature allows login and equivalent programs (which includes xdm and other graphical login programs, cron and every other program that runs a program on behalf of another user) to set the loginuid. This loginuid will be stored by the kernel, inherited across fork() and exec, and not be changed by running setuid or setgid programs. Therefore if you see some strange entries in your audit log indicating an attempted attack you can determine the original login UID of the person responsible. In terms of security features it’s not a really high priority. But it is really annoying when programs that work on RHEL don’t work properly with a Debian kernel and put many unwanted messages in the log files. For people who have less background knowledge about these things it may be more than annoying, and may even force them to change their deployment plans to make the message go away (not everyone knows which messages can be ignored or where to ask about such things). The fact that Etch has no user-space support for the auditing features in question (auditing system calls or setting the loginuid) was never a good reason for not enabling this feature (IMHO). Using the auditing system calls was simply a matter of copying the auditctl program from a RHEL, Fedora, or CentOS system (for those who didn’t feel inclined to compile the source). The loginuid required changes to PAM to enable it, but is actually a small part of the auditing layer. As a general rule minimising the differences between distribution kernels is going to benefit most people. Some people complain about kernel bloat, but there are worse candidates for that accusation and given that it seems impossible to buy a machine with less than 512M of RAM and a 900MHz CPU (the specs of the ASUS EeePC) adding a few extra kernel features seems unlikely to hurt anyone. It is of course always possible to compile your own kernel for the smallest machines. Finally I am in the process of back-porting SE Linux code and related security features to Etch, and having this already enabled in the kernel would make my work easier. I won’t do a 7 year support cycle for it unless someone pays, but supporting Etch past the release of Lenny with the latest SE Linux features (and the current features working properly) is my aim.

Share This

AJ, if some blogs would support comments, I would leave my opinion there and not add noise to the planet. 1) Censorship does not stop being censorship just because the people doing the censoring don’t have the absolute power to censor the information everywhere and only block the information or opinion from the channels they can control. It can be called otherwise - editorial control, policy of political correctness, libel liability protection policy, Children-Safe Talk Initiative or Women Friendly Environment Collective. But at its heart it is still censorship of all official Debian-related channels of communication as the aim is to remove the objectionable content from all such channels. 2 and 3) Discriminating against jerks is also a discrimination against people or groups. Please do not get all DFSG-bendy on me here. DFSG is about use and distribution license of the software and not about the communication channels used to facilitate this process. I could actually counter you with a quote from the Social Contract that says that we will not hide problems. The discussion as such admits that some people consider sexism to be a problem in Debian (for example). Excluding sexist comments from Debian official channels will not make sexism magically disappear, it will be just hidden, swiped under the rag and said to sit quiet. The only problem is that the community that is tired of such hushing is much larger then anticipated. There are people that think that men and women are different. We checked. I can’t see anything bad in the example quoted on the planet so far. Yes, the depth of the discussion is weak - we can’t be genius all the time, but I really fail to see who is insulted in there. Lesbians? Don’t think so, they are compared to a threesome quite favorably. That is not a technical discussion about interrupt timings, but that’s why it is in offtopic. Doh! Relaxed chit-chat like this is typical in all healthy and tight-knit communities. Is it offensive to women to talk about sex??? Grow up and have a good 3 hour chit-chat with some real women. Women talk about sex even more than men. Especially on-line. Can someone really show what is the “OFFENDING BEHAVIOR” so obscene and dangerous that people want to censor out of Debian and explain what exactly they see as being so horribly bad to Debian that they see total censorship of all Debian communication channels as an acceptable countermeasure?

A very sad day approaches.

Those of you old enough to remember Gopher may proceed to shed a quiet, ASCII-art tear. Gopher document type 0.

For those of you that don't know what Gopher is, here's my quick summary:

* It existed before the web.
* It is an extremely simple protocol designed to be an Internet-wide filesystem, though the bit that let you mount the Internet like a disk never quite happened, though still could. (actually I think I saw a FUSE gopher implementation recently)
* It pretty much does everything that WAP does, but about 50 times simpler. Why smartphones invented WAP instead of just using Gopher is still a mystery to me.
* XML-RPC is usually extreme overkill when you could use a simple protocol like Gopher

Now how many of you remember Veronica and Archie?

Oh yay, another argument about sexism. I thought we were over this. Aigars writes:

Trying to restrict what words people can or can not use (by labeling them sexist, racist or obscene) is the bread and butter of modern day media censorship. It is censorship and not “just political correctness”. While I would not want people trying to limit contributions to Debian only to “smart and educated white people” (racism) or “logically thinking males” (sexism), going the other way and excluding people from Debian because their remarks or way of thinking might offend someone is just offensive to me.

One: it’s not censorship for Debian to limit discussion of various things on Debian channels. It’s censorship when you prevent discussion of something anywhere. Two: if you think excluding people is bad, then supporting jerks whose mysogyny repulses people isn’t compatible with that. Three: doing something in someone else’s name, that isn’t supported by them, is wrong. If you’re in a channel called “debian-something” don’t act in ways that don’t match Debian’s goals. If you want to be free to go against the principles of the DFSG by, eg, discriminating against people or groups, make up your own name for a channel.

The past few weekends I've been drawn to the mountains. Two weeks ago I went up on Holston mtn after the snow had melted down here, and enjoyed a snowy hike on the AT. From there I drove over to Shady valley, and found the only gas station I've seen with a wood stove in it. I've never enved a gas station attendant their workplace before, but that was nice. Last weekend Maggie and I went up to Roan mtn. On road up we began to get glimpses of the peak in between the fog, and it looked strange, almost like there was snow, but not as white as you'd expect. While the ground was clear of snow, the windward side of each pine, rhododendron, and leaf of grass in the balds was outlined in a thick coat of frost. Gorgeous. As a sheltered Southerner, I've never seen anything like it, but I think it was soft rime, formed from the fog. We wished we'd brought a camera, but thanks to the magic of the 'net, here's a similar rime on Roan:

I've been quietly coveting the Zonbu for a number of months now. I finally caved in and ordered one when we got back from Australia, with the intention of using it to replace minotaur, the computer that exports my RAID10 via ATA over Ethernet to my MythTV box. minotaur is the old daedalus, which I bought back around 2000. It's a VA Linux Pentium III. It's old, noisy, and has no idea what power management is. The Zonbu has more grunt than it (in terms of BogoMIPS), and it's a fraction of the size. Our linen cupboard is now significantly quieter (and hopefully cooler). Heck, hopefully the power bill will be lower as well. Anyway, I put the order in when we returned from Australia, with the expectation that it'd turn up some time while Sarah was in hospital, or shortly afterwards, and I could use the rest of the month that I was off work to play with it. Well, I got an email on the 31st of December, telling me they were out of stock, and unless I wanted to pay $29 more for one with built-in WiFi, I'd have to wait until mid-January. As I just couldn't see the point of having WiFi (or spending more money) and not needing the thing in a hurry anyway, because I had more important things to worry about in the meantime, I opted to wait. This morning, I emailed them to enquire about whether or not more stock had arrived, and they emailed back to say that they were still waiting, but they'd found one they could sell to me anyway. The company happens to be close by in Menlo Park, so I picked it up today in our travels. Let me just say that it is a very cool little computer, just if you use it for its intended purpose. It's running a customised Gentoo Linux, with a 2.6.22 kernel. I'm a bit surprised about their choice of Gentoo. I think they'd be better off partnering with Canonical, given that Mark Shuttleworth is trying to make a Linux distribution easy enough for his grandmother to use. That'd take the work of engineering the operating system out of the equation, then they could just focus on the hardware and a bit of integration with Amazon's S3. The thing I have to give them mad props for is documenting how to hack the tripe out of the box. They tell you how to enable root. They tell you how to enable PXE booting. So once I figured out that the front USB port seems to get treated slightly differently for a USB keyboard than the back ones, it was very easy to PXE boot it and install Debian. I initially started with trying to install Etch, but I kept getting missed interrupts on the CompactFlash device, which resulted in the filesystems panicking. So I gave up and went with Lenny, and presumably because it also uses 2.6.22, everything seemed to go fine. The box comes with a 4Gb CompactFlash card, which is ample for my needs. It's running the 686-optimised kernel, which is probably not ideal, but works. We'll see how things go. Interestingly, I blew another hard drive power supply, exactly like last time. I've no idea if it's the act of plugging everything back in again that's causing the problem, or they're generally flaky, and they don't fail until they're powered off and back on again. Maybe that IEC Y-cable wasn't such a good idea after all. I've now run out of spare power supplies, so I'm going to have to get some more for when these two inevitably fry themselves. Overall, I'm very pleased with this purchase, but it's a bit early to see how it's going to perform. I can't imagine it's going to perform worse than the computer it's replacing, but it was probably never intended for what I'm using it for either... Oh, and I discovered vblade-persist, which seems to be a very nice framework for managing ATA over Ethernet exports. Now I just need to get my hands on a big tub of Lego to build a nice chassis for the whole thing.

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

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

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

Still no solution on the issues I wrote about a few days ago.
Mentions of the problems are surprisingly few and in between; either it's not universal or people just don't notice / are not bothered by it.

A new version of shadow packages (login, passwd, useradd and all other low-level user management utilities) hit unstable this week-end. That release is quite a major update as this is the first release where Nicolas Fran ois introduced numerous changes meant to make the versions of shadow used in various distros reconverge. So that version now really says "hey, Debian took shadow over". He thus incorporated lots of patches from Gentoo and Fedora as well as a few Debian ones (Debian packages were apparently closer to upstream code than others). He also added support for SHA256 and SHA512 encryption methods. Careful users will read /usr/share/doc/login/NEWS.gz to get an idea of these changes. After a small hiccup with 4.1.0-1 (The "Bleu d'Auvergne" release) which was hitting our German-speaking users (login is now providing a German version of su(1) which is also provided by manpages-de, therefore making the package uninstallable), 4.1.0-2 (the "Bleu des Causses" release) is there sitting in unstable waiting for testing. Nicolas is already working on 4.1.1, now focusing on code cleaning. That version should be out pretty soon. Also note that we'll soon be short of "Appellation d'Origine Contr l e" cheeses names for the releases and we more and more have to make our imagination work. General de Gaulle was wrong: there are not 50 million cheeses in France.

I've been a bit behind with the ISC DHCP v3 package of late. I've had a package of 3.1.0 for a few months, but I'm becoming more and more reluctant to make uploads of this package without giving it some rudimentary testing. Real life has been demanding of late, so I haven't had a chance to do that testing. Nothing's gone wrong with the package to date, I just feel negligent not giving it some basic testing before throwing it out there. So I chucked a spare QFE card in my workstation brutus, put unstable on the second hard drive, installed Debian unstable on the spare 10G partition of Sarah's old PowerBook, and lashed the two together with a bit of CAT-5, and voila, instant DHCP client/server testbed. So now that I'd verified that version 3.1.0 wasn't blatantly broken, I could have a fiddle with the new support for option 119 (domain-search) that has people at work very excited. I spent a bit of time off on a wild goose chase trying to figure out how to configure the DHCP server for this new option before I realised it was as simple as option domain-search "foo bar baz"; and then made the necessary tweaks to dhclient-script. I'm figuring that since one of the blokes who wrote the RFC works at Apple, and since Leopard supports option 119, the way they're doing it in Leopard must be approximately correct, so I've altered the behaviour of the DHCP client accordingly. All of this assumes you're not using resolvconf. Prior to 3.1.0, if you had the domain-name option set, the /etc/resolv.conf created by dhclient-script would set the search directive to the domain name. With 3.1.0, I've decided to make this set the domain option instead. The resolver behaviour remains the same, as best as I can determine. With 3.1.0, if the domain-search option is set, then the search directive is set to this. If the domain-name option is set, this is prepended to the list of domains in the domain-search option. This is consistent with what MacOS X 10.5 (Leopard) does. I'm not sure what Windows does (nor what version started honouring the domain-search DHCP option)), and since it doesn't have an /etc/resolv.conf equivalent, it's a bit hard to test. I'm going to hazard a guess and hope that since the other bloke who wrote the RFC works for Microsoft, that maybe, just maybe, Windows and MacOS X at least behave the same way. Currently, if resolvconf is in use, you get the old behaviour whereby the search directive is populated with the contents of the domain-name option, and the domain-search option is ignored completely. I've filed #460609 with a patch to fix this. Interestingly, resolvconf itself internally collapses the domain and search directives into the search directive of the /etc/resolv.conf it generates, so I can't quite get the same /etc/resolv.conf generated as would be generated without resolvconf being used. No big deal, the behaviour should be the same. The domain directive is largely unnecessary as I understand it. I have unearthed what I consider to be a bug with the domain-search option handling code in the client. It seems to be largely benign, apart from causing the client to emit some errors when it's obtaining a lease that contains the domain-search option, and possibly not splitting the domains in the domain-search option correctly. There's also another (I think unrelated) warning that gets emitted as well. I'm waiting to hear back from upstream about both. I'm not going to package the recently released 4.0 DHCP until I've figured out a transition plan to go from the old DHCP v2 packages to the v3 ones.

Neil:

The vast majority of your criticisms are unfounded. Nvidia contribute code to the open driver for their network hardware (see the commits) - you don't mention what version of Debian you're actually running, but if it's etch then it's hardly surprising that new hardware isn't supported terribly well. Try a more recent kernel. It's not clear what you expect HP to have done here - used older hardware to make sure Debian worked?

"the graphics don't work with standard Debian kernels and the standard Debian 'nv' driver" - this seems fairer. No 7000-series IDs have been added to the nv driver for some time, and 7150 is clearly missing. Naughty nvidia. No biscuit. But, again, hard to see what you wanted HP to do here - you bought a machine with an nvidia graphics chipset, and you're surprised that the open support is poor?

"I'll still need some firmware for the bcm43xx wireless card - and it is that firmware that made my previously ultra-reliable iBook into a flaky, power hungry psycho-beast." - no. Given that the firmware runs fine on non-Linux platforms, it's pretty clear that it's the (entirely open) driver that's at fault. Which is hardly surprising, given that it's had to be reverse engineered due to Broadcom providing no specifications whatsoever, but blaming vendors for using proprietary firmware is a bit much. Do you have the source for your CPU microcode? Your BIOS? The firmware that's in flash on your other wireless cards? Your hard drive? As a community, we haven't been sending a strong message to vendors that we want open firmware. Acting shocked that they then don't provide it is alarmingly unreasonable.

"GNOME doesn't yet work because of the proprietary crap" - the only proprietary crap you need is the graphics driver, and it's unlikely (though possible) that it's breaking GNOME. Perhaps you have another bug?

"I didn't think companies were still producing crap of this pitiful standard - HP: you stink" - this might at some level be linked to the fact that you paid 500 pounds, and as a result you got something made from cheap parts. That's not HP's fault. Their consumer hardware isn't designed to work with Linux. It's hardware that's designed to be as cheap and shiny as possible in order to appeal to home users who are then going to use it to download films and porn and animated mouse cursors in order to ensure that all their private data get sent to Russia. If it's supported by Linux then that's a happy coincidence. If not, then who cares?

Never mind. It's likely that your laptop is one of the machines that has some debugging hardware on io port 0x80, and as a result Linux's use of that as a delay port (despite the hardware's acpi tables claiming it as a motherboard resource) is likely to cause the machine to deadlock randomly if you do things like try to read the hardware clock or nvram. That's likely to cause you more problems than HP's use of Nvidia graphics.

What a disaster!
HP and NVidia making laptops unusable
I've been considering a new laptop for weeks - mainly to get more RAM, more space but without adding to the actual size of the machine (or weight). I know, I should have taken more time over the selection, I should have found out more about the hardware, etc.etc.
I've ended up with an HP Pavilion dv6000 (dv6615ea) for the 2Gb RAM, 15inch screen, 250Gb hard drive to replace my ageing iBook 12inch with 128Mb RAM and 30Gb hard drive - all for barely an inch extra depth and very similar weight (and it was cheaper than the original price of the iBook). I thought I'd made a good choice. Yes, it was "NVidia Graphics" according to the sticker and yes, I could have spent more time (and money) finding a pre-installed lappy but I was hasty. (Much the same way as you should never go food shopping whilst hungry). I've managed with NVidia graphics before without using the horrid proprietary rubbish and I was prepared to put up with less-than-perfect graphics (I never use 3D anyway) because the free driver is at least stable with the graphics that I actually need.
What I wasn't expecting was that the dv6615ea has a lot more NVidia stuff than just the graphics card - including the network card! This really trashes a normal install because eth0 simply does not exist. OK, I can work around that for a while but there's more - the graphics don't work with standard Debian kernels and the standard Debian 'nv' driver. Ubuntu managed some graphics with the restricted NV support but only in VESA-safe-mode. Next stop was Mepis.
Don't buy a HP Pavilion dv6000 (dv6615ea)!
Just to see if the graphics would work at all, I tried it. Aha - the non-free changes to the Mepis kernel solved both problems so at least I now have a working ethernet card and a working graphics card. That at least allows me to finish the rest of the setup to find a better way of getting the graphics to work without the non-free kernel.
I'm not happy though - I'm annoyed with myself that I got suckered into a non-free-only lappy. I'm annoyed with NVidia for being stupid about Linux support. I'm annoyed that this new lappy is just going to end up MORE unstable than my existing one because of all the proprietary crap. (I'll still need some firmware for the bcm43xx wireless card - and it is that firmware that made my previously ultra-reliable iBook into a flaky, power hungry psycho-beast.)
Currently, I'm still migrating this horrid little piece of rubbish from Mepis to Ubuntu (Hardy from Breezy) then from Hardy to Debian unstable.
GNOME doesn't yet work because of the proprietary crap but the Mepis GNOME packages are also v.old so I'm hoping that a genuine Sid installation of GNOME can actually start up but I suspect that the Mepis patches are KDE-specific and I hate KDE.
I've just wasted 500 and that's why I'm really annoyed.
I've wasted a day and a half too, making things worse.
I'm probably going to have to leave this new lappy behind and take my existing iBook to Fosdem in a few weeks and that makes me even more annoyed. Even worse, this is an amd64 machine but I'm stuck with a 32bit installation because of the proprietary crap. I doubt I'll be able to trust any packages built on this laptop - or even be able to report bugs from this machine without first replicating the bug on a genuine Debian box. There is just SO much proprietary pollution in this piece of crap. I didn't think companies were still producing crap of this pitiful standard - HP: you stink.
I'm not a happy bunny. Not even slightly.

On a lighter note - it just goes to show how I've been isolated from all this stuff until now. My other machines are fine and have no need for any non-free stuff. Nice that I don't have to deal with this every day but such a shock to the system when I'm confronted with such horrors.

I arrived back late last night from DC (National Airport, called “Reagan” by some) to Logan Airport. I got to National about an hour before my departure and checked two bags. Only one of them appeared at the baggage claim on the other end. The U.S. Air baggage people were surprised; they said National rarely loses or delays bags, especially where the passenger checks in with reasonable lead time. My second bag finally arrived this afternoon. I found the solution to the mysterious delay within: a Transportation Security Administration “Notice of Baggage Inspection.” Presumably they held my bag for too long or it just didn’t get routed properly after being manually inspected. I don’t believe the random manual inspections provide much improvement over the full CT scans now mandated at all airports. But apparently they do create inconveniences. On another note, I noticed for the first time this trip that the now obsolete “no smoking” signs above every seat have been replaced with “turn off electronic devices.” (Query which is more addictive.) Technorati Tags: TSA

Share This

Bits from the Debian i18n meeting (Extremadura 2007)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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