In 2012 I bought a MacBook Air to run Linux. It's a great silent machine with all Intel hardware, except the pretty poor quality Broadcom wireless card. It boots with any vanilla kernel, and everything just works. Except for poor wireless range. What machine can I buy these days that?
i) Just works on Linux (which in practice means everything has to be Intel, including the wireless card)
ii) Is reasonably silent
The only machine I've found worth considering is a Xiaomi Air 12 with a m3 (fanless) CPU. Some Thinkpads are OK, but they tend to be on the noisy side of things due to excessively small fans and too much power I don't need. This, despite aggressively tweaking powertop settings.
I'm also looking for external USB high-gain wireless antennas. But even classic Alfa ones with Atheros 9271 chipsets are a hit and miss.
It's a bit hopeless. If someone has good suggestions, I'd be glad to consider them.
The standards are too complex. I've spent thousands of dollars on ISO standards documents over the past several years.[1] The complexity of these documents is absurd. And I've never seen an implementation that came close to adhering to the entirety of the standard--everybody always takes shortcuts because it's not cost-effective otherwise. The problem is, everybody takes different shortcuts, so you end up with endless interoperability problems.
The exceptions are often when everybody sources hardware or software implementations from a single vendor. That's when things go more smoothly because everybody is using the same half-baked driver or firmware.
[1] The last document I purchased was 138CHF (coincidentally $138USD at today's exchange rate). They've always been at least that much in recent memory, and often standards are broken up into separate documents or incorporated by reference so you're paying 4x or 5x to get the entire standard. There's alot of free documentation online that open source developers often use, but personally I find it difficult to wrap my head around these things unless I have an idea of the overall design. (I want to see the overall picture so my initial API and architecture isn't a pile of technical debt from day 1.) I have the means so I bite the bullet. But it's a real loss to the entire community--and industry--that these standards aren't freely available. Quality of implementations would be so much better if standards were always open, and sunlight might help minimize the complexity of these things by exposing the flexibility demanded by proprietary vendors on the committees as useless barriers to entry.
In the case of the S3 sleep state, this is just sloppy decision making. Sure give us a new fancy, half sleep-like mode, but don't touch the suspend to ram, it's a feature that has value.
I don't do much traditional driver development (mostly USB related, at least when it comes to hardware). I know enough that dealing with the ARM ecosystem can be much more of a headache than in the PC world, for two reasons: diversity and more opaque specs. (Even if the PC stuff is proprietary, there's enough publicly leaked info to at least get started.) But ARM features are also often much simpler and straight-forward. If the documentation were always and completely freely available[1], then I think many developers would prefer dealing with ARM platforms than with PCs. You may be writing more drivers, but development would be more efficient and reliable and you could move on without having as much of a maintenance and bug-fix burden. It can be a worthwhile trade-off, and fits better with the open source model.
[1] I spent months trying to sign an NDA and gain access to NXP's iMX53 Security Reference Manual. After repeated back-and-forth with two NXP resellers, Mouser and Digi-Key, I just gave up.[2] I've heard of lone developers getting access to the manual, but they must be more familiar with the process than I am. Now I'm pivoting and have decided to use seL4 on PC hardware rather than bother with the TrustZone and the iMX53 crypto hardware, even though the ARM route would have been easier but for the documentation issue.
[2] I think it's NXP that kept dropping the ball, but I'm really not sure.
The culprit isn't UEFI, it's ACPI. That mess predates UEFI. Most operating systems don't really try to use UEFI features beyond the ability to manipulate the bootloader settings, and that feature is almost always correctly implemented. But it's impossible to find a consumer system with bug-free ACPI tables.
The UEFI implementation in U-Boot is tiny, and yet is enough to boot (both from local storage and network) and have a text console.
Most non-embedded board vendors do not reimplement UEFI. There's not much to get right or wrong. They just take AMI or whoever's private fork of TianoCore, tweak some settings and customize the GUI. (It is possible to screw up the GUI though: https://youtu.be/F-ndTMeRT3s)
As mentioned in other comments, it's ACPI that's really bad.
Though at least it's a standard! On ARM, you typically have to have a driver for every. damn. power. controller. Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?)
I can't believe anyone would be thankful about ACPI. Is there a machine with ACPI that isn't broken in some way? My brand new Lenovo, which multiple sites have crowned the "best" PC laptop, ships with a LTE card that can't properly power down, and causes PCI-E ASPM to be disabled. Even Microsoft has f--ked up power management repeatedly in the Surface line.
Power management on PCs is such a disaster that it calls into question the very idea of doing power management for computers built out of mix-and-match components through standards like ACPI.
I'm not necessarily cheery about ACPI in practice, but ACPI & UEFI in theory provide some kind of substrate to manage the platform, that's not just whatever the engineers are some shop cooked up this time.
But having individual drivers per SoC in the kernel for things like power management still sucks.
Only downsides are Linux's generally patchy support for hidpi, some programs scale and others don't (opt for 1080p version or set resolution to 1080p). And also the placement of the webcam is a bit strange.
Battery life is good in Ubuntu, between 6 and 10 hours depending on use case.
To be crystal clear: the 9360 has a bios featuring the proper ACPI tables, which are omitted on purpose from other cheaper models, breaking S3 on purpose.
This is why injecting proper tables as proposed in this link restores normal functionality. It is not rocket science, just hard enough to do without proper documentation to be a waste of time.
The initial submission title said it was a shame, and I agree it is shameful to intentionally break features to charge higher price (and no, I won't buy that S0 works perfectly now, or that adding a simple if/else is "too complicated"
Unless I'm playing Counter Strike on the X230, which runs great all things considered, I never ever hear the fan. Wireless and thankfully wired connections are spotless too, though the X230 doesn't have 802.11ac as far as I know.
[aside]: it has a top IO panel that every now an then decides to stop working, including the power button mouse and keyboard, although usb ports continue to work. The only option at that point is to hard reset (I carry a paper clip in my keychain :-/). Haven't found an explanation for the problem. If anyone here has any ideas, please reply. I've googled all around. I have found no correlation with anything so far.
Besides that when I say it works, I mean it really works. Even the 4g card I added worked out of box on Ubuntu!
(1) https://techtablets.com/forum/topic/xiaomi-air-12-5-inch-mod...
What do you find lacking in the BIOS? Don't you use EFI instead?
Huh. My X240 is so much quieter than my 2010 MacBook Air was.
The Air was... (I just realized this) very aptly named, as the volume of air its fans push is ridiculous.
So there was no reason whatsoever to remove the code.
IIRC, suspend to disk when battery runs out is now one of the standard S0 features.
At the OS level (windows 10) there is a telemetry to check the depletion rate, and initiate suspend to disk when the rate is too high or battery is too low.
Check the logs made by microsoft powercfg, they are very informative and will help you reach power savings close to what S3 allowed.
But I need that to work in Linux too, and last time I checked it wasn't as good.
Nitpick: "Telemetry" means "measurement far away". Does this get sent to microsoft ("tele") or is it just a measurement ("metric")?
I have done some bios and acpi code before on coreboot. It is tough, lots of work and no guaranteed results if you don't have access to the specs (NDA)
Anyway I really don't recommend you do that unless you have experience, documentation and time.
Worst case is they left the stubs pretending S3 is supported, so the computer goes to sleep - but never wakes up! Dell, I'm looking at you!!
Workarounds come from redoing the S3 code, mostly in ACPI tables with triggers - for all peripherals.
It is a shame, as in S3 most laptops eat less that 1% of the battery per hour, while in S0 such good results require heavy configuration to prevent the "active" part of active sleep, and make sure the laptop never wakes up until you actually press on the power button. But I guess it is the road to progress, as S0 is more flexible.