The new Hyundai I just bought has the giant Ipad that can control everything, but they also put in old-fashioned buttons for the important things like ass warmers. I don't have to take off my gloves (or buy those special gloves with the "touch fingers") to control most things.

Having water system operators responding to fire or flood calls from home pretty much demands an internet connection (via VPN). We aren't staffed 24x7, but our ISO insurance rating demands that operators be able to respond to fire calls within a short time frame. Having licensed operators manning an air-gapped console 24x7 would be extraordinarily expensive, plus fire calls of the magnitude requiring an operator to respond just don't occur that frequently.

The critical systems in question aren't directly internet-connected but are accessible from the internet via a VPN.

Water system employee here. Firefighting is the most urgent reason for having things available remotely. We have people on call 24x7 to activate pumps and reroute water to maintain the water pressure needed for firefighting. We're part of the 911 system and are notified of major fires. An apartment or industrial fire can require large amounts of water be delivered quickly to maintain pressure.

Second, a lot of our flood control gates and pumps are in remote areas. Heavy rains may require that these be operated at odd hours. We also allow our plant operators to WFH regularly. This requires remote access (via VPN) to do their jobs.

We're lucky in that we're a large city and have (almost) sufficient funding. We can afford to have a security team just to keep out the bad guys. Some of the smaller neighboring systems aren't so lucky and they just hope that their low-bidder AV software will be enough.

Doing rollbacks of bad MS patches helps keep me employed!

I'm a hearing aid user with upper range hearing loss, partially genetic, mostly caused by being in band and by dancing in front of the speakers at too many concerts during the 80's.

I originally went the medical/audiologist route. Those hearing aids set me back a cool $4k and required constant adjustments/maintenance. Insurance covered absolutely nothing.

When the $4k ones stopped working, I got fed up and bought some $200 "digital hearing amplifiers" off Amazon that can be set to amplify high-end sound. They stress in the advertising that these are NOT hearing aids, but "programmable amplifiers". Those work just as well for me as the $4000 ones and when I drop these in the toilet (again) or accidentally take a shower with them on (again), I can trash them and order more. Parts are also available at a reasonable price.

Video conferencing just makes it easier to say "let's set up a quick video call" that still should have been an email or even a Teams chat. Lonely people inevitably drag out the meeting even longer just for human contact.

I'm living the introverted nerd's dream right now: I never have to leave the house and engage in the awkward practice of "meeting and talking to people".

C-levels don't understand security, department managers don't want to pay for security and project managers just want to get the damn thing tested and signed off on time and on budget. There's immense pressure to "just get it done". Then after a breach, the mahogany suite wants to hold Joe Codemonkey, Jr. personally responsible for "writing insecure code".

You either pay for it up front or you pay even more on the back end. Guess which one management inevitably chooses?

I see the gig economy as an opportunity for older tech workers like me. Most companies don't want to hire a near-60-something as a permanent employee, but have no problems with signing me to a contract. I'm not ready to retire yet, but I do have, to quote a movie, "...are a very particular set of skills. Skills I have acquired over a very long career."

Most companies need my particular skills for a big project maybe up to a year, two at the outside. At the end, I train a lower-paid permanent employee to manage things, then I move on having added whatever new skills I picked up during the gig to my resume. Since it's always a short-term gig with a deadline, I can charge extortionate hourly rates and work lots of overtime and everybody's happy. Then I can add another blurb to my resume "Implemented widget sorting system at BigCo" and add another 5 bucks an hour to my rate. Win-win.

I do work for a staffing firm. It's sort of a pimp-hooker-john relationship. They're my pimp and do a good job of finding me another john (job) when I'm done with the current contract.

These robots and their minders will be the first against the wall when the Butlerian Jihad comes.

Straight from the Orange Catholic bible: "Thou shalt not make a machine in the likeness of a human mind."

I learned coding using the unholy duo of COBOL and FORTRAN, written out by hand on coding forms and then hand-punched on an IBM 029 card punch machine from hell. It was goddamn hard and we liked it that way! Now, get the fuck off my lawn.

Programming is an abstract concept. It's not like hammering nails into a board, it's all done in your head. You have to visualize, organize and convert all those bytes flowing around in your head into cognizable, workable code. It takes a certain type of person with a fair degree of mental discipline to do that. Debugging is an even more abstract mental exercise.

It's hard to produce complex code. If coding were easy, a 2nd grader could write a payroll system in Logo. Watch Johnny move the turtle to calculate FICA!

