Slashdot Mirror
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.
No one has managed to make it work reliably on Windows either. I don't think I've ever encountered a laptop on which Suspend wasn't either a game of Russian Roulette, or a guaranteed way to require a restart.
This half-assed reply from johnv-valve reminds me why I don't bother submitting issues for projects hosted on GitHub. I've seen that kind of useless reply, followed by an immediate closure of what's apparently a legitimate bug report, way too often within GitHub. While this can happen with other bug reporting systems, too, I think that there's something with the GitHub culture and mindset that really promotes such disrespectful handling of bugs. Maybe it's the total lack of accountability, coupled with the "social coding" concept. More traditional non-GitHub bug tracking systems were just about that: tracking bugs. But GitHub adds the "social" aspect to it, which ends up just being a way for the project leaders to go on power trips, which often involve treating mere users of the software like total shit.
But even disrespectful bug closures like that don't match up to the pathetic "code of conduct" controversy bullshit we saw recently. I've been involved with open source software development for a couple of decades. We didn't need bullshit "code of conducts" before this GitHub era, because our coding wasn't "social". We were writing open source software to solve real problems, or to make our lives easier. We weren't coding as a way to attract attention, or to see who had a bigger e-penis, or to treat others like shit just so we can feel like we have "power" over others. We just naturally treated one another with respect, so we didn't need some lengthy, goddamn list of rules governing each and every possible aspect of our social interactions! It's only now that the coding becomes secondary to the "social" that all this bullshit about "code of conducts" starts coming up, and it's really quite pathetic!
Suspend is a key feature, and energy costs more than ever. It's not acceptable not to suspend. Many people won't shut down, and if they can't suspend, they'll just leave the system on and turn off the display.
I hope they're at least using the lowest power states when at idle, and with a governor more intelligent than ondemand.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
This is a great example of how not to close a bug report.
Merely stating that the feature "is no longer supported" and closing the bug report without giving any further explanation is the wrong way of handling the situation.
If a user went to the trouble of submitting the ticket, then somebody associated with the project should at least put forth the small amount of effort it takes to explain why the bug is being closed without being properly resolved.
Providing some concrete information is just the sensible, courteous thing to do.
Uselessly vague "$FEATURE is no longer supported"-type replies do no good.
Giving a proper explanation for why a bug is being closed is not "handholding".
It's professionalism, plain and simple.
Being a programmer doesn't mean that one's incapable of providing a technical justification for closing a bug ticket.
It doesn't even matter if the person who logged the bug is a customer or not.
If the bug ticket is closed, then a complete, technical explanation of why is the minimum that should be expected.
The person who opened the ticket, and anyone else reading it, regardless of whether they are or aren't affiliated with the project in question, should be provided with a full explanation as to why the bug was closed.
This will typically be well over one sentence in length.
So if someone is closing a bug ticket and their justification is only one or two sentences long, then they should realize right away that what they're providing is completely insufficient.
I don't disagree that a reasonable, well adjusted person should do exactly what you said. But that's not the description of many software engineers, and reality is this sort of report is exactly the same thing that would happen internally in a lot of projects - and in fact it effects the project exactly ZERO to be this succinct; the only real issue is customer perception.
If you want politeness, make all public bug reports go through company representatives. That's in fact what nearly ALL large software companies already do. Stream has tried to model their development/bug reporting more along the lines of Mozilla, or, in the ultimate example the Linux kernel - have you ever read LKML? If this post made you butt-hurt the LKML will rip you a new hole...
If you want politeness, make all public bug reports go through company representatives.
I reject your implied proposition that engineers are incapable of being polite.
When all you have is a hammer, every problem starts to look like a thumb.
For all the nitpickers, what he said is true. Suspend saves the system state in RAM, which means NOT in CPU registers, GPU registers, nor a myriad other hardware controller registers on devices and hubs all over the system bus. The RAM is left in a low-power, self-refresh mode. Resuming from suspend means powering up all those devices, reinitializing their control registers, and getting everything back in sync with the state that the OS *thought* it was in according to the state stored in RAM.
This process involves coordinated effort of many different layers of hardware drivers to reinitialize each part and restore it to a working state. Some annoying hardware also lacks a simple "load state from bit sequence" function, and instead needs its own convoluted state-machine to be run through multiple steps in the right order to reestablish the state it had before suspending. This is where things usually go comically wrong.
Hibernate suffers all of this plus a bit more. It also has to reinitialize the disk controllers, read the saved system state from disk into RAM, and then perform all this same state-recovery that resume-from-suspend does.
Think of how we use video devices. Not just in Linux, in pretty much all current systems. In the name of "efficiency" we memory-map them, and we let the user process directly mess around with the internals of a hardware device.
This is the way a set-top video game box works, not a secure and reliable operating system.
Until the video is firewalled off from the user the way other components of the operating system are, it's not going to be safe, secure, or reliable. Obviously we'll need new hardware designs to make this work fast enough.
Bruce Perens.
So I guess I should make a comment about how superior Windows is because this is an article about Linux OS issues. Then I can be like all the Linux fan boys who just have to comment in Windows articles on how they never have such such issues because they are running a Linux based OS.
I've never have suspend or hibernation issues while running Windows based OS. In fact, it's crazy how fast resume works on my Lenovo Z50-75 running Windows 10. I don't even worry about privacy issues because I turned that stuff off. It's was easy to get the help I needed right from Windows forums on the correct settings.
Instead of all the thousand different yet same Distros. How about all the Linux geeks get together, focus on a handful of Distros and prove to us why it's superior to Windows? Because issues like suspend and the various graphic driver bugs will continue to keep it from wide spread usage. Like it or not, Linux based Distros make up 1.6% of the desktop OS and it's because of problems not because it's better. Microsoft has continued to up their game on the desktop and Linux Distros will have to match them if they every want a chance at taking over.
All that effort is better-spent making the OS start up and shut down quickly
No, it really isn't...
People who just want their computers to work also want their stuff to stay where it was when they closed their laptop. I know I do. I often have 5 to 10 programs open, sometimes 5 to 10 tabs open in a web browser.
When I turn off my notebook and turn it on a few hours later, I expect it all to be sitting there as I left it.
The problem for Windows is the same as it is for Linux - drivers. Making a driver which captures the state of complex hardware like a graphics or audio card and then restores it is very hard.
Maybe because not every SteamOS install is on a Dell Precision workstation??? Just sayin.