4 ms·

> I want cultish followings to end within the FOSS community. I swear I’ll always work against that. > And we like things following the standards already put i

> I want cultish followings to end within the FOSS community. I swear I’ll always work against that. > And we like things following the standards already put in place. Because we don’t give a damn about helping the FSF do their thing: We care about tech. We care about and love the legacy of UNIX, its philosophy, and we want to adhere to it as strictly as possible. Sorry for breaking it up to you, but this kind of "standards must be respected 11!!!!1&!1" mindset is the actual cult-like behaviour, commonly found in communities such as cat-v.org, and with people clinging to plan 9 like it's anything beyond a failed experiment. GNU and shells like bash (I use zsh which is I guess even "worse" in terms of feature bloat) are dominant because they provides a ton of super useful features to make work faster. Likewise you bash against glibc's bloat, but most software perform faster when using glibc than other "less bloated" libc implementations like musl ; the bloat is here for a reason and that reason is performance (which matters infinitely more than whatever ideological purity BS someone can find). Who cares if it's not strictly POSIX compliant: it makes computing a better experience and that's all that matters, and if tomorrow someone manages to create an entirely different non-posix platform that manages to improve on that, I'll happily jump there and I hope you do too.

klodolph 5y ago
I think the difference is with bash & zsh is down to whether you choose to use them as your interactive shell or whether you choose to write shell scripts in them. I had assumed that this was about shell script portability. Bash and zsh have a ton of super useful features to make work faster, but the features for shell programming (writing shell scripts that other people will use) are not so useful. Yes, I'm aware of stuff like [[, I don't think that [[ is very useful. I have dash as /bin/sh and #!/bin/sh in all my scripts, and seriously, it's not a problem.
- forgotpwd16 5y ago
  There're many features that are useful for programming: variable expansion, pattern replacement, substing expansion, and others. Not only that but some bash built-ins essentially replace external processes leading to your script being faster and more portable (ironically).
  - klodolph 5y ago
    Bash is not alone in having built-ins that make it faster. Generally speaking, Bash is measurably slower than other shells. If you convert make your shell scripts portable and change #!/bin/bash to #!/bin/sh, in my experience, this usually makes them faster, too (on systems where sh is not bash). This is the driving factor for Debian's switch from Bash to Dash, which resulted in noticeable startup speed improvements: https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh (Note that Systemd has since obviated most of that work.) You may be writing very different shell scripts than the ones which I encounter. I'm not sure what you mean by "variable expansion", because variable expansion is portable. Something like 98%+ of all pattern replacement I see is something simple like replacing a suffix or prefix of a string. For example, infile=input.png outfile="${infile%.png}.jpg" You can typically use sed for the complicated stuff. Above a certain level of complexity, I'd likely rewrite the script in Perl or Python, anyway. Or possibly Go.
    - forgotpwd16 5y ago
      For your example, in bash you can do infile=input.png outfile="${infile/.png/.jpg}" Yes, supposing it exists and you've permissions for it, you can use sed. Do that a dozen times and the calls to an external process add up to a significant time. But the real advantage is being easier to write and work with.
- Cederfjard 5y ago
  What level of portability do you deem necessary for what you do? I rarely encounter a box that has sh but not bash, but maybe that’s just me.
  - klodolph 5y ago
    I could equally ask, "What level of Bash features do you deem necessary for what you do? I rarely encounter a shell script that cannot be trivially modified to work on POSIX /bin/sh." At least historically speaking, Bash was noticeably slower than Dash. It's the slowest shell. If you are doing things like, say, build scripts in a CI environment where you need to execute shell scripts thousands of times or more, the 4x difference can make a real impact on user experience. Same thing during startup, back before the transition to Systemd, when Debian changed the /bin/sh alias to point to Dash instead of Bash to speed up system startup. https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash https://unix.stackexchange.com/questions/148035/is-dash-or-s... https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh At some point, shell scripts reach a level of complexity where most people choose to rewrite them in a higher-level language, often Python or Perl, or maybe even Go. My personal experience is that the Bash-isms, although kind of nice, don't really shift that threshold... like, although Bash has arrays, but if I need to manipulate arrays, I switch to Perl or Python. If I just need to pull elements out of one array, I can do that portably.
- belorn 5y ago
  It seems like if one want to be a bit more focused on compatibility, just using python with compatibility added for v2 vs v3 is easier than using shell scripts for the multiple different operating system, platforms, shells and versions that exist today. Shells seems much more coupled with the operating system and decision that people have made on that level.
  - klodolph 5y ago
    Yes, above a certain complexity, you'd probably want to write your script in Perl or Python. Python has an enormous overhead compared to shell scripts, though. If you're writing some simple wrapper in a build system that's going to be invoked thousands of times for a single build, Python could easily end up being a choke point. If you're really concerned about portability, I would probably write it in Perl :-) Perl is basically a souped up shell language, with built-in Awk & Sed, faster start-up time than Bash, and it's installed nearly everywhere.
    - belorn 5y ago
      Perl vs Python on the script side has always seemed to me to be a bit up to taste, through I have noticed on the sysadmin side that in general things has moved away from Perl towards Python. I also notice that in terms of job listing, there seems to be a lack of new perl programmers in order to support older systems. In terms of build systems, what I have most experience with would be with Debian and their build system, which pulls in the required dependencies. Compatibility in this space is less about zsh vs bash and more in line with architecture difference like RISC vs AMD64.
- aidenn0 5y ago
  Bash arrays are the only thing I really wish dash had. Some other things are "nice to have" but can be implemented on top of sh. Arrays really can't.
BuildTheRobots 5y ago
> Who cares if it's not strictly POSIX compliant: it makes computing a better experience and that's all that matters Whilst I broadly agree with your point, I'd suggest that "better experience" can be extremely "eye of the beholder" - especially if it interrupts a long established workflow / toolkit.
- not2b 5y ago
  For many, "long established workflow" now means "Linux with GNU userland". But if deviations from POSIX behavior by the GNU tools cause problems for a flow, that's what the POSIXLY_CORRECT environment variable is for.
eadmund 5y ago
> Sorry for breaking it up to you, but this kind of "standards must be respected 11!!!!1&!1" mindset is the actual cult-like behaviour, commonly found in communities such as cat-v.org, and with people clinging to plan 9 like it's anything beyond a failed experiment. That's a bit of a non sequitur: Plan 9 is very much not a standard, and indeed it derives a great deal of its power from not implementing the POSIX standard.
hoseja 5y ago
Like with the `yes` example, those looked like optimizations to me, maybe misguided but surely coreutils should be as optimized as possible.
matheusmoreira 5y ago
Completely agree. Nothing's worse than the cult of POSIX. Half a century ago some people gathered and figured out the lowest common denominator of all the unixes of the time. Now it's 2021 and we're still supposed to restrict ourselves to this "standard" system in the name of portability. POSIX has so few features that restricting yourself to it is masochism. Every unix adds their own extensions, they would be almost unusable if they didn't. So why is GNU criticized for doing the same? The author says GNU is just some optional userland. I find that amusing since in every traditional unix the POSIX userland is deeply integrated with the system. He talks about glibc but the BSDs and even Windows ship with their own libc that I can't ever get rid of because they're the only supported way to interface with the kernel. Linux is the only operating system that actually frees us from this cult. Unlike other systems, the kernel/userspace interface is stable and defined at the lowest possible level: processor instruction set architecture. https://man7.org/linux/man-pages/man2/syscalls.2.html https://man7.org/linux/man-pages/man2/syscalls.2.html https://man7.org/linux/man-pages/man2/syscall.2.html https://man7.org/linux/man-pages/man2/syscall.2.html https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/syscalls https://github.com/torvalds/linux/blob/master/Documentation/... Only on Linux is GNU truly just some optional userland. You can throw it in the trash if you want. You can make your own. Who says you gotta have little commands like cp, mv, grep, sed, whatever? Who says people have to use some "standard" shell from the 80s? You can make a graphical userland if you want. A 100% Rust or Lisp userland. Even no userland at all. People complain about systemd but I actually have a lot of respect for it. The developers had the balls to trash all this sacred POSIX stuff and make something new that actually uses Linux kernel features. The resulting system is better for it.

klodolph 5y ago

I think the difference is with bash & zsh is down to whether you choose to use them as your interactive shell or whether you choose to write shell scripts in them. I had assumed that this was about shell script portability. Bash and zsh have a ton of super useful features to make work faster, but the features for shell programming (writing shell scripts that other people will use) are not so useful. Yes, I'm aware of stuff like [[, I don't think that [[ is very useful. I have dash as /bin/sh and #!/bin/sh in all my scripts, and seriously, it's not a problem.

forgotpwd16 5y ago
There're many features that are useful for programming: variable expansion, pattern replacement, substing expansion, and others. Not only that but some bash built-ins essentially replace external processes leading to your script being faster and more portable (ironically).
- klodolph 5y ago
  Bash is not alone in having built-ins that make it faster. Generally speaking, Bash is measurably slower than other shells. If you convert make your shell scripts portable and change #!/bin/bash to #!/bin/sh, in my experience, this usually makes them faster, too (on systems where sh is not bash). This is the driving factor for Debian's switch from Bash to Dash, which resulted in noticeable startup speed improvements: https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh (Note that Systemd has since obviated most of that work.) You may be writing very different shell scripts than the ones which I encounter. I'm not sure what you mean by "variable expansion", because variable expansion is portable. Something like 98%+ of all pattern replacement I see is something simple like replacing a suffix or prefix of a string. For example, infile=input.png outfile="${infile%.png}.jpg" You can typically use sed for the complicated stuff. Above a certain level of complexity, I'd likely rewrite the script in Perl or Python, anyway. Or possibly Go.
  - forgotpwd16 5y ago
    For your example, in bash you can do infile=input.png outfile="${infile/.png/.jpg}" Yes, supposing it exists and you've permissions for it, you can use sed. Do that a dozen times and the calls to an external process add up to a significant time. But the real advantage is being easier to write and work with.
Cederfjard 5y ago
What level of portability do you deem necessary for what you do? I rarely encounter a box that has sh but not bash, but maybe that’s just me.
- klodolph 5y ago
  I could equally ask, "What level of Bash features do you deem necessary for what you do? I rarely encounter a shell script that cannot be trivially modified to work on POSIX /bin/sh." At least historically speaking, Bash was noticeably slower than Dash. It's the slowest shell. If you are doing things like, say, build scripts in a CI environment where you need to execute shell scripts thousands of times or more, the 4x difference can make a real impact on user experience. Same thing during startup, back before the transition to Systemd, when Debian changed the /bin/sh alias to point to Dash instead of Bash to speed up system startup. https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash https://unix.stackexchange.com/questions/148035/is-dash-or-s... https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh At some point, shell scripts reach a level of complexity where most people choose to rewrite them in a higher-level language, often Python or Perl, or maybe even Go. My personal experience is that the Bash-isms, although kind of nice, don't really shift that threshold... like, although Bash has arrays, but if I need to manipulate arrays, I switch to Perl or Python. If I just need to pull elements out of one array, I can do that portably.
belorn 5y ago
It seems like if one want to be a bit more focused on compatibility, just using python with compatibility added for v2 vs v3 is easier than using shell scripts for the multiple different operating system, platforms, shells and versions that exist today. Shells seems much more coupled with the operating system and decision that people have made on that level.
- klodolph 5y ago
  Yes, above a certain complexity, you'd probably want to write your script in Perl or Python. Python has an enormous overhead compared to shell scripts, though. If you're writing some simple wrapper in a build system that's going to be invoked thousands of times for a single build, Python could easily end up being a choke point. If you're really concerned about portability, I would probably write it in Perl :-) Perl is basically a souped up shell language, with built-in Awk & Sed, faster start-up time than Bash, and it's installed nearly everywhere.
  - belorn 5y ago
    Perl vs Python on the script side has always seemed to me to be a bit up to taste, through I have noticed on the sysadmin side that in general things has moved away from Perl towards Python. I also notice that in terms of job listing, there seems to be a lack of new perl programmers in order to support older systems. In terms of build systems, what I have most experience with would be with Debian and their build system, which pulls in the required dependencies. Compatibility in this space is less about zsh vs bash and more in line with architecture difference like RISC vs AMD64.
aidenn0 5y ago
Bash arrays are the only thing I really wish dash had. Some other things are "nice to have" but can be implemented on top of sh. Arrays really can't.

BuildTheRobots 5y ago

> Who cares if it's not strictly POSIX compliant: it makes computing a better experience and that's all that matters Whilst I broadly agree with your point, I'd suggest that "better experience" can be extremely "eye of the beholder" - especially if it interrupts a long established workflow / toolkit.

not2b 5y ago
For many, "long established workflow" now means "Linux with GNU userland". But if deviations from POSIX behavior by the GNU tools cause problems for a flow, that's what the POSIXLY_CORRECT environment variable is for.

eadmund 5y ago

> Sorry for breaking it up to you, but this kind of "standards must be respected 11!!!!1&!1" mindset is the actual cult-like behaviour, commonly found in communities such as cat-v.org, and with people clinging to plan 9 like it's anything beyond a failed experiment. That's a bit of a non sequitur: Plan 9 is very much not a standard, and indeed it derives a great deal of its power from not implementing the POSIX standard.

hoseja 5y ago

Like with the `yes` example, those looked like optimizations to me, maybe misguided but surely coreutils should be as optimized as possible.

matheusmoreira 5y ago

Completely agree. Nothing's worse than the cult of POSIX. Half a century ago some people gathered and figured out the lowest common denominator of all the unixes of the time. Now it's 2021 and we're still supposed to restrict ourselves to this "standard" system in the name of portability. POSIX has so few features that restricting yourself to it is masochism. Every unix adds their own extensions, they would be almost unusable if they didn't. So why is GNU criticized for doing the same? The author says GNU is just some optional userland. I find that amusing since in every traditional unix the POSIX userland is deeply integrated with the system. He talks about glibc but the BSDs and even Windows ship with their own libc that I can't ever get rid of because they're the only supported way to interface with the kernel. Linux is the only operating system that actually frees us from this cult. Unlike other systems, the kernel/userspace interface is stable and defined at the lowest possible level: processor instruction set architecture. https://man7.org/linux/man-pages/man2/syscalls.2.html https://man7.org/linux/man-pages/man2/syscalls.2.html https://man7.org/linux/man-pages/man2/syscall.2.html https://man7.org/linux/man-pages/man2/syscall.2.html https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/syscalls https://github.com/torvalds/linux/blob/master/Documentation/... Only on Linux is GNU truly just some optional userland. You can throw it in the trash if you want. You can make your own. Who says you gotta have little commands like cp, mv, grep, sed, whatever? Who says people have to use some "standard" shell from the 80s? You can make a graphical userland if you want. A 100% Rust or Lisp userland. Even no userland at all. People complain about systemd but I actually have a lot of respect for it. The developers had the balls to trash all this sacred POSIX stuff and make something new that actually uses Linux kernel features. The resulting system is better for it.