9 ms·

"The reason why we have Linux, and BSDs, and XNU is that they all provide the same baseline API, which was defined from the outside [by POSIX]. The coordination

by ninjin 1y ago

"The reason why we have Linux, and BSDs, and XNU is that they all provide the same baseline API, which was defined from the outside [by POSIX]. The coordination problem was pre-solved, and what remained is just filling-in the implementation." But that is not at all how Posix operates or has operated. Posix standardises common denominators between existing implementations. The fact that we now have strlcpy(3) and strlcat(3) in Posix 2024, is not because Posix designed and stipulated them. Rather, they appeared in OpenBSD in 1998, were found useful by other *nix-es over time, spread, and were finally taken aboard by Posix that standardised what was already out there and being used! This to me is the very opposite of the point the author is trying to make!

maccard 1y ago
Actually I think this is exactly the point. BSD got them in 1998, it took 17 years for it to go to posix and another 8 years before they made their way to glibc. 25 years to add a clear improvement
- geysersam 1y ago
  Guess not everybody though it was a clear improvement then? It's not like it made everyone adopt BSD instead of Linux. If it was easy to make all the right decisions someone would have made them and sold it as a product instead
  - maccard 1y ago
    https://xkcd.com/1172/ https://xkcd.com/1172/
  - collingreen 1y ago
    Even if profit isn't involved this entire op argument seems really weird to me. It seems exceptionally entitled and also myopic? Somehow the author wants the good (??), popular (??) open source projects (made of thousands and thousands of opinionated decisions, many aesthetic and not "rational") to decide to cooperate and suddenly share opinions and aesthetic (while simultaneously maintaining the unique opinions and aesthetic that made the project popular in the first place?). The whole thing feels a lot like consumers demanding even more from open source maintainers and continuing to pay nothing.
dale_huevo 1y ago
Linux would have had strlcpy/strlcat 25 years ago but the glibc maintainer was famously being a giant chode and refused to allow "horribly inefficient BSD crap" into his precious code, and this fight went on for years: https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053.html https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053... So it wasn't for lack of trying. Yes, Open Source can't coordinate and this is why we can't have nice things.
- culopatin 1y ago
  Well, sounds like no one else stepped up with a fork, the commitment to maintain something better, and the networking effort, so the community had to put up with whoever was doing the work. Like if you didn’t cook and just sat on the couch you can’t be picky about you’re served.
- oersted 1y ago
  It's surprising how we ended up with such a robust open-source OS ecosystem (pretty much every server running Linux) with such emotional people at the helm. He is clearly not being rational there, but I could see how his aesthetic tastes might correlate pretty well with robust software. I suppose that saying no to new features is a good default heuristic, these additions could have easily added more problems than they solve, and then you have more surface area to maintain. That being said, this old-school ideology of maintainers dumping the full responsibility on the user for applying the API "properly" is rather unreasonable. It often sounds like they enjoy having all these footguns they refuse to fix, so they can feel superior and differentiate their club of greybeards who have memorised all the esoteric pitfalls, simply because they were along for the journey, from the masses.
  - AIPedant 1y ago
    "BSD crap," "deserves to be punished"... There's also an element of "Linus Torvalds is an antisocial jerk, and he's a genius, therefore if I am an antisocial jerk I must be doing genius-level work." In particular, it's a lot easier to attack someone with empty insults than it is to defend your own position with substantive thought.
dragochat 1y ago
exactly, you can't standardize on a solution before any good one exists in the first place
- Kranar 1y ago
  Tell that to the C++ Standard Committee. They have no problem standardizing things that don't even exist and may even be impossible to implement.
  - const_cast 1y ago
    Most additions to the standard library have been existing implementations found in boost. But yes, they have a tendency to go a little too theoretical. C++ standard targets a virtual machine and all that. Modules in particular was a hot mess.

by ninjin 1y ago

maccard 1y ago

Actually I think this is exactly the point. BSD got them in 1998, it took 17 years for it to go to posix and another 8 years before they made their way to glibc. 25 years to add a clear improvement

geysersam 1y ago
Guess not everybody though it was a clear improvement then? It's not like it made everyone adopt BSD instead of Linux. If it was easy to make all the right decisions someone would have made them and sold it as a product instead
- maccard 1y ago
  https://xkcd.com/1172/ https://xkcd.com/1172/
- collingreen 1y ago
  Even if profit isn't involved this entire op argument seems really weird to me. It seems exceptionally entitled and also myopic? Somehow the author wants the good (??), popular (??) open source projects (made of thousands and thousands of opinionated decisions, many aesthetic and not "rational") to decide to cooperate and suddenly share opinions and aesthetic (while simultaneously maintaining the unique opinions and aesthetic that made the project popular in the first place?). The whole thing feels a lot like consumers demanding even more from open source maintainers and continuing to pay nothing.

dale_huevo 1y ago

Linux would have had strlcpy/strlcat 25 years ago but the glibc maintainer was famously being a giant chode and refused to allow "horribly inefficient BSD crap" into his precious code, and this fight went on for years: https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053.html https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053... So it wasn't for lack of trying. Yes, Open Source can't coordinate and this is why we can't have nice things.

culopatin 1y ago
Well, sounds like no one else stepped up with a fork, the commitment to maintain something better, and the networking effort, so the community had to put up with whoever was doing the work. Like if you didn’t cook and just sat on the couch you can’t be picky about you’re served.
oersted 1y ago
It's surprising how we ended up with such a robust open-source OS ecosystem (pretty much every server running Linux) with such emotional people at the helm. He is clearly not being rational there, but I could see how his aesthetic tastes might correlate pretty well with robust software. I suppose that saying no to new features is a good default heuristic, these additions could have easily added more problems than they solve, and then you have more surface area to maintain. That being said, this old-school ideology of maintainers dumping the full responsibility on the user for applying the API "properly" is rather unreasonable. It often sounds like they enjoy having all these footguns they refuse to fix, so they can feel superior and differentiate their club of greybeards who have memorised all the esoteric pitfalls, simply because they were along for the journey, from the masses.
- AIPedant 1y ago
  "BSD crap," "deserves to be punished"... There's also an element of "Linus Torvalds is an antisocial jerk, and he's a genius, therefore if I am an antisocial jerk I must be doing genius-level work." In particular, it's a lot easier to attack someone with empty insults than it is to defend your own position with substantive thought.

dragochat 1y ago

exactly, you can't standardize on a solution before any good one exists in the first place

Kranar 1y ago
Tell that to the C++ Standard Committee. They have no problem standardizing things that don't even exist and may even be impossible to implement.
- const_cast 1y ago
  Most additions to the standard library have been existing implementations found in boost. But yes, they have a tendency to go a little too theoretical. C++ standard targets a virtual machine and all that. Modules in particular was a hot mess.