It is a good platform for experimenting with bare bones installations. I always wanted to set up an X-less machine and see how usable it would be. I already have a library of very useful CLI apps so really this should be a great experiment. I briefly messed around with a net install of Debian Etch but in the end I went right back to what I know and decided to give Hardy a whirl. It would be a nice test to see how the brand new system stacks up on very old hardware.

So I grabbed the mini ISO, and run it with the cli boot parameter. Why the mini iso? To make a long story short, I wasted 4 CD’s burning corrupted copies of the alternate install CD. What I wanted was a bare bones CLI system but every time I started installation some file was corrupted. I guess this will teach me to check the md5 checksums before burning next time. Either way, the minimal install ISO seemed like a good solution – weighing in at 8MB wouldn’t get corrupted during transfer.

Installation was uneventful, but tad long since a lot of packages needed to be downloaded. I ended up with a lean CLI system. Since I initially did not want to install X on it, the first thing I did was to update my tty resolution This is done by editing the grub menu like this:

sudo vim /boot/grub/menu.lst

You will see something like this:

title      Ubuntu, kernel 2.6.15-20-386
root      (hd0,4)
kernel    /boot/vmlinuz-2.6.15-20-386 root=/dev/hda5 ro
initrd    /boot/initrd.img-2.6.15-20-386
savedefault
boot

The Compaq can only handle 800×600 with 24 bit color at most, so I add the following to the kernel line:

vga=789

The like should look like this once you are done with it:

kernel    /boot/vmlinuz-2.6.15-20-386 root=/dev/hda5 ro vga=789

Now how does the 789 relates to my resolution? Good question! You can find other magical values you can add to that line listed on the Ubuntu FrameBuffer wiki.

Next ting was setting up the wifi connection which was not that difficult. I ended up with a fully functional CLI system. I could browse the web with w3m, use Midnight Commander as my file system browser and etc. Btw, this takes me way back:

I sat there staring at this screen reminiscing all the good times I had working with Norton Commander back in the day. Oh man! These were the good days. I vividly remember excitement involved in unpacking a pirated copy of Wolfenstein 3D and Alone in the Dark and running it from the Norton interface. Ah, these were the days. I was young, naive and was just discovering wonders of technology. Unfortunately, I seem to be the only person with fond memories of that time. When my brother saw the screen, he made a face and exclaimed: “man, I used to hate that thing”. But how can you hate the commander? I mean, it’s a fucking commander! It commands respect! Here is a better shot of the app itself running in 800×600 mode on the tty:

My cousin had a similar reaction. She pretty much said “You know, it’s 2008 – you can use Windows Explorer now”. :cry: No, thank you – I will stick with linux and my ultra light applications that hardly take up any memory and/or CPU power to run.

But I wanted a little bit more flexibility. Swapping between TTY’s all the time is not always the optimal solution. Sometimes I would for example want to split my screen into 2 or 4 panels with different content. Screen does that, but it does not do vertical splits out of the box. You can get that functionality by applying a patch and recompiling, but I decided to get something a tad more complex. So I turned to DVTM which is labeled as a tiling window manager for the CLI. It’s not in the repositories so you have to compile it yourself:

aptitude install make build-essential libncurses5-dev
wget http://www.brain-dump.org/projects/dvtm/dvtm-0.4.1.tar.gz
tar -xzf dvtm-0.4.1.tar.gz
cd dvtm-0.4.1/
make
sudo make install

The result is pretty neat. You can see me running a split panel session with htom (upper left), aptitude doing updates (upper right), and w3m (bottom):

