Kudos for reporting this publicly! We need this kind of stuff exposed publicly so that companies fix the issue and force an update. At the same time, consumers should be made aware of what security holes look like and what the risks are. Apple has been getting away with this stuff for a while now.
Do you think a hacker with ill-intent would have reported this issue at all?
I can relate to this. It was a common theme across Microsoft. In one instance, the team I was part of was responsible for the initial integration of Bing and Facebook. We had about 24 dedicated people on the team (a few partner/principal group managers too!). Our team was considered agile because we released most features every 4 months (this was around 2009 I think)!!!
Anyway, we had a hackathon at Facebook with Zuckerberg and the FB team. There were all these big (redundant) talks by every manager up that chain about how this is the most important integration, etc.
Guess what came out 4 months later??? A like button on the Bing home page! The kicker was that the code for the widget was picked from the facebook developers portal.
This isn't purely a software engineering mess though. The PC architecture for "off" is a mess at the hardware level too.
I mean, long ago you just had a physical switch on the power supply. But then filesystem authors invented buffering and that wasn't safe anymore. So now there were two ways to shut the machine off: the "safe" way and the old way (where the "old" way was still available via e.g. holding the power button down for 4 seconds).
Then, we wanted to start using laptops and carrying them around. But booting the whole computer again and again every time you changed your seat became a chore, so software people invented this cool new trick where you could dump memory to disk and restore it later, so "hibernation" was born and we now had three ways to shut down.
Then the hardware people jumped in and pointed out that really the problem here is just the CPU. DRAM refresh is cheap, so there's really no need to dump the RAM at all. Let's just shut the CPU off and come up with a hardware/firmware/OS/driver hack (yeah, it touches basically everything) for powering on into a known DRAM configuration. Much faster! And now we had a fourth way to shut down.
(OK, this is a little spun. In fact suspend to disk and suspend to RAM landed nearly simultaneously in the PC world, with different manufacturers picking different horses. Then of course ACPI came in and standardized both, forever locking us into not one but two kinds of suspend.)
Then of course, we had a paradigm shift where "mobile" OSes revisted this whole scheme and threw it out the window. The hardware people making mobile chips designed the clock and power gating logic such that the "suspend to RAM" happens essentially every time the CPU reaches an idle state, and never has to be "entered" explicitly the way ACPI S3 is. And now PCs are shipping with this scheme too even on systems where ACPI still works in a traditional way. So, yeah. FIVE.
I mean, Microsoft surely made a UI mess out of this. But it's not like they were handed a simple problem to begin with.
In reality, CPUs and SoCs have multiple levels of sleep, some of which are standardized for a platform. ACPI at least tries to specify what should happen on x86/x64 systems. ARM has some standards, and then each SoC implements a lot of their own, which, to be fair, are sometimes really cool.
For lots of the power saving modes, hardware drivers have to opt in. This is where a lot of problems happen, if a single driver doesn't work, a laptop won't go to sleep, and the battery dies. Or, on mobile, a single bug in some component (which may manifest itself only under certain situations, which is why a reset can fix some problems) can prevent a good sleep state from being entered.
Of course software can also present problems. For the longest time, if WebGL content was loaded in any tab in, I think FF (either that or Chrome, heh), then the GPU would stay on and the system would never go to sleep.
Fun stuff like that.
The behavior people really want is "turns on quickly, uses little battery." That is harder to do on PC due to legacy, but part of the problem is also different usage patterns from mobile. Users check their mobile frequently, if something is draining the battery, odds are it'll be noticed in a couple hours and the phone will get a charge (and some apps potentially force killed, based on how knowledgeable the user is.) Laptops have less periodic usage patterns, so a single problem program may not get noticed before the battery is completely dead.
Sure, but the interfaces are more or less as described, and that's what MS has to deal with. I mean, yeah, you could make it into even more of a messy description, but from the start menu's perspective the PMIC or EC interface to power management isn't particularly important.
> Sure, but the interfaces are more or less as described, and that's what MS has to deal with. I mean, yeah, you could make it into even more of a messy description, but from the start menu's perspective the PMIC or EC interface to power management isn't particularly important.
Now days, the majority use case is "shut the lid". If software works (hah!), then users shouldn't ever have to manually shutdown or reboot, or worry about power state at all.
If I don't like what a computer is doing, I will frequently just yank the plug, pull the battery, flip the circuit breaker, and fuck the rest.
All this buffering and fault tolerance is bullshit at the consumer level. If the disk's file table gets fucked up, then let it burn.
I'll format the disk and re-install your stupid operating system as I see fit, whenever I want, and keep my actual data safe and sound far away from someone else's stupid hung process, until it produces actual results that I can copy into place, whenever appropriate.
These are lessons I learned throughout the late 90's, in the face of countless blue screens, before migrating to linux.
There was a nice paper a while back on the topic of 'crash-only systems'. That is, the idea would be that no software system was permitted to have a dignified shutdown path at all. Every system would be turned off with the equivalent of the power switch or "kill -9".
The point that was made was that frequently the recovery paths were on net faster (for a shutdown/reboot cycle) than the "durpee dur, I am slowly shutting myself down paths" and that you have to build a good crash recovery path anyhow.
I remember working at a rather large company (that you've heard of) in the 90s. It was a guy's sole job to reboot all the NT server every night for stability.
A common practice (I believe from MS) was to have C: dedicated to your OS and D: dedicated to everything else. The logic being: a rebuild would be a lot less complicated.
Ah the good ole days.
FWIW, I usually do a complete Windows reinstall every 6 months or so.
I worked as a lawyer on a Microsoft acquisition once. We had once a week 40-person conference calls for status updates. The company being acquired had a total of 9 employees I think.
The calls were scheduled for an hour. But, with 40 people on the line, the calls always ran late. At least 4 of the people of that call were billing $400+ / hr.
Most of the things I had to present during the call could have been resolved with a quick email to the relevant party that said "Hey, this looks funny. Do you care about this?" But the person running the entire thing insisted that I prepare Powerpoint slides for the meeting. And after I showed off my slides and everyone on the call had a chance to ask questions and discuss, the conclusion was almost invariably, "No, we don't really care about that."
I'm glad that I've blatantly ignored all the frameworks that have come and gone over the years. I still know what these frameworks are and their capabilities.
Frameworks like polymer are nice because they will eventually will fade out. I think that was the idea with TypeScript as well, but I think MS deviated.
What we should encourage are unopinionated but comprehensive libraries that simplify tasks just as the author mentioned.
Just trying to wrap my head around what you're saying. Are you in favor of this because it can also cover you from legal scrutiny for mistakes made while providing care?
Patients expect and deserve their medical privacy, which would get violated when a police camera records them receiving treatment. He is in favor because patient's private medical records shouldn't be automatically made part of the public record just because a cop walks in the room.
I was the sysadmin for a small medical practice for a while. Patient privacy was the one reason I was (and remain) dead se against storing practice medical records on the cloud.
If anything every got out, I would have been liable. I fully accepted that. But I had full control.
If anything stored in the cloud ever got out, I still would have been liable, but I wouldn't have had any control. For sure, the cloud storage provider would have disclaimed liability and I'd still be the man on the spot.
You are making all sorts of assumptions when the views of others were clearly expressed in previous comments. You seem hell bent on your own talking point regardless of that the actual comment's point was. Either you are being dense or you are trolling...
Agreed, but I like the simplicity when starting out since there's just so much. I'm reading Peter Norton's Assembly programming book from '87 to keep things super simple.
Do you think a hacker with ill-intent would have reported this issue at all?