Our great sponsors
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
nix-installers
Nix installers for legacy distributions (rpm & deb & pacman) [maintainer=@adisbladis]
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
I think nonguix also uses equivalent machinery for its Steam package: https://gitlab.com/nonguix/nonguix/-/blob/master/nongnu/pack...
Maybe there are docs on repurposing that someone more familiar with nonguix can point to.
Apparently there is an rpm-ostree-friendly RPM build of Nix that can be used to install Nix on Silverblue as well: https://github.com/nix-community/nix-installers/pull/8
It includes some code to get around the group/user management quirks that some other commenters have noted b0rked the Guix installer, so perhaps it gives an outline of how to install Guix on Silverblue for a hacker who'd like to try it :)
I had a couple people attempt this for the dev environment of https://www.oilshell.org/ with Nix (not Guix), and it wasn't entirely successful.
As background, we've long had a set of evolving shell scripts that fetch and build dependencies at specific versions -- like bash/dash/zsh/mksh/busybox to test against, re2c to generate code, CommonMark, Python 3.10, MyPy with pip dependencies, and (bonus) R with CRAN dependencies.
I wrote about 2 problems here: https://lobste.rs/s/s5co2f/where_contributors_have_problems_...
1. OS X and libc, which is not really a problem since our existing scripts don't solve it either. It was just one motivation for Nix that didn't quite work out.
2. The file system layout becomes different, and Oil's shell tests rely on that. So containers ended up being easier. The whole build and test system runs in OCI containers under Docker and podman now, so it's pretty reproducible and automated.
But I still think it would be nice if someone who actually knows Nix and Guix (unlike me) try again. I think you have to write like 10 Nix or Guix expressions from scratch with the exact tarballs that we use. (Otherwise the tests will break even more, because Oil's tests are extremely detailed and find bugs in specific versions of specific shells.)
Right now we have a 134 line shell.nix that tries to reuse Oil's scripts, but I think it doesn't gibe with the way that Nix and Guix are meant to be used. Probably the real solution would be more like 1000 lines from scratch?
I remember that Nix Flakes was what I thought Nix was going to be, but at the time it wasn't ready. I thought Nix was supposed to solve the "it works on my machine" problem but it actually doesn't -- you still need a CI because it's possible to write .nix expressions in ways that break the sandboxing (unlike Bazel where you always get it).
I had ran this by someone who knows Guix and my takeaway was that Guix is basically the same in that regard.
> But I believe libc is fundamentally a “hole” in the sandboxing of Nix, at least on OS X.
Nix doesn't sandbox builds on macOS at all by default, and turning sandboxing on breaks some builds: https://github.com/NixOS/nix/pull/1821
But the libc issue goes deeper. This blog post has some explanation: https://matthewbauer.us/blog/darwin-stdenv-update.html
> Linux is unique among operating systems due to the fact that the Kernel and Libc are developed independently. Linux is maintained by creator Linus Torvalds and a community of contributors. Glibc, the most popular Libc for Linux, is maintained by the GNU project. As a result, Linux has a strong separation between Syscalls and Libc.
> [ ... ]
> To accomplish this, Linux provides a stable list of syscalls that it has maintained across many versions. This is specified for i386 at arch/x86/entry/syscalls/syscall_32.tbl in the kernel tree. The syscalls specified here are the interface through which the Libc communicates with the kernel. As a result, applications built in 1992 can run on a modern kernel, provided it comes with copies of all its libraries.
> The macOS Libc is called libSystem. It is available on all macOS systems at /usr/lib/libSystem.B.dylib. This library is the main interface that binary compatibility is maintained in macOS. Unlike Linux, macOS maintains a stable interface in libSystem that all executables are expected to link to. This interface is guaranteed by Apple to be stable between versions.
> In Nixpkgs, we maintain this compatibility through a list of symbols that are exported by libSystem. This is a simple text list and is available for viewing at NixOS/nixpkgs/pkgs/os-specific/darwin/apple-source-releases/Libsystem/system_c_symbols. The symbol list is created by listing symbols (nm) on the minimum macOS version that we support (for my PR, 10.12). We do some linking tricks to ensure that everything that we build in Nixpkgs only contains those symbols. This means that we can reproducibly build on newer versions of macOS, while maintaining compatibility with older macOS versions. Unfortunately, newer symbols introduced in later versions cannot be used even on systems that have those symbols.
> A side effect of macOS design, is that fully static executables are not supported in macOS as they are on Linux. Without a stable syscall interface, there is nothing to provide compatibility between versions. As a result, Apple does not support this type of linking.
So Nixpkgs does do some things to try to let you peg huilds only to what's available in older versions of the macOS libc, but it doesn't try to let you bring your own libc.
There's at least one libc that does claim this kind of portability of course, and is the subject of lots of good posts here on HN. Maybe the author of Cosmopolitan libc ( https://justine.lol/cosmopolitan/index.html ) might have something insightful to say here.
Not sure about guix, but for nixos we have https://github.com/nix-community/nix-user-chroot
> PYTHONPATH, CPATH, etc are all set up and ready to go.
Does that mean that Guix just exports the required environment variables in the shell rather than wrapping each executable with a bash script [1] like nix does?
If yes, that's great, because the wrapper approach feels like an ugly hack. I found some executables on my nixos installation that are behind three layers of wrappers, and that's probably not the maximum.
I guess nix could improve this situation by making `makeShellWrapper` smarter (if the executable to be wrapped is already a wrapper, merge the inner and outer wrapper), but even single-layer wrappers are annoying, and I imagine they have some performance impact.
[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
You can do a pivot_root based install of Guix: https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROO...
I think nonguix also uses equivalent machinery for its Steam package: https://gitlab.com/nonguix/nonguix/-/blob/master/nongnu/pack...
Maybe there are docs on repurposing that someone more familiar with nonguix can point to.
Apparently there is an rpm-ostree-friendly RPM build of Nix that can be used to install Nix on Silverblue as well: https://github.com/nix-community/nix-installers/pull/8
It includes some code to get around the group/user management quirks that some other commenters have noted b0rked the Guix installer, so perhaps it gives an outline of how to install Guix on Silverblue for a hacker who'd like to try it :)
xmake [1] gives you something like this via `xrepo env shell`.