Hi everyone!
I saw that NixOS is getting popularity recently. I really have no idea why and how this OS works. Can you guys help me understanding all of this ?
Thanks !
this comment reads suspiciously like it was written by an LLM (eg ChatGPT). was it? please don’t do that!
@dessalines@lemmy.ml @AgreeableLandscape@lemmy.ml @wazowski@lemmy.ml @k_o_t@lemmy.ml @nutomic@lemmy.ml @kixiQu@lemmy.ml an admin is telling me not to use LLMs. Is this the official stance of this instance? If so, please let me know so I can find another instance and add it to the rules, if not please choose admins that actually enforce the instance rules without making them up.
thanks for clarifying. i’m deleting your generated comment per rule 4 (spamming) as well as two other generated comments you posted elsewhere; if another admin wants to undelete any of these i would be surprised.
please do not post LLM-generated comments without clearly labeling them as such. imo this is common sense, and doesn’t need its own rule, rule 4 is sufficient.
The admins did not remove the comment, a community mod did. Mods can impose further restrictions on their communities on top of instance wide rules (within reason of course), including banning LLMs. Lemmy.ml at least does not have a blanket ban on LLMs, but generally it’s expected that, 1, you should not post LLMs excessively, we mainly want to host discussions by humans, 2, you should disclose it’s from an LLM and which one it’s from, and preferably add to what it says with your own comments or analysis. If it’s a mix of LLM and your own writing, say so at the start of the comment, but if the community directly disallows LLMs then you shouldn’t post it there at all.
If OP wanted a response from an LLM, they would have typed their question into an LLM. The least you could do is label it as such.
I don’t know whether just using an LLM is a problem. But in your case I would say the fact you used one and didn’t indicate you did. If you indicated the answer came from an LLM, then the trust in the answer could be weighted accordingly by each user.
That’s my opinion at any rate.
Under the soon to be enacted EU AI laws such a bot would be limited-risk application (interaction with humans), the requirements for a text bot aren’t particularly high but also non-negotiable from a best practice POV: Stating front and centre that it’s an AI generated post. It’s also best practice to fulfil criteria necessary for high-risk systems voluntarily, the more you can fulfil I bet the less hostile people are going to be.
The library of congress has an executive summary of the thing.
(EU sources alas are a bit iffy at the moment there’s the commission version and the parliament amendments, haven’t seen a consolidated version yet. When will politicians start using proper VCS)
Do LLMs give citations?
(The citations in this comment appear to be all real links about NixOS, but they are not particularly relevant to the places in the comment where they’re cited.)
Do you use Nix, personally? Also, it’s crazy that I found this post while thinking about distro hopping.
I’m really not sure of where this would be anymore usefull than a simple bash script to install all packages you need since it doesn’t do configs and that rollbacks are supported by some filesystems already. Also Having version specific dependencies is already a thing for flatpacks and such
Part of the purpose of NixOS is providing a means to build a reproducible environment that’s easy to configure, migrate, and rollout. You can absolutely handle configuration of many different programs using either flakes or the native modules provided by nix. You can customize your entire system from firewall entries, to users and their shells, to the kernel itself and the kernel modules you’d want it to load, all in a single file or multiple files. If you want to try doing all those things in bash scripts, good luck and please share your experiences but don’t expect it to be as easy as the Nix ecosystem.
so it does handle more than just conditional packages like the other zealots make it sound like
There is a world of difference between a bash script and something like NixOS. The most important difference is that with NixOS something that you don’t specify won’t be there. Whereas a bash script (or other config management tools like Puppet, Chef or Ansible) only mutate things listed.
So it is very easy to write a script like:
ensure_installed python3
write_file /etc/foo.cfg 'thing = 7'
chgrp users /mnt/backups
But if you remove ensure_installed python3 it will stay installed. You can try to be very careful and always add ensure_not_installed python3 but this is both error prone and dead code as soon as you run it. I used to have a script like this and I used each of configuration management tools mentioned above and always ran into these issues. The exact error flow would be something like this:
- Enable/setup some service A that pulls in package X.
- Disable service A or remove package X because it isn’t needed anymore.
- Write configuration for service B.
- Forget to add
ensure_installed Xbut it works anyways because X is still installed from step 1.
Now you have a non-reproducible config because if you try to re-install or setup service B on a new machine it won’t work because X isn’t present. This may sound like a niche problem but I ran into it almost every time I tried to bring up a new machine using my config.
It is still possible to do this in NixOS as it isn’t completely reproducible (you can have mutable state) but in general it is much harder because any configuration that isn’t specified doesn’t exist. As soon as you remove package X or service Y from your config it is removed from your system. I’ve been using NixOS for 8 years now and this problem is mostly gone. It is definitely more reproducible than bash scripts and it has a tangible effect on my workflow.
I wrote a blog post about it a long time ago but the core is still relevant: https://kevincox.ca/2015/12/21/service-management-with-nixos/.
A simple bash script is not reproducible or deterministic. Also a filesystem rollback is not the same as NixOS’s generation based rollback.
Also, NixOS doesn’t just install packages, all system configuration is done declaratively, which would be a very bad idea to do via a bash script.
I have to check a little harder on what it does since I saw in a vid that you still needed to add your own if statement to get it working I assumed a simple
pacman -Qk xorg-xrtrop 2> /dev/null && sudo pacman --noconfirm -S package1 package2 package3 || echo 'I aint got no x, idiot'
would do the job as well
I’m not familiar enough with Pacman to know what that command does. It’s definitely not as clean or easily manageable for servers as NixOS is. Especially not when you have multiple systems of which you would like some packages to be shared and others not. It also still doesn’t allow you to manage global system configurations.
I’d recommend reading some more; especially w.r.t. imperative vs. declarative.
In NixOS, you’d do something like this:
{ config, ... }:
{
environment.systemPackages = if config.services.xserver.enabled then [
package1
package2
package3
] else [
# You could optionally make headless packages available here
];
}
You don’t need to understand the exact semantics here but you can look at it like JSON but with functions. This is not a “program”, the end-result is just data. You’re not modifying some stateful system state with new state from an uncontrolled source (i.e. the Arch repos) but rather just “outputting” a different dataset.
NixOS then builds a concrete system out of this pure data specification. In this concrete system, those packages’ executables are available in the “global” PATH.
You say “I want a system where x y z are installed” and it does it for you in a standardised manner. With the bash script, you explicitly tell it each step (“install x; install y; install z”). This pure data nature is what’s meant by declarative.
This distinction rules out whole classes of issues you simply cannot run into with NixOS.
Another aspect is that, as long as you use the same revision of Nixpkgs and the same config file, you can re-create the exact same system (almost bit-for-bit). If you were to run your bash script in a year’s time however, you’d get an entirely different system with totally different revisions of software and therefore possibly entirely different behaviour.
This is what’s meant by reproducibility.
You can achieve some of the same things NixOS does using imperative tools but nowhere near the same quality.
everyone
Now that’s what I’d call a stretch…
Overlays. Good package management, and lot of stability stuff.