4 ms·

I'm not picking on you specifically but when people say things like "Unix gives you brain damage" this is what they mean. Your suggestion is that the network s

I'm not picking on you specifically but when people say things like "Unix gives you brain damage" this is what they mean. Your suggestion is that the network should be reliable (a strict impossibility) or that every application should use a bespoke protocol to do simple things like working with a network file system. The Unix IO model isn't well designed and is far from the only Unix-ism to work poorly in the face of threads (signals and fork/exec are common offenders; not even memcpy is safe in a signal handler!) This is hardly surprising: it was slapped together ad-hoc over the years.

loeg 10y ago
> I'm not picking on you specifically but when people say things like "Unix gives you brain damage" this is what they mean. You understand that's still offensive and implies I have brain damage, right? > every application should use a bespoke protocol to do simple things like working with a network file system. It doesn't have to be bespoke, but I agree that the Unix VFS interface isn't appropriate for it. What operating system are you aware of that provides a mkdir interface with timeout? Windows' CreateDirectory() does not. OS X is just BSD. We're departing the realm of mainstream systems. QNX mkdir does not appear to take a timeout. Plan9 uses create() with a DIR flag, which does not take a timeout. Help me out here?
- fiddlerwoaroof 10y ago
  I suspect old systems like Multics did. But, this is the sort of thing that Richard Gabriel is talking about in worse is better[1] [1]: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
- deleted 10y ago
  [deleted]
- xenadu02 10y ago
  > You understand that's still offensive and implies I have brain damage, right? My apologize, I didn't intend that. I mean that some people are used to Unix and use their familiarity as a post-hoc rationalization for some of the poorly designed aspects of it. To be clear: my position is that several Unix APIs are bad designs. Rather than making excuses for them we should demand better cross-platform APIs. > It doesn't have to be bespoke, but I agree that the Unix VFS interface isn't appropriate for it. I don't agree. Network filesystems should be mountable and traversable just like local filesystems, but the OS and libraries should do more to be async and multi-thread aware, as should applications.
  - pjmlp 10y ago
    > Rather than making excuses for them we should demand better cross-platform APIs. We already have them in the form of language runtimes. POSIX as cross-platform API is mostly relevant to C. Even C++ is moving beyond POSIX, by providing proper OS abstractions on the standard library.
fulafel 10y ago
NFS violates a number of basic Unix filesystem guarantees. It's well documented that it violates POSIX guaranteed filesystem semantics. The abstraction NFS chose is "filesystem operations don't time out", and implements this by just making your process hang as long as the network is dead - possibly forever. I'm not sure it's a bad thing that the Unix FS API doesn't do networked filesystems. Everbody is using userspace APIs for remote file access, and the big and varied design space of remote file access semantics doesn't get bottlenecked on 30 year old system call APIs.
slrz 10y ago
> The Unix IO model isn't well designed and is far from the only Unix-ism to work poorly in the face of threads Right, threads in the form of pthreads should've never been introduced into Unix, as they made a huge mess of many interfaces. The rfork "you have processes that can share resources" model is a much better fit (although it doesn't solve all problems). It's what Linux as well as FreeBSD implement at the kernel level anyway except they add tons of ugly stuff on top of it to allow for performant implementations of POSIX threads semantics.

loeg 10y ago

> I'm not picking on you specifically but when people say things like "Unix gives you brain damage" this is what they mean. You understand that's still offensive and implies I have brain damage, right? > every application should use a bespoke protocol to do simple things like working with a network file system. It doesn't have to be bespoke, but I agree that the Unix VFS interface isn't appropriate for it. What operating system are you aware of that provides a mkdir interface with timeout? Windows' CreateDirectory() does not. OS X is just BSD. We're departing the realm of mainstream systems. QNX mkdir does not appear to take a timeout. Plan9 uses create() with a DIR flag, which does not take a timeout. Help me out here?

fiddlerwoaroof 10y ago
I suspect old systems like Multics did. But, this is the sort of thing that Richard Gabriel is talking about in worse is better[1] [1]: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
deleted 10y ago
[deleted]
xenadu02 10y ago
> You understand that's still offensive and implies I have brain damage, right? My apologize, I didn't intend that. I mean that some people are used to Unix and use their familiarity as a post-hoc rationalization for some of the poorly designed aspects of it. To be clear: my position is that several Unix APIs are bad designs. Rather than making excuses for them we should demand better cross-platform APIs. > It doesn't have to be bespoke, but I agree that the Unix VFS interface isn't appropriate for it. I don't agree. Network filesystems should be mountable and traversable just like local filesystems, but the OS and libraries should do more to be async and multi-thread aware, as should applications.
- pjmlp 10y ago
  > Rather than making excuses for them we should demand better cross-platform APIs. We already have them in the form of language runtimes. POSIX as cross-platform API is mostly relevant to C. Even C++ is moving beyond POSIX, by providing proper OS abstractions on the standard library.

fulafel 10y ago

NFS violates a number of basic Unix filesystem guarantees. It's well documented that it violates POSIX guaranteed filesystem semantics. The abstraction NFS chose is "filesystem operations don't time out", and implements this by just making your process hang as long as the network is dead - possibly forever. I'm not sure it's a bad thing that the Unix FS API doesn't do networked filesystems. Everbody is using userspace APIs for remote file access, and the big and varied design space of remote file access semantics doesn't get bottlenecked on 30 year old system call APIs.

slrz 10y ago

> The Unix IO model isn't well designed and is far from the only Unix-ism to work poorly in the face of threads Right, threads in the form of pthreads should've never been introduced into Unix, as they made a huge mess of many interfaces. The rfork "you have processes that can share resources" model is a much better fit (although it doesn't solve all problems). It's what Linux as well as FreeBSD implement at the kernel level anyway except they add tons of ugly stuff on top of it to allow for performant implementations of POSIX threads semantics.