Hacker News Reader

Comment by makeitdouble | Hacker News Reader

> Prior to Mac OS X, people would have been laughed out of the building for having a Mac, but now, with Mac OS X and the magic of open source, it was suddenly OK or even cool.

To push a bit further, a bunch of us switched to OSX not from windows but FreeBSD or linux. Hardware support for open source OSes was abysmal and getting commercial software to run on even linux was death by thousand cuts at best.

On the work side, anything "not windows" was also just not an option, and we'd code on windows and remote to unix servers as needed.

Introduction of Darwin really created a space where Unix could live in personal and corporate environments.

View on HN

> Introduction of Darwin really created a space where Unix could live in personal and corporate environments.

100% this. I am a huge Linux lover but also really appreciate having the option at work to use MacOS due to the Unix userspace it provides.

That being said, I would pretty much hate MacOS without the open source tooling (Nix, Homebrew, Yabai, SKHD, iTerm, etc.) I can bootstrap onto it.

I get an awful lot of mileage out of the XCode command line tools. Most of the things you need to emulate a CI pipeline locally are there, though the exceptions can occasionally be a bit of a problem.

What tools do you use/find essential that get installed with XCode's command line tools? My experience with XCode's command line tools is pretty much just installing them for Homebrew. I don't think I've taken time to actually dig into the installed tools -- so I'd love to hear what tools increase your mileage! :)

The insistence on having to install the xcode command line tools (hello "be at 99% installed for 10 hours" bug I have had over 5 different machines") is very annoyin. But I've found that brew has been a major mess as well.

Nothing like coming in on a Monday and having to debug 10 coworker's machines cuz suddenly python and postgres were silently upgraded (or some random shared lib was upgraded).

"Just use Docker" is also a PITA cuz of the abysmal file system performance stuff... I just want to run software! Or rather, I want my coworkers who might not be as well versed in system software to be able to have working systems.

All that being said, it's undeniable that I can daily drive Linux thanks to Mac stuff existing.

I've found that asdf has replaced a lot of my brew installs. It's great to be able to pin tool dependencies per project. I used, and liked, brew for a long time, but my tooling these days is almost entirely MacPorts, asdf-vm, and Docker + docker-compose (I'm also intrigued by podman).

xcode is enough to make nvm, asdf work. With only a very few exceptions I've found it to be enough to run javascript frontends, and backends of javascript, Ruby, Node...

I've been on Linux at work full time for about 7 years now. It was kinda janky for a while, but in the last couple years it feels as solid, nay, more solid, than my macbook. I did take the plunge with NixOS though, which is a quantum leap in reliability and stability.

It's still a massive pain in the ass. Their UI is inconsistent, their new arch breaks docker builds, and not enough is configurable. Brew even fails at usability, doesn't even put executables on the path for you.

It does except in cases where it might be dangerous to (e.g. `node@16` doesn't by default as that could conflict with plain unversioned `node`). You can generally `brew link` the package anyway if you need.

Or use Nix instead. I've been having a good time with Nix on macOS.

Yes, the trend for the last years hasn't been great.

With Apple's current market share, it sometimes feels like the unix core is more of an historical artifact, or one of the bullet point in commercial presentations. I don't see them put much efforts in pushing Darwin forward when they could use the same resources for Bridge OS or other parts they see as a differentiating factor.

On the bright side, Mac OX coming to enterprise settings also opened the door for linux laptops, and they became a truly viable alternative. Perhaps linux getting better representation and commercial foothold could help keep Darwin competitive and properly evolving, one could hope.

> their new arch breaks docker builds

I’ve seen this complaint quite a bit on HN, and I don’t really understand it. Apple helped Docker port over to arm64 on the Mac (which was one of the first pieces of software to use the new fancy hypervisor APIs), and it’s been working for over a year now. If your docker images can’t build on arm64, I don’t really understand how Apple or Docker can make that any easier. Most of the popular images have arm64 builds now, the only holdout I know of is MySQL due to Oracle being Oracle. If you’re building your own images, GitHub Actions and many other CI providers have had ARM64 agents for a long time (and you can build arm Docker images in QEMU super easy on GHA if you need hosted agents).

There’s not much of an excuse anymore, and since arm instances are cheaper on some public clouds, you should be making sure your stuff runs on arm64 now. Especially if it’s a typical Node/.NET/Java/Ruby/Python app, they’ve been arm native for years.

> you can build arm Docker images in QEMU super easy on GHA if you need hosted agents

Yeah, you nailed it: it's fairly trivial to create cross architecture images -- my preferred tool is Docker's buildx plugin[1].

I have an M1 Mac, Raspberry Pi 4 running 64 bit Ubuntu Server and multiple x86_64 bit machines. I try to exclusively use Docker images that are cross-architecture. When they are not cross-architecture I usually just build the project's Dockerfile using the Docker Buildx Github Action[2]. The majority of the time most projects' stock Dockerfile works on all architectures. The few times they don't work are usually when a Dockerfile grabs an x86_64 binary and downloads it. I feel like that is bad practice so I usually just write my own Dockerfile when I encounter that.

A recent image I did this with was Gitleaks[3] (link goes to my Github Action).

I will say I have found that while most projects usually compile well on all platforms, if I ever do run into issues it is usually on 32 bit ARM.

[1] https://docs.docker.com/buildx/working-with-buildx/

[2] https://github.com/docker/setup-buildx-action

[3] https://github.com/heywoodlh/actions/blob/master/.github/wor...

> the only holdout I know of is MySQL due to Oracle being Oracle.

I am (partially) responsible at the MySQL team for Docker images. I however don't use Mac myself. The only thing I am aware of is that for 8.0.28 we were a little late with ARM images due to technical issues, but that should be resolved.

But mind there are different sets of container images: `mysql` is maintained by Docker, Inc. where we only have limited influence and `mysql/mysql-server` which is maintained by us.

I see for instance

https://hub.docker.com/layers/mysql-server/mysql/mysql-serve...

Any specific issue with that? I'd then work with the involved teams to get it resolved. (Preferebly issues via bugs.mysql.com, but I'll check responses here as well)

I thought “mysql” was y’all. Sorry! I'll have to remember in the future to use "mysql/mysql-server". I just remember that GitHub issue for "mysql" being open forever.

You've certainly painted a sunny picture of arm adoption that I'm simply not seeing.

One of the advantages of docker is that you can have systems lock their versions. So our project using say, Neo4J, uses a particular version of it. Not necessarily one with an arm build. This creates predictable and repeatable builds.

So now either we upgrade dependencies out of our expected cycle, or we abandon macs as our development machines. A decent number of us wanted Linux anyway. This is a cost that Apple foisted on us.

> since arm instances are cheaper on some public clouds, you should be making sure your stuff runs on arm64 now.

Some instances might be cheaper, therefore we have to adopt it now? I think the cost/benefit analysis you're performing here is ignoring development costs. Are you a project manager of some kind?

> they’ve been arm native for years.

The native libraries and tools that make them worthwhile are not. Really it only takes a single component to ruin everything.

I’m not a PM, but I’ve been in the room during those conversations. Granted, I’ve never had to rely on a ton of native extensions (at least in a business context, personal stuff for sure).

It’s just like any other dependency. Sometimes you can afford to freeze on a single version until the end of the project, but most of the time projects I’ve been on will regularly upgrade the third party stuff we rely on if for no other reason than security, with things like arm64 support coming along for the ride. We usually prefer to be able to get help with our issues faster than our tickets getting closed with “fixed in new version update”, of course weighing that against breaking API changes or what have you.

Reply on news.ycombinator.com