> The biggest thing that doesn't run properly on here is Emacs. I am able to get a version of it via Rosetta, however there are weird hangs that will randomly eat up all my input while I am in flow. This is undesirable to say the least.
This sounds a lot like the kind of stutter Dolphin's dynamic recompiler used to suffer when it first discovered a new shader.
IIRC, for faster boot times, Emacs binaries burn in some kind of low-level memory-image that gets dumped into an mmap region and then "revivified." I wonder if that's what Rosetta is choking on.
If so, I wonder whether, until an actual AArch64 build is available, it'd be possible to work around this problem by just rebuilding Emacs (for x86!) without that optimization enabled.
Thank you! I was so confused because I didn't remember the name, and there was no documentation about it I could find without the name (probably because it's out-of-date info now.)
I'm successfully running Emacs natively on M1 using the Yamamoto fork. It just needs to be installed via the formula on Homebrew currently rather than the cask.
Haven't run any benchmarks yet, but general usage is snappier and startup time is around twice as fast as a gccemacs build running on a 2020 Intel MBA.
Seconded. I use both on a regular basis - a Mac laptop for work since I have to interact with the MS Office ecosystem there, and a Linux desktop/workstation for gaming and personal projects.
Between the two, I prefer the Linux machine on pretty much every axis. MacOS feels far too tied to the GUI-oriented way of doing things; it's often difficult or impossible to automate tasks/routines, and troubleshooting when things go wrong is painful.
I haven't found much I couldn't script using built in automation [1] or if it's lower level one of the LUA based scripting tools like hammerspoon [2]. Mac automation is really robust. Even just the default provided tools like Automator or scripting GUI tasks via Javascript/Applescript can accomplish a lot.
Using a tool like Alfred [3] and having "workflows" attached to hotkeys for automated things works wonders. For example I have a "workflow" that lets me hit a hotkey on a playing video and it automatically creates a bookmark at that timestamp which is recorded to a SQLite DB. Any future times I open that video I get a list of bookmarks and the ability to jump to them. This script marks all the currently selected songs in iTunes as loved or the currently playing song as loved. [4]
I have a lot to complain about Mac/MacOS and the direction it's gone down recently, been using Mac since OSX came out, but automation isn't one of them. Out of curiosity what did you try to automate that you couldn't?
First off, I hadn't run into Hammerspoon before, so thanks for that - it looks like it might help with some things.
Most things I've tried and failed to do involve silent/background interaction with apps. For example, my company's VPN software doesn't handle sleep well at all, so I wanted to automatically disconnect before sleeping. I couldn't work out how to do it. The Mac Automation stuff (Automator and AppleScript) work if the app supports them, but my experience has been that support isn't necessarily reliable. Electron apps, at least, ignored my attempts last time I tried.
I figured out a way to do things using keyboard/mouse automation, but that fails in any context where I'm either actively doing something or where input isn't being accepted (e.g. when the lid is closed or when I'm actively editing code). On Linux I can at generally resort to Stupid X11 Hackery to make that kind of thing happen, though it sometimes needs WM integration if the app isn't cooperating.
I wanted to use a different ssh-agent on OSx which is a very simple "I want to set a global environment variable." That's literally impossible in OSX. So, I had to open a shell and every app that I wanted to use my ssh-agent had to be launched from that shell.
ah, nice! I haven't tried to figure this out since Yosemite was new and it looks like there's now instructions for how to do it. Thanks for this! If I ever have to go back to OSX, now I know!
In addition, there's AppleScript for automating UI apps, which is capable of calling bash scripts. The reverse of bash scripts calling AppleScripts is also possible. It's super powerful.
Very much in the same boat here. I have an M1 Macbook Pro provided by my employer, and I still find myself reaching for my Thinkpad 9/10 times. I don't think MacOS is bad, but it's not even in the same boat as Linux. Compared to the level of control you have on Linux, MacOS feels like a toy in comparison. A particularly fragile toy at that.
Genuinely curious — what are your specific gripes? I switched to Macs (many) years ago after being frustrated with Linux on the desktop. I’ve been quite happy over the years, but I also realize that I tend to spend most of my development time connected to a Linux VM or server.
- I work in multiple OSes simultaneously and MacOS makes this a huge pain as it has substantially different keyboard shortcuts compared to Windows/Linux. You can kinda change this in the System Preferences but it isn't perfect.
- Depending on your distro, installing and updating software on Linux can be much easier compared to MacOS.
- MacOS updates tend to break things
- Automating things on Linux is easy as I have the CLI. Automating things on Windows is kind-of easy as I have AutoHotkey. Automating things on MacOS is hard because there simply isn't a comparable all-in-one tool.
- Docker on MacOS is pain.
- Virtual machines on MacOS is pain.
- Advanced networking on MacOS is pain (when I need complicated VPN setups or just to connect all my VMs together).
I know many of my pain points don't apply to lots of people because my desktop setup is pretty complicated but my main pain point is still keyboard shortcuts. MacOS keyboard shortcuts are just completely different from any other OS and MacOS makes customizing them difficult without 3rd party tools.
I would understand how MacOS may be easier to use if you work with a lot of audio or just use it for web/office stuff though.
> it has substantially different keyboard shortcuts compared to Windows/Linux
Not just different, substantially better, in my opinion. The addition of the command key is a 2x+ increase in modifier-space (2C1 + 2C2 vs. 3C1 + 3C2 + 3C3).
> Automating things on Linux is easy as I have the CLI. Automating things on Windows is kind-of easy as I have AutoHotkey. Automating things on MacOS is hard because there simply isn't a comparable all-in-one tool.
Mac has Keyboard Maestro, AppleScript, and a terminal.
> Not just different, substantially better, in my opinion. The addition of the command key is a 2x+ increase in modifier-space (2C1 + 2C2 vs. 3C1 + 3C2 + 3C3).
Right, but MacOS doesn't live in a vacuum. It's like the whole XKCD about competing standards again: https://xkcd.com/927/. In my eyes it's not worth being different from everyone else simply because you think you are a tiny bit better.
> Mac has Keyboard Maestro, AppleScript, and a terminal.
MacOS does have a terminal but it doesn't feel like integration is as tight with it as on Linux. On Linux I can do crazy things with desktop programs through dbus and systemd is easier to use for me compared to launchd (although this is heavily debated).
Admittingly the automation ecosystem on MacOS may be better than I'm aware as I didn't look very deep into it.
Yeah, if you move around OSs I'm sure the nonconformity is annoying. I'm in the camp that HCI is better when it's personalized rather than globally standardized, so I heavily rebind and use non-standard keyboards anyways.
It’s not a “tiny” bit better imho. It’s leaps and bounds.
Cutting/pasting into a terminal is effortlessly the same as everything else, instead of some extra modifier to Ctrl-c that I always have to look up in the menu. And find awkward to do as well...
I work pretty much constantly in the terminal on macOS ‘open <file>.pdf’, or .jpg or .png or .(whatever) then I ssh to a Linux box and want to run qtcreator on the .pro file and have to figure out what the damn app was called again...
Etc.
Just like your experience and disappointment with macOS, I expect mine (the opposite of yours) comes down to what I’m most familiar with...
Not the GP, but I absolutely cannot live without focus follows mouse and love being able to type and interact with a window without raising it. For example I can overlay a small terminal in front of a web browser and use both at the same time.
Using a floating window manager that doesn't support this is wasting a gross amount of screen real estate.
It's not a perfect replacement for mouse-focus, but most Mac apps can be interacted with without bringing them to the foreground by holding down command before clicking on the inactive window's controls. Also, right-clicking usually won't surface windows. Won't allow you to type but it's good enough for pasting bits in terminal windows, toggling settings, etc without changing which app or window is frontmost.
It's true that some stuff in macOS is tightly integrated, but the fact that homebrew exists and is a must-have kind of demonstrates the opposite.
Also, I've lost count of how many times my 1yo macbook pro crashed, while my crappy Acer laptop with Debian being subjected to the same usage pattern never did.
I’ve been staunchly pro Apple since my //e and I’ve recently gotten off of OS X completely. Most of my usage is dependent on developing server/SaaS tooling, and Apple’s dev support is so behind, that it’s made it less hassle to just run Debian on my desk.
... and then you run a script that depends on `/bin/bash` .. but uses a feature (e.g. coproc, associative arrays) from a version less than a decade old. And then you go and update your PATH and shebang lines to call out `/usr/bin/env bash` and hope things go right.
I don't know about that. My employer gives out Macbooks to us devs and there's no option but to use OS X. I must say that the OS is as bad as the hardware is good. This is definitely the best laptop hardware I've used, and unfortunately the most unstable, frustrating and bug-ridden OS I've used this side of Windows Vista.
Can you imagine that an OS update disabled the fingerprinter and also broke authenticated settings? And this is a common occurrence apparently.
You are making up terms for macOS. What do you mean by fingerprinter? Do you mean Gatekeeper / codesigning verification for the first time launch of an app?
For an OS that has a trillion dollar company and an actual integrated ecosystem behind it, macOS should offer a much better experience compared to regular desktop Linux though and not just be slightly better in some aspects and slightly worse in many others.
About the only objectively good thing that can be said about Macs running macOS is that the touchpad experience is quite nice ;)
I very much own all of my devices and Apple keeps them updated for 5+ years unlike every other OEM, particularly android OEMs who will barely deliver two major android versions if you are especially lucky.
Desktops are not railroads, Internet servers are. Considering that the overwhelming majority of Internet servers are running Linux and practically none of them are running macOS, I find this analogy to be hilariously wrong.
Even among developers, only ~25% of them run a Mac. Linux has that many developers and the rest is Windows.
FWIW, there's not a tremendous amount of parallelism to be extracted here.
I pulled the git repo on the site and it compiled in 54 s on a Threadripper 1950X @ 4 GHz (a 16 core processor). The dependencies loaded all of the cores for the first couple of seconds, but most of the time was spent in a lightly threaded section at the end.
m1 macbooks seem to be universally loved by developers and are leaps and bounds better than anything previously on the market. i'm so happy for the team at apple, especially given that not so long ago, many of us really really hated the direction apple was going for developers, and they've seem to have not only turned the ship around but strapped on rocket engines
If you like M1 you're most certainly going to love an M2 Mac which I would rather wait for.
However, I'm interested in the things Apple doesn't tell you. I would also keep an eye out on the internal SSDs since they cannot be replaced [0] especially if you're continuously using intensive software on it or your Mac keeps having to use a swapfile which degrades the flash even further.
So if you’re writing 30Tb in 2 months, you’ll start hitting the warranted wear limits in 20 months. I don’t think people expect their Apple laptops to fail in < 2 years.
If they’ve gone for (significantly more expensive) 2-bit cell (Samsung 970pro equivalent), then the write limits are 4-5 times greater - Samsung claims 1200Tb for the 970pro. I don’t believe Apple publishes the detailed specifications of their SSD flash chips anywhere though, so it’s impossible to know where the limit is for Apple devices.
It’s been a while now that some MacBook models have had soldered on SSD storage; it’s not new with the M1 Macs. If there were serious reliability issues we’d have seen them already.
What's interesting is that they could probably put a higher power (wattage) processor in there and get linearly better multicore performance. But in doing so, the laptop would no longer get great battery life and it would get hot and loud.
It benefits Apple to have achieved a level of single core performance that doesn't require high wattage. They may be able to use this to avoid the tendency of applications to eat up any resources available over time and become more power hungry.
> The amd64 version of Dolphin uses some Just-In-Time compilation that Rosetta can't emulate at all.
That's interesting. Clearly Rosetta can handle JITs since it could run the Intel versions of Chrome and Firefox before native versions of those were released. Are there any other macOS apps which don't work with Rosetta 2? Leaving out stuff like Docker, which is really an entire VM under the hood.
>This 15 watt laptop chip holds its own with desktop machines
Can people stop being surprised that a 15W per core chip is on par with an almost 15W per core chip? Get this into your head. Per core power consumption is not the same as the TDP written on the packaging.
Laptops have a high enough TDP that they can run one core at full boost. Desktops have a high enough TDP so that they can run multiple cores at full boost. There is no free lunch there. The ARM Macbook primarily benefits from a better manufacturing process, SoC integration and a better instruction decoder. These factors influence the performance, not some fantasy wishful TDP napkin math.
I don't care about Ryzen vs Apple in this scenario. I'm just incredibly annoyed that this ignorance keeps perpetuating itself because people don't understand the difference between per core power consumption and package power consumption and then act surprised that two equal machines (in the context of single core benchmarks) somehow perform the same.
> The ARM Macbook primarily benefits from a better manufacturing process, SoC integration and a better instruction decoder
It sounds like that just boils down to “it’s a better chip.” You’re even saying that the instruction decoder is better - that means it’s a better chip. What else does a processor do besides decode instructions?
How many aspects of the chip do we have to make excuses for before we can just conclude that the M1 is the overall best processor money can buy for a laptop?
Consumers don’t care that Apple is using a great TSMC process and Intel isn’t, they care about performance and battery life.
The M1 multi-core benchmarks are nothing to scoff at, either. They absolutely keep up with the more expensive, heavier, hotter, worse battery life 16” MacBook Pro Intel models - at least, they keep up close enough to not justify the $1,000+ price premium.
When Apple replaces the 16” model, the AS version is probably going to have 16+ cores and make the Intel version look absolutely silly. Just like the Intel MacBook Air, we’ll be asking ourselves how we lived with this x86 trash for so long?
I think OP is taking issue with the claim that the M1 can compete with desktop class CPUs, which isn't true for multicore benchmarks. The M1 is about on par with current Intel/AMD offerings in single core benchmarks but can't keep up in multicore.
But those benchmarks show that it does keep up until you literally throw more cores at the benchmark.
Without going up to 10 cores, only 4 models on that list are faster than a Mac mini that costs $600, and those models are negligibly faster. And they can’t run on a battery for 15 hours like the M1 laptops.
So it’s really just a nitpick surrounding the fact that Apple doesn’t sell an M1 with more than 8 cores yet, which Apple definitely will, probably within the next 6 months.
That's not a nitpick, it's a legitimate issue with the chip. 8 cores is not consistent with the state of the art, it's consistent with low tier consumer CPUs.
The other major issue is lack of memory (just by way of example, I allocate 16GB of memory on my local machine for VMs regularly - I can't buy an M1 Mac to do my work right now).
And a Mac Mini only costs $600 if you're ok with 256GB of disk space (not enough) and 8 GB of memory (not enough) and no EGPU support yet (not sufficient). It's a cool toy right now.
The M1 is a low tier consumer CPU, and the design choices are consistent with that positioning. In all likelihood this is the slowest M-series processor Apple will ever make. That it is competitive with some high-end processors is compelling, but what this might mean for the future is exciting to many.
Does anyone here have experience running Emacs on the new MacBooks? Is the authors experience the norm? My life is an Emacs right now, so this would be a blocker for me to upgrade.
I'm running Emacs natively on M1 and it works great. The biggest missing piece is certain static analyzers like shellcheck aren't available for ARM yet since ghc is still working on support, although you can probably get it working with Rosetta. See this thread for a list of most tools:
gccemacs isn't available natively yet and probably won't be until later this year, but Emacs running on M1 is very snappy and faster in my experience than a nativecomp build running on an Intel machine.
My life is also in Emacs. I'm using it all the time on the new Macbooks and it's working great for me (gui mode, not terminal mode).
There are two major versions of Emacs on Mac. There's the "NextStep" version, which is part of the official emacs repository, and the "Mac" version, which is separately maintained.
* emacsformacosx.com runs in x86 emulation mode, but flickers when using lsp mode --> this is the version the author used, and I didn't find it to work well. It's the NextStep version.
* Mitsuharu Yamamoto's maintains the Mac port and has M1 patches in the "work" branch but not in the master branch. I use the work branch and am very happy with it. Compilation instructions: https://amitp.blogspot.com/2020/11/building-emacs-27-on-appl...
* in homebrew the emacs and emacs-plus packages both work on arm m1, but I haven't tried these as I prefer the Mac port over the NextStep version.
* homebrew "railwaycat" emacs is based on the Mac port, and it looks like it has m1 patches, but I haven't tried it either.
* The gccemacs branch was tricky to get working even on my x86 mac, and I haven't tried it on the M1 macbook. It requires libgccjit which is in x86 homebrew but not in arm homebrew (gcc is not yet available). The M1 feels so fast that I've not felt the need to use gccemacs.
Article author here. A native emacs build fixes it entirely. I didn't know where a native emacs build was until I got emailed about it after I published the article.
This sounds a lot like the kind of stutter Dolphin's dynamic recompiler used to suffer when it first discovered a new shader.
IIRC, for faster boot times, Emacs binaries burn in some kind of low-level memory-image that gets dumped into an mmap region and then "revivified." I wonder if that's what Rosetta is choking on.
If so, I wonder whether, until an actual AArch64 build is available, it'd be possible to work around this problem by just rebuilding Emacs (for x86!) without that optimization enabled.