291–300 of 336 posts
Earlier quoted context omitted.
There’s also nix-alien which does this but tries to be more automagical.
nix-alien is an older, worse approach that is not that well maintained
Why would you say it is worse, older (does this one really matter?), or not well maintained?
I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…
After spending some time on NixOS I basically decided to hold off until flakes become official and the docs are written with them in mind. In the mean time I just run Arch with Nix home-manager and I'm happy. I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..
Earlier quoted context omitted.
I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well docume…
Oh, I'm interested. Are you using it on servers, or desktop? My concern is the community is small, while Nix's has been booming.
Earlier quoted context omitted.
Can you say why you think nix modules are the "biggest plus" from NixOS? They don't even make the top 5 for me.
When installing Nextcloud I basically have the following 4 options: - Do everything by hand and read through the docs on every update. Does not sound like fun. - Use someones Ansible playbook and hope that they update it on time. meh, also customizing it is not a walk in the park and requires some effort on my side. - Use the upstream Docker container which has the same customization problem as Ansible - Use the NixO…
[0] https://guix.gnu.org/manual/devel/en/html_node/Defining-Pack...
Earlier quoted context omitted.
I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well docume…
4 years can be a very long time in a project, especially when the "network effect" hit around that time, where the active user count (and contributions) grown significantly. Also, the language is quite simple, it's just foreign and you felt more at home with Scheme, so you might not have given Nix as much of a chance. This is the classic "simple vs easy" from the Hickey talk. Documentation is no perfect, but has beco…
The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".
Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…
Earlier quoted context omitted.
If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code. Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long. > * Alienating you from upst…
> If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code. Stable code by this definition experiences some stagnation. But the cost of stagnation is worth it for the stability. That's LTS. Slowly, we'll build enough checks that we can achieve frequent change and still be stable. This is partially here, and "unevenly di…
That concept is not new to stable distro's either. Though the OpenSSH package doesn't do that level of testing in Debian, their tests are here: https://salsa.debian.org/ssh-team/openssh/-/tree/master/debi...
> Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that works you and upstream.
This mindset makes no sense to me. A bug is a bug is a bug.
Earlier quoted context omitted.
Interesting, I didn't realize that that was an option. I've been getting by with buildFHSenv and Flakes, which, despite my complaints, really isn't that annoying. My goal at this point is to eventually compile all my flakes and take on Lutris.
Interesting, I didn't realize that that was an option. As a fellow daily driver of NixOS, you’ve just summed up my biggest problem with it. You can do almost anything, and once you’ve figured out how and why you do it a certain way, that way often makes a lot of sense and the NixOS design can offer significant benefits compared to more traditional distros without much downside. But NixOS is out of the mainstream and…
Earlier quoted context omitted.
Can you say why you think nix modules are the "biggest plus" from NixOS? They don't even make the top 5 for me.
When installing Nextcloud I basically have the following 4 options: - Do everything by hand and read through the docs on every update. Does not sound like fun. - Use someones Ansible playbook and hope that they update it on time. meh, also customizing it is not a walk in the park and requires some effort on my side. - Use the upstream Docker container which has the same customization problem as Ansible - Use the NixO…
Earlier quoted context omitted.
I think the main reason ZFS's native encryption isn't recommended is that there's known bugs in its implementation, especially around key rotation and send/recv.
> I think the main reason ZFS's native encryption isn't recommended is that there's known bugs in its implementation, especially around key rotation and send/recv. Is that still the case? I thought the send/recv bugs at least were squashed a couple years ago?
https://github.com/openzfs/zfs/issues/12014
It might not be the only issue related to ZFS native encryption but, at the very least, as long as this one isn't closed I'm assuming it's still not safe.