Zen programming is not a spectator sport.
A Linux distribution optimized for ordinary computer users with less
than ordinary computers. Slow, resource hungry systems are avoided,
while still providing easy to use, full featured, standard applications.
Power users are not forgotten, I am a power user and I intend to use My
Linux on my own over powered workstation for all my daily work.
My Linux is being built to support various volunteer projects that I (David Seikel
Build IT provides recycled PC's and computer support to charity organizations. They asked me to find a Linux distro suitable for their needs, or build one if none of them were suitable. While modern distros will do what was needed, they all required too much ram, and are too slow to be used on the equipment donated to Build IT for recycling.
I had already been developing a Linux distro based in Trinux to support clustering experiments by HUMBUG, a local unix user group. The HUMBUG cluster is made of PC's that are similar to the Build IT PC's.
I also run the HUMBUG distro server, a file server available at HUMBUG meetings that serves many open source unix distros, about 90% of them are Linux. The cluster distro I had been developing also included my experiments to develop a wrapper to allow network installs of any of those Linux distros that don't support network installation. The end result is to allow the distro file server to support diskless network installs of dozens of Linux distros in a generic way that doesn't need me to become expert enough in all these distros so that I can setup the server specifically for each one.
We are combining all these efforts into one Linux distro that we call "My Linux" as they share requirements. The features of My Linux are -
To answer some of the questions asked by sourceforge that are not answered elsewhere in this document -
The distro will be released as a single CD image, so each release will be upto 700MB in size.
While the release schedule has yet to be determined, release early and release often is the usual way of doing things in the open source world. Keeping in mind that this takes up a lot of space, we should settle on six or twelve months between releases once we have settled on a version 1.0. My preference is for 12 months. Until we get to version 1.0, the CD image will be much smaller, currently 200MB, and we might release every two months.
The bulk of the distro will be made up of pre existing packages, and the bulk of the rest will created as seperate packages, probably on sourceforge. This leaves a small collection of system build scripts that will need to be stored under sourceforge CVS. The sourceforge web site service will also be required.
We will not be porting software to new hardware or OS platforms.
No automated update mechanism is planned for now.
We are aiming for LSB compliance, and LSB requires RPM packages.
We are only planning on releasing stable versions to the public. A current snapshot will be available directly from us on request, but sourceforge will not be required to store it.
Only I will be directly updating the package tree.
This is a problem I have already solved, see
Micro runlevel. Part of the problem is the use of an
interpreted language for part of the boot process, typically shell
scripts. We convert boot programs to C.
The other major part of the problem is not so much speed of booting, but time from switch on to being able to login and do useful work. So we have split the boot process into two. The first part concentrates on getting the login prompt/window up as soon as possible. The second part boots the rest of the system in the background on a different VT.
Both of these work well in practice, the Pentium 100 MHz test box starts My Linux an awful lot quicker than my Athlon XP 3000 starts a major Linux distro.
Using Linux BIOS will also speed up the boot process, but is beyond the scope of a distro, due to the issues of mother board support and the dangers inherit in rewriting BIOSes.
Starting speed of applications.
The same principle can probably be applied to the startup of other major
systems like X, KDE, and OpenOffice.org.
KDE is the current focus of our efforts. While it is a really nice,
featureful system, and most KDE applications tend to be the best, most
highly polished, and feature rich in their class, this comes at a cost.
KDE requires lots of ram and time to startup. KDE programs, when run
outside of KDE, take forever to startup. We want all our applications
to startup quickly, and be feature rich. I have been looking for a long
time for non KDE applications to replace the KDE ones I love and use
often, and still have not found replacements with all the right
KDE is composed of a variety of sub systems, so a divide and conquer approach will work well. We will write, find or patch replacements for all the sub systems so that we can still have a KDE like system that KDE applications will play with nicely, yet be compatible with other window managers.
An example is the KDE kicker replacement I am currently writing. It works with any window manager, starts very quickly, and supports freedesktop.org's standards. Even when starting it as part of KDE, it starts up faster than KDE's kicker. It will auto detect Enlightenment, GNOME, KDE, and ROX menus/applications, building menus, allowing drag and drop of icons, etc. Using this will allow the user to start doing useful work (start applications from the menu) while the rest of KDE starts in the background.
Network install wrapper.
Most Linux distros come as a CD, or .iso file suitable for writing to a
CD, that is bootable and can be installed from that CD. Larger distros
come on more than one CD, or DVD. Not all of them support network
installing. While the work I am doing in My Linux is specifically to
support one computer club, it is my hope that we can show the way for
other distros by providing an easy to use, generic wrapper.
This wrapper will be the My Linux initrd that is network booted, along with the kernel from the CD of the distros installer, or the My Linux kernel if needed. It will do it's magic, then download the real initrd from the server and start it, which will install as usual.
The magic is that when the distros installer tries to access the CD it thinks it booted from, it will be redirected across the network to the .iso of that CD on the server. The magic will also need to cover the case when the user is asked by the installer to insert the next CD. The distro may also do some strange things that this magic may or may not be able to handle. This requires a special device driver. The problem is that this magic driver does not exist yet. Our team does not include any Linux device driver experts. We will either track one down, or I will learn how to write device drivers.
The My Linux initrd will rely on NIC drivers built into the kernel (which is why the distros own install kernel may not be suitable) and use DHCP to configure the networking. Then it will download a configuration file based on a kernel command line parameter that says it booted from a network. This configuration file will inform My Linux that it is to be a network install wrapper, and provide it with the details it needs to setup for this particular distros installer. Based on these details, My Linux can download kernel modules, the distros own install initrd, whatever it needs.
Sourceforge project site.
This file was last modified on 2005-03-14