You're not reading the latest revision of this page, which is here.

BasicLinux LCARS

The BasicLinux-LCARS README and the associated BL-LCARS Wiki (both on github) contain actual usage and development information. This page is more akin to a blog post about the state of the project.

BasicLinux-LCARS (Live CD and Recovery System) is a custom Linux distribution based on BasicLinux 3.5, targeting 386 systems with as little as 4MB of RAM.

The BL-LCARS distribution is not meant to be extremely tiny like BL3. The CD aims to pack in as much utility as humanly possible. While compatibility with 386 is paramount, and running within 4MB of RAM is a conscious design goal, the real aim of the project is to provide a Linux LiveCD that will run not only on a meager 386 but also a "modern" turn-of-the-century PC, so roughly any system that can run Windows 3 or Windows 98.

My initial inspiration was a system I could use to back up a complete disk image of an IDE HDD in a 386DX-40 with 8MB of RAM. BasicLinux provided a platform that could record a complete image of the internal HDD to external storage or even to my NAS over smbfs. It has since become my go-to retro PC network backup tool, is a useful recovery environment for any kind of x86 system, and provides a complete installable desktop environment for permanent use on retro machines.

BasicLinux 3.5

BL3, as it was known among its community, is a tiny libc5-based Linux distribution which can fit on a pair of floppy disks and boots via MS-DOS using LOADLIN.EXE. BL3 uses a custom 2.2.26 Linux kernel, with all drivers built as modules, and a fairly complete build of BusyBox 1.01.

Despite the contemporary (~2007) kernel and BusyBox builds, BL3 was designed to be compatible with Slackware 4.0, which shipped with an early 2.2 kernel and a libc5-based core system. Slackware 4 packages can be installed with little hassle, and except where subtle shell differences between BusyBox and Bash exist, the systems are completely compatible (and those issues can be overcome by installing Slackware core utilities).

2.2 provides solid compatibility for hardware ranging from 386s to 686s. I found it failed to boot on SATA-equipped systems.

`libc5` vs `glibc`

It took me a lot of reading old threads to figure all this out.

Except it's actually all just in this man page

Basically, in the beginning there was glibc-1.0. This was good, but Linux was developing faster than glibc was, and so forked Linux libc, which was distributed as libc{1..5}. So libc5 is the last version of "Linux libc", and glibc-2.0 is functionally libc6, the next in the series. glibc2 is much bigger than libc5, so Slackware continued to use libc5 to compile its core utilities for a few releases after glibc2 went mainstream in 1997-1998. This is why it was chosen as the basis for BL3, as it had "modern" (~1999) versions of Linux utilities compiled agains the older libc5.

BL-LCARS installs glibc-2.3.1 alongside libc5 (as of Revision 6), so apps compiled for either library will run, and Slackware system utilities will use the leaner libc5 implementations.

BL-LCARS v3.5.1

The 3.5.1 series includes "Beta 1" revisions 1 through 6.

Revision 5 provides a complete utility image, with full network capabilities, a suite of MS-DOS utilities, a full IceWM desktop environment, and support for a huge range of hardware including USB.

3.5.1 uses the same kernel and libraries as BasicLinux-3.5, and aims to be 100% compatible. Unfortunately, revisions up to and including Beta 1 Revision 5 have some library incompatibilities with BL3.5 that will be resolved in Revision 6, if Revision 6 is released.

BL-LCARS v4

v4 is a major overhaul, which still aims for compatibility with BL3 and Slackware 4 packages, but will ship a new core system - Linux 2.4.37, Binutils 2.12, GCC 2.95.3, glibc-2.3.1, BusyBox 1.32 (keesan's build). In addition, the 2.4 kernel enables the use of tmpfs and mini_fo to provide a complete virtual read-write liveCD experience (on systems with sufficient RAM) which also eliminates some of the very hacky tricks used in 3.5.1 to enable writable temp and lock files on the read-only CD filesystem.

The change to 2.4 requires a complete rewrite of the initrd scripts, and likely changes to /etc/rc and startx, among other BL-LCARS scripts.

the 4MB problem

The problem is that while 2.4 is actually pretty efficient in terms of memory, it adds a lot of CPU overhead. The system as-written is very slow on a 4MB 386, to the point of being mostly unusable, despite 4MB technically allowing the system to boot and load network drivers. One idea is to provide extra options in the MS-DOS boot menu - an expliclit "low memory" mode could be selected which uses the older kernel and init scripts. approximations thereof).

An issue here is that calling ls /lib/modules/$(uname -r) takes nearly five full minutes with the current 2.4 build and 4MB of RAM on a 386DX-33. It's not realisitc; loading NE2000 drivers takes almost half an hour. Building fewer modules means less compatibility.