Re:Installing Fonts Using Homebrew
by pxc on Saturday April 28, 2018 @05:22PM
(#16949473)
P A R T . . . T H R E E
Wow! This turned out really long. HN really wants me to split up these comments. Here is the very last of what I have to say in this reply (I promise!).
FULL APPS ARE ACTUALLY THE TRIVIAL PACKAGES, SOMEHOW
> I get what you're saying about source installs and so on, but these seem like more philosophical issues, since Homebrew just works and I install pretty much literally everything on my system through it, including full apps like Chrome, LibreOffice, etc.
On macOS, ‘full app’ installs are actually the easier part of what Homebrew offers. macOS applications are shipped with duplicates of all their shared libraries, so installing GUI applications doesn't require any kind of dependency management, unlike the source-based installations that Homebrew offers for command-line utilities and development libraries. This approach is the opposite of the traditional Linux package management approach. It's very convenient in some ways, and it can make installations more reliable for end-users in some cases. At the same time, bundling these dependencies can pose a security risk (since there's no central place to update insecure shared libraries), and causes applications to take up significantly more space.
Today, Linux distros are working on provide their own options options (such as Flatpak, Snappy, and AppImage) for application installation that provide many of the same virtues as the macOS ‘.app’ approach, along with better security/privacy/permissions control, and cross-distro compatibility. It will be interesting to see what balance of these tools Linux users end up using, but I think we'll be in a great position to have a base system built upon a robust, fine-grained, native package manager with good deduplication of shared resources and highly compatible app bundles à la macOS that we can use on top of and alongside that system.
I HAVE LITTLE TO SAY ABOUT YOUR SCRIPT BECAUSE IT SOUNDS PRETTY GOOD
> > I'd imagine, too, that the fact you had to write your own bootstrap script could be part of what the parent poster was getting at
> I'd have to do basically the same anyway. All the bootstrap script does is make sure Homebrew, git, and Python 3 are installed, checks out my repo, and then runs my setup program to set up everything.
Sounds like a pretty clean script. :-)
SOME NICE THINGS ABOUT HOMEBREW
Because most of the comparison I've made between Homebrew and various elements of the whole range of package management tools available as core system components in the world of free operating systems, I'd like to include some words about what Homebrew does exceptionally well. I've already mentioned one of Homebrew's strengths, which is the high rate of activity, frequent updates, and the wide and growing range of packages available. But that is not the only area in which Homebrew excels.
When it comes to user interfaces among package managers, `brew` is a decisive leader. The subcommand interface is a thing of beauty. The emoji in the output are a delightful touch. Homebrew's facilities for opening a package definition in an editor directly from a `brew` command are a killer feature, and so is the ability to specify a version (including HEAD from source control!) at install time, directly from the CLI, is a killer feature.
By integrating the Cask and Tap systems into the same command-line tool as everything else, `brew` is also one of the best tools in terms of user experience for managing repositories in simple use cases. Some of my favorite package managers from the Linux world are still catching up with these UX features.
NO TLDR FOR YOU
I can't really summarize what I wrote in a sentence or two, because it was mostly a bunch of examples. But here is the message:
I hope that Hombrew continues to grow and succeed. I also hope it is clear how Homebrew lacks many of the strengths of what are, to my mind, ‘traditional’ package managers.
————
Sorry it took me so long to finish this reply! It has been fun writing it, but I started it late at night and had to split it into two sessions with a couple of days. I have not read through all of it twice, so there may be some typos, inaccuracies, or things I've left out. Please reply with them instead of or inaddition to downvoting me. :-D
And for anyone who cares, I'm not really happy with the downvotes it seems that kbd here has received for their reply. Their account of their experience is perfectly believable and legitimate. I think there are some things they don't see about Linux distro package managers, so I've tried to share them here. But what they said is not wrong and hardly can be— it's an account of personal experience!
————
To kbd: Sorry if much of what I've gone over in this comment is redundant for you. I started out just writing a reply addressed more directly to you, but got caught up in a broader message that emerged from what I was saying. Please don't be offended if some of what I've written includes things you already know, or seems to wander off the topic you started us on.
Wow! This turned out really long. HN really wants me to split up these comments. Here is the very last of what I have to say in this reply (I promise!).
FULL APPS ARE ACTUALLY THE TRIVIAL PACKAGES, SOMEHOW
> I get what you're saying about source installs and so on, but these seem like more philosophical issues, since Homebrew just works and I install pretty much literally everything on my system through it, including full apps like Chrome, LibreOffice, etc.
On macOS, ‘full app’ installs are actually the easier part of what Homebrew offers. macOS applications are shipped with duplicates of all their shared libraries, so installing GUI applications doesn't require any kind of dependency management, unlike the source-based installations that Homebrew offers for command-line utilities and development libraries. This approach is the opposite of the traditional Linux package management approach. It's very convenient in some ways, and it can make installations more reliable for end-users in some cases. At the same time, bundling these dependencies can pose a security risk (since there's no central place to update insecure shared libraries), and causes applications to take up significantly more space.
Today, Linux distros are working on provide their own options options (such as Flatpak, Snappy, and AppImage) for application installation that provide many of the same virtues as the macOS ‘.app’ approach, along with better security/privacy/permissions control, and cross-distro compatibility. It will be interesting to see what balance of these tools Linux users end up using, but I think we'll be in a great position to have a base system built upon a robust, fine-grained, native package manager with good deduplication of shared resources and highly compatible app bundles à la macOS that we can use on top of and alongside that system.
I HAVE LITTLE TO SAY ABOUT YOUR SCRIPT BECAUSE IT SOUNDS PRETTY GOOD
> > I'd imagine, too, that the fact you had to write your own bootstrap script could be part of what the parent poster was getting at
> I'd have to do basically the same anyway. All the bootstrap script does is make sure Homebrew, git, and Python 3 are installed, checks out my repo, and then runs my setup program to set up everything.
Sounds like a pretty clean script. :-)
SOME NICE THINGS ABOUT HOMEBREW
Because most of the comparison I've made between Homebrew and various elements of the whole range of package management tools available as core system components in the world of free operating systems, I'd like to include some words about what Homebrew does exceptionally well. I've already mentioned one of Homebrew's strengths, which is the high rate of activity, frequent updates, and the wide and growing range of packages available. But that is not the only area in which Homebrew excels.
When it comes to user interfaces among package managers, `brew` is a decisive leader. The subcommand interface is a thing of beauty. The emoji in the output are a delightful touch. Homebrew's facilities for opening a package definition in an editor directly from a `brew` command are a killer feature, and so is the ability to specify a version (including HEAD from source control!) at install time, directly from the CLI, is a killer feature.
By integrating the Cask and Tap systems into the same command-line tool as everything else, `brew` is also one of the best tools in terms of user experience for managing repositories in simple use cases. Some of my favorite package managers from the Linux world are still catching up with these UX features.
NO TLDR FOR YOU
I can't really summarize what I wrote in a sentence or two, because it was mostly a bunch of examples. But here is the message:
I hope that Hombrew continues to grow and succeed. I also hope it is clear how Homebrew lacks many of the strengths of what are, to my mind, ‘traditional’ package managers.
————
Sorry it took me so long to finish this reply! It has been fun writing it, but I started it late at night and had to split it into two sessions with a couple of days. I have not read through all of it twice, so there may be some typos, inaccuracies, or things I've left out. Please reply with them instead of or inaddition to downvoting me. :-D
And for anyone who cares, I'm not really happy with the downvotes it seems that kbd here has received for their reply. Their account of their experience is perfectly believable and legitimate. I think there are some things they don't see about Linux distro package managers, so I've tried to share them here. But what they said is not wrong and hardly can be— it's an account of personal experience!
————
To kbd: Sorry if much of what I've gone over in this comment is redundant for you. I started out just writing a reply addressed more directly to you, but got caught up in a broader message that emerged from what I was saying. Please don't be offended if some of what I've written includes things you already know, or seems to wander off the topic you started us on.