public inbox for linux-8086@vger.kernel.org
 help / color / mirror / Atom feed
From: "Pat Gilliland" <patrick@inkpotproductions.ca>
To: Miguel Bolanos <mike@linuxlabs.com>, linux-8086@vger.kernel.org
Subject: Re: Future of ELKS
Date: Thu, 20 May 2004 08:40:27 -0500	[thread overview]
Message-ID: <40aca73b.5ed.0@cyberus.ca> (raw)

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.

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 .

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. 

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.

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.  

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?

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?

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.

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.

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.

Pat G. 
Patrick Gilliland
InkPot Productions
www.inkpotproductions.ca
(613) 722-1439
Sent using cyberus.ca WebMail - http://www.cyberus.ca/

             reply	other threads:[~2004-05-20 13:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-20 13:40 Pat Gilliland [this message]
2004-05-21 17:53 ` Future of ELKS Miguel Bolanos
  -- strict thread matches above, loose matches on Subject: below --
2004-05-24 13:17 BODRATO Stefano
2004-05-20 20:18 Tommy McCabe
2004-05-19 20:55 Miguel Bolanos
2004-05-20  3:39 ` I'm in Void
2004-05-20 14:47   ` Miguel Bolanos
2004-05-20 11:42 ` Javier Sedano
2004-05-20 15:15   ` Miguel Bolanos
2004-05-20 15:37     ` Eduardo Pereira Habkost
2004-05-20 16:06       ` Andrey Romanenko
2004-05-21  5:51         ` Dan Olson
2004-05-20 17:30       ` Javier Sedano
2004-05-21  8:32         ` Gábor Lénárt
2004-05-21 14:15           ` Jody
2004-05-24  9:29             ` Gábor Lénárt
2004-05-24 18:20               ` Alan Cox
2004-05-20 23:43       ` David Given
2004-05-21  1:04         ` Stefan de Konink
2004-05-21  3:39           ` Chad Page
2004-05-29 16:58             ` Gregg C Levine
2004-05-21  5:55         ` Dan Olson
2004-05-21  6:08         ` Jody
2004-05-21 13:24         ` Eduardo Pereira Habkost
2004-05-21 16:30           ` David Given
2004-05-21 16:59             ` Michael McConnell
2004-05-22 12:12               ` David Given
2004-05-22 17:29                 ` Chad Page
2004-05-21 18:38             ` Jody
2004-05-22  8:53               ` jb1
2004-05-22 17:00                 ` Chad Page
2004-05-24  9:42               ` Gábor Lénárt
2004-05-20 16:54     ` Javier Sedano
2004-05-21  5:50     ` Dan Olson
2004-05-21  9:08       ` Arnaldo Carvalho de Melo
2004-05-21 10:24         ` Alan Cox
2004-05-24 12:20         ` Gábor Lénárt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40aca73b.5ed.0@cyberus.ca \
    --to=patrick@inkpotproductions.ca \
    --cc=linux-8086@vger.kernel.org \
    --cc=mike@linuxlabs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox