l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

System oriented operating systems.


From: Alan Grimes
Subject: System oriented operating systems.
Date: Sat, 26 Sep 2009 01:23:41 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090925 SeaMonkey/1.1.18

Tonight, while I fret over my [completely] empty bank account, I want to
delve deep into the heart of operating system theory in hopes of
bringing some enlightenment to the unenlightened. If I am successful,
you will, having reading this, live in a bold new world with fewer walls
and broader horizons.

I fear that I'm already on a good many ignore lists, but I feel like
writing anyway.

The story of the system begins with that of the process. It goes back to
before processes were even processes, and computers were barely even
computers.

Q: What then, is a computer?

A: A computer is a machine that can emulate any other machine.

Q: How does it do this?

A: By executing a program.

Q: How does a program work?

A: You load it into memory, press "RUN", and a few minutes later, it
finishes and you get your result.

(skipping ahead a few years),

Q: What is this unix thing for?

A: Unix makes processing data easier than ever before. Instead of
writing programs from scratch, we have provided you with a wide (er,
bewildering, but let's not get distracted), set of program fragments
that you can use in conjunction with each other to process your data.
You can now compose your processes by creating a flow of data through
these pre-provided utilities which can perform an amazing variety of
computations and then get your result.

Q: How does this provide for real time or interactive applications?

A: Well, you can interact with the system through the command shell by
means of your teletype terminal. You may even be lucky enough to have a
video display terminal handy. Really, it's quite preposterous that a
computer could ever be fast enough to reproduce high fidelity music. The
best solution is to use a hybrid approach where you use your computer to
route analog signals through dedicated hardware.

Q: Why don't you simply set up a network of programs that will stay in
memory and process data continually?

A: There are two reasons, first the system only has 64 killobytes of
memory and cannot hold more than a few programs in memory at once. The
operating system exists to efficiently load programs into memory when
they are needed and manipulate information stored on disk. For reason of
cost, it's absurd that anyone would ever want to manipulate information
stored only in memory. Secondly, it is very difficult to write reliable
software. It is much easier to garantee that a program will do the right
thing once than it is to prove that it will work not just once but
perpetually.

Q: What if you want a computer to perpetually provide a service for you?

A: You start a loader process that consumes minimal memory. This loader
process will then load other processes at such time as their service is
required. The cost of loading processes into memory on demand is far
less than the cost of keeping many idle processes in memory.

######

That, my friends, is the story of the process. It is also the story of
why we deal with our god forsaken time-devouring operating systems
exclusively in terms of their filesystems. (Look, ma! I wasted two hours
today that I could have been using to earn money trying to get my
printer to work in Linux! Woo hoo!!!)

>>>>>>> The reason more people don't contribute more time to free
software is that they're wasting all the time they have trying to make
basic functions work... My bank troubles today have brought me to the
realization that I just can't afford not to buy and use Windows.
<<<<<<<

I hope that you can see the problems inherent in the concepts we have
been using all these years as if they were cast in iron and immutable.

I, for one, use applications such as pidgin, akregator, and seamonkey
continuously. I expect them to function reliably and efficiently for
months non-stop (They don't). The concept of the "process" does an
exceptionally poor job at explaining what these applications are and how
they work.

This conceptual shortcoming has very real practical implications. It
means that to implement advanced interprocess communications, each
application must fight with an operating system that's still trying to
emulate a computer that only runs one program at a time. I will grant
that there does, alegedly, exist a private "unix domain sockets" system
that allows these emulated single-application computers, ie virtual
machines, to communicate with one another.

I further submit, that the limitations of the concept of the process are
sorely felt by the IT community at large. This is why we see the sudden
popularity of such packages as "vmware" and such.

.... Back to Q and A mode.

Q: What do programs such as VMware do?

A: Virtualization is a second attempt at figuring out what an operating
system is. A VM host is a type of operating system that has been
re-invented so that instead of emulating a machine that executes a
single process, we now emulate a machine that emulates machines that run
single processes. Even though we don't really know what we're doing, and
this solution is far from optimal, we have chosen to put what we have on
the market because we've become too entrenched in our own assumptions to
fully understand what it is we are doing.

Q: Wouldn't it be better/simpler/more efficient to write a single
operating system that can emulate machines that can emulate any number
of machines recursively as needed?

A: Yes, I guess, but I'm too busy re-inventing Unix yet again.

Q: We tend to think of, and even write, applications that stay in memory
for a long time but the system imposes many limitations on how they can
be written and what they can do. Isn't there a better way to write
operating systems?

A: No, that's perposterous!!! You speak of absurdities. E Pluribus Unix!!

Q: On a modern desktop, isn't the organization and interactions among
the many pieces of software and device drivers more important than
what's on the disk?

A: Well, we mapped all of that to the /proc filesystem, you can figure
it out from there.

Q: But couldn't it be made more useful by realizing that you're
straining an old paradigm to encompass a new reality but failing to step
back and look at what that reality is?


A: [ fill in the blank ]


Good night.


-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]