<xmp><!-- <body> --></xmp>

Damn Small Linux: from Athena Widgets to Yenta Sockets

Jon Nileprecinct Feline

In what is now the 2 years I have spent with my premier Linux distro DSLinux I have written this essay repeatedly, each time with a broader insight into the idiosyncracies of this marvellous achievement. Having just relied upon DSLinux for a realworld recovery from a recent system crash I have even more respect for it, & would like briefly to summarise why. Be sure to click on the pix for more info.

A short history

In the 80s I coded COBOL for a decade amidst the last of the IBM mainframe assembler programmers who still looked down on "high level languages". I remember the IBM 3380 DASD, DOS 2.11, QEMM, & the bulletin boards which hytelnetted me to my first IRC clients where I hung on the original #Twilight_Zone. Ive written BASIC, Fortran, Algol, PL/I, COBOL, C, HTML, css, Java, javascript, & have most recently taught myself Linux shellscripting from scratch. Although trained as a computer scientist I became a creature of the net in the days before the web, & still have no use for highbandwidth content & therefore continue to get online via ordinary dialup. In the 90s I installed Unix-derived Chinese fonts under DOS on a Win31 notebook. Windoze of course is an application platform & not an operating system & in my dismay at being unable to get it to behave like one I have spent years trying to ignore it. I nonetheless have 100+ XP software titles ready to repopulate each new install & have always used it as my primary workhorse. Finally, my data integrity concerns are modest. I have 8000 images, 800 mp3s, & 80M of webcoding in some 40 projects, all of which is crossplatform & carefully backed up.

IBM 3380 DASD : 1980 : 2.5 Gigabytes : $140,000

For me, DSLinux proved to be the ideal introductory Linux distro for a number of reasons. Its incredibly small size meant it can be acquired in mere hours over the phone. Its retro 2.4.31 kernel is so attractive the project actually fell back from a 2.6.xx offering to create DSLinux v4.4.10. The embedded Firefox is not too old & Opera is available in the repository. Significantly, the project is inactive, meaning what a given person is working with is rock solid stable. Although much of the user interface scripting is buggy & must be wiped away, the bulk of the repository extensions created by the adjunct researchers is of superior quality & can customise the DSLinux system into a fully-featured Asian enabled dialup browser & media editor.

Is DSLinux actually broken?


Ive gone over this numerous times (& may even have posted about it somewhere) but its not worth wasting breath over. The scripting fixes I have adopted are posted on my site:


& have mainly to do with the malinstalled desktops & the extension downloader (update: DSLinux 4.11 released 2012aug03 in fact fixes precisely these issues as well as others). A newbie to Linux generally wouldnt have the luxury to use the DSLinux implementation as a laboratory to learn configuration issues. Yet theres a more fundamental Linux type message here. Key functions like the desktop config, filemanagement, package installs & executions, the initiation of console sessions & starting Xwindow, propagation to bootable flash & LiveCD (among others) must be under the administrators complete explicit control. Simply once I had properly installed IceWM, MidnightCommander, VFU, Opera, & Lynx, & rescripted the interactive init & application management, the underlying 2.4.31 / Debian / Knoppix technology is in fact a particularly robust & serviceable Linux.

Superior technology ever moving forward

Unix of course was originally engineered for classical midrange computers & the heart of its executive & filesystem architectures becomes more adaptable with advancing tech, which represents several orders of magnitude beyond the original platforms. DSLinux (& its peers) can not only exist completely on a selfcontained LiveCD, but can boot their entire virtual filesystems into ramdisk. A DSLinux install isnt necessarily a snarl of delicately balanced config files on a harddisk; it can in fact be a monolithic image which is merely served into memory space from any of numerous devices visible to the kernel at boottime. In addition, individual applications arent permanently installed in the traditional sense, leaving no footprint until & unless they are requested during a session. DSLinux apps are bundled into "UCI"s which are mounted upon request as readonly filesystems. All the users settings are herded into a tidy /home directory which allows for "persistent" customisations to be backed up to flash. This means untoward things happening to the OS or the apps during a session normally cant break the system; it recovers to its vanilla state with each reboot.

DSLinux was among the first to perfect this paradigm of ramdisk residence booted from removable media but it is likely to become more ubiquitous. As recently as the mid 00s a system image booting from a 512M flashdrive was ingeneous when flash was still $80/G. Suddenly this capability will find an altogether new use with 4G flash now firmly under $15.

Classical studies

