Re: Future of ELKS

[Miguel Bolanos <mike@linuxlabs.com>]

Greetings,

On Thu, 2004-05-20 at 07:40, Pat Gilliland wrote:
> Very Large Caveat: I am an "end user" rather than a "developer" so all I
> can offer is help with documentation and very sincere thanks to all of you
> who have helped keep ELKS going.
> 

Great, we need doc writers :)

> My wish list for ELKS would include:
>       a comb image that continues to a 720 floppy.
>       an easy way to install from a (720) floppy to hard drive.
>       some sort of modem support .
> 

Noted.

> Now as for the future - a few questions. 
> What is the realistic future of the 8088 architecture?  
> Are there really enough machines left in existence to give ELKS a practical
> purpose, or will it remain the play thing old hardware addicts?  I suspect
> that even in the third world the 8088 as hardware is dead. 
> 

Well the charm of ELKS is that even though it is intended to be used on
8086 / 8088 and similar hardware, it doesn't necessarily need to be
loaded on "playing" old boxes.. but actually be applied to real
production stuff, my main example would be NASA's flightlinux.
Now i really thing that such hardware is not dead at all on the 3rd
world, in fact a few days ago i received an email from a Journalist in
London, willing to make a video-story about ELKS, and the benefits that
it can provide the 3rd world.

> A few thoughts from un-educated user space:
> 
> As I recall, the 386 (or was it 286) or better can run a number of
> applications as if they were on seperate virtual 8086 machines.  Could this
> be of use to simulate large clusters on a single box?  Could a number of
> virtual machines be used to simulate network topologies with ELKS virtual
> boxes, ELKS based virtual routers and switches and ELKS based 
> "compromised" virutual machines.

Doing such kind of cluster is actually in my _PERSONAL_ Todo list, but
as many other things in it.. if others are interested i'm open to do
team work :)

> 
> Related to virtual clustering, can the limited overhead and size of the
> ELKS kernel be used to advantage somehow?  I'm thinking that a light weight
> kernel would allow more resources for applications - use a smaller engine
> to get more room in the passenger compartment.  
> 

Even if we have a light kernel.. we will still require various nodes
(maybe 10) for the cluster to actually do useful things (my personal
thought)

> ELKS as I remember,  was intially designed as an easier to understand
> version of linux.  Should ELKS be kept intentionally simple as a kernel for
> "student" use?
> 

This is something that can be seen from different points of view... 
In one side we have current elks kernel.. its small, easy.. simple.. but
if you are for example willing to get started with elks to get enough
knowledge to then start contributing to the linux kernel, u will end up
with the surprise that the coding style on both is very different...
I started working on re-writing elks kernel code to be compatible with
regular linux kernel, this will still be of great educational use, for
the fact that it will not be compatible with the coding style, but also
will be small enough to understand by people interested in learning it.

> Can ELKS be used as a sort of nano-kernel used in keeping with the UNIX
> ideal of creating simple inter-connectable tools?  I am way out of my depth
> here, but my understanding is that some things work better in kernel space
> than user space so would it be of any benefit to run applications each with
> their own kernel?
> 

I'm more a candidate of user-space, but i guess others in here might
disagree with me, if it is the case, PLEASE lets us hear you :)
 
> Can ELKS be worked onto ultra-portable devices such as USB storage keys and
> watches? Yes I realize that these devices do not in general currently have
> processors but with modern chip techniques it should be simple to tuck an
> 8088 into some corner of the mask.  One could say browse to the files on a
> keychain rather than having to mount and read it.  Reduce the form factor
> further and you could have httpd on a business card to serve up your
> resume, business website or what ever,  just plug it into an ethernet port
> and it's there. To extend the idea - a tiny machine that serves data for a
> specified number of times then rm -rf * 's it with no possiblity of user
> intervention.  It could also incorporate onboard encryption and DRM - damn
> there goes my soul straight to hell.   Limited play video, audio or any
> other data you want. Take your key down to the video store and load up a
> movie that deletes itself as it plays leaving an empty key for reuse.  Yes
> I'm drifting off topic so lets just call it "prior art" and leave it that.
> 

Nice ideas.. this should be taken in consideration for EDE.
Neil would you please comment a bit here? 

> For the gamers, what about a video card with one ELKS processor _per pixel_
> - it may not be at all efficient but would probably sell just for the
> bragging factor.
> 

mmm.... This should be included on the notes to consider it once we get
a stable release of the kernel and ede.

> An finally, I must admit it would be satisfying in a very twisted way to
> make a beowulf cluster out of my two old laptops connected over a serial
> link.
> 

I'm looking forward to something like this too... please hang around,
and let us keep hearing from you... even join us on irc... Many things
can be done with ELKS... but to do this we need many kind of people...
coders, doc writers.. people giving feedback :)

I can tell that i feel very satisfied with the fact that many people has
provided feedback... this ensures me that elks still has long road to
go, and that the work that we all are doing is really worth it.

best wishes

Mike

> Pat G. 
> Patrick Gilliland
> InkPot Productions
> www.inkpotproductions.ca
> (613) 722-1439
> Sent using cyberus.ca WebMail - http://www.cyberus.ca/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>