nebezb

> Almost certainly there is malicious intent here, you are giving them too much benefit of doubt.

It's equally as certain (not very certain) you're attributing malicious intent where there is none. They're both real possibilities.

Bits certainly don’t rot and you’re welcome to stay on the latest stable version that runs on your architecture.

And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.

No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.

The parent poster is wrongly quoting me to say the original post doesn't mean “env var”. Yes, it does mean env var.

> The unwritten assumption in 12 Factor is: the environment is secure.

Fair assumption.

Assuming no attackers and you're only running trusted code, I still maintain the environment is a poor place to keep secrets. Devs adding `{ meta: process.env }` to logs. Instrumentation/reporting libraries dumping the process (and the env) for crash reports. Trust that subprocesses + dependencies inheriting your environment are taking equal care to avoid these issues, too.

Confidently wrong. Did you read the source I linked?

> The twelve-factor app stores config in environment variables

> Built-in tsconfig paths support

A great QoL change. One less place to duplicate (and potentially mistake) a config.

What kind of headline is this? After a week of denial and blaming Iran of "poor accuracy".

More accurate: US missile capable of < 5 meters of accuracy hits Iranian school 200m away from military base, according to BBC.

> reimplementing a network protocol

My reply is that, strictly speaking, it is not a reimplementation of a network protocol if you need to recreate parts of the game based on best guesses that _impact_ the gameplay if your guess is wrong/different. A game is more than a network protocol. It is the data within that makes it to you that is being emulated.

SMB3 is SMB3. I would probably classify SMB1 (proprietary, closed) implementations as emulators if the guesses resulted in differing functionality from client<>server to another client<>server.

> I've long been irritated by the use of the term "server emulator" in gaming contexts. Technically these projects are just reimplementations of a proprietary networking protocol. Nobody calls Samba a "server emulator" because it reimplements the Windows file sharing protocol, because Samba isn't "emulating" anything from the perspective of the traditional definition of "emulator" in computer science.

I think the distinction is a lot greyer than the black/white you propose.

The very first popular online games used servers mostly to redistribute (and maybe time sync) packets from clients. There is no standard way to to do that. Player-created servers did their best to emulate the official servers logic but it was indeed impossible to replicate it perfectly.

e.g. when breaking up large maps into sectors, the official server might broadcast your location and projectiles X units away and emulators would broadcast it X + 500 units away, which could have an impact on gameplay.

Emulator feels fitting when there is no official server spec to reimplement.

edit: emulator also feels appropriate where servers are responsible for NPC activity or quest-like mechanics. This goes beyond implementing a network protocol. The gameplay is massively impacted.