The Worst Experience I've Had with an Aarch64 MacBook
christine.website
christine.website
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.
https://amitp.blogspot.com/2020/11/building-emacs-27-on-appl...
unexec hack
No true anymore for Emacs 27.x, they go with more portables (though a bit slower) preload
https://github.com/railwaycat/homebrew-emacsmacport/issues/2...
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.
You are missing out big time, coming from someone who was staunchly anti-Apple for years
It's too bad that it's Amtrak and not Japan Railways.
Even among developers, only ~25% of them run a Mac. Linux has that many developers and the rest is Windows.
But what about desktops?
> Even among developers, only ~25% of them run a Mac. Linux has that many developers and the rest is Windows.
It's less than 25% among general users...
MacOS for me is a massive pain to use compared to Linux.
So, I’m curious as to what your pain points are.
- 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 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.
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.
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.
Why should macOS curtail to what the rest do?
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...
Using a floating window manager that doesn't support this is wasting a gross amount of screen real estate.
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.
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?
[1] https://developer.apple.com/library/archive/documentation/La...
[2] http://www.hammerspoon.org
[4] https://gist.github.com/gmanley/750426aa91097aeef3aee5a73a1f...
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.
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.
Can you imagine that an OS update disabled the fingerprinter and also broke authenticated settings? And this is a common occurrence apparently.
There is a button on the top right that doubles as a fingerprint sensor. It stopped working after an OS upgrade.
About the only objectively good thing that can be said about Macs running macOS is that the touchpad experience is quite nice ;)
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.
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.
[0] https://twitter.com/never_released/status/136065759419767194...
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.
The parent tweet is a clear outlier.
Time to switch to a real text editor such as Vim then :)
/s
From github repo: "My personal/portfolio website."
Feels like only one of those two should be true.
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.
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.
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.
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?
Compare:
https://browser.geekbench.com/processor-benchmarks/
to
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.
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.
https://github.com/Homebrew/brew/issues/10152
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.
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.
TL;DR: Emacs is not a blocker, but the widely used version from emacsformacosx.com doesn't work as well as the Mac Port [https://bitbucket.org/mituharu/emacs-mac/src/work/README-mac]