Home page


Email me

Just The Linux 1.3

JTL is a very simple Linux distribution. It doesn’t come with any of the random junk that the big distros like to fill your winchester with -- stuff you don’t even understand, let alone need.
  • JTL does not use PAM
  • JTL does not even use shadow passwords
  • JTL uses a BSD-style /etc/rc, not all this init.d drivel
  • JTL does not have binary packages
  • JTL does not, in fact, have any package management at all
So what does it have?
  • JTL is less than 200Kbytes to download [1].
  • JTL builds everything from source. There are NO binary packages, although you can subsequently install non-open-source programs such as Acrobat if you wish.
  • JTL has shiny new versions of most things. This includes KDE 3.5.6, X.org server 1.3.0, glibc 2.6, and gcc 4.2.0.
  • JTL builds everything optimised for your CPU (-mcpu=i686 or whatever).
  • JTL builds its own bootable install CD -- or, alternatively, its own bootable NFS root directory. You can copy its ideas to make your own custom distributions for specific purposes, e.g. for booting discless audio/video clients.
  • JTL targets ia32, amd64, ARM, sparc32, and sparc64. (DEC Alpha support used to work, but got broken somewhere.)
[1] Plus over five hundred miscellaneous source tarballs which you have to find and download yourself, total around 1100Mbytes.

Downloading JTL

JTL 1.3 distribution jtl-1.3.tar.gz (188Kbytes).

As to where to get the source packages you’ll need, you’re on your own -- but Google, Sourceforge, and Freshmeat are good places to start looking.

Installation Instructions

Because JTL has no binary packages, you need an existing Linux system on which to build your installation CD. (An alternative name I considered was “Contagious Linux”, as you can only catch it from a system that already has it.)
Download the latest jtl-*.tar.gz and unpack it. In it you’ll find “FILES”, which is a list of all the source tarballs you’ll need for a complete JTL system. You don’t need all of them to get started, but you’ll need at least the ones mentioned in Make.sub:
autoconf automake bash binutils bzip2 dhcpcd e2fsprogs fileutils findutils gawk gcc gettext glibc grep gzip sysvinit linux lilo make modutils ncurses net-tools netkit-combo patch procps sed sh-utils tar tcp_wrappers textutils util-linux fakeroot dosfstools syslinux mtools cdrtools
When you’ve fetched all the tarballs, you can start building. Building occurs in the “build” subdirectory of your jtl directory, so use a symbolic link or a mount point if necessary to make sure there’s at least 1200Mbytes free on the partition it points to.
Now build your bootable installation CD. In your jtl directory, type
make JTL_ARCH=i386 sub
bearing in mind that you probably don’t want these binaries optimised for your CPU, as that would produce an installation CD unusable on earlier CPUs.
This process will first build a few tools (fakeroot, syslinux) that are necessary for building JTL itself. These tools are installed, by default, in /usr. If you are not root, or do not trust JTL to put stuff in /usr/bin responsibly, you should do
make PREFIX=/home/whoever fakeroot
fakeroot make JTL_ARCH=i386 PREFIX=/home/whoever sub
but you will need to make sure that PREFIX/bin and PREFIX/sbin are in your PATH.
Some time after you’ve typed that, you should be left with i386.iso in your JTL directory. Burn that file to a CD and boot from it.

Installation Instructions, Part 2: The Installation CD

OK, I lied. It’s not an installation CD. There is no form of installation program on that CD whatsoever. It is, however, enough of a Linux distribution for an expert to manually use fdisk, lilo etc. to install Linux on any detected mass-storage device. There is even enough of a distribution there that, if you have a PCI network card supported by Linux 2.4.18, and you have a DHCP server elsewhere on your network, telnetd will run and you can log in as root (blank password) and install the system remotely.
If you’re not sure whether you’re an expert or not, and want a bit of a checklist of what a manual installation entails, you’ll need at least to:
  • Use fdisk to partition your winchester (if it’s not partitioned already, or if you want to change the way it’s partitioned). This hoses the whole disk, so watch it.
  • Use mke2fs to format your root partition (and any other partitions you want). This hoses the whole partition, blah blah.
  • Use mkswap on the partition you want to swap to, if any.
  • Mount the partition you want your root filesystem in, on /mnt. If you want /boot or /usr to be on different filesystems, mount them in the right place under /mnt.
  • Untar /i386-root.tar.gz (from the installation CD) into /mnt.
  • Edit /mnt/etc/fstab and /mnt/etc/lilo.conf appropriately, and run lilo -r /mnt. This hoses your previous boot sector.
  • Once you’re satisfied that /mnt is probably a bootable root filesystem, and that lilo is going to do the Right Thing, you can umount /mnt and reboot, dextrously removing the CD before your system tries to boot from it again.
Do not moan at me if it doesn’t work, unless it’s fairly provably my fault. In particular, it’s your fault, not mine, if you’ve misjudged whether you’re an expert or not. That’s why it’s called “Just The Linux”. Any problems you have are a personal matter just between you and Linux, and I’m not going to get involved.

