It's interesting that you quoted that line, because Koenig delivered it with quiet menace. I've always wondered -- and maybe someone reading this knows -- whether JMS wrote it or Koenig himself added it, because it comes from another, much older sci-fi series: The Prisoner. My guess is that both of them saw it at one point or another, and thus were aware of the (repeated) line and its meaning.

However it found its way into B5's dialogue, it was an excellent choice -- another of the many fine bits of writing, along with "...because I have poisoned your drink" and "He is behind me; you are in front of me." and of course: "Nobody listen to Zathras".

It's not the devil; it's just garbage and is only used by inferior people who don't know any better -- and are too lazy to learn. In that sense it's useful: it allows us to easily identify the incompetent and stupid, which is why I use it as an interview question. (Seriously. It's just one in a list, and it's not the first or last, so there's no particular indication that it's a key. Of course I permanently reject any applicant who answers it incorrectly, but one thing I've noticed is that these people also tend to be seriously lacking in other areas as well. For example, a couple of months I interviewed someone who considered themselves a senior Linux expert but couldn't write a single line of awk(1) -- which is pathetic. I didn't hire them but I did recommend some remedial reading to them in the hopes that they might invest some minimal effort in self-improvement.)

These data centers are the sources and sinks for all kinds of abuse and attacks; have been for many years. The Russian government doesn't care what they go after as long as it's not in Russia, so the operations using these data centers operate with impunity.

Of course I've had most of them completely firewalled out for years, but every now and then one of them picks up an additional network block that's allocated elsewhere, the attacks start, and it's necessary to add that block to one of the existing rulesets. There are many sources for lists of Russian network blocks; one of them is IPdeny country block downloads, which is updated quite often. (That link is for IPv4; note link on the page itself for IPv6.)

Note: it's advisable to make the firewall rules bidirectional. If you're defending a server environment, and nothing running there requires outbound access to Russia, then make sure nothing has that access and make sure that you set alarms on any attempt -- because they may be an indication that you've been compromised and someone is trying to exfiltrate data. If you're defending a user environment, this is trickier -- on the one hand, none of your users should be accessing anything in the Russia, on the other hand they may get very upset when they find out they can't. But if -- for example -- your users are business users, and there's no business reason for anyone to reach Russian network space, then you can probably impose this as a matter of corporate policy. On the other hand, if your users are ISP clients, then you may not be able to make this stick.

None of this is a panacea. Proxies, VPNs, hosts in non-Russian clouds, compromised systems elsewhere in the world, all kinds of things combine to make this approach inadequate. But you should do it anyway, for two reasons: first, there's no point in making it easy for them. Second, if you don't perform this bit of due diligence, and things go sideways, you may be asked some very pointed questions about why you chose to skip something this obvious and easy.

1. Security
2. Security
3. Security
OpenBSD's maintainers are focused on security because they recognize that if you can't compute securely...you can't compute. They're (relatively) quick to remove code, (relatively) slow to add code, because -- as we've learned -- this is just about always the path to improved security.

4. Simplicity. The base OpenBSD install is small and runs efficiently on minimal hardware: I have a test system that's over 20 years old and it just hums along with each new version. Of course you can add any of thousands of packages, but they're not cluttering up everything by default. Note that this minimal install is also aligned with security: "ps" on base install doesn't show much running and 'netstat -a" doesn't show much listening. Contrast with many contemporary Linux distributions that install and run all kinds of things by default.

5. Firewall. OpenBSD's "pf" is the best firewall available, period. it's easy to configure (uses text files), easy to maintain, runs well with minimal CPU and memory, and in almost all cases, is only bandwidth-limited by the speed of the network interfaces.

6. Robustness. OpenBSD continues to stay functional in situations that would lock up or just crash other distributions. A few months ago, one of my systems was hit with a novel DoS attack that pushed the load average over 40; that system was still responsive at the command line and I was able to squelch the attack...and then everything just went back to normal. No reboot necessary. Of course that's how everything should work but it's not how most things really work.

7. Stability. While of course there are occasionally flag days on which old things stop working, for the most part, OpenBSD is very stable. Code that you compiled and ran on OpenBSD 5.7 is highly likely to compile and run on OpenBSD 8.0. Yes, there are scattered exceptions to this -- but worth noting is that some of those aren't the fault of OpenBSD, they're the fault of bad code.

8. FAST response to security issues. If something turns up, OpenBSD developers drop everything and deal with it. Fixes show up quickly, even to obscure bugs that are difficult to exploit or for which there is no known exploit.

The closest thing to OpenBSD in the Linux world is Slackware (and I run it on a few systems). But as good as it is...it's not OpenBSD.

I've run so many Unix and Linux distributions that I've lost count -- starting with Unix v6 on a PDP-11. (I've also contributed a few bits of code here and there along the way.) OpenBSD has clearly established itself as gold standard for robustness. It's not perfect -- nothing is -- but it's the best we've got.

It's not fancy, it's not trendy, it's sometimes a bit of a pain, but if you're serious about security, this is what you want to be running -- particularly on anything that has to face the public Internet. It's well worth the investment of time and effort.

...and every person employed there need to be imprisoned in a forced labor camp for the rest of their life. These aren't "prediction markets", they're completely evil corruption machines that inevitably destroy everything they touch: governments, businesses, democracy, economics, sports, EVERYTHING.

If the US was a functioning country they would have been shut down on their first day and their employees criminally prosecuted. But since the US is now an utterly corrupt country, starting at the top, that hasn't happened and unfortunately may not happen.

We knew this, decades ago -- which is why all advertising was banned. But as short-sighted next-quarter-profits commercial interests took over, of course all of that went away, and now we have advertisers (parasites) and marketers (parasites) and spammers (vicious parasites) and worse EVERYWHERE.

All web browsers should have universal ad blocking built-in and turned on by default. The parasites will of course complain, but we don't need them. (I don't want to hear "but my web site won't survive without advertising"-- I've been running sites since they were a thing and I've never allowed advertising, so I don't want to hear any whining about how it can't be done.) We need to permanently blacklist all advertiser domains on sight, and we probably need to block advertiser networks.

And the thing is: it didn't need to turn out like this. If advertisers had just behaved like responsible grown-ups then we could have grudgingly tolerated their worthless presence and just ignored them. But they couldn't do that; they had to turn their entire ecosystem into a massive assault on security and privacy.

Well, screw them.

The correct move here was not to (re)invent a source code control system so that it could handle such an enormous volume of changes.

The correct move was to realize that such an enormous volume of changes was a problem to be eliminated, not accommodated.

(1) Any day that crypto bros get ripped off is a good day.

(2) It's becoming more apparent that not only are hardware supply-chain attacks becoming more prevalent (that's hardly news) but they're becoming cheaper to execute -- which means that devices which might have escaped previously may be targeted now, because now it's cost-effective to do so. Moreover, the market for fake products is expanding thanks to trade restrictions and tariffs, so anybody who can build a credible forgery and market it appropriately is probably going to be able to do a lot of damage before they're caught....if they're caught.

