Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Dont' forget:

- Multi- and highres monitor support out of the box with proper scaling and readable fonts

- A package manager with up to date packages (granted there are Linuxbrew and things like Snap now for Linux.)

- Applications that have a consistent UI/UX and all use the same keyboard shortcuts

> All the customization doesn't offset the trouble that desktop Linux can bring.

It's nice you can customize almost everything on Linux, but most of the time I feel I must customize everything to get to a basic standard.



> A package manager with up to date packages (granted there are Linuxbrew and things like Snap now for Linux.)

On what planet is is homebrew better than Linux package managers? I agree with many of the other items in these lists, but this makes literally no sense to me. Homebrew is probably one of the worst things about doing dev on a mac.


Homebrew is more transparent and approachable, I can easily customize what is being installed, it's versioning, and control it's dependencies better than apt.

Apt, more often than not, acts as a gatekeeper for the latest version of whatever software packages I'm trying to install. I end up just having to adding various libraries and repos to my sources list to get the version I need, or go to an outside dependency manager like gvm, sdkman, etc which is basically homebrew anyway.

Homebrew is for devs that need to get shit done, apt is for computer scientists that love the tool more than solving problems with a tool. For the record, I'm on both linux and mac and there's plenty of upside and downside to both.


> Apt, more often than not, acts as a gatekeeper for the latest version

It's a distro policy issue, not a package manager issue. There are rolling distros using apt - for example https://wiki.debian.org/DebianUnstable which is updated every 6 hours.

The same way rpm is just a packaging format - you can have both the stable (fosilised) CentOS and the fresh Fedora / CentOS-Stream using it.


You're extrapolating from Debian's packaging concept to other distros, though your argument does not apply to most of the rolling distros out there.

On a rolling distro (e.g. using pacman, or say yast2 and others for sake of argument) you typically ship the header files included with the libraries, so that you don't need multiple versions of the same library installed. On Debian/Ubuntu, however, it will always end up with that mess of dozens of versions of the same library because all PPAs are somewhat outdated and used different versions of specific libraries once they were published.


That's the problem isn't it? Whichever problem you point at in Linux, the answer is invariably the same: "you're holding it wr^W^W^^W you're using the wrong distro, the wrong package manager, the wrong DE, the wrong version of any of those things".

And, invariably, for any problem the one true combination is different.


This case already started with discussion about brew. Brew is a choice you make if you don't like other distribution platforms on a Mac. But guess what - some people complain about brew not keeping software stable, but rather chasing new versions!

This is not a Linux issue - wherever you have different options and use cases you'll find different recommendations depending on what people are trying to achieve.


And that's why forks suck and everyone should use a spork. Having options that cater to different usecases is confusing. You don't really need to take big bites anyway.


- Hey, your fork is broken, and made out of plastic.

- You should use the oak box set of Forkuntu 12.4, no problems with forks there.

- Yes, but it lacks any spoons

- For spoons there's always Spoontoo.

- But... I want both spoons and forks...

- For that you can always tweak a few dozen unrelated work orders, menus and item descriptions in Sporkian. But that will only work witn Sporkian unstable, and needs a special tablecloth.

- Okay... What about knives?


Well, if you would report a bug for Office 2003, the maintainers at Microsoft would react the exact same way. That is if you persist on calling through the corporate structure until you actually are able to contact one.

Either that or well, they'll simply ignore the noise of a user that doesnt give a damn about updating anything - so the user would not receive any potential patch anyways.

If you decide on choosing a specific distro, you should know what you're choosing. If what you are complaining is too much choice, then maybe MSDOS 1.x is the best operating system for you?

The beauty of Linux is customization. If you don't agree with that, then stay on MacOS. No harm done.

But if what you're complaining about is that you lack the skills to understand and investigate - without having paid anyone anything - then honestly, I think you are an ungrateful user that nobody should help out because it's a waste of (everybody's) _free_ time.

Be nice and maintainers will be nice, too. Be cooperative and they'll be cooperative as well.


> If you decide on choosing a specific distro, you should know what you're choosing.

Indeed. And when that distro is MacOS suddenly HN is up in arms about how "not understanding why developers are chosing it".


> I can easily customize what is being installed, it's versioning, and control it's dependencies better than apt

In terms of customizability, is Homebrew any different from Apt? As far as I'm aware, Nix and Guix is the only system package manager that allows me to have full control over versioning and inter-package dependencies. Other package managers only let me install packages as provided by the packagers.


More accurate to say that apt is for the sysadmin, perhaps.


Homebrew's very up to date, without that cutting-edge quality risking system stability (since that's totally separate) and has an incredible number of supported packages, including tons of closed-source stuff, out of the box. No hunting down PPAs or obscure unofficial back-port packages or anything. The only Linux package managers I've seen even approach it (not match, but approach) are from bleeding-edge distros like Arch or Gentoo, but those come at a harsh stability cost since they also manage the rest of your system, including all the shared libs (ugh) and system-level packages (I gather that's the case on Arch, it sure was on Gentoo when I used it for many years, mostly because I loved Portage and OpenRC)


> Homebrew's very up to date, ... and has an incredible number of supported packages

Package stats from Repology seems to contradict this claim:

https://repology.org/repositories/graphs

It's not bad, but it's not the best either. Not even close.

> including tons of closed-source stuff

Homebrew doesn't ship any proprietary formulae at all. They have a clear policy against it:

> We don’t like binary formulae

> Our policy is that formulae in the core tap (homebrew/core) must be open-source with an Debian Free Software Guidelines license and either built from source or produce cross-platform binaries (e.g. Java, Mono). Binary-only formulae should go to homebrew/cask.

> Additionally, homebrew/core formulae must also not depend on casks or any other proprietary software.

