5 ms·

This is a bit of topic but: Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. It’s a pity that instead of

This is a bit of topic but: Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. It’s a pity that instead of improving the speed of the file system, everyone started to ignore it, hence making it’s speed even less important, and on and on... And now nobody uses the file system for these purposes.

progman 7y ago
> Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. As "dead" as Android (which is based on Linux, a Unix clone) and OSX (a BSD Unix) and iOS (child of OSX)? Why does Microsoft vibrantly support Linux in Windows 10 (an abomination to Ex-CEO Steve Ballmer) if Unix is "dead"? I think the very opposite is true. Some developers realized that the KISS principle (including the Unix philosophy where everything is a stream of bytes) is not a bad idea after all. https://blog.pragmaticengineer.com/software-architecture-is-overrated/ https://blog.pragmaticengineer.com/software-architecture-is-...
- fao_ 7y ago
  Support of Linux != support of UNIX and the UNIX Philosophy. Lennart Poettering, who is the mind behind Systemd, Pulseaudio, and a lot of major new technologies explicitly disavows the UNIX philosophy.
legulere 7y ago
The problem with file systems is that it is extremely difficult to build reliable systems on top of them. It’s shared mutable state with barely any error handling possibilities.
- pcr910303 7y ago
  > It’s shared mutable state with barely any error handling possibilities. And that makes me think about scoped file systems... (gotten the idea from global & scoped variables) Since the biggest advantage of ‘everything is a file’ is that it allows a consistent API for manipulating data, why didn’t this happen?
  - throwaway2048 7y ago
    plan9 namespaces and user filesystems along with bind mounting achieved this sort of scoping.
mmrezaie 7y ago
How do you think it should have evolved? I personaly think posix way of filesystem needs to be changed into specialized oject filesystems, but I am not sure what object filesystem for a UNIX OS should look like specially since it needs to be generalized into something all the other sub-systems can benefit from.
- pcr910303 7y ago
  Personally I also preferred the ‘Everything is an object’ from the lisp machines. However, I also believe that files are an acceptable object format, since if several applications know how to manipulate a file format, it’s basically duck typing. I believe file systems could have a more formal method to query the file’s format, and has less latency so that applications could use files as an inter communication format.
- datenwolf 7y ago
  Just have a look at Plan9.
- strictfp 7y ago
  It could have evolved into REST (which it didn't, but they're deceptively similar).
- fortran77 7y ago
  There are some things like audio where it's nice to simply copy an audio file to a /dev/audio to play audio and read from /dev/audio to record audio. That doesn't preclude having more advanced interfaces, too.
rvz 7y ago
> Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. Brings back memories of the old days of the late 1990s trying out so many workstations running obscure Linux distros to actual UNIX OSes like IRIX, Solaris and HP-UX. They all ran some variant of X11 which was part of the UNIX philosophy which I found interesting (X11 forwarding, startx, etc) but as the requirements of the desktop kept evolving over time, X11 just kept on showing its age. Nowadays, Wayland is showing promise as a successor but I really don't have time to be messing around with these .xinitrc, .Xresources or dotfiles to get HDPI working on my MacBook these days.
- alxlaz 7y ago
  The uncomfortable truth today is that, while having to touch an X config file hasn't been a thing in more than 10 years, it will take you some fiddling with your favourite Wayland compositor (of which only three -- two massive DEs and a tiling compositor -- are anywhere near being useful) just to get it to stop crashing on that one application that you need, or to get things like multiple monitors or middle-click copying and pasting between two particularly misbehaved applications to work. Ironically enough, the least pretentious of them, sway, is by far the most solid. It's basically all the fun we had with X11 back in 2003, just to get an environment that's about as dependable (though admittedly much faster) as X11 back in 1993. It's one of those cases where the "release early, release often" mantra kindda seems to work against us. I'm sure ten years from now Wayland will be just as solid as X11 was back in 2013, aka "good enough", but there's a different kind of crowd looking at this stuff today. Unfortunately, the anti-Wayland buzz propagates easily because the community response is inevitably unsympathetic. Mention things like "I tried Wayland for an afternoon, applications kept crashing" and you'll inevitably get a dozen answers, all of them along the lines of nah bro I'm running Gnome Wayland which is the default in Fedora 67 on my ThinkPad X1 Carbon and I'm not getting any crashes. Well, yeah, 90% of the projects that failed to get traction and adoption in the field of graphical systems did so because they couldn't make the transition from "running on its developers' and fans' computers" to "running on everyone's computer". I can run Wayland on my system just fine, too, but I'm the only one in my immediate circle of nerds who can.
  - 7y ago