All of our system configurations are under revision control. Before any revision can be committed, it must be reviewed by someone other than the person who wants to make the commit. (I trust this kind of process is familiar to everyone. It's designed to at least partially mitigate the problem that most people won't see their own mistakes even if they're diligent about looking for them.) Once a revision is committed (and thus checked into the revision control system and subsequently deployed in the live environment) notifications are sent to all the relevant people -- so that if something breaks shortly afterward, there's at least a fighting chance that someone will connect the two events and start debugging in the right place.

The LetsEncrypt automation breaks this process, which is why we don't use it. And this pointless focus on short expirations -- when other things are vastly worse problems -- just means that more hours/year are going to be spent renewing certificates.

And not just for headlights, but for taillights. Far too many vehicle designers are indulging some artistic/creative whim at the expenses of human factors and thus safety. All headlights and taillights should be designed to a handful of fixed templates (to accommodate vehicles of different widths and heights) that specify the distance between the lights, the shape of the lights, the size of the lights, the brightness of the lights, the frequency at which turn signals blink, etc.

Fixing all of these -- as much as possible -- will make it much easier for drivers to estimate distance/speed at night; it'll get rid of the animated rear turn signals; it'll dispense with the ridiculously blue headlights that some idiot in my neighborhood has; and so on. One thing that I think could be adde dto this -- mentioned elsewhere in the thread -- is rear brake light signaling for hard braking. I'm the opposite of a tailgater, and I pay attention, but even I've mis-estimated the deceleration of a car in front of me, and an additional cue would be helpful in such cases.

We need cameras and microphones set up outside their homes, livestreaming everything constantly. We need to follow them wherever they go and post audio/video/stills from that too, along with their exact locations. We need to run facial recognition on them and everyone they encounter. We need to do everything possible to ensure that they have absolutely no privacy, ever. This includes the children because, after all, they're doing it to our children -- why should theirs be exempt?

This is what Flock is doing to us; it's only fair to return the favor.

I see: decades of work in the field, a lot of successful rescues and some unsuccessful ones, plus the study and practice required to become a certified instructor, means that I'm..."short-sighted".

I'm fully aware of the multiple ways that people evacuated (or didn't) during Sandy. Not all of them made the best possible choices because they were scared, confused, or uninformed. Not all of them could make the best possible choices because they were old, disabled, or trapped by circumstances. For example, some of them chose to try to evacuate by car in places where that was impossible because streets were flooded. You and I and everyone else can sit in here in our nice dry, warm, comfortable chairs and criticize that; it's easy. It's very different when you're standing in waist-deep water for hours trying to get panicked people to stop before they make their predicament worse.

