throwawayish
How many members does the development team behind Nitrux consist of? I think it’s a very cool project, but I tend to be cautious with distros that aren’t safe from the bus factor. While googling for answers; I’ve only seen the primary/main developer being named. Can anyone provide a conclusive answer on the matter?
Cassidy Glass is aptly named after Cassidy James Blaede’s feedback found over here.
If one can afford to pay the higher price, then Star Labs’ (or System76’ etc) laptops will offer far superior Linux support. Modern hardware from non-‘Linux-first’ vendors have shown causing troubles with ‘deep sleep’. Issues like these can and have been resolved on Star Labs’ (or System76’ etc) devices. Furthermore, they don’t only sell ‘Linux-laptops’, but they also contribute to the upstream of coreboot and other Linux projects. Thus, by buying their laptops, one is actively contributing to that cause.
Aight, I actually don’t know a lot about it, but I guess something that looks like an answer is better than none. So without further a due.
First of all, Nitrux is quite unique, so I won’t be able to do it justice regardless. However, I’d say that it being an ‘immutable’ distro with OpenRC and focusing on AppImage (over Flatpak/Snap) is the primary one. It’s important to note that Nitrux’ model doesn’t allow you to install .deb packages natively at all. So in that regard, it’s one of the less flexible among its ‘immutable’ siblings. It does offer great support for Distrobox, so you can install your debs, rpms and from the AUR etc if you so desire within a container instead; you can even install other desktop environments with this. Waydroid works. AppArmor is configured. KDE Plasma looks fantastic on Nitrux, but they offer even more spice through their Maui Shell.
Perhaps consider watching this excellent video guide on dualbooting and multibooting by DorianDotSlash. It was what I used as a reference the first few times I engaged in dualbooting and/or multibooting.
DuckDuckGO for the bangs, with a custom !bang made for my favorite SearXNG instance; on which most of my ‘googling’ actually happens.
DuckDuckGO for the bangs, with a custom !bang made for my favorite SearXNG instance; on which most of my ‘googling’ actually happens.
That’s good to know! And I’m sure it’s beneficial information for those that were unaware of that. However, (unless I’m wrong) the method you described requires you to be deliberate and precise in the placement of your own bang; i.e. bag of d holding or bag of holding d wouldn’t work. As I often just start typing whatever I want to search/look for and only notice midway/afterwards that I hadn’t specified where I would like to search, the built-in ‘bangs’ in Firefox/Chrome just wouldn’t cut it unless I would try to rewire my behavior.
Surely dotfiles are meant to change over time?
Indeed. But any and all changes should await my ‘permission’ of sorts before being committed declaratively (or related) if at all. This might indeed make it hard(er) for software to create and change dotfiles as they will, which is somewhat the intended purpose.
A big downside is that you will have to install the basic nix package manager to get home manager working. You don’t have to use it to install all of your software, but it will still need a /nix and a system daemon for home manager as far as I know.
It’s part of the package-deal I’m willing to commit to as long as the solution suffices 🙂 .
nix doesn’t play well with container environments
I’m not sure what this means.
Perhaps I should have been more precise, but I (seemed to) recall that Nix and/or Nix’ Home Manager were not installable on rootless containers. Though, I failed at finding sources on this. So it might be outdated or just blatantly false (and thus a brain fart). Thus, I’ll edit the OP to reflect this. Thank you for bringing this to my attention!
What specific things are you trying to do with containers and nix?
The final solution should also be applicable in containers. Thus I thought that Nix and Nix’ Home Manager therefore required to be installed/setup within the container environments as well. I might be wrong to assume this, though*.
If you don’t want to install a
bugbig (I suppose), complicated piece of software just to manage dotfiles, maybe you could consider Ansible? I know some sysadmin types who keep their local machine configs in Ansible. It has some nice bonus features, like deployment over ssh (nix can do this too btw).
Did I understand you correctly in that you posit that Ansible is more compact, less intrusive and less complicated than Nix’ Home Manager? I’m not comfortable talking about Ansible, but it seemed to me like a grand tool for complete system management (at least for on new installation). Which, honestly, is pretty cool, but seemed to be overkill for what I tried to achieve here. Though, I’d love to be wrong on this. Furthermore, is Ansible container-friendly ?