serinemisc

[serinemisc]

Speaking of knowing Fluffshy irl, it's a pretty good idea if you want a steady stream of Fluffshy posts, but spoken out loud irl.

Me as an authoritarian would be banning speaker that play at above a given volume. If you wish to play audio to a large space just use more speakers.

Honestly me as a EU regulator might be banning such speakers for health and safety reasons (hearing damage).

[serinemisc]

(Context: I took Fluffshy to Vancouver and she is having experiences.)

Me as an authoritarian would be banning speaker that play at above a given volume. If you wish to play audio to a large space just use more speakers.

Honestly me as a EU regulator might be banning such speakers for health and safety reasons (hearing damage).

[serinemisc]

I remember this being the only Technology Connections video I didn't actually like. I've just never had this experience with algorithms.

Back when Facebook was first taking off and they switched to an algorithmic feed, the first algorithmic feed anyone ever interacted with, a lot of people were saying "if you just tell the algorithm not to recommend the bad stuff, it will recommend good stuff". And that's been my experience, too. That's why I have so much Technology Connections recommended at me in the first place.

Most of my doomscrolling isn't algorithmic, anyway. It's Tumblr and RSS.

I think my hottest take is that I don't think the algorithms are the problem. If you go to Reddit and sort by top votes, you get basically the same kind of vapid content that people complain about algorithms recommending. I assume it's just what people like, and the algorithms aren't doing anything special there.

The thing is that these companies want you to use their proprietary algorithms to mindlessly figure out what kind of art or media to consume, but it’s important for your brain that you don’t let yourself fall into that trap.  The algorithms are bad at what they pretend to do.  They think you’re stupid.  And more importantly, they’re designed to MAKE you stupid.  

It's funny to see this posted by a Youtuber whose content I found via the Youtube recommendation algorithm.

[serinemisc]

I'd assume drinking more water, in combination with having less salt intake, is probably even worse for you, and both have been pushed for quite some time...

How common is it to be salt-pilled these days?

By which I mean: the evidence that salt increases long-term blood pressure is very weak and confounded in a dozen obvious ways, and if you have blood pressure problems then going to a low-salt diet most likely accomplishes nothing except to make you unhappy.

Additionally, there are people who don't even have high blood pressure but who have absorbed the vibe that salt is "bad for you" in some unspecified way, which ought to be utterly mocked.

I have no blood pressure problems, but even if I did if you ever suggest to me that I remove salt from my diet I am hitting you with my shoe.

[serinemisc]

Geometry is called 幾何 in Chinese (pronounced jǐhé) and Japanese (pronounced kika). You might read this as "What How" or "How What" and be confused by what this has to do with geometry. The answer is that it comes from Euclid's Elements, whose title was translated into Chinese as "The Whats and Hows".

[serinemisc]

I've always thought it would make more sense for coins to be the top end of the money scale rather than the bottom. A bag of gold coins being a lot of money for very valuable things like cars, and a stack of paper in your wallet for smaller ordinary everyday transactions, that seems more convenient to me. Coins being near-worthless always seemed like an unnecessarily inconvenient way to do things.

Incidentally, China has both coin and note versions of amounts between ¥0.01 and ¥1.

i needed some tokens to keep track of things for a game and i remembered i have a bunch of effectively-worthless coins within reach and playing them has reminded me of how neat coins are. feelwise and such. i've been using them as stim toys since.

the largest coin in argentina nowadays is worth 10 ARS, which is to say less than a penny in USD, and accordingly sees little to no use. the coins i was playing around with were even older 1 ARS coins, which back in the old days was like, real money. you could buy things entirely in coins! cheap things, to be sure, but a transaction denominated entirely in coins used to be a thing that normal people would do and not exclusively the domain of someone trying to ruin your day.

now it may well be that coins are entirely outdated as a currency technology and we shouldn't be using them any more, idk. but from a sensorial perspective they are so much better than bills. little chunk of metal with a satisfying weight. would be nice to have, like, 100 and 1000 ars coins to make small purchases with.

[serinemisc]

