Adding Memtest to a Debian Install USB Drive and Menu

This is meant to work with a USB drive or other bootable media containing the boot.img.gz contents for the Debian Installer. You might be able to shoehorn it in other of the various ways to set up Debian installation media, but this is the simplest.

It’s actually very easy to add Memtest86+ to an existing drive with this setup.

  1. Copy the Memtest86+ kernel over (I named it memtest for simplicity):

    $ cp memtest86+-5.01.bin /media/user/usbdrive/memtest
  2. Add a new config (I used memtest.cfg) for Memtest86+:

    label memtest  
        menu label ^Memtest  
        kernel memtest  
  3. Include your config in the menu.cfg (I put mine at the bottom):

    include memtest.cfg

That’s it. Despite not coming with Memtest86+, it can be easily added to the menu and it works fine.

Some of the other installation media seem to be hostile to this small addition. They have locked partitions or do not have easily-amended menu configurations. That said, maybe Debian Installer will eventually include Memtest86+ by default.


Debian’s init Options

The Debian Project will choose a new default init system for its next major release (codename Jessie). The debate details (Debian Wiki: Debates: initsystem) include the following proposals:

  1. sysvinit (status quo)
  2. systemd
  3. upstart
  4. openrc
  5. One of the above for Linux, other(s) on non-Linux
  6. Multiple on Linux, at least one for every other kernel

The chief goal in switching? Bring modern boot functionality (speed and lower resource use). Others include lowering the bar for packaging and maintenance, and taking advantage of newer kernel features.

The matter of choosing an init system mainly deals with the amount of work and amount of benefit available. Unfortunately, some aspects of this debate must focus on other things.

The main contenders, systemd and upstart, both have at least one strike against them:

  • systemd looks technologically superior, but that superiority makes it a non-option for at least some non-Linux kernels (owing to using Linux-specific features), and support for other kernels would require much effort. It also takes a different approach to being pid 1, namely rolling in some functionality that has long been outside of init‘s domain.
  • upstart can be supported more readily, but similar if slightly less effort would be required for non-Linux. Worse, Ubuntu’s stewardship of upstart hampers it with the Canonical Contributor License Agreement problem.

A Contributor License Agreement basically states that by signing it, you grant rights of your contributions to the project maintainer. But the Canonical CLA goes a step beyond, in claiming for Canonical the right to relicense the contributions in a non-free manner.

In the Free/Open Source world that makes it as attractive as poison ivy. Also important, some who contribute as part of their work may actively be barred from participation. A company that sees benefit in open source will probably see hostility in their employee’s work being tied into a CLA of this sort (or any sort).

It all adds up to one difficult decision. The fact that both major contenders do not reduce Debian’s workload means the decision will boil down to technical merits. That makes systemd more likely.

What of non-Linux, then? openrc or sticking with sysvinit both seem plausible. Debian likely will not abandon their work with other kernels, so they will likely bite their tongues. Debian will put up with the extra work of dual systems for now. That will also mean that their Linux decision will remain a technical hybrid for the time being.

But not forever. Post-Jessie, I expect Debian will re-evaluate and hopefully find a more useful option to shed some of the extra weight they will take on in the short-term, whether that means configuration conversion tools, or something else.

The main reason that upstart seems unlikely, Ubuntu and Canonical never took the time to lead the way on non-Linux and while some Debian packages might have easier times adopting upstart configurations, the feature set of systemd seems to be a bit more powerful.


Slow JavaScript in My Browser?

Another short one for November. Firefox 9 beta is now out, and that means the awesome package manager for Iceweasel has already got it packaged for Debian Unstable. In reading up on what’s new in Firefox 9, people mentioned Type Inference being added to its JavaScript engine, bringing some nice performance gains.

That led me to want to see how fast my browser is these days. For that I hopped on to the Kraken benchmark and V8 benchmark (separately, of course, to prevent one from slowing the other). Then I became concerned.

My everyday browser and profile:

  • Kraken: 12008ms
  • V8: 1522

When I tried Kraken from Firefox Safe Mode, it actually got so bad that the imaging: gaussian-blur portion of the test was timing out. For the sake of consistency/thoroughness, I’ve repeated the benchmarks from Safe Mode:

  • Kraken: 59363ms
  • V8: 583

(Note that on the Kraken tests where it caused the ‘slow script’ dialog to pop up, I had to manually tell it not to issue the warning the first time, which means a score even worse than it would have been (humans are slow).)

[Edit: Mozilla Bugzilla: Bug 453642 shows that Just In Time (JIT) compilation of JavaScript is disabled in Firefox Safe Mode, which clears that up.]

