This concept should get RFK foaming at the mouth.

The pandemic proved that it was possible to survive as a business without doing everything in person, it didn't prove that it was the best way to operate, and it didn't prove that businesses would thrive without some level of in-person communication. I support the concept of remote work for most tech roles, and I have primarily worked from home since before the pandemic. That being said there are some meetings that need to be in person, particularly when the the work is beyond being a pure coder or keyboard jockey - typically in the consultancy and sales areas. You might not ever want a job that requires you to deal with someone in person and maybe need to get on a plane for that in-person meeting to happen, and that's your choice. But there are jobs that occasionally require this, and requiring an in-person interview is one way to filter out those who can't or won't do this. Beyond filtering out fake resumes, in-person interviews are a good way to determine if a candidate is capable of functioning in the real world.

I get that at small and probably medium scale management of an array is a solved problem. I have a similar sized array on my roof with micro inverters. I have 28 panels and in their 12 years of operation I have been able to easily mange the four inverter failures that have occurred. I am curious about what configuration and monitoring you use for 1.3 million panels. Do you still go with micro inverters (while they do isolate you from individual failures, they also cost more and add more failure points)? Do you you use string inverters, and if so what is the typical string size? Do you keep it all DC between the panels and storage batteries and use massive inverters between the battery and the grid? Given that a system of this size is always going to have some level of failure, what level of failure do you just tolerate and what are the thresholds for repair? What kind of staffing do you need to monitor and keep a system like this running? I am not critical of such a system, more curious as to what it takes from a technical and operational perspective to keep such a system running.

1.36 million solar panels is a lot. I would love to see some photos of what that many panels actually look like and how much space it takes up. The photo in the article is clearly not that many panels. My first thought was that maybe the article meant that there were 1.36 million solar cells instead of panels as typical panels are built with 60, 72, or 96 cells per panel. This would result in a total number of panels in the 14 to 22 thousand range, which seems like a more comprehensible deployment. However if you divide the total megawatts by the number of panels quoted, you get about 550 watts per panel, so that would be talking about panels, not cells - that passes the sanity check for the numbers.

So how in the heck do you manage an array of that size (or the set of arrays that add up to that size)? The number of electrical connections and the number of failure points would be insane. I am not suggesting that there would be any single points of failure, and solar is extremely reliable, but even with very low percentage failure rates, at that scale you are going to have some level of failure. It would be cool to know how you monitor and maintain a setup like that, and what operational threshold for repair actions are (do you take action if a single panel goes down, 10 panels go down, 100, 1000, 10000, etc?)

Anyone here have experienced with managing systems at this scale or who can point to technical articles about such?

It is a bad deal and it's dumb, but if you don't take it, then you are over paying by 2% and getting nothing back. The figure is likely higher than 2%, but the point is the same.

I am not sure the is true, do you have a reference? Even if it is true, would those chips not need an external (to the chip) antenna (that could either be not installed, or defeated by grounding out)?

When my.yahoo.com went away recently, I switched to protopage.com - I found this very post on the slashdot RSS feed.

So how would a backdoor in a chip actually work (specifically and technically)? In the case of a CPU or GPU are we talking about a special instruction that when executed kills the chip (blows a fuse or something), are we talking about an extra hardware pin that when the signal is raised or lowered kills the chip, or what? I ask because the concept of a backdoor in hardware seems kind of weird. It seems that it would also need a significant software or firmware component, as well as off chip hardware in order to trigger the kill. If software, firmware, or off chip hardware is required, what would prevent someone from just not implementing that hardware or not installing that software in order to close the backdoor? Or are we really talking about a backdoor implemented in a reference design, chip set, or other tech that isn't really just the CPU/GPU? If it's a reference design, what prevents the adversarial country or party from not using the reference design?

I get that there are things like the management engine in Intel reference designs, and when using the reference design the built in network interface has an extra endpoint not seen by the operating system, but one could protect themselves by either firewalling the machine or adding their own network interface (and not plugging in the built in one). GPUs typically don't have built in network interfaces, so how would a GPU "backdoor" be remotely accessed or triggered?

I am not saying that it can't happen, but I would love to know the technical details on how it could.

While I get your point and agree with the general concept of "cloud only bad", and it's true that Enphase may still "alter the bargain further", I am still running an original Envoy and even with the latest firmware it still supports local access. With home assistant you do need to install the legacy support package to talk to it.

In my head I can hear George C Scott saying, "Mr. President, we must not allow and Ass-AI gap!"

We probably don't need gigabit, but we do need a reasonable lower limit to officially be "broadband" and to measure what counts as "Internet being available to everyone". I have a house where the best internet you can get is a dual bonded DSL connection that totals 12MB down and 2MB up. I don't count that as broadband as while its okay for basic video consumption when I am there, it's not enough for video conferencing, and it is certainly not enough for remote security cameras. There are lots of folks where DSL is the only option, and if you are on connections this slow, I wouldn't want that to count positively in "State of the Internet in America" statistics. It's a valid debate as to what the "minimum" should be to count as broadband. I would personally say somewhere in the 20-30MB up and down range.

Doing that would be harder than rocket science. Behind applications there are databases and databases have schema. If not databases, then data access layers and those layers have interfaces. Since system updates can contain schema or interface updates, you can't always just roll back the system without also rolling back the data. Rolling the database back to a time two application versions ago would would lose a lot of information that shouldn't be lost (tickets, seat assignments, aircraft and crew status and locations, etc.)

Not all application updates have database schema updates and sure those can roll back and forward, but database schema does change from time to time and those upgrades are really hard to roll back without also rolling back data state. Even if you are storing data an unstructured or low structure database, it is still really hard to ensure that older code can handle newer schema and conventions that may appear in the database after some newer software has it's way with your data.

The real malware is the code that is performing the DNS queries and assembling the results into other malware. Sure, this mechanism would bypass normal code scanning on Internet downloads, but that code scanning should have already caught the code making the DNS queries and executing the resultant binaries.

I do.

I do this so I can rip it myself and have a single disc FLAC image - absent any compression, watermarking or DRM that may be in downloaded files, and present the proper gaps (or lack of gaps) between tracks.

More important to predict the time window where speech recognition of safe words during adverse conditions becomes reliable.