SteamOS Has Dropped Support For Suspend
jones_supa writes: As pointed out by a Redditor, it seems that suspending the machine is not officially supported by SteamOS anymore. A SteamOS user opened a bug report due to his controllers being unresponsive after a suspend cycle. To this, a Valve engineer bluntly reported that "suspend is no longer supported". He further explained the issue by saying that given the state of hardware and software support throughout the graphics stack on Linux, the team didn't think that they could make the feature work reliably.
I am a supporter and committer; my name is on a couple of files in the Linux source. If you're saying that doesn't make me a True Scotsman, then so be it. Why would Linux be a good choice if suspending is a coin flip? Because I don't suspend servers or a handful of other devices Linux supports. I'll stop supporting Linux when < 95% of what I want to do just works perfectly fine and Java is a first class citizen on Windows or BSD; I'll also need Python, Ruby and Perl to be painless to install and run. I'll switch my file server to BSD, like my router/firewall, when it offers me something over Slackware. Also, there's the issue of a few hundred Linux servers, VMs and appliances we have all over the world in my work life.
I accept the suspend thing on my Fedora/Linux Mint dual boot because it's my secondary desktop that I have Steam installed in Linux Mint for gaming and my backup development environment/testing/VM setup on. I boot between the two of those enough that I don't hibernate often. I'll suspend to RAM if I'm going back to what I'm doing within the day, otherwise I just shutdown.
For me, bottom line, the things Linux gets wrong are mostly annoyances and on the whole the OS makes my life better. YMMV of course, but for my use cases the good vastly outweighs the bad. I'll agree though that some of the bad is pretty darn ugly; I'm in complete agreement that SystemD is crap. I want to kill that part of the stack with fire.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
The swap file is only virtual memory. Both Linux and Windows have a separate file for hibernation. In Windows it's hibernate.sys. If the swap file was in use and then the OS used it again to hold the dumped contents of RAM when hibernating, the existing swap data would be lost. Don't think of swap as a replaceable cache, think of it as slow RAM. It holds real data. Also, Windows has a hybrid Suspend To Disk feature which does a normal Sleep/Suspend then hibernates after some specified time (I've never seen Linux do that. Can it?).
I'm really annoyed at the other ACs that responded to your post. They took the time to rudely point out you were wrong but didn't go the extra tiny step to explain why. You don't appear to know the basics of modern OS architecture, so maybe what went around came around?
its not necessarily the ACPI, its the manufacturers implementation of it and their need to bodge it to make sure it works on windows.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Bug tracking system exist to organize and track the bug finding and fixing process, not as a historical record or some kind of documentation. If you are not going to fix it, you close it. If you don't, soon enough you might find yourself swimming in unfixable problems just to find some work you can actually do. For a bug tracking system, "we don't support this any longer" is explanation enough. Why doesn't it work? Not our problem. What else do you want? Shit happens...
I've been running Linux on my desktop for 10+ years and the only driver issues I've ever had were solved by ditching Nouveau and using Nvidia's own drivers.
And yes, I have to reinstall them following a kernel update:
~> uptime
12:09pm up 98 days 23:53, 8 users, load average: 1.14, 1.13, 1.14
*That* is how long it has been since the last time I had to do this.
And it takes about 30 seconds to run the installer script and restart the desktop. I could automate it, but given that I only need to do this 2-3 times a year, it doesn't really seem worth the trouble.
When I ran Windows, I'd spend hours just *looking* for drivers (and hoping they wouldn't hose my system).
I bought a 64-bit laptop a few years ago which came with 32-bit Windows 7, and on which I tried to install 64-bit Win7, only to discover after searching for 2-3 days that there were *no* 64-bit Windows drivers for the wifi or graphics cards and there was *no way to obtain them*. Installed 64-bit Linux on it instead. 30 minutes after I put the CD in the drive, I had a fully working laptop.
BTW, I use OpenSUSE. It's been passing the Zontar Challenge for better than a decade. :)
Il n'y a pas de Planet B.