That brought a legit chuckle!

Nuclear safety and penny-pinchers don’t make good bedfellows.

Additionally Ukraine is an asset they want to exploit. Turning it into a nuclear landscape makes it unusable.

Jammer also keeps people from getting a notification that someone has come into view on the camera. An away homeowner who sees a person coming through their front door can call the police. With no notification you don’t know until you get home and they’re long gone.

I do. Currently I use it mostly for personal stuff as part of my time spent on production support. Importing data from queries, exporting spreadsheets, reading complex json data and extracting needed info, etc. In the past when I was on DevOps used it with Jenkins and various automation processes, and I’ve used it as a developer to create test environments and test data.

As a long-time bash, awk and sed scripter who knows he’ll probably get downvoted into oblivion for this my recommendation: learn PowerShell

It’s open-source and completely cross-platform - I use it on Macs, Linux and Windows machines - and you don’t know what you’re missing until you try a fully objected-oriented scripting language and shell. No more parsing text, built-in support for scalars, arrays, hash maps/associative arrays, and more complex types like version numbers, IP addresses, synchronized dictionaries and basically anything available in .Net. Read and write csv, json and xml natively and simply. Built-in support for regular expressions throughout, web service calls, remote script execution, and parallel and asynchronous jobs and lots and lots of libraries for all kinds of things.

Seriously, I know its popular and often-deserved to hate on Microsoft but PowerShell is a kick-ass, cross-platform, open-source, modern shell done right, even if it does have a dumb name imo. Once you start learning it you won’t want to go back to any other.

That’s all good info and explains some of the problems that could be resolved for us programmers if we were on UTC, but for the most part these are programmer problems and the computer handles it for everyone else. Additionally, it makes a few issues clear that won’t be resolved with a UTC switch.

First, as mentioned countries all over the world decide for themselves what timezone they’re going to follow. Even if countries were to switch to UTC, we know they all won’t do it nor at the same time, so programmers will have to deal with that added complexity too having some on UTC, some off, some switching on this date or that… if the movement got serious we’d have another Y2K frenzy, but not one that ended on a specific date… it’d linger for years as various countries came on-board. Additionally, we’d still have to deal with all the historical calendar, timezone and DST switches he mentioned. Those wouldn’t go away… in fact we’d be introducing a bunch of new ones.

Fact is timezones are understandable and work pretty good for normal people and their day-to-day tasks. Normal people aren’t going to want to understand UTC and then have to translate their normal day times to and from others around the world. No matter where you are I understand what you mean when you say your morning started at 6am or you eat at noon or you go to bed at 11pm or 23:00 for that matter. With UTC I don’t know what 23:00 means in Australia, Germany or India relative to your day… not only programmers but even normal people would have to know how to translate that to a time they can relate too, so you’d have to know timezones anyway. So while I’d know 23:00 was exactly the same point in time for each of us, I wouldn’t know how it relates to your day the way it relates to mine… is it morning, night, mid-day? It would actually make today’s programmers problems - which isn’t too common for most of us - a problem for everyone.

Why switch? It’s not too complicated a concept for the average person to understand and deal with. In fact, it’s intuitive. Sure in software the logic has a few nuances that are a bit complex when needing to deal with local time and timezones, but that’s why we make the computers do the tricky work.

My understanding is DST did still save appreciable energy until we replaced incandescent lights with fluorescent and leds. Longer daylight in the evening when people are awake and less in the early morning when people are asleep means lights aren’t being used as much. The average light bulb used to consume 60 watts or more and also let off significant undesirable heat, so with a house full of lights DST really did cut back energy usage. Now though with led lights low consumption and virtually no heat, it’s not nearly as significant.

Clearly you’ve not had to write and maintain much XML.

Had no trouble here on mobile.

Couldn’t agree more. It’s a great shell and scripting language. It’s object-oriented nature, native support for virtually every text format (csv, json, xml) and great libraries for others (yaml, excel), awesome regex and web/rest services support… it’s hard to beat and works on virtually every platform.

Too few people in the Linux community will even look at it though since it has MS name on it.

Can prevent a restore, whereas doing the update with auto commit guarantees a restore on (mostly) every error you make

Exactly. Restores often result in system downtime and may take hours and involve lots of people. The backup might not have the latest data either, and restoring to a single table you screwed up may not be feasible or come with risk of inconsistent data being loaded. Even if you just created the backup before your statement, what about the transaction coming in while you’re working and after you realize your error? Can you restore without impacting those?

You want to avoid all of that if possible. If you’re mucking with data that you’ll have to restore if you mess up, production or not, you should be working with an open transaction. As you said… if you see an unexpected number of rows updated, easy to rollback. And you can run queries after you’ve modified the data to confirm your table contains data as you expect now. Something surprising… rollback and re-think what you’re doing. Better to never touch a backup and not shoot yourself in the foot and your data in the face all due to a stupid, easily preventable mistake.

And always use a transaction so you’re required to commit to make it permanent. See an unexpected result? Rollback.

Indeed. The amount of work that’s went into the prevention and ways to identify who’s done it is not insignificant.

Not to ask a possibly silly question but I haven’t seen these questions asked and I don’t know your network experience. You’ve supplied the actual network address of your pihole machine and not the 192.168.1.250 address shown, right? And you’ve set your pihole server up to have a static ip address as well, correct? You don’t want it assigned dynamically and therefore randomly everytime it renews its lease.

If the ip address is statically assigned - either hard-coded as static on the machine or at least being statically assigned on your router via its mac address - then setting the dns server on your router should work. I would however assign 2nd and 3rd dns servers as Google dns or cloud flare ip addresses in case your pihole server is ever down. (1.1.1.1, 8.8.8.8 or some of the others). If that’s all confirmed and your machines are not receiving your configured dns settings from the router, it’s possible (seems unlikely) the spectrum supplied router is ignoring the settings and assigning their dns servers. If so, buy your own router and put it between your home network and the spectrum hardware. Then you have control and it doesn’t matter what their hardware does. You’ll just set yours up on a different subnet - 192.168.x where x doesn’t match the same value as the spectrum network - and you should be good to go.

Good luck!