3 ms·

Thank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.

by mikae1 13d ago

curt15 13d ago
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
- mikae1 13d ago
  > Where do you draw the line between system packages and user facing apps? If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too. I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
  - setopt 13d ago
    > I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one. Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?
    - mikae1 12d ago
      > Are you saying that Silverblue-based distros are noticeably more stable than Fedora? TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time. Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing). It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.
      - setopt 12d ago
        Thanks for the input! > I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing). Two follow-up questions on this: - How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.) - Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.
        mikae1 12d ago
        > How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.) I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off. > Does Aurora sometimes reboot multiple times when doing updates? I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.
        jasomill 12d ago
        Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only). The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working. Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to. Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine). Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.
- nxobject 13d ago
  It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc. But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
  - setopt 12d ago
    "Conflict" is maybe a strong word? Homebrew installs stuff into its own directory tree so it should in theory not have issues coexisting with native packages.
  - jcastro 12d ago
    I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.
shevy-java 13d ago
I don't understand the distinction you use here. Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with? None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.
- F3nd0 13d ago
  > NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course) Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
  - salvesefu 13d ago
    for reference: https://docs.appimage.org/reference/appdir.html https://docs.appimage.org/reference/appdir.html
- mikae1 13d ago
  > I don't understand the distinction you use here. Distinction: https://news.ycombinator.com/item?id=49683258 https://news.ycombinator.com/item?id=49683258 I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed. An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
deleted 13d ago
[deleted]
LeBit 13d ago
On Linux I use mise to install CLI tools
c0_0p_ 12d ago
Same, for me it made it possible for me to work on Linux with teammates on Mac with very little messing around of the setup scripts.

Thank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.

by mikae1 13d ago

Thank you for Linux Homebrew! It works so damn well. For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.

curt15 13d ago

Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?

mikae1 13d ago
> Where do you draw the line between system packages and user facing apps? If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too. I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
- setopt 13d ago
  > I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one. Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?
  - mikae1 12d ago
    > Are you saying that Silverblue-based distros are noticeably more stable than Fedora? TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time. Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing). It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.
    - setopt 12d ago
      Thanks for the input! > I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing). Two follow-up questions on this: - How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.) - Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.
      - mikae1 12d ago
        > How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.) I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off. > Does Aurora sometimes reboot multiple times when doing updates? I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.
        jasomill 12d ago
        Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only). The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working. Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to. Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine). Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.
nxobject 13d ago
It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc. But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
- setopt 12d ago
  "Conflict" is maybe a strong word? Homebrew installs stuff into its own directory tree so it should in theory not have issues coexisting with native packages.
- jcastro 12d ago
  I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.

shevy-java 13d ago

I don't understand the distinction you use here. Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with? None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.

F3nd0 13d ago
> NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course) Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
- salvesefu 13d ago
  for reference: https://docs.appimage.org/reference/appdir.html https://docs.appimage.org/reference/appdir.html
mikae1 13d ago
> I don't understand the distinction you use here. Distinction: https://news.ycombinator.com/item?id=49683258 https://news.ycombinator.com/item?id=49683258 I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed. An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.

deleted 13d ago

[deleted]

LeBit 13d ago

On Linux I use mise to install CLI tools

c0_0p_ 12d ago

Same, for me it made it possible for me to work on Linux with teammates on Mac with very little messing around of the setup scripts.