5 ms·

Overly contrived examples are the hallmark of software zealots. I knew to stop reading after "its more correct variant".

IshKebab 3y ago
Ignoring failures because they're moderately unlikely is the hallmark of a bad developer. It's an extremely common attitude unfortunately - you can see it all over the place, especially in the Unix/Linux world e.g. * People thinking sysvinit (janky Bash scripts) are fine. * 50% of Linux software doesn't work if you have spaces in your path. GNU Make explicitly doesn't support that. * Over use of text based APIs, e.g. /proc and /sys.
- generalizations 3y ago
  On the other hand, text-based line-oriented APIs are a force multiplier that lets one solo dev/sysadmin be capable of administering (troubleshooting and building out and keeping alive) far more infrastructure than can be reasonably expected. And it's not sysvinit you should critique, but runit (fast and bulletproof - two things the other modern alternative doesn't really do). > Ignoring failures because they're moderately unlikely is the hallmark of a bad developer. Totally agree.
  - IshKebab 3y ago
    I dunno I think something like JSON would still allow solo dev/sysadmins to get a lot done without the risk and effort of having to hand-roll separate parsers for every API. Then you could also offer something like Fuchsia's FIDL for programs to interface with - it allows generating the interface code fully typed in whatever language you want. No need to hand-roll a parser at all! > runit First I've heard of that. Looks interesting, but it doesn't seem like it has nearly enough features to run a modern desktop system? It just starts daemons and keeps them running as far as I can see.
    - generalizations 3y ago
      I'm not familiar with Fuschia's FIDL system, but it looks intriguing. Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. Ha. Runit is pretty good - it's the default in the Void Linux OS that I use on my personal machines. Definitely good enough for a modern desktop system, though it's not aimed at the same crowd as Ubuntu and Fedora.
      - IshKebab 3y ago
        > Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. Well, a) that's fine for interactive use but awful for unattended use because it's so likely to go wrong, and b) it is actually pretty easy to beat that - JSON and jq is much easier, nicer and more reliable. Or Nushell/Powershell structured pipes. Or an autogenerated properly typed Python interface. Take a look at /proc/self/status before you tell me you'd rather use some awk/cut monstrosity than `jq .ppid`. > If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. I'd definitely be happier - I wouldn't spend so much time debugging why Linux stuff breaks!
