|Subject:||Re: Xiden/Guix design comparison|
|Date:||Wed, 25 Aug 2021 00:38:22 -0700|
This is an offshoot Q&A based off Devos' questions in the "How did you handle making a GNU/Linux distribution?" thread. It pertains to how Guix compares to Xiden on some points.
Given the length of both of our emails, I don't expect everyone
to read this. Guix is mentioned for discussion purposes, but I use
the -devel list only because the questions did. Apologies to the
mods if that's not an excuse, since I'm not trying to distract
from the purpose of the list.
Read on only if you care.
In Xiden, package versions and the notations used to express them
are user-defined. If you use semver and I use dates, we can still
map our dependency lists to the same package definitions. Xiden
leaves it to us to agree on a scheme for some set of packages.
> SHA-384 and Keccak are separate things? [...] By definition,
implementations of SHA-384 have no reason to use Keccak.
Correct. I'm just saying that Alice's decision to prefer a
SHA-384 implementation for using Keccak is not our business. Ditto
for Bob and SHA-1. Alice can force use of Keccak for software
arriving on her system with Xiden, without needing to discuss that
She's in charge of how a package manager works on her system, and
we aren't. Xiden approaches CHFs similarly to OpenSSL in that
implementations are selected by providers, except in Xiden a
knowledgeable user may assume the role of a CHF implementation
provider for their own system. I suspect we'd agree that is a
terrible idea, which is why I use zero-trust defaults for
everything to mitigate risks.
I allow for danger because most software distribution problems
I've seen in the field boil down to smart people dealing with the
lasting consequences of outdated or rushed decisions. I'm not
assuming competency, but I am assuming that even those with bad
practices still need to solve their distribution problems.
unconditionally prefers cached installations, such that every defined artifactComing from Guix, I don't know what this means. Does this mean only one version
has exactly one stored copy on disk.
of a package can be in the store at the same time, and building a newer version
deletes the older version? How does this compare with ‘content deduplication’?
but only for artifacts from services authenticated by his operating system's certificatesThis is rather vague to me, unless you're referring to substitutes.
What does this mean for origin specifications?
(uri (string-append "mirror://gnu/hello/hello-" version
(sha256 ; imagine this was SHA-1 instead.
Bob got the origin specification from Xiden (or something like a Guix channel
but for Xiden). How would this ‘artifact’ authenticated by ‘operating system
certificates’? I mean, when you let your operating system build that origin
(via guix (or Xiden?), which you could consider part of the OS), it will check
that hash, and it will be considered valid (‘authenticated?’) if the hash matches.
There are no certificates at play here.
I suppose the OS (guix or Xiden?) could then ‘sign’ it, but what value does that
provide to Bob? (Unless Bob runs a substitute server on their computer.)
trusts digest creation and signature verification as implemented by his host's dynamically--linked `libcrypto` library for use in the same process.AFAIK there is no such thing a ‘GitHub packages’. What is a ‘GitHub package’,
downloads content from GitHub packages
such that packages cannot conflict in a shared namespace‘packages cannot conflict in a shared namespace’ is a bit vague.
Are you referring to ‘profile collisions’? About having multiple versions
of the same package on the same system? Guix (and nix) can handle the latter.
When the ‘propagated-inputs’ are limited, installing multiple packages each using
a different version of a package is possible.
Is something missing from Guix here (please be very concrete)? [...] I'm not sure what you mean here, can you illustrate this very concretely? And is something missing in Guix here?
A Xiden launcher may translate your preferred version notation to an upstream scheme.prefers Semantic VersionsIf upstream doesn't do ‘semver’, and instead uses a versioning system like
used by TeX (3.14, 3.141, 3.1415, 3.14159, ...), then Xiden cannot somehow
let the package use ‘semver’ instead. Unless you want to teach Xiden to
convince upstream to change their versioning system?
These preferences are valid in Xiden's DSL for writing launchers.What is a launcher (compared to packages in Guix), and why would I want one?
The docs say what a launcher is.
You want one if you want to adapt to social and technical
differences between package management systems. Xiden does not
know what you want without clarification from you, for
similar reasons to why Vulkan ended up more explicit than
Why shouldn't I just install packages and run them ("guix package -i texmacs",
start texmacs from some application chooser menu of the desktop environment).
Your question assumes `guix` is the command you want to run,
which is fine, but not everyone is you. I suspect that's why you
are struggling to understand how Xiden works, because Xiden does
not prescribe itself as the sole option for how you put things on
your system. It can also serve as a bridge between your existing
I think the pattern of everybody and their cat making a GNU/Linux
distribution with a new package manager raises questions about
interoperability. I'm trying to address that by saying that Xiden
is to package managers what Racket is to programming languages.
The white paper covers this.
The invariants for each launcher can differ as much as Cargo and Vortex differ.What are these invariants you're speaking of? I don't think you're referring
What I wanted to do was allow users to declare their own invariants explicitly,
but only when those invariants are wanted for subjective reasons.
to, say, translation invariance (‘the laws of physics remain the same under a
translation of the coordinate system’).
Or do you mean something like ‘Invariant (computer science), an _expression_ whose
value doesn't change during program execution’ (<https://en.wikipedia.org/wiki/Invariant>)?
But what are the ‘expressions’ in this case?
Xiden launchers have advantages over shell scripts in that we can both still downloadWhat is a ‘catalog maintainer’ (maybe it's like someone with commit access to a ‘guix channel’?)
and install dependencies from the same servers, and create reproducible builds in terms
of the same (bit-identical) state on disk. We just differ on details that shouldn't impact
how we work. It also helps us patch holes faster, since if (say) a catalog maintainer tells
Also, what ‘shell scripts’ are you referring to.
us that a CHF was compromised, we can immediately revoke trust in the CHF independentlyMaybe guix could gain a command "guix style transition-hash OLD NEW" to automagically
rewrite package definitions to use the new hash algorithm instead of the old. It will
need to download plenty of source code however, and it will entail a world-rebuild.
in our own clients.What are these ‘clients’ you're speaking of? I haven't been needing any ‘clients’ lately.
The package definitions are all expressed in terms of what the launchers allow.If 'package definition' = (package definition as in Guix), then this is false,
Guix doesn't have a notion of ‘launchers’ and doesn't depend on ‘Xiden’.
What are you meaning, exactly? Also, I haven't found any package definitions in Xiden,
could you point me to any?
Why would I want to ‘escape to a new distribution model’? Writing something like Guix
from scratch seems a lot of work to me, I would rather fork Guix (with a few
likewise-minded collaborators) than to start over again. Or move to Debian maybe.
I don't see what ‘Xiden’ could offer here.
I would rather not have to ‘adapt to problems’, I would rather that upstream has somethingWe differ here. I need the ability to make my own decisions that may contradict upstream decisions at any time. That's a freedom I value and aim to protect.
that works (though I can understand if occasionally mistakes are made).
|[Prev in Thread]||Current Thread||[Next in Thread]|