Yes, but each package manager has it’s (dis-)advantages. It’s great to have flatpak and docker to be able to run software on almost all distros, but the OS still needs a way to update.
Almost all immutable distros use multiple package manager.
NixOS is unique because it uses the only potent package manager (if we don’t count that one reimplementation of Nix). Calling the others “package managers” becomes mostly a courtesy when NixOS enters the picture.
lalala with FS-level snapshots + flatpak + distrobox + a kitchen sink
I don’t consider myself a dumb person but I couldn’t figure out nix when last I decided to play with it. Theoretically it seems super interesting to me, but I really just can’t dedicate the time again now to learn that esoteric syntax.
I absolutely loved NixOS on paper, and it’s undoubtedly the best way to combat updates that break my dependency trees, but I still found myself spending a majority of my time attempting to hard-code various app configuration files into my convoluted configuration.nix with its esoteric syntax rather than actually using my computer. Am I missing something, or does a good install script covering my favorite packages and a git bare repo storing my dot-files get me 90% of the way there without the hassle of bending my whole OS around a single nix config monstrosity?
Agreed, I’m also considering switching to an install script + btrfs snapshots. It worked quite well a few years ago, altough it doesn’t solve configuration drift.
When I used to build app packages internally I also built packages for our own python and ruby versions for our in-house software. The motto was: “system packages are for system software”. We weren’t writing system software, we were writing business software and shipping it, so why be dependent on what Redhat or Debian provided?
Universal packages are just an extension of this philosophy, and is why things like docker and app stores are such a success. Burdening the user with getting system dependencies right is worse than the DLL hell of the old windows days.
Docker is a success in some ways, but it’s not a silver bullet. It’s a great way to make a 800 KiB program ship in a complex 300 MiB box.
If you had an entire operating system built with static links, it would be giant and ugly. You have to stop and think: if it’s such a great idea, then why does pretty much every distro supply packages with dynamic links?
When shipping your own software, yes, you certainly want control over your own runtime. If you rely on an OS-supplied Ruby, for example, then when Ruby 3.3.0 comes out, your gems will need to be rebuilt, and it’ll happen by surprise. A runtime and shipping stuff to your own infra is much different than packages responsible for running the operating system.
It’s almost a silver bullet. 300mb is pretty modest by today’s standards, and nix supports both bare metal and docker containers, and everything in between
Seems to me we need to bridge that gap - make nix smarter and more compatible with docker, and we get a fully featured desktop/dev environment that can be packaged directly into the minimal reproducible deployment package
There’s another aspect than size that I feel people overlook: security updates. When e.g. libcurl is duplicated in a million places, how do you update them all when a critical security issue is discovered in it? Who will update all the random flatpaks, snaps and docker images that happen to include it?
Yeah, there is definitely a delineation between system and user, and like most things the line will be fuzzy.
But in that end-user software space, 300mb is a pittance to pay for a minor system package update not breaking their favorite application, or a user not being able to use software because their distro is one version behind on libfoo.
Imagine a world where people say “I would use Linux, but I’m going to stay with Windows because Linux is too bloated.”
I don’t know where the recent surge of not wanting package dependencies is coming from. Folks even not wanting dynamic links. We’re acting like Linux distros are somehow suddenly broken or impossible to maintain, yet there are hundreds of successful distros doing just that, and for decades.
You gotta have more empathy for the average person.
If the average person cared about binary size in terms of bloat, then being that smartphone apps are almost all statically linked, why are smartphones the most popular computer in the world?
To them bloat would feel more like apps you can’t delete, or say ads in a key gui component.
The bloat most people will care about in terms of Linux is facing down a software update prompt with 1000 packages and feeling anxiety over the last such dialog box destroying the use of their favorite apps.
I’m glad there are hundreds of successful distros, their complexities will serve well the hundreds of Linux desktop users.
The bloat most people will care about in terms of Linux is facing down a software update prompt with 1000 packages and feeling anxiety over the last such dialog box destroying the use of their favorite apps.
This would be a bug in packaging. File a bug with the distro.
This doesn’t happen as often as you think on a properly-configured system.
Usually people mean flatpak and other desktop-focused formats when talking about universal package formats.
Even docker images are usually built with traditionial package managers, except if they’re built directly by Nix.
I agree that there won’t be “the” package format, since they all have their tradeoffs. E.g. Nix updates need quite a bit of memory, so it isn’t a good choice for resource constrained embedded use-cases.
Why not? It always seemed to me like a lot of duplicated work to package everything on every distro.
Yes, but each package manager has it’s (dis-)advantages. It’s great to have flatpak and docker to be able to run software on almost all distros, but the OS still needs a way to update.
Almost all immutable distros use multiple package manager.
All those OS support distrobox and docker additionally.
NixOS is unique because it uses the only potent package manager (if we don’t count that one reimplementation of Nix). Calling the others “package managers” becomes mostly a courtesy when NixOS enters the picture.
look_what_they_need_to_mimic_the_fraction_of_our_power.png
I don’t consider myself a dumb person but I couldn’t figure out nix when last I decided to play with it. Theoretically it seems super interesting to me, but I really just can’t dedicate the time again now to learn that esoteric syntax.
The docs for NixOS aren’t good. Much knowledge is on many blogs but who knows them all?
Having the OS defined declaratively is great but I also dislike the Nix language.
Once it’s setup NixOS is great. Sharing configs with PC and laptop is awesome. Rollbacks are baked in.
Going off the https://github.com/Misterio77/nix-starter-configs helped me gettung started.
I absolutely loved NixOS on paper, and it’s undoubtedly the best way to combat updates that break my dependency trees, but I still found myself spending a majority of my time attempting to hard-code various app configuration files into my convoluted
configuration.nixwith its esoteric syntax rather than actually using my computer. Am I missing something, or does a good install script covering my favorite packages and a git bare repo storing my dot-files get me 90% of the way there without the hassle of bending my whole OS around a single nix config monstrosity?Agreed, I’m also considering switching to an install script + btrfs snapshots. It worked quite well a few years ago, altough it doesn’t solve configuration drift.
Only if you reinstall every time you change the configuration. And never need to do anything remotely fancy.
The syntax is just the outer layer, the whole concept inside it is alien. It’s like a smartphone for a person who’s only seen books.
I found zero to nix to be a good tutorial
You can use at least appimage with NixOS…
You cah also tow a Tesla with a couple of horses
And flatpak
all the more reason to sunlight these old packaging formats and move to universal solutions like flatpak and nix
Linked dependencies, for one. What if your distro uses uClibc? A different imagemagick version? What about LTS distros? Immutable distros?
What if who cares?
When I used to build app packages internally I also built packages for our own python and ruby versions for our in-house software. The motto was: “system packages are for system software”. We weren’t writing system software, we were writing business software and shipping it, so why be dependent on what Redhat or Debian provided?
Universal packages are just an extension of this philosophy, and is why things like docker and app stores are such a success. Burdening the user with getting system dependencies right is worse than the DLL hell of the old windows days.
Docker is a success in some ways, but it’s not a silver bullet. It’s a great way to make a 800 KiB program ship in a complex 300 MiB box.
If you had an entire operating system built with static links, it would be giant and ugly. You have to stop and think: if it’s such a great idea, then why does pretty much every distro supply packages with dynamic links?
When shipping your own software, yes, you certainly want control over your own runtime. If you rely on an OS-supplied Ruby, for example, then when Ruby 3.3.0 comes out, your gems will need to be rebuilt, and it’ll happen by surprise. A runtime and shipping stuff to your own infra is much different than packages responsible for running the operating system.
It’s almost a silver bullet. 300mb is pretty modest by today’s standards, and nix supports both bare metal and docker containers, and everything in between
Seems to me we need to bridge that gap - make nix smarter and more compatible with docker, and we get a fully featured desktop/dev environment that can be packaged directly into the minimal reproducible deployment package
And that sounds like a silver bullet to me
There’s another aspect than size that I feel people overlook: security updates. When e.g. libcurl is duplicated in a million places, how do you update them all when a critical security issue is discovered in it? Who will update all the random flatpaks, snaps and docker images that happen to include it?
Yeah, there is definitely a delineation between system and user, and like most things the line will be fuzzy.
But in that end-user software space, 300mb is a pittance to pay for a minor system package update not breaking their favorite application, or a user not being able to use software because their distro is one version behind on libfoo.
Imagine a world where people say “I would use Linux, but I’m going to stay with Windows because Linux is too bloated.”
I don’t know where the recent surge of not wanting package dependencies is coming from. Folks even not wanting dynamic links. We’re acting like Linux distros are somehow suddenly broken or impossible to maintain, yet there are hundreds of successful distros doing just that, and for decades.
You gotta have more empathy for the average person.
If the average person cared about binary size in terms of bloat, then being that smartphone apps are almost all statically linked, why are smartphones the most popular computer in the world?
To them bloat would feel more like apps you can’t delete, or say ads in a key gui component.
The bloat most people will care about in terms of Linux is facing down a software update prompt with 1000 packages and feeling anxiety over the last such dialog box destroying the use of their favorite apps.
I’m glad there are hundreds of successful distros, their complexities will serve well the hundreds of Linux desktop users.
This would be a bug in packaging. File a bug with the distro.
This doesn’t happen as often as you think on a properly-configured system.
Usually people mean flatpak and other desktop-focused formats when talking about universal package formats.
Even docker images are usually built with traditionial package managers, except if they’re built directly by Nix.
I agree that there won’t be “the” package format, since they all have their tradeoffs. E.g. Nix updates need quite a bit of memory, so it isn’t a good choice for resource constrained embedded use-cases.
deleted by creator
Dude, what the fuck are you on about?