"Why does this only happen in the USA?"
Sep. 11th, 2025 08:26 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
seawaspAs I mentioned in my prior post, this event and discussion gave me a bit of an epiphany. It's probably NOT an original one -- I'm sure other people have discussed this point -- but I personally haven't seen it discussed, so I'm going to do so here.
The perennial argument following any public shooting here (slightly less for individually targeted people like Mr. Kirk, but still present) almost always boils down to staunch defenders of the Second Amendment versus people who just want to NOT see random children or adults shot down on a daily basis. And one of the most common soundbite/talking points will be things like "Nothing could be done to stop it, says only country where this happens".
The Second Amendment defenders will trot out their own points, including "kids carried guns to school regularly back in the day and you didn't have lots of school shootings" and "guns don't shoot people, people do" and so on.
A lot of this ends up raising the question: WHY does this happen here in the USA so often, and so rarely elsewhere -- even in places where there are a lot of guns? What's so different about the USA compared to all these other countries?
Well, you know, there are actually a LOT of differences between the USA and most other countries; perhaps the most obvious is that we're a short-term (in the historic sense) patchwork of a lot of different subcultures, divided by states (which function as semi-independent countries INSIDE the country) as well as by background, with populations ranging from surviving Native American populations who are STILL at or near the bottom of the pecking order despite being the ones who were living here when Europeans first arrived, to the descendants of those Europeans, descendants of entire *cities* worth of slaves, descendants of slave owners, refugees, and more.
But in this case, I think the difference that drives the increase in public shootings is something that's so very American that we don't even think about it as a problem -- because it's just the way things have been going here.
Most other civilized countries have safety nets for people. The most obvious is healthcare. Here, heathcare is gated -- and often destructively so. Most other countries have universal healthcare in one form or another.
Most countries also have some other forms of social support -- things that generally reduce, if not eliminate, the number of people for whom the loss of a job equates to instant poverty and living on the street.
Most countries have wide-based educational support so that people who want to learn don't have to go into a hundred thousand dollars of debt just to finish college.
We -- primarily driven, it's now obvious, by the Heritage Foundation and their associates since the 1980s, though starting with RMN in the late 60s - early 70s -- have been steadily eroding the social safety net.
"What's that got to do with shootings?"
Well, more and more people are feeling more and more pressure. If you have a FEW people in desperate circumstances, this usually is a self-limiting problem -- there's many people around who can spare a bit of money, time, or resources, and most of them aren't under desperate strain.
But if more, and more, and more people are under mounting pressure -- "how can I afford the operation?" "I have to keep this job or my whole family loses insurance!" "I have to put up with everything at work because if I miss one payment on my rent I'm out", then there's less "give" in the system. There's more of a feeling of danger, of fear, of potential loss around every corner.
And that means the fragile ones and the angry angry ones will ALSO have less support to get past their own crises. Mom and Dad don't have the energy to really listen to and understand little Jack because they're both working in grinding jobs that force them to act as though the pressure is perfectly normal -- and they're having their own personal problems, that weaken both of them just when their kids need their strength. Or maybe there's JUST Mom or JUST Dad, which makes it harder.
In short, what we're seeing is the increasing sounds of strain on the very fabric of society, as we disassemble the supports that used to keep the strain from becoming unsupportable. THAT is why an increasing number of isolated, angry, terrified people are breaking in such a violent way. No one hears them until they shoot, and even if someone did hear them, no one had anything left to give them as support and relief.
When you create a pressure cooker and keep stoking the fires, the relief valve starts to scream.
And that's the warning before it all explodes.
Really, I don't write in riddles.
Sep. 11th, 2025 07:59 amseawaspI've been notified by three people (so far) that I'm now _persona non grata_ because of a post I made regarding the killing of Mr. Charlie Kirk yesterday.
Two of them made statements that clearly imputed to me statements that I hadn't made, but that they had apparently inferred from what I HAD said.
This is unfortunate, and I don't expect to change their minds (or, in general, anyone's mind, online) about such things. They've made their judgment, they now have that perception of me, and arguing about how someone perceives you is usually a lost cause from the start.
But for the record, I try to write *exactly* what I mean. If I mean to say "Ho, he deserved to die, good job!", I'd quite literally post exactly that.
What I posted said that I don't approve of killing people as a solution to the problem and I'd like to live in a world where that's not viewed as an appropriate solution.
I did then note the irony of the fact that he had explicitly said (very shortly after a school shooting) that some gun deaths were a necessary price for maintaining the Second Amendment's protections.
I also noted that I wouldn't waste prayers, if I prayed, on him, given what he promoted in life.
NONE of that says "I approve of killing people who disagree with me politically". If I want to say that, I don't need to type that long (especially on FB from a phone, which is a big PITA). I can say "Shooting people like Charlie Kirk is a public service and we need more public servants".
I don't try to hide my beliefs in my fiction OR my nonfiction. The closest I get to "subtle" (aside from hiding little Easter Eggs in the Arenaverse) is when I had Jason Wood make an anti-Patriot Act speech thinly disguised as a protest against werewolf-triggered paranoia (since the Morgantown Event is basically his world's 9/11).
If I want to say something, I say it. And I say it very carefully.
If I DON'T say a particular thing, odds are excessively strong that I don't, in fact, mean that thing.
Again for the record, no, I don't approve of people shooting people under any circumstances aside from actual self-defense (he's coming at me with intent to injure or kill). I don't even approve of it in wartime, though by the nature of the beast it does and will happen and I'm generally not going to judge the soldiers for it.
I think Charlie Kirk was doing the world a lot of disservice, and I wish he hadn't done some of the things he was doing, but that didn't earn him a bullet nor do his family and friends deserve the shock.
At the same time, he as an individual leaves me with no particular fond feelings and I feel no obligation to pretend about it.
And I find it grimly, ironically amusing that he publicly espoused the "necessity" of some number of gun deaths to protect the Second Amendment.
This is not, in any way, an approval of the killer or of assassination in general.
I am UNSURPRISED that such things are happening -- to people on both sides of the aisle.
This event and some discussion after it, though, did give me a different epiphany, which I'll write about separately.
At Least One Underlying Condition [Covid, US, Patreon]
Sep. 11th, 2025 03:58 amsiderea0.
Hey, Americans! Look sharp, the Trump Administration is trying to play a head game on you about Covid vaccines, and it's apparently working, because I see nobody talking about this in the news or on social media.
There's a lot of complexity and chaos right now about what is available to whom and how to get it. Things are changing fast, especially on the state level. I hope to discuss it in another post, but there's one thing in particular I want to clarify for you.
As you've probably heard, week and a half ago, the FDA changed the authorization for the Covid vaccines, in a way which curtails access. The thing that people are hearing is that for people under 65 years old the Covid vaccines are not authorized with some exceptions.
That's technically correct, but badly misleading. A lot of people hear "not authorized" and stop really listening to the rest of the sentence. They hear "with some exceptions" and assume they're not likely to be one such, and won't qualify to get it, and tune right out.
To be cynical for a moment, you're meant to assume that.
But it turns out you're one of the exceptions. Probably. How can I know that?
The actual language from the FDA authorization just issued ( Read more [2,750 words] )
This post brought to you by the 218 readers who funded my writing it – thank you all so much! You can see who they are at my Patreon page. If you're not one of them, and would be willing to chip in so I can write more things like this, please do so there.
Please leave comments on the Comment Catcher comment, instead of the main body of the post – unless you are commenting to get a copy of the post sent to you in email through the notification system, then go ahead and comment on it directly. Thanks!
(no subject)
Sep. 11th, 2025 05:17 am![[syndicated profile]](https://www.dreamwidth.org/img/silk/identity/feed.png){kind=small}
apod_feed
It is one of the largest nebulas on the sky -- why isn't it better known?
first-class merges and cover letters
Sep. 11th, 2025 02:38 amfanfhttps://dotat.at/@/2025-09-11-cover-letter.html
Although it looks really good, I have not yet tried the Jujutsu (jj) version control system, mainly because it's not yet clearly superior to Magit. But I have been following jj discussions with great interest.
One of the things that jj has not yet tackled is how to do better than git refs / branches / tags. As I underestand it, jj currently has something like Mercurial bookmarks, which are more like raw git ref plumbing than a high-level porcelain feature. In particular, jj lacks signed or annotated tags, and it doesn't have branch names that always automatically refer to the tip.
This is clearly a temporary state of affairs because jj is still incomplete and under development and these gaps are going to be filled. But the discussions have led me to think about how git's branches are unsatisfactory, and what could be done to improve them.
branch
One of the huge improvements in git compared to Subversion was git's support for merges. Subversion proudly advertised its support for lightweight branches, but a branch is not very useful if you can't merge it: an un-mergeable branch is not a tool you can use to help with work-in-progress development.
The point of this anecdote is to illustrate that rather than trying to make branches better, we should try to make merges better and branches will get better as a consequence.
Let's consider a few common workflows and how git makes them all unsatisfactory in various ways. Skip to cover letters and previous branch below where I eventually get to the point.
merge
A basic merge workflow is,
- create a feature branch
- hack, hack, review, hack, approve
- merge back to the trunk
The main problem is when it comes to the merge, there may be conflicts due to concurrent work on the trunk.
Git encourages you to resolve conflicts while creating the merge commit, which tends to bypass the normal review process. Git also gives you an ugly useless canned commit message for merges, that hides what you did to resolve the conflicts.
If the feature branch is a linear record of the work then it can be cluttered with commits to address comments from reviewers and to fix mistakes. Some people like an accurate record of the history, but others prefer the repository to contain clean logical changes that will make sense in years to come, keeping the clutter in the code review system.
rebase
A rebase-oriented workflow deals with the problems of the merge workflow but introduces new problems.
Primarily, rebasing is intended to produce a tidy logical commit history. And when a feature branch is rebased onto the trunk before it is merged, a simple fast-forward check makes it trivial to verify that the merge will be clean (whether it uses separate merge commit or directly fast-forwards the trunk).
However, it's hard to compare the state of the feature branch before and after the rebase. The current and previous tips of the branch (amongst other clutter) are recorded in the reflog of the person who did the rebase, but they can't share their reflog. A force-push erases the previous branch from the server.
Git forges sometimes make it possible to compare a branch before and after a rebase, but it's usually very inconvenient, which makes it hard to see if review comments have been addressed. And a reviewer can't fetch past versions of the branch from the server to review them locally.
You can mitigate these problems by adding commits in --autosquash
format, and delay rebasing until just before merge. However that
reintroduces the problem of merge conflicts: if the autosquash doesn't
apply cleanly the branch should have another round of review to make
sure the conflicts were resolved OK.
squash
When the trunk consists of a sequence of merge commits, the
--first-parent log is very uninformative.
A common way to make the history of the trunk more informative, and deal with the problems of cluttered feature branches and poor rebase support, is to squash the feature branch into a single commit on the trunk instead of mergeing.
This encourages merge requests to be roughly the size of one commit, which is arguably a good thing. However, it can be uncomfortably confining for larger features, or cause extra busy-work co-ordinating changes across multiple merge requests.
And squashed feature branches have the same merge conflict problem as
rebase --autosquash.
fork
Feature branches can't always be short-lived. In the past I have maintained local hacks that were used in production but were not (not yet?) suitable to submit upstream.
I have tried keeping a stack of these local patches on a git branch that gets rebased onto each upstream release. With this setup the problem of reviewing successive versions of a merge request becomes the bigger problem of keeping track of how the stack of patches evolved over longer periods of time.
cover letters
Cover letters are common in the email patch workflow that predates git, and they are supported by git format-patch. Github and other forges have a webby version of the cover letter: the message that starts off a pull request or merge request.
In git, cover letters are second-class citizens: they aren't stored in the repository. But many of the problems I outlined above have neat solutions if cover letters become first-class citizens, with a Jujutsu twist.
A first-class cover letter starts off as a prototype for a merge request, and becomes the eventual merge commit.
Instead of unhelpful auto-generated merge commits, you get helpful and informative messages. No extra work is needed since we're already writing cover letters.
Good merge commit messages make good
--first-parentlogs.The cover letter subject line works as a branch name. No more need to invent filename-compatible branch names!
Jujutsu doesn't make you name branches, giving them random names instead. It shows the subject line of the topmost commit as a reminder of what the branch is for. If there's an explicit cover letter the subject line will be a better summary of the branch as a whole.
I often find the last commit on a branch is some post-feature cleanup, and that kind of commit has a subject line that is never a good summary of its feature branch.
As a prototype for the merge commit, the cover letter can contain the resolution of all the merge conflicts in a way that can be shared and reviewed.
In Jujutsu, where conflicts are first class, the cover letter commit can contain unresolved conflicts: you don't have to clean them up when creating the merge, you can leave that job until later.
If you can share a prototype of your merge commit, then it becomes possible for your collaborators to review any merge conflicts and how you resolved them.
To distinguish a cover letter from a merge commit object, a cover letter object has a "target" header which is a special kind of parent header. A cover letter also has a normal parent commit header that refers to earlier commits in the feature branch. The target is what will become the first parent of the eventual merge commit.
previous branch
The other ingredient is to add a "previous branch" header, another special kind of parent commit header. The previous branch header refers to an older version of the cover letter and, transitively, an older version of the whole feature branch.
Typically the previous branch header will match the last shared version of the branch, i.e. the commit hash of the server's copy of the feature branch.
The previous branch header isn't changed during normal work on the feature branch. As the branch is revised and rebased, the commit hash of the cover letter will change fairly frequently. These changes are recorded in git's reflog or jj's oplog, but not in the "previous branch" chain.
You can use the previous branch chain to examine diffs between versions of the feature branch as a whole. If commits have Gerrit-style or jj-style change-IDs then it's fairly easy to find and compare previous versions of an individual commit.
The previous branch header supports interdiff code review, or allows you to retain past iterations of a patch series.
workflow
Here are some sketchy notes on how these features might work in practice.
One way to use cover letters is jj-style, where it's convenient to edit commits that aren't at the tip of a branch, and easy to reshuffle commits so that a branch has a deliberate narrative.
When you create a new feature branch, it starts off as an empty cover letter with both target and parent pointing at the same commit.
Alternatively, you might start a branch ad hoc, and later cap it with a cover letter.
If this is a small change and rebase + fast-forward is allowed, you can edit the "cover letter" to contain the whole change.
Otherwise, you can hack on the branch any which way. Shuffle the commits that should be part of the merge request so that they occur before the cover letter, and edit the cover letter to summarize the preceding commits.
When you first push the branch, there's (still) no need to give it a name: the server can see that this is (probably) going to be a new merge request because the top commit has a target branch and its change-ID doesn't match an existing merge request.
Also when you push, your client automatically creates a new instance of your cover letter, adding a "previous branch" header to indicate that the old version was shared. The commits on the branch that were pushed are now immutable; rebases and edits affect the new version of the branch.
During review there will typically be multiple iterations of the branch to address feedback. The chain of previous branch headers allows reviewers to see how commits were changed to address feedback, interdiff style.
The branch can be merged when the target header matches the current trunk and there are no conflicts left to resolve.
When the time comes to merge the branch, there are several options:
For a merge workflow, the cover letter is used to make a new commit on the trunk, changing the target header into the first parent commit, and dropping the previous branch header.
Or, if you like to preserve more history, the previous branch chain can be retained.
Or you can drop the cover letter and fast foward the branch on to the trunk.
Or you can squash the branch on to the trunk, using the cover letter as the commit message.
questions
This is a fairly rough idea: I'm sure that some of the details won't work in practice without a lot of careful work on compatibility and deployability.
Do the new commit headers ("target" and "previous branch") need to be headers?
What are the compatibility issues with adding new headers that refer to other commits?
How would a server handle a push of an unnamed branch? How could someone else pull a copy of it?
How feasible is it to use cover letter subject lines instead of branch names?
The previous branch header is doing a similar job to a remote tracking branch. Is there an opportunity to simplify how we keep a local cache of the server state?
Despite all that, I think something along these lines could make branches / reviews / reworks / merges less awkward. How you merge should me a matter of your project's preferred style, without interference from technical limitations that force you to trade off one annoyance against another.
There remains a non-technical limitation: I have assumed that contributors are comfortable enough with version control to use a history-editing workflow effectively. I've lost all perspective on how hard this is for a newbie to learn; I expect (or hope?) jj makes it much easier than git rebase.
Interesting app for Android [tech]
Sep. 10th, 2025 05:14 pmsidereaI just discovered the Android app "Periodically". It's described as an "event logger". It's for keeping track of when a recurring thing has happened, and figuring out what the average time is between occurrences. You just keep it updated each time the event happens, and it will do the math for you to figure out the frequency, and even give you a notification when it predicts the event is likely to happen again. If you're tracking more than one thing, it will try to suss out correlations for you.
I mention because twenty five years ago or so, I needed exactly this functionality and could not find any application that would do what I needed, so I wrote a thing for myself, and since then a lot of people I've mentioned it to have wondered where they can get one like it. Mine was Mac/Palm Pilot, so not of much use to most people, especially these days.
Lo, somebody seems to have realized the need for this functionality, and brought it to the market. So I thought I'd mention.
Now, in this day and age, a lot of people, especially in the US, are concerned with security. Especially if they're tracking something to do with their health. This app is not specific to health, so nothing about it immediately reveals that it is storing health information on casual inspection; you could use some sort of other term for whatever health condition it is you are actually tracking. So, for instance, If you were tracking how often your migraines happened, you could call that "new box of cereal".
This app defaults to local-only data storage on your Android device, and the developer claims that it only collects "app activity" for analytics, and shares nothing with third parties. It outputs CSV and has an option to back up to Google Drive.
I haven't tried it myself, but it has a rating of 4.6 stars out of five on the Play Store.
Reviewers on the Play Store note that tracker apps that are specific to the kind of event – such as health- specific loggers – often have needless complexity, and often some weird ideas about graphic design. They praise this app for its clean, elegant look and simple, effective functionality.
In addition to its obvious applicability to episodic health conditions, it strikes me as potentially extremely useful in one of the trickier parts of prepping: figuring out one's burn rate of resources. I think I might trial it to help me figure out how often I should expect to have to buy a fresh bale of toilet paper and how long the big bottle of ibuprofen will last me.
Dept. of JFC We Don't Need This
Sep. 10th, 2025 02:19 pmkaffy_rThis is so bad. I loathe the man, but I want him disgraced and humiliated, not killed. No one, not even this smug SOB, deserves to be shot. Even though the worst angels of my nature are saying "Let the big-headed sonuvabitch leave us permanently, and take his place in one of the circles of Hell," I'm trying to kick those angels to the curb, so as to invite the better angels in for tea.
No one deserves to be shot.
I hate saying it, but it's true.
Also, you just know what's going to happen now: more fascist messaging and meldtowns on the far right - and more fascist thug clampdowns for the rest of us.
I'm dourly amused at the fact that That Man is offering thoughts and prayers for Charlie.
I'll probably amend this post as we learn Kirk's actual status, but for now, this is all I can say.
dinosaur_comics_feed| archive - contact - sexy exciting merchandise - search - about |
| ← previous | September 10th, 2025 | next |
September 10th, 2025: Don't worry - I have been to SEVERAL parties so I know what I'm talking about!! So last week T-Rex suggested a new alphabet replacement, and I got an email from Michael L, who wrote: I took the liberty of finding you the first 26 Garfield comics with no text in them (barring bookkeeping text like dates and signatures ofc) so you don't have to worry about recursively putting Garfield comics inside Garfield comics in order to make them parseable. I thought this was both amazing AND PRACTICAL, and so with permission I now share this list here with you!!
– Ryan | ||
September, still
Sep. 9th, 2025 04:37 pmcellioThe other day, I saw something cute and reposted it on Mastodon:
Overheard, and for Internet old-timers: "Today is the 11,691st day of September 1993".
Someone responded to tell me that Debian has the sdate command "which keeps track for all of us".
I laughed. And then I found that there are also online calculators, for people who don't use Debian.
I am amused, even if -- or perhaps because -- those of us who remember the September that never ended are now a very small minority of the online population. Back then people were frustrated; today it's quirky history. Whatever your online community is -- Usenet, mailing lists, Twitter, Reddit, Dreamwidth, Stack Overflow, whatever -- it's going to change just from the people using it, let alone technology and companies. Don't get too comfortable.
strange credit-card pitch
Sep. 9th, 2025 04:27 pmcellioI've had my Visa card for a very long time (decades). I've been happy with the provider, and the few times I needed the weight of Visa behind a dispute, they came through. No fuss, just like I want a credit card to be.
A few months ago they started sending me email to invite me to add another authorized user to my card, suggesting it as a safety net (so if something happens to me, someone else can administer my account). Maybe that appeals to someone, but I'm not interested so I ignored it. More recently they have been offering minor inducements (a one-time small credit) to do this, and that makes me wonder what their real goal is.
If this is merely a service they offer for peace of mind, the peace of mind is the inducement and nothing else is needed. That they are trying to entice people to do it means there's some other motivation that benefits them more directly. I'm assuming this is not a way to add your minor children so they can more easily make in-app purchases or whatever the kids are doing these days -- and anyway, unless they're giving you a way to throttle spending from other users, that would be a very bad idea.
The only thing I can come up with is that this is a way for people with bad credit scores to get access to credit cards. They aren't going to issue cards to such folks directly, but if they can get you to add your deadbeat cousin with a terrible credit rating (to "help" your family member), then the credit-card company gets more transactions and thus more transaction fees at very low risk to them. They know an existing customer who'd like to keep a good credit rating is on the hook for the charges; they're going to get paid. This might be in Visa's interest, but how is it in mine? It's not, which is presumably why they're trying to buy folks off.
Have I missed some benign reason for them to push this scheme?
(Still not doing it, but curious.)
sherlock holmes and the case of the lengthy and distracting digression
Sep. 8th, 2025 12:00 amdinosaur_comics_feed| archive - contact - sexy exciting merchandise - search - about |
| ← previous | September 8th, 2025 | next |
September 8th, 2025: The bold return of Tiny Batman Head! Only now I've written for DC so uh it's even MORE important that we all just BE COOL ABOUT THIS – Ryan | ||
