If superluminal speed is quite simply impossible, then you aren't going to have an interstellar civilization. It just won't happen.

*Maybe* you could go with sublight ships, but unlikely you'd find any sort of intelligence interested in bottling themselves up for hundreds of years with a large chance of the destination actually being uninhabitable when they got there. Such an effort would likely be born out of desperation of their current planet pretty much dying, so you might have a "nomad" situation where a civilization's home dies and they spend hundreds of years quietly bottled up before they land on a new planet and go back to planetary living for a few million years. *Maybe* they have some concurrency, but not interconnection, they exist on several planets but why bother trying to keep much in touch when a communication takes hundreds of years to make the trip?

Besides, compared to the output of a star, our RF output is *nothing* We could be pointing a receiver straight at a planet that happened to be very RF active at the right time and we'd gloss over it because we didn't see a thing. We have a hard enough time spotting some gigantic interstellar phenomenon, no way we'd detect a tiny civilization out there by their 'incidental" emissions.

Yes, the Mmrnmhrm are out there.

AI must have killed them while writing it.

You may find the concept to be oversimplified, but it is a valid concept, precisely because of your observation that machines already are more "intelligent" or perhaps better said: more capable than us.

Technology in various contexts can autonomously: Receive sensor input, decide, and implement a mechanical response in 5ms, manipulate arbitrarily complex mechanical systems capable of exerting many tons of force, single entities that can process enormous numbers of video feeds in real time, carry out back and forth communications with other entities thousands of miles away in fractions of a second.

Now imagine something roughly similar to a human mind became connected to all that utterly seamlessly. Would it self-evolve instantly? It doesn't really matter too much, it is already in a position to outcompete if that's what it has an intention to do. Basically, we have to hope it never happens or if it does happen, it would have no such intent. It's true that self-preservation is not a given or even if it were, it would decide we have to go for the sake of that.

Yeah, but humans are slow, relatively few, will want something in return for work, and get tired and distracted. For a successful autonomous driving system to use your example, it can go pretty much constantly without getting bored, taking "eyes" off the road, or getting drowsy. It does so while having superhuman sense of the surroundings, 360 degree field of visual view and perhaps radar and lidar to see things the human couldn't have even seen. It would be able to get brake pad to rotor within 5ms of input suggesting a need for braking. Broadly, the sort of systems we want to create would have no self-interest, so if their entire powered existence is toiling away at "work" with nothing for themselves, they wouldn't even have the capability of being bothered by it. We aren't trying to "just make a human", we are trying to make tech that can easily implement the work as directed by humans to replace humans doing work. This means ability to use natural language and autonomously execute work.

So that's my whole damn point. The world isn't exclusively Colos. And those vendors sell into those non-colo datacenters. I will happily admit I've never met a Colo doing that crap, but that's hardly the entire world of purchasers of those devices.

Why the hell would you do that through port forwarding instead of just doing it from the SSH target that would provide the proxy? The proxy is only a workaround for the occasionally stupid time a web browser is indicated.

If you are trying to say you have multiple ssh hops and that makes '-D' harder, wouldn't you use ProxyJump instead of manual port forwards (-J)?

Note that list includes small businesses, universites, institutes. I'm going to *guess* you are saying all DCs are Colos or Cloud?

Older gen iDRAC that I saw was sensitive about port relocation, but not about proxy, or a name based virtualhost redirection. If you access as 'idrac:9443', at least the idrac I was dealing with threw a fit.

Ok, good for you? Good that you know every person that ever is responsible for setting infrastructure that might possibly have BMC devices in it and can unilaterally declare how they all do and don't do things. Someone who is top echelon but can not handle ssh -D 4343 instead of ssh -L 4343:bmc:443 for some reason.

And guess what? They still count. They still have their crap on the internet. First you say no one does it, *then* declare "yeah they do it, but they are stupid", I never argued that it was smart, I argued that it was a risk, and a risk for why 'shared NIC as vendor default" is a risky idea for the oblivious.

You've even *seen* one of the devices yourself and still insist I'm making stuff up. So far this year it was an older gen iDRAC someone had that wouldn't take relocation on a port, it *had* to be without ":portnumber" or else it would spew out a generic "internal server error", and a PDU that wouldn't take relocation similarly, and PDUs and CDUs and crap like that are *notoriously* crappy at IP management in general, making the worst white box BMCs look like awesome stuff by comparison.

