I couldn't make it through an episode of that show. I can suspend disbelief but this show was just too far. I think the "server farm" that was obviously a self storage facility was the final straw.

Even with a smart meter being read every 15 minutes it seems kinds difficult to get anything useful out, since the power company is getting a kWH number for the last polling interval. It sounds like they are "listening" for a certain pattern in the on/off of this extra CPU. So while your kWH number might go up, it would be pretty impossible to compare a building's overall load and have one core of a CPU actually make enough difference to do anything about it.

The attacker needs to gain access to the server's power cord, or maybe the building's power panel then attach some dongle. Then they need to somehow gain access to a air gapped machine on a secure network in what is likely a secured facility. Once they do that, they then gain access to the server and install malware that will send semaphores by upping CPU use.

While an interesting laboratory experiment, I'm not really all that concerned. I do predict it showing up in the next Mission: Impossible installment, though

I was really hoping they would have taken 32-bit out behind the barn and ended it with Windows 10, but they didn't. My company dropped support for 32-bit Windows a few years ago. Even with PAE and other tricks it was consuming an inordinate amount of people's time and resources in terms of regular build failures due to resource limitations, and our customers had largely moved on since the work they used our software for would rapidly exhaust win32's limits, anyway. Microsoft introduced a 64-bit variant for Itanium in 2001 and a 64-bit XP/Server 2003 x86_64 variant in 2005. Drivers were a bit patchy to find, but by the time Vista came around and certainly 7, 64-bit on Windows was just fine. So at this point we are well into a decade past Vista ... please kill 32-bit Windows ... please. Set up a memory garden and build a monument to it in Redmond ... but dear God let it become a happy memory.

My employer has installed chargers, free for any employee to use. We have a lot of Leafs and Volts on campus because they are actually in the realm of "affordable", and even more so on the used market. I've got a kid who is going to be a teenager soon, I'd consider picking up a Leaf in a few years for commuting. We'd likely have a "family car/SUV" that my wife uses and for long trips, we'll have a paid-for Volt the that will be 8-9 years old by the time the kid starts driving, and I could pick up a Leaf cheap and use it for the commute. Might have to run some additional electric service to the garage as I'd want the 240V for the Leaf (120V is acceptable for the Volt), but that's a one time cost.

I am privy to new features, bugs, big initiatives/deliverables, ship dates, financial data, methodologies, long term vision, etc at my company. Management is very clear this kind of stuff is confidential until the official software is released, or should never be released since it is considered proprietary, confidential, or may slip a release if the project doesn't work out for some reason. It happens. We do share certain information with partners, big customers, etc, but all under NDA and with similar disclaimers (e.g. "this is planned for this release but it is never guaranteed").

If I decided to blab this stuff somehow I would 100% expect to be fired if I was found out. I can read and comprehend the "CONFIDENTIAL -- DO NOT RELEASE" thing that's on all documents and presentations like this.

No problem, there's a lot of nitpicking and caveats with this stuff. I do have a Volt so I looked into this a lot when I bought it ... it's been a very nice experience skipping the gas pump for months at a time, since I can charge at home and work. Used market has a lot of good deals, too, both on Volts and other similar models, or full on EVs.

The tax credit is wholly based on battery capacity. IRS form Form 8936 (https://www.irs.gov/instructions/i8936) states this explicitly in its instructions:

Both generations of the Volt have received the full $7500 credit as the battery was large enough. Vehicles like the plug-in Prius and Ford Energi did not because their battery packs were smaller. Source: IRS document https://www.irs.gov/forms-pubs... tells you how to fill out the form. In those instructions, it says

The Gen 1 Volt battery has a presented/usable capacity of something on the order of 10.3 kWh, but the battery pack itself is on the order of 16 kWh, as it changed from introduction to the end of Gen 1. Gen 2 has 18.4 kWh pack so it also qualifies (and delivers 53ish mile range rather than 35ish mile range)

Compiler warnings are often viewed as "noise" and disregarded entirely, or "logged and fixed in the next release". We learned our lesson the hard way years ago and have moved to warning-free code as a checkin requirement, but it would not surprise me to find a lot of organizations with date-driven releases who let them slip, especially as the ship date get ominously close. We pretty much use -Wall -Werror, but occasionally I need to deal with stuff from github and it's warning city. It's kind of like learning hygene is really good and then having to go somewhere soap hasn't been invented.

Yes, indeed. We realized a lot of those compiler warnings were actually trying to tell us something (WOW!) and cleaned up our code base over the course of a number of years. We are now pretty much at the point where compiler warnings are generally viewed as errors, so the bar is very high and requires additional code review if you legitimately need to submit something that triggers a warning ... "the compiler is lying, I'm right" isn't good enough. We have a number of people on staff who are really good at figuring this out before it ships and shows up as a bug. It's also far more reassuring when you see your code compile really cleanly, makes a lot of other stuff far easier.

It's also worth noting that there's plenty of stuff you can do when you are checking in code if your organization has come up with code guidelines. Checking for things like the present of tabs, copyright strings and a number of other things can be enforced.

Back in the 90's when I was getting my engineering degree, people were whimpering about.

1. Having to write out lab reports
2. The indignity and waste of time that the non-engineering required classes were
3. Getting points taken away on lab reports for grammar, spelling mistakes, and punctuation
4. Having to make presentations to the class, explain data and give demonstrations on engineering subjects.

The professor wouldn't budge. He made it abundantly clear that you could have flawless lab technique, perfect calculations, the best design or the most innovative idea ever and it would never go anywhere unless you could adequately communicate with your peers, managers, investors, a review board, a corporate board, sales personnel, customers, and pretty much anyone else an engineer might need to communicate with.

Fast forward to where I am now and it couldn't be more true. For instance, I'm asked to contribute to capital planning for the next year. This requires me to engage the technical requirements of the teams I work with and then translate that into some amount of money that gets put in the budget. Naturally, when you request a large amount of money, people ask questions back. I have to be able to answer them coming from a manager as well as a technical expert. I get occasionally asked to sit in on a conference call with a big customer as a technical expert to back up our consultants or applications engineers. I need to know how to present myself there and not make a fool of myself or my colleagues. Customers can come in the "high level manager" variety , "person whose technical expertise is similar to mine", or "how did this person get hired and on this project" variety.

So, to sum up: yes, technical skill is important. You need that in a technical role. No question about it. At some point, though, technical skills aren't enough, the soft skills need also be present as your technical acumen and renown grow in your organization. There is absolutely nothing new to this, at all.

The chainmail body suit and tin foil hat aren't going to cut it any more?

A lot of the tech that comes out is sold B2B, via the cloud (which, honestly has also grown considerably in the last decade plus), into specialized markets (science, engineering, design, biotech, robotics, signal processing, AI, data analysis) or into backend/server room stuff a consumer never sees. Just because it doesn't make it into widespread consumer adoption doesn't mean there isn't useful work done, or innovative projects being worked on. A lot of change is incremental, too. The product my company makes today is certainly different, improved and changed than when I started here 15+ years ago.

I'm wondering how I'm getting screwed.