And even with all these advantages, my four month old Windows laptop fails to resume from hibernation 3 times out of 10. Sometimes wifi won't work, sometimes USB won't work, sometimes it just freezes.

Don't forget that "hibernating" a laptop with a lot of RAM might take long enough to run down your battery.

I think Hibernation has been impractical since 2013 or so.

It's basically impossible for hibernating a laptop to take more than about 5-6 minutes unless you deliberately configured it with insanely imbalanced components, ie. more RAM than mainstream laptop hardware platforms support, and the slowest storage you can find.

Could still be a problem if you are expecting hibernation to save you at 1% battery remaining.

Especially when 1% is displayed as 5% or 10%.

The monster laptop consumes more power because it has all of that RAM, the battery is sized to "not cause a crisis on an airplane if it burns up" not to power a machine of that type, particularly after a year of battery aging.

I have an Alienware that runs rings around any Mac and can do ML dev work with NVIDIA if it is on the plug but on battery I count on it to keep running as I move it to another plug and for the battery to maintain sleep mode for 48 hrs or so.

SSDs have also been getting pretty fast, though.

I don't have lots of RAM (but rather on the low side for present day), but hibernation takes maybe 15 seconds on a SATA SSD.

Hibernation was definitely a lot slower 10 years ago on a desktop with less RAM and a slow spinning disk.

Really? Hibernate has never taken more than 30 seconds for me even on a mediocre laptop with an HDD.

My bog-standard PCIe laptop SSD writes at 3GB/s, so anything over 10s seems like it is an implementation problem not a hardware limitation.

Strange. I never reboot, only use hibernation. I've been doing that for years and never had any problem.

You might want to share your setup then.

My HP Pavillon with windows hibernates reliable today, my very old netbook acer with Ubuntu/LXDE did so, too (but that was years ago).

Nowdays I gave up with linux laptops to even enable it, as it is quite complicated to set it up when you dual boot and use encryption. And after I did set it up, it failed over 50% of times on various devices so I did not bother anymore.

Same, the main instabilities come when I go out of hibernation with changed hardware, ie. haven't plugged back the mouse or changed the display from desk to meeting room

Also availability of drivers in Windows doesn't necessarily mean everything is comfy, certain manufacturers/BIOS vendors were notorious for not implementing ACPI correctly leading to several such issues; I hope with UEFI things have improved.

I’m wondering if a clever solution of presenting the Windows ABI to drivers but translating to Linux calls under the hood would be feasible?

It is, but the point of not defining a Linux ABI is to avoid proprietary, binary blob drivers and instead force drivers to exist in the upstream Linux kernel where they can be maintained by the kernel developers and freely distributed.

This has a lot of advantages of this approach over binary drivers in that:

- The driver can be updated so it survives architectural changes (say from x86 -> amd64 -> armv7 -> aarch64 -> riscv).

- The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries.

- Bugs in the drivers can be identified and fixed by anyone (most importantly, critical security bugs).

Also, good ABIs are hard to get right. Windows had to completely rewrite their audio subsystem and the associated driver interfaces around the time of Vista to get low-latency right, for example.

