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
prev parent 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).