this post was submitted on 18 May 2026
127 points (91.0% liked)

linuxmemes

31474 readers
593 users here now

Hint: :q!

Sister communities:

Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
  • Don't get baited into back-and-forth insults. We are not animals.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
    • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn, no politics, no trolling or ragebaiting.
  • Don't come looking for advice, this is not the right community.
    • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
    • 5. 🇬🇧 Language/язык/Sprache
  • This is primarily an English-speaking community. 🇬🇧🇦🇺🇺🇸
  • Comments written in other languages are allowed.
  • The substance of a post should be comprehensible for people who only speak English.
  • Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
    • 6. (NEW!) Regarding public figuresWe all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations.
  • Keep discussions polite and free of disparagement.
  • We are never in possession of all of the facts. Defamatory comments will not be tolerated.
  • Discussions that get too heated will be locked and offending comments removed.
    •  

    Please report posts and comments that break these rules!

    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.

    founded 2 years ago
    MODERATORS
    poopsmith@lemmy.world
    zephyr@lemmy.world
    rtxn@lemmy.world
    127
    I'm looking for a free OS, should it be Debian or Arch Linux(community)? (lemmy.world)
    submitted 1 day ago by CarlLandry357@lemmy.world to c/linuxmemes@lemmy.world
    79 comments fedilink hide all child comments
     

    They say debian is free and has its promise, but Arch has like 2-4 maintainers?

    you are viewing a single comment's thread
    view the rest of the comments
    [–] chronicledmonocle@lemmy.world 2 points 5 hours ago (2 children)

    Out of curiosity, why avoid Flatpak? I get snap or AppImage, but Flatpak is generally great.

    [–] corsicanguppy@lemmy.ca 1 points 5 hours ago (1 children)

    why avoid Flatpak? I get snap or AppImage,

    Objectively, they all frustrate validation the same. When comparing with a SLSA3-compliant setup where every installed artifact has a signed checksum in a signed bundle from a signed resource on a signed repository, and the endpoint to this is readily available from something like authenticated SNMP into the single source of truth, they all tends to compare poorly.

    The chart below completely ignores that Debs are consolidated into a single source of truth as well, and I feel violating SSoT should cost significantly because of dependency holes when artifact registry is incomplete, but SLSA doesn't care about that part.

    Ecosystem / Format Estimated SLSA Level Update Reliability / Model Trust Chain & Provenance Comments
    (withheld) 3–4 Very high; repo-based, transactional updates Strong: signed packages + signed repo metadata + central DB; distros enforce reproducible builds.
    OCI containers (hardened pipeline: cosign + Tekton/in-toto) 3 High if using automated CI/CD and policy enforcement Strong if you use signed images + non-falsifiable provenance; this is rare but achievable.
    DEB (distro repos) 2 High; repo-based, APT handles dependencies Medium: repo metadata signed, but per-package signatures not mandatory; weaker checksum chain.
    Flatpak runtimes (Flathub) 2 High; centralized runtimes, predictable updates Medium: signed OSTree commits; build infra more centralized, but not full end-to-end provenance.
    Flatpak apps 1–2 High; repo-based, automatic updates Mixed: OSTree signing helps, but build provenance varies by publisher; no uniform SLSA guarantees.
    Snap (strict confinement) 1–2 High; centralized store, auto-updates Centralized signing by Canonical, but opaque build pipelines; trust is “trust the store operator.”
    OCI containers (typical public images) 0–1 Medium; pull-latest model, tag drift common Usually unsigned; mutable tags; no guaranteed provenance—trust is mostly social and reputation-based.
    Snap (classic confinement) 1 High; same store/auto-update model Same store trust, but classic snaps bypass sandbox; even more reliance on publisher integrity.
    AppImage 0–1 Low–medium; ad-hoc self-update or manual downloads Almost no chain of custody; signatures optional; no central repo or provenance expectations.
    npm (JavaScript) 0–1 High frequency, but low reliability of safety; semver + lockfiles Registry accounts can publish arbitrary tarballs; no default signed provenance; transitive deps explode risk.
    PyPI / pip (Python) 0–1 Similar to npm; pip + requirements/lockfiles Tarballs/wheels from arbitrary maintainers; no mandatory signing; provenance work (e.g., PEP 740) is emerging but not standard.
    Composer / Packagist (PHP) 0–1 Good tooling, but same “trust the registry” model Packages pulled from Packagist/VCS; no mandatory signatures; dependency graph trust is social, not cryptographic.
    CPAN (Perl) 0–1 Mature ecosystem, but manual/legacy in many flows Historically minimal provenance; mirrors and authors are trusted by convention, not by SLSA-style attestations.
    Other language registries (RubyGems, crates.io, etc.) 0–1 Similar to npm/PyPI; lockfiles help reproducibility Central registries, but no default SLSA provenance; integrity is mostly TLS + registry operator trust.
    [–] BodilessGaze@sh.itjust.works 1 points 2 hours ago

    Man, I really need to check out "(withheld)"

    Seriously though, nice table!