>apt-get was a revolution when it was released in 1998 and it is still the best way to manage software today. brew is a mediocre replacement.
While apt still isn't the best package manager (my heart belongs to pacman, no matter what the haters say), I completely agree that brew is a failed imitation. I wanted to use MacOS for the longest time, because I've been told that it's a real "Unix system". Brew has distilled my fears into a sobering reality. The "advantages" MacOS offers really comes down to eye-candy or slightly more consistent shortcut mapping, but none of this really matters to me when I can't use the software I want, and the OS is always second-guessing my authority. Maybe I've been spoiled by Linux, but I don't understand the hype. Not even on my M1 Macbook Air.
People state consistent shortcut mapping is an advantage of using Mac but after 2 years of being required to use a Macbook Pro I'm not really sure about that - often they are more complicated IMO. I still miss built in Linux and Windows key mappings. For example Windows + Left to move the window on the left side of screen for side by side apps on the same screen. Great for remote demo's and coding sessions. Ctrl + Shift + F4 to take a screen shot vs Linux PrtSc feels backwards at least to me. On the mouse pointer side with scroll direction most people I know also get a plugin to swap the scroll direction when they use their mouse and switch back to track pad. Another example - on VS Code very often the key bindings don't work on my Mac whereas on my Linux machine they work every time. My point is while I'm probably don't know all the tricks to learn since its not my platform of choice YMMV.
I think the impression of "better key bindings" comes down to familiarity more than anything. Getting used to something else seems uncertain (it may never be as good despite learning investment) when you know on the other platform you can just "get things done fast".
On a mac I can't live without "Magnet" [1]. It lets you do organize your windows in half/thirds of screens with simple keystrokes. That should be part of the OS.
I use Rectangle [0] for the same purpose, it has a few more bells and whistles and is open source. It does have a bit of a debounce problem on multiple screens though (one tap might move the window two positions).
Will try it out. Having said that it is on my Linux machine "for free". I'm not even quite sure if I'm allowed to use these paid apps on the Macbook Pro I've been given.
For Linux users on Gnome looking for similar functionality, I use the gTile extension to accomplish this. When I first got my ultrawide display on macOS, Divvy was critical to be able to do this. gTile was a similar enough replacement to get me my workflow back.
It's not even a software development exclusive problem. You might create a product, sell it on Amazon and then notice Amazon sell its own AmazonBasics version of it after a while.
I used a macbook for 2 years and the key binding is definitely less consistent than windows or linux. If nothing something as important as word navigation and word selection (ctrl+arrows and ctrl+shift+ arrows on linux and windows), is located in different modifiers (can't remember which), something along the lines of: move with command+arrow and select with option+shift+arrows.
Drives me crazy every time, given that command + backspace deletes a word (and command +del deletes a word in the other direction).
But of course on a Win/Linux system you rarely need to use three fingers at once. On mac this is all too common for even the basic tasks you state.
Shift + End: Select to the end of the line
Home + End: Select to the beginning of the line
Home or End: Move to beginning or end of line respectively.
What's worse is when I plug in a keyboard with Home and End buttons on a recent Macbook Pro they still don't work. Do I need another plugin for that? Even if I do personally I don't find the Mac keyboard shortcuts better than Linux/Windows. Tbh after using Mac for 2 years running now every day at work I still don't quite get how people find it easier - I still wish personally for a Linux or even Windows machine to speed up my productivity.
And that's because people prefer what they are familiar with them - the mental leap to jump to another way of working for most people isn't pleasant and isn't really worth the investment. Mac still feels like a "second language" to me just as Linux must feel to mac users - I'm always translating it back to "how do I do this Linux/Windows thing" in Mac. In the end Linux, Windows, and Mac are perfectly capable OS'es and the differences is marginal between them which makes switching difficult. But I do prefer my Linux machine these days - more just comes out of the box.
> If nothing something as important as word navigation and word selection (ctrl+arrows and ctrl+shift+ arrows on linux and windows), is located in different modifiers (can't remember which), something along the lines of: move with command+arrow and select with option+shift+arrows.
I think you’re misremembering here, I don’t think there are any macOS keyboard shortcuts that work like this. It’s always shift plus the original keyboard shortcut to select.
It could be! There is one that's hostile, but I can't remember which. I know for sure because my colleague switched back to a Mac and it's complaining about it
I was honestly hyped when i got a MBP beast as developer machine after so many years of hearing mac is basically a luxury unix.
I was and still am heavily dissappointed. This was ~2018 it looked exactly as boring as imagined, a desktop as intiuitive as windows 7s. The terminal felt at best strange, many settings and confirmation dialogs are simply not available via terminal, only hidden somewhere in their UIs. The hardware run hot every day, always and you could not use an external screen without waste cycling your battery to death. Honestly not impressed.
Both mac and windows are like stuck in time compared to modern desktop approaches like gnome shell or recent kdes. If you are a shell guy to some degree no other os will justice
Yea, I think I've been through a similar thought process. Apple hardware is second to none and their machines do look awfully pretty. Macs have become the default engineering laptop in all the start ups I've been at in the past ~10 years but I never got to the point where I was really comfortable. I have grown to really love wsl 2 on windows in the past year that I've used it. To me it seems really elegant and has been a dream to work on. Most assume it's just a vm running on windows, but the integration it has between Linux and windows make it extremely powerful (eg from your Linux shell you can run windows executables, so you can do stuff like run powershell to write text to your windows clipboard or run 'code .' to open the windows vs code gui on your current working directory in wsl). I'm not sure if it would be best for everyone, but as an SRE it's great to have my Linux container have the same operating system my company uses in production so that I don't need to figure out how to do stuff on two different operating systems and I am just a lot more comfortable on centos.
There is one single feature of homebrew that regularly bites my coworkers. You can refer to software by name@version ("brew install postgresql@11" or "brew install postgresql@12") and there is no confusion about what you are installing; or you can refer to software by name only ("brew install postgresql") and the version number is calculated to be "most recently released." (v13 at the time this was written.)
Hypothetically I have two machines that I want to build out and give to developers. One machine arrives on Monday. My script runs "brew install postgresql" (no version), because of when I ran that script postgresql@10 gets installed. Tests pass, I hand that machine off to a new developer. The second machine arrives on Wednesday. I run the same script, but because v11 of postgres was added to homebrew on Tuesday, the second machine receives postgresql@11 even though the first machine received @10. Same script, two days apart, different major version of postgresql.
Yes, I can write my scripts carefully to avoid this. But consider this scenario: a new developer encounters a problem, tries to solve it themselves, finds a seemingly helpful blog, and ends up with postgresql@13 and node@15 when everyone else in their team is using postgresql@11 and node@12. Now tests are failing, but only for this one developer and only locally...
Doesn’t apt (for instance) work the same way? Or docker images without a tag? I’d you don’t specify a version in each case then you get the latest available. I’d you want a specific version pinned then you should specify it. I think I don’t see your point, works as intended. If you enforced mandatory version specification every time, you’d have to know exactly which version is which package for anything you install: apt install Firefox > nope won’t work, instead you have to know what is today’s latest Firefox version (changes every couple of days/weeks)
It's not really how apt works but rather how Debian works: you use apt with a specific release repository of Debian (stretch, buster or whatever ISO you installed).
Debian is really strict about its releases and won't push a breaking change in a specific version of the OS.
For instance, `apt install htop` will only ever install the 2.X version of htop in Buster. Including security patches and all, but you won't get a 3.0.0 version without going sideways and add a specific repository for that. Debian will ship with htop version 3 in the next release, but you'll have to upgrade the entire distro for that.
Brew is different in that it allows anybody to merge a new breaking version of the software you use, so `brew install htop` on Monday could give you the 2.x version, and on Tuesday will install the 3.0.0 version.
You could maybe compare it to the rolling releases of Arch. But Arch has a better way of handling it than Brew: they test, they prepare, they communicate for bug changes..
Brew would benefit from segmenting their offering, but you'd lose the bleeding-edginess of it. Really, if you want reproducible packaging on Mac, I'd use nix or docker. If you want convenience and edge, use brew and deal with it.
> For instance, `apt install htop` will only ever install the 2.X version of htop in Buster. Including security patches and all, but you won't get a 3.0.0 version without going sideways and add a specific repository for that. Debian will ship with htop version 3 in the next release, but you'll have to upgrade the entire distro for that.
Debian has an official backports repository if you want that behavior. It just gives you the freedom to choose.
On most debian-based distros, most packages aren't upgraded to a new major version in the repos for a particular version of the OS. If a new version of postgres is released, it won't be added to the apt repos for the current stable debian, ubuntu, etc. distributions. Instead it will be included in the repo for the next major release of the distro.
There are exceptions to that, for example browsers like Firefox and Chromium, but upgrading the major version of Firefox is much less risky than upgrading the major version of postgresql.
Rolling release distros like Debian Sid (and archlinux, though that doesn't use apt) don't work this way, which is why rolling release distros have a reputation for being less stable.
That’s really interesting, does anyone have a book or blog post taking about this versioning and releasing strategy?
I feel like as a new dev there’s so much in engineering I could learn from that’s already been solved and re-solved again and again or at least addressed by existing distribution systems.
However the reading materials to learn about some of this stuff seems far and few or very niche, sitting on some cached blog post from the 90s..
apt generally doesn't switch you to a new incompatible version of a package unless you upgrade your whole install. Browsers are not libraries and have special status due to their importance and having security and feature updates not separated.
If the solution to homebrews handling of major versions is to not use homebrew, I think it indicates there are issues.
I think it should work like almost Linux distros where the major version is fixed for a release lifecycle, and any other installations require modification. So say brew install postgresql should always install 12, and if you want something else you have to add the version modifier.
This is a side point but the docker suggestion is far cleaner if you work on multiple apps as you can easily configure and run multiple versions with Dockerfiles and compose files to be exactly right for each app, with only the plugins the specific app needs, data stored in a custom location for each app, and the ability to turn off postgres for an app. System postgres installs and upgrades are a needles pain for development.
But I agree that's nothing to do with brew conversation.
Not just different apps but having multiple working environments for the same app - very useful when you wreck the db on a feature branch and need to jump to another to fix a bug etc.
We do this where I work and while it’s great that it solves this problem, but Docker on macOS leaves much to be desired. The situation with filesystem performance is abysmal, and if you’re unlucky, CPU usage can go through the roof even when running a few lightweight containers.
That is my preferred solution and I think it works great. I have persuaded a couple of coworkers to switch, but only a couple so far.
Containerized Postgres is a real win, but running OpenLDAP (+ custom schema) as a containerized application has measurably improved my quality of life. Kudos and great gratitude to the people behind
https://github.com/osixia/docker-openldap
I think you could also utilize 'Brewfile' with pinned versions, where needed, and the latest available for the rest. I manage my environment this way when migrating from one work laptop to another. Works fine so far.
Alternatively, you can create your own 'tap' to gain more control over some packages.
For databases, I'd stick to running them as containers, too.
Homebrew is not ideal, of course, but there are ways to achieve desired goals until we have something better.
It's actually worse than you think since the @version notation needs to be explicitly marked by the maintainer of the package.
If they don't do this then there is no easy way to install an older version of a package, you will have to get the old .rb file from the brew git history and execute it yourself.
Apt sidesteps this problem because Debian-based releases are not rolling releases. Unless you install a custom PPA, if you are running Ubuntu 18.04 and you "apt-get install postgres" you will always get version 10.x. The major version number will not get bumped for Ubuntu 18.04.
If want to use a version of postgres other than 10.x, you can either use a different version of Ubuntu or install a custom PPA.
Apt's target audience is systems administrators. Homebrew's target audience is independent developers who might need to have four different versions of Postgresql installed simultaneously on their laptop, because they maintain Rails/Django/Node apps for four different clients who are each unwilling to upgrade for whatever reason.
IMO homebrew is "messy" because it is trying to solve a harder problem. If there is such a thing as an average enterprise software developer, I would argue that homebrew is trying to solve problems that the enterprise developer does not have.
For example Ubuntu X.Y LTS always use a pinner version of Apache 2.xxx and it will remain that version throughout that LTS release, such as 18.04. what they do for you is apply security patches and bump Apache 2.xxx.Y where Y is the security release applied patch. Apache stays at 2.xxx for the duration of that LTS and is considered the Stable version. Want something newer like Apache 3.x install from a PPA or an all-in-one bundled Snap package...
Except dpgk/apt is pretty good about keeping track of what libraries are being used. I've had homebrew upgrade readline to the next major version, uninstalling the version that all my other utilities were linked against. Admittedly, this was years ago and I don't know if that still happens; the experienced has soured me on homebrew and I actively avoid having to run the brew command and risking the same again.
I found it much worse that installing anything STILL by defaults upgrades literally everything. You have to actually set an ENV variable to stop this behaviour. My stuff constantly broke because I'd forget about this and install something else and a couple days later I'd go "what happened??"
It was doing this until recently when I set the env variable. It updates itself every time and then updates everything else too. Maybe I did something wrong to trigger this behaviour but it was definitely updating the packages
I've seen the exact same behavior. I didn't realize it was behind an environment variable. I passed a package to the command and for the next week I was dealing with issues from everything being upgraded.
Per gp, I haven't used Pacman in a long time, but when Arch was really popular I'd have a virtual machine, ignore it for a few months, then updates usually failed or rendered the machine inoperable.
The Arch wiki was so good that it inevitably included the exact problem and resolution already, but since I didn't have any important running systems I also might as well have reinstalled the whole thing. In which case I'd run into installation problems that were also perfectly covered in the Arch wiki.
Nowadays you can install Arch to a zfs or btrfs subvolume and have snapshots before every update, so a failed update requires you to just reboot to the previous snapshot and do a rollback.
I have never seen this personally, because the first thing to do if you haven't upgraded Arch in a long time is check archlinux.org where they list right in the front page any breaking update, which are quite rare and they provide the exact steps to proceed.
Or just install informant from AUR, to force you to read the Archlinux package news before proceeding with any pacman operation.
I had packages installed by brew that used readline 7. This went on fine for a while. At some point, brew installed something (at my direction) and moved to readline 8. Unbeknownst to me, readline 7 disappeared from my system! Tada, a pile of tools require reinstallation. Oh, and I didn't notice until weeks later when psql stopped working.
I find Docker to replace the parts that suck about using brew. E.g. I would never install something like Postgres using brew again. Small command line tools sure, but anything with complex dependencies and where you might need multiple versions it’s just better to use containers.
- updating the package index on each operation. I just want to install stuff, dammit. I don't need you to run git pull to update the gazillion package definitions
- `brew update` and `brew upgrade` dichotomy. 99.9999999999% of the time I need to update/upgrade a package, not brew. If I ever needed to upgrade brew, I could run `brew update --brew` or something
Very concise way to put it. I feel the same way. With FOSS I feel that I'm fighting with the software, and with proprietary stuff I feel like I'm fighting against the software.
Macports is a system that installs in the /opt root folder to run along side your native applications without overwriting them, but it compiles each application as you install. Installations can be very slow. It seems like it was adopted from FreeBSD's ports system.
Fink is more apt like but I haven't used it in years. All the packages are precompiled and the installations are much faster, but it seems out of date.
For both packing systems all the code and installation packages are managed by volunteers so quality varies across packages.
> Is MacPorts Universal?
MacPorts works on Apple Silicon as well as Intel- and PowerPC-based Macs, but, by default, the ports you install will be compiled only for the architecture you're currently running on. This means that if you migrate from, say, a PowerPC Mac to an Intel one and use Migration Assistant to copy your data to the new machine, you should reinstall all your ports on the new machine to rebuild them for Intel.
What they mean is that the downloaded binary will have been compiled for only the architecture you're running on. Take a look at all the binaries on http://packages.macports.org. MacPorts downloads from here.
If MacPorts is compiling from source, you're either using a non-default varient, on a very old version of OS X (MacPorts supports Tiger, but doesn't build binaries), or have some other unusual configuration option set.
That can't be true. For any mildly complex application I install it asks for "xcode-select --install". I'm using an intel Mac on 10.14.6, so it is pretty standard. I just reinstalled the software under a year ago and redownloaded macports from the website and installed it. It seems to require a local compiler to be installed for most applications, such as gcc or llvm. For instance, why wouldn't installing ffmpeg just download the ffmpeg binary instead of the all the compiler dependencies?
Oh, that may be because ffmpeg uses libraries with incompatible licenses. I should have mentioned, ports with nonredistributable binaries are also built from source, and MacPorts tends to interpret licenses conservatively.
Does the list change if you specify the +gpl2 varient?
I'm just doing the "standard install". Macports does source code for standard installs. End of discussion.
Heavenly Lord, he just keeps coming back with more rules lawyering. The macport for git goes through patching, configuring, building routine that is common in source code installs. Give me peace of mind, strength, and patience in dealing with internet trolls.
I am sorry, but you are wrong. MacPorts will not go through configure/build/install for all ports, only those for which no binary archive can be made available. As others have already explained, this happens when license restrictions do not allow redistribution of a binary.
With your example of ffmpeg, you can check yourself that ffmpeg-4.3.2_0+gpl2.darwin_18.x86_64.tbz2 exists as a binary archive and will be used on a standard install on macOS 10.14. MacPorts will definitely not build ffmpeg from source by default.
I recommend you test again with something simpler than ffmpeg, for example bzip2 or less.
Yeah, I’m a maintainer, MacPorts will download a binary if it can. ffmpeg is a weird case thanks to the non-free variants, but even it has some binary installs.
Also, for instance, OpenJDK is a port that is offered and we do not compile that in any way on any system because that way lies madness.
The other reason that macports will build from source is when there isn’t a binary like early on in Big Sur.
...no, it does that when the standard install would not be possible to legally redistribute. :) It's true that MacPorts generally prioritizes providing more features (in ffmpeg's case, access to more encoders and decoders) over providing a prebuilt binary.
I suggested the +gpl2 varient because I noticed it was present for all the ffmpeg binaries on MacPorts's build server. This is probably why. http://packages.macports.org/ffmpeg/
Now, if adding +gpl2 still causes MacPorts to pull in cmake, that's interesting, and I would like to bring that up on MacPorts's mailing list in case there's a bug. But I suspect adding +gpl2 will make it go away.
> because I've been told that it's a real "Unix system".
OSX certainly isn't a "real Unix system".
OSX a huge hodgepodge of proprietary crap with a Unix component buried somewhere in the middle of the dung heap to get FOSS proponent to believe that Apple believes in openness.
They were even certified as of 10.5 as a true-to-god Unix system. They have been more unixy than Linux for a while!
Unix, until Linux had made a breakthrough, was a proprietary system. The AT&T Unix, Xenix, AIX, SunOS, you name them. Openness of the source is not a defining characteristic.
Used to use MacPorts for many, many years. But grew tired of it breaking important packages or just failing to update when doing macOS major version updates.
Also, MacPorts can many times just fail to install a package or fail to update a series of dependencies. Good luck then getting your operation important packages running ..
Anyway, switched to Brew completely a while ago when updating to Big Sur, so have no idea if Brew will also do the same thing over time, but at least their system seems more simple, which might result in less breakage.
I've given it a whirl, and while it's better than Brew, that's not a high bar to pass. Macports suffers from the same lack of software and strange idiosyncrasies that crop up in Brew, and it really doesn't justify it's place in my workflow.
I switched to all Linux in my house a few years ago, it is a simpler and better existence overall. My kids laptops are mint, my wife is the only holdout on Mac. Mac is not bad, but for me it doesn’t have a lot of advantages and has a lot of obvious disadvantages.
> Maybe I've been spoiled by Linux, but I don't understand the hype.
This type of sentiment is usually a sign. If you've been spoiled by something, that's because it's better. I had the same feeling trying to go back to windows, "Man, why am I always fighting damaging updates", "Why can't I change this very simple setting", "Where is the documentation for this file".
The answer usually comes down to "because one thing is really good (not perfect), and the other thing is shitty (but tries to look perfect)."
I adopt a different attitude. If you have been spoiled by something, doesn't mean it's better, just that you are set in your ways. Which might be good, but sometimes it's better to broaden your horizon.
I liked macOS, I had used Linux full time for 15 years, spoiled by it if you will, then I tried to set up a WSL environment just for me and let me tell you: you guys can keep your Macs and half arsed Linux distros, Windows these days is truly underrated. Being able to game, have a better Linux and Docker experience than macOS, and not stuck in the 90s like Linux actually feels great.
Because the reality is that all software is actually crap. If you think one is better than another, you need to look harder.
Can you explain briefly what the issues are around brew? I've been a Mac user for the past decade and I still remember the days of macports, so brew still feels like magic to me.
Agree about brew and highly recommend nix in its place. Failed updates can’t take down your system (it’s literally impossible, as changes are made atomically), different packages maintain separate versions of their dependencies so there’s no dependency hell, and it’s very speedy. Only downside is it’s not as Mac centric as brew, so AFAIK casks are a no go.
For me, the ease of use of PKGBUILD files makes it easier to interface external or modifird software with the system (this has led to success of the AUR).
Apt itself is great, but the PPA repos that make every dist upgrade more complex is kind of not nice. With pacman you have AUR and very simple package scripts, that lets you easily add whatever to your system that's not included in the distribution.
There is "checkinstall" that creates an apt package by watching changes during a "make install" step. So you can install many programs that don't provide .deb packages or only provide source code that way.
Imo, both are kind of sucky. (Just install a gnome group on each, then remove it and install plasma and see how many non-used service whatever continues to be installed). Nix is the correct solution to the dependency hell problem.
While apt still isn't the best package manager (my heart belongs to pacman, no matter what the haters say), I completely agree that brew is a failed imitation. I wanted to use MacOS for the longest time, because I've been told that it's a real "Unix system". Brew has distilled my fears into a sobering reality. The "advantages" MacOS offers really comes down to eye-candy or slightly more consistent shortcut mapping, but none of this really matters to me when I can't use the software I want, and the OS is always second-guessing my authority. Maybe I've been spoiled by Linux, but I don't understand the hype. Not even on my M1 Macbook Air.