Somewhat correct, but way too absolutist about it. They're right that the "privacy" benefits are unclear and most VPN providers are untrustworthy, but there are plenty of other good reasons to use a VPN.

First, good reasons you might want to use a VPN:

(1.) you trust the VPN provider with seeing your traffic more than your internet provider (mentioned by link)

Airport wifi, untrustworthy internet provider, hey wait, isn't this literally every internet provider in existence?

I don't think this kind of privacy is particularly important to worry about (HTTPS exists basically everywhere that matters), but if you care about it, it's still a good reason to use a VPN. The average VPN provider is untrustworthy, but internet providers are usually even worse because they're usually monopolies, while you can choose a VPN provider.

(2.) you want to hide your IP from some non-government actor (mentioned by link)

Ban evasion and torrenting mentioned; common reasons to want to hide your IP. But I'll also mention that governments don't have unlimited resources and are mostly not going to bother tracking you, especially if you are subscribing to a foreign VPN provider that are much harder to pressure than your local internet provider freely giving them information. Don't rely on this, it's obviously not absolute, but, you know, it can be one useful layer in your multiple layers of protection.

(3.) you want an IP from a specific country

The classic reason other than "privacy" that YouTubers give when sponsored by VPN companies. Watch Netflix from another country!

(4.) you want to open a port

Opening ports is either a huge hassle (how am I even supposed to configure a router with all this HTTP deprecation when no one has ever bothered to spec HTTPS on LAN IPs?) or outright impossible if you're on airport wifi or something. VPNs give you a port you can open with only a few clicks. I've done this quite a few times.

(5.) your internet provider is actively interfering with you

Internet providers are famous for interfering with your internet connection in dumb ways (remember when they redirected every typo to ads, before browser makers had to step in to stop it?).

If you're paying for internet on a plane or boat, they'll frequently just block things like Discord (I'm using it for text chat! It's not my fault they put extremely low-bandwidth text chat and extremely high-bandwidth video chat on the same HTTPS connection so an internet provider with severe bandwidth constraints is forced to block both or neither).

And that's not to mention actual government interference. How are you supposed to do anything in China without a VPN? (Do not trust that VPN. It's very suspicious that the only VPNs I could find not blocked in China trace their ownership through shell corporations leading to Hong Kong. But it at least gives you access to the outside world.)

Their Actual Alternative is:

If you absolutely need a VPN, and you understand what its limitations are, purchase a VPS and set up your own (either using something like Streisand or manually - I recommend using Wireguard). I will not recommend any specific providers (diversity is good!), but there are plenty of cheap ones to be found on LowEndTalk.

The process for setting up your own VPN sucks. Streisand is unmaintained and a lot harder to use than the clients from the official VPN services. I'm an Actual Programmer (I opened those ports to test services I wrote!) but honestly part of the reason I don't do this is because it's way too much work to be worth it, and the price difference is minimal.

And even if you think that work is worth it, you get less bandwidth, no choice of IPs. Not to mention, setting up your own VPN doesn't exactly solve all five of those problems:

(1.) One IP is a lot more trackable than "random IP from the VPN provider's huge pool every time". Especially if you're the only one on your VPS's IP using it as a VPN/proxy.

(2.) One IP only lets you do ban evasion once.

(3.) One IP from only one country doesn't let you switch between every country for watching Netflix, only the one you bought the VPS from.

(5.) If you're doing Streisand or setting up WireGuard or something, you are most likely only setting up one specific VPN method. Which means if that specific method gets interfered with, you're fucked. I've used my VPN provider is to get around blocks on things like SSH. Trying tons of protocols and IPs my VPN provider supports will usually get me back into the open internet, and I can't do that if I'm just using a VPN I set up myself.

