Why Linux and open source sucks

  • Thread starter Thread starter Mike
  • Start date Start date
Heh, its generally not worth paying much attention to posts like this.

I know - I don't feel trolls, either - but this was just so blatantly
wrong and without any basis, it *HAD* to be countered.
I should also note, because you didn't and the OP might care, the minix
kernel was free and the subject of a book by its writer.
Click to expand...

Andrew Tanenbaum's "Operating Systems: Design and Implementation" - a
classic.

Marc
 
Marc Scheuner said:
I know - I don't feel trolls, either - but this was just so blatantly
wrong and without any basis, it *HAD* to be countered.


Andrew Tanenbaum's "Operating Systems: Design and Implementation" - a
classic.
Click to expand...
Ya, thats right!...I've read(and own) the second edition, which someone else
apparently did the editing and additions to make it a second edition. I just
can't find it, LOL.
 
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.
Click to expand...

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.
 
Mike,
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.
Click to expand...

I understand what you're saying. Although I have a different spin on a similar
concept. I've thought some about the fact that a componentized operating system
could easily support access via networking protocols - like remoting in .net but
on localhost or in-the-box (or nearby) network connections accessed via fiber.
For example.

I don't see any reason why an operating system must exist on a single
motherboard directly controled by one or more processors.
 
What we need is an OPEN CPU architecture so we can remove the dominance of a
single chip vendor.

Where is the open community regarding this? nowhere to be seen, therye too
busy infighting. Opensource is as fragmented as unix is.

C# is an ECMA standard, but the runtime isnt and neither is the Libraries.
 
+0200, "bwahahahaha" <[email protected]>,

"+0200" eh? Do I know you? :-)
What we need is an OPEN CPU architecture so we can remove the dominance of a
single chip vendor.
Click to expand...

The only reason there is a cpu monopoly on the desktop is because the OS demands
one. MS and Intel are joined at the hip.
Where is the open community regarding this? nowhere to be seen, therye too
busy infighting. Opensource is as fragmented as unix is.
Click to expand...

And it's only going to get worse as groups struggle to control the generation of
income.
 
Back
Top