DVTM has two major disadvantages. First is that you loose all the neat framebuffer features – for example like the images being displayed in w3m. No drawing or image viewing utilities will work in it – just like they don’t work in screen. Seconly, DVTM is not very configurable. There is no dot file (like .dvtmrc or something) that you could use to customize settings, set default layout and etc. The author suggests changing the configuration in one of the .h files, and then recompiling the whole thing every time you want to change something. :( Not really what I want to do.

Finally I broke down, and decided that that running mimimal x configuration with Ratpoison is not much more taxing on the hardware. I still intended to use mostly CLI apps (since that’s really what Ratpoison is all about) but the possibility of actually being able to run some gui apps (such as Dillo or Kazekahese for example) was a nice touch. Installing ratpoison was easy:

aptitude install x-window-system-core ratpoison
aptitude install xserver-xorg-video-vesa xserver-xorg-input-mouse

I got a lot of scrolling text on my barebones install (over 30 MB of x related packages) but installation was swift and simple. But it was not perfect. If you follow these instructions you will notice that the display is bit “gritty” and pixelated under this setup. This bothered me a bit. Running lshw told me that this system actually has NeoMagic NM2160 MagicGraph 128XD card installed on board. Quick aptitude search told me that there is a package which caters to this brand of graphic devices. To get full use out of your card you will need to do:

aptitude install xserver-xorg-video-neomagic

After that, the image was crystal clear and sharp as ever.

Now my rig starts in cli mode, but and I can continue like that. If I need X for some reason I can start it manually, and it actually takes about 2 seconds to start up. Ratpoison is rather nifty – and not much different from dvtm, only it uses X and is completely configurable. Here is a screenshot of me running htom (upper right), Midnight Commander (upper left) and opera (bottom):

Here is something that I did not expect or anticipate: Opera actually outperforms Kazehekaese on this machine. It’s bizzare but true. I guess the geko engine was choking due to limited memory or something.

I might try another windowing manager like awesome at some point in the future because of the floating window feature. Ratpoison only knows how to tile windows which is fine but not really practical in the long run. As you can see on the screenshot above, the 3 way split is already kinda cluttered. Add 2-3 more panels, and you won’t be able to see anything on any of them. With mere 800×600 resolution, the screen estate on that thing is priceless.

Anyway, for those interested my .ratpoisonrc looks like this:

bind c exec rxvt -fn "Lucida Console-8"
bind b exec links2 -g
wrap off
escape Pause

exec xsetroot -solid black -cursor_name left_ptr
exec xli -onroot -fullscreen /home/luke/eva.jpg

Note that I remapped the escape key from Ctrl+T to Pause mainly because of the keyboard layout. On the laptop keyboard the Ctrl+T becomes a two hand salute due to the weird positioning of the keys. Pause on the other hand is strangely withing the reach of my right hand. Go figure.

One thing that did not work well under Ratpoison was Midnight Commander. Something about rxvt and mc not agreeing on the locale settings. It was easily resolved by adding the following line to my .basrc:

LANG=C

I’m also bound a key for links2 since it is really the faster, and more responsive browser on this machine. If needed I can always launch opera, but for quick lookups links2 is more than enough.

So there you have it – it’s a minimalistic system, which runs mainly CLI apps. It does have X but it does not need to be running. And when it does it uses ultra light window manager that is also stripped down for simplicity and performance. What do you think?

[tags]hardy, ubuntu hardy, midninght commander, dvtm, screen, ratpoison, opera, x, linux[/tags]

So I decided to go back to what I know and love – Ubuntu. Or rather Fluxbuntu (a *buntu with Fluxbox) as suggested by jambrama. While Fluxbuntu is only in beta, it is based on Dapper which is remarkably stable (not to mention that it is a LTS distro).

The installation went smoothly if you don’t count my CD burning issues. The Live distro was a bit sluggish, and the GTK based GUI install was very, very slow. Still, every live distro was slow on this machine. I think the CD-ROM is at most x4 or x8 so you can’t expect good read times from that. So I wasn’t that concerned.

One thing that Fluxbuntu people should probably fix is the lack of auto-login on the live distro. Once the thing boots you are presented with a login screen, and no idea what is the username and password. Quick trip to their wiki page will tell you that it is:

user = fluxbuntu
password = livecd

This is all fine, but if you don’t have internet connection, you are pretty much stuck at the login screen. Also, the live distro does not include an install icon on the desktop like it’s other *buntu sisters. To launch the installation script you need to pull up a terminal and type in:

ubiquity

I guess this is the name of the universal *buntu GUI install script, but perhaps symlinking it to something like install_ubuntu could have been a good idea. But I guess these are the joys of working with a beta system. As mentioned before, the install was slow. And when I say slow I mean Slowpoke slow:

With Slax and DSL the installs were quick because you had at most 100 MB of data to copy to the drive. Fluxbuntu takes up the full CD weighing in almost 700 MB which takes considerably longer to copy – expecially with a full desktop and a GUI installer running in the background and only 98 MB of RAM with no hd to swap. So slow is the operative word here.

While installation was nice and uneventful, the post installation tasks were what gave me a headache. My WPC54G v1.2 card worked on all other platforms – but fluxbuntu (which is Dapper based) refused to touch it. The ndiswrapper would take the driver without complaining, then I would generate modprobe alias as normal. Then I would run modprobe, and dmesg output gave me the following:

bcm43xx_microcode5.fw not available or load failed

WTF? The intefeace wlan0 doesn’t even show up on the radar. Nothing works. Time to do some reasearch!

After some googling, I found out that I might need to strip out the firmware drivers from the bcmwl5.sys windows driver file.

aptitude install bcm43xx-fwcutter
bcm43xx-fwcutter -w /lib/firmware/ ~/bcmwl5.sys

Then I unplugged the card, plugged it again, run modprobe as before and…

dick

Same error. Thanks internet, but you are no fucking help at all. I rebooted the machine, run the whole operation back again from scratch and got same exact result. Nothing.

Funny thing is that this same card is working perfectly in my other laptop which is also Dapper based. Actually my laptop is a Hoary which was dist-upgraded to Dapper because I’m awesome like that. I also remember having great old time getting my card working after the upgrade. But that was because my ndiswrapper-modules package was compiled from source and it apparently did not work with the newer ndiswrapper-utils. I fixed it by removing ndiswrapper and re-installing it from scratch.

This however was a whole different issue. So I hit google again, this time finding some very useful information. Apparently Dapper ships with the bcm43xx module of it’s own that interferes with ndiswrapper. The answer:

rmmod ndiswrapper
rmmod bcm43xx 
ndiswrapper -m
modprobe ndiswrapper

BOMSHAKALAKA! My wlan0 just got associated!

iwconfig wla0
ifup wlan0

I’m online kids! Me and Internet 1, Dapper 0. Wohoo! Me and Internet make a good team. Oh yeah! I conquered the machine once again. Ph34r the awesome power of the human intellect (and the ocean of information diarrhea and monkey piss that is the internet).

You just need to remember to add the following line to your /etc/modprobe.d/blacklists to prevent the bcm43xx driver from loading at startup:

blacklist bcm43xx

If you omit this step, the system will load the driver next time you boot, rendering ndiswrapper useless once again, and forcing you to repeat the rmmod and modprobe steps once again. Once you do this, it’s smooth sailing.

So, Fluxbuntu is working. The base system is running at an acceptable speed. I think both Slax and DSL were performing better. This system just feels slower and more cumbersome. I trimmed it down using sysv-rc-conf and removed all the unnecessary daemons and background processes. This made boot times more tolerable, and made the UI a wee bit more responsive. I’m not sure if I can tweak it down from here, but suggestions are always appreciated. I guess the rest is just choice of software you use on the machine.

The default terminal on Fluxbuntu is Eterm. It is a very pretty and lightweight terminal, with nice scrollbars, it’s own menus and nice backgrounds. It has one drawback though – on my machine it is deadly slow to startup. I don’t know about you but if I can count up to 5 or 6 Mississippi’s before the window even shows up, it’s bad. I need a terminal that is a little bit snappier than this. Fortunately Martin Ankerl did all the legwork for me, and conducted a very extensive Linux terminal speed benchmark. Armed with that document, I found the best match for me: Wterm which combines good startup speeds, with acceptable output rendering. And yes – Wterm actually beats the good old xterm. I’m really happy with it so far. It pops up almost instantly!

Rox is also very swift as the file manager. I might look for another alternative later on, but so far it is working fine for me. Kazehakase is a whole other story. It is slower than slow. And when I mean slow, I mean Slowpoke Rodriguez slow:

But, here is the thing: this is a 200 MHz machine with 98 MB of RAM and Kazehakase is a gecko based browser. Gecko is a modern rendering engine which eats memory for breakfast, shits all over your swap file, and then wipes itself with your CPU cashe. I don’t think I can make it any faster. In fact, I doubt that there is a modern, full featured browser that can run fast on this hardware. There is always Dillo, but browsing the web with it is bit tedious (OMG, where are my tabz?). Not to mention that you get the retarded version of the web since Dillo is worse than IE at properly rendering CSS.

So if you want speed, you use Dillo and deal with the weird web. If you want functionality, you use Kazehakase and go get some coffee while it starts, and every time you load a bigger page.

All in all, I think this system is acceptable. It is slower than I hoped for, but it’s also fully functional Dapper which means that any packages that I might ever want are there for me to use. This was not the case with Slax and DSL. I’m not sure how much more I can improve the performance. I’m sure that there are at least a few more speed tweaks I could do, but I’m not sure if they will help much. Of course Any suggestions on trimming it down are greatly appreciated. Let me know how do you butcher your *buntu to run fast and I will do it and report the findings. Btw, the stuff I will most likely be using this machine for is for testing, casual web browsing and email. Nothing serious. So anything that is not absolutely essential to web browsing can go.

[tags]fluxbuntu, WPC54G v1.2, ndiswrapper, bcm43xx, dapper, ubuntu dapper, wireless, wifi, wlan0, modprobe[/tags]

The system booted just fine, and I experienced had no problems with the video. I’m guessing this was a DSL issue rather than hardware problem. The only things that didn’t work out of the box were sound and wifi. I already knew how to fix wifi, and sound probably wouldn’t be that hard to set up either so I wasn’t worried.

Slax is a pocket distro just like DSL – the Popcorn ISO weighs only 115 MB. But while DSL does offer some accommodations for users wishing to install the system on the HD, Slax remains 100% live distro. What does it mean? It means that it offers no mechanism to convert the system to a semi-normal linux environment. You can of course copy the files to the HD to speed up boot times, and free up your CD by issuing following commands once the system boots:

mount /dev/cdrom
cd /mnt/hdc_cdrom
./make_disk.sh /dev/hda1

However every time you boot the system will return to it’s original state forgetting all your settings. You can permanently install software using the Slax modules but most of regular system settings have to be explicitly saved and restored at each boot. For example my ndiswrapper settings would dissapear between each boot so I would always have to copy the drivers from the USB stick into the home directory and do:

ndiswrapper -i ~/lsbcmnds.inf
ndiswrapper -m
modprobe ndiswrapper
echo ndiswrapper >> /etc/modules
iwconfig wlan0 
ifconfig wlan0 up
dhcpcd -d wlan0

What I really wanted was an actual full fledged linux install that would retain my settings without some special hax and tinkering. So Slax was not for me.

Before I trashed it I made some observations. Slax is a KDE based distro, and the Popcorn edition seems to be nothing more than a stripped down version of the original. It’s as if someone removed all the KDE packages out of the distro, and then slapped on Fluxbox, Firefox and Thunderbird on top of it.

I am a hard core Firefox user, but unfortunately this browser means death to old hardware. Popcorn did not ship with any alternatives. There is a Dillo module available but what I kinda really wanted was Kazehakase which has not been modularized yet. And building a gecko based browser on a system that is not persistent (ie looses information on reboot) is not my idea of fun.

So, Slax is out. That’s not to say it’s a bad distro. It is a very good lean Live desktop that I have successfully used in the past on older hardware. Not as old as this Presario though. It requires special attention.

So let’s summarize the developments in my search for a perfect old-hardware distro so far:

1. Deli Linux was disqualified because it lacked ndiswrapper that I needed for my wifi card
2. Arch Linux wouldn’t even boot complaining my CPU is to old for it’s kernel
3. DSL worked but it had odd video issues, and persistence problems
4. Slax with Fluxbox worked fine, but it was not designed to be a persistent installed distro (oh, and I never worked out the sound issues)

So I’m pretty much back to the drawing board. I was not 100% happy with any of the recommended “old hardware friendly” distributions. So, what now? Any suggestions?

I think I’m going to go back to what I know and love – Ubuntu. I’ll start with the “Text Only” install that can be run from the Alternate Install disk. Then I will slowly build it up from there, install X server, fluxbox, Kazehakase, Dillo whatever else seems a good idea. Since this will be a Feisty install, I should have a plethora of good packages to choose from.

[tags]compaq presario 1240, compaq, presario, old hardware, dsl, arch, slax, slax popcorn, dillo, fluxbox, kde, ubuntu[/tags]

The machine had only 98 MB of RAM, and a crappy on-board video card. In fact, it was all kinds of funky. For example, check out the weird Targus power adapter that came with it. I have no clue if this was the original AC adapter that shipped with the laptop, or if this was bought at a later time as a replacement. I know one thing though – this thing is so big it basically takes over every wall plug or power strip you plug it into for itself:

When I got it it had Windows XP installed, and essentially it took about an hour to boot. I tried installing Windows 2000 on it but it was still sluggish. The system was barely crawling even after I set it up to use bblean as the default shell.

The only way to actually make it usable was to either install Windows 98 (not a good idea) or some minimalistic Linux account. The machine was ancient so I basically limited myself to the distros that claim to be fast, lean and optimized for old hardware:

1. Damn Small Linux – the 50MB live distro that can be installed on the HD
2. Deli Linux – specifically built to run on antique hardware
3. Puppy Linux – another minimalistic distro recommended by K. Mandla
4. Arch Linux – also recommended, but bit more hefty in size than the other 3 pocket distros.

After doing some digging, I noticed that Deli ships without the ndiswrapper package which I needed to make my WPC54G v1.2 working. This is the same card I use on my Ubuntu rig, so I knew it would work as long as I had something that would wrap around the windows driver. So Deli, while very promising was out the window.

Since I wasn’t sure if my hardware will handle Arch will handle arch, I was torn between Puppy and DSL. I picked the later, because I had more experience with it and I could verify that the 4.0rc3 version definitely had a recent release of ndiswrapper on it.

Booting DSL posed some problems on the hardware. DSL ships with two tiny X server modes: Xvesa and Xfbdev. The default one is Xvesa which gives you access to the higher resolution modes. I set it into 800×600 (which is the lowest possible resolution in Xvesa) but no matter how many times I tried, I could not get it working. The desktop would show up, but the colors were messed up, and the image was distorted and pixelated. Ramping down color depth and resolution did not help – below 16 bit certain threshold I just couldn’t tell if it the color distortions were caused by my settings or if I still was having problems.

Xfbdev did work, and booted into a usable desktop – or rather one that you could actually look at without getting seizures or eye strain. But the resolution was still somewhat wrong – the whole bottom of the screen was cut off making the taskbar and the pager invisible. When I killed X I noticed that this was also the case for the TTY – I could not see what I was typing most of the time. The only way to get DSL to conform to my display geomentry was to run DSL in frame-buffer mode with the cheatcode fb800x600, and then pick Xfbdev as the X server. It doesn’t look very pretty, but it works.

Is this an issue with my video hardware, or is this a DSL thing? I’m guessing it’s the combination of the two. Neither Xvesa nor Xfbdev really talk to the video hardware. Xvesa uses standard BIOS VGA video modes and Xfbdev draws directly in the frame buffer. So I’m guessing that whatever Xvesa is doing is not directly supported in the POS video card that is installed on this machine. Perhaps a full X server that actually attempts to talk to the hardware would fare better here?

The installation to hard drive went smoothly. It was actually very fast, since the whole distro is only 50 MB. You literally run it, go make yourself a cup of coffee and before you come back it is long done, and asking to confirm a reboot.

Before I started I partitioned the drive with cfdisk creating a 128 swap partition as /dev/hda1 (type 82 in cfdisk) and made the rest into a type 83 (ext2) partition /dev/hda2.

Then I created swap partition on /dev/hda1:

mkswap /dev/hda1
swapon /dev/hda1

Finally, I performed the actual install using dsl-hdinstall command, and specifying /dev/hda2 as my installation drive. I choose Grub to be my bootloader and rebooted.

Note that the default entry in Grub is the Xvesa, non frame-buffered mode. So when you boot, you need to make sure you choose the fb800x600 option. The boot was pretty seamless and relatively fast. My next task was setting up wireless.

I went and downloaded the windows drivers from the linksys ftp site. I think I wrote about this before – thanks to Linksys’ brilliant versioning WPC54G v1.2 is really v1.3. Go figure. I downloaded the zip file, and transferred the lsbcmnds.inf and bcmwl5.sys files to the laptop on a USB stick.

Here is the little caveat – watch closely what I did. I copied both files to my home drive:

# ndiswrapper -i lsbcmnds.inf
Installing lsbcmnds
# ndiswrapper -l
lsbcmnds   Invalid Driver!

Apparently you need the absolute path here:

# ndiswrapper -i /home/dsl/lsbcmnds.inf

I don’t remember having to do this on Ubuntu, but go figure. Then I of course loaded the ndiswrapper driver:

ndiswrapper -m
modprobe ndiswrapper
echo ndiswrapper >> /etc/modules

Once I did that I ran iwconfig from the GUI menu. Strangely enough you can’t use ifup to bring up your wifi – for some reason it does not recognize wlan0 as a valid interface, even though it does show up when you do ifconfig. The GUI tool works though. If you specify wlan0 as your interface, and input your channel, ssid and WEP key and hit ok, all should be well.

So now I have a working DSL install. The resolution is low, and everything looks bit ugly but it is quite speedy compared to the sluggishness of Win2k. The base install with just the window manager and a single instance of rxvt running takes only around 12MB of RAM (no swap) and less than 2% of CPU time to run which is quite impressive. Of course Fifrefox will happily eat up all your remaining RAM as soon as you touch it, so it’s usually better to run the incredibly speedy Dillo to browse the web. To bad that some pages look like crap in it.

My only issue with DSL is that it is not really intended to be used this way. DSL was designed primarily to be a quick and easy live distro and you feel it at each step. Every time you reboot it, forgets certain things. For example to re-set my wifi with iwconfig every time. Other settings mysteriously reset themselves as well. Perhaps some tweaking will resolve this but it definitely does not work 100% directly “out of the box”. But hey, I guess I can’t complain. It work – and much faster than windows at that. It will probably be hard to beat the memory footprint and installed size of this distro – but the video performance could be better.

K. Mandla highly recommended Arch so I decided to try it next. Unfortunately, that did not work. Halfway through the initial boot off the CD I got a kernel panic, and a (un)helpful message that my CPU is to old. I guess Arch and Presario were never meant to be.

So my next steps are: Slax or Slax Popcorn (shipping with XFce instead of KDE). If that fails, I’ll get the smallest debian install I can find and then just build it from the ground up till I have a working system. Either that, or maybe I’ll finally try Gentoo for that “optimized for this particular machine” touch.

[tags]compaq, compaq presario, compaq presario 1240, dsl linux, puppy linux, arch linux, deli linux, linux, windows, windows 2k, windows 2000, windows xp, laptop, notebook, dillo, ndiswrapper, WPC54G v1.2[/tags]

First of them (see the image on the left) turned out to be a Dell Inspiron 1150. This machine seems to have an a 2.6GHz CPU under the hood, a 256MB of RAM and 40G HD. It is actually a pretty solid machine. The only catch is that the screen is totally busted. If you look at the pic, this is how the screen looks like after you turn the machine on.

I connected it to an external monitor and it booted all the way into Windows and then froze. I’m guessing that the mobo and RAM are fine, otherwise the system would bug out much earlier. I think the machine was dropped (the damage to the display suggests this) so potentially I might be working with a bad drive. There might have been a nice head crash caused by the impact, but since the HD is still spinning, and reading data I’m guessing that they didn’t break the head or wedge it into the platters. Hopefully, we are dealing with few bad sectors that will be just marked as dead when I reformat.

I’m currently souring eBay for cheap displays for this model. The “Buy Now” entries are tad expensive ($150-$200) which is actually a quarter of the price of a new laptop. I’ll see if I can maybe win one of the cheaper auctions…

Second machine was an ancient Compaq Presario 1240. Amazingly enough it was in perfect condition. Someone actually managed to install WinXP on it. Scarry! This thing only has 98MB of ram and 200 something MHz CPU. I reformatted it and installed Win2k which unlike XP is actually usable within these specs.

It has no network card, but it does have a PCIMCIA slot, so I’m going to pick up a wireless G card tomorrow, and set it up for my dad so that he can use it to browse the web, and get email until I fix up the Dell.

Heh, if I get the Dell working before Christmass I can probably convince Santa to bring my dad some RTS and turn based games this year. :)

[tags]laptops, relatives, dell, inspiron, inspiron 1150, compaq, pressario, presario 1240[/tags]