Starcraft is too tame. You need to use Dwarf Fortress there and we need to make those strategy guides worded more realistic. Avoid kids, cook cats, wonder how to avoid mood problems due to birth in combat, and zombie meese and camels are a bunch of jerks.

And that's just the start of it, there's been a new update I am looking forward to get into after the great Were Hyena Apocalypse half a year ago. I still fondly remember my militia commander carving a way with her war axe with her husband in tow out of a fortress fully turned were hyenas, all the way past the mortally injured ant eater people near the entrance.

They made it. An entirely epic tale.

These days I do my war crimes in Rimworld, but I have heard bad things too about Dwarf Fortress.

So release the server code as OSS, data necessary to function & support community servers. Even in a crappy hard-to-support way, the community will usually figure out a way.

IMO, the move from community servers over to matchmaking & vendor only servers being the only viable option was a huge disservice to the long-levity of games. If I find the code around here, I could still get a Tremulous server running today for a few bucks, even if I haven't played that game for 20+ years.

This is why I stopped playing Call of Duty after the original Modern Warfare 2. After self hosting servers were removed, the game became less fun.

Solutions to this modern problem was solved during the dialup and LAN party era. None of those single player games required an online launcher.

Releasing the server code isn't always ideal. There's likely a ton of secrets, hardcoding, and exploits.

Regarding 1 and 2, my pity is mild if this requirement forced companies to follow principles of secure software development, configuration and deployment. Injecting stuff from deployment config is not hard.

3 is valid and can be tricky, as it would depend on when in the software lifecycle the release would be mandatory. If it's in a wind-down or bankruptcy situation, it would be tricky. Though that discussion is similar to the responsible disclosure discussion, isn't it? Exploiters usually already know them.

> Try open sourcing a code base that is built up over the last 15 years and most of the devs no longer work there. Thats what you’re asking for many online games.

Thats pretty easy actually.

All you have to do is go into the setting page on the git repo and change the settings from private to public.

I'm sure most game devs are able to figure that one out.

Everything else that resolves was that is merely consequences for which I have little pitty for.

Every employment contract requires copyright assignment. It's not so complicated.

Again, this would not apply to pre-existing games.

Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.

That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.

Also, from the customer side, people ask at the higher end, don't they? Beyond a certain level, it's more of a search and a quest than just browsing. So you mainly have to show that you have connections for certain things. Why does this sound like drugs now?

I know this from a few friends who are deep into tabletop and boardgames, and they would regularly work with the one or two small stores around to get some special, expensive item (to help keep the shop afloat).

Yeah, in my experience the people who want niche stuff are willing to work with you and have a "high touch" experience. Where the people who want entry-level stuff want turn-key, sane defaults.

The annoying thing is people with lots of money and no experience who want the special expensive thing but they want it now and they don't know what options they want. I'm sure other fields are good at separating fools and their money but niche hobby retail isn't the Audi dealership, we're not just trying to upsell you for fun.

Women in a committed relationship can enter a medical situation that renders then unable to work for 6-9 months, + 2 - 3 years of leave afterwards. Men don't, that's just a month or two twice.

It is illegal, and in my book also immoral to deny such a candidate, but the other side of the coin is there.

A friend of mine had an interesting point there. It was more on a personal note that either of us had a hard time spending money on nice things for ourselves. Like, do you need better headphones, do you need this, do you really need that? Better not buy anything nice or fun.

A fairly unintuitive resolution to this is to setup a "fun and nonsense" budget and force yourself to spend it every half year, or to make a conscious plan on how to spend it over the year. If you plan the budget right, it won't hurt you, but it will force you to make your life better.

Maintenance, especially of owned property, seems similar to me. You should be saving up for the real "oh shit" situations, and you should accumulate a budget to just do things continuously. 6 months of routine maintenance budget saved up, what do we spend it on actively, before it becomes a mess?

ETHOS is generally reserved for a certain type of error involving slab memory and complex logic though.

Let's hope that reference is not too obscure...

Three deterministic Linux LPEs in a week, an LPE in BSD in execve (of all things...), nginx vulnerabilities, one or two new gnarly supply chain attacks. Linus noting that the linux-security mailing list is getting flooded with duplicated, AI-driven reports of varying quality. There are pretty crazy keycloak vulnerabilities getting discovered.

We're most likely entering a year or two or rapid vulnerability discovery, patching, as well as reducing and minimalizing system footprints just to survive the onslaught of strange vulnerabilities from e.g. ancient and widely unused kernel modules.

"Molten" to me implies it is still liquid. Molten salt reactors, molten magma from a volcano, molten sand, molten steel, dipping something into molten cheese. All fluid.

If I was to nitpick, "melted" is kind of inaccurate and not entirely natural in this context. Technically, molten sand is also melted sand, because that's how you get it to that state? Usually, you'd hear about solidified magma, crystalized sand, cast iron, air-cast steel, unevenly settled corium... to make a better point on how it turned back into a solid and what to expect from it - something like "The molten sand crystalized into an unusual structure" would be clearer.

I'd usually rather hear "melted" if it is important to note that this had a phase change and back. Plastic on an electrical device may look melted, indicating heat. A hardened steel part may look melted, which may damage the hardening. Rubber on a hydraulic line may look melted, also indicating heat. A plastic container looking melted in the context of chemicals may indicate some compromise.

Now the words sound weird in my head. Thank you.

Yeah.

And I do think that security research should have some regulation about it, but it should be more about responsible handling of the privileged access you gained, or a responsibility to disclose found vulnerabilities in private and/or to a government entity. You know, "If you have gained access to a system, and you saw a button <Turn off cooling pump 2> and you pressed it, you are on the hook for the damages". That is common practice with paid pentesters already.

But we're at a point where a court had do decide if discovering an endpoint on an API without authorization is a "circumvention of a security boundary" or not. Luckily, we now have a ruling that accessing API endpoints without authorization logic is no circumvention of a security boundary, due to a lack of a security boundary like authorization.

That's the level we are at. I don't want to know what happens if foreign nation state actors start acting on this seriously.

The mere act of scanning for vulnerability often causes outages.

I once ran a vulnerability scan at an industrial company that completely disabled their employees ability to clock in and out. I didnt believe it had anything to do with my scanner at first, but it ran on a schedule and the scanners schedule matched their outages eaxctly.

Eventually it turned out the timecard system had these IOT badge readers with a poorly written tcp stack. It would ACK every SYN, and worse the half open connections never closed, so during a port scan every port was left open until it exhausted the memory on the little buggers.

My point is... you cant know in advance what damage you'll do with this sort of testing. That's kind of the entire reason we have to actually perform the real world tests instead of assuming or emulating them.

It's also the reason that real world scanning without authorization is probably already a crime in most jurisdictions, whether it's enforced or not.

But in a perfect world, the question would be: Is it reasonable to expect an outage by sending a few single TCP packet to a system? Or, were you flooding the system unreasonably?

It is a huge security risk to treat systems as ancient eggshells you must not touch ever. A certain amount of touching has to be reasonable, because that is what foreign actors will do if they need to cause trouble. Apparently you could cause this company major operational harm with a pi zero. Why is that protected by professional ruin and jail time?

> Is it reasonable to expect an outage by sending a few single TCP packet to a system?

Thats kind of the rub isn't it? If I'm authorized to do the scan its reasonable. If I'm unauthorized nothing I do is reasonable.

It' similar to drivers licenses. If you get in an accident that wasn't your fault, but your license was invalid, its still your fault legally because you weren't meant to be on the road at all.