Add /bin/bash to avoid unnecessary pain

Development
21

I agree this can be a pain, but in my experience either:

  1. We’re dealing with a proprietary binary, in which case we likely need to build a FHS chroot env, or extensively patchelf it (license permitting), or heavily patch and wrap it with makeWrapper for other libraries already, like libstdc++.so. In any of those situations we can just include /bin/bash for that binary.

  2. Or, we’re building FOSS cleanly from source, in which case it’s trivial to patch this inside NixPkgs, and usually upstream is happy to merge the fix. In general you get best results sending them a PR instead of a GitHub issue, particularly since you’ll already have the patch implementation done and tested.

Alpine Linux and some other container runtimes don’t include /bin/bash either, so we have allies in the FOSS world fixing case (2) these days.

While it’d be ideal to never have to deal with (2) at all, it’s possible the cure may be worse than the disease of having to deal with bash incompatibility and irreproducibility.

7 Likes
22

Except after apk add bash, alpine now has /bin/bash. Most (nearly all?) Linux distributions put bash in /bin/bash once installed. BusyBox/FreeBSD/OpenBSD are not Linux after all so not as relevant.

If we want to make NixOS more user-friendly and grow the community, which hopefully we are all aligned on as an objective, we need to fix rough edges like this.

2 Likes
23

We should grow the community while keeping NixOS what is NixOS, which is a system that lacks global state (as much as possible). Exposing more and more global state is a slippery slope, since in the end the most user-friendly thing to do is expose a completely global system (which would also permit running binaries unmodified and without wrappers).

Being a newcomer myself, I have found much steeper hills to climb than the lack of /bin/bash, such as learning the Nix language and all the conventions of nixpkgs :wink: . And you can’t really use NixOS without knowing the Nix language and nixpkgs.

16 Likes
24

I agree with the overall point being made by @tbenst. Nix has a pretty big learning curve, and as a community, it would be great if we could do as much as possible to make it easier for new-comers to get started with Nix.

In this thread, there seems to be a conflict between people who want to keep NixOS as pure as possible, vs people who want NixOS to be somewhat beginner friendly.

Historically, it seems like NixOS has tried to be as pure as possible, even if it means making it harder for some beginners. I don’t necessarily disagree with this approach, but it is possible this is turning off many beginners.

I’ve been in the Haskell community for a long time, and I’ve recently started playing around with Rust. Both Haskell and Rust are known for difficult learning curves, but it seems like the Rust community is doing much more to help out beginners (mostly with documentation, convenient tooling, and a helpful compiler). I don’t have any hard numbers, but it seems like the Rust community is expanding at a much more rapid pace than Haskell.

I’m worried that Nix and NixOS are going the way of Haskell, rather than Rust.

Maybe one approach would be to create a sister distribution to NixOS that maps /run/current-system/sw/ into /usr, /lib, /bin, etc as appropriate. Depending on what you had setup in environment.systemPackages, a lot of software would hopefully run without too many problems.

New users could start off on this distribution until they are sufficiently skilled with Nix, and then they could eventually graduate to the pure NixOS.

@danieldk

I have found much steeper hills to climb than the lack of /bin/bash , such as learning the Nix language and all the conventions of nixpkgs

While this is definitely true, I don’t think it is a good reason to not have /bin/bash. Just because we haven’t removed all difficulties doesn’t mean we shouldn’t try to remove some difficulties.

And you can’t really use NixOS without knowing the Nix language and nixpkgs.

I’ve seen lots of users who get started using NixOS even though they don’t know the Nix language very well, or have a good idea how nixpkgs works. In fact, I would even bet that the majority of users (or at least a large minority) don’t have a super strong understanding of the nix lanuage or nixpkgs.

Most users start out by copy-and-pasting nix code they find online. Some users never really graduate past this stage. And that’s completely fine.

1 Like
25

I think that would be much better than making NixOS less pure by default. Although my understanding may be too limited, but wouldn’t this be possible with just an additional option to one of the environment modules?

Of course, people should be warned of the risks of doing that, but I guess it may be a good springboard. Once people are settled, they could disable that option.

Color me impressed, I wouldn’t expect that, but that’s good to hear. Maybe it’s because I started using Nix on macOS before using NixOS (which breaks more frequently).

2 Likes
26

Related rejected PR: [wip] nixos/lsb.nix: init by matthewbauer · Pull Request #78798 · NixOS/nixpkgs · GitHub
Related merged PR: https://github.com/NixOS/nixpkgs/pull/69057

EDIT: last PR was just reverted by Eelco

2 Likes
27

As https://github.com/NixOS/nixpkgs/pull/69057 is merged, we have 3 almost identical code blocks for
system.activationScripts.binsh
system.activationScripts.usrbinenv
system.activationScripts.ld-linux
and 2 options
environment.usrbinenv
environment.ld-linux
That code duplication is already enough reason to refactor and convert them into a generic option accepting list of symlinks.
And an user could add /bin/bash or /lib or whatever to that list without making PRs

