tal

https://store.steampowered.com/search?sort_by=Reviews_DESC&tags=3814&controllersupport=28%2C60&supportedlang=english&ndl=1

Steam list of third-person shooters sorted by user rating for which controllers are preferred or full controller support is present.

then why not write modern software like how that was written?

Well, three reasons that come to mind:

First, because it takes more developer time to write efficient software, so some of what developers have done is used new hardware not to get better performance, but cheaper software. If you want really extreme examples, read about the kind of insanity that went into trying to make video games in the first three generations of video game consoles or so, on extremely limited hardware. I'd say that in most cases, this is the dominant factor.

Second, because to a limited degree, the hardware has changed. For example, I was just talking with someone complaining that Counter-Strike 2 didn't perform well on his system. Most systems today have many CPU cores, and heavyweight video games and some other CPU-intensive software will typically seek to take advantage of those. CS2 apparently only makes much use of one or two cores. Go back to 2005, and the ability to saturate more cores was much less useful.

Third, in some cases, functionality is present that you might not immediately appreciate. For example, when I get a higher-resolution display in 2025, text typically doesn't become tiny --- instead, it becomes sharper. In 2005, most of it was rendered to pixel dimensions. Go back earlier, and most text wasn't antialiased, and go back further and fonts seen on the screen were mostly just bitmap fonts, not vector. Those jumps generally made text rendering more-compute-expensive, but also made it look nicer. And that's for something as simple as just drawing "hello world" on the screen.

Thanks for adding it!

uncensored

https://lemmyverse.net/communities?nsfw=true

reposts

If you're browsing "All" instead of "Subscribed" --- I recommend building a subscription list of interest --- there's a bot, @[email protected] that mirrors posts to Reddit to communities on lemmit.online. You can either block the bot or block the instance if you don't want that.

There's also istheservicedown.com, but it also appears to rely on CloudFlare.

There's isitdownrightnow.com, which appears not to use CloudFlare.

You can monitor instance downtime at:

https://lestat.org/

I mean, it's easy to check whether a given instance is using CloudFlare.

        $ host lemmy.world|head -n1
    lemmy.world has address 104.26.9.209
    $ whois 104.26.9.209|grep ^NetName
    NetName:        CLOUDFLARENET
    $

You can browse anonymously on any instance that permits doing so, so if you just want to browse during an outage, you can do that anywhere.

IMHO, having an account on a second Threadiverse instance isn't necessarily a terrible idea, not just because of CloudFlare outages, but because instances do have outages for various reasons. I have an account on olio.cafe (PieFed, not on CloudFlare) and on lemmy.today (Lemmy, not on CloudFlare) because I wanted to try out PieFed, and I have fallen back to that to post before if lemmy.today has issues.

That being said, I didn't intentionally try to avoid CloudFlare. I mean, they're used by a lot of major sites, and I don't expect them to have a lot of downtime. I mean, every Threadiverse instance has had downtime for some reason or another. I've had Internet outages, as well as electricity outages. Not all that common or usually an extended thing, but they happen.

Took down Framework's website, which I was using.

So, there are a couple of reasons to use CloudFlare, but I suspect that the reason that a lot of people are doing so is to deal with DDoSes, which are hard to deal with otherwise.

Like, my home instance, lemmy.today, doesn't use CloudFlare, so it isn't affected by a CloudFlare outage. But...it was also knocked offline for a few days about a month back by a DDoS.

A lot of major sites do depend on CloudFlare, so they probably aren't going to have a horrendous amount of downtime --- like, any issue that comes up is probably gonna have a lot of engineers banging on it pretty quickly.

!actuallyinfuriating

Ah, yeah, thanks, though the community name is incorrect (needs an underscore) and is missing the instance name.

Just keep in mind that the long run trend for storage prices is pretty strongly downwards; that's a log-scale graph.

Are we okay with the “mildly infuriating” community becoming a “news that really upset me” community?

Note that Reddit's /r/MildlyInfuriating spawned /r/ActuallyInfuriating for stuff that is more severe.

Searching on lemmyverse.net shows that we do have an /r/ActuallyInfuriating analog at [email protected].

Maybe the community mods might consider putting it in the sidebar? @[email protected], @[email protected], @[email protected]?

One early company that a lot of people were using for hosting Lemmy instances was Hetzner, a German hosting company (which IIRC also has datacenter space somewhere in the US).

I did a search for "Hetzner" and "lemmy.world" and got this:

https://lemmy.world/post/55124/65982

I run lemmy.world on a VPS at Hetzner. They are cheap and good. Storage: I now (after 11 days) have 2GB of images and 2GB of database.

Now, that was two years ago, and early on, and it may or may not be located there now; IIRC, from vague reading of announcements, the lemmy.world people have upgraded their server, and they might be on bare metal instead of a VPS or something now.

Assuming that the server is still with Hetzner, according to the company webpage, they have colo locations in Finland and Germany and cloud locations in Finland, Germany, the US, and Singapore.

