269 karma · joined September 22, 2020
I'm not defending the use of AI chatbots, but you'd be hard-pressed to come up with a worse solution for depression than the medical system.
The real issue with increasing legal access to speed is that you're never fully aware of the impairment that amphetamines cause, because they make the user feel cognitively-enhanced, regardless of reality. In contrast, with alcohol and cannabis, the user is generally well-aware that they are not safe to drive or operate heavy machinery.
I have known SO many people on prescribed amphetamines who either wrecked their cars or narrowly avoided doing so. When I was on it, I narrowly avoided rear-ending multiple different cars before it finally occurred to me that I probably shouldn't be driving. Until that happened, I felt like my driving was being made better by the amphetamine, and for repetitive aspects of driving it probably was. For reaction time and spatial awareness, amphetamine was impairing.
Think of the profound-seeming drivel-filled essay written by a college student cranking out an essay last-minute while high on Adderall and now imagine these people all over the place, driving large pickup trucks with similar misplaced confidence in their cognitive abilities.
This avoided my ISP's block on outbound TCP port 25, and it also gave me a reputable sending IP address economically.
You can often tell which ISPs are competently managed by looking at which direction TCP/25 is blocked. Around me, there are 2 ISPs.The one that I use blocks port 25 outbound and leaves inbound open (sensible).
The incompetent, smaller ISP blocks 25 inbound, but leaves outbound wide open, as well as 587 inbound open. This effectively blocks people from receiving mail directly, but it does nothing to prevent outbound spam from being sent.
Where this would fall apart is if there are firewalls in between that silently drop UDP fragments. In a case like that, it may be necessary to do VXLAN/Wireguard/Wireguard to conceal the fragmented packets with MTUs of 1500/1550/1440 respectively, assuming IPv4 and WAN MTU of 1500. I bet this would come with a significant performance hit though.
A lot of banks do charge a percentage fee on top of Visa/MC's exchange rate, but my bank does not.
A long time ago, I once had a Netgear WGR614v10 (802.11g router). Imagine my surprise when I learned that it was possible to enable telnet access, alter the model number in the NVRAM, and flash WNR1000v3 firmware onto it, converting it to an 802.11n router. They were identical internally.
One time, I had to split a bunch of WAV files at precise intervals. I first tried ffmpeg, but its seeking algorithm was nowhere near accurate enough. I finally wrote a bash script that did the splitting much more accurately. All I had to do to find the byte offset from a timestamp in an raw PCM audio file is multiply the timestamp (in seconds) by the sample rate (in Hz) by the bit depth (in bytes) by the number of channels. The offset was then rounded up to the nearest multiple of the bit depth (in bytes) times the number of channels (this avoids inversions of the stereo channels at cut points).
Once I had the byte offset, I could use the head and tail commands to manipulate the audio streams to get perfectly cut audio files. I had to admire the simplicity of dealing with raw data.
At least in former RCN areas, there's usually at least a semi-viable competitor, and after being away for 2 months, you generally become eligible for the new customer promotions again.
On the other hand, my generic AliExpress Mediatek MT7612U works in AP mode. If I recall, it was passable, but it didn't perform that well compared to my dedicated AP; I think it was the range that wasn't as good (probably had something to do with my antennas). I also didn't test it with a lot of clients.
After a while, Google would associate the IP address of the local side of the tunnel with the location of the remote side of the tunnel.
I assume this is from Android devices connecting to the network on the remote side, being geolocated by Google Play Services, and Google tying this location with the IP address.
(Un)fortunately many captive portal are poorly designed, allowing arbitrary traffic to be sent over UDP/53 or ICMP, even when not authenticated. This kind of defeats the purpose of a captive portal, as the tunnel can be operated over UDP/53 (or whatever) and the captive portal can be solved remotely.
This could probably be scripted using Termux, OpenSSL, and Tasker.
While this doesn't directly address Delta's captive portal implementation, on many TP-Link Omada wireless APs, there is a feature that allows you to create a captive portal, and when doing this, you can either whitelist a website by its hostname or by its IP address. I was curious as to how it was filtering by hostname, so I ran a few DNS queries, which all resolved normally, indicating that it wasn't a DNS-based whitelist. Seeing as the whitelisting also worked over HTTPS, I assumed it was TLS-SNI. It turns out that anyone can whitelist any IP address by visiting any website while sending the SNI of a whitelisted hostname. This caused the AP's software to create a firewall rule allowing access to the IP address associated with the spoofed SNI. After doing this, it was then possible to connect to any website hosted on that IP address with any SNI hostname.
This isn't true for all of the EU. For example, in the Netherlands, you can buy and activate a prepaid SIM without any identification requirements. This prepaid SIM, once activated in the Netherlands, can then be used in other parts of the EU without subsequent registration.