So yeah. Uh, do your research (I've heard good things about Nord and Proton), don't trust the VPN provider, but there are still reasons to prefer them.

if i had a dollar for every time i saw incorrect (or at least badly confused) cybsersecurity advice on tumblr i stg ahge;ilahg

i probably don't have the bandwidth to properly beat back against the information environment & anyway you should probably trust me exactly as much as any other pseudononymous rando, e.g. zero

but if you are going to be listening to randos regardless: this old article on why you probably don't want to use a VPN service is right on the money & does suggest an Actual Alternative

[serinemisc]

The best way to experience FFXIV dungeons for the first time is the Duty Support system. Not only is there no one else to rush you and the NPCs are infinitely patient, but also you get some special story dialogue from the NPCs (at least in later expansions; I'm not sure about ARR).

The disadvantage is that you can't play with your girlfriend, but that's Square Enix for you.

(Personally, my favorite expansion was Shadowbringers and I strongly recommend getting there at some point.)

Today I finished the A Realm Reborn sequence in Final Fantasy XIV. According to Steam, it took 233 hours. Realistically probably more like 200 hours of actual gameplay, since sometimes I wander off while logged in and I know I spent a few hours of "active" time trying to get various things configured. Still, lots of hours.

To be fair, I could have gone through much faster. The game actually pops up a box when you gain the ability to level multiple jobs telling you it's not designed for you to do that too much. But I leveled everything. I have three combat jobs at 50, one at 49, and one at 48; the other four are in the thirties. My botanist and miner are 52, though my fisher is only 24; I think the crafters are all over 40, with one at 50. I've done...a lot...of optional content.

Overall I've had a lot of fun. (Of course some of that is playing it with my girlfriend, who is very enthusiastic about this game. And also helps me out a lot, although sometimes maybe too much... sometimes I wanna figure out the mechanic for myself.

But it's way easier to level DPS jobs when someone else will party up with me and heal for the dungeon queue.)

My biggest complaint so far is, well, sort of that it's not built as a single-player game; I like weird dungeon puzzles but it's hard to make ones that work for multi-player stuff that also work for single-player stuff. (And even the ones that do just stick to multiplayer, that deprives you of the joy of figuring it out with no real clues, since everyone else [a] knows the answer and [b] has to wait on you so it's not fair to fuck around and try to figure it out on your own.)

But that's my biggest actual complaint: people take the dungeons too fast. I enjoy being slow and methodical, just in general. I wanna enter a room slowly, pick off the enemies one by one, stop, regroup, look around, poke at all the corners, then form up and go to the next room. And that is very absolutely not how running a dungeon with other players works. Half the time you don't even have a chance to open the chest that spawns when the miniboss dies before everyone is in the next room.

And like that's fine when you're on your fifth run of a dungeon. And probably what I want on my fifteenth run. But I want the chance to poke around and slow-play stuff and the game just isn't built for that.

Still, overall very fun, and I did quite enjoy the story. (Some of the voice actors are, uh, not good, though.) Looking forward to Heavensward, which my girlfriend is going to NG+ with me.

(And then I can finally get to FFXV!)

[serinemisc]

It always confuses me why so many people love DuckDuckGo !bang searches, when this is, like, a built-in feature of every browser ever. I've been doing this in Firefox since before DuckDuckGo was a thing, since before Chrome was a thing.

Here's Chrome's configuration for it:

And here's Firefox's:

wikipedia no longer being anywhere near the top of search results when looking up anything feels eviscerating

[serinemisc]

@justthreefrogs in the notes:

I have three native languages. The other day I could not remember what the word for "eyes" was except for in my fourth language. At which point I started babbling in a mix of my fourth and fifth languages about my eyes hurting, much to the dismay and confusion of my friend

This is a thing I've noticed, too. I don't ever mix up my native languages (Chinese and English), but I mix up my non-native languages all the time. If I'm not carefully watching myself when I try to speak any other language, some other language (usually Japanese, my best non-native language) comes out.

It's especially funny because I have some joke conlangs (Foodtongue) in there, when I'm trying to think of "because" and my brain is supplying "coconut".

But the native thing is real. It's very noticeable because at this point my Japanese vocabulary is better than my Chinese vocabulary. But Japanese is still usually the one that my brain supplies when I'm reaching for Spanish words, never Chinese. So I think it's more about how young I learned them than about how good I am at them.

What they don’t tell you about speaking multiple languages is that your brain does not in fact have a box labeled Spanish and another one labeled German. Instead it has a box labeled “Not English” and sometimes when you’re talking or writing in one of the languages you speak it will just start pulling random words from that box.

[serinemisc]

Wait. Japanese isn't not this language. "-chan" is essentially a "I think this person is cute" honorific.

language where pronouns which force you to classify everything as "attractive" and not "attractive"; this language reform is to help boost the drama industry.

[serinemisc]

In all seriousness, JavaScript was considered quite a good language in 1995. The decisions we now hate it for were pretty standard for the scripting languages of its time (PHP also has loose/strict equality, and back then we really believed that the right thing to do when encountering a mistake was to guess what the programmer wanted and keep going; we called it Postel's Law).

2005 is approximately the "JavaScript: The Good Parts" era, where Crockford and others legitimately felt that while there were bad parts to make fun of it for, if you just didn't use those bad parts, JavaScript was a great language, and specifically way more of a functional language than most languages of its era.

By 2015, JavaScript had changed utterly. V8 had fixed its performance, TypeScript had fixed its type safety, linters (along with TypeScript and new standards like "use strict") had fixed its general looseness, and a standards committee has added in most of its missing features. Comparing it to past versions makes it seem way more like the same language than it really is.

JavaScript by the decade

1995 - JavaScript is a joke, a temporary holdover that web browsers use until someone takes the time to invent a good language to use instead.

2005 - Everyone agrees that JavaScript is lousy, but it’s the only way to do web programming, so people grudgingly acknowledge you have to learn it to be a web developer.

2015 - JavaScript is the most popular language on GitHub, and is widely used in server-side programming. Compilers exist to turn JavaScript into almost any major language, including assembly. Many major platforms have one or more JavaScript SDKs.

2025 - Writing code in any language other than JavaScript is seen as hilariously quaint or masochistic, and would never be allowed in production.

2035 - The Illuminati One World Government has abolished all spoken and written languages other than JavaScript. Oldthinkers who unbellyfeel JavaScript are sent to Room 101 for resocialization.

[serinemisc]

I read more about Fossil, so I can actually answer these questions myself. The short answer is: no, Fossil does not have good solutions to these problems.

git merge --squash

Fossil's default history view is in fact the "tangle of curvy lines" thing Git clients do.

There's no view that gets it to sort commits by "time they entered this branch" rather than "time they were committed". The color coding at least helps, but only so much.

Unlike most Git clients, it clearly distinguishes between which parent is the "real" parent (the other parent gets a dotted line), which is nice. Still, though, this view is quite cluttered and the biggest problems remain.

There's also a "first-parent" option, which is at least better than GitHub. It would have made a better default.

git pull --rebase

Fossil, while technically a DVCS, expects everyone to be in sync by default. Unlike in Git, in Fossil by default, committing will automatically fetch before committing, and committing will fail if the branch isn't up to date. So it ends up behaving a lot like SVN by default (like, it feels like you're committing directly to your remote, rather than committing to your local repo and then syncing with your remote).

This solves the direct issue with syncing local and remote branches (at least if you're not working offline). Syncing feature branches with trunk (master) (main), though, still adds quite some clutter, as you can see from the link above.

git commit --fixup

"Keep everyone in sync at all times" means you don't have a lot of unpublished commits you can polish before publishing in the first place. Committing and publishing happens at the same time. So this actually does handle this somewhat.

But in the end, the biggest philosophical difference does seem to be exemplefied by when they say:

[...] a test-first philosophical difference: fossil commit is a commitment. When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing.

The problem with "thinking before acting" is that it means leaving a lot of uncommitted code around. And if something happens to that uncommitted code, it's just gone. The pitch of Git is that it keeps track of changes that are committed ("it's always in the reflog"), but if something happens to uncommitted code, you're just fucked.

I think it's a good thing to have a middle ground betweeen "untracked code" and "committed/pushed code that's there forever" and it's a good thing that Git makes this distinction.

Fossil also discourages committing in other ways. While it is in fact a real DVCS, it causes problems when you commit while working offline, because it could cause a fork, and Fossil handles forks worse than Git does (even if you never rebase in Git).

(In case you didn't know: in Git, a branch is essentially a movable tag. In other words, a branch is a pointer to a specific commit, and pulling/committing/pushing will update the relevant branch pointer to point to a newer commit. In Fossil, as far as I can tell from these docs, a branch is the entire commit log, and so if a branch is forked, there is no single "current/latest commit".)

Anyway, I wasn't really going to switch away from Git either way, but this deep dive at least confirms I'm not missing much. Probably the best way forward is if we can get Git tools to visualize commit logs in actually sensible ways. Maybe we should lobby GitHub.

So I came across this recently.

It's funny, because I think I exactly half agree with it. I do rebase-heavy workflows in Git mostly because every single Git client makes merge-based workflows ugly and hard to use. If GitHub simply displayed merges the way it displayed squash-merges, that would eliminate so much of the need for squash-merges.

But I don't think this covers everything. So let me go through every use-case for rebase separately:

git merge --squash

The squash-merge is one of the most popular ways to merge pull requests on GitHub, and it's an abject failure of the Git ecosystem that it's so popular.

When you do a regular merge on a pull request, you are essentially taking a bundle of commits from somewhere else, and putting it on top of your own main branch. It's an extremely linear thing to do.

But if you do that, GitHub's commit log just gets a bunch of commits interspersed throughout, with zero indication where they're from. And the nicer clients, if they do, visualize it as a tree (pronounced "DAG") (pronounced "a huge tangle of curvy lines"):

This pic is from an article telling you to rebase, and, like, sure, rebasing sure is one way to work around a UI that displays your merges as a huge tangle. But Fossil makes a really good point. Why not instead display your merges as, like, not a huge tangle? git log --first-parent does this (and that's clearly an option in that Git UI), but it should be the default everywhere. And even when expanding the "bundle", the bundled commits should still be grouped together, not interspersed with other commits at essentially random.

The other issue is that, when showing the "tangle of commits", the reason it's so tangled is because it's showing the commits in chronological order of when the commits were made. Which is a completely useless sort order, compared to, say, chronological order of when they arrived in the current branch (i.e. grouping the merged-in commits together). This is why GitHub's rebase-merge is also such a popular alternative to merges.

git pull --rebase

Okay, so. Now you've fixed commit log visualization of merged pull requests. But that's not the only use of rebase! Here's another one: if you're working on some code, and constantly keeping it synced with remote, you'll generate tons of merges that are complete useless noise. Unlike a merged PR, these should ideally be hidden completely, or at least nearly-completely.

Anti-rebase people say that these merges serve the functionality of, like, preserving history. You made one commit when the remote was in this state, and another commit when the remote was in that state, and this is sometimes important history to preserve.

I think they are way overestimating how important that history is (judging by how many people use pull-rebase). I'm fine preserving that history if you can declutter the UIs, but it does require your UI to be able to distinguish between "important" merges (of new features from feature branches) and "unimportant" merges (keeping branches in sync with remotes).

The linked post doesn't talk about this problem at all, so I don't know how well Fossil handles this.

git commit --fixup

That leaves the amend/fixup commit. The link does mention that Fossil supports editing past metadata (e.g. commit message). But sometimes you want to edit the actual changes of a commit.

Now, for a sufficiently published commit, this is a bad idea. But if you have a habit of "commit early, commit often", having 50 bugfix commits makes a commit log really cluttered.

I frequently, like, have to weigh stuff like "is it worth cluttering the commit log to fix one typo in one comment?" for old code. And it would really suck to also have to do that for unpublished code, instead of going in with my trusty rebase scalpel.

git that's all I wanted to say

In conclusion. git rebase is a solution to a number of things that could also be viewed as UI problems, and fixed in other, better ways, and Fossil sure sounds like it's fixed some of them. But some of those UI problems are legitimately hard, and I'm not convinced Fossil fixes all of them, and GitHub extremely has not, so I'm gonna keep rebasing.

[serinemisc]

Man I think I just mostly checked out of this resulting conversation because I didn't have a sideblog and also figured this would be a never-ending argument.

I'll come back to say:

Yes, yes, there are of course contexts where someone might favor more or less literalness in a translation. But I still say that maximal literalness is always wrong. Save it for the translator's notes. Translations for the purpose of analyzing original meaning have translator's notes, because there's no other way to properly preserve original meaning.

There is no sense in which "With regards to my own preferences, you please me" preserves characterization. The original Japanese is someone talking normally, and the English sounds like an autistic robot. Once again, use TL notes if you care so much about this sort of thing.

Leaving things like "-chan" or "senpai" untranslated is a stylistic choice. I'm not opposed to it, I even much prefer it over many of the more awkward alternatives (it's very very rare for subtitles to translate senpai/kouhai well). It's not really the sort of thing I'd consider "literal translation". Translating "senpai" to "senior" when it doesn't fit, is the sort of thing I am thinking of when I am criticizing literal translation.

"Suki" to "I love you" is one of those things that usually feel wrong to me. In a confession, "I have feelings for you", "I have a crush on you", "I like you", "I like like you" etc are more like how Americans would say it. "Aishiteru" to "I love you" feels appropriate, though. If you want to distinguish between smaller subtleties like "suki" and "suki desu", you should really just start reading the original Japanese. No one is going to routinely make translations optimized for being Japanese study guides. The best you can do is stuff like haru-dipthong's translation notes.

Fan translation communities keep arguing about whether you should translate more literally or more freely, as if it were a matter of personal preference.

Meanwhile, Wikipedia just straight up says “Literal translation is translation that’s full of errors”, and the first Google result is a guide on how to avoid literal translation.

I wish I could get them to understand this basic point, but, I mean, they’re the people who come up with things like “All according to keikaku (keikaku means plan).”

[serinemisc]

So I came across this recently.

It's funny, because I think I exactly half agree with it. I do rebase-heavy workflows in Git mostly because every single Git client makes merge-based workflows ugly and hard to use. If GitHub simply displayed merges the way it displayed squash-merges, that would eliminate so much of the need for squash-merges.

But I don't think this covers everything. So let me go through every use-case for rebase separately:

git merge --squash

The squash-merge is one of the most popular ways to merge pull requests on GitHub, and it's an abject failure of the Git ecosystem that it's so popular.

When you do a regular merge on a pull request, you are essentially taking a bundle of commits from somewhere else, and putting it on top of your own main branch. It's an extremely linear thing to do.

But if you do that, GitHub's commit log just gets a bunch of commits interspersed throughout, with zero indication where they're from. And the nicer clients, if they do, visualize it as a tree (pronounced "DAG") (pronounced "a huge tangle of curvy lines"):

This pic is from an article telling you to rebase, and, like, sure, rebasing sure is one way to work around a UI that displays your merges as a huge tangle. But Fossil makes a really good point. Why not instead display your merges as, like, not a huge tangle? git log --first-parent does this (and that's clearly an option in that Git UI), but it should be the default everywhere. And even when expanding the "bundle", the bundled commits should still be grouped together, not interspersed with other commits at essentially random.

The other issue is that, when showing the "tangle of commits", the reason it's so tangled is because it's showing the commits in chronological order of when the commits were made. Which is a completely useless sort order, compared to, say, chronological order of when they arrived in the current branch (i.e. grouping the merged-in commits together). This is why GitHub's rebase-merge is also such a popular alternative to merges.

git pull --rebase

Okay, so. Now you've fixed commit log visualization of merged pull requests. But that's not the only use of rebase! Here's another one: if you're working on some code, and constantly keeping it synced with remote, you'll generate tons of merges that are complete useless noise. Unlike a merged PR, these should ideally be hidden completely, or at least nearly-completely.

Anti-rebase people say that these merges serve the functionality of, like, preserving history. You made one commit when the remote was in this state, and another commit when the remote was in that state, and this is sometimes important history to preserve.

I think they are way overestimating how important that history is (judging by how many people use pull-rebase). I'm fine preserving that history if you can declutter the UIs, but it does require your UI to be able to distinguish between "important" merges (of new features from feature branches) and "unimportant" merges (keeping branches in sync with remotes).

The linked post doesn't talk about this problem at all, so I don't know how well Fossil handles this.

git commit --fixup

That leaves the amend/fixup commit. The link does mention that Fossil supports editing past metadata (e.g. commit message). But sometimes you want to edit the actual changes of a commit.

Now, for a sufficiently published commit, this is a bad idea. But if you have a habit of "commit early, commit often", having 50 bugfix commits makes a commit log really cluttered.

I frequently, like, have to weigh stuff like "is it worth cluttering the commit log to fix one typo in one comment?" for old code. And it would really suck to also have to do that for unpublished code, instead of going in with my trusty rebase scalpel.

git that's all I wanted to say

In conclusion. git rebase is a solution to a number of things that could also be viewed as UI problems, and fixed in other, better ways, and Fossil sure sounds like it's fixed some of them. But some of those UI problems are legitimately hard, and I'm not convinced Fossil fixes all of them, and GitHub extremely has not, so I'm gonna keep rebasing.

[serinemisc]

The big problem with teleporter discourse is that everyone who disagrees with me always says things that are, like, very straightforward to refute. And then I'm like, "okay, I don't want to fully wade into this, but what if I just respond to this very straightforwardly wrong point?" and then five pages later I realize that I'm extremely caught up in teleporter discourse and I delete the entire draft.

The core thing, though, still seems incredibly obvious, so I'm going to try one last time.

The problem is, if you stare at the starting end, you see a guy get vaporized, and you think "okay, it doesn't matter what else is happening anywhere else, this is obviously death".

And on the other hand, if you stare at both ends, you're like, "okay, this guy's precise molecular arrangement is here, and then it's there, the only way this guy didn't go over there is if there is some magical essence that doesn't get teleported".

These obviously contradict each other, and I think the only way to make sense of it all is to conclude that consciousness was never a thing that depends on one singular spacetime-continuous experience at all.

Like, imagine many-worlds QM (you don't need to actually believe in it). You split into two timelines. Which one is the "real" you? They both equally are. The "experiencer" is a moment-to-moment thing and every copy is equally an experiencer. This all makes perfect sense for AIs but when it comes to humans, suddenly we imagine something magical.

What do we think happens if we simulate a human in a computer? Is it just never conscious? If it is, it seems obvious that it would still be the same consciousness if you paused the simulation and started running it somewhere else. Same with the teleportation - same consciousness, running on different atoms over there.

And that's really the thing. You can argue until you're blue in the face about how this collection of atoms has physical continuity with that collection of atoms and is therefore the "same" collection, but consciousness doesn't run on human ideas about identity, it runs on physics, and the laws of physics don't distinguish between two identical collections of atoms.

[serinemisc]

I don't know how we've gotten this many years into this argument without it being clear that materialists usually think of "continued consciousness" as a physical property of a thing itself, not a statement about how other people are going to react to it.

Like, "this is the actual ring my fiancée gave me" is a claim about, like, which ring you are going to be mad if it is stolen, which ring you expect the police to help you recover, etc. It's not a claim about any property of the ring like what gem is set in it, what size is it.

And if I say "I'm going to teleport over there", I'm not saying "you are not going to think I died and a copy of me is going to materialize over there", I'm saying "I'm going to feel my physical location move over there". You may disagree but, like, it's clear that this is a question about facts and not a question about how humans define identity.

If I were to try one more time: Materialists see identity as an abstraction, as a human concept, not as a fundamental fact about the universe. How else do you resolve the Ship of Theseus?

like I guess the most concise version of what I'm trying to claim is that, if I have a wedding ring, and you make a forgery of it, then "this is the actual ring that my fiancée gave me" is a meaningful statement which is true of exactly one of the rings (and this is the case regardless of how good the forgery is)