5 Likes
28

volth’s suggestion would simplify the documentation of these exceptions, wouldn’t it? That would be a very big argument in its favour, IMO.

29

@volth looks like that just got reverted :confused:.

Would love to see that as a flake or NUR, along with @matthewbauer’s LSB pull request.

When I started with NixOS I saw buildFHSUserEnv as a viable solution, but it (and nix-shell) are not production-ready, at least for software that I use. I’ve encountered a number of segmentation faults that due not occur outside of that environment, particularly when opening large files and processes with high memory / swap utilization. I don’t mean to criticize—I think these are fantastically useful tools—they just aren’t as tested and robust as a vanilla FHS, particularly for scientific/high-performance applications.

One could argue that we should instead “nixify” the world, and indeed many of us have contributed packages needed for our workflows to nixpkgs. But it’s too onerous to require users to make a nix package for everything and we’ll never have 100% coverage.

As such, the only practical solution I see is to capitulate to (de facto) Linux standards, or at least allow users to opt into this without too much effort. Allowing third party binaries to “just work” would be a huge productivity boon, and does not contradict the benefits of Nix.

zimbatm had a nice related post here: [wip] nixos/lsb.nix: init by matthewbauer · Pull Request #78798 · NixOS/nixpkgs · GitHub

2 Likes
30

But it could negatively impact Nix in two ways: 1. there is less incentive to package software properly, 2. there will be PRs from people with impure systems, which are possibly incorrect, leading to a higher maintenance burden.

I think there is a parallel to draw here with SELinux in Red Hat distributions. A lot of third-party guides recommend users to disable SELinux because it makes it simpler to use third-party software. Fedora/Red Hat prefer people to keep it enabled, to receive one of the benefits of their distributions (strong security) and to catch policy violations and refine the SELinux policies. It’s a discussion that cannot really be resolved, because both sides are right: people need to get things done; but others need to guard that what makes a system unique should not be thrown out with the bathwater.

In the aforementioned PR, Eelco suggested making a NUR repository or flake. Wouldn’t that be a good solution? People could introduce the impurity when needed, but it would not be endorsed by NixOS.

7 Likes
31

Just for reference — you mean this faults do not occur on NixOS if you properly patchelf? Because Nixpkgs is not perfect in more than just not setting FHS envs perfectly, maybe Nixpkgs version of some library is compiled with the flags the program doesn’t like or something like that.

1 Like
32

What a great example. I’ve seen countless tutorials online that start with “First disable SELinux…”. I would hate to see countless NixOS guides starting with “First disable purity…”

8 Likes
33

Why hate?
If it is the way to boost the number of NixOS guides from less than a dozen to “countless”, it is worth to try. And then fix the purity.

4 Likes
34

Once something is supported it is very hard to revert.

I find some of the “pain” in Nix packaging to be very helpful to projects themselves as it helps find impurities in them. Most projects welcome the feedback. I also find a common correlation between project maturity and ease of Nix integration.

Here is a typical interaction with a project:
https://github.com/bash-my-aws/bash-my-aws/pull/247

4 Likes
35

I was thinking of nix-shell: Bus error (core dumped) · Issue #3597 · NixOS/nix · GitHub for example. Using np.memap in a nix-shell or buildFHSUserEnv triggers a Bus error, but works fine in a python interpreter (using the same nixpkgs for all).

3 Likes
36

The custom buildFHSUserEnv chroot script should probably be replaced with something that’s supported by the industry. There are plenty of options out there like firejail that would do a better job and have been battle-tested.

6 Likes
37

I agree with @danieldk that there a bigger obstacles than not having /bin/bash. If a package is generated by a derivation patchShebangs already solves the problem. For binary packages that can not be packaged in a conventional nix fashion we use buildFHSUserEnv. Can someone maybe give an example, which does not fall in the two categories mentioned above, where the lack of /bin/bash is a problem (or at least a big annoyance)?

38

I would argue that what’s exposed in / should be consistent between NixOS and the build environment, which already isn’t the case. Adding more variations only makes these kind of build issues more confusing and difficult to reproduce.

  • nixos /bin/sh and /usr/bin/env
  • builds /bin/sh and no env

A great example of the kind of issues that implicit impurities can introduce git: 2.16.2 -> 2.17.0 by layus · Pull Request #38636 · NixOS/nixpkgs · GitHub.

5 Likes
39

There’s certainly an argument to be made that issues/PRs replacing shebangs or asking people not to use /bin/bash are causing somewhat of an effect outside of NixOS and perhaps it’s up to this community to try and alleviate that, as I fear that it might give NixOS some unpopularity.

1 Like
40

I’m currently on day 3 of trying to figure out what is wrong with my build. It clearly has to do with the shebang thing, but in spite of patchShebang’ing all over the place, I still get “bad interpreter”.

Somewhere in the list of scripts both static and generated something is not good.
I don’t think one can anticipate all the possible uses and don’t see why one should.

/bin/bash is the most minimal expectation.