I wonder whether government testing actually makes a material difference in food/beverage safety.
For example, when I worked for U.S. Customs and Border Protection, I was surprised to discover that the percentage of imported food/beverage actually tested for safety is very low. Like comically, microscopically, unbelievably low.
In the United States, I suspect concerns over reputation and civil litigation do more to keep our food safe than government testing.
Loved this piece. Especially that it is written in a Gonzo journalism style, including the author as part of the narrative, like a Hunter S. Thompson essay.
I sanity-checked it with two headshots of the same third party and it swung ~2.5 points, so it seems to capture state (lighting/angle/expression) more than trait.
Then I uploaded my own photo and got an unexpectedly high score, which conclusively validates the model and my rigorous n=2 study.
Your workday isn’t a monolith; it is a series of tiny tasks. Try deconstructing your job to identify intrinsic motivation.
Which micro-tasks do you look forward to? Which raise questions you think about and work on in your free time?
Which tasks do you avoid, put off, or find immediately draining?
If you can’t identify interesting tasks, you are likely looking at too high a level of abstraction. Break “working with clients” down until you find the specific unit of work (e.g., “debugging edge cases” vs. “proofreading emails”) that sparks interest.
After sorting tasks into intrinsically motivating or not, look for a role that involves about 20% more time on the interesting micro-tasks and 20% less on the boring ones. If you do this every few years, you drift toward a career you enjoy without needing a radical “reset.”
This approach led me down an unexpected path: law firm attorney -> government attorney -> regulatory consultant -> small-business operator. Now, I am looking at moving to a role that involves at least 20% more time on software development (intrinsically interesting to me) and 20% less time chasing unreliable people (particularly draining to me). I never set out to change my “identity,” but focusing on the micro-tasks I actually enjoy has allowed me to engineer a career I enjoy on a day-to-day basis.
Yes, this is exactly the distinction I was struggling to articulate.
“Online” has collapsed into a single bucket that includes friends-only play, strangers, stores, chat, downloads, etc. What I want (and what you’re describing with running servers) is a way to scope online access: friends-only communication, no discovery, no stores, no strangers.
The frustrating part is that many platforms either (a) force these things to come as a bundle, so saying “yes” to playing with friends implicitly says “yes” to a much larger surface area; or (b) make the unbundling process so complex that well-meaning parents fail and exhausted parents give up.
The etymology I’ve heard isn’t even listed in the article.
One theory traces “Kentucky” to early forms like Cantucky or Cane-tucky, referring to the region’s vast river-cane brakes, Kentucky River cane, North America’s only native bamboo, which early inhabitants associated with fertile, game-rich land.
A weak judgment betrays itself in the indiscriminate use of fine punctuation; for when the em-dash is made universal, it ceases to be distinguished, and becomes merely another form of hyphen.
Let the em-dash remain upon the height of style. Let the hyphen toil in the shade of the valley. And let the en-dash—patient, capable, and unjustly overlooked—at last be admitted to polite society, where it may properly mediate matters of form–function.
I wanted to share a quick piece of feedback from a potential reader's perspective: There are several small inconsistencies in the intro text (e.g., inconsistent capitalization of 'Rust' vs 'rust', grammar typos).
In a domain like OS development where extreme precision is required, these small errors can subconsciously signal to readers that the technical details might also be imprecise. A quick polish of the documentation would go a long way in establishing authority and trust for the rest of the book.
The U.S. federal government is bad at redactions on purpose.
The offices responsible for redactions are usually in-house legal shops (e.g., an Office of Chief Counsel inside an agency like CBP) and the agency’s FOIA office. They’re often doing redactions manually in Adobe, which is slow, tedious, and error-prone. Because the process is error prone, the federal government gets multiple layers of review, justified (as DOJ lawyers regularly tell courts) by the need to “protect the information of innocent U.S. citizens.”
But the “bad at redactions” part isn’t an accident. It functions as a litigation tactic. Makes production slow, make FOIA responses slow, and then point to that slow, manual process as the reason the timeline has to be slow. The government could easily buy the kind of redaction tools that most law firms have used for decades. Purpose built redaction tools speed the work up and reduce mistakes. But the government doesn't buy those tools because faster, cleaner production benefits the requester.
The downside for the government is that every so often a judge gets fed up and orders a normal timeline. Then agencies go into panic mode and initiate an “all hands on deck.” Then you end up with untrained, non-attorney staff doing rushed redactions by hand in Adobe. Some of them can barely use a mouse. That’s when you see the classic technical failures: someone draws a black rectangle that looks like a redaction, instead of applying a real redaction that actually removes the underlying text.
He and one other guy coded this together for a few years. Really good reviews on Steam.
https://store.steampowered.com/app/3057670/Pluto/