Search Results: "will"

19 January 2008

Christian Perrier: Half goodbye, dselect

The dpkg maintenance team just changed the priority of the good old dselect from Important to Optional. Simultaneously, overrides were changed by FTP masters. As a consequence, dselect will no longer be installed by default when installing a "standard" Debian system. Thanks to the dpkg maintainers for the first move (Required->Important), as well as Joey Hess who suggested to downgrade from Important to Optional. Old timers, this is time for a little tear in memory of dselect..:-)...as well as a thought to people who wrote and maintained it (it is still in the archive and part of dpkg source package but noone really maintains it, now). Time to hunt a few more "Important" packages that should be downgraded.

Theodore Ts'o: Why I purchased the Sony PRS-505 Reader

Although I lot of people have been lauding the Kindle, I recently decided to go with the Sony PRS-505 instead. Yes, the Kindle has built-in EVDO access, and the ability to buy books without a computer, or even browse the web; and yes, the Sony has once again demonstrated it can’t create a compelling 21st century computer application to save its life. However, it had a few things that at least for me, made a better choice for me than the Kindle:
  1. The Sony is thinner — I want to be able to slip it into my laptop case and have it take the absolute minimum amount of space.
  2. The Sony simply looks much more elegant than the Kindle; steel with a leather cover simply looks a lot better than white, cheasy plastic.
  3. I’m not interested in buying a lot of DRM’ed ebooks; ergo, I won’t be buying may books from either Sony or Amazon’s web sites. It is highly likely that within 2 years I will be buying a more advanced eBook reader, possibly one with color, and I don’t want to be locked into a single format where I have to go and repurchase all of my books just because some the latest and greatest eBook reader uses an incompatible DRM technology from whatever Sony or Amazon has used.
  4. The Sony is $100 cheaper. Given that something better will be available within 2-3 years at the very most, and possibly sooner, I’m just not interested in spending $400 on a first generation prototype.
  5. Perhaps the most important, the Sony has the really, really good open source support. Kovid Goyal’s libprs500 project supports the Sony PRS-500 and PRS-505, and has very good version tools, allowing people to convert eBooks previously stored in HTML, PDF, TXT, Microsoft Reader (.lit), IDPF/Open eBook (.epub) into Sony’s format. And with a little bit of work, it does a very, very good job with the conversion. Better yet, its ability to convert multiple HTML pages into a single eBook, with credible table of contents, means that libprs500 can pull down the New York Times, the Economist, etc., automatically format it into a single eBook which you can save onto your Sony Reader, and then read it while you are on the airplane. No muss, no fuss. I can also take various books that are available on the web as HTML and also convert them into an eBook which can be used by the Sony Reader very easily.
This last point is I believe one of the best reasons why the Sony Reader will be able to compete very successfully with the Kindle. The libprs500 software is written as a python application, and it will work on Windows, Linux, and MacOS — and its GUI user interface is far better than the truly pathetic Sony Connect software. Score one for Open Source! In my opinion, Sony should send a very nice gift certificate to Kovid as a thank you; his open source project has added an immeasurable amount of value to their product. The only thing that you can’t do using the libprs500 software is buy DRM’ed books which are locked to the Sony Reader — but that isn’t something that many people will be particularly interested in, I suspect. OK, I did buy Pillars of the Earth, which was available on the Sony site for $6 dollars — hmm, cheaper than Amazon’s $9.99 — but that was an investment I was willing to flush down the toilet when the PRS-505 becomes obsolete, mainly so I could test what buying a DRM’ed book would be like from the Sony web site. But I probably won’t be buying many books with DRM that way. On the other hand, I am quite willing to spend quite a bit more money on non-DRM’ed books from publishes such as Baen Books. Here’s to the hope to the publishing industry figures things out faster than RIAA’s member companies. In the meantime, I will be mostly pretending that the both the Sony and Amazon eBook stores with their proprietary DRM’ed books don’t exist…

David Nusinow: On Visualizing Biological Data

The following is a brain dump of some of the things I've been thinking about lately.

