just learned about this project erjic that does seccomp+bwrap sandboxing https://codeberg.org/prisixia/erjic the interface is really nicely designed and i believe will fit the needs of my build system perfectly
-
the end user, living the dream of linux on the desktop, largely uses gnome or KDE. fun fact: arch's
pacmannow has a new type of dependency, that's not listed as optional but can be uninstalled freely. KDE's "baloo" which indexes your entire hard drive and can't be turned off must be uninstalled with-Rddafter nearly every-Syuupgrade. it's not registered insystemctl—it just pops up inps. if you ever provide your location to the weather in the KDE clock, it cannot be removed, not without undocumented changes in~/.config.who is the customer for this? who benefits? who is all this for?
i was shocked to finally understand the zen of slackware thanks to @miss_rodent's patient explanation. no dependencies? what's the point then? why not build everything by hand? but i slowly began to pull these apart:
- a distro package recipe bundles the code for your distro
- a package manager builds or downloads the package by name (checking signatures and/or checksums)
afaiu, slackware does that just fine. and it is better than building from source by hand, because someone else did the work to build it reliably and install it in the right places. what it doesn't do is enforce a correctness constraint that forces you to pull in packages you didn't explicitly consent to (!!!)
-
i was shocked to finally understand the zen of slackware thanks to @miss_rodent's patient explanation. no dependencies? what's the point then? why not build everything by hand? but i slowly began to pull these apart:
- a distro package recipe bundles the code for your distro
- a package manager builds or downloads the package by name (checking signatures and/or checksums)
afaiu, slackware does that just fine. and it is better than building from source by hand, because someone else did the work to build it reliably and install it in the right places. what it doesn't do is enforce a correctness constraint that forces you to pull in packages you didn't explicitly consent to (!!!)
@hipsterelectron @miss_rodent so what you're saying is the package manager slacks off
-
i was shocked to finally understand the zen of slackware thanks to @miss_rodent's patient explanation. no dependencies? what's the point then? why not build everything by hand? but i slowly began to pull these apart:
- a distro package recipe bundles the code for your distro
- a package manager builds or downloads the package by name (checking signatures and/or checksums)
afaiu, slackware does that just fine. and it is better than building from source by hand, because someone else did the work to build it reliably and install it in the right places. what it doesn't do is enforce a correctness constraint that forces you to pull in packages you didn't explicitly consent to (!!!)
transitive dependencies absolutely raise questions about user consent. and failing to separate the human groups communicating across the dependency graph leads to consent violations by fiat. @ariezra's Industry Unbound used the term "engineering fiat" for intentional corporate violations of their customer's consent and it put words to what i had observed but could never verbalize from google and the rest
-
i was shocked to finally understand the zen of slackware thanks to @miss_rodent's patient explanation. no dependencies? what's the point then? why not build everything by hand? but i slowly began to pull these apart:
- a distro package recipe bundles the code for your distro
- a package manager builds or downloads the package by name (checking signatures and/or checksums)
afaiu, slackware does that just fine. and it is better than building from source by hand, because someone else did the work to build it reliably and install it in the right places. what it doesn't do is enforce a correctness constraint that forces you to pull in packages you didn't explicitly consent to (!!!)
@hipsterelectron @miss_rodent wait, what? Isn’t Slackware rpm-based?
-
@hipsterelectron @miss_rodent wait, what? Isn’t Slackware rpm-based?
@hipsterelectron @miss_rodent I guess not. My use of Slackware was in the very early aughts without reliable access to binary package repositories, so after initial install, I built a lot of things from source.
-
transitive dependencies absolutely raise questions about user consent. and failing to separate the human groups communicating across the dependency graph leads to consent violations by fiat. @ariezra's Industry Unbound used the term "engineering fiat" for intentional corporate violations of their customer's consent and it put words to what i had observed but could never verbalize from google and the rest
and the "correctness" construction of a global shared versioning, which derives ancestrally from shared libraries and the libc, has been bowdlerized and twisted beyond recognition, while the end user has absolutely no mechanism for configuration:
- what if i wanted kde connect without network access? too bad, now the service can ping whoever it wants.
- what if i wanted systemd without the user age record functionality required for OS vendors in pending US federal law? too bad, your distro is US surveillance compliant now.
- what if i wanted linux without "AI"? too bad, we publicized vulnerabilities we knew about years ago and we hate LTS kernels so you're on the backdoored 7.0
-
transitive dependencies absolutely raise questions about user consent. and failing to separate the human groups communicating across the dependency graph leads to consent violations by fiat. @ariezra's Industry Unbound used the term "engineering fiat" for intentional corporate violations of their customer's consent and it put words to what i had observed but could never verbalize from google and the rest
@hipsterelectron @ariezra "Transitive dependencies violate consent" sounds like some purist view about not wanting tainted code present on your machine at all, until you realize what it actually means in practice.
The best examples I know of are polkit and dbus service activation.
There are packages that pull in polkit as a dependency, and when they do, that's not just code present for the program to run. It's literally *installing a backdoor to root* which will be automatically executed to give requesting processes elevated permissions if conditions met in obtuse configuration files (also installed without consent).
Same conceptual thing happens with dbus service activation in general. Mere presence of these service files causes existing dbus to give access to launch things without your consent.
-
and the "correctness" construction of a global shared versioning, which derives ancestrally from shared libraries and the libc, has been bowdlerized and twisted beyond recognition, while the end user has absolutely no mechanism for configuration:
- what if i wanted kde connect without network access? too bad, now the service can ping whoever it wants.
- what if i wanted systemd without the user age record functionality required for OS vendors in pending US federal law? too bad, your distro is US surveillance compliant now.
- what if i wanted linux without "AI"? too bad, we publicized vulnerabilities we knew about years ago and we hate LTS kernels so you're on the backdoored 7.0
because spack was conceived in an environment where the end user is a programmer and not a packager, and used in airgaps (the original sandbox), it had to support injecting deps from the host (compiler, libc) and configuring build-time options, without forcing physicists to also keep up with configure flag renames and build system changes.
a spack spec says "i don't want qt. computer, give me physics without qt." and the computer does what computers are fucking good at and applies the rulesets from spack package recipe maintainers.
-
because spack was conceived in an environment where the end user is a programmer and not a packager, and used in airgaps (the original sandbox), it had to support injecting deps from the host (compiler, libc) and configuring build-time options, without forcing physicists to also keep up with configure flag renames and build system changes.
a spack spec says "i don't want qt. computer, give me physics without qt." and the computer does what computers are fucking good at and applies the rulesets from spack package recipe maintainers.
@hipsterelectron amen to a system that can track wtf you need well enough for airgaps. modern bullshit environments, tell someone you're gonna dev on an airgap'd box and they won't even believe it can be done. and it's not easy.
-
because spack was conceived in an environment where the end user is a programmer and not a packager, and used in airgaps (the original sandbox), it had to support injecting deps from the host (compiler, libc) and configuring build-time options, without forcing physicists to also keep up with configure flag renames and build system changes.
a spack spec says "i don't want qt. computer, give me physics without qt." and the computer does what computers are fucking good at and applies the rulesets from spack package recipe maintainers.
it is a fucking FAILURE if your system requires end users to concern themselves with how packages are built. it is a fucking FAILURE if your system requires end users to recreate your system by hand to avoid surveillance and backdoors. it is a fucking FAILURE if your system cannot handle fucking updating a dependency without invalidating an entire subgraph, let alone the whole fucking graph.
-
it is a fucking FAILURE if your system requires end users to concern themselves with how packages are built. it is a fucking FAILURE if your system requires end users to recreate your system by hand to avoid surveillance and backdoors. it is a fucking FAILURE if your system cannot handle fucking updating a dependency without invalidating an entire subgraph, let alone the whole fucking graph.
it is a fucking FAILURE if your system has such a limited logical representation of package dependencies that you cannot support injecting a user-provided compiler or library without making them build it from scratch within your system. that does not make people safer. it means users will take shortcuts and rely upon someone else's recipe because you have made it impossible for them to use their own trusted tooling
-
it is a fucking FAILURE if your system has such a limited logical representation of package dependencies that you cannot support injecting a user-provided compiler or library without making them build it from scratch within your system. that does not make people safer. it means users will take shortcuts and rely upon someone else's recipe because you have made it impossible for them to use their own trusted tooling
this is why a build system like the one i've finally figured out how to write must be bootstrappable itself—and bootstrappable means not just "can be built from a standard basis" but "can use user-provided resources where available". sure, technically curling a binary is "bootstrappable", but it's not secure, and it requires network access (incompatible with an airgap, the original sandbox).
and this is why (until gccrs) i can't use rust, and even with gccrs i can't use cargo. luckily, my build system will be better than cargo, and if i haven't written my own package manager, then i can use spack. spack requires python, but not openssl. and i can make a bootstrapped cpython, better than anyone else
-
this is why a build system like the one i've finally figured out how to write must be bootstrappable itself—and bootstrappable means not just "can be built from a standard basis" but "can use user-provided resources where available". sure, technically curling a binary is "bootstrappable", but it's not secure, and it requires network access (incompatible with an airgap, the original sandbox).
and this is why (until gccrs) i can't use rust, and even with gccrs i can't use cargo. luckily, my build system will be better than cargo, and if i haven't written my own package manager, then i can use spack. spack requires python, but not openssl. and i can make a bootstrapped cpython, better than anyone else
@hipsterelectron i wonder if spack can work on a python reimpl (though those are sometimes a bit flaky, idk how pypy goes or is)
-
this is why a build system like the one i've finally figured out how to write must be bootstrappable itself—and bootstrappable means not just "can be built from a standard basis" but "can use user-provided resources where available". sure, technically curling a binary is "bootstrappable", but it's not secure, and it requires network access (incompatible with an airgap, the original sandbox).
and this is why (until gccrs) i can't use rust, and even with gccrs i can't use cargo. luckily, my build system will be better than cargo, and if i haven't written my own package manager, then i can use spack. spack requires python, but not openssl. and i can make a bootstrapped cpython, better than anyone else
personally, i find "b2c" quite subversive. if they're our customers, then we have stolen them from corporate middlemen. we can serve them without profit, unless the customer is for-profit. this is why i believe so fervently in dual licensing, because corps are not humans. copyleft is a legal technique, not an ideology—and we're not apolitical, we embrace ideology
-
J jwcph@helvede.net shared this topic
