221–230 of 238 posts
Anyways the writing was on the wall for this and Nix is dying.
Earlier quoted context omitted.
Shared Dynamic Libraries. Not to say they aren't useful. Keeping applications small, keeping security updates simple, sub linear ram scaling, yada-yada-yada, big wins cross the board, not debating that. The pervasive link detection structure of effectively everything on GNU/Linux assumes is (more-or-less) objectively incorrect behavior in any sane security minded context. Binaries should be able to declare the interf…
> lipstick on a pig Yes!! > dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer I’m curious if you have an opinion on how you think this should be handled? At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every worl…
Earlier quoted context omitted.
https://git.distrust.co/public/airgap/src/branch/main/Contai... That containerfile defines an entire deterministic custom OS image, every package, and every configuration etc. Many patterns are possible, though this will be made way easier with our upcoming "box" primitives
There is a lot of repetition/stutter, also there's some hashes that belong to a .lock file. Is there tooling to edit this file? (Like some command to add/remove/update entries) Is this what the box primitives is about?
Not inventing our own language has drawbacks, but we are convinced the security and portability wins of sticking to standards with many existing implementations, however awkward at times, are worth it.
No major OCI runtime supports separate lock files yet, so for now they have to be maintained at the top of the file for portability. Most teams use scripts to maintain the hash blocks, though soon our official tool, sxctl will have a "lock" function to make this painless. Also only in most cases people will be able to get away with only one hash soon for most common use cases.
This leads to reducing repitition, "boxes" will allow us to have portable patterns such as "rootfs -> cpio" or "rootfs -> bootable iso" to make things dramatically more succinct. Here is an example of the upcoming pattern in action to produce multiple variants of a qemu/cloud bootable https://codeberg.org/stagex/stagex/src/branch/lance/distros/...
No need for hash locking inputs when in-tree as everything in tree must end up with deterministic digests signed by multiple team members before merging, which are generated in the digests folder.
Similarly we may introduce something a bit like Gentoo Overlays to allow for out-of-tree extension repos to still build with all the benefits of being in tree.
Earlier quoted context omitted.
Shared Dynamic Libraries. Not to say they aren't useful. Keeping applications small, keeping security updates simple, sub linear ram scaling, yada-yada-yada, big wins cross the board, not debating that. The pervasive link detection structure of effectively everything on GNU/Linux assumes is (more-or-less) objectively incorrect behavior in any sane security minded context. Binaries should be able to declare the interf…
> lipstick on a pig Yes!! > dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer I’m curious if you have an opinion on how you think this should be handled? At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every worl…
To "totally overcomplicate things" but do it correctly
- Binary states a list of constraints (namespace:name [|>=|> At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
Honestly same.
Having the package manager elf runtime shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers.
> I also blame C/C++ toolchains for being very very bad on Linux.
They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries.
If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".
Earlier quoted context omitted.
> lipstick on a pig Yes!! > dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer I’m curious if you have an opinion on how you think this should be handled? At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every worl…
I mean... a big part of that with conventional Linux distros is the idea that you can security-update a low level library and all the stuff linking to it gets the fixes "for free", a dream abandoned both by Nix and also the movement toward distribution via containers/flatpaks/VMs/whatever.
Earlier quoted context omitted.
> lipstick on a pig Yes!! > dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer I’m curious if you have an opinion on how you think this should be handled? At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every worl…
> I’m curious if you have an opinion on how you think this should be handled? To "totally overcomplicate things" but do it correctly - Binary states a list of constraints (namespace:name [ |>=| > At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world. Honestly same. Having the package manager…
Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not.
Sigh.
Earlier quoted context omitted.
Packages were handled way before 2025 already, so it is strange that you insinuate they'd all only burn out within a year, and before that it was all cake and tea. NixOS is dying, everyone sees this right now. > but we've also functioned without one for ~20 years. Then this is also a PR problem because why need a team when the 20 years before were allegedly so perfect?
I know nothing about the organisation of NixOS, but I know that NixOS is in a unique position now that LLMs have arrived. It offers the unique experience where you can fearlessly let the LLM loose on your system config to setup any convenience you want. I am not alone to have made this observation, so I am hopeful that Nix and NixOS will gain even more momentum in the future!
Earlier quoted context omitted.
Isn't nixpkgs still a pretty bad state? I know there used to be a lot of "abandoned" packages that went years without updating to the new versions provided by upstream, that a lot of packages were copying binaries around instead of building open source software from the source, etc.
Nixpkgs is one of, if not the largest, package managers by # of packages. I think naturally that will result in more abandoned packages than others. What is the % of abandoned packages relative to total I can't say. Nix tends to have updates almost as quickly as Arch does, I run a lot of bleeding edge software and have no issues, and the breadth of packages is immense. Nix just has a different style. With the AUR, yo…
I'm fairly certain that the graph you're thinking of is complete bullshit. It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality.
Earlier quoted context omitted.
I know nothing about the organisation of NixOS, but I know that NixOS is in a unique position now that LLMs have arrived. It offers the unique experience where you can fearlessly let the LLM loose on your system config to setup any convenience you want. I am not alone to have made this observation, so I am hopeful that Nix and NixOS will gain even more momentum in the future!
While rollback takes away some fears, “fearless” is a stretch. LLMs are relatively quite bad at Nix choosing tightly-coupled, non-modular, non-scalable patterns with unnecessary dependencies/experimental features, while also choosing to reimplement pkgs.lib functions without good reason. Generating more code, pulling in more deps to get out of the mess isn’t the solution either & is usually what I have been seeing mo…
On the other hand, I just checked, and the domain ratemyflake.com is available. I think we should set it up, so that we can rate each other's nixings!
Earlier quoted context omitted.
The most obvious cause was forcing BDFL and creator Eelco to step down https://lwn.net/Articles/970824/ The moderation team posted an open letter demanding he step down, among other reasons this accused him of jeopardizing the safety of people from "marginalized backgrounds" and allowing "fascists" in the community I have tried very hard to find any examples of what this is a actually referring to and genuinely have…
Whatever the legitimate issues were, the letter undermines its own credibility with its overbearing and self-righteous tone. Aside from Determinate Systems and the Anduril bit, the complaints lack specificity. The Blueskyisms thrown around here are just as indicative of "cultural problems" as anything else, assuming these views are representative of the community.
https://discourse.nixos.org/t/objection-to-minority-represen...
It's absurd to view this as a reason Eelco himself should be forced out of a project he himself created.