DreamOS

DreamOS

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

Yesterday I read this paper [1] which describes how a generalization
can be used to boost performance and improve UX.

I don't see a way to implement anything similar without rewriting the
entire system from scratch.  But I may be wrong.  What do you think?

The store is definitely a step in the right direction.  However, there
is still room for improvement:

"Deep down, an operating system is nothing but a manager of many
databases. Indeed, a file system, the process table, routing tables,
list of known AppleShare servers, revision control system (projector)
data, Think C projects - they are all databases. Unfortunately,
despite a sizable share of common functionality and interface, every
one of them is implemented and managed separately.Why not to trade a
multitude of "custom" database managers for a single well-designed
distributed database manager?"

"However, the unification is not complete. While it is possible to open
/proc/1024 to get hold of a process with id 1024 (to find out who owns
this process and when it was created, if for nothing else), one cannot
rm /proc/1024 to kill the process, and one cannot ls
/proc/1024/open_files to see the list of all open files for this
process. Although why not?"

"The configuration of a UNIX system is specified and controlled by a
huge tangle of plain text files: /etc/hosts, sendmail.cf, syslog.conf,
inetd.conf, /etc/uucp/Systems to name just very few. .INI files on
some other systems are also plain ASCII. Even MacOS caved in a little
with a System Folder:Hosts, although it is a very isolated example on
a Mac. Note that just because symbols displayed on screen must be in
ASCII, the information stored on disk does not have to be in the same
form. Still, ASCII configuration files abound, for a very simple
reason: they can be modified with any text editor from ex and edlin
upwards, and can be viewed and created even without an editor, with a
cat command."

"There is no need to learn the syntax of a specific configuration file,
and no wasting of the CPU time on parsing that text file and reporting
errors if any."

[1] http://okmij.org/ftp/papers/DreamOSPaper.html

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: DreamOS

[Ludovic Courtès]

Hello!

Nikita Karetnikov <nikita@karetnikov.org> skribis:

> Yesterday I read this paper [1] which describes how a generalization
> can be used to boost performance and improve UX.

Nice paper.

> I don't see a way to implement anything similar without rewriting the
> entire system from scratch.  But I may be wrong.  What do you think?
>
> The store is definitely a step in the right direction.  However, there
> is still room for improvement:
>
> "Deep down, an operating system is nothing but a manager of many
> databases. Indeed, a file system, the process table, routing tables,
> list of known AppleShare servers, revision control system (projector)
> data, Think C projects - they are all databases. Unfortunately,
> despite a sizable share of common functionality and interface, every
> one of them is implemented and managed separately.Why not to trade a
> multitude of "custom" database managers for a single well-designed
> distributed database manager?"

The store is a database, containing a variety of objects, and with a
unified interface.  To some extent, it allow us to manipulate Scheme
objects–<package>, <origin>, etc.–that would ultimately be instantiated
in the cache.

> "However, the unification is not complete. While it is possible to open
> /proc/1024 to get hold of a process with id 1024 (to find out who owns
> this process and when it was created, if for nothing else), one cannot
> rm /proc/1024 to kill the process, and one cannot ls
> /proc/1024/open_files to see the list of all open files for this
> process. Although why not?"

This part would be addressed at the core level.  The Hurd and Plan 9
have some answers to this, I think.

> "The configuration of a UNIX system is specified and controlled by a
> huge tangle of plain text files: /etc/hosts, sendmail.cf, syslog.conf,
> inetd.conf, /etc/uucp/Systems to name just very few. .INI files on
> some other systems are also plain ASCII. Even MacOS caved in a little
> with a System Folder:Hosts, although it is a very isolated example on
> a Mac. Note that just because symbols displayed on screen must be in
> ASCII, the information stored on disk does not have to be in the same
> form. Still, ASCII configuration files abound, for a very simple
> reason: they can be modified with any text editor from ex and edlin
> upwards, and can be viewed and created even without an editor, with a
> cat command."
>
> "There is no need to learn the syntax of a specific configuration file,
> and no wasting of the CPU time on parsing that text file and reporting
> errors if any."

This part is somewhat addressed by NixOS, and by the future Guix-based
OS as I view it (especially with dmd [0]).  NixOS users manipulate Nix
objects that represent system services and their configuration,
including system configuration (users, networking, timezone, etc.)  That
provides a language-level unification, more than a database-oriented
unification, but I think it’s similar in spirit.

My random comments.  :-)

What about you?  Is there a particular aspect that you’d like to see
happen?  How would you imagine user interaction?

Ludo’.

[0] https://gitorious.org/guix/dmd