One of the biggest changes over the past several years in biology has been the incredible deluge of information. In response to this there's been a rise in bioinformatics to cope with all this. While this has led to some major successes, where it's failed is in its ability to impart a greater understanding of the subject at hand. Biologists still learn primarily from reading papers, the same way we always have. There are massive databases full of wonderful information but most of it is encoded with minimal or no context so you're always forced to go back to the papers to understand what the database is actually telling you. In that sense, these databases are fantastic at indexing information, but very poor at organizing it in such a way as to teach people about the topic at hand. We're still forced to slog through papers for just about everything.

What's striking about this is that the most informative bits in any biological paper I've ever read are encapsulated in the figures. The images themselves, provided you have sufficient background knowledge, show the basic data and give you the most understanding for the smallest investment of time. You can skim an article's abstract, it's figures and figure legends and gain a fair understanding of the topic before deciding whether or not to go further.

Now, there's a contradiction of sorts here. Many of these figures are generated via computers, usually an excel-made graph. The rest are actual photographs of things, such as blots, gels, or stained tissues, eventually inserted and processed via the computer. The contradiction is that the computer is used intensively to organize this data for publication, but we have a hard time extracting the essence of that visualization for indexing in "big picture" sorts of ways. That almost always has to be done by hand (and brain) by the biologist. This, of course, is suboptimal when you have thousands of individual genes.

The fundamental reason for all of this is that biological information depends wholly on context. For example, you can sequence the whole genome, but it's totally unclear what genes will be expressed at any given time unless you have much more information about the cell type, developmental stage, pathologies, and so forth. As far as I can see, all our bioinformatics tools have failed completely at providing any sort of context for their information. A common thing to see is so-called "wiring diagrams" that display molecular interactions. These diagrams are full of nodes and edges and it looks almost impossible to understand such things. While there is a great deal of complexity, contextual information provides us with a framework to understand what's actually working. Looking at these diagrams, there's no sense of this though, it looks instead like complexity overrun.

So that presents us with the challenge for the future. What's required of bioinformatics is to not only index the raw data, but also the context, and then present the data to us in a context-dependent manner. I am convinced that the key to presenting data this way is to come up with novel visualization methods because it's the visualizations in the papers that we use today to get the most out of our time. I believe that this problem is tractable and that there is a solution. More than likely we'll need several solutions, and I look forward to seeing them develop.

Neil Williams: Debian Lenny on amd64 HP Pavilion dv6000 (dv6615ea)

Working!
I've decided to replace the previous post rather than leave it in place when there is a solution available.
Fixing the problem
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.
Updated
The ethernet card is not recognised by the Debian Etch installer - after a comment placed on this blog after my original post, I tried the Lenny installer for amd64 with signficant success. Selecting the vesa driver for the graphics provided a usable X setup (1024x768). I've still spent a lot more time on this than it should really have required but I do now have a genuine amd64 Debian installation with GNOME. The only thing not working is wireless (oh and sound). The wireless appears to be a bcm43xx issue - the driver appears to let the card work (the orange light turns blue) and the device is created but scanning fails.
I'm probably still going to have to leave this new lappy behind and take my existing iBook to Fosdem in a few weeks, but I'm now happier with HP in general.
I'll try to post a longer review somewhere soon.
So, thanks for the tip, Julian!

Neil Williams: Blaming HP for a laptop problem

