Hacker News Reader

Comment by joelkesler | Hacker News Reader

Author here:

This script helps new developers at my workplace setup their MacBook laptops quick, letting them hit the ground running.

Before this script, it could take 2-5 days to install and configure everything, as much of the knowledge needed was either scattered in old docs or passed down verbally from a few senior devs.

With this script, new developers can be ready in under 30 min.

I have tried to make this script simple and useful. You will want to customize the installation and configuration to match the tools and services you use at your company.

Note: it has not been tested on M1 Macs yet. I am still waiting on my M1 and will update when I receive it

View on HN

2-5 days that’s nothing. I once billed a customer an entite months worth of hours because they had a super weird and complex development setup with scripts, proxies, vpn and all that good stuff. But when the AD groups are trash and no one knows what’s going on, well, that was fortunately for me their problem, which they were well aware of, and working hard to replace with a local k8s setup. And lets leave it at that.

You are depending on macOS python? It’s going away.

There’s no need to chmod your script, just invoke it with sh.

Also, MacPorts or other multi-version python tools are generally better than Homebrew for Python:

https://justinmayer.com/posts/homebrew-python-is-not-for-you...

Home-brew is possibly better for all other uses. Perhaps the Python dev recipes in home-brew need fixing.

The problematic behavior is from homebrew, not the recipes. And it's not new behavior: in my system years ago it yanked the readline major version that a bunch of terminal tools (psql, graphviz, ...) were using.

We all have different problems. This isn't one I've suffered. The link farm model is capable of maintaining parallel dependencies back to the home-brew version specific install path.

I tend to think somebody didn't do a .rb Formula which preserved this version dependency. It may be clumsy but it's fixable in brew as far as I understand it.

> You are depending on macOS python? It’s going away.

That it is. We still have a few projects running on legacy Google App Engine, and the teams working on those projects use the included Mac Python 2.

We are in the process of migrating everything to Go, so the python 2 dependency should be removed in the future.

Seems like Docker + Docker Compose or GitHub Codespaces would simplify things greatly in terms of developer tooling install and setup.

Has docker performance improved on MacOS recently?

From an M1 standpoint, the engine has been M1-native for a while - there's also a more recent update that makes the Docker Desktop UI/services M1-native.

Well the Engine maybe native, but how is it running the necessary x86_64 Linux VM under HyperKit?

I don't believe it does, stil get arm64 Docker images. However, there is an experimental mode with Docker Desktop that allows for multiple architecture builds using buildx[1] but I have not tried it.

[1] https://docs.docker.com/engine/reference/commandline/buildx/

That's no bueno. I had hoped Docker, with all their investment $$, would've figured out a way (even QEMU or AOT/JIT recompilation) to run multiple architectures and platforms (i.e., FreeBSD, Linux) by now.

I run development and testing Docker workloads on a 16” M1 Max just fine. Runs native Apple Silicon (arm64)

I'm more interested in comparative benchmarks. The last I heard MacOS (Intel) running docker was significantly slower than Linux and M1 was just as bad if not worse through Rosetta.

My experience in running the odd docker container on a Mac has been that it was painfully slow compared to any Linux machine.

That's one of the main arguments for using Docker: reproduceable environments. It also makes dumping tons of tools into a fresh laptop obsolete. Furthermore, having development and production environments at/near parity is important for troubleshooting.

Reply on news.ycombinator.com