Baslinux mailing list

[3aoo-cvfd AT dea.spamcon.org]

I've just found some old emails about BasicLinux.  They pre-date
the current mailing list, so I'll include some of them here to
get them on the record:

------------------------------------------------------------------
From: ichi AT ihug.co.nz
To: arachne AT arachne.cz
Subject: Installing BASLINUX, X, and NETSCAPE 3.04 on a small HD
Date: Thu, 20 Sep 2001 17:51:33 +0000

Klaus Hameyer wrote:
> 
> how I put BASLINUX, X, and NETSCAPE onto a 120 MB 
> DOS hard drive. 

120 MB -- heaps of room.  Here's my tally so far:
---------------------------------
BasicLinux HD foundation    5meg
X (with icewm)             12meg
Netscape                    6meg
xfreecell                   1meg
C compiler                 15meg
---------------------------------
-                          40meg           

The X and C packages are the standard ones from Slackware, 
so there's quite a lot of unnecessary stuff included.  I'm 
sure they could be slimmed by several meg.
 
Cheers,
Steven
-----------------------------------------------------------
From: ichi AT ihug.co.nz
To: LifeRaft <survpc AT tmonroe.com>
Subject: BASIC vs BASH
Date: Tue, 02 Apr 2002 10:24:49 +0000

Some of you guys may remember that (a couple of months ago) 
we were playing around with BASH scripts.  Toward the end
of our "games", I wrote the following:

> My apologies to anybody who is thoroughly bored by these
> shell scripts.  But I am having tremendous fun.  Playing
> with bash scripts is almost as much fun as hacking BASIC
> on a Commodore 64.

Well, the fun hasn't stopped for me.  Until we had our little
competition, I didn't fully realized how capable BASH is.  In
the past I had automatically used sed or grep or cut or some
other external tool, rather than using a BASH built-in.  So, 
when we limited our scripts to BASH built-ins, I had to hunt
through the BASH manpage looking for new ways of doing things.
It was *very* educational.

After all that playing with BASH built-ins, it seemed to me
that anything that could be done in BASIC, could be done in
BASH.  So, I decided to give BASH the ultimate test:  an
adventure game, written *entirely* in BASH.  No sed, no grep,
no cut, no nothing.  Was it possible?  I honestly didn't know, 
but I thought it would be interesting to try.

In the early 1980s, I was an enthusiastic BASIC hacker and wrote 
several adventure games for the Commodore PET.  These were widely 
circulated and experienced a brief spell of popularity.  Programming 
an adventure game in BASIC is pretty straighforward.  BASIC has 
two-dimensional arrays to hold/access the game's data in an orderly 
fashion.  It has pretty good string handling for parsing input 
(left$, right$, mid$, len).  It has branching by number, which 
is ideal for converting a position in an array to action.  And 
it has that most *wonderful* of commands !! goto !!  My BASIC 
adventures were packed with goto's.  What power!  What convenience!  
What spaghetti!

BASH, on the other hand, lacks most of these things.  No arrays,
primitive (and obscure) string handling, and a non-branching
orientation.  And worst of all -- it has no goto.  *sob*
All in all, a pretty poor candidate for an adventure game.
(BTW, I understand that the latest BASH does include arrays; 
however, I use, and will continue to use, the older, smaller BASH).

But I decided to give it a try and see what happened.  So, for 
the last month I have been beavering away, converting one of my 
old BASIC adventures to BASH.  There were some initial setbacks 
-- like when I realized that clear, cut and sleep are not bash 
built-ins and I had trouble finding substitutes.  However, in 
the end every problem was resolved.  The BASH version now works 
perfectly (using only BASH built-ins).

I was surprised to find that BASH is just as good as BASIC for 
writing adventure games.  It is certainly different, but it is 
in no way inferior.  With BASH I was forced to use a structured 
approach.  The guts of the program is one gigantic case statement
based on verbs.  Then each verb runs its own case statement (or
something) to handle the nouns.  It is beauteous to behold --
clean and obvious.  Unlike the BASIC version, which was an 
incomprehensible tangle of numbers.