The problems are now fixed, thanks to a tip from Julian.
See Debian Lenny on amd64 HP Pavilion dv6000 (dv6615ea).
Julian notes that HP do make some friendly laptops. Thing is, I'm not looking for a "business laptop" - neither are many potential GNU/Linux users. I took the chance to persuade the sales assistant about Debian and all things free software - URL's, etc., then the laptop demonstrated the size of the gap that we still need to cover - that needs a change of heart at NVidia.
I had already found that Wiki page but that refers to the dv6116eu as opposed to the dv6615ea - a small difference but these things can mean big differences in how the chipsets are actually implemented.
Matthew - I tried to install an amd64 etch installer (4.0r2), i386 etch installer (4.0) and I tried upgrading to Debian sid once I did have a working implementation via Mepis. I wasn't at all surprised that the graphics were going to be a problem - my surprise is reserved for the parts of a laptop that I tend to assume are no longer proprietary, like ethernet. Guess I was wrong.
The bcm43xx driver problem is a Broadcom issue - it is hardly suprising that the free software driver has problems when there is no spec. What is more annoying is that the wireless device does not show up anywhere in the logs, even with Mepis, with or without the bcm driver + firmware.
GNOME does need more than the expected graphics problems - without the proprietary drivers the trackpad is also non-functional, the Mepis patches for X mean that the Gnome libraries don't load and updating the X packages means that X itself fails.
I may have been "frank" in my assessment of the laptop but that was simply down to the frustration. I don't have time to faff around with this kind of hassle.
I really don't mind having problems with the NVidia graphics - what annoys me is that the lack of any kind of ethernet support and the sheer number of fixes and hacks that Mepis have to use to get something out of the laptop.
Each time I tried to move to an updated Debian package of a mepis version, something else proprietary broke and I really can't use KDE long term. I also wanted to be able to use this in 64bit but the (non-graphics) proprietary stuff just doesn't allow that.
Not everyone has the option of only buying expensive business laptops or those that are known to work and not everyone has the time to spend working out how to fix these problems. (I used to but I wanted something that required less downtime.)

Christian Perrier: How many known human languages are there?

Tricky question, isn't it? Indeed, according to the ISO 639-3 standard which finally became an official ISO standard in 2007, there are 7696 different languages, including extinct, ancient, historic, and constructed languages. Of course, this may become a very debated discussion about what constitues a "language". Let's give the guidelines used by SIL International, who was designated by ISO as the official maintenance agency for ISo-639: There is no one definition of "language" that is agreed upon by all and appropriate for all purposes. As a result, there can be disagreement, even among speakers or linguistic experts, as to whether two varieties represent dialects of a single language or two distinct languages. For this part of ISO 639, judgments regarding when two varieties are considered to be the same or different languages are based on a number of factors, including linguistic similarity, intelligibility, a common literature, the views of speakers concerning the relationship between language and identity, and other factors. The following basic criteria are followed: So, we (iso-codes package maintainers) now have to update that part of our package and buy a big bunch of aspirin to people who will work on translating this. Moreover, contrary to all other such standards (3166 for country names, old 639-2 for languages, 15924 for language script names), there is no bloody official *French* version, so even the French translator has to work. Gues who this was until now? :-) To end this blog entry, let's ask a funny question to the readers (no, comments not allowed on my blog, I'm lazy, so answers by mail or in your blogs): what is the country in the world which as the highest number of languages listed in ISO 639-3?

Brice Goglin: Debian X.org notes - No, DisplaySize and DPI are not (always) broken

We are getting many bugs about wrong DPI configuration and DisplaySize not working. In most of the cases, it is actually caused by a confusion between Monitor sections in xorg.conf and RandR 1.2 outputs. With a default config, RandR 1.2 drivers will basically associate the unique Monitor section with their first output, even if not enabled. Bug #461501 is a good example of this issue. RandR 1.2 drivers (intel, ati, nv for G80, mga in experimental, radeonhd so far) require that you specify which output is attached to which monitor. If you have a Monitor section with identifier "Foo" connected on output "BAR", then you want the following in your Device section:
    Option "Monitor-BAR" "Foo"
Or (easier), just rename identifier "Foo" into "BAR". You need to add such a section for each output that you want to tweak (DisplaySize, ModeLine, PreferredMode). Then your tweaks will be applied to the right monitor/output. See the HowToRandR12 sections III.1 and III.3 for details.
(Permanent link) 

18 January 2008

Riccardo Setti: N81O

Finally today i received my n810. thank  you nokia fo giving me this chance. i will write a complete review tonight. this post has been written with the n810 of course...

17 January 2008

Christian Perrier: Solutions Linux 2008

The traditional gathering of the Linux and FLOSS community in France will this year again feature a Debian booth. The event will be held in Paris-La D fense (CNIT), on Jan 29-31. As the Babelbox was born in that event three years ago, we will again have one, of course (people will get bored of it...). Frans Pop improved the thing so much that it took me less than 2 hours to set one up. We will also probably have a few other demo machines and the usual bunch of developers, contributors and friends popping up at the booth. If you're around, please come up and say "hi"....(don't forget fingerprints, IDs and some aspirin to cope with the verbiage of some of us who definitely talk too much).

