Comment by moron4hire
8 hours ago
You're going to have to explain to me how a parametrized request/response system like calling a Web API or making a SQL query can be mapped to reading files. I've seen some stuff that people do with FUSE and it looks like ridiculous circus hoop jumping to making the Brainfuck-is-Turing-complete version of a query system. We have syntax for a reason.
Plan9 allows for implementing file servers in user space and exporting a whole file tree as a virtual "folder", so it's really more of "everything as a file server". No different than FUSE, really.
From what I've seen, Plan 9 fans turn their noses up at FUSE. They say FUSE is not "it", but don't really seem to explain what "it" is to differentiate it from FUSE.
And as Feynman said, you don't truly understand a thing until you can teach it. So that leaves us in a weird predicament where the biggest proponents of Plan 9 apparently don't understand Plan 9 well enough to teach it to the rest of us.
It depends what you mean by "it". FUSE clearly doesn't give you every feature in plan9, and in fact you can't have that without giving up the current Linux syscall API completely and replacing it with something vastly simpler that leaves a lot more to be done in user space. That's not something that Linux is going to do by default, seeing as they have a backward compatibility guarantee for existing software. Which is totally OK as far as it goes; the two systems just have different underlying goals.
3 replies →
Typically, if you were writing your hypothetical sql client in rc shell, you'd implement an interface that looks something like:
This is also roughly how webfs works. Making network connections from the shell follows the same pattern. So, for that matter, does making network connections from C, just the file descriptor management is in C.
This is... I don't know. I don't get why I would care to sling SQL over a file system versus a network socket.
I mean, Postgres could offer an SSH interface as a dumb pipe to psql to just have you push text SQL queries in your application. But it doesn't, it offers a binary protocol over a network socket. All the database engines have had the same decision point and have basically gone down the same path of implementing a wire protocol over a persistent socket connection.
So yeah, I don't get what doing things this way would give me as either a service provider or a service consumer. It looks like video game achievements for OS development nerds, "unlocked 'everything is a file'." But it doesn't look like it actually enables anything meaningful.
How would you connect to Postgres in 4 lines of shell normally? How would you do it for a rest api? How about any other systems?
For Plan 9, it's all the same, all using the same interfaces, with little library glue.
Opening a window, and running a command in it? Similar interfaces. Adding LSP to your editor? Got it, you mount it and write to the files.
Universal shared conventions are powerful.
2 replies →
In addition to the sibling comment, you might also consider simply not using the APIs or SQL queries to begin with. Many people have entire careers without touching either.
Why would I ever consider doing that?
That's up to you. Why ask me?
4 replies →