3 ms·

Of course you can build things on top of files. But most people don't, they use files directly, and therefore get "bullied" (which I think is a very apt term) i

• eternalban 5y ago
  The GP I replied to starts with "I've been working in the collaborative editing space for a decade now (!)" and claiming a network interface somehow magically does something that an FS can not (and speaking of Unix, entirely ignoring that both mechanisms use file descriptors). I mean, what to make of statements such as "[t]he problem is there's no obvious place on the filesystem to put that [meta-data] information"? As for the generic "application programmers", possibly you are right, and doing 'literal' mappings between their memory and persistent models is to be expected.
  • rvense 5y ago
    > [t]he problem is there's no obvious place on the filesystem to put that [meta-data] information Well, there isn't, except the file itself. I.e. you build a protocol on top of it.
    • eternalban 5y ago
      Yeah, just like "web based" systems use a protocol to shuffle bits around. So an FS will in fact support building higher semantics on top of files and folders, and a visit to your local .git directory will provide an example of a contemporary popular tool that does precisely that. Now possibly the GP is upset that random app A can't just use the files spit out by app B, which is as reasonable an expectation as having random client C use a universal driver to talk to various servers.
      • josephg 5y ago
        The problem isn’t that doing this stuff is impossible. It obviously is - databases work well. The problem is the point of interoperability between applications in Unix is the file. It’s not the database - applications don’t pass data to each other via Postgres. The pass data with files. And that means if you want multiple programs (eg, a 3D modelling program and git) to share information, the way they do so is by the modelling program saving flat files and git reading them (and diffing them). That just isn’t very good. We can work around this on a per application basis. My code editor could output all the changes to a custom SQLite database. But then it won’t work with all the other tools on the system. I can't use grep or awk. I can't use git properly. We end up with isolated bundles bits that can't easily be used together. Doing that goes against platform conventions. It’s not the Unix way. So people don’t do it. And as a result, for interoperability reasons applications don't save their data to databases. They use flat files, hope nothing gets corrupted and discard data about changes. The reason isn’t technical. It’s because conforming your software to the platform convention is what people want. I want to be able to just copy my data to a usb key without thinking about postgres's data format and extraction tools. There's a parallel in programming. Languages define common types - like strings. But they don’t need to. Rust could leave the String implementation details to 3rd party crates. The problem is if they do that, libraries wouldn’t be able to share strings easily with each other because they might each be using a different string data type. So standard APIs would probably avoid strings whenever they can. This is the problem we have on Unix. There’s no interoperable, platform-standard way to store changes on disk. So all the apps I use don’t. When git needs change feeds, it’s forced to use diff-match-patch instead. But it’s not as good: You don’t get real-time feeds. And it doesn’t work properly with non-text data. Conflicts are unavoidable. And patches are non canonical. You’re right - we can solve all this on a per application basis. I don’t want individual apps to have their own hand rolled data silos and their own crappy git replacements. I want a platform where those tools work with any kind of data. Even with apps that haven’t been written yet. That’s the Unix way. I love the filesystem. I just think that after decades of experience we can do it better.