As my local builds of Firefox are on version 11 (the current nightly), using one of them won’t give me the exact same code to test against, but it’s a start. I can also download a copy of the Firefox 9 beta as compiled by Mozilla, and run that, to give me another datapoint.

Why am I doing this? Because at this point, it’s not obviously a bug. It could be caused by some other problem with my system, and even if it is a bug in Iceweasel, the extra data can prove useful.


  • Iceweasel with my original profile:

    • Kraken: 12008ms
    • V8: 1522
  • My local build:

    • Kraken: 3612ms
    • V8: 5476
  • Official Firefox 9 beta:

    • Kraken: 3439ms
    • V8: 6324

So we know that there’s a problem. Now the question is whether it’s with the package itself or something else on my system.

Here I try Iceweasel with a fresh profile:

  • Kraken: 3711ms
  • V8: 5696

Okay. So now I know, no doubt, that it’s my profile. What’s disturbing is that the problem still showed itself in safe mode.

My first step in tracking down my profile’s problem will be to disable all add-ons:

  • Kraken: 3693ms
  • V8: 5691

Ouch. Still not sure why safe-mode would have degenerate behavior, but at least I can now do a binary search (disabling half the add-ons, and test, etc. until I narrow it to a single add-on) to find which add-on is causing my problem.

And the winner is… Firebug. Firebug is an excellent extensions that lets the user inspect the web they use every day, but to do that it has to have its hands in the pie of the web, which can slow things down. Let’s see what we can tweak about my current settings for Firebug to hopefully leave it enabled while getting acceptable performance.

And a search turns up Mozillazine Forums: TM and PM Performance Thread: Comment by phuzi0n:

Is Firebug killing javascript performance after TI landed for anyone else? I tried updating to the latest stable Firebug 1.8.2 and then to 1.9.0a1 but it still slows down v8 benchmark by ~4x and sunspider by ~2x. I made sure that Firebug’s javascript profiling is disabled (with Firebug profiling enabled v8 is ~10x slower).

So, the current vintage of Firebug has some issues with the changes to JavaScript. That’s unfortunate, but knowing is half the battle.

In retrospect, I should have tested with a fresh profile before worrying about other builds of Firefox, as it would have highlighted the source of the problem much faster, but I was thrown off by the really bad performance in safe-mode, which led me to believe it couldn’t be an add-on.

For the time being, I am going to keep Firebug on, but if I run into pages that seem slow, I can always turn it off.


Better Know a Package: clamz

So I figure it’s good to dig into things at random sometimes, to see what wisdom they will lay upon us.  It’s like when you were a kid and your parents were going to throw away some piece of broken technology (this was before eCycling, of course), they would let you pull it apart (with a hammer, if necessary, though you tried to stick to screwdrivers).  You got to see the guts.  Those little buttons were just proxies for the real buttons (be they plain switches or membranes or whatever).

But, that’s another topic for another day.  The first thing we need is a package to dig into.  That requires either inspiration or randomness, and since I don’t have one in mind, we’ll rely upon the latter.  So, open a shell and put the package manager and other tools to work to pick one.

For the first try, I’ll most restrictions to the search, but if it picks something small like a subpackage of a larger piece of software, I’ll use the main package. I don’t want virtual packages, non-free packages, or libraries to be chosen, so I will ignore them. Also, I only want packages that I’ve got installed, as there’s some chance I’ll have a little familiarity with them.


aptitude search '~i!~snon-free!~slib!~v'
  • ~i means “installed”
  • ! means “not”
  • ~s[expression] means “section contains [expression]”
  • ~v means “virtual packages”

And I got a list of packages back. A little over 1,200 packages (if I pipe the output (command | otherCommand) to wc -l, it counts the lines for me). And now I want to pick one of them, so I’ll rely on shuf to make my life easy. I’ll pipe the search to shuf -n1, which will shuffle the incoming lines and then output the number I’ve chosen, in this case a single line.


aptitude search '~i!~snon-free!~v!~slib' | shuf -n 1

And we get:

i   clamz                           - command-line program to download MP3's fro

Well, it gets cut off due to the terminal only being 80 characters wide. So now the investigation begins.

First, I open aptitude proper and type /^clamz$[enter] which searches for that exact name. It highlights the package in the listing:

