[moron4hire]

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.

[ori_b]

Typically, if you were writing your hypothetical sql client in rc shell, you'd implement an interface that looks something like:

    <>/mnt/sql/clone{
        echo 'SELECT * from ...' >[1=0]
        cat /mnt/sql/^`{read}^/data # or awk, or whatever
    }

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.

[moron4hire]

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.

[ori_b]

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.

[moron4hire]

But if it requires understanding of a data protocol, it doesn't really matter if it's over the file system or a socket or flock of coked-up carrier pigeons. You still need to write custom user space code somewhere. Exposing it over the file system doesn't magically make composable applications, it just shuffles the code around a bit.

In other words, the transport protocol is just not the hard part of anything.

[ori_b]

It's not hard, but it's sure a huge portion of the repeated boilerplate glue. Additionally, the data protocols are also fairly standardized in Plan 9; The typical format is tabular plain text with '%q'-verb quoting.

There's a reason that the 9front implementation of things usually ends up at about 10% the size of the upstream.

[GrowingSideways]

The benefit is that you can allocate arbitrary computers to compute arbitrary things. As it is now, you have to use kubernetes and it's a comedy. Though perhaps the same in effect, there are dozens of layers of abstraction that will forever sting you.

You're thinking from the perspective of the terminal user—ie, a drooling, barely-conscious human trying to grasp syntax and legal oddities of long-dead humans. Instead you need to think from the perspective of a star trek captain. Presumably they aren't manually slinging sql queries. Such tasks are best automated. We are all the drooling terminal user in the end, but plan9 enabled you to at least pretend to be competent.

[zozbot234]

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.

[moron4hire]

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.

[zozbot234]

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.

[moron4hire]

You're frustrating me. You replied to me saying "it's basically FUSE" and then after I replied to you, you come back and say, "it's not really FUSE."

[zozbot234]

Plan 9 supports file server processes natively, and that's the part that's most FUSE-like. The full OS also has many other worthwhile features that are not really addressed by FUSE on its own, or even by Linux taken as a whole.

[moron4hire]

Like. WHAT!!!???

[smorrow]

9P is a protocol, FUSE isn't.

"Plan 9 praisers who don't actually use Plan 9" have a tendentious way of speaking, that's actually a lot like "AI slop", that Plan 9 users can instantly recognise. Telltale signs include speaking about Plan 9 in the past tense, and a belief that with Plan 9 you can somehow just strap all your computers together to get more performance or something. Because "you have 9P".

[GrowingSideways]

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.

[moron4hire]

Why would I ever consider doing that?

[GrowingSideways]

That's up to you. Why ask me?

[ogogmad]

I think you're failing to get that using a filesystem API to work with things that aren't naturally anything like filesystems might get perverse. And standard filesystems are a pretty unnatural way to lay out information anyway, given that they force everything into a tree structure.

[moron4hire]

This is what I was trying to get at. A lot of the data I deal with is directed, cyclic graphs. Actually, I personally think most data sets we care about are actually directed graphs of some kind, but we've gotten so used to thinking of them as trees that we force the metaphor too far. I mean, file systems are an excellent example of a thing we actually want to be a graph but we've forced into being a tree. Because otherwise why would we have ever invented symlinks?

[GrowingSideways]

There's a bunch of literature about accessing graphs through tree lenses. I'm not sure exactly what you're looking for.

SQL certainly forces you to look at graphs as trees. Do you have an specific interface you're trying to access? If you're trying to use a graph database, why mention APIs and SQL?

[GrowingSideways]

I just assumed they wanted to interface with existing json over http apis rather than write their own code. The sibling of my previous comment addresses that concern.