One of things that we do following every response is a debrief. We analyze it and ask ourselves what we got right and what we got wrong. No rescue is ever perfect, unfortunately; all we can do is try to do the next one better than the previous one. And one of the consistent conclusions from hundreds of these is that communication is both imperfect and essential. We need to use every possible means, with a strong preference for the ones that will keep working as conditions deteriorate over minutes/hours/days. An AM radio in every vehicle is one component of that; obviously it's not the only one, we'd be delighted if everybody had a couple of cheap battery/crank/solar powered emergency radios in their homes. (We'd also be delighted if everyone had plain old POTS, because it's far more robust than cable/fiber/wireless.) But we have work with what we have, not with what we wish we had.

(I'm no longer in the field very often, but I train the people who are.)

The negligible expense of AM radio in every vehicle is an investment that's paid back in lives saved. I'll give you an example and presume that you can extrapolate to other events.

When Sandy hit, it took out all kinds of communications. (Cellular networks are particularly vulnerable to this because backup power supply systems are only designed to run briefly and because the towers fall in hurricanes/tornados/derechos/etc.) Even local radio stations -- yes, including AM stations -- were knocked off the air by the event. But non-local radio stations that could be received in the affected area stayed on the air, and when we asked WLS-AM (mentioned in this story) and other stations (e.g. KMOX-AM) to broadcast evacuation instructions, they did. And some people heard those broadcasts, which I know because I was there and asked them how they knew to come to the evac staging zones we'd set up.

That's the thing about AM radio: because powerful stations can be heard hundreds of miles away on cheap gear, they constitute a communications channel that is likely to be keep working even when everything else is down or severely impaired. It's dirt-cheap insurance, and the feeble excuse from EV vendors that it causes interference is absolutely bullshit: we figured out how to solve that problem a long time ago. Their real reason is that want people to depend solely on communication channels that they control, even if they know full well that they'll fail in emergencies, and they don't care how many people die as a consequence.

Nobody can march down the street and burn them down.

The fascist oligarchs behind the AI/data center scam know that the public hates these and that eventually, it will occur to someone to torch one of them. That's not going to be so easy if they're in orbit.

This has nothing to do with research or innovation or anything else: it's pure self-preservation.