M1 Air here that I've had for almost a year with zero issues, and I also use Firefox and watch a lot of youtube.
It's been this way since OSX day 1 IIRC, so it's a little surprising the apple versions are still apparently inferior (if the grandparent poster is anything to go by, haven't used em in years), but it's conceivable the CLI just isn't an apple priority.
I wish they'd just give up already and copy as much (of the CLI-relevant stuff) as possible from linux, and accept that they'll need to give up a tiny amount of control over a small sliver of their OS - a sliver that they never wrote in the first place and also can't really change the api of, because that would break all kinds of things, which renders their ability to close source somewhat moot anyhow. And most users never use this stuff! The linux-conventional gnu variants are well maintained and usable in both MS world and linux world - having CLI scripts that are more easily portable across three OS's would be great. Apple's toxic control-freak nature really hurts here, and mostly just their users. I really don't get it.
Anyhow, there are workarounds (but e.g. homebrew is hit and miss), it's mostly just an annoyance they're even necessary.
[1]: https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html
[2]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
[3]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
Accepting major changes like that isn't trivial; and a certain amount of NIH is healthy here. I mean, that's kind of apples motto too right? This was a technical patch set with unclear upside (if any), and potentially relevant cost - why would they accept that?
> They're basically achieving their dream now with Swift, though. I don't expect them to ever release that source. I don't think there is any precedent for Apple releasing source code after the fact.
I wonder, to what degree is this still the case today? Has Apple's position on Open Source changed in the past half+ decade?
A better phrasing: They were unable to close-source an existing GPL'd compiler.
Apple is very fond of locking down their hardware. Google took a very strong stance against the AGPL-even banning it from their own public code repo service before they shut it down.
I've loved my M1 MBA but I purchased it specifically knowing I have a primary x86 workstation to fallback on for heavier tasks and I'll often give up trying to install some dep/run some program on the MBA and switch to that. It still works great as a general purpose device and I do some dev on it but if you're looking to do all your dev on it, I'd be cautious.
I feel like many many engineers like me would easily get a reliable laptop with MacBook Pro like specs. The problem is that simply does not exist.
Excellent hidpi display.
Ryzen 5000 series CPU with its low power draw.
Good build quality.
Reliable support system.
Non weird components such that a recent release of popular Linux distribution would “just work” without needing manual tweaks.
In my experience, you get 3/5 in the above list at best. Framework laptop hits several of those points but misses out on Ryzen. Another contender on my list is ASUS 14 OLED with Ryzen - I’m worried about their support system though.
How is the trackpad?
[link redacted]
Probably not any better either. If you want to run docker on a mac you probably should not, but the second best strategy is probably to bite the bullet and run an actual VM in which you do your docker stuff.
Odds are a proper and well maintained hypervisor you keep running will be a lot better than whatever DfM does.
Probably, although you probably do still get better thermals and battery life with the M1 Macs.
It makes the case for stuff like GiHub Codespaces or sshing into a remote machine via VS Code a lot more manageable. For everything else, the M1 is a beast, and even emulated, you can get a really good Linux experience (Windows too for that matter — games, obviously not withstanding), but containers? Nah. It’s worse than the already sad state on Intel Macs.
About 6x worse perf in my specific case.