Actions  Undo  Package  Resolver  Search  Options  Views  Help
C-T: Menu  ?: Help  q: Quit  u: Update  g: Download/Install/Remove Pkgs
aptitude 0.6.4
i     clamz                                                0.4-3      0.4-3     
p     clive                                                <none>     2.2.27-1
p     clive-utils                                          <none>     2.1.6-1
p     clzip                                                <none>     1.2-2
p     cmip5-cmor-tables                                    <none>     1.3.10-1
p     cmospwd                                              <none>     5.0+dfsg-2
p     codfis                                               <none>     0.4.7-1
p     collectd                                             <none>     4.10.1-2.1
p     collectd-core                                        <none>     4.10.1-2.1
p     collectd-dev                                         <none>     4.10.1-2.1
command-line program to download MP3's from Amazon
Clamz is intended to serve as a substitute for Amazon's official MP3           ▒
Downloader, which is not free software. Clamz can be used to download either   ▒
individual songs or complete albums that you have purchased from Amazon.       ▒
Homepage:                                      ▒

Now, I press [enter] to examine it. This shows the description again, but tells me the section, priority, maintainer, and so forth.

The interesting part begins with the Depends line:

  --\ Depends (4)                                                               
    --- libc6 (>= 2.3)
    --- libcurl3-gnutls (>= 7.16.2-1)
    --- libexpat1 (>= 1.95.8)
    --- libgcrypt11 (>= 1.4.6)
  --- Packages which depend on clamz (0)
  --\ Versions of clamz (1)
i    0.4-3

This gives us an overview of what the source is probably like. It depends on libc6, which means it’s at least partly written in C. It uses libcurl-gnutls, which is the library that supports the tool curl which downloads things over HTTP (ie, the dominant web protocol). In this case, it’s the version of curl with security support provided by GnuTLS which is the GNU Project‘s implementation of TLS, used to encrypt connections to websites and other Internet/network services.

That makes sense, as the description told us clamz downloads music from Amazon.

Indeed, I was overjoyed to find clamz as a substitute for the seldom-updated and clunky official tool provided by Amazon. It’s a great little tool, does one thing and does it well.

But let’s keep digging. What about libexpat and libgcrypt? I’m not familiar. The latter is almost definitely something to do with encryption, but we can simply select them in turn and read about them.

libexpat‘s information screen says:

i A  --\ libexpat1                                         2.0.1-7    2.0.1-7   
  Description: XML parsing C library - runtime library
    This package contains the runtime, shared library of expat, the C library
    for parsing XML. Expat is a stream-oriented parser in which an application
    registers handlers for things the parser might find in the XML document
    (like start tags).

I can also read the number of packages that depend on it (directly; indirectly would take some traversal): 292 packages.

And, libgcrypt‘s information screen says:

i    --\ libgcrypt11                                       1.5.0-3    1.5.0-3   
  Description: LGPL Crypto library - runtime library
    libgcrypt contains cryptographic functions.  Many important free ciphers,
    hash algorithms and public key signing algorithms have been implemented:
    Arcfour, Blowfish, CAST5, DES, AES, Twofish, Serpent, rfc2268 (rc2), SEED,
    Camellia, CRC, MD4, MD5, RIPE-MD160, SHA-1, SHA-256, SHA-512, Tiger,
    Whirlpool, DSA, DSA2, ElGamal, RSA, ECC.

So, libgcrypt is used for computing hashes and other cryptographic uses. Neat. How many packages directly depend on it? 278 packages.

Oh, for the record we’ll look at the direct dependent count for the other two libraries:

  • libc6 has 16,978 direct dependents
  • libcurl3-gnutls has 235 direct dependents

All of the libraries that clamz uses are well-used by a lot of other packages. That’s a good thing, as it means their code is highly tested and dependable. It also means that the author(s) of clamz didn’t have to write or maintain any of the code that they depend upon, so that saved them time to work on their own tool.

Now let’s dig a little bit more into clamz itself. To do this, I am going to grab the source that Debian ships (except for the non-free packages, all Debian packages have the source code available for reuse by you or anyone). So (as a regular user):

mkdir clamz
cd clamz
apt-get source clamz

And voila, the source has been downloaded and extracted into clamz/clamz-0.4 with all the necessaries for building it. Okay, not all. It’s possible that I don’t have the development copies of its dependents installed, in which case I would type (either with sudo or as a superuser) apt-get build-dep clamz to tell it I want to have all of the packages that I need to actually build clamz.

But apt-get source [package] does get the source and extract it in a manner that it’s ready to be built into a package. The Debian package parts happen in the [package]/debian folder.

clamz comes with five .c source files and one .h source header file. It also has a man page file, a desktop file, a xml file used for its MIME registration, and its compilation structure (configure files and makefile). And, there’s some folder called .pc which I have no clue about, so let’s look at it.

