> The Nix team is aware of all of this and made these tradeoffs intentionally to maximize package support and reduce contributor friction. Nix, for all its good design choices, landed on a supply chain integrity threat model that unfortunately makes it suitable only as hobby OS that must not be used to protect anything of value.
The risks you list are shared by many distributions, meanwhile NixOS does better in some fronts, particularly around monorepo of open build recipes, SBOM, and flexible overrides to allow security sensitive usecases to limit and control dependencies.
But nonetheless, you list valid limitations, but they aren't inherent.
I'll discuss them below, but note that I don't speak on behalf of NixOS.
> Yet another reminder that Nix does not sign commits, does not sign reviews
I agree we should do this.
> allows any maintainer to merge their own code
The convention is now not to do that. I believe a maintainer recently had their commit bit revoked due to doing this. I don't know why it isn't enforced, but it should be.
> does not compile all packages from source
The vast majority are, and the exceptions are odd cases:
* firefox-bin, where some people prefer Mozilla's build. A source-built alternative "Firefox" is available too.
* firmware stuff
* Proprietary software, e.g. factorio.
* I'm not familiar with the Haskell bootstrapping case you mention in another comment, but if ghc can't be bootstrapped, are you suggesting that GHC shouldn't be available, or that a binary GHC should compile GHC from source? I agree that would be nice to have and I'm just clarifying the issue here.
> Hydra admins can absolutely tamper with builds at any time
I believe build reproduciblity is required to mitigate this risk. That is a useful property that OSS should have, but the reality is that no distribution has that, since so many packages has non-determinism.
Is there a distro that does this well? (I know Debian has spearheaded this, but they too have remaining build reproduciblity issues, and so presumably have similar risks).
> The convention is now not to do that. I believe a maintainer recently had their commit bit revoked due to doing this. I don't know why it isn't enforced, but it should be.
Unless you actually know who is committing code and who is reviewing it with 100% mandated commit and review signing, with well vetted maintainer keys, anyone can trivially make a PR under a pseudonym, then merge their own code from their maintainer identity. In effect there is no way to know or enforce who is merging their own code without the hard work of long lived maintainer identity key management that most distros other than Nix and Alpine choose to skip.
I am the one that submitted an RFC to Nix to fix this, that was ultimately rejected citing it would increase developer friction too much. In that moment Nix had chosen to favor drive-by unvetted hobby contributions over security, and thus decided Nix was never going to be useful for the high risk applications.
What offends me about Nix is that it skips all this hard work other distros do for hand waiving reasons, and has teams of paid consultants charging high risk clients money to integrate nix without disclosing they are opening their clients up for any of thousands of people to have the power to backdoor their servers with low chance of swift detection. Worse, most nix maintainers I talk to do not even understand these risks or how other distros solve them.
If nix wants to be a hobby distro, fine, but put some giant warnings on the tin so people can give informed consent for these major security tradeoffs.
I actually believe this trend of over-promising security in Nix is going to get people hurt.
> The risks you list are shared by many distributions, meanwhile NixOS does better in some fronts
I totally grant it is better at some of these risks, however it is also worse than classic distros on other fronts, lacking maintainer signatures and web of trust requirements of most OG distros like Debian. Even Guix, forked from nix with a very tiny team, gets at least this much right.
The excuses are just not acceptable for this major security regression in nix given the types of high risk things it was encouraged to be used for. It is like a new hospital that decided to not do basic sanitation because it would make it easier to hire.
To be clear, I would also not recommend Debian or any distro that places trust in single individuals for production use in the high risk applications.
Stagex (which I founded, so all bias on the table) was created because no existing distro before it was willing to hit a responsible supply chain security bar in my opinion that I was comfortable recommending for high risk applications.
It is a container native, 100% full source bootstrapped, and deterministic, with every commit signed by one maintainer, and every review/merge signed by a different maintainer, and every artifact built and signed with matching hashes by at least two maintainers. As of our next release we will be LLVM native. Also it relies on the OCI standard, instead of making up our own, which means dramatically less code to audit and you can use any OCI compatible toolchains to build any package (though our scripts support docker for now). It also means any individual can sit down and review our entire tree in a few hours due to how succinct it makes things.
Stagex was built to satisfy a threat model of trusting no single maintainer or machine, for high security use cases.
We also indeed reject any packages that are currently not possible to build this way because it is not possible to publish package artifacts under the stagex release process that cannot be full source bootstrapped and built deterministically by multiple maintainers on hardware they independently control. This means we reject packages we cannot safely distribute like Haskell and Ada, but while giving best available supply chain security for most popular languages we do support.
Haskell and Ada do not currently have any way to be built without centralized trust unfortunately but efforts are underway in both cases we will adopt when complete. Any exceptions are a place malware can hide, so no exceptions are permitted.
What is the catch? We were willing to ignore desktop use cases, at least for now, in order to hit a high security bar for software build use cases. As such we have dramatically fewer packages which allow us to hold this line. We are primarily a high supply chain security focused build distribution, though we are used to build a number of other specialized distros like Talos Linux, and AirgapOS. The latter runs on laptops but very minimal for use cases like cryptographic key management.
We will also probably never have the number of packages of Nix, but for the overwhelming majority of organizations a trusted toolchain to build their production services is sufficient to eliminate all forms of linux-distribution-level supply chain attacks by any single compromised maintainer or machine.
> Even if they speak your native tongue, they'll have to learn how to interpret your slang and texting shorthand. This sounds almost impossible today, but what kind of tools might they have in a century?
That doesn't sound impossible. Perhaps LLMs can already do this.
I think even if the company goes away we will see this continue. It modern it rust and some if its fundamentals are already used by other projects. Of course not same way, but its not just going away.
I was introduced to UNIX in 1993, Linux in 1995's Summmer, and have lost count how many X Windows desktops or windows managers have come and gone in 32 years.
I wasted too much time tweaking Enlightenment. I remember that was fun but I don't really remember much about actually using it.
OS/2's Workplace Shell feels like the biggest lost opportunity (and has nothing to do with UNIXy stuff). I really liked Rexx and the SOM stuff felt cleaner than what became COM in Windows.
Window Maker/AfterStep were my all time favourites in GNU/Linux world.
I used to be in the GNOME camp during its early days, even wrote a tiny article to The C/C++ User's Journal regarding Gtkmm, nowadays I rather use XFCE.
The original fvwm also holds a special place, that was the first I used in GNU/Linux, back in 1995, and I got to customise it quite a bit.
SOM was great, it also supported implementation inheritance, and had metaclasses concept as well.
I like COM as idea, I dislike how badly Microsoft keeps rebooting the developer experience, and isn't able to provide modern toolig as easy as it was from VB 6, Delphi, C++ Builder. For something that has become the central mechanism how Windows APIs are delivered.
Some underappreciated and forgotten tiling wms that are still viable today:
- ratpoison ("tmux for X11". Ultralight, great for kiosks and similar where you barely want a WM at all)
- stumpwm (ratpoison on steroids in Lisp)
- Xmonad (A bit different tiling dynamic that some prefer. I dig it despite Haskell, not because of it)
- Qtile (Very flexible and easily hackable in python yet reasonably stable and fast. You can reproduce for example the Xmonad or i3 experiences pretty easily)
Have you tried the new-ish KDE window tiling? (Super-T by default) I had a similar desire to you, and am quite happy with what KDE provided. It'd be interesting to read a comparison between the two.
Although I'm happy enough with what KDE gives me that COSMIC would have to be substantially better before I'd endure the switching costs.
I like tiling a lot more than I like floating windows. Cosmic is my daily driver and is awesome. I just wish it had a bit more customization options, I don't want to spend days rummaging through wikis like with hyprland but having a bit more control over it would be nice, not a deal breaker though
I hard bounced off COSMIC with the complete lack of theming. I can't even set my clock to a reasonable format in it. The only thing it has going for it is sane multi-monitor support, which neither KDE nor GNOME have gotten right so far (though at KDE there is some activity around it, dunno 'bout GNOME).
I tried a bunch of shells when I got my Legion Go, including COSMIC. It had the worst touchscreen support of any of them.
Now that SteamOS is officially released, I just use KDE. Maybe COSMIC will be better at touch eventually, but since it's a traditional laptop company, I'm not sure.
I really hate that at some point in the past, KDE developers decided that they hated how deeply intuitive virtual desktops are and deprecated them in favor of something deeply unintuitive (Activities). Any issue or complaint mentioning it is shot down with "you're holding it wrong."
Please just give virtual desktops first class support and lets forget about the Activities experiment. Most users hate it.
The attitude regarding it is about as bad as Gnome forcing Overview on everyone, refusing to provide a first party dock or lightweight launcher. Despite almost every distro and 95% of Gnome users immediately installing Dash to Dock.
Plasma/KDE's virtual desktops are working for me, as 3x3, 4x4 would be too small in the widget which shows in the 'taskbar', which is only 24 pixels high, here.
Took me some time and asking in their irc-channel, but actually the basic setup is super-simple, and was too 'intuitive' for an old greybeard like me :-)
You right-click on the launcher icon, or the systray and "Add or Manage Widgets", then a window appears where you can pick all sorts of widgets in a bar to the left, which then appear in a subwindow to the right. You just want the Pager, and remove any instances of that Activities Pager thing, if it is/they are already present(because you can have multiple instances in different places(leftover from earlier tries, maybe)).
What I didn't get was that you can pick that pager-widget from the subwindow, and move it anywhere you want it to in that whole taskbar-panel(outside the edit window!), by holding the mousebutton down(drag), until it is exactly where you want it, and then releasing the mouse-botton(drop).
And then "Exit Edit Mode" in the still open window, which then closes. That's all there is to it.
(Similar to how you customize the appearance of Firefox)
From then on you can configure the pager by right clicking onto it, and virtual desktops in system settings like you want them. Maybe having it appear larger with some key-combo, or whatever.
During the time I cursed it, I discovered the activity thing isn't really active anymore, they just let it there for the people who want/like it, meanwhile the real virtual desktop thing didn't get much attention, but that may change in the future?
Edit: Actually the most logic sequence of things to configure would be to first go into System Settings -> Window Management -> Virtual Desktops and configure how much of them you want, and how they should be arranged.
Then activate and position the Pager like I described above, and after that how it presents them.
Nonetheless I'm thinking that could be more integrated, and the pager could be larger, when howering the mouse pointer over it.
I'm not familiar with the Gnome terminologies. Is Overview the one where they removed all the desktop icons, breaking 40 years of GUI conventions going back to the 1970s? (It's impossible to do a search on a product called "Overview".) I blew away Gnome after that, installed Mint MATE (now Cinnamon), and vowed to never touch Gnome again.
Overview is when you press the Super ('Windows') key.
What appears is an unholy amalgamation of a launcher, a workspace strip, a window overview, workspace peeking, and a dock.
Worse yet is that every time you go in or out of this overview, an animation plays, making things fly and animate everywhere constantly, whenever you want to take any action.
Whenever someone points out to Gnome developers that most people only want to open a launcher to type "52*93" or find a contact, that they just want to mouse over a dock to have a lightweight way to see if an application is open (and to switch to it), they get irate and tell you their vision is vastly superior.
Gnome could be pretty great if the developers their attitude to their users wants and the feedback on their issue tracker wasn't extreme snark and "actually we are right". Even if clear UI defects are pointed out, no, in fact they are right.
The Gnome peoples also frustrate any attempt at improving Wayland at a more rapid clip.
There is a reason why Valve went with KDE. KDE has its own set of problems, but at least they are receptive, cooperative and friendly. I genuinely hope Valve puts enough money into KDE that Gnome with its high and mighty attitude gets completely railroaded.
Clearly you've had some interaction that upset you and I apologize for that, but I've never come across any Plasma dev who felt we nailed that one (and I wrote large parts of the panels, the menu, the icon desktop, etc.) I was genuinely surprised by your comment.
To be honest, this is like.. 5 years back? Maybe more. But I don't switch DEs that often.
It's funny to see the two things that prompted the discussion (naming desktops and per-desktop wallpapers) come up heavily under that issue you linked.
Like I mentioned in another comment, I like that KDE devs are much more constructive than Gnome devs. In that issue you can clearly see you're asking users to rephrase their feedback so it is more useful.
With Gnome, I've for example opened an issue for something that isn't according to visual HIG practices. Implementing this would lead to more visual clarity and it would look better to boot. I got told that no, actually they know better. It was pretty clear that they thought that if code or design originated from their shop, there could be no (better) alternative.
When I linked and gave mockup examples I got snarked, and when I snarked back I immediately got dressed down for rule violation by some mod figure that completely ignored their dev's initial snark. Just very, very unpleasant people.
Apologies for the rant haha. Anyway, thanks for linking that and for responding!
Can't switch between workspace 1 and 2 on my right monitor while leaving my left one on workspace 3. In fact, I believe by default I wouldn't even get workspaces on my secondary monitor. Because who needs 'organization' anyway?
Gnome works OK with integer scaling, more granular than this and you're up shit creek.
E.G. can you set one screen to 150% and one to 175%? (I think the answer to this is 'technically yes but then everything goes a bit blurry because they do it by rendering at 2x then downscaling')
Proper mixed dpi scaling means stuff will render pixel-perfectly instead of downscaling hacks.
I skimmed the linked story and I still don’t really know what POP!_OS is. They are using the Linux kernel and wrote their own desktop environment, but what’s in between that? Does it include all the GNU system tools? Is there a lot of software that takes advantage of the COSMIC desktop environment? Do they have an App Store? Is it closer to something like Ubuntu or is it more like Android?
It's ubuntu with their own desktop and app store (kinda like mint) its also known for being the best linux experience for nvidia users. It's designed for power users and gamers
No? They can run on cosmic, just like they can run on any other desktop. It's a linux distro, it does linux distro things and happens to be built on ubuntu. What part of this are you not getting? Remember when Ubuntu made Unity because they were pissed at the GNOME people? That's what System76 did, they got mad at GNOME because GNOME didn't like how much they were messing with GNOME
I'm not super familiar with the history of GNOME, KDE, or COSMIC and I've never used COSMIC and I haven't been able to see into their app store to see what apps are available.
The version of Chrome (for example) that Google distributes uses GTK which is GNOME, no? So I was wondering if System76 forked that and made a version that uses the COSMIC API.
GTK3, GTK4, and libadwaita applications do look native in COSMIC. In COSMIC Settings, navigate to Desktop > Appearance > Icons and toolkit theming. Or search "toolkit" and it will be a top result. In the context drawer that opens on the right, toggle "Apply current theme to GNOME apps". This will then allow the cosmic-settings-daemon to automatically generate CSS variables for GTK4 and libadwaita apps. If adw-gtk3 is installed, it will also apply those variables to GTK3 applications.
Qt4 and Qt5 applications are unsupported, but IgKh/CuteCosmic has a Qt6 Platform Theme that integrates with the cosmic theme system and applies that theming to Qt6 applications. Though it won't work in 24.04 because most of the KDE/Qt apps in this release are based on Qt5, and the version of Qt6 is too old.
You say that, but you probably do care at least a little.
It benefits you when an application doesn't do surprising things. Even basic things like clicking in an edit control, it's better for you if that results in the same outcome across all apps (stuff like does it select all text? does it place the caret at the end?).
I personally try to run Qt stuff only but a lot of stuff most people will run is either GTK (Firefox, thunderbird) or Qt (VLC, Krita, Libreoffice by default). COSMIC can theme GTK to match its style, and so can KDE to an extent
I'm glad to see boot security prioritisation, and to see some of the fundamentals revisited, and scripts replaced with languages that contributors want to write in (NixOS leans heavy towards Rust).
As the project doc notes:
> This radical solution is only really feasible and/or interesting for appliances (i.e. non-interactive) systems.
Can you explain a bit more about this? Is the idea that verity protects the integrity of the nix store, and then the boot process only runs binaries that don't expose any sort of arbitrary code functionality?
For my first few years of NixOS I didn't understand the point of the NixOS stable releases, since even on "nixos-unstable" I found that if my nix config evaluates, then it'll work. And in the very rare case things broke, I could easily rollback.
NixOS stable, for me, provides API stability. I can leave a machine auto-updating, and be confident that my nix config will continue to be compatible, and thus build.
Thanks to the release managers for the work that goes into this!
There's still the data migration issue. If you follow unstable all the time, an app may update its data files or databases at startup. Then, you can still roll back the binaries, but they'll just refuse to work (best case) or corrupt the unknown data format (worst case).
Does Secure Boot with NixOS even make sense? In an ordinary Secure Boot setup, you get the kernel/initrd/etc. with signatures from a trusted vendor, but with NixOS it is going to obviously sign everything locally. That means that you are not protected against bootkits and a root compromise is still just as bad as ever.
I suppose in combination with LUKS you could at least prevent evil maid attacks, to the extent that your machine's firmware is actually secure, but it seems like a lot of work for just that...
Following up on this, has anyone tried this and seen how well it works in practice?
“ Speedify, a proprietary VPN which allows combining multiple internet connections (Wi-Fi, 4G, 5G, Ethernet, Starlink, Satellite, and more) to improve the stability, speed, and security of online experiences. Available as services.speedify.”
Bazzite is a part of the Universal Blue family, which is more of a repackaging of Fedora Atomic.
I'm a fan of my Steam Deck and SteamOS, but I'd like that experience to eventually be available via community supported distros, which Valve/Igalia can rebase from, and instead focus on Proton.
Bazzite is the closest to that that we have so far.
SteamOS is Arch based, and can be replicated on Arch by installing Steam if you don't care for the "game console" UI trimmings. Based on another comment thread about past stupid proposals on Fedora, Arch seems like a much more reliable base than Fedora.
reply