4 ms·

> They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstr

> They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo. So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager. > we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing. The "last thing I want" is a package manager that's invasive to use, doesn't have the latest software and is slow. Immutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

vetinari 4y ago
> So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager. So, they decided that the update path is always defined, from any state to the latest, without having to update the packages in specific order, where some steps needed may disappear. You know, being robust. If the year of linux desktop has to happen, not borking the system during updates is a requirement. You don't have a problem with daily updates? Congratulation, but your grandma probably has. > mmutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool! Immutable system does not prevent writable /usr/local/bin. Your one-off tool has no business messing with /usr/bin or /usr/lib. Immutable systems are also minimal; they don't care about your additional software, as it is separated from the base system. You can update your software at any pace you want; nightlies if you want. It just cannot touch anything in /usr (with /usr/local being exception).
- wootland 4y ago
  I actually don't want a package manager tuned for "my grandma" (the white whale of the linux community). I'm a professional dev, Arch perfectly suits my needs where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them (something I go out of my way to avoid at this point). > Immutable system does not prevent writable /usr/local/bin. I can't speak to the others, but Nix most definitely does not make /usr/local/bin writable. You have to package up your tools to use them.
  - vetinari 4y ago
    > I'm a professional dev So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. > Arch perfectly suits my needs Good for you. You just need to realize that you are minority. Do you notice that Arch is not the dominant distro? There's a reason for that. > where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them You are holding it wrong ;) > but Nix Nix is not exactly a typical immutable system; it has strong opinions about many things, that other systems don't. You can't evaluate other systems through assuming they are like nix. Nowadays, even MacOS is immutable and people live with it just fine.
    - wootland 4y ago
      > So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. I didn't say that you should use Arch on the server, but it's great for the desktop. You can refer to this entire thread to see how well Flatpak/Snap... are working out. Pretty much universally reviled by developers (people who actually use Linux on the desktop).
      - vetinari 4y ago
        > I didn't say that you should use Arch on the server, but it's great for the desktop. And I said that apt/dnf solve problems that pacman didn't start thinking about yet. So we are in agreement here. Flatpak seems to be working out pretty fine. > Pretty much universally reviled by developers (people who actually use Linux on the desktop). Two things: 1) Reviled by some very conservative types, often not willing to consider things from different perspective than what they are used to. If they would build the desktop, it would end up like Homer's dream car. 2) Don't you think that it is a problem when only developers use the desktop as it is? (Not really true, but let's consider that for the sake of argument).

vetinari 4y ago

> So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager. So, they decided that the update path is always defined, from any state to the latest, without having to update the packages in specific order, where some steps needed may disappear. You know, being robust. If the year of linux desktop has to happen, not borking the system during updates is a requirement. You don't have a problem with daily updates? Congratulation, but your grandma probably has. > mmutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool! Immutable system does not prevent writable /usr/local/bin. Your one-off tool has no business messing with /usr/bin or /usr/lib. Immutable systems are also minimal; they don't care about your additional software, as it is separated from the base system. You can update your software at any pace you want; nightlies if you want. It just cannot touch anything in /usr (with /usr/local being exception).

wootland 4y ago
I actually don't want a package manager tuned for "my grandma" (the white whale of the linux community). I'm a professional dev, Arch perfectly suits my needs where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them (something I go out of my way to avoid at this point). > Immutable system does not prevent writable /usr/local/bin. I can't speak to the others, but Nix most definitely does not make /usr/local/bin writable. You have to package up your tools to use them.
- vetinari 4y ago
  > I'm a professional dev So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. > Arch perfectly suits my needs Good for you. You just need to realize that you are minority. Do you notice that Arch is not the dominant distro? There's a reason for that. > where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them You are holding it wrong ;) > but Nix Nix is not exactly a typical immutable system; it has strong opinions about many things, that other systems don't. You can't evaluate other systems through assuming they are like nix. Nowadays, even MacOS is immutable and people live with it just fine.
  - wootland 4y ago
    > So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. I didn't say that you should use Arch on the server, but it's great for the desktop. You can refer to this entire thread to see how well Flatpak/Snap... are working out. Pretty much universally reviled by developers (people who actually use Linux on the desktop).
    - vetinari 4y ago
      > I didn't say that you should use Arch on the server, but it's great for the desktop. And I said that apt/dnf solve problems that pacman didn't start thinking about yet. So we are in agreement here. Flatpak seems to be working out pretty fine. > Pretty much universally reviled by developers (people who actually use Linux on the desktop). Two things: 1) Reviled by some very conservative types, often not willing to consider things from different perspective than what they are used to. If they would build the desktop, it would end up like Homer's dream car. 2) Don't you think that it is a problem when only developers use the desktop as it is? (Not really true, but let's consider that for the sake of argument).