3,717 karma · joined September 24, 2012
https://linderud.dev/ https://github.com/Foxboron
[ my public key: https://keybase.io/fox; my proof: https://keybase.io/fox/sigs/LzugxUxnL-9sr_SJ8i6eMsmBZgyt9294JPRa2nnIl8o ]
Only if you primarily work with `cargo` and want to interact with C from Rust. The other way around has far less support and `rustc` does not standardize the object generation. This is actively preventing projects like `systemd` to adopt Rust into their project as an example.
Not really.
The meme is from 4chan and the /g/ board that had some origins around 2011/2012. Gentoo was the main meme before this.
After 2012'ish the meme-culture from 4chan became mainstream internet culture with the popularity of reddit. Nothing has really progressed beyond that.
> These people have now moved to NixOS.
[citation needed]
The most glaring one is the recommendation to use `rng-tools`, which is not needed anymore for the past couple of years.
It was written 6 years ago, and at that point it probably was not great either?
You can use `efibootmgr` to insert the `vmlinuz` binary as a boot entry. But honestly, you are better off using a proper bootloader as it makes things a lot simpler for you to manage.
The UEFI bootloader menu is mediocre if you are lucky, terrible in most cases.
I mean, reading Rod Smiths post is what originally made me write secure boot tooling many years ago. I didn't understand why it had to be soooo complicated.
If you read the original `efi-roller` project I started out with you'll see it's largely just a wrapper around the stuff in Rod Smiths book, that was later refined by actually implementing a proper library in Go and tooling on top.
Along with the glibc hacks needed by WSL1.
(I was part of the discussion and also very adamant about this not happening)
No longer true since last month.
https://lists.archlinux.org/archives/list/arch-dev-public@li...
The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts.
It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
Scratches their own itch, check.
> So was Slackware, but it took SLS and improved it. Slackware is arguably the oldest surviving distro.
Itch scratching, check.
>SuSE has roots as a German version of Slackware. Red Hat's package manager was bolted on later.
Pretty sure this was itch scratching as well.
> Gentoo and Arch are relatively modern, being 21st century projects. Arguably, they're 3rd gen.
Both are itch scratching projects!
> Fedora is a 4th gen distro, younger than any of the others here. Its ancestor was Red Hat Linux, which was contemporaneous with Debian -- but was left behind by Debian's technical encancements: in 1996 or so, Debian introduced `apt`, a package manager with automatic recursive dependency resolution. This put it far in the lead of Red Hat, which still only had RPM and no dependency resolution.
Arch and Gentoo are from 2002, and Fedora from 2003.
Fedora was based on someone starting to package FOSS software for RHEL, more itch scratching!
It's not like any of them where planning to be used by millions of people.
That's not a lie. That is the package target. The `nixpkgs` repository in the same vein package a huge number of source archives and repackages entire ecosystems into their own repository. This greatly inflates the number of packages. You can't look at the flat numbers.
> However the Nix project was designed from the ground up around reproducibility.
It wasn't.
> It also pioneered architectural approaches that other systems have tried to emulate since.
This has had no bearing, and you are greatly overestimating the technical details of nix here. It's fundamentally invented in 2002, and things has progressed since then. `rpath` hacking really is not magic.
> I think you're grossly misunderstanding the role Nix played in this effort.
I've been contributing to the Reproducible Builds effort since 2018.
Arch hovers around 87%-90% depending on regressions. https://reproducible.archlinux.org/
Debian reproduces 91%-95% of their packages (architecture dependent) https://reproduce.debian.net/
> Disclaimer: I have no affiliation with Nix, Fedora, Debian etc. I just recognize that Nix has done a lot of hard work in this space & Fedora + Debian jumping onto this is in no small part thanks to the path shown by Nix
This is completely the wrong way around.
Debian spearheaded the Reproducible Builds efforts in 2016 with contributions from SUSE, Fedora and Arch. NixOS got onto this as well but has seen less progress until the past 4-5 years.
The NixOS efforts owes the Debian project all their thanks.
https://github.com/landlock-lsm/landlockconfig
I'm going to write up some Go bindings for this when it becomes relevant.
What are they testing? 99% of what exactly?
What does "path" mean, does it inflate the number?
It wouldn't guarantee anything. It would force you, and anyone else, to do massive rebuilds when some binary down the tree changes, or has a regression.
The gcc compiler also fails to reproduce binaries with the LTO streamer backend if you use certain macros. This has the consequence of making cgo binaries unreproducible.
As for Debian, we don't really know how many packages are reproducible. The CI they show is for fuzzing out issues, there are no system currently reproducing distributed packages.
I have some bad news.
That is the goal with the work they are sponsoring, yes.
This is reading too much into it. The issue is that things like proper build infrastructure and signing enclaves is hard work that is not easy to work out and provide on a volunteer basis.
We (Arch) do not support multiple architectures for the simple reason that it would imply I'd need to watch N number of builds of one package pr architecture. This is what we did for the 32bit version and 64bit version. That's a lot of wasted time, and doesn't help you sell architecture support.
Signing enclave is hard to do right as it requires the technical know-how to do securely and the supported tooling to move the package signing from a pr developer basis to a central signing key. In the long run this would also enable Arch to support Secure Boot.
https://media.ccc.de/v/all-systems-go-2024-263-boring-infras...