Hell Labs

Old stuff not announced before: these are a couple of small and simple GTK+ tray applications to help hobbyists installing alternative operating systems in the Eeepc and similar netbooks to show capslock or numlock status (in case the hardware lacks the appropriate LEDs) or to logout or shutdown from GUI if you’re running finit with a light desktop environment. Get the code from the git repository with git clone http://helllabs.org/git/tray.git. (You may also be interested in Metalshark’s kbdstatus, which a Xlib-based version of the original Eeepc keyboardstatus application.)

You’ll need to supply a shutdown helper script and allow it to send signals to the init process if executed from the console (registering it with pam_console, for example). The applications are GPLed, so please consider contributing back your enhancements, fixes and changes.

The traditional method of dealing with filesystem images is to mount them as loopback devices, and that is a simple, elegant and universal way to change its contents in any way you feel fit. It has the disadvantage, however, of requiring superuser privileges — which you may not have in every host you frequent, or you wisely don’t wish to grant to anyone using your machine to develop filesystem images. Christian Hohnstädt’s e2fsimage solves the problem allowing one to copy an entire subtree into a image file, but what if you want to extract, examine or manipulate arbitrary content?

(more…)

“What is nash-hotplug and why is it consuming 100% CPU?“, someone asked in a Xen-related message I found after experiencing similar problems booting Mandriva 2008.1 with finit in the Asus Eeepc. This situation seems to be especially common in different Linux distributions running as Xen guests and the usual advice is to just kill nash-plugin after the system boots. Instead of doing that ugly workaround, we decided to investigate and find out what’s happening. Whatever nash-hotplug is supposed to do, I can’t say it keeps running consuming 100% of your cpu because it’s a well-written program (notice the bizarre IPC protocol, how it tries to read from a descriptor after closing it and how easily it can get trapped in infinite loops). Use the following quick fix to avoid the problem.

• mkinitrd-6.0.34-nash-hotplug.patch

Die, nash, die.

Having read the (not so enthusiastic) reviews of the first Cloudbook users, it seems that most software-related complaints of early Cloudbookers revolve around screen resolution, wifi performance and slow boot. While I offer no ready-to-use solution for these problems, here are some pointers that could help hobbyists or desperate users:

• VIA video of course won’t run with IEGD, but the (somewhat ugly) VNC-based hack for the Eeepc could work. X compositing or RandR could work depending on 3D performance, availability of RandR 1.2 for VIA graphic chips and quality compromises, but both solutions require development (i.e. possible but not available yet).
• Wifi performance issues may be related to RTL8187 rate control not working properly (it always tries to use the highest possible bitrate reducing range dramatically). Using a recent Windows driver with ndiswrapper should solve most problems, or reducing the bitrate manually should increase range using the native driver.
• Faster boot can be achived using finit (a reimplementation of the Eeepc fastinit), but some customization to finit-alt will be necessary to boot Ubuntu.

On a side note, finit-alt worked quite well booting Mandriva 2008 with Enlightenment in the Dreambook IL1, another VIA-based mini-laptop (possibly booting even faster than the Eeepc because the Intel driver for Xorg takes a while to initialize).

While I was updating the fastinit reimplementation with Metalshark’s patches, rallying enthusiast and Eeepc owner Ednilson Miura pointed me to a discussion in EeeUser about increasing screen resolution of the Eeepc display, basically by scaling down a higher resolution desktop to the native 800×480 Eeepc display. We’ve seen different approaches to solve the low resolution problem, from the traditional viewport to a larger virtual desktop to real screen rescaling (Intel has a driver-based rescaler for its Classmate PC, and there are similar resampling technologies used in other manufacturers with Eeepc-similar offerings usually with quality ranging from barely readable to unreadable). The aforementioned discussion presents a somewhat novel approach: a VNC connection to the local host. I think we could get a similar effect with a more elegant and less resource-intensive solution: X compositing. It would also be one of the first non-frivolous utilities for desktop compositing, previously used almost only for eye-candy. RandR and driver-based rescaling approaches are also discussed below.

(more…)

There is a number of updates in the Eeepc fastinit reimplementation that you might be interested in:

• It works, as confirmed by Eeepc users that tested the program.
• Metalshark fixed a bug in the reimplementation that prevented it to load the shutdown splash screen.
• Kept finit.c as an accurate reimplementation of the original Eeepc fastinit, and spawned finit-mod.c as a modified/optimized version intended to be a drop-in replacement for fastinit. A third version, finit-alt.c, contains changes to allow alternative Linux distributions to boot in the Eeepc (currently supports Mandriva 2008).

Read on for details and results of booting Mandriva 2008 on a regular (non-Eeepc) laptop using finit-alt.

(more…)

Slow booting plagues most Linux distributions today, and while this is not a such big issue for systems that are booted once a year, it becomes an annoyance in laptops or other computers you initialize every day. Different solutions for this problem have been proposed, but booting of a typical Linux system today still takes too much time. It has been said that the Asus Eeepc boots remarkably faster than regular Linux distributions, thanks to its “fastinit” system initialization program. A quick analysis of its workings shows what it essentally does, and it’s quite obvious: start the user interface as fast as possible, and initialize the rest later. A more detailed analysis allowed us to rewrite it, and even find a couple of bugs in the original code.

(more…)