NixOS needs what is IMO the killer feature of Arch: the wiki.
Comprehensive documentation on not only the OS but the additional packages that we use is what drew me to Arch, and the thing that makes me swear in frustration whenever I have to use Ubuntu/Debian.
NixOS is an excellent OS that has the promise of being every bit as hackable as Arch, but far more stable. Problem is, configuration is very different and needs extensive documentation to reduce that friction point.
The Arch wiki is pretty distro-agnostic (barring package names and
pacmanspecific stuff). I’ve been distro-hopping for past decade and I’ve always used it as a reference for setting things up.It’s distro-agnostic because Arch does very little to modify packages when they’re put in the repos, which means they’ll line up with the packages own man page & readme. The issue comes when opinionated distros modify things like command syntax, etc file locations and default behaviour.
If NixOS is similarly unopinionated, it’d only really have to document its own system layer, but my point is that Arch being guaranteed to reflect a well documented system is what drew me to it.
The way in which NixOS works in regards to packaging, locations of config files and others makes it very opinionated imo. You have to do it the nix way and trying the “normal” way doesn’t work in most cases.
Nothing wrong with having a canonical way to configure things, but if it’s not excellently documented people are going to try doing it the wrong way and get frustrated.
Yeah true, whenever I have problems with some packages like Wayland and its alternative Xorg tools or games, its Arch wiki that helps extremely to fix or understand the situation. Its like many experiences are combined and written in a simple language everyone can easily understand.
On Ubuntu for example, everything feels like its hardcoded, not the standard and its just not even documented. And the wiki has minimal info about the packages.
Fully agreed- I experimented with it around November of last year and absolutely love the idea of it, but the documentation just isn’t there. At the time I found nothing explaining flakes in a clear and concise manner so I had no idea how to use them or add them into my configs. People online kept saying to port the rest of my configuration to flakes but all of the examples online were complex and there was no simple example to build off of. I ended up settling for Universal Blue since it just uses OCI containers and I don’t need a PhD to have a pseudo-declarative environment in it, but would love to revisit NixOS if the documentation ever gets better.
NixOS needs what is IMO the killer feature of Arch: the wiki.
NixOS has a killer feature which obviates a wiki for most such purposes: NixOS options. They document themselves!
You don’t need to look up a wiki on how to install and enable i.e. paperless and all the other services it depends on, you simply set
services.paperless.enableand NixOS configures everything for you internally.The option tells you roughly what it does internally and the other options provide pointers for things you might want to tweak about it. The
services.paperless.extraConfigoption for example tells you how to configure it (pointing to upstream documentation in this case) and even gives an example on what you might want to do.Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.
In NixOS, you simply set
programs.steam.enable = true;. Off to your games.
You wanna customise the Steam package to add additional flags, pass env vars or add additional packages your weird Linux-native indie game needs?programs.steam.packagetells you how to do that right in the place where you do it.
While you’re looking forsteam, you might also come acrosshardware.steam-hardware.enablewhich you need to set in order to make your Valve Index and Steam Controller work properly.
You wanna start Steam in a gamescope session right from the display-manager?programs.steam.gamescopeSessiondoes it for you. No need to copy paste some snippet that you’ll instantly forget about and maybe breaks in a few months.programs.steam.gamescopeSessionis maintained upstream by NixOS, so if it breaks, someone will go and fix that and nobody needs to adjust any of their copy-pasta because they’ll just update as they always do and it just starts working again.None of this is perfect yet and the quality of documentation of NixOS options really varies but I think you get the idea here. I already rarely look at the NixOS wiki to configure my system because the system configuration tells me what I need to do already and this will only get better as options get refined.
the promise of being every bit as hackable as Arch
I don’t think it makes that promise and I don’t think it’s true.
NixOS is about doing things “properly”; applying software engineering to software environment management.
Whipping up a quick hack is much more complicated and time intensive on NixOS than doing so on Arch because it’s way more abstract. You can’t just quickly replace some binary with your own compiled one, you need to use NixOS’ systems to wire in the binary and build it with Nix to begin with.
Maintaining a system (even one with terrible hacks) is much simpler in NixOS however.
You’re underrepresenting the complications of NixOS and overrepresenting the complications of Arch. For example, to install Steam I would run
sudo pacman -Syu steam. On a typical Arch setup that’s all that’s needed.Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.
And that’s why the Arch wiki is so great - it has details and links about everything that goes into making something work. If you want to learn more or if something goes wrong it’s all right there.
But yes, I think you hit the nail on the head at the end there - hackability is Arch’s strength, everything is exposed and flexible to tinkering. It’s easy to make almost anything work, and easy to learn how it works. That’s very different from NixOS’s core philosophy of stability and reproducibility.
There are inherent pros and cons to both approaches - it really comes down to a mix of personal preference and using the right tool for the right job. They’re apples and oranges, and the article framing NixOS as a superior successor to Arch is as silly as the reverse would be.
For example, to install Steam I would run
sudo pacman -Syu steam. On a typical Arch setup that’s all that’s needed.That is incorrect to my knowledge. Back when I used Arch, you still needed to enable multilib which I don’t think has changed. You need a wiki entry to tell you how to do that.
AFAIK you also need to manually install yourself a Vulkan driver. I’ve recently helped a person who had opted for AMDVLK here and it broke in one game but was working fine in others.
That sort of thing doesn’t really happen with NixOS because enabling desktop support implies the presence of a Vulkan driver and we provide a sane one by default (currently RADV via mesa or nvidia when you enable proprietary drivers).
NixOS options. They document themselves!
Didn’t read past that as you clearly don’t understand what the differences between documentation, a tutorial and code comments are.
Do read past that and you might understand why NixOS options are a type of documentation. They’re not “code comments”.
I have tried NixOS, the documentation in many options is subpar. Only the most interesting packages get good documentation. I’ll give NixOS a few more years until I try it again, but currently it’s rather a hobbyist and ‘tinkerer’ distribution. Which is fine, but I don’t want to learn domain specific stuff which is different from all of the rest of Linux.
I installed NixOS on a laptop and tried to run a steam game and it just straight up didn’t launch anything, went to the wiki to figure out the amd drivers, opengl whatever put like 10 new lines in my nix config rebuilt restarted still nothing works, after about 2 hours i just swapped back to arch and the games launched straight away, so for me it wasnt as easy as you may claim it to be. I also tried it on my desktop before and it was a better experience, but still not great. The nix config file is a bit of a mess of options that you have to dig into wiki pages and searching stuff to figure out how to get some stuff to work
If you’re on AMD, all you have to do is
programs.steam.enable = true;. Not dozens of lines copied from some wiki. I should know because that’s all I do in my config to enable Steam on my AMD system: https://github.com/Atemu/nixos-config/blob/450bf3710c77818436f1459e3ea36bf087b6e56b/configs/HEPHAISTOS/default.nix#L16 (L17-L29 are optional customisation).What may or may not work is doing everything
programs.steam.enabledoes internally yourself like some outdated wiki entry might suggest you to do. Given you claim to have been manually configuring opengl stuff for instance, there’s a good chance that’s what you did. You do not have to touch any opengl settings or putsteamintoenvironment.systemPackages.The entire point of NixOS modules is that we have the capability to abstract stuff like this so that you do not have to copy pasta dozens of lines from a possibly outdated unofficial wiki but can simply set one option.
Im like 99% sure i did have that line in my config, and it still didnt work for whatever reason.
Look im not saying NixOS is bad, in fact i really like the idea of it, but ive tried it about 2 times and always came upon something that didnt just work for me, and i end up going into the nixos search thing to try and find what variables i need to put in my config, and its not always 100% clear. On my desktop steam and everything worked fine but i was annoyed at some stuff and stopped using it, on my laptop it just didnt wanna launch any games, idk why exactly that happened but another distro worked fine.
No, you’re holding it wrong. Should’ve looked at the options! 🤡
Having options is not the same thing as documenting those options; well outlined documentation doesn’t just dictate how to do something but also points out what you may want to do i.e. filling out unknown-unknowns.
Just because NixOS makes for an excellent DevOps template doesn’t mean it can’t also be an excellent platform for hacking together random crap. I understand that NixOS advertises itself as the former, but when I say “promises to be” I don’t mean “makes a promise to be”, but “has promise for being”.
Features like: a common configuration interface, safe rollback, atomic changes, nixos-hardware all are features that enable developers to safely hack together solutions, and then have an excellent log detailing what they just did.
Having options is not the same thing as documenting those options; well outlined documentation doesn’t just dictate how to do something but also points out what you may want to do i.e. filling out unknown-unknowns.
Agreed. The point is however that, with NixOS options, you do not necessarily need such documentation for unknown-knowns.
With many things however, we can simply delegate to the upstream documentation for some thing. See i.e. the paperless extra config example. We don’t need to tell users how to configure their paperless, we just tell them that any upstream option goes into this settings option as an attrset.
NixOS options do to a degree fill out unknown-unknowns though, see I.e. the steam-hardware example. I’ve stumbled upon many handy options by searching for related options.
Just because NixOS makes for an excellent DevOps template doesn’t mean it can’t also be an excellent platform for hacking together random crap.
While the initial “hacking the crap together” phase is indeed harder in most cases, maintaining these hacks is much simpler thanks to overrides/overlays and the additive nature of NixOS options.
That quality can arguably make it “excellent” too.
I think NixOS needs an approachable installer or config builder
I’m new to NixOS, just installed it a few days ago, so I can’t say much about it’s pros and cons, but the installer was easy and I installed and booted into the new system very quickly. I think it might have been udpated in the past year, because I am watching a tutorial video from a year ago and he installs it via command line from the live iso.
edit: it also gave me a default configuration.nix which I’ve just been adding to (to get nginx with letsencrypt running, plus extra packages I wanted installed)
Yeah if your knew to nix its even hard to figure out how to install a simple package.
The Nix package manager got ported to OpenBSD, so that part of NixOS must be excellent.
I’m surprised, and really pleased; I was under the impression that Nix required Systemd, and was thus a Linux exclusive. Good to see
Nix (the package manager) does not depend on systemd in any capacity; just like apt, apk or Pacman do not depend on systemd.
NixOS currently uses systemd and cannot be ported without major restructuring. So far the enthusiasm to do that has been very limited. InitWare may be the path forward but that project seems to have stalled.
Note that NixOS also does not support any kernel other than Linux either.It is also available on macos
Note that, while the Nix package manager can technically run on OpenBSD to some capacity, that doesn’t mean packages in Nixpkgs are compatible with OpenBSD.
I can’t comment on the current situation from first-hand experience but I can say that there is no support guarantee as there is for Linux and macOS and that there is no binary cache either. You have to build everything yourself and I’m not even sure we can build even basic packages such as
helloon BSDs yet.OpenBSD has no intention of trying to use Nix packages, my point was that the Nix package manager has useful enough features and functonality that it was ported to OpenBSD to use for managing OpenBSD software and packages.
That’s what porting does, it’s making a program fully functional on a different operating system or different hardware architecture. Compatibility serves a different purpose from porting.
my point was that the Nix package manager has useful enough features and functonality that it was ported to OpenBSD to use for managing OpenBSD software and packages.
My point was that support for BSDs in Nixpkgs (which is the de-facto “standard library”) is still in its infancy. Nix without Nixpkgs is like C without a libc.
That’s what porting does, it’s making a program fully functional on a different operating system or different hardware architecture. Compatibility serves a different purpose from porting.
Terminology on this is a bit loosely defined. What I meant was that the packages in Nixpkgs largely haven’t been “ported” to BSDs yet.
Many of the packages might already be “ported” and would work if other packages lower down in the tree worked. In Nixpkgs we don’t really differentiate between fixing packages so that the package works as upstream intends or making something work that was never intended to work.
There is zero interest in Nix pkgs, that’s all Linux stuff. Every and all Linux packages is incompatable with BSD, and there is no way to make Linux packages ever compatable with BSD.
To port Nix package manager to BSD they change the source code to run on BSD libraries, look for BSD compiled programs, and how run on BSD dependancies, interacting with a BSD kernel.
Installing Nixpkgs on BSD is the same as talking about making Mac OS programs run on Linux, that’s physically impossible.
OpenBSD is not trying to run the whole Nix distribution, they only tool the Nix package manager and changed the source code of the Nix package manager but removing all referances to Nix and Linux, changed the code to run on BSD libraries and changed the Nix package manager source code to look for BSD format files.
Nix package manager on OpenBSD has no knowledge and no understanding of Linux or NixOS files.
I may not have been precise enough here with the wording.
To clarify: Nixpkgs is a source distribution. You can see all of it here: https://github.com/NixOS/nixpkgs
From Nixpkgs, Hydra builds binary artifacts which then get distributed through the binary cache (cache.nixos.org). Users usually use binaries substituted by the cache but these binary artifacts are a direct result of the source, a small set of parameters (mainly platform), some time and some energy, so we usually rarely talk about them. They’re not interesting to us; we could reproduce them at any time by just building again.What I’m talking about all happens at the “source” level, not the binary level. You obviously can’t take a Linux binary to a BSD and expect it to run but you can take a package definition initially made for Linux, try to build it on a BSD and run the result of that.
From experience with Darwin, this works in the majority of cases and usually only requires very few adjustments to the build recipe. With Nix, we have a full expression language at our hands, so we are able to to things like optionally adding some dependencies depending on the platform. We usually do not maintain separate build recipes for separate platforms; they usually use the same build definitions with different parameters.OpenBSD is not trying to run the whole Nix distribution, they only tool the Nix package manager
What do you mean by this? OpenBSD “forking” Nix (a la Guix) would be news to me. Do you have some links for me?
Nix package manager on OpenBSD has no knowledge and no understanding of Linux or NixOS files.
The Nix package manager has no knowledge or understanding of “Linux or NixOS files” on any platform, including Linux/NixOS.
Its purpose is to know how to evaluate and realise Nix expressions.
I can evaluate a Nix expression for OpenBSD on my macOS machine. Nix doesn’t care.
(Obviously I can’t build it but I could theoretically cross-compile it, if support for that was to be wired up in Nixpkgs.)I think you’re misunderstanding a bit how Nix and Nixpkgs work with different platforms.
In the OpenBSD ports and packages tree for user installation here
These are pretty good points.
Is it just me or do large portions of this article feel AI-generated?
The fake excitement sounds like a YouTube influencer acting, but maybe it’s AI. Either way it’s crap.
I feel like I could ask ChatGPT to “write a fairy tale about Nix” to get the exact same article.
I was curious what this would be like. Here you go:
Once upon a time, in the enchanting land of Softwareia, there existed a magnificent kingdom called NixOS. It was a land filled with wondrous programs, magical packages, and a unique way of managing its realm.
In the heart of NixOS, there lived a wise and benevolent ruler named King Nix. He possessed a deep understanding of the mystical arts of software configuration and believed in the power of declarative system management. King Nix had a vision of creating a stable and reproducible kingdom where every program and package would live harmoniously.
Under King Nix’s rule, NixOS flourished. The kingdom’s castle, named “/etc/nixos,” stood tall and proud, housing all the secrets to its magical configuration. Inside its walls, the King’s trusted advisors, known as the “Nixpkgs,” tirelessly crafted packages and spells to ensure the smooth operation of the entire kingdom.
But NixOS faced a great challenge. An evil sorcerer named Dependencyus wreaked havoc on neighboring kingdoms by casting wicked spells of dependency conflicts and chaos. Determined to protect NixOS from this malevolent force, King Nix summoned his bravest knight, Sir Hydra.
Sir Hydra was a mighty warrior, blessed with the power to build and manage an army of software packages. With his magical powers, he could conquer any dependency conflict and ensure that every program in NixOS lived in perfect harmony. Equipped with his trusty sword, “nix-build,” and an unyielding determination, Sir Hydra set out on a grand quest to rid the land of Dependencyus’s dark influence.
As Sir Hydra ventured through the enchanted forests and crossed treacherous rivers, he encountered various creatures that sought to thwart his mission. But with the wisdom of King Nix and the support of the Nixpkgs, Sir Hydra defeated every challenge. He assembled an army of packages, each ready to battle the forces of chaos and maintain order in the kingdom.
With each successful conquest, Sir Hydra’s reputation grew, and soon his name echoed throughout NixOS. Other kingdoms heard of his exploits and marveled at the stability and reproducibility of NixOS. The news spread far and wide, and developers from distant lands sought to learn the ways of NixOS and harness its power.
In the end, Sir Hydra confronted Dependencyus himself. With a swift stroke of his sword, Sir Hydra shattered the sorcerer’s spell of confusion and brought peace to the kingdom. Dependencyus, realizing the strength and resilience of NixOS, abandoned his wicked ways and pledged to help maintain the harmony of software in the realm.
NixOS prospered, and its fame spread across the entire land of Softwareia. King Nix and Sir Hydra became revered figures, their names etched in the annals of software history. Developers from all corners of the world flocked to NixOS, drawn by its elegance, reliability, and enchanting ways.
And so, the fairy tale of NixOS became a legend passed down through generations. It taught the importance of declarative system management, the power of reproducibility, and the magic of a kingdom united under the visionary rule of King Nix and the valiant knight, Sir Hydra.
Not sure, but either way the article is crap.
Fun fact: I use NixOS since six years now and at least in the first two years the Arch Wiki helped me a lot to understand the NixOS configuration options.
That’s the main crux with NixOS, it does a lot of stuff in the background for you that in my opinion you should know why it’s being done the way it is. As such I consider Arch a good distro for a beginner who wants to learn the inner workings of Linux, while NixOS is a better-engineered distribution that takes care of the system for you. Arch’s goal is to be simple for the maintainers which means it’s very close to what one might consider a “standard Linux”, and its wiki is mostly a documentation of exactly that.
I use Nix btw.
I use Arch btw.
I use Nix btw
I use a reproducible, declarative and reliable system btw.
I also use flakes btw.
That font is fucking horrible and so small… I had to make it 160%…
there is a spectacle button on top of the article for us shit sighted readers
I’m normal sighted and that font is waaaay to small.
Tiny font and anime GIFs. WTF
😄 🤣 😂
This article reminded me of how I haven’t run in a single dependency version conflict for years, I’m starting to get what debian users feel like seeing all this new distros fixing problems they never had in the first place
You can thank Flatpak for that. Dependency hell is real, especially on Debian, which ships old libraries. If you stick to default repos, you’re unlikely to directly run into dependency issues, but once you install a program manually or from another repo, it’s another story.
One example you may not have noticed, but which is a direct consequence of dependency hell, and a serious security issue, is for Firefox on Debian 11: it took around 6 months after it was EOL for Debian to update Firefox ESR. Twice (in other words, every single Firefox update on Debian 11).
There were similar issues for Chromium.
Source: https://www.phoronix.com/news/Web-Browser-Packages-Debian (same thing happened the year after, at least for Firefox, I don’t know about Chromium).
It’s almost like patience has its benefits, even if it means being forever behind the proverbial Joneses.
I tried using Arch for a year+, and spent too much time finding ways to fix things that broke with each update. Or fixing Pacman errors that made every package fail. Or filtering the update list to prevent breaking things. Or fixing the errors that using the AUR had introduced to Pacman.
On my debian PCs, I haven’t even had to deal with version upgrades breaking them. I’m definitely missing out on the latest and greatest for most software I run, but I much prefer the peace of mind not worrying about updates breaking anything. I’d probably be a more powerful user if I had taken the time to learn exactly how to balance everything in Arch, but sometimes I just want to spin everything up, patch any major flaws or issues, and then get on with doing what I set out to do. An OS should be transparent when you need it to be.
Wtf no one told me yall had moved here already
On a side-note - what an awesome website.
There is a part of me that wants to try this, but I have one question.
I believe this distribution allows you to have multiple versions of the same library to work with different programs at the same time, correct? Does this mean that each program downloads all its dependencies independently? If the answer is yes, I am staying with Arch. Too much bloat.
this distribution allows you to have multiple versions of the same library to work with different programs at the same time, correct?
That is correct. You can even have programs from entirely different releases running on the same system without conflicting with another; one with i.e. glibc 3.34 and one with 3.37 for example. Or even wilder setups with some packages using musl, other glibc and others yet being built statically.
Does this mean that each program downloads all its dependencies independently?
Each program references all of its (exact) dependencies. Nix then looks at the program and its references and builds a tree of dependencies.
Then it tries to “realise” these dependencies (make them, well, real), possibly by substituting (downloading) them from a binary cache or automatically building them on your machine if they’re not available in any configured cache.However, if some package with the same exact version already exists in the Nix store, no action will be taken. Why should it, it’s already there.
For example, if you were in an empty world and built an environment withhelloandcoreutilsin it, they’d both depend onglibc. If both came from the same revision of Nixpkgs, chances are that they depend on the exact same version of glibc.
What Nix would do here is fetch 1x glibc, 1x hello and 1x coreutils.Note however that you don’t need to manage any of this. You just say “I want
helloandcoreutils”. Nix takes care of getting the correct dependencies in place but they won’t be in your immediate environment. When you then say that your environment should no longer containhello, it does that. At this pointhellowill still exist in the Nix store but it won’t be in your PATH any longer, so it’s not polluting any shared state; it just sits there on disk and the worst it could do is waste disk space. It’s not “installed” in the same sense as what it’d mean to have an unused dependencies installed on an FHS system.
In order to reclaim disk space from unused Nix store paths, you can simply run a garbage collection. You don’t need to care about that one specific hello store path here though, you just say “remove all unused store paths for me, thanks” and Nix removes it along with all other unnecessary paths. In NixOS, you can even have that ran periodically for you.
(Note that this is distinct fromautoremoveand the like; those “clean up” the shared state and free up disk space. In NixOS, these are separate processes and dependencies which you don’t explicitly declare are never in the shared state to begin with.)You see, while this could be seen as “bloat”, it has none of the negative consequences bloat has on other systems such as more packages for you to manually manage, more binaries in your PATH or weird interactions of other programs. It’s just easily managed disk space and disk space is honestly quite cheap.
Not exactly. If one package needs foo as a dependency, and another package also needs foo, it won’t download a second copy.
But if another package needs, say, an older version of foo, it can download the older version of foo and you’ll have two foo packages.
This is possible because Nix packages have hashes to differentiate between them, so any package can ask for the exact version of foo it needs instead of asking for foo in general and hoping the version it gets isn’t incompatible.
Pretty sure this is also different from other containerized package managers, like Flatpaks or Snaps, which I believe throw all the dependencies in with their packages so each package has exactly what it needs in its container, and which is obviously going to be much more bloated than having shared dependencies. As far as I know Nix on the other hand doesn’t get any more bloated than other distros (keep in mind that regular distros like Arch will still sometimes have multiple versions of a package, for example Python).
Yeah. I feel the same way. I remember NPM (nodejs) had this exact issue and you would end up having so many duplicate packages.
I believe shared dependencies are not duplicated.
Each version of a library (or any package) will only exist once, and things are garbage collected when not referenced.
Tbh i would not mind the extra bloat if it meant i get stability.
I think Nix is a really cool distro but the whole config things is really hard to learn, I wish there documentation was easier to understand as a nix noobie. I’ve used arch and many rolling release but nix configs are hard to learn. I really want to learn how to use nix, if anyone has any good sources for learning configs, id be much obliged
Try this: https://zero-to-nix.com/
Thank you because the configs are one of my biggest hurdles as well
Thanks!
Does nix have access to the AUR?
No.
But Arch supports around 14,000 packages and any branch of Nix has around 100,000 stable and 100,000 unstable packages.
How the fuck does Nix have so many. And who’s packaging them all.
Do different versions of the same libraries count as an entry in that seemingly enormous number by any chance ?
If what I hear it’s true than once a NixOS user is up and running adding additional packages and up-streaming them appears to be a fairly simple process.
Something like Arch has ~10,000 packages in the main repo and the AUR has ~70,000 packages. It’s hard to get something into the Arch repo, very easy to get something into the AUR. NixOS seems like it may be a middle ground where by the time someone can grok the system they should only be a step or two away from contributing to it.
I’m sure it’s a factor. I don’t use Nix but from what I gather the easiest way to run a package is often to add it, and upstream are pretty accepting. The number isn’t that wild if you compare it to something like Arch+AUR. Also Nix wants to do it all and replace stuff like pyp and other native package managers, I think pyp alone is responsible for >5000 nixpkgs.
If you are counting different versions then it’s hundreds of thousands…and I think you can mix and match them.
I’m assuming you mean the ability to run an AUR-helper and automagically install from PKGBUILDs; in which case, the answer is no. IMHO, lack of AUR access isn’t as big of a deal as it used to be since Flatpak covers a good portion of what I have downloaded from the AUR in the past.
deleted by creator
See, that’s the feeling Ubuntu/Fedora users had when hearing how Arch would solve all their inexistant problems.
The bottom line is, there are a lot of Linux distros, most of them are great, so if you’re happy with your choice then so be it!
deleted by creator
Funnily enough, when I upgraded from a SATA SSD to an NVME, I didn’t have to reinstall anything. Instead I just moved the LVM LVs to the NVME and rewrote the boot config. Just booted up from the existing installation without having to install anything.
Of course,tune2fsreports the right age for the filesystem:# tune2fs -l /dev/mapper/VolGroupSSD-ssdvol | grep created Filesystem created: Thu Jun 16 10:33:49 2022 << This used to be the root fs, inside the SATA SSD # tune2fs -l /dev/mapper/VolGroupSAT-satvol | grep created Filesystem created: Mon Nov 14 14:13:49 2022 << When I bought the NVME and created a new VG just for the SATA drive
Tried Guix (Yeah not Nix, but similar principles), didn’t really like it and came back to Parabola.
Nix and Common Lisp seem to sit in the same space – it’s spoken of extremely fondly but has difficulty escaping the lab. For some reason it’s extremely technically capable, but fails to find widespread adoption.
Add Guix to this.
