Hacker News Reader

Comment by theoutlander | Hacker News Reader

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.

View on HN

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.

Power states are much more complex than this.

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.

Perfect world and all that.

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.

   It is now safe to turn off your computer.

Indeed.

I think you meant:

It is now safe to burn.

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.

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".

https://www.usenix.org/legacy/events/hotos03/tech/full_paper...

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.

There's a storage vendor (hilariously for thread context) that took this to heart. They don't have a power button, just a switch. You turn it off.

I think it was Tintri?

I'm pretty sure Dell MD3200's are like that.

six

shutdown -r now + pull the power cable out of the wall when i see the bios screen.

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."

Wow. And I thought things were bad at my fortune 5. That is insane. You should seriously write a blog (or maybe a book?) about that.

Reply on news.ycombinator.com