-
I’ve noticed in some more newbie-friendly (user-friendly OS) a popup-screen at first boot that can be turned off (vink) with all necessary links and basic info for newbies. I couldn’t found this!
I’ve noticed in some more newbie-friendly (user-friendly OS) a popup-screen at first boot that can be turned off (vink) with all necessary links and basic info for newbies. I couldn’t find this! -
Also with every given command (cli) line on the website in the manual (or elsewhere where newbies are looking for solutions/help) there seemed to be a copy button (great!) but did you ever try this? cause it copies also a (not-that-usefull) $-character.
-
Another something that I (personaly, maybe now as newbie, maybe always) rather would like is a graphical interface program for install/removing packages (like many other distro have already made their own app/remove-gui). Nix-gui (See on Github) was trying to build this (technicaly, I guess the graphical part wasn’t finished too), but seems depricated now!
-
Yesterday I tried to do with the liveISO a custom NixOS install on my prefered partition, seemed that the gui-installer let me install with btrfs but failed in the end-process! Today I’ve followed the explaining on the websites (Btrfs - NixOS Wiki). Why is it possible to choose such a partition-type in the gui-install?
This should at least be disabled and marked out (gray) (or removed from the possibilities) or working!
Also tried lvm before I was doing btrfs and was the same with the gui, even for this there is no full explaining website like with btrfs!
Those are some good QA notes 
Sadly there are quite some technical challenges left to solve for this one. Some people - primarily @vlinkz - are working on them (and some of the broader idea of a more GUI/beginner focused NixOS) over on https://snowflakeos.org/.
You might enjoy trying GitHub - snowflakelinux/icicle: A gtk4/libadwaita installer for NixOS based distributions, though I’m not sure if it’s usable for a daily driver yet.
Thanks for the advice, I’ll tryout snowflakeOS to see & maybe give some feedback too.
So far I got configured the rebuild (configuration.nix) for my preferences and home-manager (home.nix) for prefered packages. As you can see still learning this NixOS.
[I prefer to use pantheon and with NixOS it seems to be integrated as a standard window/desktop-manager. I’ll try to install on snowflake too.]
So far my feedback with Pantheon:
- The terminal has strange behavior (not seen before at fresh install, have to check this!): I can’t resize the terminal-window, only have it in full screen. So can’t also move the windows (to other screen for example).
What about a really limited/stripped down GUI package manager that emulates other OSes, requires root to run, adds/removes stuff from environment.systemPackages in its own config file module?
You could go even further, and have it require a checkbox option, or else only show packages from within a special vetted list of things known to work without any extra work.
It could also load prefab config files from a GitHub library in the same way, so as much as possible could be done with reusable setups.
Seems like the whole thing could be done in a weekend if you stick to a really basic, opinionated kind of workflow, and don’t try to manage user dotfiles or anything fancy like that, which GUI users often don’t need anyway.
That’s effectively what icicle is afaik. Simple weekend projects tend not to be maintainable or polished enough for the user you have in mind, it takes some time to bake.
Honestly I think the graphical piece somewhat defeats the purpose of Nix and I was never really too interested in it myself. I see the appeal from a UX perspective, but honestly, the whole point is to build a declarative system closure. These are inherently programming language concepts, and they are best described using a programming language imho. Maybe that is the reason these tools never seemed to have taken off in a major way?
I have no experience with the graphical installer, for the same reasons, but hopefully since it is now an official part of the distribution your concerns there can be addressed. And I’ve said it before, that while I think we should do what we can to make Nix and NixOS as easy to use as possible, I’m not sure it will ever be a “user-friendly” as in “beginner-friendly” distro, as the concepts behind it are just inherently fairly advanced.
That said, I do believe NixOS may be the most “user-friendly” in the “suckless” sense, in that it is simple to use and operate for users who have acquired that advanced knowledge. It’s a tradeoff for sure, and I’m not really a huge fan of elitism, so like I said, we should do what we can to take this kind of feedback seriously. But I also think its a good idea to realize what you are getting into here. Nix isn’t designed to be the “simplest” tool to understand by its very nature, but for those who understand the requisite background it is quite “simple” in another sense and amazingly elegant once it is grasped.
Perhaps a big component to improve here then, would be education of why Nix is different, what the trade-offs are, and why it is worth it for some use-cases. All that said, I appreciate your feedback, and there are lots of folks in the community actively trying to make things more friendly as much as possible. Hopefully at least some of your concerns can be addressed promptly.
Ehh, this is kind of why I think snowflakeos as a separate distro makes sense. NixOS can be where the programmers play.
That said, I do think there is a place for a declaratively configured, GUI-focused distro. It gives the community a fighting chance to help confused users debug what is going wrong on their systems. It gives the community a chance to tame the hell of bespoke laptop configurations and missing kernel modules. It just… Encodes more of our ecosystem in a usable format.
Even if the average muggle can’t read that format, it gives more experienced people a chance to understand more than ever before. It’d be great to bridge this gap so normal users can use the distro comfortably, so we all can benefit from the shared data on how computers can be made to work this generates.
And also, the confused GUI user of today may well be a 1337 hacker 10 years from now. Give people a chance to learn comfortably, or we will be crowded out to insignificance.
I get what you are saying, and it sounds nice in theory, but I’ve yet to see a single implementation that doesn’t cause more problems than it solves. Eventually, inevitably, a user will get stuck and frustrated where if that had just started with the fundamentals to begin with, they might actually stand a fighting chance to figuring out their problem.
In general, I’m not a big fan of hiding complexity for the sake of user friendliness, it just leads to more complicated UIs and bigger problems down the road, as well as less prepared users to deal with them. But its just my opinion, I could be wrong 
It works very well on Android(and presumably well on iOS). I think the key is to just not expose any leaky abstractions in the GUI, and to only do things that map very cleanly to the underlying model.
Install LibreOffice yes, switch to a different kernel with a custom config flag, no. If you need to do something that would cause a GUI tool to be more harmful than useful, you failed at ease of use at a deeper level than the GUI itself.
As far as I’m concerned, Android is the ultimate OS for ease of use, and they have a really simple way to do configuration: Mostly just don’t. Stuff just works and doesn’t need some daemon to be set up in just the right state. If an app isn’t like that already, it’s very hard to paper over the fact that the base paradigm isn’t easy, and it might even be obnoxious for technical users.
The place to hide complexity, IMHO, is in the app itself, if the app does that, the setup tools become easy, all you need is just a GUI that adds a line to the packages list. Modern GUI apps have their own settings menu, average users can recreate their setup in minutes by hand, because the apps purposefully imply a specific workflow without much customization.
Comparing NixOS to Android and IOS is a fairly apples to oranges comparison though, imo. I see a lot of people arguing that it can be done well, but I haven’t seen anyone do it yet. That’s all I’m saying
For simple config it should work fine, but for abstracting out config functions and mapping that over multiple values a programming language is always gonna be the go to imo.
Yep, I definitely agree there, not much beats text for nontrivial Real Programming. GUI is best for pure end user stuff where you don’t expect or want new abstractions to be made.
There is a comparison that makes sense to make: the only other declarative OS that comes close to NixOS is vyatta (vyOS or whatever they call it nowadays). It has a tree of configuration options, similar to the NixOS module system, and it can be manipulated either through a configuration file, a web or a command line interface.
You can do complicated stuff using the GUI and then tweak it from the configuration file, or modify the configuration on the fly with a command.
Sounds great, right? No, it sucks: what happens is that your carefully handwritten file (indentation, comments, etc.) is trashed by the other tool everytime you change the configuration.
It’s not that a GUI is intrinsically incompatible with declarative configuration, but it’s very complicated to do without creating a mess of mixed generated and manually written code. What I appreciate of NixOS is that absolutely no one is ever going to touch my configuration files.
A GUI or CLI can be useful, but it’s mostly making up for a bad declarative interface. For example, see openwrt firewall rules where you need 10 lines of text to open a port on the WAN.
Further suggestion: nix build --offline is a bit confusing. Most other systems pretty aggressively avoid fetching stuff from they internet if they don’t need to. Maybe “Keep outputs” and something like --offline should be the default, with --clean to reload or something.
There’s also a problem where --offline seems to build stuff that doesn’t need to be built.
Shouldn’t there be a config option for “Don’t build stuff from source if you can find it at a binary cache, but also don’t fetch anything you already have, and don’t fail just because you can’t check the metadata you checked five seconds ago?”
Nix will never fetch what it already has in the store. Neither with nor without --offline.
i.e. that’s the default behavior.
What do you mean by this?
Hiding complexity is literally the entire purpose of computing systems. GUI hides more complexity than CLI, sure, but it’s all relative. C hides the complexity of Assembly, which hides the complexity of binary. Filesystems hide the complexity of storage blocks, which are abstracted from NAND chips by a storage controller. Everything is an abstraction.
That being said, there is a debate to be had on how much complexity to hide and how much to reveal. In my opinion, the best option is always choice. Give the user the choice to see the complexity, and understand it, and become a more proficient user. Or let them spend their time on things that they find more enjoyable or useful. As long as Linux, or NixOS, requires people to learn how computers work to get stuff done, it will never be mainstream. However, this is not in itself a bad thing. It is great to have a hackers’ OS. But for those of us who want Linux to be mainstream (like me), we need to realize that robust GUI tools are necessary to achieve mainstream relevance.
Build a simple package, that has a few dependencies. Then make a one line code change and try it with WiFi turned off.
It will completely fail on a nixinfo or json request if you don’t use --offline
Yes, nix will check if the expression you want to build is substitutable.
Without --offline or --fallback unreachabe substitutes are an error. If you know what you are doing pick the correct one.
This has nothing to do with “redownloading stuff thats already there” though.
PS: I prefer to fail when no substitutes are available, rather than bootstrapping some compiler toolchain in the worst case. If I really want it, I can still use --offline/--fallback.
Sorry for sounding snarky, but duh. I understand the point of abstracting complexity. My point is, sometimes the wrong abstraction can just end up hiding the complexity in a way where it simply reemerges at a different level in an even more abohorent, and less obvious manner. I tried to give concrete examples of this in my previous post.
In any case, I’m a bit playing devil’s advocate here to perhaps motivate those who believe it can be done well to actually go ahead and do it 