Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.
The product of a chat with @[email protected]
Nix has the same mix of conceptual simplicity and atrocious user interface as git, but somehow magnified three times over. I've tried it multiple times, but could never get over the unintuitive gaggle of commands.
It's simple. Like git, you search the command on the internet
Yes but git can be reasonable
Have you considered GUIX instead? Same concept, but with added GNU and configured entirely with Guile Scheme, apparently.
It's far better in theory, but in practice it's got some massive issues:
In it's current state it's really only good for emacs, lisps, and some other languages like haskell.
It's much simpler because you're using text files to define the expected state, the cli is there only to tell nix to figure out what it needs to do and to get on with it. Meanwhile with git you're manually doing each of the steps until you reach the desired state.
I only need cd ~/dotfiles/nix/ && nix-channel --update && nix flake update && home-manager switch for everyday package management. It's the nix version of apt update upgrade and install.
nix shell and nix run are pretty useful as well, and you'd want home-manager generations to rollback.
The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn't be used even though they're recommended in the official docs, and you need to get lucky to get the info that you can use home-manager and that one liner.
The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn't be used even though they're recommended in the official docs
I appreciate what you're trying to say, but you're kind of illustrating exactly the point I was making about conceptual simplicity and atrocious UX.
You're ignoring the difference between using something declaratory and imperatively. Just because it's difficult to get to that one liner, it doesn't change the fact you'll still only use that one command. Git by it's nature requires you to use different commands to achieve different results. Home-manager allows you to both update your packages and delete all of them with the same command, because that command is "sync the state with the source of truth".
I don't really care about the declarative/imperative thing, to me how many commands you "really need" is beside the point. This is essentially the same argument as the people who say "git is not complex because you only really need checkout/commit/push, just ignore all the other commands." This doesn't matter when the official documentation and web resources keep talking about the other billion commands. Even home-manager has this warning at the very top of the page that basically tells you "you need to understand all the other commands first before you use this," and "if your directory gets messed up you have to fix it yourself."
These are exactly the same kinds of problems people have with git.
I don’t really care about the declarative/imperative thing, to me how many commands you “really need” is beside the point.
Caring is not required, but you need to at least understand the difference.
This is essentially the same argument as the people who say “git is not complex because you only really need checkout/commit/push, just ignore all the other commands.”
It's really not.
Stage,commit,push,fetch,merge,etc. are all commands you need issue to git in order to manually create a desired state. You need to know what you're doing, and what to do differently if there's an issue.
home-manager switch does all of it on its own. You don't use a different cli command if something's broken, you change the source of truth. All of the commands you might use in an imperative package manager like apt update/upgrade/install/remove are instead that one command.
Even home-manager has this warning at the very top of the page that basically tells you “you need to understand all the other commands first before you use this,” and “if your directory gets messed up you have to fix it yourself.”
It's quite a disingenuous interpretation of "beware: home-manager uses the nix language and so gives nix language errors" and "choosing to create configuration files might overwrite the existing ones for that package"...
If you're using a programming language, expect error messages specific to that language/compiler/interpreter/whatever. And it's not like every other PM is using standardised error messages, you still need to learn to read them.
Config files aren't generated randomly, you need to manually enable the configuration of each package. If someone is capable of getting to the info required to know how to configure a package, it's reasonable to expect that they can guess that changing a config might overwrite the existing one.
These are exactly the same kinds of problems people have with git.
Do tell me how you can solve git problems without changing the git commands.
You're essentially saying that the terraform cli has the exact same problems as the aws cli, and that's just ridiculous. They both let you host your blog, but they do it in a completely different way and therefore have different issues.
So you're saying that it's easier to learn C++ than git, because you only need one command (g++ foo.cpp -o foo) instead of many?
In case you missed topic of the whole discussion:
Nix has the same mix of conceptual simplicity and atrocious user interface as git,
Nobody at any point compared the difficulty of learning the entirety of each of those systems, and my entire point is that the complexity of nix is not in the cli commands...
Still haven't reached the flakes stage. An experimental feature that the maintainers are too afraid to treat as experimental and make breaking changes, but unwilling to name stable because it requires bug-fixes and changes that would be breaking, but too afraid to break because... reasons.
[rest of post]
Anti Commercial-AI license
Hey look, the trend is spreading: you're the second user I've seen doing that.
It'd be nice if the Lemmy devs added some sort of metadata field to support that so that (a) we could have a preference to insert it into every new comment automatically, and (b) it could be reduced to a badge on the comment header or something so that it would be less obtrusive to those of us who aren't trying to do anything that would require us to pay attention to it.
It's pretty easy for home-manager use, but still really useful. You can:
Here's an example:
flake.nix
{
description = "home flake";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
home-manager.url = "github:nix-community/home-manager/master";
home-manager.inputs.nixpkgs.follows = "nixpkgs";
nixpkgs-stable.url = "github:nixos/nixpkgs/nixos-23.11";
# nixgl.url = "github:guibou/nixGL";
};
outputs =
{
self,
nixpkgs,
nixpkgs-stable,
home-manager,
# nixgl,
...
}@inputs:
let
system = "x86_64-linux";
pkgs = import nixpkgs {
system = system;
config = {
allowUnfree = true;
};
};
pkgsStable = import nixpkgs-stable {
system = system;
config = {
allowUnfree = true;
};
};
in
{
homeConfigurations = {
shareni = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
modules = [ ./home.nix ];
extraSpecialArgs = {
inherit inputs;
inherit system;
kmonad = pkgsStable.kmonad;
};
};
};
};
}
The 'code' tag here does not respect newlines, I tried to fix it but this is the best I could do:
`{ description = “home flake”;
inputs = { nixpkgs.url = “github:nixos/nixpkgs/nixos-unstable”;
home-manager.url = “github:nix-community/home-manager/master”;
home-manager.inputs.nixpkgs.follows = “nixpkgs”;
nixpkgs-stable.url = “github:nixos/nixpkgs/nixos-23.11”;
# nixgl.url = “github:guibou/nixGL”;
};
outputs = {
self,
nixpkgs,
nixpkgs-stable,
home-manager,
# nixgl,
…
}
@inputs:
let
system = “x86_64-linux”;
pkgs = import nixpkgs {
system = system;
config = {
allowUnfree = true;
};
};
pkgsStable = import nixpkgs-stable {
system = system;
config = {
allowUnfree = true;
};
};
in {
homeConfigurations = {
shareni = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
modules = [ ./home.nix ];
extraSpecialArgs = {
inherit inputs;
inherit system;
kmonad = pkgsStable.kmonad;
};
};
};
};
}`
The ‘code’ tag here does not respect newlines,
Now there's a newline between every single line of code
It's working perfectly fine for me on desktop, jerboa, and voyager. Also, add a spoiler.
I started with NixOS and now I installed something called "Lix"
Yeah I'm deep in it to return
That's such a bad name, I only see lixmaballs.
How do you like it, that's one of the earlier forks, right?
I'm going to have to come back to Nix/NixOS in a bit. I tried setting it up as a baremetal OS but clearly didn't have sufficient understanding of the Nix DSL to get it to do what I want. Following the instructions in the manual led to a functional system missing the network stack. I'll probably wait until the official docs catch up as it appears that they are quite a bit behind. That and I'm not sure how I feel about a DSL for package management. I'd much rather use JSON or YAML, or even INI or TOML. Maybe if I were a LISP or Haskell guy.
So, after a few hours sunk there, I switched to Fedora Silverblue, which worked out of the box and added Incus via rpm-os-tree. Just need to get the UI setup and I can start moving through my distro list.
I’m going to have to come back to Nix/NixOS in a bit.
Use nix + home-manager first for sure. It's far easier, and you can slowly get into it while making a list of bleeding edge packages.
I’ll probably wait until the official docs catch up as it appears that they are quite a bit behind
Skip them altogether when you're starting out. I gave up on trying nix the first few times due to how bad they are. zero-to-nix.com is better for learning the basics of nix.
That and I’m not sure how I feel about a DSL for package management. I’d much rather use JSON or YAML, or even INI or TOML.
The closest you can get is home-manager with a list of packages in a json-like format. It's really not practical to develop a declarative system without a programming language. A basic example would be variables, more advanced would be to write a wrapper that modifies the package so it automatically runs the required cli commands to use your dediated gpu and nixGL with specific packages (nvidia-run-mx nixVulkanNvidia-525.147.05 obs for example).
It's sort of like IaC where you've got terraform (dsl), pulumi (various languages), and cloudformation (json/yaml). Can you guess which one is universally despised?
Maybe if I were a LISP or Haskell guy.
Then you'd use guix and a dsl made within an actual programming language (much better approach IMO).
The product of a chat with @[email protected]
Can confirm, very productive indeed ;)
There is only a way forward, and once you start, you cannot stop
…which are going to die