And a minority of those kids will get curious about the How and Why. Those are the security nerds of the future securing the networks against both the kids they were themselves and actual malicious actors.
Source: Early interest in wifi security, including in other people's networks, lead me down an education and career in security
In 2019 there was a talk about data mining the DB arrival data [1] (yes, this problem is nothing new). One of the takeaways was that on some connections you can actually buy a "Sparticket" (cheaper, but only valid for a specific train), but get it upgraded to a "Flexticket" (more expensive, can take any train on the route) for free. This works because a delay of more than X minutes removes the specific train requirement and some routes are nearly always delayed by at least that threshold.
Related, there is a stable way to detect whether your .exe is running under Wine and even which version by looking up the address of the export wine_get_version in ntdll [1]. Years ago I actually had to do this to work around some weird path bug when we were testing our Windows build under Wine (easier to setup Wine than a full Windows CI).
SteamVR works ok, but last I checked it still performs worse than on Windows. If you are feeling adventurous, you can try a FOSS VR stack [1]. It works for Steam games running Proton and when it works it provides better performance. I had some troubles with it, sometimes you need to switch versions or you get some artifacts in games, or some games just don't work at all. Good thing is, switching between FOSS and SteamVR is as simple as launching either first before starting the VR game in Steam.
I guess the Linux VR stack might get a bit of love from Valve for the Steam Frame, so things might improve in the near future.
SteamVR for Linux requires DRM leasing to function and many Linux distros, well... window managers/compositors do not support this. But yes it can work.
At this point escalating, or threatening to, might be the better option. But I can't help trying to figure out how to solve a people/organizational problem with a technological solution.
Github is still famously IPv4 only. I don't know if there is a split between the SSH (if you use SSH to access the repos) and HTTPS (the tarballs) setup on their end, so maybe you get full speed on IPv6 and limited on IPv4 (or the other way around). Try disabling IPv6 on your end, if the speeds match then this might be it. If IPv6 is fast using an IPv4 gateway that tunnels via an IPv6 VPN might be a workaround.
I also had a similar problem a while back. Some speedtests showed more bandwidth than I could get in regular HTTPS downloads. I could get multiple downloads running at the same time that in total added up to the expected speed. In my case the line was just lossy enough (TCP retransmits in Wireshark) for TCP to never scale up its window size properly beyond a certain limit per connection. I verified this by running iperf in TCP and UDP against a gigabit server, UDP reached near full speed because it didn't care about a few lost packages. Working around that issue might be a bit harder, maybe [1] via [2] can provide some ideas to look into.
> I also had a similar problem a while back. Some speedtests showed more bandwidth than I could get in regular HTTPS downloads. I could get multiple downloads running at the same time that in total added up to the expected speed
Yes, this is behavior I am seeing on my end too. On Arch Linux, I enabled parallel downloads for updates via pacman. Whenever updating my system, I can saturate my connection, but as soon as I get down to one huge package, like wallpapers or rocm-llvm, the download speed for that package is only 8 MB/s.
As much as I hate where this might lead, I can't help but amuse myself over a scene like this: You walk up to a bearded fellow in a dark alley and quietly whisper "Stallman..." only for him to quietly respond "... was right.". He then opens his coat for you to choose the install USB of your favorite distro (Arch of course!). He dutifully hands you the stick and a printed copy of the GPLv5 for you to hide in your coat as you walk past the telescreens back to your home.
That part also caused my tin foil hat to heat up. At least they get the credit of including it directly instead of adding it in a later revision that gets even less news coverage. It is hard not to grow cynical when you see this.
I am also worried about another detail:
> The states also want to prevent the circumvention of blocking orders by erotic portals ... using so-called mirror domains – i.e., the distribution of identical content under a minimally changed web address. For a page to be treated as a mirror page and quickly blocked without a new procedure, it must essentially have the same content as the already blocked original.
Note the part "quickly blocked without a new procedure" so there is a way to block sites with even less process and oversight. That just invites overblocking without accountability.
Source: Early interest in wifi security, including in other people's networks, lead me down an education and career in security
reply