lvc_ 7y ago
Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. The implications are more around having a standard set of syscalls for moving data in and out of a program, abstracting away where it actually lives and treating the data itself as something opaque.
- pcr910303 7y ago
  > "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. Yeah, and shouldn’t that (theoretically) file systems with very small delay? (For example, RAM based file systems for inter-process communication.) I thought that it isn’t the slow storage that is blocking use of files, but more of a software problem that has significant overhead to use files as a communication method. (I’m not an expert here; please correct if I’m wrong.)
  - geofft 7y ago
    If you're sending a message to some process for it to consume, like X11 or like standard input to your shell, sure, you could technically interoperate via disk, but - UNIX itself has no inotify/kqueue/etc. feature, blocking reads are via pipes or sockets, not regular files (plain UNIX tail -f polls the file every fraction of a second) - you're appending to the end of the file for a message that's going to get read once, and the file model of UNIX doesn't let you truncate a file from the beginning, so it will just grow indefinitely for no reason - one benefit of the open socket/pipe approach is you get notified if the other side exits/crashes, you can't detect that from a disk file
- fao_ 7y ago
  > Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" You're right that it never meant 'everything is a disk file', but generally the implication of the unix philosophy was that everything could be accessed from the filesystem. Have a look at Plan9, which is essentially directly descended from 7th edition UNIX and IIRC was built from what was going to be 8th edition UNIX. It has a HTTP interface from the filesystem -- one can literally do GET requests on documents from the internet just by opening a file on the filesystem.
Znafon 7y ago
> I realize that the UNIX philosophy (everything is a file) is dead Was it ever alive? As far as I know lo0, eth0 and others where never accessible as a file interface and we still rely on them. Is there something to gain to give them a name on the filesystem?
- jlokier 7y ago
  They actually are accessible as a file interface: ls /sys/class/net You can't read and write packets via the interface, but there are configuration knobs and statistics you can access. I think it's quite messy and inconsistent that some network interface attributes are only in sysfs, and others are only accessible via AF_NETLINK (usually via the "ip" tool). But it's there.
draw_down 7y ago
I’m ok with it, everything isn’t a file.

progman 7y ago

> Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. As "dead" as Android (which is based on Linux, a Unix clone) and OSX (a BSD Unix) and iOS (child of OSX)? Why does Microsoft vibrantly support Linux in Windows 10 (an abomination to Ex-CEO Steve Ballmer) if Unix is "dead"? I think the very opposite is true. Some developers realized that the KISS principle (including the Unix philosophy where everything is a stream of bytes) is not a bad idea after all. https://blog.pragmaticengineer.com/software-architecture-is-overrated/ https://blog.pragmaticengineer.com/software-architecture-is-...

fao_ 7y ago
Support of Linux != support of UNIX and the UNIX Philosophy. Lennart Poettering, who is the mind behind Systemd, Pulseaudio, and a lot of major new technologies explicitly disavows the UNIX philosophy.

legulere 7y ago

The problem with file systems is that it is extremely difficult to build reliable systems on top of them. It’s shared mutable state with barely any error handling possibilities.

pcr910303 7y ago
> It’s shared mutable state with barely any error handling possibilities. And that makes me think about scoped file systems... (gotten the idea from global & scoped variables) Since the biggest advantage of ‘everything is a file’ is that it allows a consistent API for manipulating data, why didn’t this happen?
- throwaway2048 7y ago
  plan9 namespaces and user filesystems along with bind mounting achieved this sort of scoping.

mmrezaie 7y ago

How do you think it should have evolved? I personaly think posix way of filesystem needs to be changed into specialized oject filesystems, but I am not sure what object filesystem for a UNIX OS should look like specially since it needs to be generalized into something all the other sub-systems can benefit from.

pcr910303 7y ago
Personally I also preferred the ‘Everything is an object’ from the lisp machines. However, I also believe that files are an acceptable object format, since if several applications know how to manipulate a file format, it’s basically duck typing. I believe file systems could have a more formal method to query the file’s format, and has less latency so that applications could use files as an inter communication format.
datenwolf 7y ago
Just have a look at Plan9.
strictfp 7y ago
It could have evolved into REST (which it didn't, but they're deceptively similar).
fortran77 7y ago
There are some things like audio where it's nice to simply copy an audio file to a /dev/audio to play audio and read from /dev/audio to record audio. That doesn't preclude having more advanced interfaces, too.

