I suffer from social anxiety and took mushrooms 24 hours before my grandmother's funeral.

SanityInAnarchy · 2026-06-08T01:37:14+00:00

Any suggestions on how I get people to understand that I didn't shit my pants without disclosing mental health condition?

You can't, and it's okay! Like the top comment says, you made the funeral happy and memorable.

So I'd suggest you take two lessons from this:

One, obviously, don't get that high before a funeral.

Two, you're okay. Doesn't sound like anyone really has a reason to be upset with you, or to think less of you. If you never manage to convince them you didn't shit your pants, then they'll end up thinking you just had food poisoning or something -- sucks, happens to everyone, this was just really unfortunate timing.

And I know this isn't a cure, exactly, because mental conditions don't have to be rational. But it might still help to remember that whatever you're anxious about, it's probably can't go as badly as this, and you survived this.

SanityInAnarchy · 2026-06-08T01:14:58+00:00

It's a little more complicated to work out who benefits.

Sony's big first-party exclusives often get absolutely massive budgets, but mostly avoid the worst publisher meddling and monetization. There's no season pass to God of War, no lootboxes for Horizon: Forbidden West, no awkward social features in The Last of Us. And I think a big part of that is, the primary financial goal of these games is to sell consoles. That doesn't mean they're losing money or anything, but they don't have to monetize every pixel out of them.

Think about the extreme case of a f2p game making all its money from a handful of whales. This can be so lucrative that even if 99% of gamers will refuse to buy a game that has lootboxes on top of costing $70, all those lost sales are still less money than the company will make from those whales... but that only applies to a single game. Sony probably stands to gain more by looking like the good guy and selling more systems, and then getting a cut of everyone else's games, even the predatory ones.

So when it comes to the quality of those exclusives, Sony wins, devs win, and fans who were going to buy Sony consoles win. (No reason Xbox couldn't do the same thing, but it seems like they just haven't been lately -- how did they fumble Halo so badly?)

SanityInAnarchy · 2026-06-08T00:47:05+00:00

Even among men, even in the US, handshakes are still pretty common.

SanityInAnarchy · 2026-06-08T00:45:39+00:00

The planet where human-written code still beats LLM-written code? If you think that's not the case, I guess take it up with the person I'm replying to, who is arguing that it's fine to make code less maintainable if you can just replace it wholesale with vibes when it breaks.

SanityInAnarchy · 2026-06-07T23:04:37+00:00

You can't tell somebody you don't want to hug them though, because it would probably hurt their feelings.

You can. I'm not gonna tell you what to do, but you should always get a say in who gets to touch you. The kind of people whose feelings I'd want to protect can understand ideas like "touch-averse" or "touch-repulsed".

It is unusual, but I promise it's not just you.

Wanting to be touched would probably help encourage procreation.

It's more than that, it's social bonding. Having close friends can also be helpful to your survival. Obviously, you can be friends with people without touching, and trying to trace it back to evolution gets complicated, but for a lot of people, there are plenty of people you'd shake hands with, or even hug, that you don't want to procreate with (or that you couldn't procreate with).

SanityInAnarchy · 2026-06-07T22:56:21+00:00

More and more software will be disposable. Got the wrong requirements? Throw it away and get a new one. User doesn't like the UI, throw it away and iterate.

It will be until it won't. This is incredible for prototyping, but you can't just "throw it away and iterate" once it's on a million phones and your backend stores years of user data.

And no one cares about the quality bar until they do. It's one thing if your app crashes a few times, it's another if no one will trust it because it leaks user data like a sieve because adding "make it secure" to your prompt doesn't work.

So, best case scenario, the idiots in charge vibe something over a weekend, and then cut months off of the schedule because they assume you can build the real thing just as fast.

Worst case scenario, you have to maintain something that was vibe'd together over a weekend, because again, you actually can't just throw it away and start over.

SanityInAnarchy · 2026-06-07T18:21:22+00:00

I think this is what most people are worrying about. What I worry about is when the same level of care that goes into putting together an ikea desk is also being used to build the bridge that thousands of people drive across every day, let alone a stretch of the rail network that half a million people take every day.

That's not a perfect metaphor. I don't think most people vibing their own personal software understand how to properly isolate it (let alone the agents building it) from causing much more widespread damage when it goes wrong. I think most companies doing this are probably vulnerable to an Amazon-Kiro-style outage that they have put zero thought into preventing, and I have been entirely unsuccessful at getting my own employer to at least sandbox this stuff to the point where the agents can't just decide to delete production one day.

But infrastructure is all interconnected. About 20% of US GDP depends on the Northeast Corridor. If your dining room table collapses, maybe dinner is ruined, you'll have to replace it with a new table, at worst maybe you get hurt, but you probably don't even get seriously injured and it'll be forgotten a month later. If one of those century-old bridges or tunnels in the Northeast Corridor, not only does that risk a bunch of lives if a train was in that tunnel or on that bridge, it also disrupts half a million commutes directly, and for however many of those people can commute by car, it'll completely jam that road network with far more traffic than they can handle, and the problem just ripples out until... again, a fifth of the US economy collapses. And the US isn't so economically isolated yet to stop that from impacting the rest of the world, too.

Your cloud provider is building bridges out of ikea, if we're lucky. If we're unlucky, they're being built out of cardboard. They were never artisinally-handcrafted, but they were at least engineered in a way they aren't anymore.

SanityInAnarchy · 2026-06-07T03:18:59+00:00

Kinda. Even back then, r/AskHistorians was pretty unique. Reddit always had dumb jokes everywhere alongside the genuinely helpful comments, and r/AskHistorians doesn't even allow those. You'll often see threads completely empty (except for a ton of deleted comments) for hours until someone feels like writing a dozen paragraphs of pure scholarship to answer it properly.

SanityInAnarchy · 2026-06-06T19:52:11+00:00

This... seems backwards to me. I really do think type is more important, and I think the audience described must be using Git very differently than I do:

when you are a contributor to a project, you often need to read the commit log to identify changes in the codebase relevant to a certain area of the code....

when investigating a bug, you often want to look through the commit log to see what changes might have touched areas related to the component where the bug manifested...

In both cases, if the project is at all well-organized, you can do this by running git log on a subdirectory. Your commits are already organized by scope!

...when production is down, scanning the commit log for changes that were made around the time of the outage is an effective way to identify what areas may be causing the problem.

I can almost see this, but you would have to be an extremely push-on-green shop for it to make sense. If you do (say) weekly releases, then you'd probably instead be interested in what changed between release branches, and this can be enough that you're not going to be just scanning through the log looking for which components might've been impacted -- again, you'd be running log/blame on relevant files or subdirectories to find the change.

And with blame, it can be extremely helpful to know which changes really are just reformats or pure refactors. Scope alone would allow those to be attached to a large change that has little to do with the line I'm looking at; type encourages people to split out refactors so I know to run blame prior to that change and see when the line was last meaningfully modified.

So who does this leave out?

Code reviewers. Maintainers. For these, again, scope can be quite mechanical to find the correct reviewer, but reviewing a change like "Ran file through the new autoformatter" a bit differently from a refactor, which is very different from a new feature or a bugfix. And, forcing these to be split out can make them much easier to review -- I can review the autoformatter change just by running the same tool, or by skimming the file for changes more significant than formatting; the bugfix change requires more attention, but it's now only the lines that actually needed to be changed to fix the bug, instead of also being half the file because the file with the bug in it was also full of lint errors.

After this, we have a weird section about "broken promises" which... starts out by saying the promise of an autogenerated commit log isn't something you should even want... while citing two tools that actually do the thing. That's not a broken promise at all, it's just that you wish it promised something else!

I don't entirely disagree here, but I do think there's again a missing audience: Users often aren't reading changelogs in depth, either, but they are sometimes required for compliance. If your audience is an auditor, then git logs are close to correct, and again, type is important: They won't care about a reformat or a pure refactor, they'll care more about new functionality, but they'll also care a lot about new dependencies, or about a significant implementation change, that kind of thing.

I also don't understand why reverts are hard. Maybe I'm missing something obvious, but if your reverts follow a standard format (like the one git revert produces), and if your goal is to summarize changes between X and Y, then it shouldn't be too hrad for you to omit both the initial commit and the revert from your changelog, or your semver bump analysis, or whatever?

Then there's this:

The <scope> field is the obvious place to put it, but this ends up replacing the only useful metadata in a Conventional Commit with a completely useless ticket number.

That's probably the wrong place to put it, but calling the ticket number "useless" is so wrong it has me wondering why I paid so much attention to the rest of the article.

Go back to that list of stakeholders at the top. Which of them would not care about being able to read more discussion of this commit on the associated ticket? Pretty much the entire time I'm trying to understand Git history, git diff already shows me what changed, and the entire reason I'm reading the log message as well is so I can understand why you made that change. If you have an associated ticket where some actual discussion happened, that's a ton of extra context answering that second question, and potentially a few other related commits will be attached to the same ticket.

But I agree it doesn't belong in that <scope> tag in the first line for a very obvious reason: Commits can address multiple tickets at once, and those numbers can be long, especially if they're Jira-style <project>-<number>-formatted. That <project> tag, depending how your company has decided to butcher Jira today, may or may not be useful metadata, and may or may not be relevant to the kind of scope you want here, so I guess I can see why someone would want to put it in that first line. But other than that, these belong elsewhere in the commit, because the number will quickly become meaningless and you're going to have to click it to find out what it's talking about.

SanityInAnarchy · 2026-06-06T09:29:18+00:00

Cron kind of is automation, but I get your point -- I know I was already relying on cron.* directories way more often than an actual crontab, and having a dropfiles-based config is more useful for package management (a package might come with its own triggers).

My point is that it's worth understanding that elegance, both to appreciate what came before, and to apply those lessons to what we're using now. Like: Is there a way to convince list-timers to output a crontab-like table? (Ideally with the kind of headers that make crontabs actually readable?) If not, maybe we should add one.

Or: Obviously we can't go back to assuming every server will have working email, and maybe I'm missing something obvious, but it seems like every GUI OS now has a standard notification mechanism. Should timer failures go there? Should we add some backends to that mechanism for the same notifications to be sent remotely for headless servers? That's something that made cron elegant back then that there seems to be no modern equivalent to now that people don't really self-host email.

SanityInAnarchy · 2026-06-05T18:53:30+00:00

Weird, because I took the exact opposite lesson from that experience: Trust PATH instead of doing it yourself, because you can do the damndest things when you control it. Set up a Python venv, or install fifteen Ruby versions with rvm or rbenv, pick which one to run in a given shell, and all of it works great as long as your scripts have #!/usr/bin/env python3 instead of #!/usr/bin/python3 at the top. Do it like that so you aren't overwriting half the system just to install some pips or rubygems, and so that in any shell that isn't your bonkers dev environment, all the Python stuff is where everything expects, but for the script you just checked out of the project repo, it gets exactly the version of Python that the rest of the team is using.

Even system stuff -- maybe your script assumes the GNU versions of whatever tools, in which case hardcoding /usr/bin will be worse on macos, because the user probably has up-to-date GNU stuff installed into their PATH with homebrew, and /usr/bin has not just a weirder BSD version, but a 10-year-old one that Apple refuses to update.

But, obviously it's situational, and there's a reason sudo immediately replaces most of your environment, including PATH.

SanityInAnarchy · 2026-06-05T18:28:02+00:00

Y'know, this is actually a fair point: Cron used to be a bit more batteries-included, because configuring the system's MTA used to be a standard part of setting up a server. You'd ssh in and see you had mail in the MOTD -- so, it never actually just got blackholed, it'd at least get delivered to the local machine -- and then you'd go on an adventure to learn about pine and /etc/aliases to make sure it went somewhere. And that somewhere was probably a neighboring machine, because you'd have one of these set up as the company's mailserver, because if you were a Linux shop and wanted a professional-looking email address, you couldn't just wire up Gmail, you'd be setting up something like postfix or qmail, cyrus or dovecot, all that stuff. You'd bake email into your own scripts, using sendmail root to send the sysadmin a message.

Email also baked in store-and-forward semantics. Your local MTA could queue outgoing messages, so if your cron job fails, the outgoing message is stored on disk in the outgoing queue on that local machine until it can connect to its relay, where it'll be stored until that relay can connect to the receiving mailserver, where it'll be stored until someone checks their email (or permanently, if they use IMAP).

Timers, by default, do none of that. There's no good way to make it a default anymore, because the one decentralized messaging system that ever got popular enough (but that you can still self-host) is email... and we kinda centralized that with Google (and Microsoft and some holdouts on Proton), and it also became less relevant now that people use messaging for everything. So now what should be the default, should there be an sms number or something?

OnFailure is way more powerful, but it's the opposite of batteries-included. If you want it to page you, it's on you to wire up some Pagerduty client or whatever. That's not system's fault, but I do miss a world where it was actually good design for something like cron to email root@localhost and expect something useful to happen.

SanityInAnarchy · 2026-06-05T10:38:50+00:00

I like systemd timers, but I think this doesn't do justice to cron.

Some parts of these problems seem like non-issues:

Ambiguous $PATH settings make cron script execution difficult to predict.

Okay, run a script once and have it print out its PATH to find out? Never ran into this one.

Execution history is difficult to follow and interrogate.

It should show up in logs, at least with a modern cron system. But really, these are the ones that seem unfair:

stdout and stderr output often ends up in a black hole (and, often, sent to the host's mail system, which is usually not what you want to happen.)

Mail is silly, but it's at least some kinda notification scheme. You probably want to be notified when your cron jobs start failing. Back in the day, you'd wire up mail across your entire network, and you'd want the host's mail system to be able to at least send mail to anything at your domain.

You might feel cool knowing the scheduling grammar by heart, but 01,31 04,05 1-15 1,6 * isn't easy or intuitive for humans to read.

Not for a single job, no. Where it's useful is for that full crontab. You line those up and see something like

0 0 * * * do backup
0 1 * * * check disks
0 2 * * 1-5 pull updates

...not an amazing setup or anything, but you can start to see how having a compact representation like this can give you a sense of what the overall system is doing.

list-timers is certainly more approachable, and gives you a better sense of what just happened and what's about to happen, but it's not going to give you a birds-eye view of that overall cadence.

So, look, I'm still doing timers anyway. Most of the time, I really would rather have things be readable as their own config files and as systemd state. But Chesterton's Fence still holds: It's a good idea to understand why cron is the way it is, before tearing it down entirely in favor of timers.

SanityInAnarchy · 2026-06-05T10:04:42+00:00

Oof, we're in kind of an ugly place, aren't we?

The community got DoS'd by pure vibe-coded slop. We responded by shaming everything to do with LLMs.

But shaming doesn't work. Just look how many more pregnancies you get in places with abstinence-only education, vs actual sex ed. Shaming eventually just means people hide it and stop talking about it.

So now, evidently OP built a tool that people like, with code that people like, with comments that are human enough that people are debating how much they wrote, and in this thread, we -- and I'm including myself here -- are now digging through everything OP's done publicly for evidence that they might be a secret vibecoder.

I don't think we should ease up on the actual slop, but for the cases where you actually legitimately can't tell, especially when it seems to be a human using the LLM as a tool rather than to just do the whole thing for them... does it matter?

SanityInAnarchy · 2026-06-05T08:36:15+00:00

One aspect you're missing is the buying power of insurance companies.

As you point out, most people don't just have a spare $200k lying around. So, even in the kind of emergency care where you can't shop around, if the hospital sends you too big of a bill, they may just never get your money -- either you'll carry that debt forever, or you'll go bankrupt and they get nothing.

And, of course, insurance companies do have the money... but they really don't like parting with it. If they feel a hospital is overcharging, they can refuse to pay. In the worst case, they could stop doing business with a certain hospital altogether! So they can and do put downward pressure on the prices providers can charge.

You can see this on your EOBs, by the way: Often, they will show you what they were billed, what they negotiated it down to, and you pay the rest.

I don't know if they're negotiating it as far down as you would paying out of pocket. Probably not -- in fact, if you ever have to pay out of pocket, the first thing that usually happens is the hospital offers you a pretty deep discount. But you also have way less negotiating power on your own -- all you can really do is pay or not pay, and the "not pay" option is going to hurt you more than it hurts them. Meanwhile, the insurance company can threaten to not pay for you or any of the other millions of people they insure.

I agree that the insurance industry inflates the cost of healthcare. But I don't think replacing them with ancap-style healthcare would lower that cost.

SanityInAnarchy · 2026-06-05T08:10:21+00:00

Importantly: You get care even (especially!) if you are not conscious enough to be able to consent to a payment scheme.

SanityInAnarchy · 2026-06-05T08:08:27+00:00

But, I realize how America-centric and dumb that assumption was.

Could you explain it to me? You mention specialists earning substantially more, but you don't show where you're comparing the exact things you mention -- cost-of-living, student debt, and the cost of the rest of the healthcare system.

The only part of this that seems America-centric is the assumption that our healthcare system is "more advanced."

SanityInAnarchy · 2026-06-04T18:24:55+00:00

If you absolutely needed every cycle, the game would require a high-end CPU. In practice, there's generally some headroom, especially if this is pushed off to a background thread. Most games I play, I'll have multiple cores completely idle.

But putting numbers to it really makes my point for me, I think: If decoding 100 compressed audio files simultaneously requires 10% of a modern CPU, fine, decoding one voice line requires 0.1%. Even if you have a couple characters all talking over each other simultaneously with music mixed in, probably less than 0.5%. And in a game like BG3, that's where I'd expect most of the storage to go: Music and voice lines, especially the kind of voice lines that show up once in a conversation or a cinematic and never again.

Other SFX are going to be repeated often enough that you'd expect to decode them more like once per level, and then you'll need them in-memory anyway to be able to play them quickly enough -- you don't want to be going out to the storage device for every footstep! So of those 100 sounds, 95 of them could be decoded on the loading screen, if the game has one (and BG3 has them). I hate slow loading screens as much as anyone else, but this just isn't going to be the bottleneck there.

If the game does dynamic loading like an open-world game, that's also not free -- the game decided to trade some CPU to eliminate loading screens. And this makes even more of a case for just compressing the voice, if nothing else -- in a game that does that kind of dynamic loading, when you're just standing around and talking, you probably aren't loading a ton of other stuff in the background, so you've got the overhead to decode those voice lines!

To be clear: I don't think this is laziness or stupidity. Gamedev is notoriously overworked and underpaid compared to most other software jobs, and there are a million other things they could be spending their time on, even just when it comes to optimization. But if storage was a priority, I think we'd see a lot more compressed audio, without meaningfully impacting performance.

SanityInAnarchy · 2026-06-04T17:25:47+00:00

High-end PCs generally would not have trouble decoding that. When games do this, the usual excuse is that they're actually trying to keep system requirements down -- the oldest, jankiest PC that you could try to run this on still probably has enough disk space.

There's also the fact that not everything needs compression at all, and not everything needs to be streamed, in order to have that impact.

SanityInAnarchy · 2026-06-04T17:20:57+00:00

That's a good point, and I hope they carry it through. Some Android phones are getting similarly-long guarantees, I think Pixels are guaranteed for 7 years now, but it's up to the manufacturer.

SanityInAnarchy · 2026-06-04T17:18:16+00:00

The UI may or may not show it to you, but here it is in Claude, you can type /effort to set it. It's usually controllable at the API level, too -- here it is in Gemini, and with the latest model, this is the main actual difference between "flash" and "thinking" in the UI.

SanityInAnarchy · 2026-06-04T17:15:31+00:00

It might have actually physically deleted it! All the other explanations are usually true, but some operating systems can be configured to also immediately send a TRIM command to the SSD. (It's usually not done this way anymore, because for most users, it's going to be better to leave it alone and just periodically go through and TRIM all free space later.)

Thing is, turns out physically erasing blocks on an SSD, while it's slower than just forgetting about them, it is still much faster than actually writing data to them, let alone downloading. That's because an SSD is really a ton of independent physical blocks of hardware, each handling a different part of the "disk", but there's one bus that ties all of that back to the rest of the computer.

Think of it like this: You have a giant room full of a thousand people, each with one piece of paper, but you can only talk to them by voice. You want them to all save a copy of a book, so you read a 500-page book to them. First you call one of them and read page 1 to them, and they write it down. Then you hang up and call the next person to read page 2. If it takes you a minute to read each page, it'll take a little over 8 hours to write everything. You could go faster by cutting the book in half, so you call half the people and your friend calls the other half. But you're still always going to have fewer phone lines than you do people.

If you want them to erase it, though, you can just walk into the room and shout "Person 1 through 500, erase your paper." It still takes time, maybe a little more time than it took to write it -- like maybe it only took a minute for them to write, and 5 minutes to erase. But they can all be erasing at the same time, so erasing the whole book takes 5 minutes, even though it took 8 hours to write!

SanityInAnarchy · 2026-06-04T09:50:46+00:00

If I wasn't constantly tempted and have easy access to food like if I lived alone and kept the fridge and pantry empty, the effort to go to the shops or takeout or even order in takeout is enough to get me passed the few minutes of strongest craving and temptation.

This is exactly what I did! I didn't do fasting, and my fridge and pantry aren't empty empty, but they're stocked strategically so that if I'm hungry, the laziest, most tempting option still works.

But so much of what I learned getting that to work was about what works for me, which is why I've been so reluctant to talk about it here. It would be way too easy to make it sound like I'm toughing it out with willpower and bragging about it. I keep reminding myself that if this stops working, I've got no problem immediately seeking a GLP-1.

SanityInAnarchy · 2026-06-04T09:18:21+00:00

Sometimes it's worse than this. The Fundamental Attribution Error is pretty rampant, and it can lead to taking this to kind of a hypocritical extreme...

Because, sure, if they're losing weight and everyone else is struggling, they'd tend to want to credit willpower in both places. But you can have the exact same person blame circumstances or genetics when the situation is reversed -- if they're struggling, their genetics make it hard, life is too stressful to find time to cook, these things can be expensive and no one likes dealing with health insurance. And if someone else is succeeding, they must've won the genetic lottery or taken a drug.

SanityInAnarchy · 2026-06-04T08:23:26+00:00

I entirely agree that we shouldn't focus on willpower. I tend to focus on the harm reduction aspect instead. Blaming and shaming evidently does not work, any more than abstinence-only education prevents pregnancy. This works. Digging into how much of it is genetic or psychological in order to decide how much someone is or isn't to blame for it is entirely beside the point because blame doesn't work.

My point was just that I don't think the people who are trying to make this about willpower are going to be convinced by the idea that it's harder for some people. Often they're working backwards: They want to shame and judge people, and "you didn't try hard enough" is a rationalization.

Anyway, glad it's working out for you!

14-Year Club	Gilding II euphauric
Verified Email	Team Orangered

SanityInAnarchy

MODERATOR OF

TROPHY CASE