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.
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.
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 do recognize that you could also just like Linux more from a usability perspective, which is your opinion to hold!
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.
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-...
?!?!
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.
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.
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 ;-)
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 :-)
I installed Linux on a 2015 MBP recently and there is no real way to get the webcam working.
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.
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.