cLIeNUX FEATURES, Oct 1999
I'm wrapping up the next cLIeNUX release, which will be out in a matter
of days, and will reflect most of what is described below. cLIeNUX is
based on or influenced by or strives to be similar to several existing
systems. My influences, and the influences I think will be of most use to
Linux "on the desktop", are unix, Linux, the GNU system, the Amiga, the
Forth programming language, and the ASCAP/BMI model of compensating music
authors and recording performers. cLIeNUX is actually the current
incarnation of an earlier proposal for a from-scratch-new Forth
hardware-software platform I did, that never went anywhere, but saw some
very encouraging discussion.
The open source movement in the unix world is nothing new. The Forth
programming language gets much of its striking functionality from the fact
that Forth is open source by design at the lowest level possible. The
reusability and mutability of open source software is inate to the
language, and the clear technical superiority of open source is well shown
by Forth. However, what is also well shown in the Forth world is that this
is a marketing problem. In order to make money on Forth one must
dysfunctionalize it somehow, in order to maintain the distinction between
developer and user, which is a distinction that is meaningless to Forth
itself. Otherwise a vendor can not remain "the vendor", which is of course
utterly unpalatable to many potential vendors, and so is not good for
Forth in the marketplace.
As an attempt to address these problems, and as an absurd attempt by one
guy to reinvent an entire complete microcosm, the Linux/GNU/unix world,
the existing features of cLIeNUX are created or chosen to show how things
might go if open source works could be almost automatically of some
material value to the authors of them.
IN cLIeNUX Core
cLIeNUX has lots of text documentation.
cLIeNUX Core includes help entries for "C" and "programming". I think
this is illustrative of the fundamental difference in motivation between
cLIeNUX and other distros/OSes.
The docs are mostly html, and have a lot of cLIeNUX content, edits,
hyperlinks and notes.
cLIeNUX docs are "fuzzy", and have numerous not necessarily pertinent
tangential references, since there's no telling what exactly is tripping
up the user.
Most high-level directories have an ABOUT file, explaining the usual
contents of the directory.
cLIeNUX is default configured for client-side end-user use of the Internet
cLIeNUX is geared for one user with unlimited (root) priviledges.
cLIeNUX comes with an ANSI Forth, GForth. A Forth may be assumed to be in
cLIeNUX whereas vi, C++, groff, X, and some other normally assumed unix
things are not present in Core.
"cLIeNUX Core" can rebuild and modify itself. That is, cLIeNUX Core is
based on "can rebuild itself" being the definition of a complete base OS.
cLIeNUX is very pro-active about informing you of things. Defaults,
starting with the shell prompt, are very verbose.
There is a "tour" command to give you a tour of cLIeNUX and point out
some unix fundamentals.
The Dotted Standard File Hierarchy and the cLIeNUX default file/directory
names are geared for user-friendliness and simplicity. X goes in /suite/X,
There are several standard utilities that are modified only slightly in
cLIeNUX so that thier inate unix interoperability will be enhanced, rather
than discarded. The GNU Bash shell is modified to produce its own help in
response to the internal "shelp" command, so that the string "help" can
be a more general command. The docs provided are for ash, heavily edited,
which represents a subset of the functionality of Bash. GNU man2html is
modified so that cLIeNUX seedocs can reside in cLIeNUX as html, rather
than depending on being rendered as html from *roff source as a plugin to
the man command, removing the need for *roff support and the man binary.
The ed editor is modified slightly to have a quantum of verboseness, so
that it may be possible to get somewhere with it without studying the docs
for it first, and so that certain error messages are more informative. The
"binary editor" bpe is updated in functionality and renamed to binedit.
Various standard utilities have user-friendlified default names, although
the traditional names remain in $PATH in alias directories. grep == scan,
cat == get, file == sniff, and so on. The tr command has been given 3
alternative names, pluck, squeeze and exchange, reflecting it's three
basic modes. Normal tr is a classic example of what a Forth programmer
would call "poor factoring".
Everything in cLIeNUX, including the kernel, has been modified or checked
to support the Dotted Standard File Hierarchy.
There are a number of utilities in cLIeNUX Core that aren't in other
distros at the core or base-install level, that reflect an emphasis on
do-it-yourselfism and modularity: the fonter console font editor; the
netcat general-purpose networking implement; the sc spreadsheet is in Core
rather than being a separate package; Lynx, default-named "browse", is in
Core; the SVGATextMode utility; the dcon "modem script utility" and
programming language; pppsetup; the EPIC Internet Relay Chat client and
the splitfire script for it; the zgv console picture viewer, default-named
"view"; renames, slrn, suck, Pico, and I forget what else.
There are a number of utilities, mostly written by me, that serve thier
various inate purposes, and also serve as examples of programming in C,
shell, Forth, awk, m4 and dcon: "tour" is a shell script that demonstrates
a lot of cLIeNUX features; "see" is a shell script that calls Lynx on
cLIeNUX "seedocs", which replace the "manpages" and man; "slice" is the
feature dd almost has that I needed for 11 point console fonts; "DSFHed"
and friends are how Linux gets converted to the cLIeNUX directory
structure; "ppp-on" is my dcon modem script; "comments" is the feature cpp
doesn't have, "just output the comments"; "charts" is a dcon script that
prints guitar fingering charts; H3sm is a Forth-like language I'm working
on; "pixslinger" is the beginnings of a console paint program; "xart" is
my version of XPaint ( in X); kandinski is a Forth utility that makes
images from MIDI files; the bonkers.Fs suite of Forth words for IO port
and peripheral bus exploration, especially MCA Bus and XGA cards; Alex
Beyn's shnetapps netcat-based Internet client shell scripts; "status" is
like the usual "top" command but as a script; "add" is a trivial adding
machine in awk; "beep" is handy for announcing the end of long jobs;
"stc" scrambles the console text colors, which may reduce fatigue perhaps;
"append" is the script I use to keep tabs on built kernels;
find_the_modem, count, hits, and I forget what else.
cLIeNUX may come with a kernel with the hard-realtime rtlinux patch by
the time you read this.
cLIeNUX is built on PS/2's, with sincere thanks to Charles Lasitter of
Durham, N.C. This keeps cLIeNUX in a bit of a platform-independant mindset
for a distro that is only for x86 CPUs so far. cLIeNUX "packages" will be
sourcecode only, although X may have an "XCore" or something.
Notably absent from cLIeNUX Core
*roff, except the troff calls in libc that happen to be sufficient to run
man2html; C++, gcc comes with the C cc1 binary only; libstdc++, which
*roff wanted; vi, which is replaced by Pico (edit) and cLIeNUX ed; most
servers; su, sudo and sticky bits; Perl; pretty-printing of any kind;
kernel modules; GNU libc2, BKA "glibc", etc.
Documentation versus Automation
cLIeNUX configuration features are mostly just docs, and hyperlinks to docs.
There are several reasons for this.
Given the above, cLIeNUX tries to make sure you are aware of what is
configured by what. /help/configuration.html is the primary example of
There's only one of me, and automating things is a huge task.
I question whether automating the configuration of all possible Linux
boxes, even x86-only, isn't provably impossible to do correctly for all
possibilities, or without making rash assumptions about what you want.
Most of the stuff that usually gets automated is stuff you should know
anyway, and will have a hard time discovering on your own.
The X Window System for cLIeNUX
Largely due to the urging of Charles Lasitter, there will be an XCore for
the next cLIeNUX, which is now in ../interim on the FTP mirrors. It
features the Mosaic webbrowser, which is a bit out-of-date but reasonably
useable and open-source, my xart version of the XPaint paint program, the
xv ("X-View") picture browser/editor, and my configuration of the CTWM X
window manager. The window manager is what implements the behavior of the
GUI in X. CTWM is very full-featured, configurable, fully documented, and
free of gratuitous bloat or dependancies. CTWM as configured in cLIeNUX
features 8 virtual workspaces, focus-follows-mouse, minimized ("tabbed")
window titlebars for minimum pixel waste and a fairly un-occludable region
at the top of the screen, per-workspace window cloning and background
images, animated window buttons, and a rich menu tree available by
clicking mouse button one outside any application windows.
In general, applications included in cLIeNUX tend to be a few years
behind what is generally considered to be the hot new must-have. cLIeNUX
stuff tends to be more mature. This is not entirely intentional. Mostly
it's about most bang for the buck. The side effect though is that cLIeNUX
may be the closest thing to active support for many of these apps or
libraries, such as Linux libc5, XPaint/xart, Mosaic, SVGATextMode, sc,
CTWM and others. There are much "nicer" alternatives to all of these, but
most are resource, dependancy and configuration nightmares, and offer only
marginal actual additional functionality. In the case of sc for example, I
don't think there's anything similar that doesn't need X, which to the
cLIeNUX view of modularity is quite unacceptable. Others may need certain
libraries, or C++, or may have a bad habit of breaking thier own legacy,
as is the case with The GIMP and GNU libc2. Also, one of Linux' great
strengths is it offers an escape from the mad rush to obsolete hardware
with bloated software. cLIeNUX is currently built primarily on 486 PS/2's,
partially for this reason. You are of course welcome to install anything
you want on cLIeNUX, but please don't bug me with problems installing the
likes of Enlightenment, KDE, GNOME, xemacs and so on. Those are the sorts
of things big companies have support departments for, and I don't use any
of them. My comparison between the GIMP and xart is "xart does the 30% of
what the GIMP does that you use 90% of the time in 10% of the resources."
and I've been told that's a fair comparison. AND, xart even does a couple
things the GIMP doesn't. That's typical of most of the apps in cLIeNUX,
compared to thier alternatives or offspring. Also, smaller apps tend to
interoperate better, particularly in unix. Orphan apps tend to be very
self-sufficient, but also quite capable of, and open to, team play.
Lots of cLIeNUX-originated material is released under the cLIeNUX
license. Much of what distinguishes cLIeNUX from other distributions is
not redistributable separate from cLIeNUX. This license is to create some
material value for cLIeNUX and its contents as a distinct open source
entity, which I believe may ultimately serve users and authors of open
source works much better than they are now being served.
Oct 17 1999