rvz 7y ago

> Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead. Brings back memories of the old days of the late 1990s trying out so many workstations running obscure Linux distros to actual UNIX OSes like IRIX, Solaris and HP-UX. They all ran some variant of X11 which was part of the UNIX philosophy which I found interesting (X11 forwarding, startx, etc) but as the requirements of the desktop kept evolving over time, X11 just kept on showing its age. Nowadays, Wayland is showing promise as a successor but I really don't have time to be messing around with these .xinitrc, .Xresources or dotfiles to get HDPI working on my MacBook these days.

alxlaz 7y ago
The uncomfortable truth today is that, while having to touch an X config file hasn't been a thing in more than 10 years, it will take you some fiddling with your favourite Wayland compositor (of which only three -- two massive DEs and a tiling compositor -- are anywhere near being useful) just to get it to stop crashing on that one application that you need, or to get things like multiple monitors or middle-click copying and pasting between two particularly misbehaved applications to work. Ironically enough, the least pretentious of them, sway, is by far the most solid. It's basically all the fun we had with X11 back in 2003, just to get an environment that's about as dependable (though admittedly much faster) as X11 back in 1993. It's one of those cases where the "release early, release often" mantra kindda seems to work against us. I'm sure ten years from now Wayland will be just as solid as X11 was back in 2013, aka "good enough", but there's a different kind of crowd looking at this stuff today. Unfortunately, the anti-Wayland buzz propagates easily because the community response is inevitably unsympathetic. Mention things like "I tried Wayland for an afternoon, applications kept crashing" and you'll inevitably get a dozen answers, all of them along the lines of nah bro I'm running Gnome Wayland which is the default in Fedora 67 on my ThinkPad X1 Carbon and I'm not getting any crashes. Well, yeah, 90% of the projects that failed to get traction and adoption in the field of graphical systems did so because they couldn't make the transition from "running on its developers' and fans' computers" to "running on everyone's computer". I can run Wayland on my system just fine, too, but I'm the only one in my immediate circle of nerds who can.
- 7y ago

lvc_ 7y ago

Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. The implications are more around having a standard set of syscalls for moving data in and out of a program, abstracting away where it actually lives and treating the data itself as something opaque.

pcr910303 7y ago
> "Everything is a file" never meant "everything is a disk file" - think of std{in,out,err} or network sockets. Yeah, and shouldn’t that (theoretically) file systems with very small delay? (For example, RAM based file systems for inter-process communication.) I thought that it isn’t the slow storage that is blocking use of files, but more of a software problem that has significant overhead to use files as a communication method. (I’m not an expert here; please correct if I’m wrong.)
- geofft 7y ago
  If you're sending a message to some process for it to consume, like X11 or like standard input to your shell, sure, you could technically interoperate via disk, but - UNIX itself has no inotify/kqueue/etc. feature, blocking reads are via pipes or sockets, not regular files (plain UNIX tail -f polls the file every fraction of a second) - you're appending to the end of the file for a message that's going to get read once, and the file model of UNIX doesn't let you truncate a file from the beginning, so it will just grow indefinitely for no reason - one benefit of the open socket/pipe approach is you get notified if the other side exits/crashes, you can't detect that from a disk file
fao_ 7y ago
> Not disagreeing we've moved on from it a bit in some places, but.. "Everything is a file" never meant "everything is a disk file" You're right that it never meant 'everything is a disk file', but generally the implication of the unix philosophy was that everything could be accessed from the filesystem. Have a look at Plan9, which is essentially directly descended from 7th edition UNIX and IIRC was built from what was going to be 8th edition UNIX. It has a HTTP interface from the filesystem -- one can literally do GET requests on documents from the internet just by opening a file on the filesystem.

Znafon 7y ago

> I realize that the UNIX philosophy (everything is a file) is dead Was it ever alive? As far as I know lo0, eth0 and others where never accessible as a file interface and we still rely on them. Is there something to gain to give them a name on the filesystem?

jlokier 7y ago
They actually are accessible as a file interface: ls /sys/class/net You can't read and write packets via the interface, but there are configuration knobs and statistics you can access. I think it's quite messy and inconsistent that some network interface attributes are only in sysfs, and others are only accessible via AF_NETLINK (usually via the "ip" tool). But it's there.

draw_down 7y ago

I’m ok with it, everything isn’t a file.