4 ms·

This is a super nice idea. I wonder what other software we could interact in this form. The Unix people did have a good point about everything being a file.

by guax 4y ago

behnamoh 4y ago
> The Unix people did have a good point about everything being a file. Yes and no. While it simplifies things to an extent, it's also confusing, especially with extension-less files. Example: Tell me, is this a file or directory? ~/hn/today-posts It could be a file that curls todays posts, or it could be a folder (directory) that contains them.
- sva_ 4y ago
  The terminal emulator may change the color of the prompt, for example.
- yegle 4y ago
  How would adding an extension solve the issue? E.g. is this a file, a device file, or a symlink? /dev/readme.dev To know what this is, a `stat(2)` is required.
- crabbone 4y ago
  Valid complaint, but maybe not such a great reason. It gets worse when you deal with sysfs or procfs and similar. It all becomes obscure magic, like what values can be written into what file, why some files aren't readable, or the contents of files being just a bunch of numbers which you have no way of interpreting. Another problem is that there's way too many of different file types and they aren't organized into any kind of hierarchy or any other meaningful order. This makes tools like rsync extremely complicated, with loads of footguns and still not solving the problem well. It feels especially bitter because in exceeding majority of cases you don't want tools like rsync to deal with named FIFO or device files or sockets etc. but you get accidentally but painfully bitten by them every now and then.
- drdaeman 4y ago
  > Example: Tell me, is this a file or directory? A directory is a file (and IIRC e.g. Plan 9 decided they should be readable just like normal files and there shouldn't be any special readdir syscalls). You can see its attributes to figure out the rest. If not for strong Linux limitations (because of alleged hardlink knot-tying problem) and belief that it just cannot be both, transparent archive access through a filesystem would be a thing. As well as metadata access (`play ./file.mp3` vs `edit ./file.mp3/id3v2`). People of the past seemed to have paid great attention to interoperability and effort to make common interfaces; folks of the modern age ('00s and later) love unique and completely incompatible solutions to the same problem.
  - christophilus 4y ago
    Neat. I’ve often wished I could cat a directory or ls a file. Plan9 sounds like something I would have enjoyed using.
    - enriquto 4y ago
      > I’ve often wished I could cat a directory This was possible in the beginning. But then came the moral police and deprived us of this freedom, because they deemed it to be "confusing". See, for example, The Unix Programming Environment, by Kernighan and Pike, page 51 [0]: Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. (...) The time has come to look at the bytes in a directory: $ od -cb . [0] https://archive.org/details/UnixProgrammingEnviornment/page/n61/mode/2up https://archive.org/details/UnixProgrammingEnviornment/page/...
- dredmorbius 4y ago
  'ls -l' will tell you the basic information of a given listing, including whether it's a normal file, directory, symlink, block device, named pipe, etc. stat(1) will provide additional information on a file. file(1) will not only distinguish between filesystem=level distinctions, but will make a remarkably good guess as to what the file contents of a normal file are, based on magic(5).
jbverschoor 4y ago
Any database: cat /mnt/imdb/movies/tt0103064/director/details.json cat /mnt/imdb/actors/by_contains_name/arnold/roles.csv Or any graphql source
- pmoriarty 4y ago
  GraphiQL.... what a fucking nightmare
pmoriarty 4y ago
Plan9 takes this even further
yjftsjthsd-h 4y ago
One source of inspiration is to see what the Plan 9 folks did, plus things inspired from that - filesystems for network access, for the clipboard, for representing windows on the screen. I've also been considering some sort of filesystem for MQTT, which combined with an appropriate bridge would allow for reading and control of assorted smart devices as a filesystem.
layer8 4y ago
The file interface is somewhat limited though (e.g. everything is just an opaque untyped byte stream) and has security issues in conjunction with shell scripting (e.g. quoting and escaping). A data type aware interface like AppleScript or COM, if universally supported, would be more expedient.
- enriquto 4y ago
  > The file interface is somewhat limited though And so? The mantra says "everything is a file", not "everything is only a file". You can provide stream access to everything, and then more advanced access to some particular resources.
  - layer8 4y ago
    The problem is that everything below the file surface is proprietary, so to speak, and that the file interface doesn’t give you a standard way of discovering the file format or (for command pipes) the commands it understands. What’s missing is a standard way of querying schema information about files/pipes. In addition, like in the TFA use-case, not just individual files have schemata, but whole directories and directory trees have. Those are not communicated by the file system, but have to be known out-of-band for each specific purpose. Providing just a generic interface cuts two ways: On the one hand, you can represent anything, but on the other hand, you don’t know what anything represents without additional information (metadata).
yesenadam 4y ago
I loved this talk by Omar Rizwan from !!Con 2018 on that topic: Four fake file systems! (9 mins) https://www.youtube.com/watch?v=pfHpDDXJQVg https://www.youtube.com/watch?v=pfHpDDXJQVg i.e. screenshots, torrents, youtube, git.