Michal Čihař: Toshiba ACPI keys, HAL and friends

Long time ago I used FnFX to handle events from ACPI keys on my Toshiba notebook. However when reinstalling notebook because of disk crash, I thought there must be a cleaner way to handle these and I found patch for acpid which added handling of these special events. However I really didn't like patching acpid on every update and there didn't seem to be chance to merge it upstream, so I started to look for better solution. After another amount of googling, I found that HAL already has some support for Toshiba hotkeys. Unfortunately it is now disabled in Debian because most key did not emit anything using HAL. Okay, let's fix the HAL, maybe it will get later enabled. Converting FnFX keymap to C code was quite easy and I made a patch for HAL to add support for all keys. Hopefully it get merged soon and I can then file bug on Debian package to reenable Toshiba support in HAL. Meanwhile I'd like to find some generic way of configuring what happens on these events. For now I hacked simple Python script which listens to DBUS events and invokes appropriate commands for keys, but I hope that some such tool already exists and I just missed it. If you know something, please let me know at michal@cihar.com.

Ingo Juergensmann: SA Basics

As there are some threads on the lists of enhancing Debian from time to time in various aspects and the upcoming DPL election period in some weeks, I found some memorable quotes in the book I'm reading at the moment:

Note: SA = System Administrator

The number-one attitude problem among SAs is a blatant disrespect for the people whom they are hired to serve. It is surprising how often we remind SAs that their users are not "lusers" or "pests with requests." They are the reasons why SAs have jobs. SAs are there to serve but, more important, to advocate for these people. [...]
We advocate that SAs stop using the termin users and replace it with the term customers. This becomes a reminder that SAs are in a service industry, supporting the needs of these people instead of "pests" who make request all day.

(From: The Practice of Network and System Administration, Limoncelli, Hogan, Chalup, Second Edition, page 756)


Communication:

  • I will communicate with management, users, and colleagues about computer matters of mutual interest.

  • I will strive to listen to and understand the needs of all parties.


(From: The System Administrator's Code of Ethics in The Practice of Network and System Administration, Limoncelli, Hogan, Chalup, Second Edition, page 325)

SAs do many tasks, but often, customers see only the parts that involve responding to their requests, not all the back-office work, and shouldn't have to see it. Therefore, how well you respond to customer requests is critical to maintaining an organizations reputation.

(From: The Practice of Network and System Administration, Limoncelli, Hogan, Chalup, Second Edition, page 364)

I don't know whether someone read this book as well lately or received another a proper christmas gift, but apparently someone found the time, finally, to fix the access to incoming.d.o for m68k buildds.

Thanks for giving access back! Yay! :-)


John Goerzen: DjVu: Almost Awesome

Earlier today, I started reading about the DjVu family of document formats. It really sounds slick: file sizes much smaller than PNG (and incredibly smaller than TIFF or PDF) for lossless data with the DjVuText format, file sizes much smaller than JPEG with equivalent quality for the DjVuPhoto format, and an advanced DjVuDocument format that separates the background photo from the foreground text and produces a quite nice output. There are wonderful plugins for browsers on all platforms, and server-side support already in Debian for sending pages incrementally as needed by clients.

I tried this out a bit and indeed it looks great on monochrome scans, and I made a quick try of DjVuPhoto as well. That part looks great.

So here's the bad news.

Debian has no nice way to generate DjVuDocument files. There is a PS/PDF-to-DjVu converter that uses a djvu driver for Ghostscript. But Debian does not include that driver. Though, strangely, the program that depends on this driver is actually in Debian main. (Bug filed.) That program actually will make background-separated images, but only if they are separate objects in the input.

All Debian has is a program csepdjvu, which requires you to somehow manually separate the foreground and background images. Ugh.

So there is no way using software in Debian to produce DjVuDocument files with automatic separation, either from scans or from a digital source. It appears that there may not be Free Software to do this from scans either. This fact is not made clear at all in the DjVu documentation that is around.

