I’m always reminded of https://youtu.be/ZI0w_pwZY3E for Skype

I mean, I guess, but that’s only a selling point to the small number of people without smartphones, which isn’t a large enough group to make it a sound business strategy.

Also, the “(after federal incentives)” is doing a lot of heavy lifting here. The basic option for the 2023 Bolt comes out to about $20K after federal incentives, but you get way more range and a bunch of those “luxury” features this is missing. Considering how cheap low-end smart phones are, I have a hard time imagining that infotainment systems actually add more than 1-2% of the cost of the vehicle. Feels more like a type of virtue signal than a real cost-saving measure.

For me, the huge value-add of Discord is for gaming (and is what Discord was created for). In college, my friends and I were originally using Skype calls when we’d play League together, but it was super annoying; essentially in order to not have to create a new call and add everyone who happened to be playing every time we just had one giant call with everyone we’d “redial” when playing. The downside is that if you were on Skype but not part of the game (in class or something) you’d get the Skype call invitation and have to decline it.

Switching to Discord was fantastic. We’d just have a persistent voice channel for different games, and you could chill in there to indicate it’s what you were playing or wanted to play, and if someone wanted to join they just jump on the call. It was also nice for organizing our text chats into different subjects (using different text channels), so if you were trying to ask if anyone had any advice for a certain class, you wouldn’t have your messages drowned out by people talking about news about a upcoming game. We just have a “games” text channels and a “classes” text channels and a “weekend plans” text channel, etc. This became particularly important as the server grew from friends to friends of friends and would’ve been overwhelming to have everyone stuck in one chat.

That’s pretty much been the extent of my Discord use, and I’m continually amazed to hear how others have been using it. I’ve seen the “join us on Discord, X, Facebook, etc.” for different games coming out, but never thought much of it or ever considered doing that.

it isn’t possible to synthesize neutronium at that amount or handle that much safely.

To be clear, the neutronium you’re talking about here is the one that is theorized to exist at the core of neutron stars? Could you elaborate on how much has been synthesized and could be handled safely?

Relevant xkcd’s

Corporations cannot create nontoxic social media, the incentives will always be there to make it toxic.

I don’t know that’s true. The incentives to make it toxic come from engagement being the goal, which is a function of advertising being the income. I’m not advocating for it, but if there were a flat subscription and no ads, I don’t think they’d have any economic pressures for toxicity.

I would throw out that Windows executables work surprisingly well on Linux these days via “wine.” I use EndeavorOS and it’s pretty much no work on my part, I double-click a .exe and it starts it up via wine. I think the only thing that’s been spotty for me is Meshmixer crashes sometimes, but it’s also abandonware so I’m not sure it actually runs better on Windows.

Oh, I don’t heat it at all, I just eat it room temperature

To me, the potential point of confusion is referring to “sent by Ctrl+D” and things “received by the end process” as synonymous, ignoring the tty driver in between. When you Ctrl+d, you send a magic byte value to the tty master (which I would refer to as a EOF character, but I understand the argument against the terminology). On the other side of it the process doesn’t receive this value, but instead has its read call returned even if the buffer is 0.

A simple example hopefully highlighting the difference

Window1:
nc -nvlp 5555 #"far nc"

Window2:
nc -nv 127.0.0.1 5555 #"local NC"
Hi there[Enter]
Hi [Ctrl+D]There[Ctrl+D][Enter]

Window3:
strace -p [pid of local nc]

Window2:
[Right arrow][Right arrow][Ctrl+D]
[Ctrl+D]Uh oh[Enter]

What we see is pretty much as described. From the first line, we see “Hi there\n” on the other side. For the second line, we first see "Hi " appear, then “There” then “\n”.

From the third line, in the strace we can see the sequences representing the right-arrow key, and we can see the tty driver on the far side takes those sequences and interprets them to render the cursor two characters to the right.

The fourth line is where it gets more interesting. We send the tty driver the EOF byte, and the tty driver interprets this and gives the current active tty client a 0-byte return to read() and assumes we have no more data to send. But unlike bash, nc doesn’t care about a 0-byte read and is still looking for more data (as we can see in the strace). But if we continue to type and send more data (the “Uh oh”), we can see in the strace that the tty never sends this to the nc. So, to some definition, we’re still sending data to the local nc, but the tty driver isn’t actually relaying it