4 ms·

> GNU `which` is the de facto standard on Linux Well, no, even on Linux there's no de facto standard. Fedora/RHEL use GNU which, but Debian-derived distros use

by jabl 5y ago

> GNU `which` is the de facto standard on Linux Well, no, even on Linux there's no de facto standard. Fedora/RHEL use GNU which, but Debian-derived distros use the debianutils which, which is not the same as GNU which. > POSIX doesn't cover init, but it does cover many other system calls and behaviours that systemd explicitly rejects Interesting. Can you be a bit more specific? What in POSIX does systemd explicitly reject? And might there be a reason for that?

msbarnett 5y ago
> Interesting. Can you be a bit more specific? What in POSIX does systemd explicitly reject? And might there be a reason for that? The project specifically rejects "caring about POSIX" in its entirety. Poettering has discussed this at length[1]. I'm not criticizing systemd here, I'm merely pointing out that Debian is already perfectly fine with shipping non-portable, aPOSIX or even anti-POSIX software by default (which I think is fine), and that the sudden pearl-clutching around `which` not being POSIX is completely inconsistent with many other decisions the project makes and has made. [1]: https://archive.fosdem.org/2011/interview/lennart-poettering.html https://archive.fosdem.org/2011/interview/lennart-poettering... "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!" The interview notes various POSIX-incompatibilities as they existed in 2011. They have grown enormously since. It surfaces in userland in a huge number of ways, and *BSD ports maintainers have noted that it's increasingly hard to port any number of things due to the systemd-isms (which now extend to logging, cron, home directories, and many other core functionality replacements) they're baking in. Again, this is not intended to criticize systemd, but this is precisely the sort of effect that people are hand-wringing about wrt `which` in bash scripts, but nobody is insisting that systemd needs be removed from Debian for having similar POSIX portability impacts. POSIX compatibility has simply never been a meaningful goal of Debian
- orhmeh09 5y ago
  If Debian is perfectly fine with anti-POSIX, why go to the effort of making and switching to dash over bash? One of the impetuses for that project was bash’s inability to confirm to posix even when launched in posix mode. What’s that about?
  - deleted 5y ago
    [deleted]
  - jbovlaste 5y ago
    Ubuntu made the switch to dash back in 2006 to decrease boot times, as dash is much faster than bash. This was upstreamed to Debian. POSIX compatibility made the transition easier (as most scripts were made to run on many Unix systems, not just Linux), but was not the motivation for the switch. https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
  - mjw1007 5y ago
    As I understand it, the main motivations were speed and memory footprint. Might not matter too much on a desktop, but people also use Debian for smaller things like Freedombox.
  - marcosdumay 5y ago
    The main reason stated at the time was that dash was a much faster executable that would improve the performance on boot and all background tasks.
  - effie 5y ago
    Well Debian isn't some BDFL's project, different authors have different visions that sometimes don't agree with each other. With dash, the original advantages put forward were minimalism, higher speed, and POSIX compliance [1]. But that was a long time ago and when systemd came, the preference for dash may have changed for many Debian authors and maybe dash is just kept in Debian as a token of the past accomplishments. [1] http://gondor.apana.org.au/~herbert/dash/ http://gondor.apana.org.au/~herbert/dash/
chasil 5y ago
The one that comes to my mind is crontab, [which can be] replaced by timer units. These are all the POSIX standardized commands: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ It's also interesting that POSIX specified a job queue environment that nobody seems to use (entry with the qsub command), separate from the simple job system that originated in Bill Joy's C shell. The systemd oneshot service modifier comes to mind as an alternative to qsub.
- orhmeh09 5y ago
  I use qsub daily with sun grid engine. Other derivatives of grid engine and I believe SLURM also implement qsub.
