this post was submitted on 14 Jul 2023
82 points (89.4% liked)

Technology

58677 readers
3656 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
 

So a few popular Linux distros decided to drop a few major packages like how red hat dropped rpm packages for libreoffice in favor for the flatpak packages.

If more distros decided to drop more packages from their main repository in favor for flatpak packages, then are there any obvious concerns? From my personal experience, flatpaks didn't work well for me. If flatpaks become mainstream and takeover the linux distros, then I might just move to Freebsd. I just want to know if there is any positives to moving away from official repositories to universal repositories.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago

It doesn't iterate on Flatpak, it's its own thing.

Describing Nix in detail would require a PHD thesis but in short it takes the concept of a version to the extreme; capturing every property about some package and encoding that into the "version"; a package bar-0.1.0 that depends on foo-1.0.0 and a package bar-0.1.0 depending on foo-1.0.0 that has been built with the same GCC but a patch applied to it are considered entirely separate. This implies that your package bar cannot accidentally depend on the wrong foo and that both can be present at the same time.
Using a functional DSL, you implicitly build up a tree of such "exact versions" of dependencies and this tree is then "realised" bottom to top.
It takes many inspirations from functional programming such as purity and immutability. The build takes place in a sandbox with no filesystem access outside the declared dependencies and not networking whatsoever and cannot be changed after the fact. This aims to ensure that a build really only depends on the paths it claims to depend on (those paths must also be "exact" versions) such that running the build again with the same inputs results in the exact same output.

Again, describing Nix in detail would go beyond the scope of this comment but this approach comes with many useful properties which prevent entire classes of issues you could encounter with classical package managers such as dependency hell.

It's not tied to NixOS either (that's its own thing again; doing Linux system configuration management using Nix), you can install Nix packages on pretty much any Linux as it doesn't interfere with your classical package manager. Give it a try: https://nixos.org/download.html