A rather tame and boring release, which is perfectly fine after the bomb that was 9.0
- Posts
- 0
- Comments
- 105
- Joined
- 3 yr. ago
- Posts
- 0
- Comments
- 105
- Joined
- 3 yr. ago
I meant that just because I don't know about it doesn't mean that it isn't possible.
They cover a few things -- most notably they replace channels, which are imperative.
True. I never considered channels imperative, but rather a purity issue. But I guess this is a matter of perspective.
Unless I'm way off, you can also install user software through flakes if you add them as inputs.
I don't know about this, but that doesn't mean anything.
You can also pull a repo and 'nix run .#software' from the command-line, without entering a shell.
True, though this by default only runs the default binary, and you're probably in a shell anyways, so it doesn't save that much. Also that output is, to my knowledge, not protected by garbage collection. But my knowledge of any imperative stuff is minimal, so I don't know if that's the case there.
I don't think flakes can do much more declarative than "legacy" nix, rather they increase reproducibility and purity. Also their tooling doesn't offer imperative stuff by default, but I'm not sure they cover use cases previously solved imperatively. E.g. I don't think you can install user software through a flake. Sure you can create shells with software available, but that is also possible without flakes.
Maybe my understanding here is wrong though.
NixOS itself by default isn't fully declarative anyways, nix-env for example is imperative and very comparable to flatpak regarding applications.
I welcome the efforts to move away from all imperative bits in NixOS though. My point was rather not to dismiss an article on NixOS for mentioning flatpaks.
They're not that different from the classic nix files. Their main difference is that their inputs are always well-defined (as opposed to a channels registry, i.e. you can get totally different systems by reapplying a configuration when you change channels which doesn't change your nix file at all). A configuration is always exactly described by a flake.nix and flake.lock.
I mean there is more to it, but this is the primary motivation. What you would normally put into use case specific nix files goes into a flake's output section. The stuff in your input sections is what you can use in there.
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:
- 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.
- 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 commandsbasenameanddirnamefor this. - Can't comment
- 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 +VsyncIt 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:
- Go to wiki, see if topic exists
- If it does, notice how it doesn't cover your case
- Use the hints from the wiki to get your search engine redirect you to https://ryantm.github.io/nixpkgs/
- Notice it still doesn't cover your use case
- Use search engine again, this time with the hints from aforementioned page, to arrive in the proper code in the nixpkgs repository
- 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 thatstdenv.mkDerivation rec {…}is not best practice, but ratherstdenv.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.
No it’s not just a phase. Mint really is very good which is why it’s very popular and widely regarded as the overall best distro whether beginner or advanced user.
Mint widely regarded as the best distro for advanced users? I must have missed it.
Not trying to shit on it or anything, but I've never heard the sentiment.
You can even use
cpof I recall correctly,ddallows to tune some parameters but it's not strictly necessary.