Installation Instructions, Part 3: A New World

Unless you edited /mnt/etc/passwd above, the root password is still blank. (Which has security implications, of course, but if you didn’t know that sort of stuff you wouldn’t have read this far.)
Your new system has a JTL directory at /usr/src/jtl, and your previous collection of archives in /archive. You’ll probably want to start by rebuilding the base packages, optimised for your CPU (recall that those on the install CD were optimised for i386). In /usr/src/jtl, type “make base” (which remakes everything that came on the installation CD). JTL will optimise for your CPU by default, you don’t need to set JTL_ARCH.
If JTL doesn’t work out how to optimise for your CPU (which is likely, for instance, if you have an Athlon or Duron) you can override the default optimisations by setting JTL_ARCHFLAGS in /etc/jtl.conf (see the Makefile for how that works).
If you rebuild init or glibc (which “make base” does), don’t forget to run “telinit -u”, or rc.shutdown won’t be able to cleanly unmount /.
The basic installation includes only enough programs to compile the rest of the system: if anything could possibly be left out and compiled later, it has been. So once you’ve recompiled the base packages, you should start adding to your collection of tarballs, and making further packages:
  • If you didn’t go “make base” then you need to “make gcc”, as the one on the installation CD is a C compiler only, not C++.
  • “make kde” might be a popular choice, or “make evolution galeon”, or both. Making KDE takes 17.5 hours on a Celeron 366, or about two weeks on a Sun Ultra 1.
  • You’ll almost certainly want packages such as man, time, which, nfs-utils, apache, console-data, perl and python.
  • For a server you might also want imapd, samba, exim, and procmail.
  • There’s a good amount of audio/video stuff in JTL, including amarok, lame, mplayer, transcode, and ogle.

Alternative Installation Methods

Bootable NFS root: As well as the i386.iso CD image, the “make sub” procedure described above leaves you with a directory i386-root, which is suitable for use as a bootable NFS root. It also sets you up a /tftpboot directory, using PXELinux, suitable for most BIOS “network boot” settings. In order not to overwrite any existing settings, it sets it up under i386-root, so you’ll want to copy that to the right place on your boot server. See the PXELinux/SysLinux web pages for more on NFS booting, which would double the size of this document if I described it all here. Once you’ve got it working, you can go on to Part 3 of the standard instructions.

Chroot jail: To see what life would be like on a JTL system, you could visit one temporarily by “chroot i386-root /bin/sh”. This is also handy for testing new JTL makefiles, i.e. seeing whether they specify enough dependencies to build correctly on an “empty” system.

JTL-for-non-x86: Everything described so far assumes that your Linux machine is x86-based. And, indeed, that’s the only platform that making JTL install CDs has been tested on. But in theory, it should work for other architectures too; that’s the big advantage of compiling from sources. A machine of any architecture should be able to compile a native JTL for another machine of the same architecture.

JTL-for-sparc32: JTL has one further trick up its sleeve. If, instead of “sub” you make “sparc-bootstrap”, JTL will attempt to cross-compile a Sparc Linux bootable root from x86. (It builds an x86-to-sparc32 cross-compiler first.) This means that JTL-for-x86 can be contagious to sparc32-based machines (such as the Sparcstation 4, but not Ultrasparcs), in a kind of species-jump vCJD kind of a way. Again, this leaves you with the barest minimum of software (not even an editor, this time) and you should be prepared to spend a considerable time compiling before you have a usable system.
The bootable sparc32 root is left in the directory “sparc-root”. Currently the only way to get a Sparcstation to boot it, is via NFS boot. You’ll need to set up rarpd, tftpd, and NFS on your server; various web pages will help with that, but note that the “rarp” command doesn’t work on modern Linuxes, and you really do need to use rarpd and /etc/ethers. Copy the “sparc-root” directory to /tftpboot/<sparcstation-IP-address> on your server. Then just type “boot net” at the Sparcstation’s PROM prompt. Once you’ve got NFS booting working, JTL can make all the tools (silo, elftoaout) that you’ll need to install Linux to boot from the Sparcstation’s winchester.
Stop me if I’m bragging, but the very first time I tried cross-compiling a sparc32 userland and NFS booting it, the whole hella thing came all the way up multiuser. How cool is that?
Sparc32 hardware that was the stuff of dreams when I were a lad, is now available for essentially no money on Ebay. It’s a cheap and stylish way to test software portability to big-endian platforms, though the performance that wowed us back in the days of sun3, seems really quite feeble nowadays.

JTL-for-sparc64: The “sparc64-bootstrap” target works like “sparc-bootstrap”, but for 64-bit Ultrasparc-based machines (Ultra 1, and most if not all subsequent Sun gear). The userland is wholly 64-bit, which makes this port a teensy bit experimental (X and glibc need patches to even compile).
The userland is left in the directory “sparc64-root”, and needs to be NFS-booted by the Ultrasparc in the same way as described for sparc32 above.
Sparc64 hardware such as the Ultra 1 and Ultra 2 can be had for under fifty pounds on Ebay, though even machines like the Ultra 5 -- scarcely usable in today’s terms -- still go for real money. Again, it’s useful for testing software portability to big-endian LP64 platforms.

