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.

So I can use something like systemd.services to make my own services as well? Because I’ve been wondering how to do this as well.

Gotcha yeah that makes sense, so I’ll start doing this as well.

I didn’t know this before, but a lot of comments said the same! I think I’ll start doing this.

Plan 9 has multi-monitor support?

Bash’s posix mode still has a lot of bashisms. The only way to test true posix compliance is to test with other shells like dash and ash. I have found this is the case a lot of time. People will say it’s POSIX compliant shell, but it’ll obviously only be tested in bash Like at that point just make it a bash script, since pretty much every system under the sun has it.

Ooh yeah I’ll look into that thank you!

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.

Nothing makes me cringe more than seeing 4 unwraps in a row in Rust code. Like are you sure those errors will never happen? Do you really wanna panic?

And then I do it in my own code and I get it again. Rust error handling sucks ass. (I love Rust btw)

I just made a post about my musing on NixOS so maybe read that? (here) Basically after the main learning curve it’s pretty easy to use.

I’m getting the hang of their package manager as well, so if need be I can make my own (Like I would for Arch. The AUR scares me from a security standpoint).

My main advice is to not go against the curve. If the manual says that NixOS does it that way, do it that way, because going against the grain is like going through a cheese grater in this OS.

Unlike Arch where you can do things as you want, in Nix you do things using Nix. You can almost always accomplish what you want, but it’s gotta be done the NixOS way. This is actually a benefit rather than a problem once you get used to it, because it starts becoming second nature, and it is extremely powerful.

I’m weird and use ArchLinux ARM on my Raspberry Pi computers. I think it’s much easier to admin, especially if you don’t need video accelleration, but I use Arch on the daily, so that’s probably why I feel that way.

I also find that Fedora was pretty nice as well, but felt too bloated for what I needed.

Finally, Alpine was amazing. I used to use it as my daily driver for a while as well, and it is nice, lean, and easy to use. The main downside is that it uses the musl libc meaning sometimes packages won’t work, or things won’t compile. That was very uncommon though and the exception , not the rule.

The main problem I’ve had on ALL of those distributions were the clock. The Raspberry Pi doesn’t have a built-in clock, so you need to use NTP to pull the time down, or else it’ll be extremely out of sync. This means setting up your timezone, etc. RPi OS does this for you, but most DIY distros (Alpine, Arch) will not, so you’ll need to set that up.