Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S

Shareni

@ Shareni @programming.dev

帖子
2
评论
614
加入于
2 yr. ago

  • The genesis of a nixOS user

    跳过

  • 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 genesis of a nixOS user

    跳过

  • That's such a bad name, I only see lixmaballs.

    How do you like it, that's one of the earlier forks, right?

  • The genesis of a nixOS user

    跳过

  • 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...

  • Laptop randomly playing media

    跳过

  • You're not using KDE connect perhaps?

  • 已删除

    Permanently Deleted

    跳过

  • Aaah, so that's why it takes them so long to update packages.

    I'll bet you anything they're not reading the code for every random package and dependency. But yeah, with free distros it's at least possible to read everything that's on your machine.

  • The genesis of a nixOS user

    跳过

  • 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.

  • The genesis of a nixOS user

    跳过

  • It's far better in theory, but in practice it's got some massive issues:

    • non-free packages are taboo in the official guix community
    • binary support was lacking the last time I used it (firefox didn't have a precompiled bin for example, and that means you need to leave your browser to compile overnight)
    • far less packages than nixpkgs even when you account for the non-free repo
    • packages are seriously out of date (I tried using it as an additional pm a few months ago, and debian 12 was newer in a lot of cases)
    • essentially no support for some programming languages and package managers (node and npm for example)

    In it's current state it's really only good for emacs, lisps, and some other languages like haskell.

  • Wait, it's all Linux?

    跳过

  • And how is SEL less for a rich person than RHEL?

  • The genesis of a nixOS user

    跳过

  • 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".

  • The genesis of a nixOS user

    跳过

  • It's working perfectly fine for me on desktop, jerboa, and voyager. Also, add a spoiler.

  • The genesis of a nixOS user

    跳过

  • 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 genesis of a nixOS user

    跳过

  • It's pretty easy for home-manager use, but still really useful. You can:

    • choose which packages to install from stable and which from unstable
    • add packages from repos that have flake.nix in them
    • correctly match nix and home-manager versions, and always update them at the same time
    • allow-unfree without nixpkgs conf, so 1 less directory required in .config (if they accepted the "experimental" features it'd be down to 1)

    Here's an example:

     
        
{
  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;
          };
        };
      };
    };
}

  • Wait, it's all Linux?

    跳过

  • RHEL - 16 free licences and you can use them for whatever you want

    Ubuntu pro - 5 free licences for personal use

    SEL - you can try it out for 60 days or cobble something together while testing our enterprise packages

  • How do you prefer to install compilers, interpreters, sdks e.t.c

    跳过

  • On what distros/desktop envs is it possible to have the same taskbar on every screen?

    跳过

  • It's not, Xfce can only have one systray

  • [Plasma 6] How to get virtual desktops to behave like MacOS “Spaces”

    跳过

  • I don't think you can do it with kwin (KDE wm), but if you're using xorg, you can replace it with something like i3wm. Do note you'll lose the desktop, and will need to unbind most KDE shortcuts. It's definitely worth it though.

  • How do you prefer to install compilers, interpreters, sdks e.t.c

    跳过

  • That's pretty interesting, I'll need to give it a try.

  • How do you prefer to install compilers, interpreters, sdks e.t.c

    跳过

  • maybe it wouldn't be as wonky as the AUR since it's Nix at least

    That's for sure, since nix handles dependencies a lot better than pacman. But I meant that due to the sheer size of nixpkgs, and the way you can add a repo to your flakes, there's no real need for it. But that's just pure speculation.

    I think a sensible progression is: nix + home-manager -> flakes -> develop -> nixOS

    You build on previous knowledge without getting overwhelmed. I tried using guixos without ever using guix or nix, and it's really not nice when you have to spend a week trying to figure out how to do something that takes you 5 mins in a regular distro. It even took me a few attempts to get started with nix simply because the docs are abysmal, almost all info is on nixos, and home-manager is rarely mentioned.

  • superfile - A pretty fancy and modern terminal file manager

    跳过

  • I would rather Linux just be able to detect what's missing and install it for me. In the case of a lot of missing components, what it says is missing will be named completely different from the package you need to install which makes it really hard.

    That does happen, but Linux doesn't have anything to do with installing packages, your package manager does. If this package was installed through apt for example, it would also download all of the dependencies. But this package is using a makefile to build and install, therefore it has nothing to do with your package manager.

    Tldr: use the package manager, and don't use DIY packages if you don't want to DIY

    Additional package managers like flatpak and nix solve different issues:

    • dependency mismatch: let's say libreoffice and this package require a different version of glibc -> flatpak downloads both versions and symlinks them in a different location in order for each package to have the correct version while not impacting your system and the glibc your DE is using
    • newer packages: Debian freezes packages for 2+ years, flatpak gives you a fresh version
    • easier packaging for developers: you can package for flatpak instead of having to maintain packages for every popular package manager and distro