Francesco P. Lovergine: Vlogger with a named pipe

In an old post I dealt with the nice mod_chroot module to secure your multisite server. I also adopted recently vlogger in order to manage better apache logs for virtual hosts, when you have dozens or hundreds of them. Unfortunately the suggested way to use it (a simple piped command) does not work nicely with mod_chroot, because the piped command has to run in the chroot jail.

Of course, it is not a good idea installing the whole perl intepreter and all required modules in a minimized jail, so I adopted an oldish classic trick (the old things are always the best) to solve the issue: using a named pipe. You basically need to do something like the following:

mkfifo -m 600 /var/run/apache2/logger && chown www-logs /var/run/apache2/logger

cat /var/run/apache2/logger /usr/sbin/vlogger -u www-logs -g nogroup -s access.log /var/log/vlogger >/dev/null 2>&1 &

/etc/init.d/apache2 start


Of course your log directives will be something like:

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"% Referer i\" \"% User-Agent i\"" vcombined
CustomLog "/var/run/apache2/logger" vcombined

You absolutely need to run the reader before the writer, else the init script would hang for ever. It is easy adding a simple init script to run vlogger before apache and it has also the big advantage of not requiring re-fork a perl intepreter at every damn log action. Piping rocks.

16 January 2008

Michal Čihař: One year under my reign

One year ago, I took over Gammu maintenance. I think it time to summarize a bit what happened during that year. There were definitely good and bad releases in that time (especially strictness introduced to SMS parser in 1.13.0 took quite a lot of releases to fix various bugs), but generally I things Gammu is moving in a good way. What I would definitely call positive: There are also some bad things: Some statistics of last year (based on Ohloh):
ValueDec 2006Dec 2007Difference
Code Lines90,540101,687+12%
Comment Lines9,20415,336+67%
Comment Ratio9.2%13.0%+30%
All these changes were made in approximate 1200 commits. I hope next year will not be worse :-).

Annabelle Tully: #debian-offtopic

As one of the females in #d-o might I add that this is not at all a sexist channel. Sure, like all friggen channels on IRC, and not to speak of the internet in general, there will be jokes, about men, women, monkeys, MacGyver and politicians. If you walk into a channel as a stranger and immediately draw conclusions because one
of the known peers of the channel utters a joke, and ramble about it, publically slandering that this person or channel is sexist, you really have no friggen business on the internet. Sorry, but you don’t.
Everyone is made fun of on irc, in #debian-offtopic it’s definitely “friendly insults” at that, and women are no exception to this. If you are too sensitive to handle this, again, you really have no business on irc. Please stop slandering and causing excessive drama because you cannot handle a fucking joke, for the love of god. I’ll say it again, #debian-offtopic or ANY debian channel I have ever been to (which according to my whois is a whole fuckload) has never ever hit me as sexist, and if you hang around enough to see some of the cool people around in them, maybe, just MAYBE you’ll see that these simple insults are JOKES and meant to be FUNNY and SARCASTIC. If you are unable to handle JOKES and SARCASM, get your ass off the internet and leave the rest of us “sexist” and ”blasphemist” freaks alone, PLEASE.

Lior Kaplan: Who moved my PEs (or why does pvmove sucks on linux) ?


Yesterday I wanted to extend an existing LVM VG with some central storage disks. In the process, I notice the VG is built upon local & external disk, which isn’t according to my standards. So I decided to extend the VG with the external disks, and then use pvmove command to move all the PE from the internal disk before reducing the VG. The problem is, that on RHEL 4.4, the pvmove command hangs during it’s work, never returns to the prompt, and locks all the other LVM commands. Seems that for little amounts of PEs the command works, but for 10G disks it hangs. As nothing else helped, I was forced to hard boot the server using to power button. Running the command in single user also doesn’t effect the result, although non other user/services are running. RHEL 4.4 has LVM2 version 2.02.06, RHEL 4.5 has version 2.02.21 and RHEL 4.6 has version 2.02.27. Reading upstream’s changelog seems there isn’t any change regarding pvmove, although it’s still worth testing if upgrade helps. Version 2.02.29 has “Refactor pvmove allocation code” in its changelog, but it will take time before this version will be officially available for RHEL (fedora 8 only has 2.02.28). Hoepfully it will solve the problem, as my HP-UX colleagues are laughing on my expense… And that I have to invest more time in mimicking pvmove work manually.

Anand Kumria: We're back. And, we won.

Actually I never went away, yes 22 months is a long time between blog entries, I just got distracted by travelling and working at AwayPhone. I'm still there and we are looking for one or two developers, principally in the US (Washington state) — but as a global company, not necessarily — so let us know (ASCII only, spell-checked, coherent English, etc.) if you are interested. I've been on (technically) holidays for the past few weeks, but I find myself awake, reviewing code at 02:45 (now 03:30) and trying to catch up on emails. I'm reminded of a friend of mine who always used to shout “RELAX!” whenever we went bar-hopping. I've been trying to apply that to a broader area of life than just bars but it appears that it just isn't how I'm wired to operate; for better or worse. That means, that whilst in Australia, I'm also rebuilding my mothers' IT infrastructure at her publishing company. I want it all to survive without any intervention for at least 2 years. So, I've been evaluating various pieces of kit. My conclusions:
NetGear
Switches, Modems (ADSL) and Wireless access points
Western Digital
Linux NAS boxes (they have Samba, rsync and SSH on pre-installed. I'd expect a firmware update from the makers to incorporate iSCSI and allow you to join a domain shortly).
HP
Desktops and Servers. Although I wish Bdale has some influence within HP and I did not have to taint the kernel of my servers. Seriously, it is because of that I re-do a price/functionality check everything time I go to purchase a machine. HP only just get it right.
Linksys / Cisco - snom
VoIP handsets. To be honest, this category is still being evaluated; but I'm leaning towards snom.
I realise everyone has probably been burnt but some of the vendors mentioned above but this is my experience of them. You'll notice nothing about laptops. I'm looking around for a decent vendor, I'll let you know if I find one. If you have been following along, you will notice that the Netgear ADSL modems (DM111P) runs Linux. The WD MyBook World Editions II's, run Linux (and I'd expect that they could be coaxed very easily into running generic Debian). The HP stuff (mostly) runs Linux. As does the Linksys and snom handsets. We won. Now, I've got to figure out how to setup Clonezilla so that the desktop Windows machines can be replaced when they fail. And I have less than 144 hours to do so. There is nothing like a deadline to concentrate your mind. P.S. I do have some half-finished entries for the intervening 22 months, I will clean them up and post them under their original dates in the next few weeks

Steve Kemp: Never made it as a wise man

Recently I bought a new desktop PC and rotated my existing machines around, leaving me with one spare. Last night I donated that PC to a local friend, (co-incidentally the same woman who had been out cat-sitter when I went to stay at Megan's parents for Christmas). I said "Its got Debian on it, that funny operating system that you used when you were looking after our kitten, remember?". She said "Linux ssems to be getting popular these days I might as well try it out". But seriously she used it. It had GNOME, it had firefox, she seemed happy. It isn't rocket science these days to point a technicalish user at a Debian Desktop and expect them to know what to do with it. The only minor complication was the lack of flash/java since it was etch/amd64 - but thats probably a plus with the amount of flash adverts! In other news I made a new release of asql last night. This now copes with both Apache's common and combined logformats by default. (Yet another tool of mine which is now being used at work, which motivated the change.) I've also started pushing commits to xen-tools last night, so there'll be a new release soon. Mostly I'm bored with that code though, it doesn't need significant updates to work any longer. All the interesting things have been done, so it's probably only a matter of time until I drift off. (To the extent that I've unsubscribed myself from xen-users & xen-devel mailing lists) Virtualisation is increasingly a commodity these days. If xen dies people probably won't care, there are enough other projects out there doing similar things. Being tied to one particular platform will probably come to be regarded as a mistake. (Talking of which I should try out this lguest thing; I just find it hard to be motivated...)

Mark Brown: dpkg symbol versioning

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

Russell Coker: Differences between Distribution Kernels

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.

Next.

Previous.