cLIeNUX FEATURES, Oct 1999

background

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, for example.
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.

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.

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 this approach.

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.

The Orphanage

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.

Licensing

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.

Rick Hohensee
Maryland
Oct 17 1999