Rationale
NixOS is a great operating system, perhaps the best in my opinion. However, it is inherently targeted towards devs and doesn’t want to target towards not-much-aware end-users, nor should it.
Now, I, personally, see great potential in it, “even”… or especially for this purpose - a reliable, graphical desktop with minimal knowledge or configuration. Sounds ridiculous, right? But I actually believe in it.
What I actually have so far is pretty much nothing - a logo, a name, and a GitHub org - but should be enough to ‘get started’ and I welcome all your input on this.
Why the CirnOS name? Isn’t it copyrighted or something?
Cirno is indeed a character in the Touhou universe but I don’t think there would be a better name for a hackjob that I’m conceptualizing right now ^^ ZUN/Shanghai Alice are incredibly lax with copyright, this can be changed anyway if it becomes an issue.
@manveru was working on a graphical installer. I heard numerous times of people getting stuck on the initial partitioning and that would benefit from a guided experience there. That’s probably something that could be merged upstream as well.
Picking one DE, and making the support perfect is also a good idea. It also helps users getting a good working experience. Just like Ubuntu that has a default DE.
If you need the space and freedom to explore these subjects in a fork it’s probably fine. Hopefully, the changes will end-up in nixpkgs at some point in the future.
Calamares is ridiculously good, Manjaro has one of the easiest installs out there. (And by the way, I’ve found NixOS CLI formatting way easier than Debian GUI formatting.)
However, my idea thinks a little bit further, designing the actual aesthetic. “turns out “OS nerd” and “touhou fanatic” are a commonly overlapping demographic” -V. Might push the thing forward
Maybe it is also an opportunity to tackle a subject launched in @jonringer posts about the release process. Decorrelate the server/dev/devops experience from the desktop might be a solution using two different distros: one as a platform and the other as a custom overlay + polishing.
I suppose the server/dev/devops should be stable enough to have a simple DE experience and the other one be build a rock solid DE experience.
And as @zimbatm mentioned as nix is so good at composing stuff (and now/soon with flakes ) the two teams can work pretty well together
I don’t think there’s as much of a precedent to do forks. A lot of forks for most distros are, “like our parent distro, but we come with X installed by default”. For example, Xubuntu. Since NixOS is so compose-able, we don’t really need to do the forking model to provide a Gnome, or Plasma, or Cinnamon experience; that’s just part of NixOS.
Having a curated overlay for a specific domain I think would make sense. For example, we could have a “ScieNixOS” fork, which provides a curated overlay prioritizing science and Machine Learning packages. So we could have tensorflow_1 and tensorflow_2 working by default, etc. And perhaps provide more versions of libraries for people to pick and choose from.
Yes, perhaps I used the wrong wording, I think an overlay would be ideal here. It still might be consider a fork due to different organization distributing installer ISOs.
is quite interesting for intel based architectures… lots of things are compiled with optimisations for intel specific CPU’s and extra optimisation patches.
Might be an interest piece of research to find out what their secret ‘source’ is, and see if some of those optimisation and patches can be ported in someway. A fork might be a great place to try these optimised builds out.
If I could spend more and more time to the NixOS project, I would make a tool to easily compare packages downloaded from some sites and built locally and publish some sort of reputation of package (“XYX seems now reproducible, finally! (+1)”) and/or the cache sites (“ABC provided by cache.nix-is-awasome.example and one built by myself were not identical while the local build and one from cache.nixos.org matches… (-1)”).
Guided installer is desired of course, as commented by someone above.
User experience things asides, reducing the seed binaries required to bootstrap NixOS (like GNU Guix) is what I would like to see in the future. Also, improvement of reproducibility even if upstream project did something undesired would be helpful, as I don’t want to see certain errors on my daily-use computers.
Security hardening, like AppArmor, stackable LSMs, audit subsystem, applying systemd sandbox to more services and so on, is truly needed for not only servers but also desktop PCs, as most of us (are forced to) run untrusted third-party programs downloaded silently on our computers via web browsers every day.
(By the way, Cirno is already the unofficial mascot character of 9front, a fork of the Plan 9 operating system )
It would be impolite for anyone to tell you what you do with your time but I feel that the nix ecosystem is confusing as it is for beginners and adding a new “fork” would just add to it.
Might i suggest you use nix-community as your org? This way you will also have access to zimbatm’s generously provided compute resources.
That said, it’s specially important to remember what kind of community one wants to build. (Sorry no way to put this nicely …) I just hope you don’t market your thing like Manjaro. Or , god forbid, Rust. Once there is enough population of novelty hunters they take over the community and the only content you see on their forums is either self congratulatory or comparison with others.
I often see the conversation coming to the installer but:
no one ever mentions what exactly the pain points are and how the curses version of parted + nmcli cannot fix it mostly.
how someone who isn’t comfortable with the command line or cannot navigate linux without a step-by-step program (wizard) expects to be able to use nix, and more importantly, benefit from it.
Also,I believe the logo is the property of NixOS foundation and they are ethically obligated to disallow the use of lookalikes so that users don’t unknowingly use something that is not at par with their standards.
Thanks again for the discussion, you seem to have well fleshed out ideas, and I hope to use them in Nix pkgs mainline eventually …
Security hardening, like AppArmor, stackable LSMs, audit subsystem, applying systemd sandbox to more services and so on, is truly needed for not only servers but also desktop PCs, as most of us (are forced to) run untrusted third-party programs downloaded silently on our computers via web browsers every day.
To be fair, you list a lot of things which are more about services, and what you need for your stated (well-founded) complaint is multiple browser instances (to reduce cross-contamination across sensitivity contexts) in roughly speaking firejail…
(Which is definitely a good idea, I run like that — although of course it is also a good idea to grab plain HTML and read via something… simpler… wherever possible, which is a much larger fraction of Web than some spyware-Javascript-mongers would prefer you to believe)
You are definitely correct. I had thought about something like browser sandbox escape, but actually in-browser secrets were low-hanging yet potentially higher-priced fruits. I am sorry for confusing claims.
Browser sandbox escapes, cross-context in-browser leaks, and just tricking the user to pick a wrong file to upload are all possible and all bad. And the measures you list could be useful on top of a proper sandboxed-instance-separation anyway, surely nothing to be sorry about having said.
I wonder if firejail or something similar (together with xdg-portal?) could be indeed polished to the level of «clearly better than anything else what an unprepared user can handle otherwise»…
the trick to making something secure is to add so many security mechanisms, protections and layers, that it renders the machine unusable and unmaintainable due to complexity. If the machine is unusable to humans and cannot be repaired, no keys are likely to be generated or indeed leaked… the system will be so broken no unauthenticated code will run, however this does have the slight side effect that no other code will run either… This is called a non-functional secure system…and it’s 100% secure.
nix/OS is a build system, your still building something else, using the build system of the projects that needs to ‘put software together’. Your kinda at the mercy of how other languages build software and manage their dependencies and configuration. Thats even before you have the software running.
I’m always fear full not to drink too much docker koolaid or in fact nix/OS koolaid (however nix/OS does taste a little better) , in the weeds things can get hairy… and the devil is in the details sometimes. Yes, i’m talking about the murky depths of the dynamic linker and all that other ‘stuff’ end users don’t see, or seldom care about.and the dreaded ‘it works on my machine syndrome’.
I’d rather have 1000 people looking/refactoring/debugging and fortifying code… than 1000 security ‘band aids’, place on the top of a OS. Refactoring the OS it something which rethinks security architecture is the right way to go (and have a level of backward compatibility)… the is why
spectrum os shows such promise.
I’d rather have 1000 people looking/refactoring/debugging and fortifying code… than 1000 security ‘band aids’, place on the top of a OS.
Debugging lasts until the next upstream bump, band aids last longer actually…
Making sure they are actually layers and not too intertwined is useful, of course
Refactoring the OS it something which rethinks security architecture is the right way to go (and have a level of backward compatibility)… the is why
spectrum os shows such promise.
NS-based jails pose quite a bit fewer tricky things, and so might be applicable more generally and with less user tuning than truly proper VM-based approach.
) the two teams can work pretty well together
)