7 ms·

Most of this comment is incorrect.

skissane 10y ago
I think xenadu02 raises some valid criticisms, but I think those criticisms would have been better received if they were expressed more politely. I'd love to see a rebuttal of the specific points made as opposed to just "Most of this comment is incorrect".
- deleted 10y ago
  [deleted]
- jjnoakes 10y ago
  Most of the statements aren't really conducive to rebuttals because they are lacking substance. But I can imagine what xenadu02 might have meant, if you like, and provide some counter arguments. Signals aren't "garbage" (whatever that means). Signals can call APIs (the set of async-signal-safe APIs). They can't call non-async-signal-safe APIs not because of threads, but because signals can interrupt a routine at any point (necessary for asynchronous notification of certain events which must be handled before the normal instruction control flow can be resumed) and that interrupted routine may not have been written to be reentrant. This is true even without threads in the picture. The fork/exec model is not "garbage". It is actually a fairly nice alternative to the "provide one API to start a child process and give it a large number of parameters for all possible situations". And you can call plenty of APIs between fork and exec in the child safely, just like from signal handlers. I haven't dealt with dependency hell ever since shared libraries got sonames. The rest of the comment doesn't list anything of substance. If you want rebuttals for "the file system layout is a bad design" or "the C compilation is a bad design" or anything else, provide some reasons why those are bad designs; some of those reasons may be valid criticism, and some may not be, but one can't just make vacuous statements like that and expect a reasonable discussion to follow.
  - jcrites 10y ago
    Unix signals have been called garbage by some and "unfixable" by others [1]. The article [1] explains the evolution of signal handling, from sigvec(), sigaction(), to signalfd() -- a rocky history fraught with problems, an article in the series "Unfixable designs". > So while signal handlers are perfectly workable for some of the early use cases (e.g. SIGSEGV) it seems that they were pushed beyond their competence very early, thus producing a broken design for which there have been repeated attempts at repair. While it may now be possible to write code that handles signal delivery reliably, it is still very easy to get it wrong. The replacement that we find in signalfd() promises to make event handling significantly easier and so more reliable. Another critic makes the case that "signalfd is [also] useless" [2]: > "UNIX[] signals are probably one of the worst parts of the UNIX API, and that’s a relatively high bar." Signals came up recently on HN when someone remarked that not even memset() is signal-safe! [3] All in all, working with signals correctly requires mastering a tremendous degree of complexity. Other platforms have provided simpler APIs, such as Structure Event Handling (SEH) [4]. [1] https://lwn.net/Articles/414618/ https://lwn.net/Articles/414618/ [2] article link from https://news.ycombinator.com/item?id=9564975 https://news.ycombinator.com/item?id=9564975 [3] https://news.ycombinator.com/item?id=13313563 https://news.ycombinator.com/item?id=13313563 [4] An HN comment describing how it's simpler: https://news.ycombinator.com/item?id=13323870 https://news.ycombinator.com/item?id=13323870 P.S. Please note that the views quoted above are not necessarily my views.
    - jjnoakes 10y ago
      Like I said, there are some valid arguments on both sides. But a blanket "signals are garbage" is not useful or correct.
  - skissane 10y ago
    I'm not going to defend everything xenadu02 said, but I think there were some points that resonated with me even though I agree they could be expressed more constructively. > Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? I think these are valid examples of how Unix itself fails to follow the "Unix philosophy" of "Do One Thing and Do It Well". > The fork/exec model is not "garbage". It is actually a fairly nice alternative to the "provide one API to start a child process and give it a large number of parameters for all possible situations". And you can call plenty of APIs between fork and exec in the child safely, just like from signal handlers. fork-exec complicates the implementation of threads (see atfork handlers). Rather than "a large number of parameters for all possible situations", another alternative would be to have (1) a call which given executable name and arguments returns an opaque handle (or file descriptor) representing the process to be started (2) a bunch of further calls to set attributes on that handle – new features could add new APIs acting on the handle, or an extensible API like ioctl could be used – if there is a handle to represent the current process, then you only need one API call to set it for the current process or a child to be started (3) finally, a start call which turns the process-to-be-started handle into a running process handle. > Unix file permissions are shit The user-group-other model is arguably too limiting. ACLs are a better idea, but then should you use POSIX ACLs or NFSv4 ACLs? The distinction between primary group ID and supplementary group IDs is silly. Why must every file have both a UID and a GID? For files owned by a single user, you end up creating a dummy group like "staff" or so on just to obey the rule that every file must have a GID. For shared files, e.g. project files, files generally end up owned by their creator, even though in a business sense they really belong to the project not to whoever created them. It would make more sense if the owner could be either a user or a group, and then also have zero or more non-owning groups associated with it. In most cases permissions should only exist on the directory, and then automatically apply to any files in the directory. (In most cases every file in the same directory should have the same permission; Unix bases its design on the exception rather than the rule.) Of course, hard links make this impossible, but I think hard links were a mistake. The executable permission bits actually do double duty as a file type indicator. That's rather ugly. If Unix had explicit file types (rather than just a naming convention of file extensions), then certain file types could be declared to be executable. Executable permission would then mean "you are allowed to execute this if it is an executable" instead of "this is an executable". Stuff like the +x vs +X distinction in chmod would never have been necessary. > Let's not even get into everything is a file Unix would have been much better if everything were a file descriptor, rather than having stuff like pid_t. Linux at least is evolving in this direction. Plan9 does it better. Even the WindowsNT philosophy of "everything is a handle" is better than the traditional Unix approach.
- lisivka 10y ago
  «Foo is garbage» is not a valid criticism.
