1. 21
  1.  

  2. 9

    I just quickly skimmed through the article and I have some issues with it.

    one cannot rm /proc/1024 to kill the process

    Okay, let’s say I can do this; that is, rm /proc/1024 is equivalent to kill 1024, which sends SIGTERM. How would I send the dozen other signals? Importantly, how would I send SIGKILL? You may say that we don’t need SIGTERM and SIGKILL separately, but we do; SIGKILL is handled by the kernel and it does not permit the process do anything. SIGTERM signals the process to terminate, which would allow it to do some cleanup work (like closing files). Without this distinction, it’d either be impossible to safely terminate processes or predictably terminate misbehaving processes. Given that we have different signals to send, how would that work in a “database engine”? A echo SIGKILL >/proc/1024/signals? Is that any different from kill -9 1024? In fact the latter is much nicer.

    one cannot ls /proc/1024/open_files to see the list of all open files for this process

    you can, though.

    $ tty
    /dev/pts/1
    $ touch /tmp/file
    $ tail -f /tmp/file
    

    separately,

    $ tty
    /dev/pts/2
    $ ps -A -o pid,cmd | grep tail | grep -v grep
      899 tail -f /tmp/file
    $ ls -hal /proc/899/fd/
    lrwx------ 1 adtac adtac 64 Aug  8 23:04 0 -> /dev/pts/1
    lrwx------ 1 adtac adtac 64 Aug  8 23:04 1 -> /dev/pts/1
    lrwx------ 1 adtac adtac 64 Aug  8 23:04 2 -> /dev/pts/1
    lr-x------ 1 adtac adtac 64 Aug  8 23:04 3 -> /tmp/file
    

    Much (if not all) of the system configuration can be set up by opening a resource and toggling a few buttons, retyping strings or adjusting colors. 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.

    No, you still need to do all of that processing. With a “database engine”, one would have to talk to a different process in the system with IPC, which is way slower. And even after you get the data, how are you going to validate it? For example, a config’s value may be an email address. But if it’s empty, for example, it’s an invalid value that should be caught at config parsing time.

    Besides, trying to save cycles on configuration parsing is premature optimisation at its finest.

    list of all processes belonging to user joe can be found faster by a database query rather than with ps aux | grep joe

    You can just do this, which is just as simple as a “database query”.

    $ ps -a -u joe
    

    Really, read the ps documentation. ps aux isn’t the only way to invoke the utility.

    The universal database would also allow linking of an #include file directly into an includee; this will obsolete the arcane art of specifying compiler’s -I and -L flags and trying to predict which of several possible time.h files the compiler would actually pick.

    How does having a “database engine” solve this?

    1. 4

      Okay, let’s say I can do this; that is, rm /proc/1024 is equivalent to kill 1024, which sends SIGTERM. How would I send the dozen other signals?

      In Plan9, which took “everything is a file” much further than unix, they have process control files. So you echo kill > /proc/pid/ctl. You say that kill -9 is much nicer, though I can’t understand why – plan9 requires fewer commands to learn, a simpler cognitive model (you do everything by manipulating files), etc.

      You can just do this, which is just as simple as a “database query”.

      Again, it’s not. It’s a separate command. And unix/linux/etc commands are riddled with inconsistencies in its various flag arguments. If you have a single query language that can be applied across all system operations, that lowers the learning curve dramatically.

      And ps is honestly a terrible example since it has two entirely different sets of flags for the same operations (SysV vs BSD). It’s a very tough command to learn, and once you learn it you’re very likely to stick with only half of the available flags.

      How does having a “database engine” solve [include directives requiring library paths]?

      Well, let’s look at how BeOS/Haiku does it. It’s fairly simple, as long as you’re not doing conditional #includes.

      -> addattr -t string META:include /path/to/foo.h bar.c
      

      Then a compiler could use that information when building bar.c instead of requiring flags or environment variables defining a search path. I personally think it would be more useful if there were a “file” type, separate from the “string” type, that updated if the file moved, but that’s a whole other problem.

      In short, both “everything is a file” (including GUI elements, etc) and “the filesystem is a database” have been implemented in open-source OSes before (plan9 and Haiku, respectively). I encourage you to read up on how they solved the problems you perceive with the concepts.

    2. 7

      one can tell the Finder: “here, this is a list of files, manage it as you usually do with a list of files, just tell me when you are about to trash something.”

      This sounds suspiciously like fuse to me. When I made x11fs[1] I quickly arrived at the conclusion that aiming for one unified abstraction for every concept in an OS might actually not be the best idea, and sometimes it’s best to use the right abstraction for the job, rather than shoehorning interfaces to be file or db based etc.

      [1] https://github.com/sdhand/x11fs

      1. 6

        tldr: everything is a DB entry.

        I guess, compared to everything-is-a-file, a DB could be a regulated and formatted way of storing information. Instead of millions of file formats/types, you end up with millions of DB schema. I’m not sure if this is going to help.

        1. 7

          Didn’t BeOS already do this 20 years ago…?

          1. 6

            Note this article is from 1996 or earlier. The idea was definitely in the air.

            1. 4

              It really irks me when documents like this have no dates attached to them.

              1. 3

                I did not know that. Thanks!

                edit: oh wow, that site’s a treasure trove

                1. 1

                  The year should be in the title, really.

                2. 4

                  Haiku has reimplimented it.

                  It’s a cool idea. It means that many apps become easier. An mp3 player, for example, doesn’t have to keep a precompiled database of parsed mp3 tags, it can instead offload that work to the filesystem (once those tags have been turned into file attributes). It also means you can have it play “all mp3s on the disk”, rather than building lists of music directories, etc. It can be a remarkable toolset for an application developer.

                  In fact, IIRC, the Haiku addressbook app uses files that have no content, only attributes. The file name is the contact name, and everything else is added through database operations.

                  1. 1

                    Even Microsoft took a crack at the idea in the early 00’s.

                  2. 4

                    Many mainframe operating systems have record-oriented filesystems. https://en.wikipedia.org/wiki/Record-oriented_filesystem

                    1. 2

                      ls providing a list of files means you don’t have to call with certain flags to get the information you want.

                      It also means that you don’t have to make sure every tool includes a “parse input” and “format output” layer, since there’s already some structure (this doesn’t rule it out entirely but it means you can survive without it)

                      I bet a lot more people would be OK doing ops work if you could operate with tools at the same level as most development work

                    2. 2

                      It would be interesting to consider how “everything is a database” intersects with “everything is online”, which is what we have today. How could I work with resources which are not on my machine? How could I manage information which I find online – annotating it, integrating it with other local and non-local bits of information?

                      1. 2

                        This sounds a bit like the Canon Cat (wherein everything is part of a single, perpetually-open text document, most navigation is built on searching, and even code is contextualized as part of the document in which it is embedded).

                        Alternatively, the author may want to look at the OS of the Cambridge Z88 (the last machine to be produced by Sinclair, albeit not with the Sinclair name). It has an interesting way of combining text documents with spreadsheets & making the same operations apply to both, reusing special column-overwriting rules for layout purposes. (The Z88 has other interesting UI features as well…)

                        1. 1

                          This would be great for efficiency and consistency, but on the other hand I can see this stifling application innovation. Framebuffers allow application developers the flexibility to do whatever they want.