It is a wonderful catalog, but I don't find it to be as useful for learning to tie the actual knots as books by Budworth, Pawson, etc. (or Youtube, these days)
One of the cool aspects of knots for this audience is that they have a unix-like aspect where multiple individually-useful knots can be "piped" together, the example I like to use is the Trucker's Hitch:
I think "If water kill your child / Water you go use" is fairly profound, and a good demonstration of the idea that the pidgin expression refers to. And it rocks, of course.
The dangers are obvious (and also there are some fascinating insights into how healthcare works practically in China). I wonder if some kind of "second opinion" antagonistic approach might reduce the risks.
Medical Advice Generative Adversarial Networks would be a good idea.
I see some of this adversarial second-guessing introspection from Claude sometimes. ("But wait. I just said x y and z, but that's inconsistent with this other thing. Let me rethink that.")
Sometimes when I get the sense that an LLM is too sycophantic, I'll instruct it to steelman the counter-argument, then assess the persuasiveness of that counter-argument. It helps.
I hadn't really even seen much in the way of recent, first / second person accounts of what it's like to receive chronic care in modern China. It's sad but maybe not surprising to see that it's dysfunctional in its own special way.
Worth mentioning that though tea does contain polyphenols and flavinoids which are good for us (and l-theanine and caffeine which we enjoy introducing to our nervous systems), it's had a much bigger impact on health historically because it required us to heat water to boiling (or near boiling, depending on what kind of tea you're making).
Also, can't miss a chance to spice things up with the mention of adding salt to brewed tea[1]. Which is heretical, but seems palatable to me, though I probably wouldn't do it to good tea.
When I switched to black coffee I read that putting a tiny bit of salt in cuts the bitterness. It works and the amount of salt needed is so small that you don't taste it, less than a pinch.
Likewise, it enhances things like smoothies, martinis, and damn near anything with bitterness or sweetness in their profiles, generally added at levels that are not perceptible as "salty".
It's gross, but of course we think many ISPs are abusive in similar ways? I haven't ever used a Starlink connection, I wonder if their latency a problem for VPNs or tunneling.
I've recently spent a few hundred hours playing Arc Raiders on Starlink from a small island in the Pacific. ~80ms ping to Australian servers is pretty mindblowing. Jitter and packet loss also tend to be insignificant in the absence of obstructions.
My home server back in New Zealand is behind CGNAT and I had issues with high birate (>25Mbps) HTTPS streaming over Tailscale. I suspect MTU size causing packet fragmentation combined with DERP relay fallback under CGNAT was the culprit, but that's outside my expertise to diagnose fully.
Reverse proxying to a VPS in Sydney with Pangolin achieved much better performance, almost 100Mbps over WebDAV. Somewhere inbetween I tried SMB over Cloudflare WARP (~70Mbps), but allowing Cloudflare to terminate TLS seemed incongruent with self-hosting everything else.
Indeed that is the case - all the other major consumer ISPs have ties with media companies and have much more incentive to collect and abuse user data than Starlink does.
Consistent 25-35ms to 1.1.1.1. You won't see >60ms unless you're deprioritized, and that's about your choice of plan not about what the network can do.
i have my starlink plugged directly into a gl.inet router that runs a wireguard client. all of the clients connect to the gl.inet wifi. absolutely nothing unencrypted goes out the starlink wan.
it works fine.
i have the exact same setup at home with cox cable, because they will data mine the shit out of your traffic (and they have your phone number and home address to link it to). most terrestrial residential isps do this shit. vpn everything.
I agree they want the face data, but I think it's less clear they want to "hand it" (presumably that's really "sell it"?) to third parties. My sense is Google and Apple and Meta are amassing data for their own uses, but I haven't gotten the impression they're very interested in sharing it?
Sharing it is bad for business; selling insights derived from it for ad placement is the game. Faces definitely contain some useful information for that purpose.
also, even you think about using it "their own uses" - much of that is scrutinizing you to make you better susceptible to ads and other solicitations by their paying clients. I mean, people are not the clients of Google and Meta - they're the raw material.
your links don't disprove OP's main point at all. being forced to share data to the government is different than actively collecting data to sell to other third parties. these companies have tons of incentive to collect user data, but very little to sell it. i think that nuance is important to understand. if you think i'm wrong, try going to facebook or google and asking to buy some user data. you cannot.
you are correct. having that data is one of their competitive advantages, it makes no sense to sell it. they will collect as much as possible and monetize it through better ads, but they don't sell it
I'm not a fan of Tailwind, but I can see that it's probably reasonable for code gen to be able to write / extend projects that use Tailwind, since it's in pretty widespread use. For a new project, maybe it could ask if you want to use Tailwind or just keep things vanilla?
I was nodding along until your last paragraph - SSGs encourage letting other people own parts of your personal site, really? Sure, people bolt on Disqus or something, but otherwise I am not sure I follow the argument. Isn't part of the appeal of SSGs that all you have is a bunch of html/css/js that you can drop on any server anywhere (even a solar-powered RPi can serve a lot of requests[1])?
> Isn't part of the appeal of SSGs that all you have is a bunch of html/css/js that you can drop on any server anywhere (even a solar-powered RPi can serve a lot of requests[1])?
This is the part I'm struggling with. That's the view I held from 2016 - 2024. Practically though, it's only true if you want a leaflet website with 0 interactivity.
If you want _any_ interactivity at all (like, _any_ written data of any kind, even server or visitor logs) then you need a server or a 3rd party.
This means for 99% of personal websites with an SSG, you need a real server or a 3rd party service.
When SSGs first came around (2010 - 2015) compute was getting expensive, server sides were getting big and complex, bot traffic solutions were lame, and all the big tech companies started offering free static hosting because it was an easy free thing to offer.
Compare this to now, 2026, it's apparently nothing special to handle hackernews front page on free or cheap compute. Things like Deno, Bun, even Go and Python make writing quick, small, modern server sides so much quicker, easier and safer. Cloudflare and or crowdsec can cover 99% of bot and traffic issues. It's possible to get multiple free multiple GB compute instances now.
I didn't mean to imply there's some sinister plot of people maliciously encouraging people to use SSGs to steal their stuff, but that's the reality that modern personal webdev has sleepwalked into. SSGs were first sold to make things better performing and easier than things were at the time. Pretty much any "server anywhere" you own now will be able to run a handwritten server doing SSR markdown -> HTML now.
So why force yourself to have to start entertaining ideas like making your visitors download multiple megabyte client side index files to implement search, or embedded iframes and massive JS external libraries for things like comment sections? Easier looking SSG patterns like that typically break all the stuff required to keep the web open and equal, like screen readers, low bandwidth connections and privacy. (Obviously SSR doesn't implicity solve these, but many of these things were originally conceived with SSR in mind and so are naturally more compatible).
Ask anyone who's been in and out of web dev for more than 15 years to really critically think about SSGs in depth, and I think they'll conclude they offer a complete solution for maybe 1% of websites, but seem to be recommended in 99% of places as the only worthy way to do websites now. But when you pick it apart and try it, you end up in Jeff's position: statically rendered pages (the easy bit) and a TODO with a list of compromising options for basic interactivity. In 5 years time, he'll have complex SSG pipelines that's running almost 24/7, or a complex mesh of dependencies on external services that are constantly changing or trying to start charging him more to deal with his own creations.
Ah, that makes more sense. I would agree that for sites that need more than the bare minimum server-side still makes a lot of sense (I was just confused here in the context of little personal sites / blogs).
Yes, your calculus is exactly like mine - there are things to like about the Round (personally I just find round watches more aesthetically pleasing, we've had a couple hundred years of mostly round cases...), but I want longer battery and a shorter wait to get my watch.
One of the cool aspects of knots for this audience is that they have a unix-like aspect where multiple individually-useful knots can be "piped" together, the example I like to use is the Trucker's Hitch:
https://www.animatedknots.com/truckers-hitch-knot
(which also can be tied in multiple ways, depending on which knots you combine to make it)
reply