[HN Gopher] Identifying Software
___________________________________________________________________
Identifying Software
Author : ementally
Score : 106 points
Date : 2024-03-12 18:12 UTC (1 days ago)
(HTM) web link (guix.gnu.org)
(TXT) w3m dump (guix.gnu.org)
| datadrivenangel wrote:
| "we believe binary artifacts should instead be treated as the
| result of a computational process; it is that process that needs
| to be fully captured to support independent verification of the
| source/binary correspondence. "
|
| So binary artifacts should verifiably come from source code,
| which can be accomplished by signing it with a signing mechanism
| specified in the source code?
| abound wrote:
| Since this is coming from the GNU folk, they naturally have
| their inclinations towards open-source software, but I'd argue
| (and they probably would too) that reproducibility is a much
| stronger invariant than just code signing.
|
| Bootstrapping everything from a tiny first stage compiler and
| getting bit-identical compiled outputs is a much higher level
| of confidence than PKI offers, as PKI can be cracked, stolen,
| made to sign things it shouldn't, etc. Even if the signature is
| legit, it doesn't help you against insider risk (e.g.
| internally added backdoors) on closed source software.
|
| These are all things governments (should probably) care about.
| tarruda wrote:
| Here's a must read that helps newcomers understand one of the
| problems Guix attempts to solve: https://www.cs.cmu.edu/~rdri
| ley/487/papers/Thompson_1984_Ref...
| Zambyte wrote:
| I have felt spoiled by GNU Guix honestly. It has documentation
| that is comparable to Gentoo or Arch, power over your system that
| generally matches Gentoo (though a system-wide equivalent of USE
| flags is not yet available, individual packages can be
| configured), the ease of maintenance of a system like Fedora
| Silverblue, and one of the most approachable communities I have
| ever dealt with. I highly recommend playing around with it :)
| xcdzvyn wrote:
| Interesting, so the docs are better than Nix'?
|
| I've been meaning to finally figure out LISP, I'd be willing to
| use this as an excuse!
| Zambyte wrote:
| I used Nix for a few months several years ago, so their
| documentation is probably better now than I was when I used
| it, but yeah, I find the Guix documentation to be much more
| pleasant to use than the Nix documentation was when I used
| it.
|
| This is partially because it uses an existing language,
| rather than a home grown language. Guix was also my entry
| point for learning Lisp, and the abundance of learning
| material for the language will probably always dwarf that of
| Nixs homegrown language. I actually watched all of the SICP
| lectures; I found that to be an incredible resource to get my
| footing.
|
| It's also important to note that Guixs documentation is
| readily available on the system using the GNU info utility,
| which if you're not familiar with, is like man but on
| steroids. If you use Kagi, I also made this lens[0] that
| allows one to search through the web version of the
| documentation, the mailing list archives, and the IRC logs
| all at once using !guix.
|
| [0] https://kagi.com/lenses/l7mPOuJp7zljHquBjsekFn6dM9Thw1A8
| kriiuuu wrote:
| I use nix and the documentation is dogwater. It's the best
| system I have ever used, but by god you need to get your
| hands dirty with it for a while.
| lambdaba wrote:
| What are the technical merits of Guix compared to Nix? Also,
| what's the situation with unfree packages? And package
| availability in general?
| Zambyte wrote:
| Guix started as a fork of Nix, but I believe all original Nix
| code has been replaced with Guix specific code at this point.
| Core functionality is pretty comparable between the two of
| them. Two differences I can tell you immediately is that GNU
| Guix has a built in user home configuration management
| system[0], and Nix depends on an external module to do the
| same[1]. NixOS, like most distros uses systemd for it's init
| system. GNU Guix uses Shepherd[2]. Honestly it hasn't really
| been much of a point of note in my experience, but it's
| probably worth mentioning as a difference.
|
| Regarding Free vs non-Free packages: this can be a pain point
| if your system requires non-Free packages to function on GNU
| Guix. I (like most other Guix users I would guess) use the
| nonguix[3] channel for additional packages. One of my systems
| requires the baseline Linux kernel for propriety Ethernet
| drivers (included in Linux because of GPLv2 :P), so I had to
| create a custom installation ISO with the baseline kernel.
| This probably sounds horrifying, but creating a custom
| installation ISO is actually very easy in Guix (and probably
| Nix as well). It's the only distro I've ever done it for.
|
| But between the main Guix channel, nonguix, and Flatpak, it's
| very uncommon that I cannot find what I want. According to
| repology[4], Guix is the #5 repo for most packages. And the
| few packages that I have wanted that were missing, I have
| actually been able to contribute package definitions for
| upstream to Guix, since the process is very easy and well
| documented (also the only distro I have ever done that for).
|
| [0] https://guix.gnu.org/manual/en/html_node/Home-
| Configuration....
|
| [1] https://github.com/nix-community/home-manager
|
| [2] https://www.gnu.org/software/shepherd
|
| [3] https://gitlab.com/nonguix/nonguix
|
| [4] https://repology.org/
| nextos wrote:
| An interesting advantage of Guix over Nix is having better
| options for runtime isolation. Nix is not well developed in
| this area yet, although one can always use bwrap or
| AppArmor to implement something ad hoc.
|
| Besides, Guix uses Scheme everywhere, whereas Nix is a mix
| of the Nix language and lots of shell code. The Nix
| language is a pretty elegant lazy functional language, and
| yields very compact and clean code. But if you want to do
| complex things, Scheme might be easier.
| ryukafalz wrote:
| Although it doesn't seem have much in the way of runtime
| isolation of Guix source files themselves. From what I
| can tell it runs the Guile scripts that evaluate to
| manifests and such as your own user, with all of the
| authority associated with that.
|
| So although Guix provides good mechanisms for isolating
| applications at runtime, you do have to put a lot of
| trust in the channels you're using.
|
| (This is something I would like to see improved as a Guix
| user.)
| BlueTemplar wrote:
| There's also a social element here : communities around
| software matter, and I for one (being a EU developer, for
| reasons of professional ethics) cannot justify any more
| associating myself with the kind of developer that _still_
| thinks it 's acceptable to use Github (especially for
| something as fundamental as Nix(OS) - and I'm pretty sad
| about Rust too) (at this point developers had enough time to
| migrate even the most complicated projects off of it).
| bbkane wrote:
| Because GitHub is non-FOSS or owned by Microsoft or
| something? I use GitHub, and I don't really have any
| complaints...
| zamalek wrote:
| > What are the technical merits of Guix compared to Nix?
|
| It doesn't boot on non-libre hardware.
|
| In all seriousness, it uses Lisp. That is a _substantial_
| advantage over Nix - which uses a home-grown language. As you
| can see from the front page today, there is roughly a million
| Nix-wrappers addressing the issue that people don't want to
| learn nixlang.
| orbital-decay wrote:
| All these wrappers are there because nixpkgs doesn't have
| non-awkward ways to deal with the stuff people deal with
| often. Nix the language is probably the least of the
| issues, it's maybe a few % of the chaotic Nix ecosystem.
| Most of the logic (that desperately needs proper
| documentation) is in nixpkgs and tooling.
| mdaniel wrote:
| s/Lisp/scheme/ unless you meant "a Lisp"
| https://guix.gnu.org/manual/en/html_node/Package-
| Modules.htm... ->
| https://www.gnu.org/software/guile/manual/html_node/Guile-
| an...
|
| but I'm with you on "why in the holy hell reinvent the
| wheel". I need to dig back into Guix and see if it supports
| moving the store out of /gnu since on Cupertino's OS one
| cannot write to / without a bunch of stupidity <https://nix
| os.org/manual/nix/stable/installation/installing-...>
| weinzierl wrote:
| This is good take on the topic focusing on intrinsic identifiers.
| Guix has their own approach but the article also mentions
| SWHID[1] and OmniBOR[2] which are both contenders to fill that
| space.
|
| SWHID is on its way to become an ISO standard[3]. OmniBOR is
| quite new but a highly interesting approach.
|
| Because it does not directly solve any problems for Guix, it's
| fair enough that they do not talk about much about extrinsic
| identifiers except to rightfully dismiss CPE as _" showing its
| limits"_, which is put mildly.
|
| I think there is need for an extrinsic identifier standard beyond
| CPEs (in addition to intrinsic identifiers).
|
| While intrinsic identifiers allow us to pinpoint artifacts
| exactly sometimes this is not what we want. Sometimes we
| deliberately want to talk about sets of artifacts together, like
| variants or versions of an artifact. One contender would be
| purl[4] (as in package URL and not the older persistent uniform
| resource locator).
|
| [1] https://www.swhid.org
|
| [2] https://omnibor.io
|
| [3] https://hal.science/hal-04121507v1/file/2023-03-27-SWHID-
| kic...
|
| [4] https://github.com/package-url/purl-spec
| GlenTheEskimo wrote:
| Yep, it's software
| epiccoleman wrote:
| This is exactly the meme that came to mind when I saw the topic
| title, glad I'm not the only one who's had their brain ruined
| like this ;)
| robblbobbl wrote:
| Way too late but downvoting always works.
___________________________________________________________________
(page generated 2024-03-13 23:01 UTC)