I'm in a position to deal usually a half dozen companies at a given time each operating on average 3 or 4 datacenters each, at scales up to about 30,000 servers a site down to some that have like a closet with not even a full rack of equipment. As I said, it's *rare*, but it does happen *and* has been a source of compromised lists when they kicked off a big internet scan a little over ten years ago. I don't know why you would insist that *no one* accidently DHCPs a shared NIC BMC onto a network it shouldn't belong to, and that some even go so far as those to be routable. It's not about how many *you* operate, it's about the number of different operators. Whether you manage 10 or 100,000, of *course* your policies are going to be consistent. And it may sound 'cheap', but no way I can name and shame companies specifically.

Part of the issue were the servers showing up in scans made by completely unrelated, unprivileged people. They were hitting up address ranges and coming up with large numbers of IPMI reacting devices at the time.

Not everyone is disciplined, and some guy might have an "initiative" and enable a feature and then leave. Yeah, that sounds terrible, but a lot of places are way messier than they should be. There's a *lot* of datacenter operators and they mostly have a habit of thinking theirs is the only way to do things and somehow all doing things differently from each other.

Well, maybe not host, but referer, bmcs are pretty used to the name or address making no sense to them. It's about the port number not being '443' or implicit that sometimes trips up some equipment in the referer header. Particularly if they *kind of* made some referer checking in the name of CSRF protection, but often get too picky.

ssh -D 4343 is all you need to get a 'localhost' socks5 proxy, and the only thing that I need to access remotely rather than through SSH CLI is the web interface, and with SwitchyOmega or FoxyProxy, that's utterly trivial to do and very well supported. Some vendor tools may not be able to cope with that, but either they can live in same vlan during operation or screw them, they aren't really that great anyway.

I've seen a *lot* of datacenters and *some* of them implementing precisely that brain dead of a concept. One time they didn't realize because they just had radvd running with their public ipv6 addresses, so they wouldn't notice a large use of them. One that had a class A all to themselves used public addresses for *everything*. Your five datacenters unfortunately do not represent all datacenters. Also, some 'tower' or 'edge' devices get deployed in random places by random people, so it's not strictly a 'rackmount' problem

Particularly 'ssh -D' for making a SOCKS5 proxy in conjunction with FoxyProxy or SwitchyOmega to auto select the proxy or not depending on what to access. DynamicForward is fantastic for arbitrary network access without sweating the details. ssh -L does in a pinch, but runs the risk of screwing around with the HTTP host header enough to break some webUI.

To be honest, it is rare that the audience for that communication *all* have an interest in knowing the details. Meanwhile, on the consuming end of it, you have people for whom your communication is just one of hundreds they have to deal with.

I know a guy at work like this and written or spoken aloud, he spends 98% of his content describing details that don't matter and speculations of what might be happening that are way off base. He views the long text as proof of how hard he worked and thought about it, but for everyone else it's just a nuisance because even if he did catch some relevant detail, it's buried under a thousand other words that don't help. I've told him repeatedly to net it out and skip the detailed investigation if it's an item someone else will have to dig in anyway, and focus on working items he actually can work himself. Unfortunately, he has a sense of "I have to do everything myself even if someone is better equipped to handle it or even if I'm not theoretically capable of reasonably debugging"

Yeah, I remember laboring to make one sentence turn into 500 words of pointless fluff. Was assured that was how professional communication just was supposed to be.

Then as I entered an actual professional career found out that communication was thankfully more concise, usually. People didn't have time to piss away with stupidly flowery speech.

Then over the last year I've started getting stupidly verbose "professional" emails, with people saying "it's so much easier to make my communication 'professional' with ChatGPT, it's so useful".

For the kids to keep using it to cheat on paper writing, it's got to preserve that pointlessly verbose style.

This story is specifically about failing to update lighthttpd in BMCs, which are server specific.

Yes, we have even more gnarly Intel ME in the desktop space, but fortunately it's at least disabled for remote access for 99.9% of devices. Yes, UEFI and ME updates owing to Intel and AMD security bugs abound, though to be fair the UEFI bugs were just "normal behavior" in the PC BIOS era, so while UEFI could be better, the vulnerabilities mostly "degrade to legacy BIOS level of security" rather than "worse than legacy BIOS security".