JTL-for-alpha: The “alpha-bootstrap” target works like “sparc-bootstrap”, but for machines based on the DEC Alpha. This was the most recent target I got booting, and not all packages build yet.
The userland is left in the directory “alpha-root”, and needs to be NFS-booted by the Alpha in the same way as described for sparc32 above.
The JTL holotype for Alpha is a DEC Multia using a 166MHz 21066. These are so feeble that they’ve dropped off the bottom of Ebay: I saw a dual-CPU 533MHz 21164 going for under £30 the other day. Alpha is important, though, as it “completes the square” of all four target combinations of 32 and 64-bit, little and big-endian.

JTL-for-ARM: The “arm-bootstrap” target works like “sparc-bootstrap”, but for ARM-based machines such as Empegs and RiscPCs. GCC has known bugs on ARM and will not compile certain packages unless optimisation is turned off (you might want to edit the JTL Makefile on your x86 machine first). This doesn’t currently work -- the userland builds successfully, but all its binaries segfault when run on an actual RiscPC.
The toolchain built is a soft-float one.

JTL-for-powerpc: Currently this target is just theoretical, and the compiled userland hasn’t been tested. Again, you’d start out by NFS-booting it. Early IBM RS/6000 powerpc32 gear can easily be had from Ebay – though some RS/6000 kit comes in the same cases as IBM 486 PCs from the same era, and so doesn’t look anything like as cool as the obviously-not-a-PC sparc and alpha boxes.

Building from Cygwin: You’re a sick man for even thinking of it. But you might be able to get it to work. Try it.

When The Kernels Don’t Work, They Just Make It Worse

The “.config” files for the kernels used for bootable CDs and for NFS booting, are kept in the jtl/patches directory. To edit them (perhaps to add more SCSI drivers, or drivers for an ISA network card):
tar xzf linux-2.4.18.tar.gz
cd linux
cp jtl/patches/linux-2.4.18-config-bootable-cd .config
make oldconfig
make menuconfig (or xconfig or whatever)
make oldconfig
cp .config ../jtl/patches/linux-2.4.18-config-bootable-cd

But It Doesn’t Have Program Foo, Which I Use Every Day

So figure out how to compile and install it, and send me a Makefile so I can integrate it into the next version of JTL. If you’re a vi user, you’ll have to figure out how to compile and install vi using only xemacs. Ha ha, de ha ha, har.
Programs which can be installed by a simpleminded “untar ; configure; make; su; make install” only need very simple Makefiles, as most of the work is done by the generic “_gnu” target; look at Make.pkgconfig for an example. Note that JTL installs everything to /usr by default, not /usr/local.
JTL does have patches for a few particularly vital or intransigent programs, but try to avoid relying on a patch when adding further packages to JTL. Patches get out-of-date quickly, whereas evilness in Makefiles (and some of the existing ones, particularly ncurses, are tangibly evil) tends to be more durable.
If you submit a Makefile, I’d appreciate it if you donated that Makefile to the public domain (rather than claiming copyright on it), as I have done with all the Makefiles I wrote.

Special Prize For The Package Whose Build System Caused Most Grief

Awarded to ncurses.

Licensing And Legal Issues

JTL will build many different packages, which between them have many different licences. It is up to you to obtain and use those packages in accordance with those licences. Just because JTL includes a makefile for a given package, doesn’t mean you’re necessarily allowed to build or use it.
For example, JTL will build libdvdcss for you, if you have obtained a libdvdcss source tarball and if you tell JTL to build it (or a package which depends on it). JTL itself contains no CSS code whatsoever, nor links to where any may be found. Only if you already have it, will JTL be able to build it.
As another example, JTL will build several packages which are capable of reading or writing GIF images using LZW compression. If you live in a country where software patents are enforceable, then you may require a patent licence from Unisys to obtain or use any of these packages. JTL itself contains no LZW code whatsoever.
As a third example, JTL will build several packages which use “strong crypto”. Such packages may be illegal to export, or require a special government permit, or may even be illegal to own at all. JTL itself contains no cryptographic code whatsoever.
Those parts of JTL which I did write -- the Makefiles, and one or two (not all) of the patches -- are placed in the public domain. As a request (not a demand), if you use them for anything else, it’d be nice if you mentioned somewhere that your creation was based on, or included, parts of JTL.

Other Projects That Are, Frankly, Pretty Similar To JTL

If Sourceror Linux, Gentoo Linux, or Linux From Scratch had been around when I started, I might not have bothered. Gentoo, in particular, has a lot more packages than I do. But I believe they all still have a binary download for the installation CD, and I don’t believe they can cross-compile themselves.
(K) All Rites Reversed -- Copy What You Like