Baslinux mailing list

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

James wrote:
>
> 386sx with 3MB RAM, if it will be used as an xterminal, 

3mb RAM is too little for an Xterminal.  With 3mb RAM
it swaps when you move the mouse (which is not nice).
On the other hand, 4mb RAM works surprisingly well as
an Xterminal -- minimal swapping (after initial startup).
  
Keep in mind that X has a pretty hefty footprint (even
Xvesa).  It's too much of a load for 3mb RAM (even though
3mb RAM runs OK on the CLI).    

> To act as a standalone machine with a gui, I think
> he said 386sx with 8MB RAM.  

Yes, I recommend 8mb RAM for stand-alone X.  A low-end
386 will be slow, but it will work.

> I suppose 100MB HD would be a bare minimum, if one expects 
> to use the BL3 machine as a standalone computer 

I disagree.  The current 15mb filesystem is sufficient for
many purposes.  For example, I am in BL3 right now, reading
and sending mail (which for many people is the primary
purpose of a computer).  It works pretty well, but if I 
wanted something fancier, I could install Netscape 3.04 
(which will fit into the current filesystem).

> should there be a standalone version as well as an xterminal 
> version?  

It is both.  I am currently using X standalone.  It works
fine.  I have also used it as an Xterminal.  It works fine.

> for a standalone computer, 30MB is probably way too small.  

That is certainly true for a normal Linux distro, but with
BL3 I am aiming for something much, much smaller.  In fact,
I expect over time that BL3 will become smaller still as I
find/develop smaller applications.  swm and e3pi are two
examples of what I am trying to bring together in BL3: useful 
functionality in a very small footprint.

> I looked at the uClibc page today Steven.  Are you waiting 
> for 1.0 before trying to use it for BL purposes?  

I have already been using uClibc for BL3.  However, will be
waiting for 1.0 before replacing libc5 with uClibc.

> Or maybe just the next major release, 

I suspect the next major release will be 1.00rc1

> which is supposed to break binary compatibility with prior
> versions of uClibc?

The breaking of binary compatibility was the main reason
I did not use uClibc from the outset.

Cheers,
Steven