38
submitted 5 months ago by GravitySpoiled@lemmy.ml to c/linux@lemmy.ml

What's up with homebrew that you'd have it installed by default on linux?

I don't understand the appeal of it, can someone help me?

top 13 comments
sorted by: hot top controversial new old
[-] poki@discuss.online 29 points 5 months ago* (last edited 5 months ago)

By default, Fedora Atomic envisions the following in regards to installing packages/software:

  • First, try the Flatpak.
  • If that doesn't work, use Toolbx(/Distrobox).
  • If all else fails, resort to rpm-ostree.

This works pretty fine, but isn't perfect:

  • Flatpak has become pretty good for software with a GUI. However, while it can do CLI, it's underutilized.
  • Toolbx/Distrobox has its merits, but not everyone enjoys consuming CLI through containers.
  • Besides the fact that installing all your CLI tools through rpm-ostree will negatively impact how fast you can update your system, it also requires you to (soft-)reboot before you can access the newly installed package (unless you enjoy living on the edge with --apply-live). This can be pretty cumbersome, especially if you're in flow.

Thus, the situation around CLI on Fedora Atomic became a sore to the eyes. Within the community, there were multiple attempts to tackle this problem:

  • Nix; For some time, this was the perfect solution. Unfortunately, in its current iteration, installing Nix on Fedora Atomic requires SELinux' enforcing mode to be turned off. As turning enforcing mode off is unacceptable for uBlue's maintainers, this was eventually dismissed.
  • Better tooling around Toolbx/Distrobox; There have been made some efforts in this regard, perhaps most notably Ptyxis. But, we're not there yet. Though, some are hopeful of what podmansh will bring to the table.
  • Homebrew; It behaves as any other package manager used for installing packages from the repository on any Linux distro out there. Except, in this case, it's exclusively utilized for CLI. Currently, it's simply the most straightforward in use. You just have to teach people to replace their apt/dnf/ pacman with flatpak (for GUI) and brew (for CLI). Furthermore, it comes with a big and healthy repository. Finally, it utilizes technologies related to the ones found on Fedora Atomic.
  • systemd-sysext; This has only very recently been added to systemd. I wouldn't be surprised if this will play a prominent role going forward. Though, I'm unsure if CLI will benefit most of it.
[-] mogoh@lemmy.ml 4 points 5 months ago

Very interesting. I wish flatpak would offer a better CLI experience. I don't want another package managing tool, but here we are.

[-] poki@discuss.online 5 points 5 months ago* (last edited 5 months ago)

Can't agree more.

I believe Flatpak initially couldn't and/or didn't want to do CLI. At some point, it offered some basic functionality; I first noticed it on Bottles. But, it's pretty dire if no variation of top can be found as a Flatpak.

I wouldn't be surprised if most people are simply unaware that Flatpak can even do CLI. This inevitably also negatively affects its CLI ecosystem.

[-] Bitrot@lemmy.sdf.org 7 points 5 months ago* (last edited 5 months ago)

The flatpak packaging tutorial has you build a cli app, so anyone building one is likely aware.

The real issue is invoking the commands. If you install a snap of top, you run top and it opens. If you installed a flatpak it wouldn’t be added to your PATH and even if you added the exports directory to your PATH you would need to remember to run org.gnu.top. Nobody wants to run some random flatpak run command all the time or create aliases for everything, so “flatpak isn’t for cli” becomes the mantra.

In an ideal world a flatpak could register the cli commands it wants to present to the user, and some alternatives system could manage which flatpak gets which command if there were collisions.

[-] theshatterstone54@feddit.uk 3 points 5 months ago

In an ideal world a flatpak could register the cli commands it wants to present to the user, and some alternatives system could manage which flatpak gets which command if there were collisions.

This has been my dream ever since I discovered Flatpak. I wish it becomes the case one day.

It's good that there has been partial progress in that direction. Let me give an example with the Floorp browser. I can do a flatpak install floorp and I can do a killall floorp and they will work. If we can somehow get a way of accessing flatpaks as if they're regular packages via the terminal (is it possible to build a program to do this and have it packaged as a flatpak?; Maybe a program that creates a oneliner script to act as an "alias" in a directory (within $HOME so it works on immutable systems) that gets added to $PATH), that would be amazing!

[-] filister@lemmy.world 1 points 5 months ago

Doesn't updating homebrew packages require a reboot?

[-] Pantherina@feddit.de 4 points 5 months ago
[-] j0rge@lemmy.ml 21 points 5 months ago* (last edited 5 months ago)

ublue co-maintainer here. I go over a bunch of the reasons here: https://www.ypsidanger.com/homebrew-is-great-on-linux/

Namely we needed a way to complement Flatpak and brew was a natural fit. It's an ecosystem reason not a technical one. It has everything we need and a good deal of Bluefin's target audience are already using it on mac. So for us it's an easier lift to just add homebrew and move on to larger problems.

Plus it's nice that they're working with the openssf to secure the supply chain pipeline, and it's nice that everything is in github where we can inspect it, use the same tooling we use for the OS, etc.

[-] warmaster@lemmy.world 7 points 5 months ago
[-] smileyhead@discuss.tchncs.de 7 points 5 months ago

UBlue developer likes and use Homebrew so he thinks it is essential tool so his distro preinstall it to be better and more "user friendly".

[-] Guenther_Amanita@slrpnk.net 6 points 5 months ago* (last edited 5 months ago)

I don't know the pros or cons of it vs Nix and others, but one pro is that it also runs on MacOS and other OSs. I've never used it, but it's nice that uBlue offers a simple installation ootb.
Many devs seem to use it regularly, and it isn't dead simple to set up from what I've heard. When uBlue offers an installation, then there is at least one person using it, otherwise it wouldn't exist :D

[-] vk6flab@lemmy.radio 5 points 5 months ago

It's a package management system in the same way that Flatpack, yum, apt-get, snap and dozens of others are.

If you use MacOS and Linux, it's not inconceivable that you might want to use the same package management system across both.

I've used it, didn't particularly warm to it and didn't install it on my most recent MacOS install after it shat all over itself on a previous installation.

I didn't know that it was available for Linux. Not tempted to try.

I'm a firm believer in apt-get and failing that, Docker with side journeys into podman.

[-] kenkenken@sh.itjust.works 2 points 5 months ago

They think it's nice way to install command-line tools. I think that only spoil the idea of immutable system as a desktop OS, where ideally everything could be reduced to a single installation method.

That's why I use the original Fedora Silverblue and have no interest in uBlue derivatives. Actually I want a more simplified base system and not more bloated one.

And yes, Flatpak is enough for everything (mind about Termux on Android).

this post was submitted on 18 Jun 2024
38 points (91.3% liked)

Linux

48376 readers
729 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS