Hacker News Reader

> It's worrying how obscure and poor standards compliance modern hardware is starting to display.

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.

Taking one example... UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right. I don't have a solution to this problem to propose, other than to say, if you're in the position to influence specs that effect the design of hardware, or are the result of hardware design, please push for the simplest solution to the problem every chance you get. That said, huge amounts of complexity are added to things in the name of backwards compatibility, which is something we generally want.

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 can't disagree with you. But regarding backwards compatibility, the simpler the standard, the easer it is to write an implementation, the more practical it is to simply start fresh every iteration. Considering how cheap and disposable hardware is becoming these days, the more obvious is the false economy of flexibility in the design.

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.

> UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right.

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.

Is it a mess? The UEFI spec is big, but most of it is not necessary to boot.

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?)

> 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 dunno. I've worked with a bunch of different ARM chips and each one's workflow is "build a kernel, build an initrd, then use this magic tool to get our boot ROM to load it" and that's always been gross & dumb.

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.

Thanks to Flattened Device Trees, you don't have to build special per device kernels, you can just have a generic kernel that includes drivers for all the SoCs.

But having individual drivers per SoC in the kernel for things like power management still sucks.

It would be easier if the specs were developed without the "help" of organizations that stand to gain nothing from complete interoperability and who are perfectly content with "works with Windows".

Dell XPS 13. Comes with Linux and the new model is very quiet (fans don't even spin with most tasks).

Seconded. I have a 9360 and I've had everything work out of the box with Ubuntu 17.04, 17.10,and 18.04. As well as Linux Mint 18.3.

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.

This is third degree price discrimination by Dell. I should have been more precise in my first comment.

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"

With cheaper models you mean non-XPS-13 models?

non developper models

Thinkpads might not be as bad as you think. I have an X230 at home, which runs many flavors of linux extremely well and is dead silent, and a T440s at work which is also an excellent choice albeit slightly more expensive. You can pick up refurbished t440s'es for around 500-700 euros in the Netherlands, where X230's go for 200 at the very lowest price point (still with an ssd!).

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.

The T440 is no longer being manufactured (the current model is T480). I have a refurb T460 at home[aside] which works great out of the box with any Linux distro and has a keyboard that is a pleasure to use when contrasted with most laptops out there. And the repairability also means that you can buy a cheaper model and only once you need it extend the sdd/ram when you need it.

[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.

X1 Carbon 5th gen had some kinks at first but has been serving me well w/ Ubuntu for a year now. Managing the HiDPI display has been the only real headache -- if I could go back in time I'd have gotten the 1080p screen instead of the high res one.

Besides that when I say it works, I mean it really works. Even the 4g card I added worked out of box on Ubuntu!

Yeah, that's why I got the 1080p screen :) Learned my lesson with the 2nd gen - that was a piece of crap.

I own Xiaomi laptop you mention for almost a year now (2016 model). It is overall a pretty fantastical laptop, especially for the price. But be aware, that some models (mine as well) have coil whine issue (1), so it may not be completely silent. Also, BIOS is very limited, you can disable security boot, choose boot device and that's pretty much it. However, Linux runs perfectly without jumping through any hoops.

(1) https://techtablets.com/forum/topic/xiaomi-air-12-5-inch-mod...

Thanks for those comments about the Xiaomi 12.

What do you find lacking in the BIOS? Don't you use EFI instead?

Yes, by BIOS I mean the hardware setup utility you invoke before booting OS. It is very barebones compared to what ASUS offers in their laptops. There are no advanced settings such as configuring CPU features, timings, etc. It doesn't really bother me, since I don't tend to tinker with those settings. But I dislike the trend of locking down hardware.

> tend to be on the noisy side of things due to excessively small fans and too much power I don't need

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.

HP Spectre x360. I run Arch Linux on it and everything has been fantastic.

Dell XPS runs linux flawlessly. Dunno about wireless range though

Dell XPS uses almost the same wifi as the macbook stuff AFAIK - the fullmac broadcom chips.

Two years ago, I bought a ASUS ZENBOOK UX305FA and it is fanless and works well under Linux. Maybe there is some newer similar model.

I have everything working on my Lenovo T480 with Fedora Linux.