• 0 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle




  • I’m not going to weigh in on the specifics of Flatpak vs AppImage, because I don’t know enough about the particulars.

    However, I think the “user choice” argument is often deployed in situations where it probably shouldn’t be.

    For instance, in this case, it’s not the user’s choice at all, but a developer’s choice, as a normal user would not be packaging their own software. They would be merely downloading one of a number of options of precompiled packages. And this is the thrust of the argument. If we take the GitHub rant at face value, some developers seem to be distributing software using AppImage, to the exclusion of other options. And then listing ways in which this is problematic.

    I, for one, would be rather annoyed if my only option were either AppImage or Flatpak, as I typically prefer use software packaged for my package manager. That is user choice, give me the option to package it myself; hopefully it’s already been done for me.

    There are some good things to be said about trust and verification, and I’m generally receptive to those arguments way more than “user choice.”



  • Because the nix package manager places all system packages under /nix/store/uniquehash-packagename-version/

    Where the unique hash is obtained via a Merkel tree of all the inputs. So in particular, binaries and libraries exist underneath those directories, not in the places you would expect from FHS.

    In order to make the system actually work, environment variables are set up and executables are patched to refer to specific paths within the Nix Store.











  • If “D” is physically on the same hard drive, then you’ll probably want to back it up before installing. Technically, you can manage to do it without screwing everything up, but I would not trust myself to. It’s always a good idea to have backups anyway.

    Also, user files typically reside on C by default and it takes some effort to put them on a different drive. Things like Downloads, Documents, Pictures, etc. so it’s worth checking that before wiping as well.

    Additionally, you’ll probably want to format your “D” drive to a Linux native filesystem (eventually, after you back it up, because formatting results in data loss). While Linux does support NTFS quite well, it’s not perfect, and your data would probably be safer on ext4 or f2fs (depending on if you have HDDs or SSDs) (or zfs or btrfs is you’re into COW filesystems).

    In Linux, you have all of your files mounted to a single “drive” called /. Everything is below /, which is called the “root” of your filesystem.

    Typically, user data is stored in “/home” and this resides in the same directory structure as the rest of your OS, but on most systems it’s on a different filesystem or even on a different drive entirely. This is because in Linux it is routine to put a “D” drive just in a folder. On my computer, I have several of these mount points defined, so the different types of data don’t get mixed around, and I don’t have to worry about downloading too much bullshit affecting my computer’s updates.

    Hope this helps.



  • The single killer feature that convinced me to move to NixOS is the ability to very easily keep separate development environments separate. For instance, if you’re working on multiple dev projects that have different minimum requirements, and you want to ensure that (for instance) you don’t accidentally use features from after boost 1.61 for project A, because that’s the stated requirement, but you need features from boost 1.75 in project B.

    In a normal distribution, in order to set up an environment that has the proper version for project A you’d need to set up a chroot, a virtual machine, a complicated set of environment variables in a bespoke script with custom installation paths that you need to set up manually and remember to source, or just install a newer version of boost and rely on continuous integration to catch it if you screw up.

    In NixOS, you can set up different shells which all reference the exact correct version of the libraries required for every project, you can have them installed simultaneously and without conflicts, and there’s even a shell hooking program that will automatically load and unload this configuration when you change directories into and out of the project folder. It makes managing many different projects much easier. It’s like a better version of venv, but for everything.