While battery storage may be helping keep the grid stable during peek loads, its still an expensive solution that trades peak load intentional shutoff outages for toxic fires that harm surrounding communities (such as Moss Landing) and cause other outages. Meanwhile, ignoring the more serious problem of frequent unforced & unexplained outages occurring all the time. Just yesterday, in nice weather, power was out across my community for over 4 hours. No reason was provided, but I'll betcha it was some form of poor maintenance practices and mismanagement on the part of PG&E. The batteries aren't fixing the more common and mundane problem of poorly maintained systems causing ever more frequent outages.

The problem is that ice vending is a monopoly, so ice vendor employs monopoly tactitics. Since customers can't buy anywhere else, the vendor could not care less about inconveniencing them - they can't buy from another supplier.

Solution is to have more than 3 independent vendors, and BM sets the pice. Vendors will compete on service for sales - fastest server will prevail. The vendor that just takes customers' money and lets customer pick their own ice up from the truck will be fastest.

First-world problem solved.

Great, one hole in the sieve that is e-voting plugged. Just a few thousand more to go. When are the hashes ever verified, and what can be done once one or more ballots fail verification? How might a voter validate (via hash on receipt) that the ballot was tabulated as hashed? This is just one of a myriad of possible attack vectors. What about the others, particularly the wholesale methods of rigging like simply altering the contents of the Access database that stores the votes between when voting concludes and when votes are tabulated? That appears to have happened in Ohio in 2004, where several people were convicted of the offense.

At best, a good case for compiling PHP code. I'm not sure the assumptions are sound at all: 10:1 ration? PHP code is dominant code executed? I'd bet most of execution is in database, and that is surely executing compiled C/C++.

Pick a theme and stick to it. In the past, we've used names of fish and that seemed to work pretty well...swordfish, hammerhead, etc. Obviously, pick something with a sufficiently large set of names for your network. This is effective as non-meaningful id's, but gives the workstations the sort of personality that they deserve.
Avoid using information *about* the workstation in its name. Primary user, location, function may change over time. Renaming is problematic so avoid needing to do it.

I remember using Micro Focus cobol to write DOS apps in the early 90's. That language seemed antiquated in those days, but it's still king for certain types of systems.

I don't get how comcast can get away with offerring "unlimited" internet at speeds "up to 16 Mbps" and then cap @ 250 GB/month. 250 GB/month works out to a rate of 809 kbps, or .79 Mbps, a mere 1/20th of the advertised rate.
Where is the Federal Trade Comission whe you need them. It seems absurd to let Comcast get away with offering speeds of 16 Mbps, sold on a monthly basis, while essentially terminating service for any customer that averages over .79 Mbps during that period. They should be forced to change their advertising to say "speeds up to .79 Mbps". Class action suit anyone?
While 250 GB in a month seems sufficient for most users most of the time, I could easily see a time in the not so distant future where you might want to have a video feed (or several) running all the time (much as some people leave their TV on all the time) -- easily consumming 1 or 2 Mbps.