Just The Linux 1.3JTL 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.
Downloading JTLJTL 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 InstructionsBecause 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 cdrtoolsWhen 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 subbearing 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 fakerootbut 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 CDOK, 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:
Installation Instructions, Part 3: A New WorldUnless 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:
Alternative Installation MethodsBootable 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.
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).
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.
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.
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 WorseThe “.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
But It Doesn’t Have Program Foo, Which I Use Every DaySo 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 GriefAwarded to ncurses.
Licensing And Legal IssuesJTL 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 JTLIf 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.