The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Tag: debian

Adding Memtest to a Debian Install USB Drive and Menu

Posted in linux by Adam
Posted on

I wanted to add Memtest86+ to my debian installer thumb drive, so I am documenting how.

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

Posted in linux by Adam
Posted on

A look at the choice that Debian faces in choosing a new init system and process.

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?

Posted in linux by Adam
Posted on

I look at a case of finding bad performance in ECMAScript/Javascript benchmarks, leading to a hunt for what’s wrong with 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.

So:

  • 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.