> This includes automatic installation of casks at runtime.

https://github.com/Homebrew/brew/blob/master/docs/Acceptable...


> Homebrew doesn't ship any proprietary formulae at all. They have a clear policy against it:

And yet, I can install Sublime Text, Slack, and others through it out of the box. I just checked a couple more, Figma's there. Microsoft Office. Steam.

You used to have to run a one-liner to enable casks (just one, not one for every damn vendor like with apt) but not anymore.


Can't edit anymore, but just wanted to say: on review that post came off as snarkier than I intended it. I just mean that, whatever the policy on including closed-source in the primary Brew repo, casks are enabled by default and don't even require a different command or any set-up anymore. From a user's perspective they're 100% as available as other packages, as soon as you install homebrew. I think the only major difference is that they don't auto-update when you do a "brew upgrade"—you have to specify the cask package you want to upgrade. Which is a good policy since a lot of those programs have their own built-in updaters anyway.


Some of this is a matter of taste, clearly. I strongly prefer having my system packages being rock solid; I can always fetch updated software for the very few cases where I want that.

However, my aversion to homebrew goes beyond taste: my experience with homebrew is rife with breakages. To be fair we were trying to use it in a CI system, which will very quickly reveal a buggy system. By contrast, apt/dnf are rock solid when used in CI.

An actual example: we tried providing our own recipe to install a particular version of libicu. This triggered an upgrade of some dependency; that triggered an upgrade of libicu to a different version than 68. The command exited with a successful status. A real package manager would have detected the package conflict and reported it, giving you resolution options, or errored out in a non-interactive terminal.

Why were we trying to pin versions in the first place? You guessed it, package breakages.


Yeah, I don't manage dev dependencies for projects in home-brew, just software for which I am a mere user. I probably wouldn't use apt and friends for those, either—not directly on my workstation anyway, maybe in some pinned-OS-version VM—unless my workstation happened to be identical to my deploy target and was guaranteed to stay that way. For a macOS build for C or C++ or anything along those lines, I'd probably vendor dependencies.


Agree as a Mac user. I miss pacman from Arch. Now -that- is a nice package manager. It took the best (simple) parts from Gentoo and combined them with the better parts of apt/rpm/zypp etc.



I always found pacman a little weird to use, but I think that was more a function of its UI -- its commands and options just weren't easily memorable for me, and I had to look them up almost every time. Its actual functionality was great, though.


It isn't, but there's MacPorts, nixpkgs, pkgsrc, and ArchMac (although I kinda dropped the ball on the latter)


On the planet that runs arbitrary community maintained Ruby scripts to install packages, and the planet where doing brew update requires a full days work + max CPU usage.


> It's nice you can customize almost everything on Linux, but most of the time I feel I must customize everything to get to a basic standard.

The last time I had to customize everything was like 10 years ago, and now I just copy my $HOME from machine to machine when I get a new one and everything just works and looks like it did on my previous machine.


"- Multi- and highres monitor support out of the box with proper scaling and readable fonts"

Unless you want to use two TypeC->DP connected monitors using MST. For "reasons" ($$$), Apple arbitrarily decided to not support MST over TypeC connectors (thunder bolt good, TypeC bad!!). And since this is MacOS, its impossible to ever have that support unless it was blessed upon us by the overlords. I don't like being held hostage by a company, and Apple is great at setting their way or the highway (some may like that, but not I).

When I got my new job and they forced MacOS on me: Ok, now I need a usable home setup. Lets try to get this running without running to buy $4k in new monitors.. days searching and a few wasted purchases later, everything worked fine just to discover that Apple refuses TypeC MST for no specific reason. So by all means, you can keep it. I'll hold my nose because I like my company, but their choice to mandate this hardware was awful.


> Multi- and highres monitor support out of the box with proper scaling and readable fonts

What's funny, is this is the complete opposite experience that I had in every single way. Multi-monitors absolutely suck on macos unless you drop $1000 on mac monitors

Try running two external monitors with differing resolutions, in my experience, it will be stable about 1 time out of 20. The rest will have artifacting, refusal to recognize the monitor, or other weird behaviour.

Or try running a monitor that isn't at least 4k, the most recent macos removed text aliasing so text rendering on 1080/1440p monitors looks like something out of the 1980's.

Linux though? I've never once had an issue with external monitors using Ubuntu

Edit: Sitting here on my work mac, almost forgot about my favorite one! When running multiple monitor resolutions, mouse movement hitches and lags for seemingly no reason! Only a disconnect and reconnect of the external monitors fixes it!


Meanwhile I use both a 1080p display and a 1440p display (Both Dell displays) with zero issues on macOS Big Sur.

I get no odd behavior, both monitors are always detected nor do I see artifacting or anything other issue. There was some minor pink lines on the boot up screen that have since been fixed in the latest release. (M1 Mac mini)

I can't really say I noticed a difference personally since they removed text aliasing on 1440p or lower, however it's a single toggle to turn back on.

I get zero mouse lag with differing resolutions and I use both a Magic Mouse 2 and a Magic Touchpad 2.

anecdotes are always going to differ.


Might be a difference between the Intel and M1 macs


You can't even change the subpixel rendering to BGR on a Mac! The suggested solution is, literally, to flip your monitor upside down.


Mac OS removed supixel rendering AFAIK


> Multi- and highres monitor support out of the box with proper scaling and readable fonts

My M1 mini has all kinds of issues with 2 4k monitors attached. Sometimes waking up from sleep, the monitor plugged into TB scales to default setting (200%?) instead my config (125%). And don't get me started on Ultra Wide support.


I’ve got a 49 inch ultra wide connected to my MacBook Pro using a Belkin Thunderbolt dock… what about ultra wide support?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: