Tag Archives: Debian

Debian “drops” the Linux Standard Base

Posted on by
2

LWN recently reported on a decision by the Debian community to drop most support for the Linux Standard Base (LSB). The LSB is an attempt to define as standard for compatibility across Linux distributions. Even binaries should JustWork™ on multiple distributions. At work, I take advantage of this: for many packages we use the same binaries across CentOS, Ubuntu, and SLES.

I can’t blame the Debian maintainers for not wanting to continue putting in the effort. The LSB is a large standard set and very few applications have been officially LSB certified. In addition, the LSB’s selection of RPM as the package manager puts the spec at odds with Debian anyway.

Debian’s unwillingness to put effort into keeping up with the LSB doesn’t necessarily mean that it will suddenly become incompatible with other distributions. Debian plans to continue complying with the Filesystem Hierarchy Standard, a subset of the LSB that defines what files and directories go where. I suspect this is the key standard for many people who work across distributions anyway.

In the short term, this seems like a non-story. In the longer term, I wonder what will become of the Linux ecosystem. Running a single distribution is herding cats on the best of days. Coordinating standards across multiple distributions, even with common upstreams, is madness. Among the major distributions, there are basically two camps: Debian/Ubuntu and Fedora/RHEL (and RHEL-alikes). They’ve managed not to drift too far apart, thought I thought systemd would start that process.

To many, “Linux” (as an OS, not a kernel) is a single entity. Others don’t even realize that Ubuntu and Fedora are in any way related. While reality is (sort of) closer to the former currently, I wonder if we’ll get to a point where it’s closer to the latter. Standards are important but are useful only to the degree that they are complied with. Linux has avoided the competing standards problem so far, but will that remain the case?

Sometimes, Windows wins

Posted on by
4

It should be clear by now that I am an advocate of free software.  I’m not reflexively against closed software though, sometimes it’s the right tool for the job.  Use of Windows is not a reason for mockery.  In fact, I’ve found one situation where I like the way Windows works better.

As part of our efforts to use Condor for power saving, I thought it would be a great idea if we could calculate the power savings based on the actual power usage of the machines.  The plan was to have Cycle Server aggregate the time in hibernate state for each model and then multiply that by the power draw for the model.  Since Condor doesn’t note the hardware model, I needed to write a STARTD_CRON module to determine this.  The only limitations I had were that I couldn’t depend on root/administrator privileges or on particular software packages being installed. (The execute nodes are in departments across campus and mostly not under my control.)

Despite the lack of useful tools like grep, sed, and awk (there are equivalents for some of the taken-for-granted GNU tools, but they frankly aren’t very good), the plugin for Windows was very easy.  The systeminfo command gives all kinds of useful, parseable information about the system’s hardware and OS.  The only difficult part was chopping the blank spaces off the end of the output. I wanted to do this in Perl, but that’s not guaranteed to be installed on Windows machines, and I had some difficulty getting a standalone-compiled version working consistently.

On Linux, parsing the output is easy.  The hard part was getting the information at all.  dmidecode seems to be ubiquitous, but it requires root privileges to get any information.  I tried lshw, lshal, and the entire /proc tree.  /proc didn’t have the information I need, and the two commands were not necessarily a part of the “base” install.  The solution seemed to be to require the addition of a package (or bundling a binary for lshw in our Condor distribution).

Eventually, we decided that it was more effort than it was worth to come up with a reliable module.  While both platforms had problems, Linux was definitely the more difficult.  It’s a somewhat rare condition, but there are times when Windows wins.

The first few weeks with the N900, part 2

Posted on by
Reply

This is part 2 of my review of the N900.  Part 1 includes “Unboxing”, “The screen”, “Connectivity”, “Web browsing”, and “The camera and other multimedia goodness.”  Part 2 includes “E-mail, calendar, contacts, and instant messaging”, “Other applications”, and “The phone.” Continue reading →

The first few weeks with the N900, part 1

Posted on by
8

Three months to the day after I first wrote about the N900, Nokia’s newest smartphone ended up on my desk.  Since I’ve talked so much about it on Twitter (and since I had to lobby my wife aggressively to let me buy it), I think I owe the world my review.  I get the feeling that this review will end up focusing on a lot of the negatives, but don’t misunderstand me: I really like this phone.  The N900 is great phone with a lot of potential, but it is currently an early-adopter’s phone.  I’m generally not one to play the early adopter game, but this time around I couldn’t help myself. Continue reading →