5 ms·
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 usabilit
by smeagull 4y ago
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.
- striking 4y agoIt 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.
- makeitdouble 4y agoYes, 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.
- easton 4y ago> 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.
- heywoodlh 4y ago> 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/ https://docs.docker.com/buildx/working-with-buildx/ [2] https://github.com/docker/setup-buildx-action https://github.com/docker/setup-buildx-action [3] https://github.com/heywoodlh/actions/blob/master/.github/workflows/gitleaks-buildx.yml https://github.com/heywoodlh/actions/blob/master/.github/wor...
- johannes1234321 4y ago> 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-server/latest-aarch64/images/sha256-bcb56714933157b2bb203408b6b5e292559d8b8a42d4e3acb8514ae783225e13?context=explore 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)
- easton 4y agoI 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.