deleted 10y ago
[deleted]

I think xenadu02 raises some valid criticisms, but I think those criticisms would have been better received if they were expressed more politely. I'd love to see a rebuttal of the specific points made as opposed to just "Most of this comment is incorrect".

deleted 10y ago
[deleted]
jjnoakes 10y ago
Most of the statements aren't really conducive to rebuttals because they are lacking substance. But I can imagine what xenadu02 might have meant, if you like, and provide some counter arguments. Signals aren't "garbage" (whatever that means). Signals can call APIs (the set of async-signal-safe APIs). They can't call non-async-signal-safe APIs not because of threads, but because signals can interrupt a routine at any point (necessary for asynchronous notification of certain events which must be handled before the normal instruction control flow can be resumed) and that interrupted routine may not have been written to be reentrant. This is true even without threads in the picture. The fork/exec model is not "garbage". It is actually a fairly nice alternative to the "provide one API to start a child process and give it a large number of parameters for all possible situations". And you can call plenty of APIs between fork and exec in the child safely, just like from signal handlers. I haven't dealt with dependency hell ever since shared libraries got sonames. The rest of the comment doesn't list anything of substance. If you want rebuttals for "the file system layout is a bad design" or "the C compilation is a bad design" or anything else, provide some reasons why those are bad designs; some of those reasons may be valid criticism, and some may not be, but one can't just make vacuous statements like that and expect a reasonable discussion to follow.
- jcrites 10y ago
  Unix signals have been called garbage by some and "unfixable" by others [1]. The article [1] explains the evolution of signal handling, from sigvec(), sigaction(), to signalfd() -- a rocky history fraught with problems, an article in the series "Unfixable designs". > So while signal handlers are perfectly workable for some of the early use cases (e.g. SIGSEGV) it seems that they were pushed beyond their competence very early, thus producing a broken design for which there have been repeated attempts at repair. While it may now be possible to write code that handles signal delivery reliably, it is still very easy to get it wrong. The replacement that we find in signalfd() promises to make event handling significantly easier and so more reliable. Another critic makes the case that "signalfd is [also] useless" [2]: > "UNIX[] signals are probably one of the worst parts of the UNIX API, and that’s a relatively high bar." Signals came up recently on HN when someone remarked that not even memset() is signal-safe! [3] All in all, working with signals correctly requires mastering a tremendous degree of complexity. Other platforms have provided simpler APIs, such as Structure Event Handling (SEH) [4]. [1] https://lwn.net/Articles/414618/ https://lwn.net/Articles/414618/ [2] article link from https://news.ycombinator.com/item?id=9564975 https://news.ycombinator.com/item?id=9564975 [3] https://news.ycombinator.com/item?id=13313563 https://news.ycombinator.com/item?id=13313563 [4] An HN comment describing how it's simpler: https://news.ycombinator.com/item?id=13323870 https://news.ycombinator.com/item?id=13323870 P.S. Please note that the views quoted above are not necessarily my views.
  - jjnoakes 10y ago
    Like I said, there are some valid arguments on both sides. But a blanket "signals are garbage" is not useful or correct.
- skissane 10y ago
  I'm not going to defend everything xenadu02 said, but I think there were some points that resonated with me even though I agree they could be expressed more constructively. > Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? I think these are valid examples of how Unix itself fails to follow the "Unix philosophy" of "Do One Thing and Do It Well". > The fork/exec model is not "garbage". It is actually a fairly nice alternative to the "provide one API to start a child process and give it a large number of parameters for all possible situations". And you can call plenty of APIs between fork and exec in the child safely, just like from signal handlers. fork-exec complicates the implementation of threads (see atfork handlers). Rather than "a large number of parameters for all possible situations", another alternative would be to have (1) a call which given executable name and arguments returns an opaque handle (or file descriptor) representing the process to be started (2) a bunch of further calls to set attributes on that handle – new features could add new APIs acting on the handle, or an extensible API like ioctl could be used – if there is a handle to represent the current process, then you only need one API call to set it for the current process or a child to be started (3) finally, a start call which turns the process-to-be-started handle into a running process handle. > Unix file permissions are shit The user-group-other model is arguably too limiting. ACLs are a better idea, but then should you use POSIX ACLs or NFSv4 ACLs? The distinction between primary group ID and supplementary group IDs is silly. Why must every file have both a UID and a GID? For files owned by a single user, you end up creating a dummy group like "staff" or so on just to obey the rule that every file must have a GID. For shared files, e.g. project files, files generally end up owned by their creator, even though in a business sense they really belong to the project not to whoever created them. It would make more sense if the owner could be either a user or a group, and then also have zero or more non-owning groups associated with it. In most cases permissions should only exist on the directory, and then automatically apply to any files in the directory. (In most cases every file in the same directory should have the same permission; Unix bases its design on the exception rather than the rule.) Of course, hard links make this impossible, but I think hard links were a mistake. The executable permission bits actually do double duty as a file type indicator. That's rather ugly. If Unix had explicit file types (rather than just a naming convention of file extensions), then certain file types could be declared to be executable. Executable permission would then mean "you are allowed to execute this if it is an executable" instead of "this is an executable". Stuff like the +x vs +X distinction in chmod would never have been necessary. > Let's not even get into everything is a file Unix would have been much better if everything were a file descriptor, rather than having stuff like pid_t. Linux at least is evolving in this direction. Plan9 does it better. Even the WindowsNT philosophy of "everything is a handle" is better than the traditional Unix approach.
lisivka 10y ago
«Foo is garbage» is not a valid criticism.

deleted 10y ago

[deleted]