27 comments

[ 6.3 ms ] story [ 86.4 ms ] thread
> Almost everything is shared between host OS and the JuNest sandbox (kernel, process subtree, network, mounting, etc) and only the root filesystem gets isolated (as the programs installed in JuNest need to reside elsewhere).

And

> Run on a different architecture from the host OS via QEMU

How is it possible to share the process tree between a QEMU host and guest? Network and mounting filesystems yeah that sounds normal but sharing a process tree?

Presumably QEMU is available as a fallback when the guest binaries cannot run directly on the host CPU.
If only the binary is emulated by QEMU and sharing the same Kernel, this should work fine. Similar to what Apple is doing with their x86-to-ARM tech.
For when you want to boast that you run Arch and take those screenfetch screenshots but you don't actually want to properly run Arch because you've got better things to be doing with your time.
Yeah that hour installing Arch to get the best Linux distro on the planet...tough decision!

I'm a long time Arch user and it's just the best system there is. Pacman with the Aur has literally everything in its latest version. When I need anything at all to be installed, it takes me 10 seconds to type a single command and then I have it.

But sure, if you think the install is difficult despite the billions of user guides, Pop OS would be my second choice. It's really really stable and beautiful and fast.

Void [1] gives Arch a run for its money, particularly if you want musl-libc or non-systemd init. I’m a long-time user of both.

Chimera [2] is also worth watching.

[1]: https://voidlinux.org/

[2]: https://chimera-linux.org/

musl sounds like too much of a hassle. Too much stuff out there depends on glibc, if you don't know what software you are going to be running, that sounds like a world of pain.
I'm running void musl, but have glibc musl chroot for problematic apps or use flatpak for stuff like steam.
> if you think the install is difficult despite the billions of user guides

I've installed Arch from scratch many a time. It's not the setup, it's keeping it working that's the interesting bit.

In the last ~eight years of using arch I can count the number of times it's broken on one hand.
This was my experience too. In that time I would have had to reinstall most LTS distros a couple of times or regular distros many times.

I have heard that in-place upgrades are getting better but back in my Ubuntu days I never had luck. It seems like you are always going to slowly accumulate cruft that the installer doesn't fix.

My distro journey started with Red Hat 5.2, Mandrake, Mandriva, Ubuntu, Debian, and settled on Arch. It's by far the most stable system I've used. I managed to bork a Debian stable's dpkg two months ago, I've absolutely never been able to make pacman break.
I used to be a big fan of Ubuntu, up until apps just stopped working because the UI refused to function. Something something pixbuf something. Never had the issue once since taking the time to get acquainted with Arch. So glad Ubuntu broke for me.

Starting with Arch taught me way more about Linux than anything, and also had a factor in starting me on the path of using Emacs, and a tiling window manager.

I've only ever broken arch once and it was totally my fault. I broke Debian and Ubuntu a lot more.
I think the Arch installation is the best way to understand the basic plumbing behind a linux distro.
Has anyone here tried to run this in NixOS?
It's not in nixpkgs, so I guess nobody's made a derivation for it. It would be nice.
adding a package to nixpkgs is much more hussle than writing an experimental derivation for an interesting package
Finally I can use Arc, btw.!
Fabulous.. i had been toying with PoC-ing exactly this ("there is a pkgbuild for most of the random small projects i use, can't i just use that? I like my Debian/Ubuntu/Pop base system, but I hate checking for a new GitHub release all the time/using an appimage/flatpak/etc bundle/manually pulling and building master/etc")
This saved me once to enable me to install my own updated tools on an outdated centos (as non root user). Really nice!
What I'd like to see operating systems do is move to a simple YAML or similar format for creating install configs. I think cloud-init has something similar but always had issues.
GNU Guix can do that. You can describe [1] the system in Guile Scheme and you can install a system or create a virtual machine image from that configuration.

[1] - https://guix.gnu.org/en/manual/en/html_node/Using-the-Config...

This is very Nix like, and what I'm really asking for is a simple YAML markup file to define the OS, packages, devices, encryption, users, etc. Arch has something similar but it is a cluserfuck to be frank. Also, there are some edge cases that I'd like to see included like using a detached LUKS header.
Check out some Guix package definitions. They are written in a declarative style. It looks closer to YAML than code.
Oh god I’ve been looking for this so long! Pop OS my daily driver but I miss Pacman and Yaourt so much. APT is shit :/