zane(_)abderaware.com (Zane Thomas) wrote in message news: said:
But the situation on the desktop is even more serious. Even assuming a good
idea for a componentized, secure (
http://blog.monstuff.com/archives/000102.html)
operating system, overcoming the stranglehold MS has on the desktop is The Major
Problem - IMO.
Your problem is you guys don't think big enough. New things are hard
to make
and mostly beyond our scope for the most part. Think big and outside
the box.
Let the gui ontop a 20 year old command prompts go and look ahead to
something
that's possible, but that we don't understand, and then begin to work
on it.
The new OS should be completely API based and have 4 microcode
embedded 'CPU's' which will not be called CPU's anymore. They will be
read only for the most part and offer the processing and storage in a
read only manner for the API's.
You can call these brains or logic blocks. (basically CPU with gigs of
NVRAM)
containing its own entitiy.
The new OS should be comprised of 4 API blocks on the system board:
Input - All input devices and interfaces and input from datasources
Output - take a guess
Messege - Holds user defined paramaeters
Process - the go between or messenger of the logic blocks
Since each logic block contains it's own API code embedded, you would
just
call apon the window api certain parameters and would get
instantanious
results. The Process block would hold the imediate info for the
window.
If you were to read from a database, the data connection API would hit
the database portion API portion of the input block.
Here's the thing, since you are utilizing a portion of the 'CPU'
directly and
the rest are left undisturbed, you can do another API simutaniously,
thus,
acheiving true mutlti-threading within the same or different block
because
you are not using a singular CPU, but rather thousands of small stand
alone
CPUs; each ccontaining it's own API. The API *is* the physical CPU. An
incoming
TCP/IP connection would be dealt this in the Input block which would
process
the connection with no lag time or performance hit.
WIth the right algorithems and hardware architecture, you could make
an array of say 16,000,000 concurent API's, each considered seperate
from one another
and each would be considered it's own thread with no performance hit.
This means that 20,000 users could connect to your server concurently,
each fetching database transactions from the within the same block,
with no stress on the OS or system performance because the API's are
completely different
from one another.
There would be no load times, reboots, little crashes, or viruses
becuase each API is read only in the embedded CPU microcode seperate
from one other. If the
fault dectecting management portions detect a faulty state, it can
flash power
to the API portion and re-power it. (But have does embedded code for a
LCD clock
on your watch fail much?)
See bigger than what you're used to.