@whitequark which one is the latter?
-
@whitequark @SRAZKVT
> eudev
here's a complete, albeit still experimental, complete reimplementation of systemd-udev: https://git.pinkro.se/Rose/gardenhouse/gardendevd.git/
made by, a gentoo user, it's capable of booting modern DEs like KDE
> if you mask all critical software
damage control and risk assessment is a thing -
@whitequark @SRAZKVT
> eudev
here's a complete, albeit still experimental, complete reimplementation of systemd-udev: https://git.pinkro.se/Rose/gardenhouse/gardendevd.git/
made by, a gentoo user, it's capable of booting modern DEs like KDE
> if you mask all critical software
damage control and risk assessment is a thing -
-
@whitequark rose also has a simple userdb and hostnamed (mostly for the sake of gnome), plus other tools like sysext, sysusers, ukify, and more, all reimplemented, all independent of each other and, obviously, of systemd
-
@whitequark @SRAZKVT i know what you're doing, yes -- and we've talked before once but that's highly irrelevant
distros don't misled people, it's best efforts, and often enough it works -
@SRAZKVT we are talking past each other. ocaml's situation that i'm mentioning is "if you are on certain platforms, then if you want your code faster, you're out of luck", in contrast to an approach where "if you are on certain platforms, you have to use certain extensions to make things faster". i think that while both have merit the former is severely underutilized. not every platform needs to be supported equally. this is not the same "baseline" as a "core without extensions" in that nobody except for the compiler maintainer and the people using that platform have to spend effort on a platform they never use.
for the latter part, rust has a 8-bit avr port that i've always found fairly senseless. it isn't a very nice thing to do to others to take a language where programmers could previously assume that a machine word is 32-bit and to extend it to a 8-bit microcontroller series which violates that assumption. i've always thought it should've just been left out of scope entirely
@whitequark rust on avr is crazy work. i thought 32bit arm microcontrollers are ubiquitous at this point, am i missing something? -
@whitequark @SRAZKVT
I feel that bootstrapping is essential to help counter supply chain and Trusting Trust attacks. -
@whitequark @SRAZKVT
I feel that bootstrapping is essential to help counter supply chain and Trusting Trust attacks. -
@whitequark @SRAZKVT
Oh yes, it's by no means an optimisation target, but it's a necessary one nonetheless. -
@whitequark @SRAZKVT
> i don't think bootstrapping and having a stable abi are an essential component of a healthy ecosystem. in particular not having a robust interoperability story can motivate people to reimplement a lot of existing software, hopefully while taking lessons learned to heart
rust doesn't have a stable abi across rust <-> rust modules/crates, which has nothing to do with makes does the opposite of what you say -- all it does is making rust-rust dynamic linking impossible, so people have to drop to the system abi for it, and/or make any sort of build cache invalid whenever you update the compiler@navi @whitequark @SRAZKVT Android dynamically links its Rust code. This does require rebuilding programs when their dependencies change, but for a closed system like Android that isn’t a problem.
-
@whitequark I think it is also because big corporations are the ones who see the impact of memory unsafety at large scale. Individuals may be aware that the problem exists, but I suspect most aren’t aware of its scale.
-
@navi @SRAZKVT if all distros do is ship vanilla software i'd much rather save the collective effort and invest in something like flatpak
flatpak is (sigh) kind of terrible, as i've been studying it in detail just yesterday night, but it's the direction i care about here more so than the exact implementation. it could be a nix flake for all i know. though nix is also kind of terrible (i use it a lot, i would know)
@whitequark @navi @SRAZKVT Main problems with Flatpak are:
- Some upstreams (you almost certainly not included) don’t update dependencies when there are major security vulnerabilities. For instance, OBS Studio shipped an old CEF that had a Chromium version riddled with exploitable holes.
- It only works (well) for graphical applications. CLI tools need hand-written wrappers, and it doesn’t work for daemons, libraries, or embedded devices.
- It blocks user namespaces, breaking browser sandboxes. I believe WebKit and Gecko (Firefox) have alternative sandboxing options, but they have more overhead. Chromium doesn’t have an upstream alternative at all, which is unfortunate because it is the most secure browser engine.
-
R relay@relay.infosec.exchange shared this topic
