6 ms·

Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why d

Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change it". fork/exec is garbage. Signals are garbage. You basically can't make any API calls after fork or in a signal handler because threads came after. The interaction of fork and threads is bananas and many hacks have been required over he years to paper over the problems. The layout of /usr/bin, /usr/sbin, /usr/local/bin, et al isn't a good design. It's dogshit but it was necessary because early Unix file systems couldn't span multiple volumes and early disk systems were small. The C compilation model of separate header files is not a good design. People have retroactively determined some of the side-effects are not only good but The One True Way. In reality the design was a result of extremely limited RAM and slow CPUs. The preprocessor itself was never designed, just grafted on ad-hoc. Unix file permissions are shit. Every unique combination of permissions requires a group. Owners are by simple integers. NFS legitimately gives people nightmares. Let's not even get into everything is a file, except when it's not, and some files are more equal than others. What about dependency hell? How's that "simple" model working out? The "Unix philosophy" can piss right off.

jjnoakes 10y ago
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.
- deleted 10y ago
  [deleted]
quickben 10y ago
"The C compilation model of separate header files is not a good design" This is probably just your lack of experience not having worked on 50+ million LOC compiling for 12 hours and not having anything else as a better option. There is a reason these things exist.
- GFK_of_xmaspast 10y ago
  Do you want to clarify that, because I think you may have missed a "not" in there.
- skissane 10y ago
  Isn't the limitations of the header file system the reason why the C++ module system is being developed? Why wouldn't something like the C++ module system be of benefit in C also?
  - quickben 10y ago
    One of the reasons it seems. It would, but by the look of it, C++ evolves faster these days.
- moosingin3space 10y ago
  > There is a reason these things exist. Enlighten me. And while you're at it, explain why this is better than, say, Rust's module system, where we don't need separate header files.
  - deleted 10y ago
    [deleted]
- deleted 10y ago
  [deleted]
- zvrba 10y ago
  I've worked on a project that combined C++ and C# in approximately equal amounts (say 2MLOC each). The C++ project compiled and linked for 20 minutes , C# compiled and linked in under 2 minutes. Go figure. I agree: C and C++ compilation model is not a good design. It's a patch for not having a decent module system. Heck, even Borland Pascal compiled faster in 90-ies than C++ does now on an orders of magnitude faster machine.
aaronky 10y ago
"Who said the Unix philosophy was the be-all, end-all?" I didn't and I don't know anyone that has. I was comparing systemd and SysV. "Unix is just a collection of random decisions made by various people over the years." "Linux has never been about quality. There are so many parts of the system that are just these cheap little hacks, and it happens to run." - Theo de Raadt "The layout of /usr/bin, /usr/sbin, /usr/local/bin" I don't agree with you. Having base in a directory and having user installed bins in another makes sense. I don't understand why most modern Linux distros install on only one partition by default. You lose the ability to mount with flags ie noexec,nosuid,nodev. NFS is horrible. Unix/Linux is a multi-user operating system why would you not want to have groups? KISS
- Shorel 10y ago
  > NFS is horrible. Unix/Linux is a multi-user operating system why would you not want to have groups? Now that's backwards. He obviously mean a better permission system. Do you seriously think groups is the best way? Access Control Lists are a better way.
x0 10y ago
Yes, yes, yes! Never has someone articulated what I believe so damn well. There is so much blind worship of tradition and heroes in the UNIX world, so glad to see someone else believes what I've always believed.

jjnoakes 10y ago

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.
deleted 10y ago
[deleted]

quickben 10y ago

"The C compilation model of separate header files is not a good design" This is probably just your lack of experience not having worked on 50+ million LOC compiling for 12 hours and not having anything else as a better option. There is a reason these things exist.

GFK_of_xmaspast 10y ago
Do you want to clarify that, because I think you may have missed a "not" in there.
skissane 10y ago
Isn't the limitations of the header file system the reason why the C++ module system is being developed? Why wouldn't something like the C++ module system be of benefit in C also?
- quickben 10y ago
  One of the reasons it seems. It would, but by the look of it, C++ evolves faster these days.
moosingin3space 10y ago
> There is a reason these things exist. Enlighten me. And while you're at it, explain why this is better than, say, Rust's module system, where we don't need separate header files.
- deleted 10y ago
  [deleted]
deleted 10y ago
[deleted]
zvrba 10y ago
I've worked on a project that combined C++ and C# in approximately equal amounts (say 2MLOC each). The C++ project compiled and linked for 20 minutes , C# compiled and linked in under 2 minutes. Go figure. I agree: C and C++ compilation model is not a good design. It's a patch for not having a decent module system. Heck, even Borland Pascal compiled faster in 90-ies than C++ does now on an orders of magnitude faster machine.

aaronky 10y ago

"Who said the Unix philosophy was the be-all, end-all?" I didn't and I don't know anyone that has. I was comparing systemd and SysV. "Unix is just a collection of random decisions made by various people over the years." "Linux has never been about quality. There are so many parts of the system that are just these cheap little hacks, and it happens to run." - Theo de Raadt "The layout of /usr/bin, /usr/sbin, /usr/local/bin" I don't agree with you. Having base in a directory and having user installed bins in another makes sense. I don't understand why most modern Linux distros install on only one partition by default. You lose the ability to mount with flags ie noexec,nosuid,nodev. NFS is horrible. Unix/Linux is a multi-user operating system why would you not want to have groups? KISS

Shorel 10y ago
> NFS is horrible. Unix/Linux is a multi-user operating system why would you not want to have groups? Now that's backwards. He obviously mean a better permission system. Do you seriously think groups is the best way? Access Control Lists are a better way.

x0 10y ago

Yes, yes, yes! Never has someone articulated what I believe so damn well. There is so much blind worship of tradition and heroes in the UNIX world, so glad to see someone else believes what I've always believed.