That isn’t the premise of the article, that is the “common wisdom” the author corrects as the article goes on. The author goes on to list video games as an example of where UDP makes sense, as well as live video.
It's true that HE is a backbone but there is an enormous difference between having bits of your traffic transiting a firehose and sending your entire session thru someone's endpoint.
The latter is much more comprehensive and identifiable.
This isn't to throw shade at HE; I don't recall any complaints about their integrity. It's just to say HE's tunnel is in a practical position to monitor, should they choose or be compelled.
Is it though? I can run Windows programs from 20 years ago on my Windows machine just fine.
Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorry state of affairs.
Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.
You are talking about backward compatibility, the parent thread is about forward compatibility. You won't have much luck running a modern executable on XP unless the vendor went out of their way to make that happen.
> What's worse is that you can't even really statically link it without herculean effort.
The program we are discussing happens to be written in Go so it's trivial to build a statically linked executable.
With Go on Linux libc is only needed when the libc DNS resolver is used (instead of Go's built-in one) or if C libraries are used. superfile doesn't need either of these so it's very simple to build it as a pure Go executable which will be statically linked and contain no C code at all.
It's an interesting comparison. I agree that five years is well within the expected period of viability of an operating system. Some points to consider:
- any given release of a Linux distro will probably work on hardware released five years earlier -- one factor that reduces the cost of upgrading the OS (there are many more obvious factors)
- Microsoft is highly motivated to get customers to upgrade to the new Windows at the time. The legacy support is well-known as a "bone" (or: "a factor that reduces the cost of upgrading the OS")
- binary backwards/forwards compatibility is less of an issue in an environment that doesn't treat source code as a secret
- why run old versions of software? In other words: xterm is older than Windows and also as new as Windows
Also, I've always found it amusing that I have much less trouble running old windows software on a Linux (wine) than on new versions of windows.
Wow, all comments removed as spam or hidden by default, update posted saying "We are targeting to land support for IPv6 towards the beginning of next year." Well, Q1 2024 has come and gone. Where's IPv6 support or the communication about what is happening? Good reason to never use Vercel if you ask me.
>I apologize for the slow response. We are targeting to land support for IPv6 towards the beginning of next year. We will communicate updates on this issue. Thanks for the patience.
So cringey. Why not just post a new post that said "sorry the deadline slipped, no new date available at the moment"? I will strongly recommend _against_ this company solely based on this communication. If this sort of gaslighting is how they handle their public comms, imagine how their support must be run.
Was this its raw response to the same query as in the OP? It seems odd it would provide a response using variables named with underscores, rather than using spaces, or more traditional algebraic notation (x/y/z).
ChatGPT (paid version at least) writes a quick python script in cases like these, and then executes it to get the result. For transparency, the script is shown in the output as well. Probably to avoid embarrassments like the ones we saw above.
Having done a couple of their courses without paying:
You are expected to complete the project in steps they define (so for their Redis project, step 1 is to bind to a port, step 2 is to respond to a PING command, etc). If you choose not to pay, you can only complete one step per day, even if you submit code which would pass future steps.
This can be quite frustrating, since each step is often very simple, and IMO discourages producing a well-architected solution which anticipates future requirements, as you're left waiting 24 hours to press the submit button for code you've already written.
Still: It's free, and the restricted progress forced me to not use it for procrastination purposes, so there's that.
It's better for me this way, having things broken down to piecemeal level like this allow me to avoid overthinking and know when to just produce a solution and accept it.
Being a current user of Migadu: I’m not sure what they’ve written there is actually correct. When I’ve gone over the outgoing message limit, I’ve received no warning, no 25% margin, and the messages were just dropped, not deferred. I just received an email telling me I had exceeded my account limits.
I agree it’s not a TOS violation, but I do think it could potentially be a shitty move to post the ASN from which a specific user is connecting to your service, if they’ve not said it’s okay for you to do so.
If you’re from a small town with a local ISP, associating that town with your first name could be enough to specifically identify you, with the help of yellow-pages directory sites. Even just knowing someone’s state or country is a data point that can be used to narrow down their identity. For the privacy minded, this could be very unfortunate.
I’m not sure why you would be publicly posting the ASN from which a user is connecting anyway? Could you explain the context a bit more here?
Good point, I think I misinterpreted the conversation in the second screenshot.
I think the point is still relevant though: if these are the ASNs connected to a server which you know has 10 active users, for example, then there is still a potential privacy concern.
We have 40+ servers, the ASNs did not have any other information tied to it like usernames as I had already mentioned.
This is a clear case of gross negligence by Discord.
Even if there was a potential privacy concern, that does not warrant an instant ban with no warning especially from a 7 year old account that is in charge of a Discord server for thousands of users and paying Discord $95/month in the form of boosts.
> This is a clear case of gross negligence by Discord.
I agree. This is clear because you’ve explained the context wherein you were posting those ASNs, and it is obviously not something anybody would have an issue with because
