unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Nikita Karetnikov <nikita@karetnikov.org>
Cc: bug-guix@gnu.org
Subject: Re: DreamOS
Date: Fri, 22 Mar 2013 13:39:17 +0100	[thread overview]
Message-ID: <87d2urhami.fsf@gnu.org> (raw)
In-Reply-To: <87620lhb9f.fsf@karetnikov.org> (Nikita Karetnikov's message of "Thu, 21 Mar 2013 04:01:00 +0400")

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

      reply	other threads:[~2013-03-22 12:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21  0:01 DreamOS Nikita Karetnikov
2013-03-22 12:39 ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2urhami.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=bug-guix@gnu.org \
    --cc=nikita@karetnikov.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).