Lightweight Arch-based distro that runs, without root, upon any Linux distro | Hacker News Reader

Lightweight Arch-based distro that runs, without root, upon any Linux distro

github.com

109 pointscosmojg21 comments

This has officially replaced Linuxbrew as my go-to solution for package management on multi-user Ubuntu machines at work. Now, I'm trying to see if I can't pair it with QEMU to replace Homebrew on my work laptop running macOS.

>Now, I'm trying to see if I can't pair it with QEMU to replace Homebrew on my work laptop running macOS.

By qemu, do you mean qemu-user rather than qemu-system?

That'd be a quite interesting approach.

That is exactly the thought it my head. Linuxbrew just barely works and breaks frequently. I wonder if this would be more reliable. So you can run current tool versions of tools on an older machine.

I wonder if this works on older systems. A good use case would be if you are on a managed system and have an uncooperative admin, don't want to bother to ask for them to install new software, or a package is not available for your OS. However this seems to be built against a regular recent kernel?

A couple of years ago at the university I was stuck on an old CentOS / Scientific Linux release, but needed Skype and a newer version of Chrome. So I built glibc + GCC in my home directory, and used patchelf to make the binaries look for libraries in a relative path instead of in /usr/lib. It was annoying to get running but in the end worked like a charm.

So you build glibc and GCC with the CentOS supplied gcc in something like ~/opt then used that to build Chrome?

I'll bet there was some fiddling and well done.

Just wondering what version of CentOS, i.e. how old the Xorg and GTK stuff was.

Scientific Linux shipped with some ancient stuff, like they moved to GTK 3 in 2020. https://distrowatch.com/table.php?distribution=scientific

That must have been around 2011, 2012. I don't know which CentOS version it was. It was the current supported version, so not ancient, but not exactly bleeding edge. The problem was that closed source stuff like Chrome didn't work because they only considered Ubuntu and maybe Fedora?

You had to build glibc and GCC in unison, and building them is always difficult, especially the first time. But once I figured out the steps (configure, make, ...) it was easy. The only fiddling was to get all the executables to use "rpath=$ORIGIN" so I could just pop it in my home directory and it would reference the correct variables.

I didn't build Chrome (I'm not that crazy), in fact the above was done so I could avoid building Chrome and just run a Chrom(ium) binary. I think the main reason for this ordeal was to be able to run Flash :-D but I also learned a bit about GCC and so on.

You could just use pkgsrc. Joyent has binary packages.

I had exactly the same experience in building a glibc and gcc, and it was also on an old CentOS system on HPCs that are not updated and I do not have root privilege to. I used linuxbrew to build glibc and gcc.

In my case it was that VSCode remote delivers a node to remote machine that requires a new glibc, where the HPC does not have. I have to use patchelf to patch the node runtime in order for it to find the glibc libraries I built.

I am so glad there finally more products that allows me to easily run newer software, and glad to see it is Arch Linux, which always have latest software and is my go to for dev machines.

> In fact, the purpose of JuNest is not to build a complete isolated environment but, conversely, is the ability to run programs as they were running natively from the host OS. Almost everything is shared between host OS and the JuNest sandbox (kernel, process subtree, network, mounting, etc) and only the root filesystem gets isolated (since the programs installed in JuNest need to reside elsewhere).

> This allows interaction between processes belonging to both host OS and JuNest. For instance, you can install top command in JuNest in order to monitor any processes belonging to the host OS.

So this is more similar to something like pip/npm/composer than to docker?

Are there any overheads using applications via JuNest compared to directly running it on the host?

> The Linux namespaces represents the default backend program for JuNest.

So no, you can think of it like docker without the sandboxing from the host. It just swaps out the host environment for the junest one similar to a chroot but doesn't require root (unless you're using the chroot method)

Only the PRoot method has some overhead, as it hijacks system calls with ptrace(). Linux namespaces or chroot shouldn't have noticable overhead.

If you are looking for similar solutions, there are:

Gentoo Prefix (can also run on x86 macOS): https://wiki.gentoo.org/wiki/Project:Prefix

Nix (note: not NixOS): https://nixos.org/download.html#nix-install-linux

pkgsrc: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/bootstrap/R...

Nix needs root to install unless you do some extra work.

How is that different from chrooting into arch linux base install?

This is part of the Installation Howto IIRC.

The chroot() syscall requires the user to be root.

I was hoping for something like rootless systemd-nspawn.

AIUI messing with namespaces and/or cgroups does also require root.

I think that would make a good docker shim os

similar to andronix to me,a user mode linux basically,need play with it.

Reply on news.ycombinator.com