So, in the next day or two, I will be releasing Castlemaze Adventure.
Written entirely in BASH, it will run on anything that has the BASH
shell.  I've tried it on BasicLinux (naturally) and it works great.
I've also tried it in DOS with the DOS version of the BASH shell 
and it works (except that the graphic characters on the title page
come out as alpha-numerics).  It should also work on BSD or anything
else that has BASH.  Isn't there a Windows version of BASH?

Cheers,
Steven
--------------------------------------------------------------------
From: ichi AT ihug.co.nz
To: LifeRaft <survpc AT tmonroe.com>
Subject: Re: beep script
Date: Mon, 24 Jun 2002 08:34:42 +0000

Here's another version of the jig that Ron scripted for beep.
This is the data file:

---------------------rats.data-------------------------------
a 2 G 2 a 2 G 2 E 2 a 2 E 2 D 2 a 2 g 2 f# 2 g 2
a 2 G 2 a 2 G 2 E 2 a 2 E 2 D 2 a 2 g 2 f# 2 e 2
d 2 G 2 a 2 G 2 E 2 a 2 E 2 D 2 a 2 g 2 f# 2 g 2
a 2 b 2 G# 2 G 2 E 2 D 2 C# 2 D 2 G 2 E 2 D 4 a 2
G 2 a 2 G 2 E 2 a 2 E 2 D 2 a 2 g 2 f# 2 g 2 a 2
G 2 a 2 G 2 E 2 a 2 E 2 D 2 a 2 g 2 f# 2 e 2 d 2
G 2 a 2 G 2 E 2 a 2 E 2 D 2 a 2 g 2 f# 2 g 2 a 2
b 2 G# 2 G 2 E 2 D 2 C# 2 D 2 G 2 E 2 D 4 a 2 D 2
a 2 D 2 E 2 a 2 E 2 G 2 G# 2 G 2 E 2 D 2 b 2 D 2
a 2 D 2 E 2 a 2 E 2 G# 2 E 2 G 2 G# 4 880 2 988 2 880 2
G# 2 880 2 G# 2 G 2 G# 2 G 2 E 2 D 2 b 2 a 2 b 2 G# 2
G 2 E 2 D 2 C# 2 D 2 G 2 E 2 D 4 a 2 D 2 a 2 D 2
E 2 a 2 E 2 G 2 G# 2 G 2 E 2 D 2 b 2 D 2 a 2 D 2
E 2 a 2 E 2 G# 2 E 2 G 2 G# 4 880 2 988 2 880 2 G# 2 880 2
G# 2 G 2 G# 2 G 2 E 2 D 2 b 2 a 2 b 2 G# 2 G 2 E 2
D 2 C# 2 D 2 G 2 E 2 D 4
------------------------------------------------------------

And here is the executable to play the data file.
The syntax is:  play rats.data

---------play-----------
#!/bin/sh
[ $# = 0 ] && exit
set -- `cat $1`
until [ $# = 0 ]; do
case $1 in  d) f=294 ;;
            e) f=329 ;;
           f#) f=371 ;;
            g) f=392 ;;
            a) f=440 ;;
            b) f=494 ;;
           C#) f=555 ;;
            D) f=587 ;; 
            E) f=659 ;; 
            G) f=741 ;;
           G#) f=784 ;;
            *) f=$1  ;;
esac
let l=$2*75 
beep  -f $f -l $l
shift 2
done
-------------------------

Cheers,
Steven
-------------------------------------------------------------
From: ichi AT ihug.co.nz
To: Older PC and DOS Internet Forum <SURVPC AT SOFTCON.COM>
Subject: BasicLinux
Date: Fri, 03 Jan 2003 19:22:17 +0000

I've now got Opera 6.11 and AbiWord 1.02 running on BasicLinux 
(everything fits into an 80mb partition).  The X packages came 
from Slack71 (*not* Slack35) and I installed the glibc2, dxxlibs, 
ncurses, gpm, glib, gtk, zlib and libpng packages from Slack81 
(I probably could have used Slack71 for all the packages, but 
I have a Slack81 CDrom so it was easier to use that).  