https://marvel.fandom.com/wiki/Category:Portal_Creation

One portal at the outflow port of the hydroelectric dam, one portal back up at the top.

In The Cuckoo's Egg, Cliff Stoll (correctly) identified that a German hacker working for the KGB attacking his systems in Berkeley, California and bouncing through intermediate systems was likely in Europe, based just on a round-trip latency measurement of Kermit responses, which is a lot more primitive than the above:

So I reopened our doors and sure enough, the hacker entered and poked around the system. He found one interesting file, describing new techniques to design integrated circuits. I watched as he fired up Kermit, the universal file-transfer program, to ship our file back to his computer.
The Kermit program doesn't just copy a file from one computer to another. It constantly checks to make sure there haven't been any mistakes in transmission. So when the hacker launched our Kermit program, I knew he was starting the same program on his own computer. I didn't know where the hacker was, but he certainly used a computer, not just a simple terminal. This, in turn, meant that the hacker could save all his sessions on a printout or floppy disk. He didn't have to keep notes in longhand.
Kermit copies files from one system to another. The two computers must cooperate—one sends a file, and the other receives it. Kermit runs on both computers: one Kermit does the talking, the other Kermit listens.
To make sure it doesn't make mistakes, the sending Kermit pauses after each line, giving the listener a chance to say, "I got that line OK, go on to the next one." The sending Kermit waits for that OK, and goes on to send the next line. If there's a problem, the sending Kermit tries again, until it hears an OK. Much like a phone conversation where one person says "Uh huh" every few phrases. My monitoring post sat between my system's Kermit and the hacker's. Well, not exactly in the middle. My printer recorded their dialogue, but was perched at the Berkeley end of a long connection. I watched the hacker's computer grab our data and respond with acknowledgments.
Suddenly it hit me. It was like sitting next to someone shouting messages across a canyon. The echoes tell you how far the sound traveled. To find the distance to the canyon wall, just multiply the echo delay by half the speed of sound. Simple physics.
Quickly, I called our electronic technicians. Right away, Lloyd Bellknap knew the way to time the echoes. "You just need an oscilloscope. And maybe a counter." In a minute, he scrounged up an antique oscilloscope from the Middle Ages, built when vacuum tubes were the rage.
But that's all we needed to see these pulses. Watching the trace, we timed the echoes. Three seconds. Three and a half seconds. Three and a quarter seconds. Three seconds for a round trip? If the signals traveled at the speed of light (not a bad assumption), this meant the hacker was 279,000 miles away. With appropriate pomp, I announced to Lloyd, "From basic physics, I conclude that the hacker lives on the moon."
Lloyd knew his communications. "I'll give you three reasons why you're wrong."
"OK, I know one of them," I said. "The hacker's signals might be traveling through a satellite link. It takes a quarter second for microwaves to travel from earth to the satellite and back." Communications satellites orbit twenty-three thousand miles over the equator.
"Yeah, that's one reason," Lloyd said. "But you'd need twelve satellite hops to account for that three-second delay. What's the real reason for the delay?"
"Maybe the hacker has a slow computer."
"Not that slow. Though maybe the hacker has programmed his Kermit to respond slowly. That's reason two."
"Aah! I know the third delay. The hacker's using networks that move his data inside of packets. His packets are constantly being rerouted, assembled, and disassembled. Every time they pass through another node, it slows him down."
"Exactly. Unless you can count the number of nodes, you can't tell how far away he is. In other words, 'You lose.' " Lloyd yawned and returned to repairing a terminal.
But there was still a way to find the hacker's distance. After the hacker left, I called a friend in Los Angeles and told him to connect to my computer through AT&T and Tymnet. He started Kermit running, and I timed his echoes. Real short, maybe a tenth of a second.
Another friend, this time in Houston, Texas. His echoes were around 0.15 seconds. Three other people from Baltimore, New York, and Chicago each had echo delays of less than a second.
New York to Berkeley is about two thousand miles. It had a delay of around a second. So a three-second delay means six thousand miles. Give or take a few thousand miles.
Weird. The path to the hacker must be more convoluted than I suspected. I bounced this new evidence off Dave Cleveland. "Suppose the hacker lives in California, calls the East Coast, then connects to Berkeley. That could explain the long delays."
"The hacker's not from California," my guru replied. "I tell you, he just doesn't know Berkeley Unix."
"Then he's using a very slow computer."
"Not likely, since he's no slouch at Unix."
"He's purposely slowed down his Kermit parameters?"
"Nobody does that—it wastes their time when they transfer files."
I thought about the meaning of this measurement. My friends' samples told me how much delay Tymnet and AT&T introduced. Less than a second. Leaving two seconds of delay unaccounted for.
Maybe my method was wrong. Maybe the hacker used a slow computer. Or maybe he was coming through another network beyond the AT&T phone lines. A network I didn't know about.
Every new piece of data pointed in a different direction. Tymnet had said Oakland. The phone company had said Virginia. His echoes said four thousand miles beyond Virginia.

