When I was in high school in the mid 2010s, Verizon's email-to-SMS gateway didn't verify SPF/DKIM/DMARC, and I had a field day showing my classmates the Viagra ads that Hillary Clinton's "hacked" email server was sending me. In reality, it was an open relay, but Verizon didn't care; they always delivered it anyway.
Timing and scalability are probably the biggest issues with realtime P2P applications. Scalability is becoming a bit less of an issue; with mid-splits becoming the norm on cable internet services and 5G SA rolling out, there's just a lot more bandwidth to go around.
Timing issues can be worked around and GPS modules are cheap.
NAT problems aren't usually that bad. Only a minority of networks use symmetric NAT implementations, with most seeming to be using port-restricted cone NAT (EIM/APDF), which can still communicate with any other NAT implementation using endpoint-independent mapping (EIM). Most CGNAT implementations that I've encountered use EIM, with some also doing endpoint-independent filtering (EIF). Between UDP hole-punching, UPnP, NAT-PMP, and IPv6, it's usually possible to establish a P2P connection between 2 endpoints.
A game could use a hybrid client/server and P2P model, with the option to run entirely P2P while accepting its limitations.
I forget if it was $20 or $29.99, but in either event, it wasn't much. If you shop at Wally World regularly, you can sometimes find carrier burner phones for $10-$20, but finding them in-stock can be a bit of a challenge.
Many opioids, including opiates, used to be OTC. I personally know someone who used to smoke paregoric (camphorated tincture of opium), which was OTC in the US until 1970.
I believe 1970 was also the year when amphetamine (Benzedrine) inhalers stopped being OTC.
Some of us are already doing this. My main phone is a Google Pixel 8 running LineageOS 23.2 with F-Droid, microG, and Aurora Store installed.
For things requiring Play Integrity, I picked up a $20 burner carrier-locked Motorola phone at Walmart for $30. It's WiFi-only, given that I'm never going to pay for service on it, but I can also tether it to my main phone. It's also useful for writing one-star reviews on apps that require Play Integrity to function, which is something everyone should be doing.
Systems like Everseen make that approach significantly riskier than it used to be. A live video of you checking out is run through image classification software, so if you scan a steak as 4011, it'll pause the checkout flow and call the SCO (self-checkout) attendant to watch the video of you scanning the item. They then have to approve the scan, at best leaving you publicly humiliated.
One of the AP (asset protection) guys at my local store always wore an eyepatch and a t-shirt reading "A bullet a day keeps the terrorists away". He did NOT look like a typical grocery store employee, and I'm sure that was intentional.
I think it was just clock drift on the camcorder during the initial recording, as I'm pretty sure I tried adjusting the frequency of the audio track to make it the same duration as the video track, and the A/V sync was still wrong.
I'm so glad the audio and video tracks are stored interleaved, as it made my solution possible, and the results I got were great. By splitting the interleaved video into small enough chunks, padding the audio, and cutting it exactly to video length, the padding was practically imperceptible.
The only issue I ran into was that ffmpeg can't cut audio with any real precision. I eventually figured out that I could dump the audio track to a headerless PCM file, calculate the exact byte offsets for my cut points, and cut them with perfect precision using the head and tail commands from GNU coreutils. This was perfect because I was able to use the cat command to combine all of the padded audio chunks into a single raw PCM file, which I then made an AAC encode of with ffmpeg to mux with my original encoded video track.
Ffmpeg's dvvideo implantation is unfortunately just broken and mangles timecodes, even if just doing a stream copy from dvvideo to dvvideo without any re-encoding.
Fortunately, dvgrab does allow you to take the original .dv file and generate a .srt subtitle track with time stamps that you can mux into your encoded files.
I used dvgrab to ingest my old tapes, and ffmpeg and avisynth/QTGMC to de-interface and encode files for easy viewing (though I keep the original .dv files).
The biggest issue I ran into was that while the audio and video were properly synced up in the original .dv file (due to it being an interleaved format), when I re-encoded the videos, the audio and video would drift out of sync as the video went on.
I was able to fix the sync issues by using dvgrab to split the original dv file into a bunch of 3 minute chunks. I then wrote a script to extract the audio track from each chunk, pad the end of the audio with milliseconds of silence to the exact length of the video track, combine the padded audio tracks, encodes the combined track, and muxes the fixed audio track with the encoded video. This worked really well; the silence padding is imperceptible, but the audio and video are still in sync - even after 2 hours.
A final point that needs making is that doing anything with dv files in ffmpeg (even -c:v copy) destroys the SMPTE timecodes embedded in the original file, making it much harder to split by scene.
I built a revolutionary AI-powered weather forecaster. Unlike other similar websites, WeatherZOID runs entirely client-side, thus massively improving scalability and reducing hosting costs, allowing the site to remain ad-free forever.
The weather forecasts seem to have similar accuracy to the forecasts delivered by Google, but unlike Google's forecasts, if the first forecast generated by WeatherZOID is wrong the first time, you can get an accurate forecast by pressing the "Get Weather" button an indefinite number of times.
I would recommend VyOS Stream for this situation. It has better performance and hardware compatibility than *BSD-based software routers, and it also has a nice CLI that is syntactically similar to Vyatta and EdgeOS (found on Ubiquiti's Edgerouter line).
In additon, compared to PF/OPNsense or OpenWRT (Linux based), you have more control and exposure to the underlying network concepts with VyOS. You're not configuring the kernel manually, but you still learn quite a bit.
I was admittedly a bit hot-headed when I wrote the original comment, but the critical qualifier in all of this is that these driver assist technologies should be optional and easily disable-able in a persistent manner, with a dashboard warning light to remind you that they're disabled.
In a lot of modern cars, there's no straightforward way of fully disabling ABS, traction control, electronic stability control, etc. There are certainly situations where they may be helpful, such as in a top-heavy truck with an open differential, but ABS and traction control systems can pose problems in other situations, such as in snow. Especially in the case of RWD coupes with limited-slip differentials, a bit of skidding may be an asset, provided the driver knows how to correct for oversteer. Even in FWD cars, ABS can sometimes be a detriment when stopping in snow, as the rapid automated brake-pumping can dislodge the snow you were otherwise going to be holding steady on.
Ultimately, I'm opposed to driver assist features being forced onto drivers who don't want to use them. I'm also opposed to teaching people how to drive with these assistance features. It's a lot like teaching students to use AI chatbots to do their work instead of teaching them to do their work themselves.
I fully agree. Similar to killing bacteria with antibiotics, Attempting to idiot-proof machinery only leads to the creation of idiot-proofing-resistant idiots.
We need to move back to putting users back into full control. Machines (including computers) should ALWAYS respect the input of the user, even if the user is wrong.
If a person shoots themself with a gun as a result of their incompetence, we don't fault the gun manufacturer for not designing the gun to prevent auto-execution. If you can't operate a firearm safely, you shouldn't attempt to operate a firearm.
Similarly, if a person deliberately points their car a solid object and accelerates into it, the actions of the operator shouldn't be the car manufacturer's responsibility. We need to get rid of ESC, ABS, AEB, etc. These features have created a whole slew of drivers who speed headfirst into the back of stationary drivers and expect their car to stop itself. This works right up until a sensor fails and the operator flies through the windshield (usually people like this don't wear seat-belts). If you can't drive, you shouldn't be driving until you rectify your incompetence.
Similarly, phones and computers should respect user input. If a users wants root access to their personal device, they should be able to get root access. If a user runs "rm -rf --no-preserve-root /" as root, the device should oblige and delete everything, since that is what the operator instructed it to do. If you can't be trusted to use a computer, you shouldn't be using a computer until you rectify your incompetence.
The lack of accountability in modern society is disgusting, and it leads to much deeper societal problems when people refuse to better themselves and instead expect the world to shield them from their willful ignorance.
Is this new? It seems like this sort of thing has been going on for a while. A lot of the products are incorrectly labelled as containing amanita muscaria, but contain cannabinoids such as Δ8-THC and/or Δ9-THC and/or 4-substituted N,N-dimethyltryptamine derivatives, such as 4-AcO-DMT and sometimes psilocybin and psilocin themselves, in spite of their status as schedule I controlled substances.
The lack of labeling enforcement is really a problem. Genuine amanita muscaria mushrooms are a lot more like alcohol than psilocybin in terms of effects, and if you didn't know better, you could easily take a few to relax at the end of a stressful day and end up freaking out instead.
A lot of the older hybrids use NiMH batteries. With that being said, a replacement traction battery for a 2nd gen Prius isn't that expensive, at least compared to newer hybrids/EV batteries. The second gen Prius is practical, affordable, and reliable (assuming proper maintenance).
The biggest issue with the Prius (at least for the years in my price range), is that the driving experience is liable to make one fall asleep at the wheel. They're the perfect cars for monks; if you're willing to forego all earthly driving pleasures, you can get high 40s mpg.
My grandmother drove a Prius, and there was a stir in my extended family as to whether she should still be driving, as she'd been seen going 20mph below the speed limit and was driving pretty far to the right side of her lane.
I got the opportunity to drive her Prius and promptly found myself alternating between going too fast and going too slow. Between the awkward pitch of the windshield and the gross-feeling electric power steering, I wasn't the best driver either. I never have any of these problems in my 2005 Honda Civic LX or my family's 4-cylinder 2011 Ford Ranger. The Prius felt like one of those stoned driving simulators that police departments bring to high schools in an effort to prevent DUIs.
I like the idea of hybrids and EVs, but it's hard to justify completely losing the pleasure of driving for 10 extra mpg. For all I know, newer models may have improved this, but they're still to expensive for me to pay any real attention to.
Finding it's half the fun! Going out walking by a creek/river on a warm, rainy spring day is kind of an antidepressant in its own right. When you find a patch of Ovoids and pick a few, it's just all the better.
Calling the Prologue "Honda's EV" feels like a huge stretch. The Prologue was a rebadged GM vehicle that served strictly as a compliance car for meeting CAFE standards. Now that the CAFE standards have been rendered toothless, there's no longer a need for that deal.
MicroG does an excellent job at reimplementating most of Google's proprietary APIs on the client side.
I don't know how feasible this is, but it would be cool if there were open-source drop-in replacements for Google's server-sided APIs that app developers could use to replace Google's services with alternate servers running open source software.