Laser

I mean why would you be fully against flatpak? I use NixOS without it and always packaged natively on Arch, but especially when upstream offers flatpak, it makes sense to enable it. Keeps the user-facing programs up to date and somewhat sandboxed while you can have a stable release beneath it. Especially if the system's actual users aren't that tech-savvy.

Stuff on unstable tends to break, especially electron-dependent derivations. Stable doesn't always have the latest and greatest. Flatpak seems like a good compromise for desktop applications in some cases.

Regarding some of your points:

1. Depends on the case. A script operating on stuff in its subdirectories will probably be better with a relative path, especially if they get moved somewhere. Same logic goes for symbolic links.
2. This is called string manipulation. ## deletes the longest match from the beginning, so it deletes everything to the last slash, as the asterisk expands as far as possible. If you wanted the directory the file is in using this method, you'd use ${file%/*}. This deletes the shortest match from the end. You also have the dedicated commands basename and dirname for this.
3. Can't comment
4. I guess this works as long as you get exactly one match.

The refresh rate most people think of doesn't go into the modelines. An 800x600 60Hz modeline looks like this:

Modeline "mymode" 38.22 800 832 912 1024 600 601 604 622 -HSync +Vsync

It should be noted for the newer users that miscalculating your modelines could destroy your screens, so getting them right was kind of important.

People switching nowadays have it so easy lol. When I switched, you'd still have to configure ALSA or OSS, tweak xorg.conf, use Nvidia because AMD was just not working (I did try and dual boot Linux before when ATI still existed but didn't fully switch), DXVK didn't exist, Vulkan didn't exist and WINE was still pre-1.0. And all this during a time when Microsoft had what some people consider the best version of Windows.

I don't really miss those times. And I know that it was even less convenient before. I also had a copy of SUSE Linux 9.0 or something from a family friend who ordered these from SUSE. And Mandrake I tried very briefly. But I wasn't really computer literate enough to teach me all that stuff myself so I consider my Linux journey starting in 2007 when I ordered a new PC and decided not to install Windows on it so that I wouldn't have that alternative in case something doesn't work.

Interesting that you mention it. I mainly use fish but always do some stuff in nu to check out its progress. They are in my opinion the two most interesting interactive shells at the moment that I know of, the third shell I keep an eye on is oil but rather as a replacement for bash when used in scripts rather than interactive. The project also has ysh which also doesn't look too bad and seems to go in a similar direction as fish.

Let us know when you do! It's a huge undertaking and NixOS has a pretty big network effect. Doesn't mean no one should tackle creating an alternative. I fully believe declarative distros are the future for any production environment and that the space is far from taken by current distributions.

Good points. If you go through the open pull requests on nixpkgs, there's a lot of stuff that never got through and it's not obvious as to why. I was happy to see a lot of stuff merged less than a week ago. But at this point, there's a huge backlog.

As to forking NixOS, which in my opinion means forking Nixpkgs, Guix system seems like a good start. I decided for NixOS because of proprietary packages as I use Steam, and support for secure boot which while still young and only through lanzaboote works very well for what I use it.

As I mentioned somewhere else, getting a system to do what you want is the easy part. The impressive part is offering a solution that can be sustainably maintained long-term, at low effort for the user.

I wouldn't call LFS an actual distribution. Also, while anything but easy, getting a Linux system up from scratch is the easy part. Actually building an infrastructure to maintain it is hard.

Personally, I'm not the biggest fan of Debian's and by extension Ubuntu's development and distribution model. That being said, it's my personal preference, and not an objective judgement on quality.

Mint doesn't really have any features that make it especially interesting for advanced users that it doesn't inherit from Ubuntu or by extension Debian. Or does it?

Again, not trying to shit on it or anything, but Mint's goal was always to create an easy distribution, which is no small feat. But this is nothing I'd associate with "advanced users".

How to read NixOS documentation:

1. Go to wiki, see if topic exists
2. If it does, notice how it doesn't cover your case
3. Use the hints from the wiki to get your search engine redirect you to https://ryantm.github.io/nixpkgs/
4. Notice it still doesn't cover your use case
5. Use search engine again, this time with the hints from aforementioned page, to arrive in the proper code in the nixpkgs repository
6. Read annotated source code to see what actually happens

Yeah, this is how I found https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh yesterday because I wanted to install some shell scripts that needed to be adapted.

Don't get me wrong, maintaining a distribution the way NixOS is a huge effort and I can't praise the maintainers and developers enough. The ecosystem they've built is unlike I've seen anywhere, and the technical foundation is sound – in fact I'd wager more sound than what commercial distributions offer. The latter just have more grease. But I do understand the criticism about lacking documentation. But human labor is scarce, and I mean look at me posting this here instead of improving it.

There's also no good guidance or best practices for packages in nixpkgs and stuff is permanently changing (which in my opinion is good). E.g. did you know that new derivations should be sorted by letters, not categories, and not go into all-packages.nix? At least if your derivation doesn't require fancy attributes (pardon me if that is not the correct term). Or that stdenv.mkDerivation rec {…} is not best practice, but rather stdenv.mkDerivation (finalAttrs: {…})? And why the latter even works?

Writing good documentation for a system, especially one that's permanently evolving, is not easy, and I prefer all efforts going to actually maintaining and evolving the system itself than trying to get the perfect documentation that's outdated in a matter of time. And without trying to gatekeep it, NixOS is a distribution for advanced users. I recommend it to everyone who has a solid understanding of how a Linux system is composed because I think it's important what NixOS abstracts away from you. And as an advanced user, reading commented code once in a while is fine in my opinion.