Each controller and subcomponent on the motherboard needs a driver that correctly puts it into low power and sleep states to get battery savings.
Most of those components are proprietary and don't use the standard drivers available in Linux kernel.
So someone needs to go and reverse engineer them, upstream the drivers and pray that Apple doesn't change them in next revision (which they did) or the whole process needs to start again.
In other words: get an actually Linux supported laptop for Linux.
One of my favorite machines was the MacBook Air 11 (2012). This was a pure Intel machine, except for a mediocre Broadcom wireless card. With a few udev rules, I squeezed out the same battery performance from Linux I got from OS X, down to a few minutes of advantage in favor of Linux. And all this despite Safari being a marvel of energy efficiency.
The problem with Linux performance on laptops boils down to i) no energy tweaks by default and ii) poor device drivers due to the lack of manufacturer cooperation. If you pick a machine with well supported hardware and you are diligent with some udev rules, which are quite trivial to write thanks to powertop suggestions, performance can be very good.
I am getting a bit more than 10 hours from a cheap ThinkPad E14 Gen7, with a 64 Wh battery, and light coding use. That's less than a MacBook Air, where I would be getting around 13-14 hours, but it's not bad at all. The difference comes mainly from the cheap screen that is more power consuming and ARMs superior efficiency when idling.
But I prefer not to trade the convenience and openness of x86_64 plus NixOS for a bit more battery range. IMHO, the gap is not sufficiently wide to make a big difference in most usage scenarios.
The need to tweak that deeply just to get “baseline” performance really stings, though, particularly if you’re not already accustomed to having to do that kind of thing.
It’d be a gargantuan project, but there should probably be some kind of centralized, cross-distro repository for power configuration profiles that allows users to rate them with their hardware. Once a profile has been sufficiently user-verified and is well rated, distro installers could then automatically fetch and install the profile as a post-install step, making for a much more seamless and less fiddly experience for users.
> 40% battery for 4hrs of real work is better than pretty much any linux supported laptop I've ever used
Not sure what "real work" is for you, but I regularly get more than 12 hours of battery life on an old Chromebook running a Linux and the usual IDEs/dev tooling (in a Crostini VM). All the drivers just work, sleep has no detectable battery drain. It's not a workstation by any means, but dual core Intel's are great for Python/Go/TypeScript
Out of curiosity, does Google contribute the drivers for Chromebook hardware to Linux upstream or do they keep it for themselves? Could it be that they just choose the hardware that works very well out of box with Linux?
I have no idea if there's upstreaming, but the Chomium OS repo is open source so you could check.
I don't know if that would help the wider Linux laptop community, because Chromebook OEMs can only select from a small list of CPU & chipset hardware combinations blessed by Google
What's the bar here? My Thinkpad X270 gets about 16 hours under Ubuntu with swaywm.
If we really want to get pedantic, its internal battery means the external pack is hot-swappable, so I can actually get several days on a "single charge." Good machine for camping trips.
Yes. The existence of a proprietary escape hatch is not evidence of goodwill.
> ThinkPads have a bunch throttling issues on non-windows OSs.
That is an ACPI issue. Intel Macbooks also exhibit this behavior on Linux and BSD, and it's not even close to how incomplete power management is on Asahi.
Yet. Plenty of people have with Intel ones - I’m one of them. My first experience with Linux was on a 2016 MBpro. And inevitably people will do the same with the silicon Macs, likely using Asahi it seems.
It's not inevitable. That's not what that word means.
Intel Macs supported Linux because they used Intel's Linux drivers and supported bog-standard UEFI. There are no preexisting drivers or DeviceTree files published by Apple for Linux. There is no UEFI implimentation, just a proprietary bootloader that can be updated post-hoc to deny booting into third-party OSes.
> Why are some of y'all so hostile to this idea?
I would love for Linux to support as many ARM devices as possible. Unfortunately, it requires continuous effort from the OEM to be viable. I've bought Qualcomm, Rockchip and Broadcom boards before, none of them have been supported for half as long as my x86 machines are. Nevermind how fast ARM architectures become obsolete.
It feels like Apple is really the only hostile party here, and they coincidentally decide whether or not you get to use third-party OSes.
It is inevitable. I guarantee you there will be people who run Linux on their silicon Macs. I don’t know how you could possibly hold a stance that no one ever will.
Apple is very hostile to it. It won’t stop everyone though. It’ll continue to be niche but it’s happening.
It's not inevitable. It's fragile. Go boot up your old iPad; that should be well-studied, right? We ought to know how to boot into Linux on an ARM machine that old, it's only fair.
Except, you can't. The bootloader is the same iBoot process that your Apple Silicon machine uses, with mitigations to prevent unsigned OSes or persistent coldboot. All the Cydia exploits in the world won't put Linux back on the menu for iPhone or iPad users. And the same thing could happen to your Mac with an OTA update.
It is entirely possible for Apple to lock down the devices further. There's no guarantee they won't.
Apple cannot lockdown the Mac. You can’t have a development machine that is incapable of running arbitrary code. Back when they still did WWDC live they said that software development was the biggest professional bloc of Mac users. I’m certain that these days development is the biggest driver of the expensive Macs. No one has ever made a decent argument as to why Apple would lock down the Mac that would also explain why they haven’t done it yet.
Passivity isn’t hostility. There isn’t any evidence that Apple is considering locking down the Mac. They could have easily done that with the transition to their own silicon but they didn’t despite the endless conspiracy theories.
Apple can lockdown the Mac. You might not think it is likely, but without UEFI there is no path of recourse if Apple decides to update iBoot. How do you launch Asahi if Apple quits reading the EFI from the secure partition?
> They could have easily done that with the transition to their own silicon
They already did, that's what my last comment just outlined. Macs do not ship with UEFI anymore, you are wholly at the mercy of a proprietary bootloader that can be changed at any time.
Again, why haven't they done it yet? It's because you cannot lock down a development platform. Yes, they could do it but it doesn't make any sense. You haven't articulated why they would do it only that they could.
Why people continue to think Apple will treat the Mac like the iPhone I have no idea. Will Microsoft take the same approach with Windows as they did with Xbox? Different product, different strategy.
> There is literally an apple-developed way to boot securely into alternative OSs
This is not a good thing! You do not want a proprietary bootloader as your only way to launch Linux, it's not a safe or permanent solution. Apple Silicon could have implemented UEFI like the previous Macs did, but Apple chose to lock users into a bootloader they controlled. This is markedly different from most ARM device bootloaders which aren't changed by an OTA update in another OS partition.
> if only apple is hostile
I did not say that at any point in my comment. Forgeties original claim was that Apple Silicon would eventually have support comparable to Intel Macbooks on Linux. I am telling them point-blank that it is impossible, because Apple and Intel have fundamentally different attitudes towards Linux.
> where is my Xbox/ps/switch/any random Android tablet/million other device's running Linux?
Your Switch and Android tablet is already running the Linux kernel. The past 2 generations of Xbox and PS chipsets have upstream support from AMD in the Linux kernel, so you really only need a working bootloader to get everything working.
Ironically, this does mean that the Nintendo Switch has more comprehensive Linux support than Apple Silicon does.
Sure, the kernel. But you surely know that android abstracts away the drivers, so without the proprietary drivers you are back to square zero - it's not "GNU/Linux".
Because the Apple laptops use exactly the same architecture and bootloader as iPads - if you think they're separate you don't know enough to be part of this debate.
That's an admirable goal, but, depending on the hardware, it can run into that pesky thing called reality.
It's getting very tiresome to hear complaints about things that don't work on Linux, only to find that they're trying to run it on hardware that's poorly supported, and that's something they could have figured out by doing a little research beforehand.
Sometimes old hardware just isn't going to be well-supported by any OS. (Though, of course, with Linux, older hardware is more likely to be supported than bleeding-edge kit.)
This is very true. I've been asked by lots of people "how do I start with Linux" and, despite being 99.9% Linux user for everything everyday, my advice was always:
1. Use VirtualBox. Seriously, it won't look cool, but it will 100% work after maybe 5 mins mucking around with installing guest additions. Also snapshots. Also no messing with WiFi drivers or graphics card drivers or such.
2. Get a used beaten down old Thinkpad that people on Reddit confirm to be working with Linux without any drivers. Then play there. If it breaks, reinstall.
3. If the above didn't make you yet disinterested, THEN dual boot.
Also, if you don't care about GUI, then use the best blessing Microsoft ever created - WSL, and look no further.
I've never gotten along too well with virtualization, but would second the ThinkPad idea, or something similar. Old/cheap machine for tinkering is a good way to ease in, and I think bare metal feels more friendly.
I'd probably recommend against dual booting, but I understand it's controversial. I like to equate it to having two computers, but having to fully power one off to do anything* on the other one. Torrents stop, music collection may be inaccessible depending on how you stored it, familiar programs may not be around anymore. I dual booted for a few years in the past and I found it miserable. People who expected me to reboot to play a game with them didn't seem to understand how big of an ask that really was. Eventually things boiled over and I took the Windows HDD out of that PC entirely. Much more peaceful. (Proton solves that particular issue these days also)
That being said, I've had at least two friends who had a dual boot due to my influence (pushing GNU/Linux) who ended up with some sort of broken Windows install later on and were happy to already have Ubuntu as an emergency backup to keep the machine usable.
*Too old might be a problem these days with major distros not having 32bit ISOs anymore
I went 100% bazzite back in April/May, no windows, and I couldn’t be happier. The pc I built is basically 90% gaming/movies/hanging with friends, 10% browser tasks. Very easy to live this life if you don’t have particular professional needs IMO. When I was doing more freelance editing this really would not have been an option as resolve studio does not work well on Linux.
I've tried this once for IntelliJ to work around slow WSL access for Git repos. Was greeted by missing fonts and broken scaling on the intro screen. Oops. But probably I was just unlucky, it might work well for most.
It's a common use-case for x86 machines that implement UEFI. Taking the iPhone and iPad into account, it is a nonexistent use-case for mobile ARM chipset owners.
I know you may have a particular axe to grind here, but Android devices are not a whole lot more likely to let you boot a vanilla linux distro. Apart from a handful of explicitly linux-compatible smartphones, the boot loaders tend to be pretty locked down, and the drivers all propietrary too
Apple does tons of optimizations for every component to improve battery life.
Asahi Linux, which is reverse engineered, doesn't have the resources to figure out each of those tricks, especially for undocumented proprietary hardware, so it's a "death by a thousand cuts" as each of the various components is always drawing a couple of milliwatts more than on macOS.
Exactly. This myth keeps being perpetuated, for some reason.
I'm typing this from a ThinkPad X1 Carbon Gen 13 running Void Linux, and UPower is reporting 99% battery with ~15h left. I do have TLP installed and running, which is supposed to help. Realistically, I won't get around 15h with my usage patterns, but I do get around 10-12 hours. It's a new laptop with a fresh battery, so that plays a big role as well.
This might not be as good as the battery life on a Macbook, but it's pretty acceptable to me. The upcoming Intel chips also promise to be more power efficient, which should help even more.
Eh it's pretty awful. I get 8 hours, yes, but in Linux, those 8 hours are ticking whether my laptop is sleeping in my bag or on my desk with the lid closed or I'm actively using it. 8 hours of active use is pretty good, but 8 hours in sleep is absolutely dreadful.
For optimal battery life you need to tweak the whole OS stack for the hardware. You need to make sure all the peripherals are set up right to go into the right idle states without causing user-visible latency on wake-up. (Note that often just one peripheral being out of tune here can mess up the whole system's power performance. Also the correct settings here depend on your software stack). You need to make sure that cpufreq and cpuidle governors work nicely with the particular foibles of your platform's CPUs. Ditto for the task scheduler. Then, ditto for a bunch of random userspace code (audio + rendering pipeline for example). The list goes on and on. This work gets done in Android and ChromeOS.
This doesn't match my experience. My previous three laptops (two AMD Lenovo Thinkpads, one Intel Sony VAIO) had essentially the same battery life running Linux as running Windows.
I also have an X13 Gen2 AMD. My idle power consumption is 2.5W to 4W depending on brightness. This ends up in 12h-15h (machine/battery ist 2y old I think).
Creating Daino Qt - a collection of components that makes Qt apps feel and look native on both Desktops and mobiles (each with its own set of challenges).
Developing Qt apps with C++ and QML is a blast - the fast performance of C++ and ease of use of writing UI in QML. But there is so much left to be desired with the built-in Qt Quick components - mobile issues like non native text handling, non native swipe-able stack view and much more. I’m aiming to bridge that gap.
It's still native (in terms of performance and ability to customize the look and feel) and working pretty well, it's just that not enough effort was put into making the built-in components behave and look like those on the platforms it runs.
What benchmarks are good these days? I generally just try different models on Cursor, but most of the open weight models aren't available there (Deepseak v3.2, Kimi K2 has some problems with formatting, and many others are missing) so I'd be curious to see some benchmarks - especially for non-web stuff (C++, Rust, etc).
I actually love that separation. QML is a great language for writing beautiful, responsive, modern UI with animations easily. C++ is great for performance and logic. I don't like Javascript but I don't need to write a whole lot of it. I wrote my note-taking app's block editor in QML and C++ if some people are curious[1].
Yeah, I appreciate the separation as well actually, even though I'm not a fan of the langauges involved (no issue with QML, dislike JS and C++). I've made a few things with Qt and despite my feelings on the languages, found it to be pretty useful and capable, and the learning curve wasn't that bad imo. I can't recall using much JS to be honest, but it's been a hot minute since I worked with that.
That said there's simplicity to Iced being pure rust managed through cargo that I enjoy. Though it should be said that my "learning curve" for Iced was much lower than it might be for others as I discovered it well after I'd adopted Elm (which inspired Iced) and - independently - Rust, so Iced was pretty easy for me to grok.
I don't think there's a right/wrong way there to be honest, both approaches have their pro's/con's, and my main issues with Iced vs Qt is largely a matter of maturity/prevalence than any specifics with the implementations/workflow themselves.
I gave Notes/Plume a try a year or so ago, it was an interesting experience. I ended up falling back to Joplin as I could use it on macOS, iOS, and Fedora with synchronization via Dropbox.
I've always been curious about productizing apps like these, from a financial/business perspective have you found Daino worthwhile or enough of a success (by your standards) to continue developing it as a proprietary application?
Hi! That put a smile on my face (: I'm working now on a mobile version with real-time sync, so maybe give it another try when it comes out.
Not really, not yet. Once my FOSS app was popular I used to earn a livable amount of money from ads on the website. But after a SEO crash that all went down the drain and the money I'm getting now from subscriptions to Daino Notes is nice but not livable. I've been working the last year (at a really awesome place) doing React programming (my first salary job, actually) and at nights and weekends working on Daino.
I actually got many requests to license Daino Notes' block editor. So I've figured there's a business there. I'm working on something I'm calling Daino Qt which is a collection of different components to accelerate Qt apps development (so I'm also its client). It will include my block editor, components for mobile - current Qt components on mobile are extremly shitty - so I'm planning on changing that with things like native-feeling swipeable stack view, native-feeling text editing, etc. And maybe Qt C++ client SDK for InstantDB (and more stuff).
Hope I can sell this as well while also consuming these components for Daino Notes and other apps I will develop.
Yes, my FOSS note-taking app[1] used to be pure Qt Widgets. Recently, I've added the Kanban feature that uses QML (this and the editor settings should be the only parts in QML, if I remember correctly).
reply