- qweqwe14 3y ago
  1) How are shell scripts janky? Could you elaborate on that? Obviously if someone doesn't know shell very well they will write suboptimal scripts. Personally I use runit init, which uses shell scripts for services and it works well. 2) No idea where you got that from, I never had a problem with this (as a full-time Linux user) 3) Mixed opinions on this one. There's a ton of various info in /proc that could theoretically be exposed via different syscalls, or maybe a single syscall? But having a text-based API in this case isn't a big issue really.
  - IshKebab 3y ago
    1. Sounds like you have written very few shell scripts if you don't know the issues and think you can just "don't make mistakes" (a classic fallacy). You can Google it and there are a ton of articles. Here's the first one I found which is decent but doesn't even mention some big issues like quoting: https://pythonspeed.com/articles/shell-scripts/ https://pythonspeed.com/articles/shell-scripts/ 2. Try putting a space in your home directory and let me know how that goes... 3. Most programs don't resort to reading /proc or /sys because it is such a pain! I bet there's a ton of undiscovered vulnerabilities in programs that do.
    - qweqwe14 3y ago
      1. The real fallacy here is assuming "it requires experience so it's impossible to do". Everything described in that article is trivial and anyone with experience in writing shell scripts knows about these things. People just instinctively go "this doesn't do what I expect therefore it's bad" instead of trying to understand the reasoning behind that. tl;dr Classic skill issue 2. Another fallacy. Obviously there will be badly written programs that don't handle paths properly. And I'm sure that if I put a space there it will screw things up. But it doesn't mean that most programs do that? 3. It's not a pain. It's absolutely trivial to do, and people whose code is vulnerable in this case are most likely just bad at programming and shouldn't be writing at such a low level as to cause vulnerabilities anyway. These are the type of people referred to as "developers" instead of "programmers". (Source: I personally parsed /proc entries without third party libraries, can't say it was hard)

IshKebab 3y ago

Ignoring failures because they're moderately unlikely is the hallmark of a bad developer. It's an extremely common attitude unfortunately - you can see it all over the place, especially in the Unix/Linux world e.g. * People thinking sysvinit (janky Bash scripts) are fine. * 50% of Linux software doesn't work if you have spaces in your path. GNU Make explicitly doesn't support that. * Over use of text based APIs, e.g. /proc and /sys.

generalizations 3y ago
On the other hand, text-based line-oriented APIs are a force multiplier that lets one solo dev/sysadmin be capable of administering (troubleshooting and building out and keeping alive) far more infrastructure than can be reasonably expected. And it's not sysvinit you should critique, but runit (fast and bulletproof - two things the other modern alternative doesn't really do). > Ignoring failures because they're moderately unlikely is the hallmark of a bad developer. Totally agree.
- IshKebab 3y ago
  I dunno I think something like JSON would still allow solo dev/sysadmins to get a lot done without the risk and effort of having to hand-roll separate parsers for every API. Then you could also offer something like Fuchsia's FIDL for programs to interface with - it allows generating the interface code fully typed in whatever language you want. No need to hand-roll a parser at all! > runit First I've heard of that. Looks interesting, but it doesn't seem like it has nearly enough features to run a modern desktop system? It just starts daemons and keeps them running as far as I can see.
  - generalizations 3y ago
    I'm not familiar with Fuschia's FIDL system, but it looks intriguing. Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. Ha. Runit is pretty good - it's the default in the Void Linux OS that I use on my personal machines. Definitely good enough for a modern desktop system, though it's not aimed at the same crowd as Ubuntu and Fedora.
    - IshKebab 3y ago
      > Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. Well, a) that's fine for interactive use but awful for unattended use because it's so likely to go wrong, and b) it is actually pretty easy to beat that - JSON and jq is much easier, nicer and more reliable. Or Nushell/Powershell structured pipes. Or an autogenerated properly typed Python interface. Take a look at /proc/self/status before you tell me you'd rather use some awk/cut monstrosity than `jq .ppid`. > If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. I'd definitely be happier - I wouldn't spend so much time debugging why Linux stuff breaks!
qweqwe14 3y ago
1) How are shell scripts janky? Could you elaborate on that? Obviously if someone doesn't know shell very well they will write suboptimal scripts. Personally I use runit init, which uses shell scripts for services and it works well. 2) No idea where you got that from, I never had a problem with this (as a full-time Linux user) 3) Mixed opinions on this one. There's a ton of various info in /proc that could theoretically be exposed via different syscalls, or maybe a single syscall? But having a text-based API in this case isn't a big issue really.
- IshKebab 3y ago
  1. Sounds like you have written very few shell scripts if you don't know the issues and think you can just "don't make mistakes" (a classic fallacy). You can Google it and there are a ton of articles. Here's the first one I found which is decent but doesn't even mention some big issues like quoting: https://pythonspeed.com/articles/shell-scripts/ https://pythonspeed.com/articles/shell-scripts/ 2. Try putting a space in your home directory and let me know how that goes... 3. Most programs don't resort to reading /proc or /sys because it is such a pain! I bet there's a ton of undiscovered vulnerabilities in programs that do.
  - qweqwe14 3y ago
    1. The real fallacy here is assuming "it requires experience so it's impossible to do". Everything described in that article is trivial and anyone with experience in writing shell scripts knows about these things. People just instinctively go "this doesn't do what I expect therefore it's bad" instead of trying to understand the reasoning behind that. tl;dr Classic skill issue 2. Another fallacy. Obviously there will be badly written programs that don't handle paths properly. And I'm sure that if I put a space there it will screw things up. But it doesn't mean that most programs do that? 3. It's not a pain. It's absolutely trivial to do, and people whose code is vulnerable in this case are most likely just bad at programming and shouldn't be writing at such a low level as to cause vulnerabilities anyway. These are the type of people referred to as "developers" instead of "programmers". (Source: I personally parsed /proc entries without third party libraries, can't say it was hard)