The “for less” bit might be true but is the better specs part?
In a comparison[1] the M1 in a MacBook Air seems to handily beat the Intel Core i7 1165G7 chip on most metrics.
Personally I’m not that CPU bound generally and I like Intel Linux compatibility so I’d still make the trade off.
1. https://nanoreview.net/en/cpu-compare/intel-core-i7-1165g7-v...
I just couldn't bring myself to use macOS daily, so I punted the laptop change to next year. I wish Apple would just sell their hardware like anyone else, working with OS vendors to get it supported.
Apple doesn't provide Linux drivers for their components, but neither does "anyone else", sadly.
But it means that Linux on M1 Macs might actually happen in the near future.
Edit: And Windows doesn't run natively/officially on M1 Macs because Microsoft has a stupid exclusivity deal: https://www.macrumors.com/2021/11/22/microsoft-qualcomm-arm-...
Apple not actively hindering Asahi Linux isn't exactly a great accomplishment. They chose not to write Linux drivers for their platform and that's their choice, but that puts them behind even Nvidia as far as supporting Linux goes.
Since Apple do not keep their firmware ABI stable across the board, we'll have specific firmware versions (=specific macOS versions they come from) "blessed" for Linux compatibility. For updates (bugfixes or security issues, chiefly) you'd re-run our installer which will eventually have an "upgrade my firmware please" mode. That would run from recovery mode, same as the original install. All this stuff is per-OS, so it does not affect any adjacent macOS install which will use its own firmware - you can upgrade macOS whenever you want without breaking Linux.
Wifi works fine (modulo some firmware support details that'll get ironed out); people have been doing performance and stability tests and there is no major issue. I've heard stories about bad radio performance on Macs in the past, but those are almost certainly due to using the wrong firmware or config. That's what my patch set fixes: we use all the same firmwares and configs that Apple does, so we get the same results.
ATI/AMD intentionally redesigned their GPU silicon to make it's possible to develop open source drivers without exposing HDCP secrets, and even the open source drivers can use HDCP if they want to.
This is not known very widely, but this is worthy of great praise if you ask me.
Can you clarify what you mean exactly? I have a hard time believing AMD ever ran HDCP keys through the Windows kernel.
Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card.
AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used.
This is something to praise for, IMHO.
Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.
So, they were unable to provide the access they wanted to provide (for video decoders, at least), on the previous (then current) architecture.
Considering HDCP came later, it might have just been slapped as a side module and some of their math magic might be offloaded to GPU even. I remember having old ATI drivers having a very cinematic look when video was accelerated by the GPU itself (it was surreally beautiful), but they had to throw all this machinery out from the driver when they started to modernize their stack (and they broke video playback for months due to not supporting proper overlay formats).
Similarly, I think closed source drivers were programming some of the cards during initialization, because I remember they're talking about moving all this init step to the BIOS itself, and opening some doors on the BIOS to tweak the card during the init (clocks, fans, temp reads, etc. IIRC) for allowing OS and open drivers to play nicer and with less effort with the cards in the long run.
The details are hazy, because these transitions were made almost a decade ago if not longer. However, while NVIDIA was playing the deaf, and Intel was just starting to provide good open drivers for their IGPs, AMDs move as a prime GPU vendor brought a lot of good light to them.
If you want, I can try to dig the history and create a timeline for you, but it might not be an immediate endeavor.
I'm just quite confused as to how HDCP factors into all that. HDCP really is just a hardware block that's part of the video output which you enable or disable; there is a bunch of nonsense associated with PAVP and other such stuff on Windows, but none of that should really matter to Linux, nor should whatever way HDCP is implemented affect other features of the open drivers. AMD certainly do deserve credit for their work on Linux support, I just find your specific HDCP story quite strange :-)
But if I go and buy a random Windows _laptop_ and try to slap Linux on it, I might have all sorts of issues with the trackpad, webcam, fingerprint sensors, never mind sleep/wake.
That's why Linux laptop vendors are a thing and deserve our praise (just like the companies you've mentioned)! All I'm saying is that Apple is hardly the only company left that doesn't actively support Linux.
I installed Linux on a 2015 MBP recently and there is no real way to get the webcam working.
?!?!
There are vendor-provided Linux drivers for pretty much everything?
Everything in Intel and AMD CPUs are supported in mainline. nVidia provides Linux drivers.
I don't have a clear view about how many devices nowadays are reverse-engineered, and how many are provided by someone with datasheet (it happens quite often that mainline drivers are not provided by vendor directly, but by a third party that got access to datasheet), but it really feels like most vendors do work with OS vendors to get their hardware supported, and that Apple is totally an exception in the hardware world.
Also, like Java, they have maintained their own nVidia drivers up to a certain point.
Today that gap is smaller since HW manufacturers are more open about their firmwares and drivers, and Linux is more widely adopted.
I just sent in a patch series to Linux a few days ago to get all custom Broadcom cards for T2 and M1 Macs working (~2017-present), with the right firmware selection logic. Took a week or so to develop and test on both ARM64 and x86. (There was some prior art but certainly nothing that would've taken more than a few more weeks to work out from scratch; besides, I found a Broadcom source dump for Android that contained most of the interesting knowledge excluding the Apple-only bits, since some of it is relevant to newer non-Apple chips too).
Once you have a team of the right people and enough motivation, getting reverse engineered hardware working on Linux doesn't take as long as everyone thinks :-)
OTOH, kudos for all the hard work you're doing on the kernel. Maybe one day I'd have enough spare time to work on that marvelous beast.
> Once you have a team of the right people and enough motivation, getting reverse engineered hardware working on Linux doesn't take as long as everyone thinks :-)
As long as the hardware (or the vendor) is not intentionally malicious towards Linux or being reverse engineered. I've seen my fair share. :-)
The b43 days were definitely special, and that was a full from scratch reverse engineered driver plus open firmware, which is a crazy accomplishment. These days though, we just accept that we're going to have to run vendor firmware, either because there's signing involved or because it's a huge amount of work to attempt to reverse engineer and reimplement that bit. Firmwares have grown from dozens of kilobytes to megabytes and it's just not viable to rewrite all that any more, if it's even possible.
OTOH, we also have better tools for and experience reverse engineering now than we did back then. Ghidra has made "proper" disassembly and decompilation accessible to anyone, and we can run proprietary OSes in VMs to study how they interact with hardware.
> As long as the hardware (or the vendor) is not intentionally malicious towards Linux or being reverse engineered. I've seen my fair share. :-)
Well, it doesn't happen that often outside of closed platforms (i.e. needing an exploit to do anything) and Nvidia ;-)
When I was shopping around a few years ago, the fingerprint reader even on Dell's Linux-focused developer laptops was dead. I liked the Razer Blade, but many components didn't support Linux; looks like the trackpad on some models still doesn't work.
If "any vendor" actively supported Linux, we wouldn't need companies like Framework or system76 that pick compatible components. I'm not saying that Apple is particularly helpful, just that they're hardly alone in not caring about Linux.
Apple may not contribute much more than a bare platform with M1, but that isn't unusual in the scope of computer history. What's important is that they are not actively enforcing exclusivity or deterring the attempt. They've even shown tacit support in recent EFI patches by making changes that preserve the current mechanism other OSes can be loaded.
No one doubted that Intel could make a CPU as powerful. But everyone knows that it isn't gonna be cool and quiet.
Cellphones have moved away from replaceable batteries specifically because of fast charge. Most phones with 20 watt charging will reach ~50% battery in 30 mins, so even with battery degradation, you really don't notice the effect in day to day life.
Same thing with laptops, there really are very few situations where you don't have access to a charging port for ~6-8 hours.
Given that, Id personally rather take the hit on efficiency in return for way better compatibility, ability to run a full linux natively , and not deal with all the extra crap that Apple throws in the M1. And, If I really care about longevity, a second battery is easily an option for laptops like Frameworks.
I have to use it for work, and it really is a drag compared to Linux.
also, sometimes even a simple `ls` from terminal takes a few seconds. why? i have absolutely no idea.
If you don't have a stable internet connection, that could be the reason - macOS sends a hash of every executable to Apple's servers before it is opened[0]. This caused a major issue at the end of 2020, when these servers stopped working and all macs stopped working unless disconnected from the internet[1].
macOS has also been updated so that syspolicyd bypasses VPNs and system firewalls like Little Snitch[2], so you can't easily block these connections now.
[0] https://www.reddit.com/r/netsec/comments/gp52pe/apple_is_tra...
I hate when people say "mine works," but here's an `ls` of my homedir showing it's not universally slow. I currently have an absolute garbage network connection.
> ls -G 0.00s user 0.00s system 64% cpu 0.010 total
There are also many, many other reasons it could be; some macOS specific and others that aren't--most importantly what they're seeing isn't universal. macOS often ships with very old GPL2 tools that can cause various problems (many people brew install updated GPL3 versions), people often have configurations that can slow down `ls` by multiple factors (colors, sorting, etc can each cause multiple queries to disk or require the listing to complete before displaying output), customizations causing a slow prompt, a slow or corrupt disk, listing a slow network drive, etc.
The VPN bypass was very quickly removed from macOS over a year ago [1]. So it would only be relevant if they were using a very old version of Big Sur.
Some specific examples,
No internet connection: instant fail over
Blocked OCSP firewall or whatever: instant fail over
Slow internet but still able to reach: slow start: 1+ seconds
Bad internet, not able to reach: 3-5 second delay waiting
Normal internet, OSCP reachable: <1 second delay
Disabled trustd: Nothing will start, single user mode and trustd restore required
I've experienced all of these and is one of the reasons I have a shiney new Framework laptop sitting waiting to be migrated over to. Also the "only on first run" also isn't true. It periodically checks for certificate revocation (as it should) and therefore will cause issues at sporadic intervals.
And the kicker of course is that all this is via plain ol' http, so everyone knows what developer's programs you're starting via the hash.
I've tried to push myself to use various Linux distros (most recently Pop and Ubuntu), but I always end up back on MacOS.
I also like the open nature of Linux. It's fun to be able to look into the source code for pretty much anything.
I do recognize that you could also just like Linux more from a usability perspective, which is your opinion to hold!
Compiling LLVM eats a lot of memory for instance. 16Gb is not really enough to take full advantage of the number of CPUs in a modern laptop.
Is this a laptop for everyone? Not necessarily, but for certain classes of users it's manna from heaven.
I’m sure there are other 'workstation-ish' jobs that people would happily run on their laptop if it had > 16Gb memory. 64Gb is quite the leap.
No $2000 laptop in 2020 should have only quad core cpus.
The M1 16gb will run circles around the i7-1185g7 (highest spec chip framework sells) compiling llvm with 64gb of ram.
Only using a shitload of idle VMs will have any apparent benefit over M1 MacBook pros.
The cpu is just too limiting for the 64gb of ram argument.
I have an M1 MBP and an 1185g7 based Linux laptop. Single core benchmarks, the i7 comes out slightly ahead. Multi core benchmarks, the M1 comes out slightly ahead. There are no circles being run around in performance - only in battery efficiency. For day to day developer usage, testing things literally side by side, I find absolutely no discernible difference in speed.
The M1 does win for battery life, but the battery still lasts for a full work day in my i7 laptop. Honestly at home I always reach for the Linux laptop, because I don't really need the battery life. But for going out and about away from power, the M1 MBP has advantages. Sadly the software (personally) lets it down, I'd probably use the MBP more if it has better Linux support in the future.
It will run circles around the 1185g7 compiling large codebases.
Passmarks across hundreds of benches show a 25% single and 40% multithreaded performance boost over the 1185g7.
I’ve got an i9 8/16 laptop chip and the 13” M1 is trading blows with my laptop despite 2-3x the thermal headroom and considerably less cores/threads across all workloads.
The i9 Apple laptops were notorious for not having a cooling system that could match the heat output of the CPU & throttling almost instantly.
Modern Intel laptop CPUs are no where near the performance / W of the M1, but they are considerably better than those that Apple stuffed into their laptops a few years ago with inadequate cooling I believe.
The only problem with the first generation framework laptop is intel’s quad core CPU because of thermal and power problems associated with their process nodes.
Hex core is really the lowest I will go now for anything over $1000. If this was a Ryzen 5800u, I’d have bought one already.
FWIW, Cinebench multi-core benchmark is around 20% faster for me on the M1.
[0]: https://developer.arm.com/documentation/100076/0100/a64-inst...
Many of us spend substantial periods of time writing up the technical documentation in Confluence or use JIRA. Confluence alone loads approximately 22Mb of mangled and compacted JavaScript for each open page in a separate browser tab.
Before M1, Confluence and JIRA were the single most source of a sustained battery drain, irrespective of the browser. On M1 based laptops, the battery impact is so negligible that it can be considered non-existent. How much of this subjected experience can be attributed just to the the ARM 8.3 JavaScript hardware acceleration is an interesting question as the JavaScript browser performance on Intel CPU's has also been affected by Spectre and Meltdown mitigations in the CPU microcode.
LLVM builds eat memory in my experience & end up swapping if you don’t play games with the build system to reduce the parallelism of memory intensive parts of the build.
If you’ve got a VM or two sitting around then obviously that makes things worse.
2) If you need 64Gb just sometimes, swapping on M1 MBP is insanely fast.
Also, you want to ignore 400 Gb/s provided by Apple's 64Gb memory, but... you know.
It’s often tempting to dismiss a product that doesn’t meet your own personal use cases but it’s a bit naive.
It’s actually fun to see products get popular that I know I wouldn’t buy myself. It doesn’t make them bad it just makes them not for me right now.
I understand that upgrading the CPU is not yet quit viable at this point in time for framework but still, it noticable lacks behind the competition when it comes to CPU perf for many (all) tasks.
And things will only get harder with the Ryzen 6000 laptop CPUs coming late this year (on the German marked maybe only early next year).
And similar is true for the competition from newer Intel processors.
Edit
This kinda has me stuck, 16GiB of RAM isn't enough, but the additional perf of the newer CPU is well wanted, but then USB ports being non easily repairable on a T14 is a problem to as I somehow tend to brake them. And only 2 USB-C ports on the T14 are a proble, too.