Ah, I immediately recognize the name quilt that prefixes several of the files, along with several others including the word patch. This folder is obviously there to contain patches to the original source and information about those patches. At present it only contains one patch, and the applied-patches file tells us that it is applied; it’s a patch (fix-clamz-desktop.patch/) that adds the desktop file I mentioned, which is used to add the file to the frontend of GNU/Linux systems, so that users can find it in menus or searches.

I think that’s as far as we go, for now anyway. I could explain the structure of the Debian-specific packaging a bit more, but it’s a simple (ie, good) package so there aren’t a lot of details there. The rules file only contains a command to install the man page.

In other editions of this (if I continue it), I will probably look at source a bit.

If you do use GNU/Linux, and you do download music from Amazon, you should at least consider using clamz. As seen here, the dependencies are a lot nicer than those of the official tool, and it’s definitely more UNIXy.


Free as in Culture.

Came across some ongoing debate regarding whether culture should be treated as software is.  That is, whether the licenses of culture can be equally free to those of software.  Thought I would write briefly on that subject.

Before continuing I will simply note my own guilt in licensing the contents of this blog.  Up until today I was using the Creative Commons 3.0 License with the Attribution and No Derivatives caveats.  Today I’m glad to relicense all of the works under the simpler, freer Attribution, Share Alike license.  This is much more in line with my general leaning toward the GPL.

Prehistory and History

In the time before writing, man did possess language.  While language has evolved further due to the intertext from written language, its core remains spoken.  And in that time before writing, culture was free.  If I told you a story, you would retell it in your own fashion.  You might or might not attribute the story to me, and I might or might not attribute it to its original author or influences.  But the central freedom to experience, modify, and redistribute the data was maintained.

Once writing came into play, the general pattern did continue.  Oral tradition became a bit more fixed (and in some cases the freedoms were lost due to lack of ability of more than the privileged to write and read), but even then rewriting occurred.  The new regime rewrote the old regime’s deeds, depending on their relationship.


One of the things that made the programming language LISP so powerful and notable was its treatment of data and code as equals.  With that ability in place, LISP informs this discussion.

If you see human language as a programming language for building memes, it becomes important to see that it’s a case where data and code are equals.  Otherwise, we might be stuck with a non-functional meme like, How come that bird we like to eat sometimes with the funny head and it lays eggs went all the way over that place people like to walk around on? instead of, Why did the chicken cross the road?

Why Culture is Free

Cultural freedom is essential because in order to be in a culture, one must participate.  Some cultures try to reduce that participation to being a member of an audience, but that is still participation.  The bystanders of the revolution are just as much involved as the victims, tyrants, soldiers, terrorists, police officers, attorneys, and so forth.

Recognizing that by reading this you are sharing a cultural experience, you automatically have some amount of shared ownership in that experience.


Ownership is a set of freedoms and restrictions over some given object.  In culture, most of those attributes are implicit.  If you attend a museum or a play, you implicitly have the right to experience your presence in that location.  You implicitly (explicitly in cases, by statute or contract (eg, ticketholder agreement)) may not take the artifacts with you or get on stage.

But you can tell people you were there, what it was like, what it cost you, etc.  And you own that experience.

As it Was

So the issue with culture that’s raised is the threat of someone taking a work and changing it in ways that misrepresent or otherwise diminish the original.  If I draw my own Mona Lisa then does that harm the original?  No.  Particularly not when I give attribution (“go see Leonardo’s version over there”).  Particularly not when I disclose the difference between the works.

That’s exactly among the requirements of the Creative Commons Adaptations section: that one must disclose that the work is not the original.

As You Wish

But that’s still my decision.  You might feel in some circumstances you want the work to get out there and don’t want anyone to make a buck on it or to change one iota (Ɩ, 0x0196).  Just as with software, that’s the creator’s right to decide.  That’s important, that free software and free culture never seek to coerce behaviors, only to provide the choices.

Think of the (Time When You Were) Children

When you were a kid, you hopefully had some pretty fun interactions with others.  They didn’t tell you that those experiences were restricted.  They didn’t say, “I own hide and seek,” or that you had to repeat their exact giggle when you splashed in puddles.

Some of the games even depended upon free culture, like the Lossy Encoding Game where you sat in a circle and whispered what you heard to the next person.

No one got mad when the lossiest encoding was something that was almost, but not quite, entirely unlike the original.  It was fun.  And no one really believed the first person had said that last phrase, either.  And everyone had their own set of phrases, the heard and the spoken, and they all differed from the initial and the final.