My new background

I’m aware, but the appimage I run (Slippi Launcher) will run other appimages, and appimage-run can’t handle that, since it extracts the appimage, then runs the contents, but it won’t automatically do that for other appimages that are run.

Which is why I used a Distrobox and it was awesome, worked like a charm. I used Arch previously, and I just made an Arch distrobox and it worked perfectly.

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.

Gotcha I’ll start playing around with derivations. I also just came to the realization that because of the magic of Nix, I can try these things, and if it breaks it, I can just roll back.

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.

I use Distrobox with my NixOS machine for when I need AppImage support (or some random binary that isn’t equipped for Nix’s weird ass directory layout) and it’s amazing! Pretty much native speed, and when I’m done with it I can just wipe it out. Perfect!

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.

Ooh if you’re thinking of trying something new I recommend Alpine. An extremely underrated distro for a DIYer. It’s really lightweight and simple and its packaging system is a breeze to write packages for (for things you’d usually use the AUR for, since there isn’t an equivalant for Alpine AFAIK). Void is also fun I ran that for a year. Keep in mind, I’m only talking fun. For a good distro that will Just Work™, Alpine is fine, but I think Arch wins on that front.

NixOS is a journey and I have the privelage of having two systems, one “Home” system running Arch that I use usually and my “Roaming” system which I run whatever and is what I take to class and stuff because usually I only use it to take notes meaning minimum requirement is “Be able to log into a tty so I can write a text file”. So being able to use that for NixOS has helped a lot, since if something goes wrong, I can just ssh into my “Home” machine to get work done.

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.

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.

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.

No problem! Happy waylanding! And out of curiosity, an update would be appreciated. I always like hearing how others’ experiences are. It helps when I help others with Wayland.

I personally love Wayland for my system. I use Sway for mine and with support for VRR with my monitor, a lot of the vsync problems people talk about goes away (at least for me). I will say, some things that rely on Xorg screen sharing (Like Discord) will only share Xwayland windows. This is fixed in most applications, but not all. Also screen recording in general is a bit lacking. My main pro for Wayland is I use multiple monitors, and unlike Xorg which caps the refresh rate for the full desktop to the lowest (which for me is 75hz), Wayland allows different refresh rates per monitor, which means if I drag a vsync game over to a different monitor, the fps cap changes.

Wayland is also vastly improved by moving over to PipeWire instead of Pulseaudio. I’ve never had a singular problem with PipeWire and it’s drop-in pretty much. I recommend that as well. PipeWire is compatible with applications that use PulseAudio so you shouldn’t even notice a difference at worst, and will notice an improvement in sound latency most likely.

I think the main drawback about Waypand right now is people have VASTLY different experiences. Which is why I say just try it out. Most big DEs like KDE and GNOME have Wayland sessions that you can choose if you just install the wayland parts. Worst case scenario you go “This sucks” and go back. Wayland is only getting better, though, and I find that a lot of the problems I had even just 6 months ago are pretty much gone. Check in often and just keep your Xorg stuff laying around. That’s the beauty of Linux.