bachmeier 5y ago
> Well, no, even on Linux there's no de facto standard. Fedora/RHEL use GNU which, but Debian-derived distros use the debianutils which, which is not the same as GNU which. Honest question, is any of this relevant? It's a mystery to me why anyone would care as long as it gets the job done. Anyone wanting something else can go ahead and use it. Put differently: it would make no difference to anyone currently using command -v. If the Debian devs have a time machine, they can go back to the start and change the course of history. Otherwise none of the discussion around this issue makes sense.

by jabl 5y ago

msbarnett 5y ago

> Interesting. Can you be a bit more specific? What in POSIX does systemd explicitly reject? And might there be a reason for that? The project specifically rejects "caring about POSIX" in its entirety. Poettering has discussed this at length[1]. I'm not criticizing systemd here, I'm merely pointing out that Debian is already perfectly fine with shipping non-portable, aPOSIX or even anti-POSIX software by default (which I think is fine), and that the sudden pearl-clutching around `which` not being POSIX is completely inconsistent with many other decisions the project makes and has made. [1]: https://archive.fosdem.org/2011/interview/lennart-poettering.html https://archive.fosdem.org/2011/interview/lennart-poettering... "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!" The interview notes various POSIX-incompatibilities as they existed in 2011. They have grown enormously since. It surfaces in userland in a huge number of ways, and *BSD ports maintainers have noted that it's increasingly hard to port any number of things due to the systemd-isms (which now extend to logging, cron, home directories, and many other core functionality replacements) they're baking in. Again, this is not intended to criticize systemd, but this is precisely the sort of effect that people are hand-wringing about wrt `which` in bash scripts, but nobody is insisting that systemd needs be removed from Debian for having similar POSIX portability impacts. POSIX compatibility has simply never been a meaningful goal of Debian

orhmeh09 5y ago
If Debian is perfectly fine with anti-POSIX, why go to the effort of making and switching to dash over bash? One of the impetuses for that project was bash’s inability to confirm to posix even when launched in posix mode. What’s that about?
- deleted 5y ago
  [deleted]
- jbovlaste 5y ago
  Ubuntu made the switch to dash back in 2006 to decrease boot times, as dash is much faster than bash. This was upstreamed to Debian. POSIX compatibility made the transition easier (as most scripts were made to run on many Unix systems, not just Linux), but was not the motivation for the switch. https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
- mjw1007 5y ago
  As I understand it, the main motivations were speed and memory footprint. Might not matter too much on a desktop, but people also use Debian for smaller things like Freedombox.
- marcosdumay 5y ago
  The main reason stated at the time was that dash was a much faster executable that would improve the performance on boot and all background tasks.
- effie 5y ago
  Well Debian isn't some BDFL's project, different authors have different visions that sometimes don't agree with each other. With dash, the original advantages put forward were minimalism, higher speed, and POSIX compliance [1]. But that was a long time ago and when systemd came, the preference for dash may have changed for many Debian authors and maybe dash is just kept in Debian as a token of the past accomplishments. [1] http://gondor.apana.org.au/~herbert/dash/ http://gondor.apana.org.au/~herbert/dash/

chasil 5y ago

The one that comes to my mind is crontab, [which can be] replaced by timer units. These are all the POSIX standardized commands: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ It's also interesting that POSIX specified a job queue environment that nobody seems to use (entry with the qsub command), separate from the simple job system that originated in Bill Joy's C shell. The systemd oneshot service modifier comes to mind as an alternative to qsub.

orhmeh09 5y ago
I use qsub daily with sun grid engine. Other derivatives of grid engine and I believe SLURM also implement qsub.

bachmeier 5y ago

> Well, no, even on Linux there's no de facto standard. Fedora/RHEL use GNU which, but Debian-derived distros use the debianutils which, which is not the same as GNU which. Honest question, is any of this relevant? It's a mystery to me why anyone would care as long as it gets the job done. Anyone wanting something else can go ahead and use it. Put differently: it would make no difference to anyone currently using command -v. If the Debian devs have a time machine, they can go back to the start and change the course of history. Otherwise none of the discussion around this issue makes sense.