At the moment, I suspect most users are developers of some sort. So my thought is, what would make their lives easier. Something I’ve sometimes wanted is a quick way to see the diff when changing options or faster feedback while developing nix expressions. I can hook up a file watching script, but the main limitation for easy quick tools seems to be the the speed of evaluations. If we can take advantage of some sort of incremental build or a faster evaluator we will probably discover unexpected tools and features for increased understanding for a wide range of users. I’m thinking the equivalent of what hdevtools is for Haskell.
1 Like
Besides the installer, Manjaro has a lot of GUI fixes we have abandoned in NixOS.
Disable font antialiasing in one click (without mass-rebuild) and XFCE 4.13 to name a few.
That polishing of GUI is not fun and probably requires pay workers to do the work done.
I meant git repo, I sent a correction afterwards.
Sorry, I kept in my “live” tag your previous message and forgot the
second one, even with notmuch I’ve too many mail…
Some people just use chattr +i (personally I have workflow that
minimizes risks of accidental overwrites, but +i is indeed sometimes
nice).
That’s ok for static content, but not feasible for frequently changed
content… Think about a large document (a thesis, a big report etc)
that it mistakenly overwritten because you hit save&close after an
erroneous change, perhaps a binary docs like a video you edit or an
audio or a picture and undo capabilities of your software can’t help.
With a logfs you can recover issueless and it have substantially zero
overhead in the sense that it’s a protection maybe used very rarely
but does not require anything after initial setup.
Of course, this implies division into large and immutable and […]
Sure, this is always needed even to make backup easy but a net division
between mutable and immutable is hard. Personally I divide per topic and
per importance of data (like volume for music/photos/video less
important, volume for docs, volume for config, generic “varhome” for
all configs and chance I do not care). Also it require user action in
too many case, think about pdfs invoices, you can easily categorize
them but or you have a (big) script to chattr any of them or you have
to act manually for any new invoice. And this kind of “always append”
contents does not fit well in a VCS…
Anyway it’s a bit offtopic…
There are real complicated questions about GUI configuration editor.
If you want to prevent GUI installer from happenning, you should look
around the ecosystem and look for a question that is complicated and
interesting and relevant, so that it gets attention and obviously
should be resolved before going on. If there are hard trade-offs,
consensus will just never happen.
Oh no, I’m only a NixOS user, can’t pretend to steer any evolution! I
only give a (strong and repeated) world of warning about possible
evolution I already see in the past.
– Ingmar
That’s ok for static content, but not feasible for frequently changed
content… Think about a large document (a thesis, a big report etc)
that it mistakenly overwritten because you hit save&close after an
«think thesis» → VCS
There are real complicated questions about GUI configuration editor.
If you want to prevent GUI installer from happenning, you should look
around the ecosystem and look for a question that is complicated and
interesting and relevant, so that it gets attention and obviously
should be resolved before going on. If there are hard trade-offs,
consensus will just never happen.
Oh no, I’m only a NixOS user, can’t pretend to steer any evolution! I
only give a (strong and repeated) world of warning about possible
evolution I already see in the past.
NixOS community tries to make different mistakes than other ones!
Sometimes we even succeed.
Actionable issues raised will mean that you, yes you, can make sure that
the things you are worried about will be at least deliberately (and
likely thoroughly) considered. I mean, «just a user» might be a reason
to abstain from trying to change the decision on a implementation
detail, but users-who-are-no-NixOS-developers are exactly the group of
people with valuable and underrepresented opinions about use cases.
Truly @davidak’s remark about the elementary OS UI on top of NixOS is critically important. I don’t know if folks are aware of the Darling effort (think WINE but running macOS apps atop Linux instead), but one can begin to capture the vision if you just consider this for a few moments.
Apple is moving down a terrible path and people are wanting out, BUT they want and need their macOS apps. Linux would be incredibly stupid and naive to think for a moment that the community couldn’t use the remarkable boon that this could bring. Having a cohesive and very macOS-like user interface with the same keybindings would change the world for Linux as a whole.
Having a foundation of the Nix package manager would be enormously helpful and exciting in terms of gluing system admin and general installation + updates together.
2 Likes
FYI: The Pantheon Desktop is packaged for NixOS for some time now. It is included in 19.03 stable channel!
I use it for some months on personal and work computers. Only one critical problem exists with multi-monitor setups: Pantheon session crash after lock or suspend with multi-monitors · Issue #60082 · NixOS/nixpkgs · GitHub. See general progress here: Pantheon · GitHub
Darling is also packaged. Well, kind of. But it seems far from usable. But indeed an interesting effort.
https://github.com/NixOS/nixpkgs/issues/38628
I’m not sure if we should use the new elementary Installer and create a elementary ISO. I like it because it has state of the art design, but it is quiet new. A more general solution would be better for the success of NixOS.
But first we need Design and UX for an Installer that fits NixOS and teaches the user the basics without overwhelming them! Elementary is doing a fantastic job in that space: Get Settled into elementary OS with Onboarding | by Cassidy James Blaede | elementary | Medium
Without Design that has the user experience in mind, it is just a tech demo that experts can use. I wish NixOS becomes more user friendly and make it’s advantages available to more people. For that, we must hide most of the magic happening on the technical level. Users just want to install the system, configure it, install software and be productive. elementary OS delivers that.
I think right now only technical people are involved in NixOS. We need designers, UX experts and technical writers to make it accessible to more people.
3 Likes
This is exactly correct. Even myself, with over 25 years on Linux/FreeBSD I am done with “fiddling” and this is why I moved to macOS around 15 years ago. Now with Apple making the decisions it’s making regarding eliminating 32-bit and a plethora of other decisions that are moving away from “developer-first” centricity, I’m looking for another home within the next 1-3 years. I’m still going to need macOS apps and I’m still going to need Windows apps, but how those are presented is a big deal to me and this is where Darling and perhaps even Wine come in (or perhaps the WSL 2 model from Windows 10 that’s going to be released this fall is the better model to follow regarding virtualizing some aspects).
At any rate, the only thing that Linux is missing (and has never been able to get together) is a cohesive UI/UX. KDE would have been the winner had the idiots with Gnome had not somehow screwed up the hearts of Linux users back circa 2000. The Linux community has never recovered from that royal screwup and we’re still dealing with crap today and people like Ubuntu and Pop_OS are continuing to push it hard with negative side effects.
Elementary probably is the only realistic good UI/UX path that already exists, but there perhaps could be better options if a strong and cash positive organization could get behind such an effort. It wouldn’t take much to get a NeXTSTEP/GnuSTEP/Cocoa-like library in full swing and a strong wm. I suppose that Vala can be the base of that, but perhaps even V lang would be more efficient and effective over the next few months. V’s multi-platform capacity could be a real key aside from all of its other attractions (it looks like V may be the most popular upstart language ever at this point with getting over 10k stars on GitHub within just about a month).
Anyway, a lot to consider and a lot of potential if the proper core people could be brought together under the same opinion and umbrella vs continuing to hold this Linux diversity crap up as some kind of banner or badge of honor… 
2 Likes
I don’t think building something new is going to be a solution. There are already excellent GUI libraries, such as Qt. To become a competitor on the desktop (assuming the desktop still matters), you need a very focused effort to polish some existing desktop to remove the thousands of paper cuts. This is how GNOME 2.x became a very good environment in the mid 2000s. Sun Microsystems invested a lot of power in usability studies, HIG guidelines, and polishing the GNOME UI. Of course, they were motivated to improve GNOME to replace CDE.
Though I am not sure who’d be willing to invest the manpower in such an effort. It will be interesting to see how far the Elementary people get. At least they have the right mindset.
2 Likes
It feels like the missing stepping stone for wider adaptation. According to Repository statistics - Repology there is enough well maintained packages.
One proof of concept DE with decent GUI installer would open NixOS for the world to try.
1 Like
I haven’t been here that long but it really seems like a GUI installer with a pretty desktop isn’t enough. While a GUI installer would definitely ease the barriers to getting nix installed it seems like it would just slam them into the next wall that much faster.
The nix install process just involves partitioning and mounting disks, editing a config file and running nixos-install. The walls that come up after install are much harder to scale. To use nixos in any meaningful way, you have to have at least a basic understanding of the nix language and some nixos concepts that are very different from pretty much any other OS out there.
I think to make nixos user-friendly would take a full blown derivative distro that included some tools and automation to ease the learning curve. It seems like that would inevitably come with trade-offs to flexibility and/or purity but that would probably be OK in a derivative distro.
3 Likes
It’s 2020. GUI = Webpage these days. Fish shell is an example of how one can have a web gui (I’m not saying it’s the prettiest).
Users know webpages - they are friendly things with known UI conventions and come with bookmarks and back buttons. An app store where you click on apps and they get added to the config sounds great, and then you can review your changes to the configs and hit the make it so button. Done well it could lead people into the world of the config and demystify it a little.
Microsoft did brilliantly with their vba script macro recording as people could find out how to do things and then tweak it to their own needs.
Nix seems awesome in delivery of its vision, it’s just the discoverability of its powers that are lacking (from my newbie viewpoint).
I’d also like to point out that it’s not the lack of a UI installer, it’s the lack of the app store / config brought to life that is the missing link. People only have to install it once. But after that they have to live there. If you make living there beautiful then they’ll put up with jumping through hoops to get there.
2 Likes
I think you’re spot on. I had the idea the other day of a web based Nix configuration system + native mobile app being a potentially killer combination enabling a lot of unique features people would love including easier installation.
Imagine a system like this:
- Nix(OS) runs a webserver that can be connected to locally via a browser
- This interface acts as a graphical configuration editor. The “app store” portion is essentially just adding/removing packages to an array.
- When the user is done making changes there’s a “make it so” button to apply the config
- The interface offers easy rollback and management of generations
Now that would be useful on its own, but if we take the concept a little further it becomes unique and IMO a highly awesome way anybody manage their system(s) that doesn’t exist elsewhere
- The webapp is also a mobile app (use react-native for a single codebase)
- Offer services via nixos.org (of course also with option to self host). These services would include:
- Allow for easy connection via proxy (for example: https://connect.nixos.org/{identifier} to reach your machines from anywhere as long as it has internet)
- Auto-backup and versioning of configurations
- Sharing of configuration pieces, to make common use cases easier. For example an option for “android development” or “lamp server” or “steam gaming” or “nodejs development” or “kde desktop” IIRC nix modules already enable this, but discoverability and sharing isn’t easy.
- Use the app for installation. Pop installation media into a machine then open the app, auto-detect the installer or scan the displayed QR code (or navigate to the url) to configure and install the machine remotely. Apply your saved configs to do it quickly. Quickly and easily set up multiple or headless machines!
- Notifications. Machine rebooted? Service crashed? The Nix app could be your hub for managing all your nix deployments.
- Expert mode: raw config editing but nice to use via an embedded monaco editor (the editor vscode uses) with nix extension.
- Crazy idea: auto-packaging (or guided packaging) of apps that aren’t in nixpkgs yet. For many apps adding them to nixpkgs seems to be just boilerplate of getting the url and hash then putting them into the standard builder, checking they work, then submitting a PR. Could that be largely automated?
All of this combined would be amazing for day-to-day use of NixOS and for building/managing deployments of multiple NixOS machines.
I love Nix and NixOS but I always find myself back on MacOS after several months of nix-ing because the day to day usage and management of NixOS gets in the way of other things I need to do. Right now there’s a lot of hoops to jump through in order to do “simple” things in NixOS. Most of those things aren’t hard to do, but there are a lot of steps and minutia to remember to get them done. Most of the time I don’t remember that stuff and have to go searching. Most of the time I don’t have time to do that at the moment.
I’m guessing others feel this way as well and that an easier way to manage nix systems would go a long way to easing the most common use cases. I’m a web/react-native dev by trade so I’d love to hack on something like this but unfortunately for the foreseeable future I’m not realistically going to have the time to put together anything of substance.
5 Likes
what you’re describing feels like a nicer NixOps frontend intended for end-users (while NixOps was originally targeted at DevOps engineers and system administrators) that has lots of new features and integrations, especially number 6 and 7.
A proxy-server integration for easy connection feels like a nice idea… for a backdoor. This might need to be password-protected somehow, or better cryptographically, since it opens a large attack surface - essentially, you’re asking for a reverse shell. I think it’s better to do remote access with SSH, using domain names like computer.username.manage.nixos.org, where manage.nixos.org is the management server’s domain name.
Auto-versioning could be performed with Git under the hood.
Sharing of configuration pieces could be a bit easier with the emerging flakes RFC - as Nix flakes are pure, and there’s a proposed central flake registry (with support for local registries for extension) you could import flakes that contain NixOS modules to configure your system faster. Outlining a standard for inclusion into the official registry will be great for allowing others to publish on this platform.
For installation, I think that Nixpart should be finished and included into NixOS before this can proceed, for unattended partitioning. A guided partitioning option could also be available.
Notifications - this feels nice, especially for me - someone who never knows when her server crashed. This will require a daemon to be present on the system constantly, but systemd could probably handle another daemon, couldn’t it? :3
Expert mode - as flakes are essentially Git repos hosted somewhere for access, this is essentially provided by services like GitHub already. No need to invent something special :3
1 Like
I use netdata for that. It discovers services by itself and sends e-mails when a mailserver is installed and a rootAlias is given. But you also want external monitoring to see if the system is available, like Uptime Robot (checks every 5 minutes are free).
The guys at https://mercode.org seem to have begun some work in the ‘friendly NixOS’ department, although it seems they do struggle with the effort somewhat.
I made a barebones version of something related. Here Nixos-generate-config and option, nix discoverability
If you have comments, I can improve it. It’s only a skeleton now but there would be lots of settings for each module so a user can uncomment a single import and easily get configuration he needs without going through the wiki.
1 Like
I’m one of those average users. Just this week I got NixOS installed easily…on a computer with ethernet. I couldn’t get it on my laptop, which has only a WiFi card, because the driver for said card isn’t in the install image.
Now, I don’t care about proprietary vs. free when it comes to something this basic. I just want to install the system, which is impossible without internet. (That seems to be the norm in Linux.)
Forgive my ignorance, but it seems there are are two different tools for connecting to the web here: NetworkManager (graphical system) and wpa_supplicant (text-mode, WiFi only). Either way, I don’t benefit from not being able to get online. Tl;dr: make sure new users have their wireless drivers, proprietary or not.
Sorry, but they can’t.
Especially the firmware needed for some RealTek chipsets is not allowed to be redistributed. They can not legally put these firmware on the ISO.
Neither would a RedHat or Canonical be allowed to put these firmware on the ISOs, unless they perhaps paid RealTek or otherwise have contracts with them.
The golden rule for WiFi on Linux is, have your ethernet ready to back you up.
Also you can build your own installation ISO which already contains all necessary firmware and kernel modules. Even the unfree ones, but you are not allowed to share it.
https://nixos.wiki/wiki/Creating_a_NixOS_live_CD
If there are such restrictions in your firmwares license, blame those that put the restrictions, not those who follow them.
6 Likes
We could however make creating such a custom ISO easier.
It’d be really cool if we could have a Docker command that builds custom ISOs with proprietary firmwares, modules etc. right on the download page for people who need it so that they don’t have to go digging and/or understand both Nix and Docker.
Would be a very cool showcase of the power of Nix too, I don’t think this would be as easy and portable using other build systems.
5 Likes