These days the Windoze refugee wanabees in ubuntuland believe one shouldnt have to "learn Linux like in the 90s". Certainly I love to see my apps run & my hardware recognised, but theres still too much history out there to ignore the MIT ftp archives, the Unix Haters Handbook, the International Obfuscated C Coding Competition, advanced scripting, regular expressions, & the operation of the compiletime & runtime linker. Linux also cannot be separated from its philosophies including its relationship to its communities. Even modern desktop Linux users arent entirely spared the quasirevolutionary rhetoric surrounding the GPL & its place in the history of software development. But someone using the web to get a Linux distro to work is safer starting by trawling the DSLinux archives, as they contain the complete story of a project whose final offering proved a functional success despite the technical mayhem, rather than be in the line of fire in a realtime forum somewhere tempted to effect bleedingedge fixes to a current release. In short, for the studious, DSLinux is an excellent place to start.

DSLinux can be tamed

I installed DSLinux on 2009jan03 & within 2 weeks had a PPP connection over a USR5637 USBmodem. I immediately ceased using Windoze. Booted from flash, DSLinux cant update the NTFS on the harddisk but *can* read it. That means with plenty of rewritable room on the flash & with all the Win data visible, Windoze merely needs to be booted periodically to propagate updates from flash to the harddisk. Windoze can be relied upon to burn CDs & rip audio but DSLinux proves theres no need to have write access to the disk or boot from it for the majority of ordinary tasks. Ive also been keeping around a trailing edge Dell or Presario completely devoted to a properly partitioned DSLinux harddrive "frugal" install which is necessary to burn a LiveCD image of the customised system, & which can otherwise run XMMS & serve as a perpetual mp3 player. DSLinux & its extensions have thankfully omitted the Unix manpages (& the manpage reader), the former almost always locatable online & the latter replaceable by a routine which converts manpage to HTML.

Ill admit I maintain by hand the IceWM menuing structure which rather than the desktop is the primary interface to the applications, & I also keep it mirrored as an HTML page which allows local application menuing under LYNX even at the console. The usermenus of MidnightCommander & VFU (both of which can run in console mode) have also been extensively tailored to perform system tasks such as mounting / unmounting volumes & to recognise various filetypes. At that point it is indeed possible to surf the archives at large including the Debian repositories to acquire sources which successfully compile / install & execute. Most fundamental are my dozens of bash scripts which perform system functions including application management & menuing (imagine ... a programmable operating system). Linux scripting is phenomenally viable & its long tradition means there are millions of examples & a reason to go ahead & cultivate expertise in it. Because these scripts are full of properly debugged Linux syntax they do more than automate repetitive tasks; they serve as documentation for the most arcane albeit intrinsic commands & their parameters. The overall result is a seamless interface between the filemanagers & the atomic operating system commands.

Replacing the system

When the XP device finally crashed recently I acquired my first nForce chipset & found myself adapting the DSLinux flashdrive boot to a BIOS which expects "USB-ZIP"; ie an iOmega zipdrive plugged into the USB. It is classical Linux retro engineering to use sfdisk to give 4G GigaWare flashdrives "zipdrive geometry" consisting of 64 heads & 32 tracks/sector whereupon the 51M bootable DSLinux partition can be placed behind a FAT16 partition, the rest of the drive an enormous amount of partitionable available space. I called the process "Thanksgiving with Shingledecker" because that November I had to rip apart his final buggy script & perform the forensics required to verify why DSLinux no longer has a routine for USB-ZIP pendrive install. Ultimately I created the necessary script which spawns the current pendrive system while booted from the current pendrive.

GigaWare FlashDrive : 2010 : 4.0 Gigabytes : $9.99

I now boot the nForce from what I call "MBR on a stick", a zipdrive geometry bootable pendrive with the GRUB bootloader invoking the DSLinux 2.4.31 kernel (with a menu option to start XP from the untouched harddisk MBR). The BIOS often takes the bootdrive offline at that point (only to become readdressable via the later hotplug scan), yet the loaded kernel succeeds in locating the rest of the Knoppix image on almost any other visible medium, including Linux partitions on the harddrive which then do not themselves need to be "bootable". Ultimately I used GParted to halve the size of the XP partition on the 80G drive. By disabling Windoze paging, defragging, then booting *2x* after the partitioning XP has no problem with what Ive always considered a radically perilous process. For the first time half my production harddisk is devoted to Linux filesystem partitions, meaning a boot from any medium has access to Linux swap space & Linux disk I/O. BTW I discovered in the process that DSLinux *can* burn data CDs with a little patience. A system crash is a valuable thing.


& thatz the scoop. DSLinux works great, but it cant start DHCP or ALSA on those nForce mobos. LiveCDs on the way. Thankz everybody (!).

Blog Home
Articles / News


hit counter

hosted by

powered by
kBlog v1.02.007

find the Mystique
Screaming CuckooBroad Associates part of the CircleOmega organisation
<noscript> <!-- ooo