The problem with realtime compression via ANY codec is that you lose your ability to use B and P frames unless you add at least 16.67ms of additional latency to delay transmission by at least one frame. After all, you can't predict the content of a frame that doesn't actually exist yet. Any time there's a radical scene change that can't be delta'ed from one or more earlier frames, you're going to end up with a mangled frame or ten, because ultimately, if your link rate is 6mbps, you're transmitting 60fps, the limit of what you'll tolerate is a delay of one frame, and the actual compression is instantaneous, that STILL limits you to 100k (6mbps divided by 60fps) to somehow convey the state of somewhere between 2 million (1920x1080) and 3 million (2160x1440) pixels.
Do the math. Unless you're trying to replicate the look and feel of 'Asteroids' on a vector graphics CRT, I don't care if your compression algorithm is downright miraculous... fsck'ing 320x200 256-color VGA needed 64 kilobytes. 100 kilobits works out to approximately 12 kilobytes. Let that sink in... you're trying to somehow send an I-frame with 2-3 million pixels using approximately 20% of the ram needed to display a 320x200 VGA bitmap.
Absent some magic compression algorithm that uses something like Markov chains to pre-share a humongous dictionary of graphic data specific to your game, there's no way on god's green earth you're going to somehow convey 2-3 million pixels' worth of data in single-bit black and white, let alone 32-bit alpha-blended color, within the constraints of a 6mbps link budget, 60fps, and zero-frame pre-buffering delay (because even if you manage to compress a frame instantaneously and begin transmission immediately, your absolute data limit before you fall a frame behind on the client end is the amount of data you can physically transmit within the time it takes to display a single frame of video).
Repeat after me: the ability of h.265 to massively compress high-quality video is inversely related to the number of frames' worth of latency you'll tolerate. And even a single 16.67ms 60fps frame is enough of a delay for your controls to feel perceptibly sloppy. Two frames @ 33ms, and you're dying for reasons that aren't even your own fault. Three frames @ 57ms lag, and you might as well be wading through wet concrete.
Don't believe me? There was a story right here on Slashdot a few days ago about a study that confirmed that in a multi-player networked game, players running at 120-144fps consistently beat players running at 60fps. Latency is EVERYTHING.
One of the hardest aspects of programming a fast-action responsive multi-player networked game is dealing with conflicts where one computer sees a legitimately-landed deathblow, while another sees that same player dodge the blow because he was able to react in time. That's one of the things that prevented realtime-networked peer-to-peer Soul Calibur-like fighting games for so long... games like that literally hinged on single-pixel hits or misses within the span of a single frame. Without a server to authoritatively serve as referee, a game like that would have been unplayable even on a 100mbps LAN, let alone over the internet. And even fast DOCSIS3, VDSL2, or fiber that passes through at least one peering point has too much latency for games like that to work unless you can come up with some excuse to factor hair-trigger single-pixel hit/miss logic out of the game (and it's why someone who played games like Soul Calibur 20 years ago would view hand to hand 'combat' in today's PvP networked games as a cruel, sad, sloppy joke).
So, yeah. 5-10 frames of pre-buffering latency might be tolerable for an interactive-fiction adventure game, and 1 or 2 frames might be semi-acceptable for a PvP game with sloppy high-level excuses for 'combat', but it's just not going to cut it for games with intense action and hair-trigger reflex action. And if you're going to settle for a game where latency is tolerable, you might as well just run it natively on the phone instead of screwing around trying to remotely run it on a PC and virtualize its display over the internet.
I agree. I can't see how it could possibly have ANY chance of working as advertised UNLESS the user managed to satisfy ALL of the following requirements:
* 5mbps uplink, absolute bare minimum.
* Expensive router. Most people have NO IDEA that if they have internet connectivity faster than 50mbps down and 5mbps up, their own router/access point is likely to be their network's single biggest chokepoint.
* Good (or better) quality gigabit switches, with proper wiring. The majority of cheap "gigabit" switches can't themselves sustain a true gigabit between two ports, let alone MULTIPLE gigabit connections among their ports. Even IF they can genuinely switch a gigabit from a port, their own back-end fabric probably maxes out at a gigabit too. The internet connectivity might be a tiny fraction of a gigabit per second, but the latency of this is likely to be so bad, even a millisecond of extra latency caused by using 100mbps or less could be the latency that makes it intolerable to use.
* Video card that can do hardware-accelerated h.265... which pretty much eliminates any laptop more than a year or two old, and any desktop video card more than 2-3 years old.... and even THEN, it would probably still suck. Or at least, end up being an EXTREME disappointment, given the reality that very, very few people can sustain more than 10mbps up, regardless of how fast their nominal downlink speed might be (and because ISPs constrain uplink speed both to allow them to advertise bigger numbers for the download speed AND preserve the distinction between 'residential' and 'business' service by forcing anyone who wants faster upload speeds to pay enormously higher rates to get it).
Netflix can pull off high-quality HD with a 4-6mbps link budget because it does offline non-realtime multi-pass compression. Attempting to pull off a similar stunt in realtime is another matter entirely. It's ~80% of the reason why we didn't get to have 1080p60 in ATSC1.0... back in the 1990s (when ATSC1.0 was finalized), realtime compression of 1080p60 MPEG-2 within the ~19mbps link budget was flat-out IMPOSSIBLE... and for the most part, it still is (at least, as MPEG-2). In retrospect, the decision was kind of short-sighted... we never would have gotten to have things like live sports in 1080p60 using MPEG-2 (at least, not without a 15-60 second time-delay, using commercial breaks as an opportunity to play "catch-up" and re-fill a depleted video compression pipeline), but we most certainly COULD have had things like prime-time TV shows (and pretty much ANYTHING that can be compressed long in advance of airing) in 1080p60, even with mpeg-2
Nevertheless, I think it's absolutely delusional to expect low-latency 1080p60 live video from even a high-end gaming PC connected to fiber or premium cable/vdsl2 within a realistic, achievable present-day link budget. There are just too many things that can (and absolutely WILL) go wrong. It might be good enough for Candy Crush, but I just don't see it as being even REMOTELY viable for things like a multiplayer FPS.
Maybe... MAYBE... if Valve got networks like AT&T and Verizon to colocate high-powered virtual gaming rigs at tower sites (so literally the only constraint was the wireless data link between the phone and tower), it MIGHT not TOTALLY suck.
What, exactly, is terrible about it? The fact that it involves a half-hour instead of a whole hour? Iran and India both do it already... and I think it's safe to say that if the US & Canada did it, Britain and the EU would probably do the exact same thing within a year or two (and vice-versa).
Look at it this way... splitting the difference between standard and daylight saving time is just about the only thing at this point that's going to stop the majority of Florida from moving into year-round Atlantic Standard Time (the law was already passed, though I think it leaves the western panhandle pinned to Alabama's timezone). Once Florida gets spoiled by late sunsets all year, it's NEVER going to voluntarily rejoin the rest of the eastern US, EVEN IF the remainder eventually moves to UTC-4.5. If you think having the continental US at UTC-4.5/5.5/6.5/7.5 is "too confusing", try adding a fifth timezone ("Florida/Atlantic Standard Time") at UTC-4 into the mix as well.
Could the feds forcibly drag Florida kicking and screaming back into Eastern if it shifted it to UTC-4.5? Sure... technically... but frankly, neither party would DARE at that point to antagonize the third-largest state in the country and risk having a half hour of "stolen" after-work daylight turn into a federal election-deciding backlash from angry voters. If Florida moves to UTC-4, "Florida/Atlantic Standard Time" will be permanent as far as Florida is concerned, REGARDLESS of what the rest of the east coast ultimately decides to do.
You're assuming the "bad" product actually gets discarded. In reality, it's used to make pet food.
The single biggest thing that makes "pet food" different from "human food" is the ENORMOUS variation in formulation and taste from batch to batch. Dogs don't seem to care, but people with cats are PAINFULLY aware of it. With cats, you can't just go blindly stock up on some particular brand & flavor... you have to buy a few cans from a specific (well-stocked) store (ideally, one that keeps the cans palletized & has big stacks you can dig through), run them past your cats, note their reactions... then, when you stumble upon a can they seem to really like, RUN back to the store and buy every single can of that flavor with the same specific date/batch code. And pray to your favorite deity that you can find another acceptable batch before the current one runs out.
I first noticed the problem years ago with Fancy Feast. My cat normally liked it, but every now and then, I'd buy a 24-pack in the same flavor as always, and he'd pick away at it can after can. Then, I'd buy another 24-pack from a different store, and suddenly he'd be chowing down on it again. I finally started doing A/B testing, and discovered that I could predict with 100% certainty whether he'd like or reject the last 18 cans in a 24-pack based upon his reaction to the first 6. I have multiple cats now, and they've collectively reaffirmed my initial observation... some lots of the same nominal flavor taste better (or worse) than others.
Well, technically, it *is* "saving" daylight from the perspective of most people. Very few people are awake & take advantage of daylight at 5:30am. Nearly everyone is awake & appreciates extra daylight after work, including most of the people who ARE awake at 5:30am.
Morning traffic is naturally spread across a 3-5 hour window of time. In contrast, when DST ends, EVERYBODY (statistically) goes running for the door between 4:30 and 5:30pm, causing INSTANT gridlock that persists for hours.
It's particularly graphic in South Florida. In the summer, people without kids tend to work later, avoiding the instant 5pm gridlock that happens during the winter.
Think of it as time-domain multiplexing for freeways. If everyone on a cellular network tries to transfer a megabyte at 5pm, the network grinds to a halt and NOBODY'S data gets through. Stagger that same megabyte over a longer interval of time, and data gets through. When the sun sets early, it induces people to all hit the roads at once.
Old phones (esp. pre-2008) were "single processor" -- they used the same CPU for BOTH the radio AND running general software. That hasn't been the case for YEARS, especially since multi-core CPUs and ARM TrustZone became the norm. For all intents and purposes, the "radio" functions now run on their own virtually-isolated CPU that "regular" software (including the OS itself) can't touch.
The thing about DFS that REALLY sucks is the stupid way it ends up getting implemented... when it's time to do the DFS check, the access point just goes dark without warning for a minute, leaving everything that was connected without connectivity in the meantime.
Why can't 802.11 have an optional extension that allows the AP to tell connected clients, "hey, I'm about to go dark for a minute to do a required DFS check... in the meantime, if you really NEED continuous connectivity, temporarily switch over to 2.4GHz channel {n} at SSID="xxx" using the same credentials you used to connect to me on channel 122, and I'll let you know when it's safe to switch back"?
I mean, even the cheapest piece of shit access point that's capable of using a DFS-protected channel is almost guaranteed to have 2.4GHz 802.11n, so why not provide a way to automatically (and rapidly) fail over to it during the DFS check? Even if 2.4GHz wifi sucks, connectivity that temporarily SUCKS for a minute is still a net improvement over connectivity that DOESN'T EXIST AT ALL for a minute.
Likewise, if 802.11 had a way to communicate that upcoming DFS check to wifi-connected clients, they could try to do a better job of anticipating it. For example, if Netflix has been sustaining 6mbps buffered ahead by 5 seconds, it could attempt to crank things up to pre-buffer enough content to get you through that dry minute without glitches if it knew the disruption was coming and had time to prepare.
DFS is important, but the way it was IMPLEMENTED needlessly sucks more than it HAS to.
There are two even EASIER ways a malicious vendor could enable a computer to spy on you:
1. Make the sound chip extra-flexible, so that it's designed to be connected to three 1/8" jacks and allow any jack to be software-configurable as a mic input, a line-level output, or a headphone output. If the user connects a pair of headphones, you can then use them as a pair of low-fidelity microphones, even if they've bent over backwards to make sure to omit/disable any explicit microphone.
2. Connect the piezo transducer soldered to the motherboard (used to beep BIOS error codes) to the sound chip, with the same internal mods to allow it to work in both directions (as both a speaker AND a mic, depending upon whether the pins it's connected to are configured via software to be outputs or inputs).
Or, if the goal is to enable an agent to exfiltrate data from a computer that has its outputs nominally locked down, use the motherboard speaker (if it's wired in a way that uses directly-generated PWM to make sound instead of a transistor feedback loop with a capacitor) to generate ultrasonic audio & capture it with a second device.
The point is, physical security matters at least as much as software security does. If a malicious actor has physical control over a device, you've already lost the battle. On the other hand, attacks like this are practically impossible to pull off unless you literally HAVE the resources of a state espionage agency. While "China" most certainly falls into the category of "has the resources and expertise to do it, at least occasionally", consider for a moment that China's economy (and by extension, the CCP's ability to govern the masses) depends almost entirely upon its ability to sell and export products. Patent laws might be lax in China, but they most certainly apply to products exported to another country. If "China" copied some secret high-tech technology from Tesla or Intel (which they could almost as easily obtain just by downloading the patents from the USPTO's web site), they wouldn't be able to sell it abroad anyway, so it really wouldn't be much use to them ANYWAY. And their overseas divisions of that company would be sued into bankruptcy by the company they stole the technology from.
Corporate espionage sounds hot & sexy, and has been the theme of god knows how many Hollywood movies... but in the real world, it's pretty damn rare. Very, VERY few things are genuine "trade secrets" that aren't publicly-known ANYWAY. Not even Coca-Cola's formula is particularly "secret" -- Coca Cola's value isn't its taste, but its brand name. If you copied Coca Cola's formula verbatim (and somehow managed to source de-cocanized coca leaves), manufactured it, and sold it, the company couldn't do a damn thing to stop you... as long as neither you, nor anyone with any kind of ties to you, EVER uttered the words "Coke" or "Coca Cola". The moment they did, you'd be sued into oblivion for trademark violation. And if nobody ever DID disclose the fact that your product tastes exactly like "the Real Thing", hardly anyone would notice or buy your product... because the truth is, Coca Cola doesn't actually taste all that great (something Pepsi has been reminding people for literally decades at every possible opportunity).
Similarly, consider the annual export value of Huawei's products to China's economy. Now consider the almost piddling value of any intelligence gained using compromised Huawei products relative to the value of those exports, and just how staggeringly HUGE of a hit China's economy would take if it were caught red handed selling products designed to allow spying. China's government would, frankly, have to be completely fucking INSANE to risk that kind of direct economic damage. That's not to say China's intelligence agencies don't try at all to coax companies into including subtle features that can be repurposed and used for espionage purposes... but ultimately, it would be equally naive to think that US intelligence agencies don't have agents working for companies
It's not quite *that* easy... you STILL have to account for the very real possibility that another vehicle might LIE about its current state or intentions... possibly to try and get an advantage for its driver & allow it to save 30 seconds merging into traffic, get a better parking spot, etc... possibly to cause mayhem, death, and destruction.
Simply put, trusting untrustworthy input is dangerous. At best, you can treat it like, "Trust, but Verify".
More likely is that someday, government road departments will deploy their own sensors & make the data available (with robust security) to cars in the area. And even THEN, you have to consider the real possibility of sabotage (if only the equivalent of, "drunk teens taking a stop sign for shits & giggles).
You have to deal with scenarios where multiple signals contradict each other. Some are easy... if a database says you're approaching an intersection with a stop sign, but no stop sign is visible, the algorithm can sensibly assume there SHOULD be a stop sign & act accordingly, because the consequences of an unnecessary stop are minor compared to the consequences of an IGNORED necessary stop. Ditto, if the car sees a stop sign, but the database says nothing, or says it's a yield sign. Worst-case, the car treats it as a 'yield' & slows down enough that it COULD stop if it sees an oncoming vehicle.
That said, there's also a case to make for "conga line" logic, especially if most cars are still human-driven. If the car finds itself on a road with ambiguous/conflicting lane markers, and the car in front of it swerves, there's a solid argument that the car behind it might want to swerve, too, even if it sees no other reason to do it. Where external sensors (in other cars, on state DOT drones, etc) become useful is evaluating the logic for such behavior when detected so that a single swerving human won't turn into a 6-hour ripple (think: those times when you're in gridlock, the road suddenly opens up wide in front of you, and you're left wondering why everyone in front of you stopped. It's because some past event brought traffic to a halt, and it persists long after the original reason is gone).
Where self-driving + external coordination can help is resolving those situations gracefully. Like Howard Stern's joke about, "ok, on the count of 3, everyone stopped by mm77 on the NJ turnpike slowly begin accelerating & everyone can start moving together". With humans, it would just cause more fender-benders. But with autonomous vehicles & proper PID logic, the electronic "traffic cops" COULD carefully break up the "clots" and digitally shoo people along to break up wave effects.
Current self-driving is entirely self-contained in an attempt to bootstrap it, because it takes DECADES for road upgrades, even things like signage (there are STILL a few 1960s-era nonstandard-colored US-highway route signs scattered around Florida... the ones that show US-1 in red, US-41 in orange, US-27 in green, etc. Admittedly, it's because they aren't really hurting anything & the few remaining ones have almost become tourist attractions & photo spots, but it shows just how long legacy stuff can persist). It can take a decade or two just to plan & fund a road project, and ANOTHER 5-20 years to do it (Miami's Palmetto Expressway has been in a state of perpetual construction somewhere along its length for pretty much my entire sentient life... as soon as the late-80s round of upgrades finished after ~30 years, FDOT tore it up AGAIN to add the Lexus lanes & rebuild the I-75 interchange for the third time in 20 years (#1 grafted exit ramps to NW 138th st into it, #2 widened the deck of the ramp to northbound 75 to add a lane, #3 is underway now). Even if everyone agreed NOW about how to add electronic sensors & signaling for autonomous cars, it would take 10 years for the minor upgrades, and 25-40 years for the ones requiring major new construction to get funded & built.
Sensible compromise (albeit somewhat worthy of a Douglas Adams or Terry Pratchett novel): make Britain GMT+0:30 year-round, with the exception of the Greenwich Observatory & its parking lot, plus some symbolic (but small) radius centered upon Stonehenge, which would be GMT year-round.
A sensible combination of pragmatic compromise and symbolism.
There's nothing that says timezones HAVE to be exactly one hour apart, and several countries already have timezones that split the difference and lie on a half-hour boundary instead.
30 minutes is enough to give most of the benefit of extra daylight in the evening after work, while reducing the hardship of early-morning darkness to a couple of weeks.
Guaranteed, if the EU splits the difference for Central European time, the US will do the same thing within a year or two (and vice-versa).
Most people don't want to give up summer evening daylight, and a lot of people don't want 9am dawn, but everyone hates clock-changing. Splitting the difference between summer and winter time is a sensible compromise.
First, sniff the robot's wifi traffic using Mallory transparent MITM proxy ( https://github.com/intrepidusg... ). Note that there might be better intercepting wifi proxies available now... possibly, based upon other platforms like ESP32, ESP8266, or RasPi. I really haven't kept up with it. I just remember that at the time I did it, using Mallory with a desktop PC and PCIe wifi card seemed like the obvious choice.
The last time I used Mallory (~5 years ago), it was somewhat straightforward to set up (with slightly above-average Linux experience)... AS LONG AS you used a wifi card with a supported chipset:
* It HAS to be a PCIe wifi interface, because the host PC needs realtime access to the bare-metal wifi hardware that USB just isn't suited for.
* Not all wifi chipsets have binary Linux kernel modules available that support the features necessary to fully implement a wireless access point. I think I remember that most/all Atheros-based cards were suitable, but only a select few Realtek-based cards were... and then, with major disclaimers and caveats. This situation might have gotten better OR worse over the past 5 years. I haven't kept up with it.
* Use EXTREME caution before buying a Linksys or Netgear interface card, based upon web reviews saying that it uses some specific (and supported) Atheros chip. Both companies have a really nasty habit of using Atheros chips for their first generation of a product, racking up glowing 5-star reviews and people praising it as the greatest product the company has ever made... then quietly redesigning later versions to use cheaper, less flexible chipsets. Sometimes, without even bothering to change the UPC... occasionally, without even mentioning on the packaging that it's a later revision. You might be better off skipping the brand-name card, and just hunting on eBay for a generic card that identifies its chipset by name. Generally speaking, Linux doesn't care about the brand or model number of the card... it only cares about the chip used to implement it. In theory, two cards built around the same chip COULD be wired up differently... but 99 times out of 100, companies in China that make generic cards just take the chipset vendor's reference design and copy it verbatim.
Anyway, once you have Mallory up and running, it looks just like a wireless access point. Connect the robot to it just like you'd connect the robot to a normal access point, and have Mallory begin capturing traffic WITHOUT decrypting it.
At this point, you'll know two things:
1. The hostname it's connecting to for its web service calls, and the protocol it's using.
2. Whether or not it's encrypting its traffic. If it's encrypted, you'll basically see a CONNECT followed by garbage. If it's NOT encrypted, you'll probably see straightforward http GET or POST requests in the log.
If it's NOT encrypting the traffic at all, you're in luck. Jump ahead to step 4.
3. Enable Mallory's decryption, and restart the robot so it will attempt to connect to its home server like it did before. If you're EXTREMELY lucky, it'll decrypt the traffic without a hitch. If you're unlucky, the robot will either hang, or give an error that's ultimately caused by an invalid TLS certificate.
If the Robot's software was written properly, it won't make it past this point, and you'll basically be out of luck absent some as-yet undiscovered exploit. HOWEVER, it's quite possible that it MIGHT just ignore the certificate error. There's literally a metric shit-ton of bad example code on StackOverflow and elsewhere that gives the impression that it's OK for apps to just ignore certificate errors, and I'd say that in the real world, probably 60-80% of "secure" devices that "use https" will completely IGNORE certificate errors. Why? Certificates are a royal pain in the ass to deal with during development, because the debugging needs of developers are more or less perpendicular to the demands made by robust security. More often tha
If you wouldn't mind, can you read the MID codes from those discs & post them here? (You can use a tool like CDspeed to read the MID code -- http://www.cdspeed2000.com/ ).
Ultimately, the MID code is the final authority on whether or not a disc is HTL or LTH, because it's how the drive determines its writing strategy.
My guess is that the manufacturer of the discs you bought just decided that it didn't even HAVE to identify its discs as "LTH" on the packaging anymore, and didn't.
I suppose it's not inconceivable that things might have changed... but absent a low-key industry-wide move to abandon LTH and return to HTL, I think it's MORE likely that the manufacturers just found a loophole that allowed them to stop disclosing on the packaging that a given pack of discs are LTH.
My own personal Amazon experience the last time I bought non-LTH discs ~2 years ago was that nearly all of the discs listed there said nothing whatsoever in the listing about whether the discs were HTL or LTH, and NONE of the non-Verbatim discs were HTL when I looked up the UPC or SKU number online.
There are two kinds of BD-R (recordable blu-ray) discs.
The first ones that came out had a shiny metallic layer that permanently dulled when the laser burned it. The technology was used precisely because everyone knew by that point that recordable discs based upon organic dyes had a TERRIBLE track record for long-term stability. By the time development of BD-R discs began, nearly ALL 10+ year old CD-R discs had at least some unreadable sectors, and DVD+R and DVD-R had an even WORSE track record. The catch was, the first-generation BD-R discs required a totally new manufacturing process and tooling, so only a few large companies (like Mitsubishi/Verbatim) made them... and they were pretty expensive, especially compared to DVD+/-R discs.
A few years later, the industry decided that Azo-based organic dyes WERE good enough for the unwashed masses, even while simultaneously conceding that their long term stability was unquestionably likely to be inferior to the original BD-R discs. Basically, their argument was, "yeah, Azo-dye BD-R discs will start becoming unreadable after 5-10 years... big deal, most people don't need archival-quality discs with hundred-year lifespans, and anyone who does can still use the more expensive original kind." At that point, companies like CMR (legendary for making low-quality discs) jumped on the bandwagon, and started cranking out LTH BD-R discs by the millions.
The really SHITTY decision the industry made was NOT giving a unique, unambiguous name to the original non-LTH type BD-R discs. Officially, they might be referred to as "HTL" (high to low)... but you will NEVER see "HTL" as an advertised feature, nor is there any unambiguous logo, certification, or anything else that allows you to unambiguously determine that a given pack of discs is HTL type, and not LTH. All "LTH" discs will specify it somewhere on the packaging... but they won't necessarily go out of their way to make it obvious, and they'll often try to word it as though it's a selling point instead of a disclaimer.
Broadly speaking, the cheapest non-LTH discs are usually going to be at least twice as expensive as the most expensive LTH discs. Of course, you might always get lucky and trip over a liquidation sale or something, but most of the time, you can just ignore the cheapest discs entirely and take for granted that they're going to be LTH.
Likewise, store-brand and non-major brand discs are almost ALWAYS going to be LTH. Ditto, for pretty much any discs purchased at a big-box retail store like Best Buy or Walmart. For all intents and purposes, you're going to have to buy non-LTH discs online.
Take Amazon reviews and listings with a pound of salt. Amazon is NOTORIOUSLY sloppy with its "SKU-keeping". If a listing doesn't EXPLICITLY identify a specific model number or UPC, you should probably assume the worst. Likewise, if the listing says the discs are non-LTH, but it's merely "fulfilled by Amazon", double check the SKU or UPC listed in the ad. Amazon is known for being really sloppy about commingling things they view as "commodity items. By the same token, if the listing unambiguously identifies a SKU/UPC for a product you've confirmed is non-LTH, but there's one or more reviews that say it's LTH, that could mean EITHER that Amazon was sloppy and sent someone a pack of LTH discs despite the ad saying they were non-LTH, or Amazon's powers that be might have just gotten sloppy and lumped reviews for BOTH LTH and non-LTH discs together. Amazon really sucks about doing that. Either way, if you DO buy the discs from Amazon, my advice is to 1) MAKE SURE there's something in the listing that UNAMBIGUOUSLY indicates that the discs are non-LTH (preferably, a SKU or UPC that you've independently verified via the manufacturer's web site), 2) check the discs when they arrive, and don't be shy about demanding a refund if they end up being LTH after all.
Newegg is a little better. At least, as long as you stick to items that are literally sold by Newegg itself (the last time I checked, they
In a sense, it IS kind of like having a house with rooms piled floor to ceiling.
Consider for a moment the data on a 250GB USB1.1 hard drive frome sometime around 2006. Ignoring for a moment the increasing annual possibility of drive failure due to age, imagine trying to look for a file on that drive. At USB 1.1 speeds, the disc is for all intents and purposes locked away and unusable (at least, from the perspective of Windows Explorer or Gnome 3's file manager, especially if the computer has antivirus software running that decides to try scanning the entire drive before it'll allow you to do anything with it). Connect the drive to a computer running a minimalist Linux distro and use Bash to copy the files to a newer, faster hard drive, and it's probably going to take DAYS for the copy to complete. Even if you rip the drive out of its enclosure and connect it to an IDE-to-SATA-to-USB3 adapter, it's going to take at least half the day to finish, just because even pre-SATA IDE was shockingly slow compared to SATA2 or SATA3.
There's also the fact that hard drives are AWFUL for long-term storage. They can literally suffer mechanical failure after years of non-use... and if it happens, cheap recovery options are basically nonexistent. They start at 'ungodly expensive' and increase exponentially from there.
Non-LTH single-layer BD-R media is just about the best long-term storage medium available today (cheaper LTH media is no better than organic-dye DVD+/-R... it fades and has a predicted half-life of around 3-10 years before accumulating enough errors to prevent reading as a normal filesystem, and 10-20 years before accumulating enough errors for even forensic recovery to encounter nonrecoverable errors in at least a few files). But BD-R media is pretty slow to read compared to just about everything besides tape. So, once your BD-R collection grows beyond a certain point, you'd BETTER have some good way to at LEAST keep a copy of the file metadata indexed and on something like a hard drive or SSD, or you're going to be in a world of pain trying to someday even figure out what files you HAVE, let alone the contents of any file.
That said, if you had to pick a single media type for "throw in a box and forget about it until far in the future", Non-LTH BD-R is absolutely your best choice. Even if optical drives cease to be a common cheap CONSUMER item, they're all but GUARANTEED to exist in some form for bulk archival storage & commonly used by libraries, universities, enterprises, etc. Just be aware that getting a mountain of BD-R discs containing 40TB of data into a form that can be searched and browsed in any kind of interactive manner will probably itself require several weeks of effort.
Note: avoid the temptation to use multi-layer discs. Multi-layer discs have a lot more that can go wrong (and can manifest unrecoverable read errors for deeper layers long before a single-layer disc of comparable age would have encountered problems). Also, when you're storing data for the long haul, be aware of your goals. Requiring that the disc be directly-readable as a normal mounted filesystem without special handling is a MUCH more difficult goal than simply requiring that data be confidently readable by forensic means. A BD-R that Windows 2030 someday chokes on and rejects as 'unreadable' when you stick it in (because the malware analyzer choked on an unrecoverable read error) might nevertheless be readable just fine if you rip the raw bitstream from the disc using Ubuntu 42.06 and use a utility to reconstruct a corrupted UDF filesystem. And if you actually know what precisely you're looking for and approximately where to find it, your likelihood of getting it off the disc is likely to be high for decades, maybe centuries.
Someday, digital archaeologists are going to make careers out of using robotic disc-rippers and AI content-analysis to sift through exabytes of old data from the 21st century, searching for treasures like an old cat video from Youtube that HASN'T already been viewed 400 trillion times, or a fifth-grade book report from someone who later went on to become the 84th president of the United States.
My main complaint with folding Thunderbolt into USB is the fact that it opens the door for asshole manufacturers like Apple to turn around and make laptops with a single fucking USB port, then expect consumers to go out and buy an ungodly expensive hub to unwrap everything.
In the beginning, there was DisplayPort. Using it with multiple displays required an expensive hub, but you could also use it with a cheap passive adapter cable to connect a single HDMI display. And it was good.
Then came Thunderbolt. Thunderbolt was multiplexed into DisplayPort. In theory, using the port for BOTH Thunderbolt AND DisplayPort required a UNGODLY expensive hub, but in reality, the only thing anyone cared about connecting via Thunderbolt was an external video card that had a DisplayPort or multiple HDMI ports of its own, so you could skip the expensive hub since you were still only connecting a single device to the computer itself using the computer's single DisplayPort port. And it was still good.
Then someone got the idea of multiplexing DisplayPort into USB. At first, it seemed like an OK idea... you could still use a cheap adapter cable to connect a single Thunderbolt eGPU to one of the ports, and use a $15 USB hub to connect things to the remaining USB port(s). After some nervous concern, it was still good.
Then Apple decided to Boldly Innovate, and sell laptops with a single USB port that needs a $500 hub if you want to use BOTH Thunderbolt (or DisplayPort) AND USB peripherals, and other manufacturers quickly followed just because they all blindly follow every stupid trend Apple comes up with. And it really, totally, fucking SUCKED.
Condensing everything -- PCIe, video, and USB -- into a single port that needs an expensive hub is OK when you're talking about a device like a phone that has extremely limited space for external expansion ports AND where using external peripherals is itself an extreme, rare edge case... but doing it with something like a LAPTOP where there's MORE than enough room for a half dozen ports, and would add only a few cents to the manufacturing cost, is just plan mean and user-hostile.
Yeah, combo hubs will probably be cheap SOMEDAY... but in the meantime, we're looking at 3-5 years of needing hubs that cost more than the peripherals connected to them. DisplayPort got away with needing an expensive hub, because most people didn't actually NEED that expensive hub to use it for the most common use case (connecting a single monitor). That's absolutely NOT the case with USB... especially if the manufacturer decides to pull an 'Apple' and ALSO use that single USB port for power delivery as well.
Oh, please. An average "smart" TV is dumber than a 4 year old Roku. An average gaming mouse probably has more onboard flash than an average "smart" TV.
Cryptocoin mining? Give me a break. The "smart" TVs I've seen huff and puff just trying to display a fsck'ing MENU on the screen. Their ability to decode h.264 on the fly is an illusion... it's all done by limited-purpose hardware, stapled together by a "computer" that's about as powerful as a SNES.
Serving child porn? Via some mystical 5G free data that was forced on you by the TV manufacturer? Don't make me laugh. The only thing 5G is going to bring America is higher average monthly phone bills. Even IF (big IF) future "smart" TVs include "free" 5G data service for some purpose, you can bet your ASS it's only going to be "free" to use for accessing the services of specific partner companies. The only way any "smart" TV is EVER going to be capable of using "5G" to stream ANYTHING outbound from your house is if you've intentionally paid for that service. So no, I'm not about to lose the slightest bit of sleep worrying that hackers are going to use my future TV to stream child porn over 5G data I can't disable, because I'm not going to PAY for 5G data service for my TV above and beyond what I'll already be paying for fiber, and I probably won't BOTHER with the TV's "smart" functionality anyway, because it'll be too stupid and crippled compared to all the discrete devices I'll have available to use instead.
And in any case, if my TV gets hacked and is somehow being used to stream child porn, it'll be one of approximately 20-30 million compromised TVs doing exactly the same thing at that point. Paraphrasing Stalin a bit, "one person serving child porn is an evil pervert... 20 million people inadvertently serving child porn via hacked smart TVs is a statistic".
Camera? Meet electrical tape. And worry MORE about the half-dozen OTHER cameras strewn around the house, most of which will have less real security than the TV ultimately does.
Mic? The battle is already lost. If you have fewer than four dozen internet-connected microphones within 100 feet of the TV at that point, you'll probably be lucky. If someone really wants to eavesdrop on you, they won't HAVE to hack YOUR devices... they'll be able to hack your neighbors' devices and use them as directional listening devices against you anyway.
Look at it this way. If you're in a group with 10 people getting chased by a hungry bear, you don't have to be able to out-run the bear, you just need to outrun the slowest member or two of the group and be a less-appealing target so the bear will capture and eat THEM instead of you. Your future smart TV will be one device out of literally trillions of minimally-secure devices spread around the world. Use it as a dumb monitor with your own discrete media devices, and it's unlikely to be one of your biggest likely future security problems.
If Tesla were smart, they'd cut a deal with someone like Hertz or Avis, so that if you wanted to test-drive a Tesla, you could go rent one for a week (at some non-free price that would be considered a fair price if you were just renting it to drive for a week while traveling), then apply the price of up to 4 rental weeks from the past year to the purchase price of a Tesla if you decided to buy one.
IMHO, that would kill two birds with one stone... it would avoid the problems of dealing with returned cars from people who changed their minds (since the same cars would be rented over and over), while simultaneously drawing in potential buyers who might decide to rent a Tesla for a week while on vacation & decide that they absolutely LOVED it. It also minimizes the impact of regional availability... a family from a small town in North Dakota or Montana could rent a Tesla while vacationing in Orlando, Miami, or Las Vegas for a week just as easily as a family from Seattle or Atlanta. It also minimizes the risk to the people trying one out... if even a "normal" rental car in Miami is going to cost $200 for the week, and you can get a Tesla for $50-100 more, lots of people who might not have gone out of their way just to rent a Tesla in their hometown might say "fuck it, I'm on vacation, gimme the Tesla!"
Honestly, I think their BIGGEST problem would be supplying with the rental car company with enough cars to satisfy the demand. They probably WOULD have to start off for the first year or two by limiting it to just a couple of very popular vacation markets... say...
year 1: Orlando and Las Vegas
year 2: Miami, Washington DC, Los Angeles, Chicago
year 3: every remaining international airport in Florida, plus every city that currently HAS a Tesla showroom. I'd expect that over time, places like South Florida would probably have Tesla-equipped Avis/Hertz locations at BOTH the airport AND some off-airport suburban locations that seriously blurred the line between "rental car office" and "de-facto Tesla showroom".
Their biggest problem would be convincing Hertz or Avis to keep the cars in circulation for 2-3 years instead of replacing them all annually (since otherwise, Tesla would be struggling just to keep the rental car company fully supplied, let alone anyone else).
> What possible security or control do you hope to gain from it having an hdmi port?
Er.... being able to completely ignore the remainder of the TV's alleged capabilities, and use it as a dumb video display to watch content using devices that ARE under my own control? With a means of directly feeding video into my TV and using it directly as a dumb video display, everything else becomes largely moot.
> your TV will be online.
Big. Fscking. Deal. If it's not on my home network, and I'm using it as a dumb video display, the TV can ping a 5G carrier forever (at the TV-vendor's expense) for all I care.
I mean, seriously. There's "security-aware", then there's "tinfoil-hat-paranoia". What do you seriously think someone like Samsung or Toshiba is going to do, secretly send screen-captures of your HDMI-fed content back to their servers just so they can find nefarious ways to violate your privacy? It would be legal suicide, if only because it would only be a matter of time until some copyright holder sued the TV manufacturer for infringement (since those screenshots technically wouldn't have been authorized by the copyright holder).
Worst-case, your 7 year old smart TV someday connects to a 5G network without your permission, gets bricked by hackers exploiting an old vulnerability, and you join the class-action lawsuit against the manufacturer and end up getting a free new TV out of the deal. Vendors can make all the noise they like about disclaimers, warranties, and EULAs... if a company big enough to make smart TVs gets caught with its pants down like that, they WILL take a legal beating in at least one jurisdiction somewhere in the world.
> in a very short time they will come with a 5G radio that you dont control
And, what? You think they won't have a HDMI port? Jesus, even the worst bargain-priced Black Friday piece of shit in electronics history came with a HDMI port, composite+stereo, and an antenna input. Most have multiple HDMI, a component port or two, at least one s-video plus multiple composite & stereo inputs, Toslink and/or S/PDIF input (and usually, one for output, see note).
Many even have a useless VGA port ("useless", because the mfr. limits it to 1024x768, and explicitly disallows 16:9 640/704/720 x 480/576, or any other mode that might be useful for media... but handle even 1920x1080@50/59.94/60 just fine if your laptop has a video chip that can output component video using vga-port pins & you have the right octopus cable).
One MAJOR reason why mfrs (in the US, at least) love "smart" TVs: they can sell a TV with the hardware to receive OTA broadcast atsc, but only pay royalties for users who actually "activate" the capability online. The royalties aren't cheap ($10-20/set, I think), and they're required by law to include a tuner on any device marketed as a "TV" (vs "computer monitor"), but most people don't actually USE the tuner (and many who WOULD just give up when presented with an 'online activation' step), so it's an easy way for the mfr. to save millions of dollars in royalties.
---
note: 99.999% of TVs made after 2006 that have toslink or spdif out will only use it to output PCM 2.0 stereo for content extracted from HDMI. OTA is hit or miss... AFAIK, they're ALLOWED to output DD5.1 via toslink/spdif for OTA content, and can pass through DD5.1 FROM toslink/spdif, but many just blindly downconvert EVERYTHING to 2.0 stereo.
What, exactly, does "blockchain" have to offer with regards to "proof of authorship" that conventional PKI and digital notarization doesn't already address perfectly well?
Seriously. If you're trying to establish ownership of something in court, the only opinion that matters is the legal system's. If one side's case is based upon the word of a government-recognized notary, backed up by PKI provided by Verisign in compliance with the required ISO certifications... and the other side's case is based upon the word of some crowdsourced blockchain... the side with the notary and Verisign behind them is going to win, every single time. Even if blockchain ultimately gained equal recognition by the government, Verisign is still going to either outgun it... or own it as a subsidiary, rendering the distinction moot anyway.
The big problem with 10gbps is that it's too fast to handle with more than a few feet of copper, and fiber is a BITCH to terminate.
The other problem with 10gbps is that it's simultaneously too fast AND too slow.
From the perspective of a single endpoint device (like a computer), 10gbps is absurdly fast for Ethernet... but the two things you might actually WANT to wrap up and transmit over Ethernet -- HDMI and multi-lane PCI Express data -- blow past 10gbps and keep going without looking back.
So... as a transport medium for connecting switches with gigabit ports, a 10gbps backbone is a nice, sensible speed. But for the few things that genuinely outstrip the capabilities of gigabit Ethernet, 10gbps is ALREADY obsolete and inadequate.
Think of it this way: suppose that circa 2008, you had an old laptop with 128mb of PC100 RAM that could be expanded to a gigabyte of PC100 RAM at staggering cost(*)... except by that point, Windows could barely boot without thrashing itself to death with anything less than 2 gigabytes, so spending ANYTHING to expand its RAM at all would be largely pointless because even the most expensive expansion possible would still be inadequate to solve the problem that motivated its expansion in the first place.
(*) For those who remember, high-capacity PC100 RAM was a weird era in PC history... lots of computers could ONLY use it, and not PC133... but by the time the chips to make 256mb modules had become semi-affordable, the market for those modules had largely dried up, so we had a period when smaller sizes were basically worthless... but 256mb PC100 modules pulled from a scrapped computer sold for more on eBay than brand new DDR(2/3) modules with 1-4 gigabytes at Best Buy.
Slashdot Mirror
The problem with realtime compression via ANY codec is that you lose your ability to use B and P frames unless you add at least 16.67ms of additional latency to delay transmission by at least one frame. After all, you can't predict the content of a frame that doesn't actually exist yet. Any time there's a radical scene change that can't be delta'ed from one or more earlier frames, you're going to end up with a mangled frame or ten, because ultimately, if your link rate is 6mbps, you're transmitting 60fps, the limit of what you'll tolerate is a delay of one frame, and the actual compression is instantaneous, that STILL limits you to 100k (6mbps divided by 60fps) to somehow convey the state of somewhere between 2 million (1920x1080) and 3 million (2160x1440) pixels.
Do the math. Unless you're trying to replicate the look and feel of 'Asteroids' on a vector graphics CRT, I don't care if your compression algorithm is downright miraculous... fsck'ing 320x200 256-color VGA needed 64 kilobytes. 100 kilobits works out to approximately 12 kilobytes. Let that sink in... you're trying to somehow send an I-frame with 2-3 million pixels using approximately 20% of the ram needed to display a 320x200 VGA bitmap.
Absent some magic compression algorithm that uses something like Markov chains to pre-share a humongous dictionary of graphic data specific to your game, there's no way on god's green earth you're going to somehow convey 2-3 million pixels' worth of data in single-bit black and white, let alone 32-bit alpha-blended color, within the constraints of a 6mbps link budget, 60fps, and zero-frame pre-buffering delay (because even if you manage to compress a frame instantaneously and begin transmission immediately, your absolute data limit before you fall a frame behind on the client end is the amount of data you can physically transmit within the time it takes to display a single frame of video).
Repeat after me: the ability of h.265 to massively compress high-quality video is inversely related to the number of frames' worth of latency you'll tolerate. And even a single 16.67ms 60fps frame is enough of a delay for your controls to feel perceptibly sloppy. Two frames @ 33ms, and you're dying for reasons that aren't even your own fault. Three frames @ 57ms lag, and you might as well be wading through wet concrete.
Don't believe me? There was a story right here on Slashdot a few days ago about a study that confirmed that in a multi-player networked game, players running at 120-144fps consistently beat players running at 60fps. Latency is EVERYTHING.
One of the hardest aspects of programming a fast-action responsive multi-player networked game is dealing with conflicts where one computer sees a legitimately-landed deathblow, while another sees that same player dodge the blow because he was able to react in time. That's one of the things that prevented realtime-networked peer-to-peer Soul Calibur-like fighting games for so long... games like that literally hinged on single-pixel hits or misses within the span of a single frame. Without a server to authoritatively serve as referee, a game like that would have been unplayable even on a 100mbps LAN, let alone over the internet. And even fast DOCSIS3, VDSL2, or fiber that passes through at least one peering point has too much latency for games like that to work unless you can come up with some excuse to factor hair-trigger single-pixel hit/miss logic out of the game (and it's why someone who played games like Soul Calibur 20 years ago would view hand to hand 'combat' in today's PvP networked games as a cruel, sad, sloppy joke).
So, yeah. 5-10 frames of pre-buffering latency might be tolerable for an interactive-fiction adventure game, and 1 or 2 frames might be semi-acceptable for a PvP game with sloppy high-level excuses for 'combat', but it's just not going to cut it for games with intense action and hair-trigger reflex action. And if you're going to settle for a game where latency is tolerable, you might as well just run it natively on the phone instead of screwing around trying to remotely run it on a PC and virtualize its display over the internet.
I agree. I can't see how it could possibly have ANY chance of working as advertised UNLESS the user managed to satisfy ALL of the following requirements:
* 5mbps uplink, absolute bare minimum.
* Expensive router. Most people have NO IDEA that if they have internet connectivity faster than 50mbps down and 5mbps up, their own router/access point is likely to be their network's single biggest chokepoint.
* Good (or better) quality gigabit switches, with proper wiring. The majority of cheap "gigabit" switches can't themselves sustain a true gigabit between two ports, let alone MULTIPLE gigabit connections among their ports. Even IF they can genuinely switch a gigabit from a port, their own back-end fabric probably maxes out at a gigabit too. The internet connectivity might be a tiny fraction of a gigabit per second, but the latency of this is likely to be so bad, even a millisecond of extra latency caused by using 100mbps or less could be the latency that makes it intolerable to use.
* Video card that can do hardware-accelerated h.265... which pretty much eliminates any laptop more than a year or two old, and any desktop video card more than 2-3 years old. ... and even THEN, it would probably still suck. Or at least, end up being an EXTREME disappointment, given the reality that very, very few people can sustain more than 10mbps up, regardless of how fast their nominal downlink speed might be (and because ISPs constrain uplink speed both to allow them to advertise bigger numbers for the download speed AND preserve the distinction between 'residential' and 'business' service by forcing anyone who wants faster upload speeds to pay enormously higher rates to get it).
Netflix can pull off high-quality HD with a 4-6mbps link budget because it does offline non-realtime multi-pass compression. Attempting to pull off a similar stunt in realtime is another matter entirely. It's ~80% of the reason why we didn't get to have 1080p60 in ATSC1.0... back in the 1990s (when ATSC1.0 was finalized), realtime compression of 1080p60 MPEG-2 within the ~19mbps link budget was flat-out IMPOSSIBLE... and for the most part, it still is (at least, as MPEG-2). In retrospect, the decision was kind of short-sighted... we never would have gotten to have things like live sports in 1080p60 using MPEG-2 (at least, not without a 15-60 second time-delay, using commercial breaks as an opportunity to play "catch-up" and re-fill a depleted video compression pipeline), but we most certainly COULD have had things like prime-time TV shows (and pretty much ANYTHING that can be compressed long in advance of airing) in 1080p60, even with mpeg-2
Nevertheless, I think it's absolutely delusional to expect low-latency 1080p60 live video from even a high-end gaming PC connected to fiber or premium cable/vdsl2 within a realistic, achievable present-day link budget. There are just too many things that can (and absolutely WILL) go wrong. It might be good enough for Candy Crush, but I just don't see it as being even REMOTELY viable for things like a multiplayer FPS.
Maybe... MAYBE... if Valve got networks like AT&T and Verizon to colocate high-powered virtual gaming rigs at tower sites (so literally the only constraint was the wireless data link between the phone and tower), it MIGHT not TOTALLY suck.
What, exactly, is terrible about it? The fact that it involves a half-hour instead of a whole hour? Iran and India both do it already... and I think it's safe to say that if the US & Canada did it, Britain and the EU would probably do the exact same thing within a year or two (and vice-versa).
Look at it this way... splitting the difference between standard and daylight saving time is just about the only thing at this point that's going to stop the majority of Florida from moving into year-round Atlantic Standard Time (the law was already passed, though I think it leaves the western panhandle pinned to Alabama's timezone). Once Florida gets spoiled by late sunsets all year, it's NEVER going to voluntarily rejoin the rest of the eastern US, EVEN IF the remainder eventually moves to UTC-4.5. If you think having the continental US at UTC-4.5/5.5/6.5/7.5 is "too confusing", try adding a fifth timezone ("Florida/Atlantic Standard Time") at UTC-4 into the mix as well.
Could the feds forcibly drag Florida kicking and screaming back into Eastern if it shifted it to UTC-4.5? Sure... technically... but frankly, neither party would DARE at that point to antagonize the third-largest state in the country and risk having a half hour of "stolen" after-work daylight turn into a federal election-deciding backlash from angry voters. If Florida moves to UTC-4, "Florida/Atlantic Standard Time" will be permanent as far as Florida is concerned, REGARDLESS of what the rest of the east coast ultimately decides to do.
You're assuming the "bad" product actually gets discarded. In reality, it's used to make pet food.
The single biggest thing that makes "pet food" different from "human food" is the ENORMOUS variation in formulation and taste from batch to batch. Dogs don't seem to care, but people with cats are PAINFULLY aware of it. With cats, you can't just go blindly stock up on some particular brand & flavor... you have to buy a few cans from a specific (well-stocked) store (ideally, one that keeps the cans palletized & has big stacks you can dig through), run them past your cats, note their reactions... then, when you stumble upon a can they seem to really like, RUN back to the store and buy every single can of that flavor with the same specific date/batch code. And pray to your favorite deity that you can find another acceptable batch before the current one runs out.
I first noticed the problem years ago with Fancy Feast. My cat normally liked it, but every now and then, I'd buy a 24-pack in the same flavor as always, and he'd pick away at it can after can. Then, I'd buy another 24-pack from a different store, and suddenly he'd be chowing down on it again. I finally started doing A/B testing, and discovered that I could predict with 100% certainty whether he'd like or reject the last 18 cans in a 24-pack based upon his reaction to the first 6. I have multiple cats now, and they've collectively reaffirmed my initial observation... some lots of the same nominal flavor taste better (or worse) than others.
Well, technically, it *is* "saving" daylight from the perspective of most people. Very few people are awake & take advantage of daylight at 5:30am. Nearly everyone is awake & appreciates extra daylight after work, including most of the people who ARE awake at 5:30am.
I agree. Split the difference once & for all... Eastern = UTC-4.5, Central = UTC-5.5, Mountain=UTC-6.5, Pacific=UTC-7.5, etc.
Morning traffic is naturally spread across a 3-5 hour window of time. In contrast, when DST ends, EVERYBODY (statistically) goes running for the door between 4:30 and 5:30pm, causing INSTANT gridlock that persists for hours.
It's particularly graphic in South Florida. In the summer, people without kids tend to work later, avoiding the instant 5pm gridlock that happens during the winter.
Think of it as time-domain multiplexing for freeways. If everyone on a cellular network tries to transfer a megabyte at 5pm, the network grinds to a halt and NOBODY'S data gets through. Stagger that same megabyte over a longer interval of time, and data gets through. When the sun sets early, it induces people to all hit the roads at once.
Old phones (esp. pre-2008) were "single processor" -- they used the same CPU for BOTH the radio AND running general software. That hasn't been the case for YEARS, especially since multi-core CPUs and ARM TrustZone became the norm. For all intents and purposes, the "radio" functions now run on their own virtually-isolated CPU that "regular" software (including the OS itself) can't touch.
The thing about DFS that REALLY sucks is the stupid way it ends up getting implemented... when it's time to do the DFS check, the access point just goes dark without warning for a minute, leaving everything that was connected without connectivity in the meantime.
Why can't 802.11 have an optional extension that allows the AP to tell connected clients, "hey, I'm about to go dark for a minute to do a required DFS check... in the meantime, if you really NEED continuous connectivity, temporarily switch over to 2.4GHz channel {n} at SSID="xxx" using the same credentials you used to connect to me on channel 122, and I'll let you know when it's safe to switch back"?
I mean, even the cheapest piece of shit access point that's capable of using a DFS-protected channel is almost guaranteed to have 2.4GHz 802.11n, so why not provide a way to automatically (and rapidly) fail over to it during the DFS check? Even if 2.4GHz wifi sucks, connectivity that temporarily SUCKS for a minute is still a net improvement over connectivity that DOESN'T EXIST AT ALL for a minute.
Likewise, if 802.11 had a way to communicate that upcoming DFS check to wifi-connected clients, they could try to do a better job of anticipating it. For example, if Netflix has been sustaining 6mbps buffered ahead by 5 seconds, it could attempt to crank things up to pre-buffer enough content to get you through that dry minute without glitches if it knew the disruption was coming and had time to prepare.
DFS is important, but the way it was IMPLEMENTED needlessly sucks more than it HAS to.
There are two even EASIER ways a malicious vendor could enable a computer to spy on you:
1. Make the sound chip extra-flexible, so that it's designed to be connected to three 1/8" jacks and allow any jack to be software-configurable as a mic input, a line-level output, or a headphone output. If the user connects a pair of headphones, you can then use them as a pair of low-fidelity microphones, even if they've bent over backwards to make sure to omit/disable any explicit microphone.
2. Connect the piezo transducer soldered to the motherboard (used to beep BIOS error codes) to the sound chip, with the same internal mods to allow it to work in both directions (as both a speaker AND a mic, depending upon whether the pins it's connected to are configured via software to be outputs or inputs).
Or, if the goal is to enable an agent to exfiltrate data from a computer that has its outputs nominally locked down, use the motherboard speaker (if it's wired in a way that uses directly-generated PWM to make sound instead of a transistor feedback loop with a capacitor) to generate ultrasonic audio & capture it with a second device.
The point is, physical security matters at least as much as software security does. If a malicious actor has physical control over a device, you've already lost the battle. On the other hand, attacks like this are practically impossible to pull off unless you literally HAVE the resources of a state espionage agency. While "China" most certainly falls into the category of "has the resources and expertise to do it, at least occasionally", consider for a moment that China's economy (and by extension, the CCP's ability to govern the masses) depends almost entirely upon its ability to sell and export products. Patent laws might be lax in China, but they most certainly apply to products exported to another country. If "China" copied some secret high-tech technology from Tesla or Intel (which they could almost as easily obtain just by downloading the patents from the USPTO's web site), they wouldn't be able to sell it abroad anyway, so it really wouldn't be much use to them ANYWAY. And their overseas divisions of that company would be sued into bankruptcy by the company they stole the technology from.
Corporate espionage sounds hot & sexy, and has been the theme of god knows how many Hollywood movies... but in the real world, it's pretty damn rare. Very, VERY few things are genuine "trade secrets" that aren't publicly-known ANYWAY. Not even Coca-Cola's formula is particularly "secret" -- Coca Cola's value isn't its taste, but its brand name. If you copied Coca Cola's formula verbatim (and somehow managed to source de-cocanized coca leaves), manufactured it, and sold it, the company couldn't do a damn thing to stop you... as long as neither you, nor anyone with any kind of ties to you, EVER uttered the words "Coke" or "Coca Cola". The moment they did, you'd be sued into oblivion for trademark violation. And if nobody ever DID disclose the fact that your product tastes exactly like "the Real Thing", hardly anyone would notice or buy your product... because the truth is, Coca Cola doesn't actually taste all that great (something Pepsi has been reminding people for literally decades at every possible opportunity).
Similarly, consider the annual export value of Huawei's products to China's economy. Now consider the almost piddling value of any intelligence gained using compromised Huawei products relative to the value of those exports, and just how staggeringly HUGE of a hit China's economy would take if it were caught red handed selling products designed to allow spying. China's government would, frankly, have to be completely fucking INSANE to risk that kind of direct economic damage. That's not to say China's intelligence agencies don't try at all to coax companies into including subtle features that can be repurposed and used for espionage purposes... but ultimately, it would be equally naive to think that US intelligence agencies don't have agents working for companies
It's not quite *that* easy... you STILL have to account for the very real possibility that another vehicle might LIE about its current state or intentions... possibly to try and get an advantage for its driver & allow it to save 30 seconds merging into traffic, get a better parking spot, etc... possibly to cause mayhem, death, and destruction.
Simply put, trusting untrustworthy input is dangerous. At best, you can treat it like, "Trust, but Verify".
More likely is that someday, government road departments will deploy their own sensors & make the data available (with robust security) to cars in the area. And even THEN, you have to consider the real possibility of sabotage (if only the equivalent of, "drunk teens taking a stop sign for shits & giggles).
You have to deal with scenarios where multiple signals contradict each other. Some are easy... if a database says you're approaching an intersection with a stop sign, but no stop sign is visible, the algorithm can sensibly assume there SHOULD be a stop sign & act accordingly, because the consequences of an unnecessary stop are minor compared to the consequences of an IGNORED necessary stop. Ditto, if the car sees a stop sign, but the database says nothing, or says it's a yield sign. Worst-case, the car treats it as a 'yield' & slows down enough that it COULD stop if it sees an oncoming vehicle.
That said, there's also a case to make for "conga line" logic, especially if most cars are still human-driven. If the car finds itself on a road with ambiguous/conflicting lane markers, and the car in front of it swerves, there's a solid argument that the car behind it might want to swerve, too, even if it sees no other reason to do it. Where external sensors (in other cars, on state DOT drones, etc) become useful is evaluating the logic for such behavior when detected so that a single swerving human won't turn into a 6-hour ripple (think: those times when you're in gridlock, the road suddenly opens up wide in front of you, and you're left wondering why everyone in front of you stopped. It's because some past event brought traffic to a halt, and it persists long after the original reason is gone).
Where self-driving + external coordination can help is resolving those situations gracefully. Like Howard Stern's joke about, "ok, on the count of 3, everyone stopped by mm77 on the NJ turnpike slowly begin accelerating & everyone can start moving together". With humans, it would just cause more fender-benders. But with autonomous vehicles & proper PID logic, the electronic "traffic cops" COULD carefully break up the "clots" and digitally shoo people along to break up wave effects.
Current self-driving is entirely self-contained in an attempt to bootstrap it, because it takes DECADES for road upgrades, even things like signage (there are STILL a few 1960s-era nonstandard-colored US-highway route signs scattered around Florida... the ones that show US-1 in red, US-41 in orange, US-27 in green, etc. Admittedly, it's because they aren't really hurting anything & the few remaining ones have almost become tourist attractions & photo spots, but it shows just how long legacy stuff can persist). It can take a decade or two just to plan & fund a road project, and ANOTHER 5-20 years to do it (Miami's Palmetto Expressway has been in a state of perpetual construction somewhere along its length for pretty much my entire sentient life... as soon as the late-80s round of upgrades finished after ~30 years, FDOT tore it up AGAIN to add the Lexus lanes & rebuild the I-75 interchange for the third time in 20 years (#1 grafted exit ramps to NW 138th st into it, #2 widened the deck of the ramp to northbound 75 to add a lane, #3 is underway now). Even if everyone agreed NOW about how to add electronic sensors & signaling for autonomous cars, it would take 10 years for the minor upgrades, and 25-40 years for the ones requiring major new construction to get funded & built.
Sensible compromise (albeit somewhat worthy of a Douglas Adams or Terry Pratchett novel): make Britain GMT+0:30 year-round, with the exception of the Greenwich Observatory & its parking lot, plus some symbolic (but small) radius centered upon Stonehenge, which would be GMT year-round.
A sensible combination of pragmatic compromise and symbolism.
There's nothing that says timezones HAVE to be exactly one hour apart, and several countries already have timezones that split the difference and lie on a half-hour boundary instead.
30 minutes is enough to give most of the benefit of extra daylight in the evening after work, while reducing the hardship of early-morning darkness to a couple of weeks.
Guaranteed, if the EU splits the difference for Central European time, the US will do the same thing within a year or two (and vice-versa).
Most people don't want to give up summer evening daylight, and a lot of people don't want 9am dawn, but everyone hates clock-changing. Splitting the difference between summer and winter time is a sensible compromise.
First, sniff the robot's wifi traffic using Mallory transparent MITM proxy ( https://github.com/intrepidusg... ). Note that there might be better intercepting wifi proxies available now... possibly, based upon other platforms like ESP32, ESP8266, or RasPi. I really haven't kept up with it. I just remember that at the time I did it, using Mallory with a desktop PC and PCIe wifi card seemed like the obvious choice.
The last time I used Mallory (~5 years ago), it was somewhat straightforward to set up (with slightly above-average Linux experience)... AS LONG AS you used a wifi card with a supported chipset:
* It HAS to be a PCIe wifi interface, because the host PC needs realtime access to the bare-metal wifi hardware that USB just isn't suited for.
* Not all wifi chipsets have binary Linux kernel modules available that support the features necessary to fully implement a wireless access point. I think I remember that most/all Atheros-based cards were suitable, but only a select few Realtek-based cards were... and then, with major disclaimers and caveats. This situation might have gotten better OR worse over the past 5 years. I haven't kept up with it.
* Use EXTREME caution before buying a Linksys or Netgear interface card, based upon web reviews saying that it uses some specific (and supported) Atheros chip. Both companies have a really nasty habit of using Atheros chips for their first generation of a product, racking up glowing 5-star reviews and people praising it as the greatest product the company has ever made... then quietly redesigning later versions to use cheaper, less flexible chipsets. Sometimes, without even bothering to change the UPC... occasionally, without even mentioning on the packaging that it's a later revision. You might be better off skipping the brand-name card, and just hunting on eBay for a generic card that identifies its chipset by name. Generally speaking, Linux doesn't care about the brand or model number of the card... it only cares about the chip used to implement it. In theory, two cards built around the same chip COULD be wired up differently... but 99 times out of 100, companies in China that make generic cards just take the chipset vendor's reference design and copy it verbatim.
Anyway, once you have Mallory up and running, it looks just like a wireless access point. Connect the robot to it just like you'd connect the robot to a normal access point, and have Mallory begin capturing traffic WITHOUT decrypting it.
At this point, you'll know two things:
1. The hostname it's connecting to for its web service calls, and the protocol it's using.
2. Whether or not it's encrypting its traffic. If it's encrypted, you'll basically see a CONNECT followed by garbage. If it's NOT encrypted, you'll probably see straightforward http GET or POST requests in the log.
If it's NOT encrypting the traffic at all, you're in luck. Jump ahead to step 4.
3. Enable Mallory's decryption, and restart the robot so it will attempt to connect to its home server like it did before. If you're EXTREMELY lucky, it'll decrypt the traffic without a hitch. If you're unlucky, the robot will either hang, or give an error that's ultimately caused by an invalid TLS certificate.
If the Robot's software was written properly, it won't make it past this point, and you'll basically be out of luck absent some as-yet undiscovered exploit. HOWEVER, it's quite possible that it MIGHT just ignore the certificate error. There's literally a metric shit-ton of bad example code on StackOverflow and elsewhere that gives the impression that it's OK for apps to just ignore certificate errors, and I'd say that in the real world, probably 60-80% of "secure" devices that "use https" will completely IGNORE certificate errors. Why? Certificates are a royal pain in the ass to deal with during development, because the debugging needs of developers are more or less perpendicular to the demands made by robust security. More often tha
If you wouldn't mind, can you read the MID codes from those discs & post them here? (You can use a tool like CDspeed to read the MID code -- http://www.cdspeed2000.com/ ).
Ultimately, the MID code is the final authority on whether or not a disc is HTL or LTH, because it's how the drive determines its writing strategy.
My guess is that the manufacturer of the discs you bought just decided that it didn't even HAVE to identify its discs as "LTH" on the packaging anymore, and didn't.
I suppose it's not inconceivable that things might have changed... but absent a low-key industry-wide move to abandon LTH and return to HTL, I think it's MORE likely that the manufacturers just found a loophole that allowed them to stop disclosing on the packaging that a given pack of discs are LTH.
My own personal Amazon experience the last time I bought non-LTH discs ~2 years ago was that nearly all of the discs listed there said nothing whatsoever in the listing about whether the discs were HTL or LTH, and NONE of the non-Verbatim discs were HTL when I looked up the UPC or SKU number online.
There are two kinds of BD-R (recordable blu-ray) discs.
The first ones that came out had a shiny metallic layer that permanently dulled when the laser burned it. The technology was used precisely because everyone knew by that point that recordable discs based upon organic dyes had a TERRIBLE track record for long-term stability. By the time development of BD-R discs began, nearly ALL 10+ year old CD-R discs had at least some unreadable sectors, and DVD+R and DVD-R had an even WORSE track record. The catch was, the first-generation BD-R discs required a totally new manufacturing process and tooling, so only a few large companies (like Mitsubishi/Verbatim) made them... and they were pretty expensive, especially compared to DVD+/-R discs.
A few years later, the industry decided that Azo-based organic dyes WERE good enough for the unwashed masses, even while simultaneously conceding that their long term stability was unquestionably likely to be inferior to the original BD-R discs. Basically, their argument was, "yeah, Azo-dye BD-R discs will start becoming unreadable after 5-10 years... big deal, most people don't need archival-quality discs with hundred-year lifespans, and anyone who does can still use the more expensive original kind." At that point, companies like CMR (legendary for making low-quality discs) jumped on the bandwagon, and started cranking out LTH BD-R discs by the millions.
The really SHITTY decision the industry made was NOT giving a unique, unambiguous name to the original non-LTH type BD-R discs. Officially, they might be referred to as "HTL" (high to low)... but you will NEVER see "HTL" as an advertised feature, nor is there any unambiguous logo, certification, or anything else that allows you to unambiguously determine that a given pack of discs is HTL type, and not LTH. All "LTH" discs will specify it somewhere on the packaging... but they won't necessarily go out of their way to make it obvious, and they'll often try to word it as though it's a selling point instead of a disclaimer.
Broadly speaking, the cheapest non-LTH discs are usually going to be at least twice as expensive as the most expensive LTH discs. Of course, you might always get lucky and trip over a liquidation sale or something, but most of the time, you can just ignore the cheapest discs entirely and take for granted that they're going to be LTH.
Likewise, store-brand and non-major brand discs are almost ALWAYS going to be LTH. Ditto, for pretty much any discs purchased at a big-box retail store like Best Buy or Walmart. For all intents and purposes, you're going to have to buy non-LTH discs online.
Take Amazon reviews and listings with a pound of salt. Amazon is NOTORIOUSLY sloppy with its "SKU-keeping". If a listing doesn't EXPLICITLY identify a specific model number or UPC, you should probably assume the worst. Likewise, if the listing says the discs are non-LTH, but it's merely "fulfilled by Amazon", double check the SKU or UPC listed in the ad. Amazon is known for being really sloppy about commingling things they view as "commodity items. By the same token, if the listing unambiguously identifies a SKU/UPC for a product you've confirmed is non-LTH, but there's one or more reviews that say it's LTH, that could mean EITHER that Amazon was sloppy and sent someone a pack of LTH discs despite the ad saying they were non-LTH, or Amazon's powers that be might have just gotten sloppy and lumped reviews for BOTH LTH and non-LTH discs together. Amazon really sucks about doing that. Either way, if you DO buy the discs from Amazon, my advice is to 1) MAKE SURE there's something in the listing that UNAMBIGUOUSLY indicates that the discs are non-LTH (preferably, a SKU or UPC that you've independently verified via the manufacturer's web site), 2) check the discs when they arrive, and don't be shy about demanding a refund if they end up being LTH after all.
Newegg is a little better. At least, as long as you stick to items that are literally sold by Newegg itself (the last time I checked, they
In a sense, it IS kind of like having a house with rooms piled floor to ceiling.
Consider for a moment the data on a 250GB USB1.1 hard drive frome sometime around 2006. Ignoring for a moment the increasing annual possibility of drive failure due to age, imagine trying to look for a file on that drive. At USB 1.1 speeds, the disc is for all intents and purposes locked away and unusable (at least, from the perspective of Windows Explorer or Gnome 3's file manager, especially if the computer has antivirus software running that decides to try scanning the entire drive before it'll allow you to do anything with it). Connect the drive to a computer running a minimalist Linux distro and use Bash to copy the files to a newer, faster hard drive, and it's probably going to take DAYS for the copy to complete. Even if you rip the drive out of its enclosure and connect it to an IDE-to-SATA-to-USB3 adapter, it's going to take at least half the day to finish, just because even pre-SATA IDE was shockingly slow compared to SATA2 or SATA3.
There's also the fact that hard drives are AWFUL for long-term storage. They can literally suffer mechanical failure after years of non-use... and if it happens, cheap recovery options are basically nonexistent. They start at 'ungodly expensive' and increase exponentially from there.
Non-LTH single-layer BD-R media is just about the best long-term storage medium available today (cheaper LTH media is no better than organic-dye DVD+/-R... it fades and has a predicted half-life of around 3-10 years before accumulating enough errors to prevent reading as a normal filesystem, and 10-20 years before accumulating enough errors for even forensic recovery to encounter nonrecoverable errors in at least a few files). But BD-R media is pretty slow to read compared to just about everything besides tape. So, once your BD-R collection grows beyond a certain point, you'd BETTER have some good way to at LEAST keep a copy of the file metadata indexed and on something like a hard drive or SSD, or you're going to be in a world of pain trying to someday even figure out what files you HAVE, let alone the contents of any file.
That said, if you had to pick a single media type for "throw in a box and forget about it until far in the future", Non-LTH BD-R is absolutely your best choice. Even if optical drives cease to be a common cheap CONSUMER item, they're all but GUARANTEED to exist in some form for bulk archival storage & commonly used by libraries, universities, enterprises, etc. Just be aware that getting a mountain of BD-R discs containing 40TB of data into a form that can be searched and browsed in any kind of interactive manner will probably itself require several weeks of effort.
Note: avoid the temptation to use multi-layer discs. Multi-layer discs have a lot more that can go wrong (and can manifest unrecoverable read errors for deeper layers long before a single-layer disc of comparable age would have encountered problems). Also, when you're storing data for the long haul, be aware of your goals. Requiring that the disc be directly-readable as a normal mounted filesystem without special handling is a MUCH more difficult goal than simply requiring that data be confidently readable by forensic means. A BD-R that Windows 2030 someday chokes on and rejects as 'unreadable' when you stick it in (because the malware analyzer choked on an unrecoverable read error) might nevertheless be readable just fine if you rip the raw bitstream from the disc using Ubuntu 42.06 and use a utility to reconstruct a corrupted UDF filesystem. And if you actually know what precisely you're looking for and approximately where to find it, your likelihood of getting it off the disc is likely to be high for decades, maybe centuries.
Someday, digital archaeologists are going to make careers out of using robotic disc-rippers and AI content-analysis to sift through exabytes of old data from the 21st century, searching for treasures like an old cat video from Youtube that HASN'T already been viewed 400 trillion times, or a fifth-grade book report from someone who later went on to become the 84th president of the United States.
My main complaint with folding Thunderbolt into USB is the fact that it opens the door for asshole manufacturers like Apple to turn around and make laptops with a single fucking USB port, then expect consumers to go out and buy an ungodly expensive hub to unwrap everything.
In the beginning, there was DisplayPort. Using it with multiple displays required an expensive hub, but you could also use it with a cheap passive adapter cable to connect a single HDMI display. And it was good.
Then came Thunderbolt. Thunderbolt was multiplexed into DisplayPort. In theory, using the port for BOTH Thunderbolt AND DisplayPort required a UNGODLY expensive hub, but in reality, the only thing anyone cared about connecting via Thunderbolt was an external video card that had a DisplayPort or multiple HDMI ports of its own, so you could skip the expensive hub since you were still only connecting a single device to the computer itself using the computer's single DisplayPort port. And it was still good.
Then someone got the idea of multiplexing DisplayPort into USB. At first, it seemed like an OK idea... you could still use a cheap adapter cable to connect a single Thunderbolt eGPU to one of the ports, and use a $15 USB hub to connect things to the remaining USB port(s). After some nervous concern, it was still good.
Then Apple decided to Boldly Innovate, and sell laptops with a single USB port that needs a $500 hub if you want to use BOTH Thunderbolt (or DisplayPort) AND USB peripherals, and other manufacturers quickly followed just because they all blindly follow every stupid trend Apple comes up with. And it really, totally, fucking SUCKED.
Condensing everything -- PCIe, video, and USB -- into a single port that needs an expensive hub is OK when you're talking about a device like a phone that has extremely limited space for external expansion ports AND where using external peripherals is itself an extreme, rare edge case... but doing it with something like a LAPTOP where there's MORE than enough room for a half dozen ports, and would add only a few cents to the manufacturing cost, is just plan mean and user-hostile.
Yeah, combo hubs will probably be cheap SOMEDAY... but in the meantime, we're looking at 3-5 years of needing hubs that cost more than the peripherals connected to them. DisplayPort got away with needing an expensive hub, because most people didn't actually NEED that expensive hub to use it for the most common use case (connecting a single monitor). That's absolutely NOT the case with USB... especially if the manufacturer decides to pull an 'Apple' and ALSO use that single USB port for power delivery as well.
> so the average state is 2% of the population of the US
And it's a perfect illustration of why "average" is such a misleading figure.
* Approximately 12% of Americans live in California... more Americans than live in the 20 states with the smallest populations.
* More than 25% of Americans call California, Texas, or Florida home.
* More than half of Americans live in just 9 states: California, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, and North Carolina.
or... making it even more graphic...
There are more people whose hometown can be loosely described as "New York" or "Los Angeles" than the sum total populations of 35 entire states.
Oh, please. An average "smart" TV is dumber than a 4 year old Roku. An average gaming mouse probably has more onboard flash than an average "smart" TV.
Cryptocoin mining? Give me a break. The "smart" TVs I've seen huff and puff just trying to display a fsck'ing MENU on the screen. Their ability to decode h.264 on the fly is an illusion... it's all done by limited-purpose hardware, stapled together by a "computer" that's about as powerful as a SNES.
Serving child porn? Via some mystical 5G free data that was forced on you by the TV manufacturer? Don't make me laugh. The only thing 5G is going to bring America is higher average monthly phone bills. Even IF (big IF) future "smart" TVs include "free" 5G data service for some purpose, you can bet your ASS it's only going to be "free" to use for accessing the services of specific partner companies. The only way any "smart" TV is EVER going to be capable of using "5G" to stream ANYTHING outbound from your house is if you've intentionally paid for that service. So no, I'm not about to lose the slightest bit of sleep worrying that hackers are going to use my future TV to stream child porn over 5G data I can't disable, because I'm not going to PAY for 5G data service for my TV above and beyond what I'll already be paying for fiber, and I probably won't BOTHER with the TV's "smart" functionality anyway, because it'll be too stupid and crippled compared to all the discrete devices I'll have available to use instead.
And in any case, if my TV gets hacked and is somehow being used to stream child porn, it'll be one of approximately 20-30 million compromised TVs doing exactly the same thing at that point. Paraphrasing Stalin a bit, "one person serving child porn is an evil pervert... 20 million people inadvertently serving child porn via hacked smart TVs is a statistic".
Camera? Meet electrical tape. And worry MORE about the half-dozen OTHER cameras strewn around the house, most of which will have less real security than the TV ultimately does.
Mic? The battle is already lost. If you have fewer than four dozen internet-connected microphones within 100 feet of the TV at that point, you'll probably be lucky. If someone really wants to eavesdrop on you, they won't HAVE to hack YOUR devices... they'll be able to hack your neighbors' devices and use them as directional listening devices against you anyway.
Look at it this way. If you're in a group with 10 people getting chased by a hungry bear, you don't have to be able to out-run the bear, you just need to outrun the slowest member or two of the group and be a less-appealing target so the bear will capture and eat THEM instead of you. Your future smart TV will be one device out of literally trillions of minimally-secure devices spread around the world. Use it as a dumb monitor with your own discrete media devices, and it's unlikely to be one of your biggest likely future security problems.
If Tesla were smart, they'd cut a deal with someone like Hertz or Avis, so that if you wanted to test-drive a Tesla, you could go rent one for a week (at some non-free price that would be considered a fair price if you were just renting it to drive for a week while traveling), then apply the price of up to 4 rental weeks from the past year to the purchase price of a Tesla if you decided to buy one.
IMHO, that would kill two birds with one stone... it would avoid the problems of dealing with returned cars from people who changed their minds (since the same cars would be rented over and over), while simultaneously drawing in potential buyers who might decide to rent a Tesla for a week while on vacation & decide that they absolutely LOVED it. It also minimizes the impact of regional availability... a family from a small town in North Dakota or Montana could rent a Tesla while vacationing in Orlando, Miami, or Las Vegas for a week just as easily as a family from Seattle or Atlanta. It also minimizes the risk to the people trying one out... if even a "normal" rental car in Miami is going to cost $200 for the week, and you can get a Tesla for $50-100 more, lots of people who might not have gone out of their way just to rent a Tesla in their hometown might say "fuck it, I'm on vacation, gimme the Tesla!"
Honestly, I think their BIGGEST problem would be supplying with the rental car company with enough cars to satisfy the demand. They probably WOULD have to start off for the first year or two by limiting it to just a couple of very popular vacation markets... say...
year 1: Orlando and Las Vegas
year 2: Miami, Washington DC, Los Angeles, Chicago
year 3: every remaining international airport in Florida, plus every city that currently HAS a Tesla showroom. I'd expect that over time, places like South Florida would probably have Tesla-equipped Avis/Hertz locations at BOTH the airport AND some off-airport suburban locations that seriously blurred the line between "rental car office" and "de-facto Tesla showroom".
Their biggest problem would be convincing Hertz or Avis to keep the cars in circulation for 2-3 years instead of replacing them all annually (since otherwise, Tesla would be struggling just to keep the rental car company fully supplied, let alone anyone else).
> What possible security or control do you hope to gain from it having an hdmi port?
Er.... being able to completely ignore the remainder of the TV's alleged capabilities, and use it as a dumb video display to watch content using devices that ARE under my own control? With a means of directly feeding video into my TV and using it directly as a dumb video display, everything else becomes largely moot.
> your TV will be online.
Big. Fscking. Deal. If it's not on my home network, and I'm using it as a dumb video display, the TV can ping a 5G carrier forever (at the TV-vendor's expense) for all I care.
I mean, seriously. There's "security-aware", then there's "tinfoil-hat-paranoia". What do you seriously think someone like Samsung or Toshiba is going to do, secretly send screen-captures of your HDMI-fed content back to their servers just so they can find nefarious ways to violate your privacy? It would be legal suicide, if only because it would only be a matter of time until some copyright holder sued the TV manufacturer for infringement (since those screenshots technically wouldn't have been authorized by the copyright holder).
Worst-case, your 7 year old smart TV someday connects to a 5G network without your permission, gets bricked by hackers exploiting an old vulnerability, and you join the class-action lawsuit against the manufacturer and end up getting a free new TV out of the deal. Vendors can make all the noise they like about disclaimers, warranties, and EULAs... if a company big enough to make smart TVs gets caught with its pants down like that, they WILL take a legal beating in at least one jurisdiction somewhere in the world.
> in a very short time they will come with a 5G radio that you dont control
And, what? You think they won't have a HDMI port? Jesus, even the worst bargain-priced Black Friday piece of shit in electronics history came with a HDMI port, composite+stereo, and an antenna input. Most have multiple HDMI, a component port or two, at least one s-video plus multiple composite & stereo inputs, Toslink and/or S/PDIF input (and usually, one for output, see note).
Many even have a useless VGA port ("useless", because the mfr. limits it to 1024x768, and explicitly disallows 16:9 640/704/720 x 480/576, or any other mode that might be useful for media... but handle even 1920x1080@50/59.94/60 just fine if your laptop has a video chip that can output component video using vga-port pins & you have the right octopus cable).
One MAJOR reason why mfrs (in the US, at least) love "smart" TVs: they can sell a TV with the hardware to receive OTA broadcast atsc, but only pay royalties for users who actually "activate" the capability online. The royalties aren't cheap ($10-20/set, I think), and they're required by law to include a tuner on any device marketed as a "TV" (vs "computer monitor"), but most people don't actually USE the tuner (and many who WOULD just give up when presented with an 'online activation' step), so it's an easy way for the mfr. to save millions of dollars in royalties.
---
note: 99.999% of TVs made after 2006 that have toslink or spdif out will only use it to output PCM 2.0 stereo for content extracted from HDMI. OTA is hit or miss... AFAIK, they're ALLOWED to output DD5.1 via toslink/spdif for OTA content, and can pass through DD5.1 FROM toslink/spdif, but many just blindly downconvert EVERYTHING to 2.0 stereo.
What, exactly, does "blockchain" have to offer with regards to "proof of authorship" that conventional PKI and digital notarization doesn't already address perfectly well?
Seriously. If you're trying to establish ownership of something in court, the only opinion that matters is the legal system's. If one side's case is based upon the word of a government-recognized notary, backed up by PKI provided by Verisign in compliance with the required ISO certifications... and the other side's case is based upon the word of some crowdsourced blockchain... the side with the notary and Verisign behind them is going to win, every single time. Even if blockchain ultimately gained equal recognition by the government, Verisign is still going to either outgun it... or own it as a subsidiary, rendering the distinction moot anyway.
The big problem with 10gbps is that it's too fast to handle with more than a few feet of copper, and fiber is a BITCH to terminate.
The other problem with 10gbps is that it's simultaneously too fast AND too slow.
From the perspective of a single endpoint device (like a computer), 10gbps is absurdly fast for Ethernet... but the two things you might actually WANT to wrap up and transmit over Ethernet -- HDMI and multi-lane PCI Express data -- blow past 10gbps and keep going without looking back.
So... as a transport medium for connecting switches with gigabit ports, a 10gbps backbone is a nice, sensible speed. But for the few things that genuinely outstrip the capabilities of gigabit Ethernet, 10gbps is ALREADY obsolete and inadequate.
Think of it this way: suppose that circa 2008, you had an old laptop with 128mb of PC100 RAM that could be expanded to a gigabyte of PC100 RAM at staggering cost(*)... except by that point, Windows could barely boot without thrashing itself to death with anything less than 2 gigabytes, so spending ANYTHING to expand its RAM at all would be largely pointless because even the most expensive expansion possible would still be inadequate to solve the problem that motivated its expansion in the first place.
(*) For those who remember, high-capacity PC100 RAM was a weird era in PC history... lots of computers could ONLY use it, and not PC133... but by the time the chips to make 256mb modules had become semi-affordable, the market for those modules had largely dried up, so we had a period when smaller sizes were basically worthless... but 256mb PC100 modules pulled from a scrapped computer sold for more on eBay than brand new DDR(2/3) modules with 1-4 gigabytes at Best Buy.