There's groundwork that's already been done, as mentioned in the article, which brings some dividends, but, ultimately, there is a new mac every year that comes with a new chip, a plethora of microcontrollers and gpu changes, impossible to keep up with, that is why asahi team is focused more on m1 and m2 models. Even so, to this day both of them have issues with idle power management and alt-dp implementation, preventing many to switch, by the time they will have been ironed out the value of machines would be significantly diminished.
It is a miracle how much so few can do, but in the end, despite ubiquitous media coverage it looks like team's enthusiasm and passion have dwindled to the point that even m1 air will never be ready.
Will it ultimately be manually loading a build into specific hardware each time, or is there a level of automation that can be done here?
Nit: I²S has nothing to do with I²C.
(Most I²S chips also have an I²C interface since I²S only carries raw audio data, no sideband like volume control or clock configuration. But that's a separate interface and can also be SPI rather than I²C. In fact, SPI is more closely related to I²S than I²C is.)
I think the last time I used an RPM-based distro was almost 2 decades ago.
It allows you to do some remote control and automation for kernel loading and debugging where you get a very thin layer in between the real hardware and the kernel, without affecting the hardware I/O behaviour.
M1 support is pretty usable nowadays, and I would imagine at least a fraction of the work translates to future devices... It's not sunshine and rainbows, but it isn't a project doomed to fail either.
1000s of hours of work for what is just sitting in a drawer in Cupertino. But they won’t.
Selling hardware with the software that helps them track means more revenue than the same hardware with the software.
They still have the Darwin kernel open,but more and more of the open core is moving to closed components, a recipe for what Google started doing to Android. Now that they're no longer the hipster underdog, I don't think they care much about the brand marketing. You already believe they make the best laptops by far, what more marketing do they need?
I don’t agree that Apple makes the best laptops by a parsec. Not anymore, many alternatives are closing the gap. This is aided by the fact that Apple hasn’t touched the MacBook Pro chassis in 5 years, making it quite dated especially with the underutilized, oversized notch and the horrendous menu bar software implementation that plagues the notch as a real problem for me and something that doesn’t just “disappear into the background.” The software solution is to just disappear menu bar items that don’t fit, making them unusable.
Apple is still the gold standard, don’t get me wrong. But I’ve got my Framework 13 Pro preorder in, and the list of compromises compared to a Mac is very short. My existing Framework 13 is already close enough and the Pro appears to fix 100% of the gripes I have with my system.
CNC machined chassis? Check. Haptic trackpad? Check. Graphics performance? Better than the M5 (non-Pro). Battery life? 20 hours of video playback.
And I’ll be getting numerous advantages over a MacBook: cross-compatible modular hardware, upgradable RAM and storage, customizable I/O, low cost DIY repairs, 3:2 screen ratio ideal for coding.
But this is just one laptop. If you explore the windows laptop space, there are a lot of great machines these days. Windows is really the weakest part of the equation, and you can just get rid of that.
I’ve myself eyed the Zephyrus G14 or G16 as a gaming and general purpose system in a MacBook Pro-sized form factor. It’s refined, it feels premium, the OLED display is gorgeous. Apple’s best chips can’t touch the graphics performance of a dedicated Nvidia GPU, so long as a huge amount of VRAM isn’t a requirement for you.
There are also laptops in the Lenovo Yoga line that are extremely compelling against a MacBook Air.
This is the weal-and-woe of reverse engineering. It's awesome that these machines now have native Vulkan 1.2 drivers, but it took years to get there. There are still unsolved problems 7 years after Apple Silicon hit shelves, and most newer hardware is broadly unsupported. The lesson here is a reiteration of what Linux users have always said - proprietary drivers suck.
That's just your made up opinion, completely not supported by their financials.
Hopefully, they will manage to get it done someday.
iPhones are largely locked to their App Store so no risk there. Macs (currently) aren’t locked to the App Store - and I’d guess that Mac App Store usage is middling as a result.
Which is to say, I doubt that a marginal Mac App Store revenue hit from a small proportion of users switching to Linux over MacOS is the driver for not supporting Linux development. I’d guess it’s more about an inflexible company culture and maybe not wanting to extend their area of responsibility and risk.
And this is related to MacBooks how exactly?
You do realize that Apple is a public company and one can just go look at their financials like their latest 10-Q [0] right? For the most recent 6 month half (ending March 28 2026) I'm seeing $194 billion for product sales and $61 billion for service sales. The gross margins are certainly higher on services, at 77%, but 40% product margins are nothing to sneeze at either, and the disparity in absolute sales means the absolute dollar gross margins are $77 billion for products vs $46 billion for services.
So I don't see how you can assert that their "big money maker is their app store" from those numbers. Hardware matters a lot, and furthermore Apple sells services (like AppleCare+) that are specific to hardware and thus even a Linux user might still be interested in.
And without their hardware, their services would evaporate. There is a much tighter link there than with many companies. So they're on the hook for continued R&D and capex on that no matter what, you can't really separate that out, and in turn it's always going to be useful to have more volume to amortize it with.
I think primarily it comes down to corporate DNA, which is powerful. There are plenty of Mac hardware, software and service markets in pro/business/enterprise Apple has neglected or abandoned over the years, including ones making oodles of money, not out of any 4D chess but just because it doesn't fit them as an organization.
----
0: https://d18rn0p25nwr6d.cloudfront.net/CIK-0000320193/37f5e9c...
That said, their AirPods division could be a Fortune 500 on its own.
The only reason I'd see support for Asahi making sense for Apple is a Firefox situation, keeping the project alive to prove to regulators that there are alternatives.
The reason why they both follow the same naming scheme is that Philips Semiconductor (now NXP) made both.
I haven't actually tried to install it yet, though.
https://voidlinux.org/download/#arm%20platforms
It's a regular package of linux in the distro: https://github.com/void-linux/void-packages/tree/master/srcp...
I don't think the Mac App Store is going to get to iPhone levels of lock-down soon, but Apple thinks in ecosystems, not just in laptops. If you have an iMac, you probably have an iPhone, and you're probably going to buy an iPad should you ever want a tablet.
If they wanted, they could open source all of the drivers necessary to boot an OS as part of their Darwin core, but they choose not to. That actually breaks with their older, more open development style. I guess they just don't see the benefit of being open any longer.
Though their kernel fork is (obviously) open source, so there's nothing stopping you from taking a Debian aarch64 roots, build your own Asahi kernel (or take the build from Fedora), and set up Debian on these machines with Debian yourself. Just requires some elbow grease.
Or, if you find Ubuntu acceptable, there's Ubuntu Asahi: https://ubuntuasahi.org/
EDIT: After some googling I found this wiki article: https://wiki.debian.org/InstallingDebianOn/Apple/M1
I believe you.
> I already buy from Steam.
I believe this even more.
In practice, I expect a paid Linux app store to go down about as well as the Microsoft Store has. Especially now, in the age of vibecoding.
They’re working hard on upstreaming everything exactly so it’s easier for any distribution to be ported.
As a result, I understand the desire to stick with a particular distribution that we're already familiar with - it's less work, and less having to remember subtle differences in structure. But when there is a time where I'm forced to use a new distro (e.g., when Asahi was first released exclusively as an Arch Linux ARM distro), I never regret the small learning experiences involved :-)
Admittedly, the screen ratio is better with the framework. But prefer the matte screen of the MacBook.
Yeah, they pretty much lied about that. It is only in a special Windows ultra-power saving mode that heavily throttles background tasks, forces the screen to be 30% lower brightness, heavily downclocks the CPU (50%+ less performance!), etc; The MacBook has to do no such tricks.
You're not gonna see Frameworks that equal the perf-per-watt of Apple until they release a model with a Snapdragon chip.
Frameworks have one benefit that other laptops don't: there's only a few parts. So for example for your Framework speakers you can find an EasyEffects / Pipewire (+bankstown?) tune profile that makes them sound better than 99% of laptops on the market. It's basically the Raspberry Pi effect.
Why? People have been using Orbstack, Lima and Docker long before Apple shipped first-party container tooling. The virtualization support was never ever a problem.
For actual dedicated server usage, macOS itself is the problem. You want to be running Proxmox on baremetal, nobody wants to administer headless macOS machines by-hand.
iPhone: 50.4%
Mac: 8.1%
iPad: 6.7%
Wearables, home and accessories: 8.6%
Services: 26.2%
I assume that the majority of service revenue is App store revenue.
Other services they provide are iCloud and Apple care
A distro is just window dressing and flavor.
Someone looking that machine who wants strong GPU performance, I’d probably send over to a Zephyrus G16 or something like that, and give up the modularity.
SSD and RAM speed specs aren’t really something that impacts the user experience unless you’re doing local LLM work.
What does impact the user experience, for example, is having access to hundreds of thousands of PC games by not being platform locked. Or maybe your user experience is impacted by having upgradable storage.
This obviously depends on individual needs, and I’m certainly not saying either system is bad. But I am saying that the Apple “experience” is often assumed to be the best when it does have some downsides.
Even the fact that there’s no charge port on the right side of the MacBook Air/Neo is a user experience downside (of course, not every PC laptop has that feature, but you can find them in the same price category as the Air).
I sold my MacBook Pro because I needed 2TB and couldn’t afford it from Apple. Being stuck with 512GB when 2TB drives cost under $200 at the time was stifling.
Tim Cook said it himself: Apple is not a hardware company (https://www.businessinsider.com/tim-cook-apple-is-not-a-hard...).
The days of assuming that Apple has the best chip efficiency are coming to an end, especially if the Windows/Qualcomm platform is a workable choice for your needs (maybe someday Linux support will get better).
Apple still has a lead but it’s small enough that it’s not a good reason to choose an Apple system on its own. The M1 MacBook systems got double the battery life of competitors, now 5 years later, Apple systems are at best getting ~10% better battery life than competitors, and some systems like the XPS 14 have Apple beat entirely.
Obviously getting 20 hours in real world productivity use was never realistic, and it’s not realistic on a MacBook Pro, either. I disagree that framework was “basically lying.” They live-streamed the laptop hitting 20 hours, it doesn’t matter that they changed settings to get there. MacBooks have a brightness slider, too. You aren’t getting anywhere close to 20 hours on a MacBook without turning the screen brightness down.
IIRC the MacBook Air/Pro can’t even make it to 20 hours regardless of settings.
The point is that the new framework 13 Pro laptop isn’t a 5-7 hour battery life experience like the previous models. Instead, you can expect 10+ hours depending on what you’re doing it, so it’s a full work day.
Linux 7.1 is now here, and of course with it comes another progress report. We’ve got M3 progress, Apple bugs, and more!
When you long-press the power button on your Mac to bring up the boot picker (or use the Startup Disk application), what you see listed as Asahi is not actually the partition with the operating system on it. Apple’s boot tooling will only work with what it considers to be a “valid” macOS installation inside an APFS container. So that we can use Apple’s bootloader and avoid needing users to run commands from Recovery every time they want to use Asahi, the Asahi Installer creates a small APFS container (2.5 GB) with just enough of macOS on it to convince Apple’s tools that it is a bootable installation of macOS with m1n1 as its kernel. This arrangement worked completely unchanged from macOS 12 to macOS 26, and Apple even fixed a couple of bugs in their tools that are only encountered when attempting to boot raw binaries that are not a real XNU kernel.
Shortly after the release of the macOS 27 Golden Gate developer beta however, we began receiving reports that people were no longer able to boot into Linux on their machines — the option had simply disappeared from both Startup Disk and the boot picker! Obviously this is quite concerning, and so we made investigating this a priority.
Inspecting the disk using diskutil revealed that all Asahi-related partitions were still present on the disk after upgrading to macOS 27. No data loss was occurring, which is a positive sign. Additionally, Asahi was still bootable on the same machine when using the boot tooling from a second install of macOS 26.
chaos_princess began inspecting Apple’s own macOS Installer and old streams from way back when we were first poking at Apple’s boot tools. The macOS Installer sets some APFS metadata before rebooting the machine, which further investigation revealed to be a flag that marks the volume as bootable. Until macOS 27, the boot tooling simply ignored this flag entirely. After setting the flag manually on an Asahi APFS container, it becomes available in the macOS 27 boot picker with no further changes.
Going forward, all new Asahi installs will have this flag set automatically by the Asahi Installer. We’ve also added an installer mode that will fix existing installations. If you’ve installed the macOS 27 developer beta and cannot access your Asahi install, please run the installer again and use the “Fix macOS 27 boot picker compatibility” option.
chaos_princess has also developed a program that can be run from Linux to fix the issue. While we would eventually like to deploy this fix automatically, we need more testing data to confirm that it is reliable and will not destroy anyones’ filesystems. That’s where you come in. If you are willing to help us test this, clone this repo, then build and run it from Linux before upgrading to macOS 27. If your Asahi volume is still selectable as a boot target from macOS, it has worked. Do be sure to let us know how it went by popping in to one of our channels on OFTC or Matrix, especially if you run in to any issues.
macOS 27 also brings firmware updates for all peripherals with global firmware, including the SMC. One of the SMC’s myriad functions is battery management. Our Linux power supply driver talks to the SMC to get information such as charge state, voltage, time until empty and battery health. The driver also uses the SMC’s firmware interface to configure charge start and stop thresholds to prolong the life of the battery. macOS 27’s SMC firmware changed one of the battery management interfaces from returning a 32-bit integer to returning a single byte. This change confuses our driver, which under certain conditions considers the battery as having failed and initiates an emergency shutdown to protect the system. We have already patched this in the downstream kernel; starting with version 7.0.12, the power supply driver can deal with both firmware ABIs.
Bugs like these are an important reminder that developer betas are just that, developer betas. It is ill-advised to install them on production machines. The two issues we have had so far have luckily minor, but that doesn’t mean that all future issues will be too. Global firmware updates are effectively permanent too, and can only be rolled back with a DFU restore of the machine. Please refrain from installing developer betas going forward. We have sacrificial machines we use to test these things on your behalf, there is no need to risk your own expensive hardware and important data.
Designing and validating computer platforms and the ICs that go into them is extremely expensive and time consuming, so it makes very little sense to make changes to existing designs when they are not necessary. Early on in the project, we made a bet that Apple would agree and refrain from making constant breaking changes to either. Discounting a few of the larger SoC blocks like the GPU that are almost required to change every generation, this bet has largely paid off.
Audio on an Apple Silicon laptop involves a few different ICs and SoC blocks. The defacto industry standard for audio ICs is I2S, an I2C-based bus optimised for audio data. Apple’s I2S controller has remained unchanged since M1. All of these audio ICs also need a stable clock source, which must be configurable to accommodate the wide variety of audio data rates. Apple’s Numerically Controlled Oscillator (NCO) has also remained unchanged since M1. Apple have also used the exact same speaker and headset amplifier chips in almost all Apple Silicon machines. So, when chaos_princess started adding speaker and headphone jack support to M3 machines, little more was required than some trivial Devicetree additions and config files for asahi-audio and speakersafetyd. As such, M3 machines now sport high-quality audio output on Asahi Linux!
M3 machines have also grown support for both CPU frequency switching and proper big.LITTLE task scheduling. Apple have not changed how CPU frequency switching works since the base M2, meaning that all M3 and M3 Pro/Max/Ultra SoCs required nothing more than Devicetree changes to work with our existing cpufreq driver. Tasks should now be more intelligently placed on either efficiency or performance cores according to their requirements, and the CPU cores themselves should clock up and down based on load. This will both save energy and improve performance!
Adding support for the SMC’s hardware sensors was similarly trivial; the SMC’s firmware is not materially different across machines, so once again nothing more than a few Devicetree changes was required here.
On top of the above, we also have PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, and other core SoC block drivers working in Linux for M3 series machines. Most of this work has come by way of Yureka, who has been very busy hacking on both m1n1 and Linux with her M3 series machines for a while now. We still have a ways to go before we can start enabling Asahi Installer support for these machines, but progress is rapid so watch this space!
Most of the complicated hardware on this platform uses complicated firmware blobs. Most of this is based on RTKit, an RTOS-like firmware framework used by Apple to present a mostly standardised interface for the kernel to talk to the various bits of hardware. There are exceptions to this, however. Some blocks, like DCP and AOP, use RTKit as the basis for their firmware, but layer yet another set of abstractions called EPIC on top of it. Others still, like the Broadcom WiFi/Bluetooth chipset, use third-party firmware that Apple has no direct control over. Then, there’s the Apple Video Decoder (AVD).
AVD is special. Its firmware is neither RTKit nor EPIC, it’s a secret third thing. The hardware itself is essentially an ARM Cortex-M3 controlling a series of fixed-function hardware units for decoding video frames encoded in AVC (H.264), HEVC (H.265), VP9, and AV1 on more recent SoCs. The CM3 runs a blob of firmware that exposes an interface for XNU to point it to video data, and then programs the actual decoder hardware itself. This would normally be fine, however Apple made the interesting choice of bundling both the AVD’s firmware and a pile of configuration data inside the AVD kext. Making matters worse, each SoC has a slightly different AVD variant. This is logistically challenging, as the Asahi Installer would have to constantly be updated with (and keep track of) Apple’s changes to the offsets of the firmware data in the kext. We could do this, but what if there’s a better way?
The firmware loaded by XNU is not verified by the CM3. It will begin executing from its reset vector when signalled, no matter what is actually there. What if we just… used our own firmware?
Since the firmware is effectively just there to abstract away the underlying video decoder hardware, it doesn’t actually matter what it does, so long as it installs interrupt handlers for the various hardware blocks. If we understand what the underlying hardware expects, we can just program it all from a Linux driver. To do this, we need to understand how the firmware drives each decoder.
Being standard Cortex-M3 code, it is possible to run the AVD firmware in an emulator. A number of solutions exist to do this, including QEMU, which allows you to single-step your program and inspect bus and register operations. The groundwork for this was laid many years ago by Jamie, R and Eileen, who through a combined effort managed to reverse engineer the instructions and data formats required by the AVC and VP9 decoders.
The XNU kext also applies a unique set of tunables to each AVD revision. We are not entirely certain what these do, so applying these essentially needs to be a replay of MMIO writes made by XNU. We need to keep track of each AVD revision, each set of tunables, and which revision they need to be applied to. This would be impossible to maintain satisfactorily in an upstream Linux kernel driver, so this should also probably live in firmware.
While not much work happened on this front for a long time, new contributor sofus recently stepped up to fill the gap. With a blob of custom AVD firmware that simply installs interrupt handlers and applies each variant’s set of tunables, he was able to write a working V4L2 driver for the AVC hardware! The hardware can decode 10-bit AVC-encoded video up to 4K, and works well with software that implements the V4L2 Request API. Keeping the firmware basic and stateless, with userspace and the kernel being responsible for parsing all video data and programming the decoders themselves, also enables us to more easily support other video acceleration APIs like VA-API and Vulkan Video at some point in the future.
There’s still some work to do before we can ship AVD support to users. AVD supports VP9, HEVC and even AV1 on some SoCs, but we have not implemented support for any of these yet. Some devices also have quirks that must be tested and accounted for in the driver. We hope to have something shippable for you all in the not too distant future!
We have also recently tagged version 1.6.0 of m1n1. This is a consequential release for distros, as it is the first version that requires Rust for stage 2 builds. Previously, m1n1 only made use of Rust when built with chainloading support. Stage 1 m1n1 replaces the XNU kernel in Apple’s boot tooling, and is used only to mount the EFI System Partition and chainload Stage 2 m1n1 from there. A little while ago however, we made the decision to move GPU initialisation into m1n1. This removed the need for the kernel driver to deal with the floating point numbers found in Apple’s hardware initialisation data, and also greatly simplified the Devicetree bindings. The version of the GPU driver we eventually submit to the Linux Kernel Mailing List will therefore rely on m1n1 to do this initialisation for it. We also ported the Apple Device Tree parsing code to Rust, which is consumed by just about every other part of m1n1.
Given that m1n1 is effectively firmware, it uses no_std Rust and targets aarch64-none-softfloat. To avoid pulling in superfluous dependencies, you can pass BUILDSTD=1 to make to build core and alloc without requiring a full softfloat toolchain to be installed.
Version 1.6.0 also brings a whole host of improvements to M3 series support, including support for the SPMI controller and PCIe initialisation. We also now support tunnelling the SoC’s hardware UART directly over DebugUSB with kisd, which can be used to achieve much the same functionality as the Central Scrutiniser. Much of this work is also courtesy of Yureka.
We are also laying the groundwork for M4 and A18 Pro (MacBook Neo) support, with better handling of Apple’s non-macOS boot mode and support for new power domain metadata found in the Apple Device Tree.
As always, we would like to thank our generous supporters on GitHub Sponsors and Open Collective, without whom we would not be able to continue working on unfinished M1 and M2 features or work on M3, M4 and A18 Pro support while supporting our enthusiastic new contributors!
James Calligeros · 2026-06-30
Torvalds often crosses that line into outright toxicity. I've written a few kernel patches that I never tried to upstream for that reason.
It’s easy to diss Apple alternatives and call them unrefined and all that, but to the right person, there are downsides to a Mac.
For example, the current MacBook Pro models with higher end chips prioritize quietness over heat and get very hot to the touch under heavy workloads.
Unless you are in music production, a little fan noise never hurt anyone, and the idea that windows laptops sound like hair dryers when doing basic tasks like browsing the web is very outdated.
Apple is revered for refinement and quality yet they get some basic ergonomics wrong like the sharp edges near your wrist and the notch blocking the menu bar.
That's not what you said. Their margins on software and hardware are irrelevant to what they, as a company, make most money off on — which was your original claim on which you are wrong and got called out on.
So annoying when people can't just admit they're wrong and instead gaslight people with their changed narrative.
As we saw recently, they decided they are, after all, a hardware company, since they decided not to slash their margins...
Then sometimes when I’m on the go I like to play a game or two, but nothing seriously requiring graphics power
SSD speed and RAM speed start mattering when memory pressure is high. And when doing stuff with video and photo editing.
The storage price is indeed steep and now the RAM price as well. I wish I hit the buy button when I had the chance before the price increase.
Standby time is likely also a major issue, unless Intel suddenly reversed course and decided to support proper sleep again.
Apple still pushes updates and security updates to OS versions which are not the latest. So I don't see how they can be blamed much here.
The big difference I see is in the chip. The PowerPC arguably had its benefits (vectorization) which made it super attractive for bioinformatics, etc., and a lot of that software was Linux-based. People could either buy a super-computer or a G4 (or a cluster of G4s) and get the work they needed done for a fraction of the cost. MacOS (and OSX) were behind on a lot of this stuff compared to Linux then.
Today from what I see the M3-M5 chips are a big leap forward compared to their competitors, and it just happened to hit at the same time LLMs became popular. I imagine there are some similar, specialized needs with the M[1-5] chips that might benefit from Linux but with OSX's stronger BSD underpinnings it's a different world.
Asahi founder is a community heavy with drama and loved to attack and brigade anyone that didn't immediately bow down and listen to demands of their team and social media entourage. This isn't how the most important OS in the world should be led and Torvalds was right to call out that toxic behaviour.
Regardless, to a newbie potential kernel contributor, that high level of toxicity can be intimidating, and the professional-programmers-only aspect is non-obvious, so it's easy to see why this would discourage hobbyists/free-time programmers from contributing.
Framework specifically has stated that they worked very hard to improve standby time and claim that it’s dramatically better. Being able to use LPDDR5x LP-CAMM2 modules aids in standby time significantly. We’ll find out soon when the first reviewers get their retail units in, probably within a month or so.
For standby time, my current framework 13 has never bothered me. It’s great that Macs have incredible standby but it’s much less of a dealbreaker than I originally thought it would be. I just have sleep to hibernate set up in Linux.
My system sleeps for 2 hours then hibernates afterward. If I am putting my system down for 2 hours I’m likely done using it for the day anyway.
I'm not sure it's fair to ding Framework specifically for not being able to make Linux battery life as good as Windows. Is that actually something they could reasonably fix?
You may have missed the "retroactively aborted" one.
https://lkml.org/lkml/2012/7/6/495
To be fair, he's got much more self-control now.
https://github.com/corollari/linusrants/blob/master/table.md
Someone who doesnt see a problem with this is probably one of those toxic people who dont realize they're toxic you mentioned. Nobody wants to be treated how Torvalds treated people.
Also, coming from an orchestral background, I'm well aware of situations where the leader needs to be gruff. A gentle conductor will never get the idiot violists playing in tune. (A harsh one won't either, but at least the violists will be too scared to make any noise.) That said, it's still unacceptable for a conductor to cross the line from gruff to personal attacks.
Just take the L, dude.
My understanding is that the reason why Linux still struggles in this front is that nobody has put in the hardware-specific optimization work to make it happen. There’s also some friction with how the bulk of Linux dev attention is paid to servers rather than portable consumer hardware.
> Nobody wants to be treated how Torvalds treated people.
Exactly, nobody wants but so many can't stop until treated.
> Stop this "we can break stuff" crap. Who maintains udev? Regressions are not acceptable. I'm not going to change the kernel because udev broke, f*ck it. Seriously. More projects need to realize that regressions are totally and utterly unacceptable. ... That just encourages those package maintainers to be shit maintainers. ... And stop blaming the kernel for user space breakage!...
Hate 0.832673044602
For common sense.
To clarify for you, “moving the goalposts” means that I changed my definitions over time. You’ll notice that in my comments I never changed my definition of what it means to have good battery life. I know sometimes turns of phrase are easy to misuse so I hope that helps you out.
There’s no winner or loser here. We’re just discussing technology. I’d appreciate if you tried to add conversation value rather than just dissing me personally.
Panther Lake is an impressive chip. The only MacBook Pro that can achieve 20+ hours of battery life at all with any setting is the 16” model that comes with the largest battery capacity allowed on a commercial airplane. It’s really not framework’s achievement, it’s the chip that’s so good, and that’s great for consumers because you can find a lot of competition on the market that has the coveted “all day battery life” without compromising on performance.
It’s really the achievement of the Panther Lake chips paired with LPDDR memory. If Framework is achieving 20 hours of video playback on windows that should mean Linux is still going to end up being more than respectable.
If we assume Linux is ~30% worse, that’s still a great result.