olafalo

Thanks, this rings true to me. The struggle is an investment, and it pays off in good judgement and taste. The same goes for individual codebases too. When I see some weird bug and can immediately guess what’s going wrong and why, that’s my time spent in that codebase paying off. I guess LLM-ing a feature is the inverse, incurring some kind of cognitive debt.

Quoting Trump directly, from Agenda 47:

> Furthermore, I will direct the Department of Justice to pursue federal civil rights cases against schools that continue to engage in racial discrimination. And schools that persist in explicit unlawful discrimination under the guise of equity will not only have their endowment taxed, but through budget reconciliation, I will advance a measure to have them fined up to the entire amount of their endowment.

For me, it's configinator[0]. Write a spec file for a config like [1], get a Go file that loads a config from environment variables like [2]. Code-gen only, no reflection, fairly type-safe, supports enums, string, bool, and int64. I made it because it was gross to add new config vars in a project at work, and it's come in handy a lot!

[0] https://github.com/olafal0/configinator

[1] https://github.com/olafal0/configinator/blob/0576a53970bcb4d...

[2] https://github.com/olafal0/configinator/blob/0576a53970bcb4d...

The whole comment:

$ echo -n "Well, this nerd sniped me... I made a quick Go tool for this. You simply write a string {like|this}, and then it finds a hash with the same prefix automatically. (Hash this comment, it's also 182a7c9)"|sha256sum 182a7c9ba0f815f77542774dc5ad9ea34975bf3747635ed0768748bcd772ef43 -

Well, this nerd sniped me... I made a quick Go tool for this. You simply write a string {like|this}, and then it finds a hash with the same prefix automatically. (Hash this comment, it's also 182a7c9)

I'm not very good at this but I'll see if I can explain my thought process:

(is tiger fed) requires (eats tiger ?food)

which means there must exist ?what such that (is ?what eatable) and (is ?what ?food)

But in the fact table, nothing is actually eatable! We could have our tiger eat plants by asserting (eats tiger plants) and (is grass eatable), but that's two assertions. Tigers eat animals, and tigers ARE animals, so since we need to make something eatable we might as well do it on the only animals we have: (is tiger eatable)

I got level 2 as well but only after checking for hints in the source. I have been thoroughly nerd-sniped.

> Less water [use], sure, but more electricity

Well, no. As dishwashers get more energy efficient, they tend to use less water as well[0]. And dishwashers have steadily been using less electricity and water.

> One in five homes have just stopped using their dishwashers altogether

The survey that is linked here[1] says "less than once per week," not "stopped altogether". The writer of the linked article suggests that the reason is the misconception that washing dishes by hand uses less energy, so people (especially in smaller or poorer households) are washing dishes by hand instead of using their dishwasher.

> Thanks to federal mandates, all phosphates were eliminated from detergent

Yep, those federal jerks hate us citizens having clean dishes! Or, wait, turns out those phosphates are environmentally damaging, which sounds like a good enough reason to me to remove them from detergent.

Moving on to a more anecdotal response - I have literally never heard anyone complain about their dishwasher not working. I have never had or used a dishwasher that didn't clean the heck out of whatever was in it. The idea that "dishwashers are bad nowadays" is completely foreign to me. And, personally, it does strike me as pretty weird that Trump and the article author consider dishwashers to be a "feminist issue."

[0]: https://aceee.org/files/proceedings/2008/data/papers/1_123.p...

[1]: https://www.reviewed.com/dishwashers/news/survey-says-1-in-5...

This is cool! I came up with something similar for hosting a few personal sites from my home network, except I did it the other way around - I built a docker image that does the SSH tunneling part. The external host is just a cheap droplet with GatewayPorts set to yes in the sshd config. A benefit of doing it this way is that you don't even have to expose localhost; I have Caddy running in another container in a docker-compose.yml file, so I can forward it directly with:

  ssh -R 80:caddy:80 -R 443:caddy:443

So all the networking happens within the network created by docker-compose.

Yes, that's the solution we came up with. One stack with lambdas, managed policies, roles, user pool, etc; one stack with the APIGateway::RestApi and some resources and methods, and then another stack with yet more resources and methods. This works, but I don't think it's a great solution. Wouldn't it be preferable to have one stack that encompasses the whole API for one service?

I'm guessing it's heavily dependent on what you're using it for, what kind of resources are you describing in CFN?

In my case, it's Lambda + API Gateway that's the main culprit. For each endpoint in an API, there's a resource for the lambda itself, and a managed policy, role, log group, subscription filter, API resource, method, lambda permission, model, and additional OPTIONS method for CORS purposes. With a setup like that, you can hit the limit with a moderately-sized API.

IMO the limits of CloudFormation are a bigger pain point than they're made out to be here. The limit of 200 resources per stack is easy to hit, and so is the 450KB template size limit (well, it's possible at least). It's frustrating to need to spread a single service across three stacks because it has a lot of API Gateway endpoints. The real answer is nested stacks, but those still count towards the (raisable) total stack limit of 200.

There's some great information about how GPUs are organized here. It's interesting that GPUs and CPUs aren't that different, even though maximizing performance requires different considerations. SIMD lanes are just wider on the GPU, and you have to treat memory differently (registers are bigger, main memory has higher latency but better bandwidth, etc).

It's also funny that Nvidia lists the total number of SIMD lanes as "CUDA cores", meaning that a single compute unit with 64 SIMD lanes counts as 64 CUDA cores. That's cheating, if you ask me :P

This is a fantastic tool! When I was younger, it was great to be able to experiment without needing any hardware and while having more visibility into what was happening. Especially cool that it lets you play with memristors.