Radio will end up being an endless replay of the same 20 pop hits by the same mega-artists.

Oh, wait. It already is.

We're still running COBOL code from the 70's. Probably 600k lines of it all told, which is down from over a million lines around Y2K. It's all boring financial stuff, but utterly essential.

I'm a greyhair now, but I was in junior high school when this system first went online. The names at the top of the change log have been dead and buried for 20+ years. The names in the middle retired right after Y2k. The names at the bottom are all 55+ years old. COBOL coders are worth their weight in gold these days, but getting any to stick around for more than a year has been difficult. COBOL contractors can ALWAYS make substantially more money somewhere else.

The cost to analyze the codebase and build a replacement will cost a frikkin' huge fortune. Thus, I suspect the company will continue to run this same code long after my name has moved to the top of the change log and I've been archived on that big DASD in the sky.

I have legacy green-screen skills that are valuable only because the people that have my skill are retired and/or rapidly dying off, yet these systems are still in common use all over the world. Why should my skills be valued the same as some dime-a-dozen Java union hack when I can pull down extortionate wages on my own?

I'd be happy to get right on migrating chop chop just like MS wants. Our MS TAM keeps pushing pushing pushing, but the problem is that I have 30k+ workstations to manage. Just the act of physically upgrading the OS on each of those workstations takes plenty of time as it is. Plus, there's the matter of keeping the business going while I upgrade all those workstations.

First, however, I have to create a Win7 OS build that works on all the one-off situations I have. That a work in progress. Then I have to test the OS build on all those one-off situations. Then I have to test the bajillion apps I have and figure out what works and what doesn't. Then I have to determine what can be remediated and what has to be replaced. Then I have to get the budget for both remediation and replacement of those apps. Then I have to test, certify and package what's been remediated and replaced. Then I have to determine what will need to be certified by the various government agencies that we operate under. (We have to get governmental blessings in some cases to change hardware and/or software). Then I have to buy replacement hardware for those workstations that are below the waterline for the new OS. Then I have to schedule (and pay for) end user training on the new OS in various languages in cities all over the globe. Then I have to plan the overwhelming logistics of putting a new OS on all these workstations all over the globe in a manner that doesn't disrupt the business. In addition, I have to deliver replacement hardware to the right place at the right time with very limited resources (that is, not enough people to install so many boxen). Then I have to have the support infrastructure in place to support the inevitable issues that will come roaring in. Then I have to have procedures in place to investigate these issues on the new OS and do whatever is required to unbreak whatever is broken, whether it be sending the software back for fixes or unforeseen hardware replacements.

So, yeah, pardon me if I'm running a bit behind. I've got a lot of work to do with too few staff, too little time and not enough money. But, what else is new?

I work at a fairly large international outfit, with data feeds coming and going to the far ends of the Earth. Everything we do is time-sensitive. Processing messages that depend on prior messages already being processed means we can't gracefully handle things coming in out of order.

We spent lots of time and money studying this problem, hired a high-priced consulting outfit to advise us and spun up lots of projects to mitigate the "risk" of the leap second. There were far too many meetings and conference calls with vendors, VARS and other people that wanted us to pay them for their time. What was determined was that we couldn't guarantee that nothing would crash or (gasp!) messages might be discarded or processed incorrectly, which was a risk we weren't willing to take. We run a full gamut of OSes, from HP/UX, Solaris, Linux, z/TPF, z/OS, DB2 etc etc.. You get the idea. Too many variables and too many systems to update and test with the limited funds and limited timeframe given.

In the end, we avoided the problem by shutting down all (and I do mean ALL) processing and flushing all the transactional systems to disk and suspending EVERYTHING from a minute before until a minute after the leap second. (Was that two minutes or two minutes PLUS one second? Clock math has always eluded me.) Shutting down all these interconnected systems in the correct order was a precision dance that, in the end, we didn't perform very well. Messages did end up being discarded. At precisely :20 seconds after the leap second, we began syncing all our systems with our internal NTP server and then at precisely one minute after, we slowly started everything back up. There were some systems that required a restart. We manually reprocessed those earlier discarded messages just as fast as our little fingers could type. In all it took us about 15 minutes to get everything spun back up, and all that time is getting charged to our SLA, which affects ALL our evaluations and year-end bonuses.

Lots of work was done, overtime was paid and buckets of money were given to lots of high-priced consultants and I personally will take a hit to my paycheck, all over ONE GODDAMNED SECOND.

Let's not do that again, okay?