The old icewm doesn't work with the X from Slack71.  Fortunately 
Slack71 has its own icewm package.  BTW, I installed X from 
Slack71 because it is smaller than the X packages in Slack80 
and Slack81.

The Opera package came from the Opera site -- I untarred it 
to /tmp and ran it from there. The AbiWord package came from 
Slack81 (/slackware/gnome directory) -- I used pkg to install
it.

The above installation works fine with the default 2.0 kernel 
in BasicLinux (but not with a 2.2 kernel -- it seems to need 
a /dev file that is not in BasicLinux).  I haven't tried any 
other X applications with this installation; however, I expect 
most gnome-compatible applications will work.

Cheers,
Steven
---------------------------------------------------------------
From: ichi AT ihug.co.nz
To: Older PC and DOS Internet Forum <SURVPC AT SOFTCON.COM>
Subject: best Slackware for old PCs
Date: Wed, 08 Jan 2003 10:35:24 +0000

For several years I have been using Slackware 3.5 on 
all my PCs.  It performs well on old hardware and I have 
been very happy with it (especially after I compiled a 
customized kernel).

However, it's getting harder and harder to find libc5 
binaries (even compiling from source is often tripped 
up by something lacking in libc5).  A similar problem 
is happening with the 2.0 kernel.  Several interesting/
useful utilities are designed for 2.2+ kernels.  Moreover
the old 2.0 kernels can't access the new filesystems --
not even ext2 (most current distributions format ext2
with sparse-super by default).

So, I'm thinking it's time to move to a more up-to-date 
Slackware.  A couple of months ago, I got a Slack81 CDrom 
and installed it on my best computer, a P166 with 64mb RAM.  
The installation went OK, but I was disturbed by how sluggish 
it was.  It performed like a 486-40 running Slack35.  The 
kernel was incredibly slow and cumbersome, and my first 
minimalistic CLI installation topped 100mb.  I was feeling 
quite uncomfortable.  I had only just acquired the P166, and 
all the benchmarks indicated it should be three times faster 
than my old 486-100.  I couldn't believe that Slack81 would
weigh it down so much.

Things got better when I compiled my own kernel.  I was able
to remove a lot of junk and it now runs better.  I was also
able to cut down the size of a minimalistic CLI installation.
However, when I tried to install X, I ran into a nasty surprise:
a huge monolithic X package.  No way to pick and choose just the 
necessary bits -- you get everything including the kitchen sink.  
Suddenly my 640mb HD (my largest) was 2/3 full.  This was looking 
bad, very bad.  I hadn't even installed Opera and AbiWord yet.

My experience with Slack81 has led me to reassess my decision to
go from 3.5 to 8.1.  Is there perhaps a Slackware between 3.5
and 8.1 that provides glibc2 and a more up-to-date kernel without
all the weight of Slack81?  I considered them one-by-one:

Slackware 4.0
^^^^^^^^^^^^^
The first Slackware with a 2.2 kernel.  Still libc5.  No go.

Slackware 7.0
^^^^^^^^^^^^^
The next Slackware after 4.0 (the big jump in version was to
give it a bigger number than RedHat :-).  First Slackware 
with glibc2.  A more mature 2.2 kernel.  Not a bad distribution;
however, it represents a big library change for Slackware and
I'd be more comfortable letting it mature a bit.

Slackware 7.1
^^^^^^^^^^^^^
More mature glibc2.  More mature 2.2 kernel.  Still has the
individual X packages.  Still uses DOS-friendly (8.3) filenames
for the packages.  This is as good as it gets.  It even has
icewm!

Slackware 8.0
^^^^^^^^^^^^^
The next version after 7.1.  The rot starts to set in.  A huge
monolithic X package.   Big jump in size of glibc2 library. 

Slackware 8.1
^^^^^^^^^^^^^
Big glic2 library.  Huge kernel (2.4) overhead.  Huge
monolithic X package.  DOS-unfriendly packages.

It appears to me that the best choice for an old 486 is Slack71
(I still recommend Slack35 for a 386 or for a 486 with 4mb RAM).
Therefore I will be downgrading my own installation from Slack81
to Slack71 and will be using Slack71 for upgrades to BasicLinux.

