No Stupid Questions
No such thing. Ask away!
!nostupidquestions is a community dedicated to being helpful and answering each others' questions on various topics.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules (interactive)
Rule 1- All posts must be legitimate questions. All post titles must include a question.
All posts must be legitimate questions, and all post titles must include a question. Questions that are joke or trolling questions, memes, song lyrics as title, etc. are not allowed here. See Rule 6 for all exceptions.
Rule 2- Your question subject cannot be illegal or NSFW material.
Your question subject cannot be illegal or NSFW material. You will be warned first, banned second.
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Questions which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding META posts and joke questions.
Provided it is about the community itself, you may post non-question posts using the [META] tag on your post title.
On fridays, you are allowed to post meme and troll questions, on the condition that it's in text format only, and conforms with our other rules. These posts MUST include the [NSQ Friday] tag in their title.
If you post a serious question on friday and are looking only for legitimate answers, then please include the [Serious] tag on your post. Irrelevant replies will then be removed by moderators.
Rule 7- You can't intentionally annoy, mock, or harass other members.
If you intentionally annoy, mock, harass, or discriminate against any individual member, you will be removed.
Likewise, if you are a member, sympathiser or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people, and you were provably vocal about your hate, then you will be banned on sight.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- Majority of bots aren't allowed to participate here.
Credits
Our breathtaking icon was bestowed upon us by @Cevilia!
The greatest banner of all time: by @TheOneWithTheHair!
view the rest of the comments
Actually, they do, it's called the "S0" low power state, and it's part of the ACPI standard. Microsoft calls this "Modern Standby" in Windows (and "suspend to idle" in Linux) , and it's pitched to do exactly what you've described.
The only problem is, the implementation sucks. Most users actually hate the S0 state because it consumes so much power - on some laptops, even the fans may continue to run on S0, and your laptop may overheat if you've closed the lid and chucked it in a bag, and it's in the S0 state.
Also, because Microsoft and Intel have been pushing this so much, the "standby" mode now defaults to S0 instead of S3 (which is full suspend-to-RAM). So many users actually actively seek to disable S0 and go back to proper S3 standby, via registry hacks etc.
So why is S0 so bad? Part of this is due to the limitations, long history and the variable nature of the x86 platform. All the power-saving stuff was implemented as an after-thought - both at the hardware and software levels. Whereas ARM, at least the modern ARM ecosystem, was developed with mobile usage and power saving from ground up. An x86 PC is also made up of components from disjointed manufacturers, and we need all those components to implement the same standards so that it all works well as expected. So for instance, if a particular component isn't capable of entering a low-power or active standby state, then it won't - and you can't do much about that, unless you're Apple and have a tight control over the ecosystem.
The second half of the problem comes with the software. All applications must be modern standby / S0 aware, if not, one of two things will happen: that app will keep the system awake, or the app will get suspended by the Desktop Activity Moderator (DAM). Either way, the app must be capable of running in the DRIPS phase (deepest idle runtime platform state), which rules out most Win32 apps (basically almost every app that's not on the Microsoft Store).
Finally, the reality is that most PC users don't care about modern standby regardless - and why should they, when they've all got smartphones, which handles notifications well? Also, hardly anyone does large file downloads these days, and the people who do still download, wouldn't care about doing it while on battery (and if they do, they can take manual actions to lower the power consumption, such as switching to a power saving plan and turning off the display etc).
Ultimately, most people would expect a laptop to go into a fully suspended state when the lid so closed and they're on battery, because if they're on battery the #1 concern for them would be the battery life. So most people actively seek to disable S0 and see it as a hindrance.
Thanks for the excellent response.
I wonder if Valve will try to implement it in Steam OS for the Steam Deck's successor, as a lot of people complained about the lack of downloading while asleep after the Deck was launched. It would still need cooperation in hardware I assume, but they were able to get resuming games working, so it doesn't seem like an insurmountable problem if there is enough desire from both gamers and Valve.
I don't think this would need to wait for a successor. The problems are software, not hardware. They would need to have games and SteamUI get suspended but leave other processes running, might be tricky and prone to bugs.
Of course hardware is part of the problem too.
PC architecture does not allow, for example, that the network interface may feed any data directly to the harddisk. Every bit and byte must be input to the CPU and then output from there.
Otherwise we could allow the CPU some real good sleep while other devices remain a little active.
Isn't this the idea of having a chipset (Northbridge/Southbridge) on the board, to handle some of these IO tasks?
Also, I recently saw the Cathode Ray Dude video on Dell's Brain Slug, where down basically hijacked the system with a low-power ARM SBC. I almost wonder if something like this would be possible, it would obviously require a revision but it would theoretically allow for suspended downloads, invite notifications, etc. It would also be fairly expensive and complex though
Well, not in the way we are talking here. The bridges work under the CPU's direct commands. When the CPU goes to sleep, they have nothing to do either.
Maybe a PC's CPU can do some short time limited sleep like microcontrollers do, and maybe that would be useful for such scenario's. But even then the main problem remains that the CPU wants to be in control of everything.
Very much this; I've got a whole army of machines I can SSH into to launch a long-running download, which frequently additionaly cuts out a 2nd step of copying the file to where it needs to be after downloading it (a action which would normally cause additional battery usage on the laptop).
And I thoroughly agree with you; I want the laptop to go to S3 sleep immediately when I shut the lid, and then pull it out of my bag a hours later with only a couple of percent of the battery consumed in the interim.
Thankyou for answering some historical mysteries for me. It has always irritated me that I didn't know why programs only sometimes drained battery while asleep - but it wasn't always like that, and I couldn't find a pattern in what programs affected it, and I didn't know why a Linux dual-boot on the same drive didn't cause the same issue. The backstory of this makes a whole lot of experiences make sense now.
What is involved in an app being S0 aware and running on DRIPS? Is this a badly-educated-developers-requiring-permanent-network-connections issue or a Microsoft-proprietary-certificate-bullshit thing or something completely different? I'm mostly curious for if I ever dive into desktop application development what performance optimisations I should be keeping in the back of my mind.
I haven't developed a desktop app in ages so I'm probably not the best person to ask this, but my understanding is that if you develop a modern UWP app, then it's automatically S0 aware, but you can also make use of WinRT APIs to execute background tasks during modern standby. The user can also choose whether or not to allow this activity.
I'm not sure if the WinRT APIs can be called from a regular Win32 app though. For Win32 apps, as far as I'm aware, they should get suspended by the DAM automatically (and background services may get throttled), but Windows may choose to unsuspend/unthrottle these apps if it thinks some critical activities are happening. I never looked into what it deems as a "critical activity". Personally though I always disable S0 so that my laptop suspends as you'd expect it to.
Bottomline is, if you're making a UWP app it should all just automatically work, maybe look into the WinRT APIs, and if you're making a Win32 app you need to look more into the DAM. There's some info on that here: https://learn.microsoft.com/en-us/windows/win32/w8cookbook/desktop-activity-moderator
Thanks so much, this is extremely helpful. I've been separate from the entire Windows ecosystem for a long while, so a high level overview like this is perfect. I now have all the acronyms and names I need to research further instead of trying to figure out what acronym is responsible for what, which is always the most tedious part.
Very informative- thank you