[Top][All Lists]

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

Re: DreamOS

From: Ludovic Courtès
Subject: Re: DreamOS
Date: Fri, 22 Mar 2013 13:39:17 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)


Nikita Karetnikov <address@hidden> 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?


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

reply via email to

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