pluto_modadic

personally, the golang highlighting is nice.

- dark blue: keywords (var, nil)

- light blue: variables (defines the scope you're looking at)

- blue-green: types (bool, string, your custom thing, the kind of the variables)

- dark green: comments

- yellow: functions/methods (jumping to another section)

- orange: strings (not variables, so static things here!)

- if/braces/parens/select/switch/defer/go: purple (control logic)

da rulez:

- if you don't understand your concept/market, build in a VPS. you can get away with scaling a VPS for a while.

- if you intend to be netflix, rent at the edge (mid game) and eventually own the edge servers in POPs (otherwise, "edge" compute isn't worth it). before that, start with a beefy VPS cluster with HA and SQLproxy.

- if you spin to zero, use lambdas (for things like codebuild or fractional needs of a computer). before that, build things in VPSes.

- if you spin up/down but not to zero, use container platforms?

- once you have a reliably steady understanding of your infrastructure, buy physical servers in a colo

this kinda proves the point that you have to know a silly workaround

static secrets that you can even extract and set in a config file (or store in a secrets manager) need to go. TPM secrets that you can't extract, and public keys that you can pin without considering them "secret", along with Oauth / IAM roles, are the way to go.

focus on the customer's problem. Not on debugging a huge thorny k8s stack or AWS deploy.

I think this skips over /how to do it/.

...so your argument is.... stay with the abusers?

LSM is great for write heavy loads. not sure about random reads, isn't that a B+ tree's turf?

is there an implementation of B+ trees that fluidly pulls from disk vs RAM?

e.g., two B+ trees, one in RAM and one on disk, with the RAM one evicted with sieve caching? possibly a very lite WAL?

something that lets you use a B+ tree bigger than RAM, and persist to disk

I think... that's because.. DJB was... (gasp) disobeying the code of conduct. and has been, for a long, long, loooong time.

people can see reactions :p they can also see when a mod adds or demotes a member

user posts inappropriate thing in group chat. group admins cannot delete it for everyone.

this is the same argument as saying "you shouldn't have remote delete requests". Yes, people can screenshot or export. That doesn't mean you shouldn't have a nicety that generally works pre-compromise or pre-evil. Locks just keep honest people honest.

I think they could use better moderation features.

So, the pitch for TigerBeetle is... "you can do database schemas wrong and we're performant enough"? (and also we don't have auth)

to take a hike sooner*

https://github.com/pubky/pkarr is another one

it's mostly seeing juniors and project managers writing garbage that creates a massive pile of BS for us to clean up that pisses us off.

when you're paralyzed into not putting anything on the page, it's important to just get the dumb idea onto the IDE and refactor from there.

New corollary: sometimes new tech gets built because you don't know how to correctly use existing tech.

I agree that moderation tools are important :) one of signal's failings is the lack of moderation tooling. You can have small scale group moderation without having government scale surveillance.

the UI/UX of discord is definitely nice, but the /ethics/ of discord isn't.

The developer is also kind which makes this awesome.

It would be a bad look if he took the money and quit.

I don't think the grunts get to decide. youtube is now governed by the dude who used to run AdSense, and has a mandate to fix revenue losses.

render the video twice -> gotcha, the GPU needs to run TPM code and knows where the buffer will go.

breath of fresh air compared to mullenweg or DHH.

this is solved by reading the repo's README: hiding timing information.

they're big, and we expect proper behavior out of them when they mess up. that includes public details.

"have a human take a look at this conversation (from {time} to {time})"