Hello! Nikita Karetnikov <[email protected]> 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
