I like to eat noodles. Yummy!

  • 1 Post
  • 13 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2023

help-circle
  • Or maybe terminal emulation needs to be brought up to speed with modern computing. New terminal specs and all that.

    Nothing is better for remote computing and administration than a terminal. It’s far too data data dense for anything to be competitive.

    Nothing is better for quick and easy iteration of programming ideas than a quick text output in a terminal.

    It doesn’t need to be destroyed, it needs some iteration. It’s an old technology with a lot of cruft.



  • Sorry for the late reply. In the 2 weeks I’ve still kept using it and I learned a lot! But a lot of my musings still stand, at least in my mind, but after thinking a little longer, a lot of the thoughts I had also apply to other distros as well.

    To answer what you asked in final, a good hypothetical that might answer it is something like GNOME. If the nixos channel blew up in a doomsday scenario, I’d be stuck maintaining my packages myself, right? And I use the doomsday scenario, because the problems here apply for self-made packages as well, but it’s easier for me and maybe others to wrap their head around the problem I’m getting at. So with GNOME, I’d have to update every single dependency manually in my nix files. With something like Arch/Alpine I could just have those files, and they have these really neat scripts where I can just bump the version, and it’ll download, set the hash up, and bump the version all for me. With Nix there are no such tools. I can’t just automate the process, nor is it feasible to do this type of thing manually. As new features are added, so are new options needed to activate those features. And yes, although in this scenario, I would probably just opt to not add these options and set it up myself, when making a package for the general public this isn’t the case. If GNOME adds a feature (idk why I picked GNOME I haven’t used it in like 5 years) to have extensions managed by the package manager, I’d have to add an option for what extensions are needed and all that. And this is a lot of work, at least as far as I know. The extensions would also have to be packaged.








  • I used Void for a while and I loved it! I had to move off because I kept having to make packages for the esoteric programs I kept using (cc65, Zoom, etc.). but I loved every bit of it. Even making the packages was pleasant, and it’s the first distro I ever contributed packages to.

    Also, at the time I was using musl, and it was good, but not perfect. I’d recommend the glibc version for 0 headaches, but the musl version was very fun.


  • I could’ve worded the configuration part a bit better. My gripe wasn’t necessarily with that, but more with “If I ever had to make my own package from scratch including dependencies, this would be practically impossible” Nix’s derivations and other packaging information is crazy complex and keeping track of versioning, etc. is a nightmare. I think often about doomsday scenarios for systems. It happens, just look at CentOS and all that, so my main thing was if something like that happened, could I maintain the packages I use manually, and the answer was no. Of course I’m not in a doomsday situation, so I’m fine with it as it is. It’s just a thought I had, and that was my conclusion.


  • I guess I could’ve worded this better but my second problem was: I would like to do everything declaratively. What do I do when a package doesn’t have its own declarative configuration options? Before it was simple because it was imperative, so I could just change the config file, but not so much in NixOS.