This is a super nice idea. I wonder what other software we could interact in this form. The Unix people did have a good point about everything being a file.

by guax 4y ago

This is a super nice idea. I wonder what other software we could interact in this form. The Unix people did have a good point about everything being a file.

behnamoh 4y ago

> The Unix people did have a good point about everything being a file. Yes and no. While it simplifies things to an extent, it's also confusing, especially with extension-less files. Example: Tell me, is this a file or directory? ~/hn/today-posts It could be a file that curls todays posts, or it could be a folder (directory) that contains them.

sva_ 4y ago
The terminal emulator may change the color of the prompt, for example.
yegle 4y ago
How would adding an extension solve the issue? E.g. is this a file, a device file, or a symlink? /dev/readme.dev To know what this is, a `stat(2)` is required.
crabbone 4y ago
Valid complaint, but maybe not such a great reason. It gets worse when you deal with sysfs or procfs and similar. It all becomes obscure magic, like what values can be written into what file, why some files aren't readable, or the contents of files being just a bunch of numbers which you have no way of interpreting. Another problem is that there's way too many of different file types and they aren't organized into any kind of hierarchy or any other meaningful order. This makes tools like rsync extremely complicated, with loads of footguns and still not solving the problem well. It feels especially bitter because in exceeding majority of cases you don't want tools like rsync to deal with named FIFO or device files or sockets etc. but you get accidentally but painfully bitten by them every now and then.
drdaeman 4y ago
> Example: Tell me, is this a file or directory? A directory is a file (and IIRC e.g. Plan 9 decided they should be readable just like normal files and there shouldn't be any special readdir syscalls). You can see its attributes to figure out the rest. If not for strong Linux limitations (because of alleged hardlink knot-tying problem) and belief that it just cannot be both, transparent archive access through a filesystem would be a thing. As well as metadata access (`play ./file.mp3` vs `edit ./file.mp3/id3v2`). People of the past seemed to have paid great attention to interoperability and effort to make common interfaces; folks of the modern age ('00s and later) love unique and completely incompatible solutions to the same problem.
- christophilus 4y ago
  Neat. I’ve often wished I could cat a directory or ls a file. Plan9 sounds like something I would have enjoyed using.
  - enriquto 4y ago
    > I’ve often wished I could cat a directory This was possible in the beginning. But then came the moral police and deprived us of this freedom, because they deemed it to be "confusing". See, for example, The Unix Programming Environment, by Kernighan and Pike, page 51 [0]: Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. (...) The time has come to look at the bytes in a directory: $ od -cb . [0] https://archive.org/details/UnixProgrammingEnviornment/page/n61/mode/2up https://archive.org/details/UnixProgrammingEnviornment/page/...
dredmorbius 4y ago
'ls -l' will tell you the basic information of a given listing, including whether it's a normal file, directory, symlink, block device, named pipe, etc. stat(1) will provide additional information on a file. file(1) will not only distinguish between filesystem=level distinctions, but will make a remarkably good guess as to what the file contents of a normal file are, based on magic(5).

jbverschoor 4y ago

Any database: cat /mnt/imdb/movies/tt0103064/director/details.json cat /mnt/imdb/actors/by_contains_name/arnold/roles.csv Or any graphql source

pmoriarty 4y ago
GraphiQL.... what a fucking nightmare

pmoriarty 4y ago

Plan9 takes this even further

yjftsjthsd-h 4y ago

One source of inspiration is to see what the Plan 9 folks did, plus things inspired from that - filesystems for network access, for the clipboard, for representing windows on the screen. I've also been considering some sort of filesystem for MQTT, which combined with an appropriate bridge would allow for reading and control of assorted smart devices as a filesystem.

layer8 4y ago

The file interface is somewhat limited though (e.g. everything is just an opaque untyped byte stream) and has security issues in conjunction with shell scripting (e.g. quoting and escaping). A data type aware interface like AppleScript or COM, if universally supported, would be more expedient.

enriquto 4y ago
> The file interface is somewhat limited though And so? The mantra says "everything is a file", not "everything is only a file". You can provide stream access to everything, and then more advanced access to some particular resources.
- layer8 4y ago
  The problem is that everything below the file surface is proprietary, so to speak, and that the file interface doesn’t give you a standard way of discovering the file format or (for command pipes) the commands it understands. What’s missing is a standard way of querying schema information about files/pipes. In addition, like in the TFA use-case, not just individual files have schemata, but whole directories and directory trees have. Those are not communicated by the file system, but have to be known out-of-band for each specific purpose. Providing just a generic interface cuts two ways: On the one hand, you can represent anything, but on the other hand, you don’t know what anything represents without additional information (metadata).

yesenadam 4y ago

I loved this talk by Omar Rizwan from !!Con 2018 on that topic: Four fake file systems! (9 mins) https://www.youtube.com/watch?v=pfHpDDXJQVg https://www.youtube.com/watch?v=pfHpDDXJQVg i.e. screenshots, torrents, youtube, git.