Ask HN: How are you dealing with the M1/ARM migration?

Give https://github.com/bogo/arm64-to-sim a try. Perhaps you'll be able to get the arm64-simulator slice for free.

I work on large-scale systems software, mostly high-performance database and analytics products. Docker's sole function in that kind of environment is easy replication of dev and functional test environments. No one deploys this type of software in Docker or similar due to the performance implications. Docker was a convenience, it wasn't providing anything critical. I replaced it with a small set of shell scripts and similar.

For this type of development, the number of external dependencies you have is very small. Aside from the compiler, build system, and testing, the number of third-party libraries linked into a release can usually be counted on one hand. Again, for good reason.

Basically, I am doing what I did before Docker, writing a small set of scripts that can perfectly reproduce the environment where I need it. This is made much easier because modern build systems have good dependency management built-in so writing those scripts is a lot less involved.

At the time I was on macOS, I ended up using iTerm2, but I didn't feel great about it. I understand that iTerm2 has a wealth of features, including some that are virtually unique. But I wasn't happy with iTerm2. Annoyances I can remember at the moment are:

  - it was shocking to me that getting decent performance with tmux required installing an unstable build and enabling GPU acceleration (something I never had to resort to before)
  - I had a skeptical view toward many of iTerm's unique features because
    + the whole scandal with iTerm2 leaking private data via DNS had just happened (see: https://www.bleepingcomputer.com/news/security/iterm2-leaks-everything-you-hover-in-your-terminal-via-dns-requests/ , https://gitlab.com/gnachman/iterm2/-/wikis/dnslookupissue )
    + the tmux ‘integrations’ didn't work with my tmux setup, because they require iTerm2 to launch tmux and at the time I already used a different system for managing local tmux sessions ( https://github.com/sagebind/tmux-zen ) that I liked
    + when I temporarily changed things to let iTerm2 launch tmux, I found that it broke/ignored my keybinds, which is apparently intentional -- https://gitlab.com/gnachman/iterm2/-/issues/3997
    + shell integrations always seemed almost like a layering violation to me, but also just plain didn't (and don't: https://iterm2.com/documentation-shell-integration.html ) work with normal tmux or screen sessions anyway
  - iTerm2 displayed vertical spacing with the bar characters used for drawing vertical lines in tmux incorrectly unless I went out of my way to use a special font (Hack), something I had never encountered before
  - swapping the Option and Command keys inside of iTerm2 was required for getting in-terminal Emacs keybindings to work right, but it swaps them *globally*, so that if you use either modifier in your ‘Hotkey Window’ configuration, you have to use a different key to dismiss the window than you use to summon it
    + I had to supplement my iTerm2 config with a Hammerspoon config to essentially bind summoning it and dismissing it to two different key chords, which worked but broke the animations the app features for ‘Hotkey Window’ because I was summoning it via iTerm2 but dismissing it via Hammerspoon
  - I had to modify some keycode configuration stuff to get it to act more xterm-like to get some in-terminal apps to interpret the right keybinds, and it was a more annoying, fiddly process than on terminal emulators I'm used to, which provide comprehensive profiles you can just swap between for that
  - iTerm2's configuration windows feel really disorganized, cluttered, and just messy to me compared to Konsole's
  - I didn't need some of iTerm2's special features, because I already had them implemented in my tmux config, like regex search for find-on-page and copy mode, so I didn't really have a chance to be impressed by them
  - some of iTerm2's special features, like displaying images, were then implemented only in a non-standard way, which meant I couldn't count on them on other platforms (nowadays iTerm2 and Kitty share their special image protocol, I think, plus iTerm2 supports Sixel graphics, which is really cool) and didn't really want to use things that relied on them

I feel bad about posting much negativity about iTerm2 when it is clearly such a lovingly maintained, ambitious project that serves many people well. And I understand that for people with different expectations or who don't care to have a portable, cross-platform command line environment, letting iTerm2 ‘take over’ for tools like tmux and push them to the background is an amazing feature. I also get that iTerm2 is very creative and clever about getting crufty old protocols to do things they were never originally intended to do, and that the results can be really nice sometimes.

The landscape of cross-platform terminal emulators has also changed a bit in just the past few years, because some nice terminal emulators have matured substantially.

But as someone who, a few years ago, came to macOS with a fluent, agreeable, largely terminal emulator-agnostic workflow already and just wanted ‘a fullscreen dropdown terminal that won't lag out if I have a a few noisy commands running in a tmux window’, iTerm2 was simultaneously overkill and underwhelming. On Linux, the dropdown terminals baked on the defaults of the big two DEs, Guake and Yakuake, both work just fine, as do several others that I've tried.

PS: Back then I only cared about programming ligatures in GUI Emacs, which was fine, but nowadays Konsole does have ligature support. And Wezterm is another cross-platform terminal emulator with ligature support and reasonable performance. :)

PPS: I do see an iTerm2 feature every now and then that I find myself envying until other terminal emulators I like catch up, and I'm happy to admit that the iTerm2 maintainer seems to pick up the new terminal hotness at an impressive pace. Lately it's OSC52 escapes for remote terminal Vim and Emacs sessions :)

Can you describe in a bit more details on this case? I'm trying to understand for myself, would it hit any problem for our dev team anytime soon - so far I've heard no complains/requests from them about Apple Silicon - should we get prepared for that or it's very specific case?

In nutshell I don't see how having Apple Silicon locally makes the problem - if your non local env (dev, prod, stage) is running on x86 Linux or even arm Linux, shouldn't be any issue to build for that architectures on your build farms anyway.

I may be missing some important part here.