silent_water [she/her]

  • 0 Posts
  • 30 Comments
Joined 3 years ago
cake
Cake day: October 26th, 2021

help-circle








  • I think one of the issues with nixos learning materials is that they eschew talking about how to write your own packages. but to really understand anything, you have to get your head around writing and modifying packages. in nix, a package is just a build step that can do I/O during particular phases and produces an output to the nix store, so they’re an essential building block for anything that isn’t utterly trivial.

    the other major stumbling block is working out how modules (the things that let you write config for the system) can actually be composed. adding a new module to imports gives you new config params you can set so you can organize your system config in terms of modules and packages to make things work the way you like.

    Nix Pills are the canonical learning material for packages. I don’t know of any good learning material for modules - I learned by working on nixpkgs and another involved project that made extensive use of modules.

    lastly, nix config files are written in the nix language and it’s a bit idiosyncratic. it almost looks and feels like Haskell but it’s slightly different in important ways. there’s no way around learning it if you have multiple systems and want to share config between them.






  • no worries! you want a separate boot partition on your hard disk to make this all easier. if you don’t have one already, I would make one, then go back through the arch install. at the end, there should be instructions on how to update the grub.cfg for arch. you’ll need to do the exact same thing for Ubuntu. the only hard part is that Ubuntu is set up right now to not mount a /boot partition so when you install updates, the updated boot images won’t get installed in the right place. so you need to boot into Ubuntu first and change /etc/fstab so it mounts the boot partition to /boot. then you need to run:

    sudo update-bootloader --refresh
    

    then you can go back and do the arch install with the same /boot partition and run grub-install. there’s detailed instructions on how to change the boot partition here and the ArchWiki should have the rest.


  • no like you can skip the entire grub-install part and just mount your ubuntu /boot partition as your boot partition in arch and go through the normal install process. then at the end, you just update the grub.cfg to include the arch install.

    edit: if you don’t have a separate ubuntu /boot partition, you’re going to need to reinstall it with a separate boot partition, or configure the bootloader in arch and do grub-install but stick in the ubuntu boot block into grub.cfg. the issue is that you’re still going to need to update the configuration on the ubuntu side so it uses the arch /boot partition and installs kernels there.






  • when you say “something is not properly supported” what do you mean? like nvidia/amd haven’t released graphics drivers yet for linux? or some peripheral isn’t recognized?

    basically, by buying new hardware just after it launches, you’re effectively one of the very first people to boot that hardware with linux. you can usually make it work but most hardware manufacturers don’t work with the linux devs to make sure support is in place. so devs have to get ahold of the hardware retail and then fix whatever is broken. the exception to this is AMD and Intel - both companies have people working on linux so they will merge support for new hardware into the kernel before that new hardware is even announced to the public. so if you stick to cpus and video cards from those two manufacturers, you’ll make your linux life easier.

    even then, though, the support might exist in the latest version of the kernel, but the last Ubuntu or Mint release is still several versions behind. so you’re effectively forced to use a distro that releases updates much faster (ie rolling release), or be willing to make modifications to the system post-install to get it to work.

    tl;dr: you’ve got a constellation of requirements that can’t all be met at the same time. either give it 3 to 6 months after release of new hardware or be willing to learn how to make it work. expecting software to work with hardware it hasn’t yet been designed to work with is always going to be a recipe for failure.