Cheers,
Steven
---------------------------------------------------------------
From: ichi AT ihug.co.nz
To: Older PC and DOS Internet Forum <SURVPC AT SOFTCON.COM>
Subject: Re: Which NICs do I put in BL2 ?
Date: Fri, 24 Jan 2003 19:42:26 +0000

A few days ago I wrote:
> 
> I've been working on a slim 2.2.16 kernel for BL2.
> So far I've got it down to 543kb.  I'd like to make
> it smaller still, so that 486s with 8mb RAM will be
> able to run it in a ramdisk.  

The BL2 kernel is now 512kb in size.  
--------------------------------------
Slack81 bare.i (2.4.18) kernel  1061kb
Slack71 bare.i (2.2.16) kernel   735kb
BasicLinux 2.0 (2.2.16) kernel   512kb
BasicLinux 1.8 (2.0.34) kernel   464kb
--------------------------------------

Although the BL2 kernel is larger than BL1, it 
actually occupies less memory after it is booted:
--------------------------------------
Slack81 bare.i (2.4.18) kernel  2820kb
Slack71 bare.i (2.2.16) kernel  2088kb
BasicLinux 2.0 (2.2.16) kernel  1600kb
BasicLinux 1.8 (2.0.34) kernel  1668kb
--------------------------------------

Because the BL2 kernel has a smaller footprint than 
BL1, the ramdisk version of BL2 will probably run OK 
in 8mb RAM.  The only cloud on the horizon is the BL2
libraries (glibc2.1) -- they are so much larger than 
the BL1 libraries (libc5) that I'll need to do some 
heavy trimming somewhere.  At this stage, I'm planning
on dropping all the vgalib stuff and IP masquerading.
I'll probably also need to use more mini-binaries (like 
the busybox versions of ftp and telnet).  However, the 
full versions of bash, links and nano will remain --  
they are too important to trim.  

Cheers,
Steven
----------------------------------------------------------
From: ichi AT ihug.co.nz
To: Older PC and DOS Internet Forum <SURVPC AT SOFTCON.COM>
Subject: BasicLinux
Date: Thu, 06 Feb 2003 03:47:00 -1300

BL2-alpha is ready for release.  I'll play with it for
a few hours more (just to make sure I have caught all
the obvious flaws) and upload it tomorrow.

Now that BL2 is ready, I'm very interested to see how
it compares to BL1.  So, I've just done a quick comparision 
between BL1 and BL2 (using exactly the same hardware:
486dx66 mem=8M).  The results are encouraging:

                              BL1             BL2
----------------------------------------------------
BOOT TIME                    14 sec          17 sec
----------------------------------------------------
This is a reasonable result for BL2.  It's a bit slower
than BL1, but not too bad.  Afterall, the BL2 kernel is
larger so uncompressing and installing it is going to 
take more time.  Also, when it is finished booting, the
BL2 kernel takes time to reassesses its memory allocation 
and frees up unneeded memory.  This leads to the following
surprising result:
----------------------------------------------------
MEM FREE                      260kb          272kb
----------------------------------------------------
BL2 actually has a slightly smaller memory footprint.
This was measured immediately after logging in, so
nothing much is happening.  Once the user actually tries
to do something (using the larger binaries in BL2) any
memory advantage is likely to disappear.  So call this
one even.
----------------------------------------------------
GZIP 4MB FILE ON C:          2:38 min       2:53 min
----------------------------------------------------
As you can see, gzipping on a 4mb ramdisk is hard work.
With little temp workspace available, gzip has to process
very small chunks of data.  This is a considerable burden.  
On a normal size filesystem, gzip would only take a fraction 
of that time.  Anyway, it's a useful comparision:  a small
win for BL1.
-----------------------------------------------------
GUNZIP THAT FILE              23 sec         16 sec
-----------------------------------------------------
A clear win for BL2.  Something interesting happened here.
A more efficient kernel routine, perhaps?  Or maybe some
speed advantage in glibc2?

The overall conclusion is that users will notice little speed
difference between BL1 and BL2.  A few seconds longer on some
things, a few seconds less on others. 

Cheers,
Steven