Poring over the atlas, I remembered Maggie Morley recognizing the hacker's password. "Jaeger—it's a German word meaning Hunter." The answer had been right in front of me, but I'd been blind.
This explained the timing of the acknowledgement echos when the hacker used the Kermit file transfers. I'd measured 6000 miles to the hacker, though I'd never relied much on that figure. I should have. Germany was 5200 miles from Berkeley.

They may also publicly announce it somewhere. I haven't gone looking. I don't know if they care about keeping their location private or not.

https://legal.lemmy.world/tos/#our-governing-laws

The website and the agreement will be governed by and construed per the laws of the following countries and/or states:
The Netherlands
Republic of Finland
Federal Republic of Germany

They could write whatever they want there, but that's probably a pretty decent argument that the server's in Europe.

I imagine that if there's some way to induce a Lemmy server to perform an outbound connection to a host that one controls and it isn't specially set up to use a VPN or something, that might expose its IP. Like, might be a way to do that via ActivityPub federation activity or something; I don't know if that was designed around avoiding that.

IIRC lemmy.dbzer0.com explicitly does try to keep its location private, so I imagine that they're relying on Lemmy not to expose its location. I don't know whether @[email protected] has looked hard at whether the Lemmy codebase is set up specifically not to do that, but he might have some familiarity with the topic, since I imagine that it'd be of interest to him.

For anything behind a reverse proxy network like CloudFlare, you could probably do something like measure access times from different CloudFlare points around the world and measure latency; that won't give an exact address, but it'd probably let you home in on the general location. Probably some way to get a tcpdump of a TCP connection and do some kinda timestamp analysis that measures something like minimum time until an ACK packet is reflected in packet transmission or something like that; that'd cut stuff like connection setup time out of the question.

I remember thinking about how to identify the Jia Tan attacker some time back --- that entity was always behind a VPN, as I understand it --- and I remember thinking that if one knew that they were malicious before they broke off, one way would be traffic analysis on logged connections. If one has some idea of congestion on various international network links, it's probably possible to get an effective statistical timestamp by analyzing packet response times on a TCP connection. If the unknown source has correlation in latency with latency on a given network link, then it becomes increasingly-likely that their connection, on the other side of the VPN, is traversing that link. Then walk back up potential network links, looking for statistical latency correlation with them. For smaller network links, could even briefly induce saturation yourself to accelerate generating a statistically-meaningful "latency fingerprint".

Probably intelligence agencies and security researchers and suchlike that have done research on "piercing the VPN veil" via traffic analysis.

They probably use CloudFlare, though, as do many instances, and that'll just be where it enters CloudFlare, which will then open a connection to the actual server.

        $ whois 104.26.8.209|less

Looks like it.

        NetRange:       104.16.0.0 - 104.31.255.255
    CIDR:           104.16.0.0/12
    NetName:        CLOUDFLARENET
    NetHandle:      NET-104-16-0-0-1
    Parent:         NET104 (NET-104-0-0-0-0)
    NetType:        Direct Allocation
    OriginAS:       
    Organization:   Cloudflare, Inc. (CLOUD14)

Your home instance, fedia.io, may not know about [email protected] yet.

You need to trigger a community search for the string "[email protected]" on your home instance, which is what makes it "discover" the community.

Fedia.io runs Mbin.

On Lemmy and Piefed, clicking on a link to a community that your home instance doesn't know about will provide an option to do such a search. I don't know if Mbin does that. If not, I'd manually do it.

If that doesn't work, maybe there's some sort of compatibility problem between current Mbin and current Lemmy.

EDIT: Or could be the client, since you say that you're using Interstellar.

IRC, though you'll want to use it over TLS.

XMPP, which someone else listed, is also good if you want a more instant-message-like interface.

https://en.wikipedia.org/wiki/Ouija

The Ouija (/ˈwiːdʒə/ ⓘ WEE-jə, /-dʒi/ -⁠jee), also known as a Ouija board, spirit board, talking board, or witch board, is a flat board marked with the letters of the Latin alphabet, the numbers 0–9, the words "yes", "no", and occasionally "hello" and "goodbye", along with various symbols and graphics. It uses a planchette (a small heart-shaped piece of wood or plastic) as a movable indicator to spell out messages during a séance.

Spiritualists in the United States believed that the dead were able to contact the living, and reportedly used a talking board very similar to the modern Ouija board at their camps in Ohio during 1886 with the intent of enabling faster communication with spirits.[2] Following its commercial patent by businessman Elijah Bond being passed on 10 February 1891,[3] the Ouija board was regarded as an innocent parlor game unrelated to the occult until American spiritualist Pearl Curran popularized its use as a divining tool during World War I.[4]

We've done it before with similar results.