But that said, the use of binary blobs exists even today (CPU microcode, various driver firmware blobs that people don't have time to reverse engineer, etc.).

Someone else also mentioned ndiswrapper, which reimplements the binary interface for supporting Windows network drivers on Linux.

So you can pick any Windows driver interface and write a Linux kernel module or a combination of a kernel module and some userspace framework that can host and utilize that driver. You might have to emulate or paravirtualize some hardware access or instructions to avoid causing conflicts, but there's nothing technical stopping you, other than it just being hard. It can also never be included in the upstream Linux kernel for the ideological reasons I already mentioned.

"The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries."

Nice theory. It is just, that writing drivers is hard and not many people are capable of it. So for most existing driver issues, it will be much cheaper to buy new expensive hardware that might actually be somewhat supported for a while - than hiring someone to write a reliable open-source driver for it. (oh and of course, you also cannot buy the latest hardware as then there is mostly no support there yet)

I would love my whole system to be fully open source and working.

But since hardware is very closed anyway, I would rather have a couple more binary blobs on my system, that work reliable - instead of a bunch of open, but very faulty drivers. So I very much would prefer a stable Linux ABI.

Because without - I am forced to use Windows on my new Laptop, as everything runs much slower and buggier on linux - and I would like to use my laptop to work on other things - and not on the laptop itself.

There will never be a year of the Linux desktop if ideological purity (of a highly questionable ideology in the first place) continues to stay in the way of practicality. Grandma doesn't care if her network driver doesn't give her the whatever number of software freedoms as defined by RMS and honestly neither do I.

It's easy to criticize the chosen trade-offs, but I would argue that Linux would actually be in worse shape today if it had taken the driver ABI approach and encouraged proprietary drivers. Many drivers originally upstreamed in the 32-bit x86 era would no longer be usable on amd64 had they been 32-bit proprietary drivers, and a good number of 64-bit proprietary drivers would be useless on ARM platforms like the Raspberry Pi.

There are a lot of old computers in research laboratories running Windows XP because some proprietary driver for some important piece of equipment (like a mass spectrometer) doesn't have a 64-bit version.

None of the issues mentioned are about some theoretical ideological purity, they're all about very practical pragmatic concerns. There are a lot of open source software that put some ideological purity above all other concerns, but the Linux kernel is certainly not among them - if anything they're among the most "flexible" when it comes to GPL compliance.

If you really care about user experience, I recommend seeking out products made by companies that are vertically integrated, like Apple, because they have the power to curate the components of their products for maximum compatibility and support.

The closest examples so far with Linux are System76 and Purism:

https://system76.com/

https://puri.sm/products/librem-14/

This is also what makes the Surface tablets and Surface Book so great. There's a top to bottom alignment of interest in creating the best user experience and making sure the product works.

The closest thing to computing hell is when a commodity operating system is slapped onto the cheapest commodity hardware by someone who isn't concerned at all about using it, but has a list a mile long of systems to configure. There are plenty of enterprise IT-managed work laptops with no display or chipset drivers that can't hibernate, but at least they have McAfee virus scanner installed and the corporate group policy enabled.

That is what I thought when I decided to give money to Asus with 1215B pre-installed with Linux, I was wrong.

Grandma doesn't care about the year of Linux on the Desktop either because she probably just uses a macbook to manage the server farms that are running on Linux and won't need to hibernate.

Honestly how old is "grandma" in 2021? Grandma is probably 60-70 years old, and likely grew up in the "space age" of computers. She likely has a Facebook and uses an Android phone. Grandma should take some time to learn the Linux way, she'll be a better computer user for it.

Why should she? Grandma primarily uses Facebook, Instagram, and Facetime. Grandma doesn't have a goal to become a better computer user in general terms. Linux gives effectively 0 value to her over any other OS. And negative value in a number of various ways. Driver support among them.

At this point, I wonder if Grandma wants a desktop at all. Maybe Grandma just wants a tablet, perhaps with a keyboard. Tablet OSes don't really hibernate, but they use a lot less battery and have software designed to come back from a cold boot quickly.

I use my desktop OSes for my job, but could be perfectly happy with a Chromebook for most of what else I do in my life.

Or she doesn't care about computers and just wants to call her friends via Skype in a pandemic. Why would she care about becoming a better computer user?

Yes, your type of grandma exists, but I don't know her.

> she'll be a better computer user for it

Who (outside of HN readership) wants this?

Linux is tremendously successful. You want to enforce restriction on kernel developers because of "grandma", that's impractical.

Linux is tremendously successful as server OS. Desktop - not very much, because of "grandma"

On server and Android, and IoT. Sleep is enough for my laptop.

I hardly doubt you are kernel developer yet you "know better". Such people always do.

One doesn't have to be kernel developer to acknowledge the fact that Linux on desktop is not doing very well.

By the way, Linux did well on Android because it is made there with "grandma" in mind.

Kernel is one of the best parts about Linux on desktop. It works. I've recently tried Windows, annoyed by hibernate, few seconds to wake up but sleep is instantaneous.

Linux did well on Android because it does not suck. Mainline kernel boots hundred of models (postmarketOS). Another part mostly unchanged — browser. ChromeOS is Linux kernel and browser.

You've said hibernation is a matter ideological purity, no, it is a matter of practicality. You have to be kernel developer to understand practicality.

>> You've said hibernation is a matter ideological purity

I've never said that.

I think this conversation is going nowhere, no reason to continue it.

Sounds a lot like NDISwrapper.[1] God, that was a pain in the ass.

[1]https://en.wikipedia.org/wiki/NDISwrapper

I don't miss that. But it was better than the alternative at the time...

"Ok, there are at least three versions of the Linksco WG8211, all with different wireless chipsets. The box is identical except for the UPC sub-label - you want the one ending in -02. Some of the -01 boxes might work, but no guarantees, and the -03 definitely doesn't have support yet. You can't tell by the PCI ID, but if you poke this particular register, you can get the sub-version, which should tell you which chipset they're using - if they haven't changed it again."

Wireless cards on Linux, back in the early days of 802.11, were brutal to get working properly, mostly due to lack of drivers. The NDISwrapper was gross and sometimes hard to configure, but it also meant you had a snowball's chance in hell of getting a random wireless adapter working on Linux.

AMD tried something similar and the Kernel maintainers rejected the patch. At least that's how I understood it. I think this is a HN post about it: https://news.ycombinator.com/item?id=13142285