"thousands of miles across a desert" is kind of an exaggeration. The Great Pyramid is about 4 miles from downtown Cairo, itself adjacent to the Nile. Modern-day Cairo literally sprawls to the base of the pyramids. Back in ancient times, you could have probably seen the pyramids from just about anywhere along the Nile within 10-20 miles of Giza.
This 360-degree photo vividly illustrates just how close the pyramids are to Cairo:
On one hand, the pyramids were an extravagant waste of money if you consider only their official intended purpose. On the other hand, considering how much money they generate for Egypt's tourist industry year after year, they were arguably one of the most robustly-profitable long-term capital investments in the history of human civilization.
Part of the problem is that these services have too much blind faith in their ability to make predictions based upon incomplete knowledge. They REALLY need to come up with a way for users who end up pigeonholed and seeing endless recommendations for content to indicate, "Alright, enough already! I read a goddamn article about something while I was bored & taking a dump. Go back to recommending the kind of stuff I'm NORMALLY interested in."
It's like the way TiVo used to be. A few years ago, my brother's family came down for a weekend. I recorded two episodes of a show for my niece & nephew. For the next 3 months, my Tivo was absolutely HELLBENT on endlessly recommending shows on Disney & Nickelodeon, despite the fact that I had about 40 open-ended scheduled recordings for shows that were about as close to being polar opposites of Disney & Nickelodeon kids' shows as you can get. It's like their algorithm said, "Oh, JOY!!!! Someone who now has small kids!!!! Now they're ensnared in the parent-industrial complex forever!!!"
Because Google has decisively and intentionally made its services into infrastructure with a direct, demonstrable impact upon interstate commerce. Pretty much every single Supreme Court decision over the pasty century has reinforced and reaffirmed the right of Congress to regulate anything that significantly affects interstate commerce, including actions that themselves only involve actions taking place entirely within a single state (and only indirectly affect interstate commerce).
Here's an illustrative example. Suppose a city allows a private company to build toll roads through its present-day hinterlands, and agrees to exclusivity agreements that prohibit the city from building (or allowing others to build) any infrastructure that might "compete" with that company's toll roads for the next 100 years (with "compete" being interpreted as anything that might be an alternative to the road, including rail lines, bike paths, helicopter landing pads, or even dirt paths not blocked by fences and "no trespassing" signs). Fast forward 50 years. Land that used to be desolate swamp or desert has become the metro area's second (and maybe third or fourth) central business district. Most of the metro area's best job opportunities and residential areas are now there as well.
One day, out of the blue, the company that owns the toll roads decides that certain individuals are no longer allowed to travel on its roads... even as passengers in vehicles driven by others... and deploys a network of private investigators and security guards to make sure that buses and taxis aren't carrying banned individuals as passengers (knowingly OR unknowingly). The company feels no need to explain why, and asserts both its right to exercise unlimited discretion in whom it accepts as customers (direct or indirect) and disavows any need to justify it.
That policy would almost INSTANTLY be swatted down by legal challenges, on so many possible legal grounds it's hard to even know where to start.
Yes, we had a similar debacle with the "No-Fly List"... but at least the No-Fly List was ultimately subject to constitutional safeguards. It was a hot clusterfuck of an unholy mess... but at least anyone who ended up on the list could feel confident that their case would EVENTUALLY be reviewed by real people who actually CARED about facts and evidence... which is more than you can say for anyone who's ended up on the receiving end of Google's automated wrath.
Putting it more starkly, suppose you were one day cornered by an evil, sadistic being with deity-like powers who told you, "I've decided to ruin your life as much as possible... but I don't want to be thought of as COMPLETELY evil, so I'll let you pick between two alternatives:"
1. You get put on the 'no-fly' list for a reason that will be readily apparent as an error the moment someone officially reviews your case.
2. Lifetime banishment from all services provided by Google (including indirectly, as the user of a service that itself depends upon Google services), with no right to review by a human... or any right to review and due process AT ALL.
As bad as #1 would be, I think just about everyone would agree that #2 would be ENORMOUSLY worse in the long run (and, on strictly narrow constitutional grounds, would severely harm your present and future ability to engage in interstate commerce... and in aggregate with others similarly affected, would have a significant effect upon interstate commerce overall).
Google doesn't have to be micromanaged by the government... but if it wants to be an inescapable provider of business infrastructure that's inextricably woven into the very fabric of America's economy, it needs to start ACTING like it, and respect the safeguards that have traditionally made America a safe place to do business. Google is presently engaged in arbitrary acts of economic violence that will ultimately harm our economy if allowed to continue unchecked.
Pfft. 20 years ago, I went on a multi-week holy quest to try and find a way to make Enlightenment work with networked X11 and a headless Linux box. It was an act of hopeless futility (Enlightenment needed capabilities that X11 can't provide over a network, and I later discovered that for various unintuitive reasons, networked X11 usually has worse performance than VNC).
BTW, for anybody who's wondering, networked X11 is NOT the Linux equivalent of RDP with Windows. It's roughly ANALOGOUS to it, but they're products of different eras. Networked X11 hasn't aged gracefully AT ALL, and BOTH RDP and the entire architecture of Windows display drivers evolved hand in hand to support each other.
Sadly, there really is no RDP-equivalent on the horizon for Linux. VNC sucks, but it's perceived as "good enough" because there's nobody willing to finance & shepherd 10 calendar years of development into Linux video architecture to come up with a new standard that's simultaneously high-performance, networkable, and yet capable of being used in stripped-down form on lesser hardware. Both X.org and Wayland have struggled to fully replace legacy X11, and Wayland's developers EXPLICITLY decided ~5 years ago that RDP-like networkability was off the table, and not even an 'aspirational' long-term goal, while X.org decided to settle for maintaining legacy compatibility with some minor tweaks to improve security.
The fundamental problem is that Google has increasingly put indie developers in impossible positions by changing the rules, deciding to retroactively apply them to apps that were published via Google Play literally YEARS ago under different rules, then swooping down and suspending them without warning, and perma-banning any developer who gets "too many" apps suspended. And perma-banning (for life) the accounts of anyone whom their AI determines is somehow "linked" to the account that was banned for having old apps that were retroactively determined to be in violation of rules that didn't even exist at the time they were published.
It's as if Google sat down, read about China's "social credit score" (which dings individuals merely for "associating" with anyone whose social credit score is low), then enthusiastically decided to roll it out as the new model for all Google services. There are people who've invested literally YEARS of their careers in Android development who've not only had their portfolios and/or ad revenue cut off without warning, they've been rendered UNEMPLOYABLE as Android developers because any company that hires them would risk getting "linked" to them by association and punished as well. If you're American, you're at risk. If you're from a country like Canada, Britain, France, or Germany, you're at slightly greater risk. If you're from India or eastern Europe, Google will ban you on the slightest whiff of suspicion without a second thought. All with no meaningful route to clear your reputation (or even find out what exactly they think you did that was horrible enough to justify destroying your career), and officially... for the rest of your life.
Yes, Google really HAS become that completely evil and bad. Frankly, I'm shocked it hasn't been the plot of at least a few Hollywood movies yet.
I haven't personally gotten banned, but the extreme danger faced by anyone who develops Android apps and depends upon any Google service has forced me to step back from Android and intentionally minimize my future exposure to Google's potential wrath. Google has now taken it upon themselves to be judge, jury, and economic executioner... based upon algorithms with confirmed, known false positives and literally ZERO accountability or pretense of due process.
For a developer, the implications of getting banned for life by Google goes WAY beyond merely being unable to publish apps via Google Play. Getting banned ALSO locks you out of the entire Google Play ecosystem, so you can't use Play Location Services or Google Maps API for apps published independently of Google Play, either. It can result in the loss of access to every Android app you've ever purchased through Google Play, and could get you permanently locked out of any third-party web site that uses Google's authentication services.
And once again, people have gotten such bans not for publishing malware, but merely for having ever published an app that was completely acceptable to Google at the time it was published, but later failed to comply with Google's changed requirements. Most outrageously of all, Google won't even settle for allowing you to preemptively unpublish your now-noncompliant app, because even unpublished apps remain accessible to people who've purchased them in the past. There are documented cases of developers who've unpublished a now-noncompliant app from Play, then ended up getting that now-unpublished app suspended at some later time ANYWAY (possibly triggering a lifetime ban of the developer's own account).
Google has NEVER been known for particularly caring about anyone who falls victim to its policies as collateral damage... but this is seriously the kind of thing that's going to end up putting Google on the receiving end of a class-action lawsuit that would probably end up getting appealed all the way to the US Supreme Court (basically, asking the court to decide whether a company that intentionally injects itself into so many cross-cutting aspects of interstate commerce ought to be held to a higher
Ok, so limit the subsidized portion to the nearest paved road or existing utility pole on public right of way, whichever is closer. That would eliminate the most expensive 1% or so that would likely account for 40-50% of the subsidy costs.
Even now, I'd guess that at least 80-95% of remote small towns with 50-100 residents now have existing fiber within 10 miles, probably less. Towns don't crop up in random locations... they develop around transportation routes. If you factor out the least-populous 1% of American settlements, the remainder pretty much ALL fall along visually obvious lines. Even in places like rural Nebraska... you have a widely-spaced grid of roads with family farms that are uniformly narrow along a public road & really deep. In Alaska, just about any settlement with electricity falls along a public road connecting lots of similar settlements. The truly isolated & outrageously expensive to serve ones (without commercial electricity) wouldn't qualify under my standard, anyway.
A major limit TODAY isn't the cost of getting fiber to the nearest public road, it's the cost of running fiber down a quarter-mile driveway. The feds could allow those people to finance its construction at 0% interest and 25-year payback schedule, tied to the land as a lien if it goes unpaid.
We don't demand 100% geographic availability for electricity or landline telephone... some areas ARE genuinely too remote and expensive to serve. But getting to 80-90% is cheap, and getting to 99% (up to the point where the paved public ROW ends) is fairly cheap considering fiber is a 100+ year infrastructure investment.
Suppose I write an Android app that uses Google Maps & requires an API key. I dutifully follow Google's instructions, build my app with the key in Strings.xml, compile it, sign it, and publish it to Google Play.
What, exactly, is there to stop someone from obtaining my app through Google Play, ripping it from their phone, deodexing the binary, extracting my API key, then writing THEIR OWN Maps-using app that uses my API key and distributing it to a million users in China (or anywhere else in the world) so the API calls of ITS users end up getting charged against MY account?
I mean, I certainly hope that Google at least does binary-analysis and would reject an app uploaded to Play that attempted to re-use MY API key... but that still does nothing to address API key security in apps NOT distributed via Google Play.
Likewise, Google could theoretically do some form of sanity-checking, and pass along BOTH my API key AND an ID tied to that specific user via Google Play Services, and reject the key's use if the user had never actually installed my app... but that wouldn't help with something like Amazon API keys.
I could see it being secure if API keys offloaded responsibility for registration and payment directly to end users, so that apps would be distributed with dummy keys that were replaced by "real" ones after end users directly authenticated THEMSELVES to Google Maps, Amazon AWS, etc., and used MY app with THEIR key at THEIR OWN expense... but I just don't see how the current way API keys are used with things like Android apps is in any way even REMOTELY secure against key-hijacking.
This is a MAJOR reason why I've always been afraid to publish any Android app that depends upon having an AWS key. At least Google will allow you to distribute a Maps-API-using app with a key that simply gets disabled if you go over the free limit. Amazon won't. They'll give you a certain free allowance, and it might even be fairly high... but Amazon WILL NOT give you the courtesy of setting any kind of absolute circuit breaker and tell them, "if my app exceeds {free-allowance | some-absolute-limit}, just kill it dead and stop any additional charges from accruing". Even worse, Amazon's billing isn't realtime... you can set up all the safeguards you want to notify you if your usage exceeds some amount and kill your account, and even to try and kill it via scripted means... then see the amount you own CONTINUE to skyrocket AFTER you've pulled the plug due to use that happened before you suspended the service, but AFTER the most recent balance update.
Frankly, Amazon's AWS billing policies (above and beyond any concerns about the security of distributing an app with my API key compiled into it) scare me shitless, and apparently I'm far from being the only one who feels that way. I, for one, will NEVER willingly give someone a literal blank check to bill me into bankruptcy.
* Americans with college degrees? Bzzzt. Under NAFTA, any American or Canadian with a college degree can go work in the other country, as long as they aren't barred from entry for some other reason.
* Americans without a college degree? Unlikely. From what I've heard, it's damn near IMPOSSIBLE for an American without a college degree to officially get permission to move to Canada and work (and vice-versa). There are a few edge cases, mostly in the entertainment industry, but not many.
* non-Americans who came to America as H1-B and went to Canada as the equivalent of H1-B after losing their job in the US? I suppose it's not impossible, but I believe someone who moved to the US under H1-B, lost their job, quickly applied for a job in Canada, and managed to get hired & moved there before the US officially kicked them out would STILL have to make a final documented trip from the US back to their own country before flying to Canada to begin their official employment there, which would instantly nuke a few thousand dollars right off the top.
Personally, I think there are already too many stupid barriers between the US and Canada. It's not like there are masses of impoverished Americans or Canadians huddled along the border desperately yearning to flee in EITHER direction. If an American wants to move to Canada, or a Canadian wants to move to the US, fine. Let them. Any cost borne by either country (and the respective states or provinces) would probably be piddling compared to the cost of enforcing laws that literally EVERYONE thinks are patently absurd.
Hell, I'd go so far as to extend the deal to just about ANY country with an economy that's basically equivalent to that of the US, with approximately the same number of people who want to move in both directions. Just to pick another comparable English-speaking country as an example, let's say the UK. The fact is, relocating across the Atlantic is incredibly expensive, and it's not like someone who's indigent in either country could possibly afford to just casually move to the other, EVEN IF the border and immigration formalities were minimal and frictionless.
If US citizens and British citizens could freely move in both directions, I'd guess that the absolute number moving in both directions would be approximately equal, and that the overwhelming majority of people doing the moving would either be recent college grads who think living in the other country would be cool, or people who ended up in a relationship with someone from the other country & decided to move to the same city as a sensible next step. For the first year or two, there might be an influx of British construction workers naive enough to think they could spend the winter working in Florida... until word got out that half the construction workers in the northern US have the exact same idea at some point in their lives, and the amount they could earn working in Florida during the winter is so insultingly low compared to what they'd make in London, they'd come out ahead financially if they just literally spent the winter collecting British unemployment benefits instead of bothering to try working in a state with third-world wages and first-world cost of living.
Update... just did some more research about 802.11ad. According to what I've read,
* 60GHz can't penetrate anything (including fleshy lifeforms), but absolutely DOES reflect from most surfaces. Its max distance is approximately 100 feet, measured along the signal's path (including any reflections necessary to reach the receiving antenna).
* In an area like an enclosed conference room that's approximately 12x20 feet, with the AP itself located in a spot that's sane (ie, not inside a cabinet or deliberately hidden behind/below something), but not otherwise chosen with any particular care, you can realistically expect 1gbps in 99% of the room, 2gbps in 90-95% of the room, and 4gbps in 60-80% of the room.
* It appears that the real-world performance difference between two single-antenna 802.11ad network adapters directly communicating as peers is PROFOUNDLY worse than the performance you'd get with a proper access point operating in 'infrastructure' mode with beamforming, hanging from the ceiling near the center of the room. In the former case, bodily obstruction could make a HUGE difference, because the alternate paths might exceed more than 100 feet after factoring in multiple reflections... multiplied by all that potential multipath interference. In the latter case, the AP would constantly be probing around to find the ideal beam direction that maximizes signal strength and minimizes multipath interference... simultaneously increasing signal quality and minimizing echo-like background noise.
* Supposedly, 802.11ad has extraordinarily low latency compared to 802.11ac and older standards... like, 10 microseconds. Apparently, it's low enough to use as the transport layer for PCI Express as long as the transmission conditions are basically ideal (like, a wireless laptop dock that's nevertheless within a foot or two of the laptop, with clear line of sight between the antennas).
So... it looks like that with a proper access point in an intelligently-chosen location and a halfway-reasonable attempt to keep the client's antenna in a reasonably visible location, you could feel absolutely confident of sustaining 1gbps just about everywhere within 10-20 feet of the AP, 2gbps nearly all the time, and 4gbps most of the time. Of course, this all assumes that the Quest has a viable interface to the outside world, and that its USB port (for example) would not itself be the primary bottleneck.
---
Side thought... I'll be absolutely SHOCKED if a future teardown of the Quest doesn't reveal the presence of at least a few "test" pads on the circuit board that expose the signals needed to connect Qualcomm's 802.11ad chip and/or implement Rift-like HDMI connectivity, EVEN IF Oculus has literally no intention of ever officially supporting their use by end users. The fact is, it's a lot cheaper to have one of their engineers grab a production Quest and hack it into an experimental prototype than to go through the effort and expense of building one-off prototype headsets for internal use from scratch. Chances are, the Quest prototypes that were being made a few months before it went to manufacturing (and before the official specs were finalized) had circuit boards that implemented "everything" (802.11ad via Qualcomm's extra chip, a HDMI-like video link, etc), then later prototypes simply omitted the components to implement the unnecessary functionality. Even if they subsequently pruned away the component footprints, they almost certainly would have left the pads, just in case someone down the road at Oculus needed some in-house prototypes that re-implemented the desired functionality.
The main issue with 802.11ay is that 802.11ad exists today at a cost that's within the realm of 'sane', even though it's still pretty niche. 802.11ay, not so much. Not everything involving 802.11 turns to gold. Just look at 802.11y (basically, 802.11n with tweaks & extensions to operate in the lightly-licensed 3.6ghz band).
Back when AT&T still had a 1gb monthly data cap, I would have totally bought a home 802.11y access point & license, and a pocket-sized access point that used 802.11y for the backhaul & 802.11n for connections from my phone, because it would have enabled me to have free ~256kbps(ish) data within ~10km of my house for approximately what a year of monthly overage fees from AT&T (if I'd used it without restraint) would have cost, then paid for itself thereafter.
The only problem was, as far as I can tell, 802.11y-2008 gear never actually EXISTED as off-the-shelf products. The closest I found was a mPCIe module (by Microtik, I think) that *might* have been usable to make my own access points... but even now, I'm not 100% sure the module was 802.11y (the description circa 2012 mentioned wi-fi and 3.6ghz, but never came out and specifically said, "802.11y"). Until an 802.11* standard is at least mature enough that someone can choose between at least two off-the-shelf APs, and has at least one or two USB, mPCIe interfaces available, it's too risky to depend upon.
That said, I *am* kind of surprised that 60ghz is literally SO line of sight that it can't even work if you're 10 feet from the AP, but blocking the direct signal path with your body. I know it has no ability to PENETRATE anything, but I expected that it could at least REFLECT off of walls, the floor, the ceiling, etc.
Does the Vive just have a really, really shitty implementation (poor antenna, less than max legal transmit power, poor RF design vulnerable to noise or overloading, etc)? Or is that how bad 60ghz 802.11ad is in general?
Or worse... in the name of "democracy", the AI itself would be developed by elected officials with the approximate programming skill of the people who wrote horrific Visual Basic programs and Word/Excel macros & scripts with absolutely NO CONCEPT of security, maintainability, scalability, or code quality in general back in the late 90s/early 00s... ready to be pwn3d by the first group of hackers who find the AI's weakness, with organized crime, foreign governments, and extremist political groups laying the foundation for much more ambitious, longer-term complex multi-stage exploits.
So... we still need human oversight. But then, how do we pick those humans? In elections most people won't bother to vote in, by voters who can be systematically manipulated by social media campaigns that might be driven by the AI itself? At best, we end up with a system with checks & balances that's even more tortured and obtuse than what we have now. At worst, we end up with a system that lacks most of the protections given to us by those checks & balances.
As it stands, a company like Google can casually render you a non-person (potentially, with devastating results), for no specific stated reason, by having something (deserved or not) trigger one of their algorithms, ultimately ending with a declaration that their decision is final and there is no appeal, without ever having to even pretend that the decision was even reviewed by an actual human, let alone held to any objective standard of guilt and innocence. Do we REALLY want to subject ourselves to that same degree of scorched-earth indifferent bureaucracy from hell at the GOVERNMENT level as well?
Compressing with something like h.264/265 that depends upon having a few frames to reference adds latency. Doing things like HuffyUV... YPbPr with 4:2:2, RLE, etc, is fast, because it doesn't depend upon knowledge of anything besides the current frame.
The big delay with most codecs isn't literal calculation time, it's the need to wait until you have at least 2 or 3 frames in the pipeline before you can even START compression. For a modern GPU, matrix transformations between RGB & YPrPb or between 4:2:2 and 4:4:4, are practically instantaneous.
The key to making something like this work with a 1-2gbps link is to forget about codecs designed to be maximally-efficient, and instead look at codecs designed to be fast & "efficient ENOUGH".
Well, if you have an expensive video card that can do it without breaking a sweat & would otherwise just sit there unused going to waste, why NOT?
Effects like that might be wasteful if the computer is struggling to do the task at hand, but if you have that much raw horsepower just sitting around unused going to waste, you might AS WELL take full advantage of it.
It would be like running a stripped-down minimalist Linux distro on a 5GHz 8-core i9 with 1tb SSD instead of Ubuntu. You certainly could... but WHY? It would be like buying a Lamborghini, then using it only to drive around the neighborhood at 30mph running errands.
Interesting note... the Quest uses a Snapdragon 835 SoC, which was designed to cheaply support 60ghz 802.11ad with the addition of a single chip and some passive components. While that chip obviously isn't in the Quest, I can't help but wonder whether Carmack might have been able to pull some strings and find a way to expose the pins needed to interface with that chip so it could be implemented as an external add-on.
In most Android devices, the USB port is actually connected to the USB root hub through a crossbar chip that enables the port's literal pins to be connected to multiple different circuits inside the phone, and used for purposes that have nothing whatsoever to do with USB. For example... JTAG, I2S digital audio, analog audio, a TTL serial port, whatever.
I don't have an Adreno 835 datasheet in front of me, nor do I have any idea how the Quest is wired up internally. But... given how badly Carmack WANTED the Quest to support Rift-like usage, I'm going to go on a limb and theorize that if there's any way the engineers could have exposed the necessary pins to connect the Qualcomm 802.11ad chip to the 835 through the crossbar and USB-C port without raising the manufacturing cost... they almost certainly DID. Carmack is someone who absolutely HATES to slam the door on a future possibility if there's any possible way he can leave it propped open for free. He might have lost the battle to add the extra hardware to support something like DisplayPort-over-USB-C, but exposing a data bus through a crossbar that's already "there" using lines that would otherwise have gone unused is another matter ENTIRELY.
Another possibility: if at least a few of the pins on the USB-C interface are connected to pins on the 835 that can be tri-stated, and the pins on the 835 that are needed to connect to Qualcomm's 802.11ad chip can be tri-stated, Oculus could have conceivably dispensed with the crossbar entirely and just connected the two sets of pins in parallel. It would complicate the software initialization slightly (if something caused the 802.11ad-interface pins to go high or low, like a firmware bug, it could cause the USB interface to malfunction), but in hardware terms, it would basically be free. Worst-case, they might have to add some pull-up or pull-down resistors that they might have gotten away with omitting if the lines were single-use, but officially are required for standard-compliance ANYWAY.
On the downside, I'm not sure someone actually COULD viably sell such an 802.11ad interface, even IF the signals were exposed as described. The problem is FCC certification. If someone built a module that used an already-certified mPCIe 802.11ad module and connected to the Quest via literal USB 3.1, getting it past the FCC would be easy... they'd just have to prove it didn't emit excessive RFI, and that the 802.11ad module itself was already certified. In contrast, if they tried to roll THEIR OWN 802.11ad module using Qualcomm's bare chip, they'd have to go through a much more rigorous and expensive certification and approval process that would likely result in an 802.11ad add-on interface that cost $25 to manufacture and had to sell for $600 to cover the cost of getting it certified in the first place.
Ugh, the math actually isn't correct. I realized a half second after hitting submit that it should be 1440 x 1600 x 2 x 90 = 414,720,000 PIXELS/second. Assuming 32-bit alpha-blended color, that would be a little over 13gbps (415 million pixels x 32 bits/pixel).
That said, my idea might still be do-able... assuming the left and right frames are relatively similar, you could get lossless compression approaching 2:1 right off the top, reducing it to ~6.5gbps. Converting the video to 4:2:2 YUV with 2-4 bit RLE-compressed alpha-blending should easily chop at least a third of that away, getting us down to 4gbps. Dropping back to 4:2:0 color for the first frame after a radical scene change and referencing the previous frame can probably get us down to 2-3gbps. It would probably mean we'd have to do all the local image-recognition onboard instead of streaming the onboard cameras directly to the remote host since we'd already be maxing out the best-case USB bandwidth, but it should still be do-able since that would be just about the only thing (besides rendering the remotely-streamed video directly to the screen in the Quest, possibly after overlaying it on the local passthrough video in a genlock-like manner) we'd have to DO on the Quest itself.
So... I think my idea might still work, but only if the Quest's USB interface really, truly can sustain 2gbps at the bare minimum, and would be risky unless it could reliably sustain 4gbps.Any lower bitrate, and we'd probably have to forget about uncompressed (or lightly compressed) video from the host PC (or at least, settle for major visual artifacts whenever there's a radical scene change, since we'd only be able to reference past frames without adding latency and any completely new frame would be limited to the data we can fully transfer within 1/90th of a second)
Or built 802.11ad ("WiGig") into the Quest, and allowed anyone with a suitable access point (or PC via peer-to-peer) within 3-10 meters in the same room to basically stream 90fps uncompressed video directly to it with minimal latency. From what I understand, short-distance line of sight 60GHz 802.11ad is capable of easily sustaining 4-6gbps with a minimal implementation, potentially faster with a more sophisticated implementation.
Assuming my math is correct, 1440 x 1600 x 2 x 4 x 90 = 1.659gbps. With 4-6gbps to play with, there's plenty of headroom left to stream the Quest's own video and sensor data straight back to the host PC (without delay or compression).
If I understand correctly, and the Quest's own cameras can be used to capture eye-level stereo video suitable for passthrough AR, having 802.11ad onboard would also potentially enable you to do something like this:
* Grab a pair of raw video frames at the camera's fastest framerate, plus all the sensors that the host PC has subscribed to.
* Throw them across the network at the host PC without compression for it to use for things like object/gesture-recognition.
* A moment later, the next pair of frames arrives from the host PC (either without compression, or some low-latency mostly-lossless fast compression that only compresses the delta between the left and right frames), with 8-bit alpha channel. Merge them with the most recent local passthrough frames, and display them.
The advantage of doing genlock-type overlaying of PC-generated video with locally-captured passthrough video is latency... when doing passthrough VR, even a single frame of latency is painfully noticeable, and two or more is downright nausea-inducing. By keeping the passthrough-AR video's processing realtime and local, you could shave the frame or two of latency you'd otherwise end up with if you had to wait for it to get to the host PC, get edited into the next frame, then get sent back.
Remember... with VR, and even moreso with passthrough AR, latency is EVERYTHING. Anything you can do to reduce it is going to profoundly improve the user experience. If you're going to just overlay remotely-generated content into video captured locally ANYWAY, it makes no sense to add the latency of sending that local passthrough video to the remote PC just so it can be edited into the scene and transmitted right back. The Quest has more than enough horsepower to do THAT job locally.
Anyway, that's my view. 802.11ad has plenty of bandwidth to stream high-framerate video with minimal latency in both directions, so you'd get the best of both worlds... you could use the Quest's own processor to do locally things that would take longer to roundtrip, while nevertheless offloading the really heavy lifting to a PC across the room that's as powerful as it needs to be to do whatever you want.
Now, the good part. IF (big "if") the Quest actually has a USB 3 port with enough bandwidth to sustain anything close to 2gbps+, and Oculus exposes enough functionality to allow a thirdparty to pull it off, some thirdparty (or grad student looking for a cool thesis project) could conceivably make their OWN 802.11ad interface for the quest, and do exactly what I've described. Say, built around an off-the-shelf 802.11ad mPCIe module, in a belt/pocket-mounted case the approximate size of a RasPi with its own battery, connected to the Quest via USB. Ideally, the Quest supports being a USB host... but even if it doesn't, implementing the module as a USB host and connecting to the Quest via OTG isn't all that big of a hurdle. The biggest unknown is whether the Quest's USB implementation is actually fast enough to sustain the kind of transfers using an external 802.11ad card would require.
I'll believe realtime raytracing -- classic, physically-based, or otherwise -- has really arrived when a future version of Windows gives us everything Aero was supposed to have been in the first place, including accurately-blurred semi-translucency with refraction, crystal-like window chrome, and everything else. Not faked translucency, but literal "window content is rendered onto semi-translucent dark smoked virtual glass, with obscured content that's somewhat visible through it accurately updated in realtime". And does it on a row of three 3840x2560 desktop-extending displays at 120fps with zero glitches or slowdown.
I don't think that's too much to ask for. If a game can do 4k at 144fps with water effects, accurate shadows, and 400 moving elements, is it REALLY expecting too much for Windows to be able to run Word with a vaguely-translucent milky-white background that vaguely hints (accurately) at the scrolling output from a command prompt running behind it while making the window chrome sparkle with faux diffracted light?
At the moment, the best passive long-term storage medium we have is the original (high-to-low) standard for single-layer BD-R.
Note this is NOT the newer & cheaper "low-to-high" (LTH) standard that came out a few years later.
HTL starts out as a shiny substrate that gets melted & dulled by the laser. LTH uses organic dyes (like DVD+/-R) that fade over time, especially if exposed to light or heat.
Players capable of reading them might not be common cheap consumer items 25-100 years from now, but they absolutely WILL exist as items for libraries, universities, governments, etc (so they might not be CHEAP, but they'll definitely exist & be reasonably available).
Avoid multi-layer discs. Lower layers START OUT with (recoverable) errors, and only get worse over time.
The main advantage of HTL (non-LTH) BD-R is the fact that it decouples the reading apparatus & electronics from the media. If your only copy of something is on a 40 year old SATA hard drive that no longer works, you're going to spend an UNHOLY amount of money to recover the data... if it can be recovered AT ALL.
Flash storage is COMPLETELY unfit for long-term storage... it's like a leaky bucket. And newer flash is LESS long-term stable, because the margin for error in MLC flash is a fraction of what it was with SLC flash.
By all means, keep additional backups in the cloud or on hard drives... but if you have to gamble everything on a single media type, go with HTL (non-LTH) BD-R.
Also... use common, open, well-documented & non-proprietary formats. Think twice about using encryption & ask whether you'd be more traumatized by disclosure or permanent loss... and assume the lesser evil you choose WILL happen.
Assume anything that's DRM-protected is likely to be gone in the long-term... by obsolescence & obscurity, if not outright disappearance.
I think the IPv6 privacy extension goes a step further & shares a short privacy prefix among a large number of the ISP's users... so you, as the customer, would get TWO prefixes:
* a 48-64 bit prefix that's either fixed, or at least infrequently-changing
* a much longer prefix with a much shorter lease, from among a short prefix shared by a large number of users, to use for tasks like anonymous web-browsing.
That said, I think I remember reading that many US ISPs currently take the middle ground... they assign a 56-64 bit prefix, and have a web proxy available for customers to optionally use for privacy-sensitive traffic that does address-scrambling. I think the push for doing it at the IP level is to satisfy government logging requirements. With the proxy approach, the ISP has to log (and retain) literally every http request (or at least, the origin, destination, and timestamp). With the IP approach, the ISP only has to log the IP assignments (lowering the compliance storage burden enormously).
> Please focus on solutions that work for everyone.
Nothing EVER literally works for "everyone"... but if you really want to be pedantic about it, the app is for user convenience.
If push really came to shove, even somebody with a https://en.wikipedia.org/wiki/... could call their telephone service provider's customer service number to generate and obtain another batch of 10-25 40-digit numbers assigned to their phone and write them down on a page of the phone's paper "phone book" using its included pencil... crossing them off the list (ideally, with a note indicating whom they assigned the number to) as they use them one by one.
Or, someone could buy a million randomly-generated phone numbers, print them into 10,000 booklets of LITERAL "one time pads" with 100 of those numbers apiece, and provide a customer service number on the back that the purchaser could call to instantly associate the 100 numbers in that book with their "real" phone number. Maybe print 5 numbers per credit card sized perforated tear-off sheet, so the buyer could rip of a sheet at a time & carry it in their wallet to use as the need for a number arises.
The point is, it's 2019, and even someone who's dirt poor can buy a piece of shit throw-away Android phone at Walmart for $30... or get one that's practically free from a pail at a flea market or Goodwill store.
There you have it... an entire spectrum suitable for 99% of people who care enough about avoiding unwanted calls to at least lift a finger and do something about it, ranging all the way from convenient apps to numbers written on scraps of paper.
> Obviously the fail here is when they start using your known contacts that were leaked out by social media and other parasites
That's the beauty of giving everyone a different number to call you at... if the phonebook of a friend or relative gets inhaled by malware, all that's been compromised is LITERALLY a single phone number used by exactly one person to call you. It's a lot easier to nuke a number used by only one person to contact you and give them a new number to reach you at than to change your One and Only phone number and update everyone ELSE to use it instead.
This is why I started using adhoc email aliases more than 15 years ago... everyone who emails me gets a different address to reach me at. Part of my reason for starting to use adhoc aliases was precisely the fact that people like my dad kept getting their addressbooks vacuumed up by malware and ruining my email addresses by disclosing them to spammers. The solution was to limit the scope of damage from any one addressbook-slurping to an address used by exactly one person. If a business extorts my email address from me and starts spamming me, I don't have to bother asking them to stop emailing me... I just add the alias to my mail server's nuke list, and future email from them gets blackholed directly to/dev/null.
As an alternative, they could possibly extend SS7 so that it uses the first {n} digits to ROUTE the call, but PRESERVES and PASSES ALONG an additional {x} digits as the tail end of the caller ID string so people could treat those additional digits as customer-defined routing codes, inbound-ring passwords, whatever. It would only be used by tech-savvy users for a few years, but eventually someone like Apple or Verizon would start selling services to intercept inbound calls and decide how to handle them based upon the additional digits dialed along with the number itself. The only catch to make THIS work would be the need for a federal regulation requiring that any business that DEMANDS the disclosure of a phone number be capable of accepting registrations with the additional digits (put another way, a shitty web site that just wants a phone number for no specific reason and doesn't actually REQUIRE you to provide a number could still get away with only allowing 10-digit numbers, but someone like Domino's, Uber, Citibank, or whatever who won't allow you to proceed with registration or an order without disclosing a valid phone number would be required by law to accept those long numbers).
Building on random-dialing prevention, they could set aside all the 40-digit numbers so that attempting to dial an invalid number cost the caller 10 cents, but dialing a valid number was free. That alone would quickly reduce random dialing by telemarketers by destroying the profitability of dialing random numbers.
The only way keeping your phone number a secret might reduce spam calls is if the current successor to NANPA (Neustar?) takes a currently-unused areacode, then uses it as the prefix for a random 40-digit phone number (approx. number of decimal digits in the largest unsigned 128-bit value), then allows consumers to link an unlimited number of randomly-picked numbers to your "real" one (and allow you to know what number an incoming call dialed, so you could program your phone to ignore incoming calls to your "real" number, but allow incoming calls to one of your incoming 40-digit numbers to ring).
Then, whenever you had to give someone "your number", you'd peel an unused 40-digit number from the metaphorical stack & give it to them (probably, via an app running on your phone).
If a specific incoming number of yours started attracting too many junk calls, you could unceremoniously nuke it & unlink it from your real number. Likewise, since you'd give a unique inbound number to everyone, you could do 'traitor tracking' & punish businesses that failed to safeguard your number.
Random dialing would cease to work, because a robocaller could literally try random numbers for HOURS before hitting a valid one... especially if the system were designed to detect and frustrate such attempts.
The same service could reserve the shorter numbers (say, 12-16 digits) for more public purposes. Say, I might buy a 16-digit number & post it to social media after linking it to a service that charges callers $20 to complete the call (if I answer) & pays ME $15 for answering it if I agree to talk to the caller for at least a minute. We could ALL have the equivalent of 1990s-era 900/976 numbers to give out to the public & use dollars as a tool for screening our calls. I might even set up one number with a $5 charge explicitly FOR telemarketers to call me at, agreeing to give them 5 minutes of my time in exchange for paying me to listen.
Or... I could point one number to a bot that answers the call, then makes the caller play "Simon Says" & spend 10-20 minutes answering captcha-like puzzles for the privilege of making my phone ring (or the privilege of leaving me a message) for free.
If you read the article, the summary omits a very important detail... he spent most of his time with a headset that had a live video feed of his surroundings. So, he didn't spend a week in "VR" as much as spend a week with a simulated visual impairment.
This is important. If you involuntarily spent an entire week immersed in a true immersive VR environment, you'd either become VIOLENTLY ill, you'd experience a literal dissociative psychotic break after a few days, or both. Seriously, read the descriptions of what it's like for someone who's relatively "VR-adapted" to take off the headset and feel oddly disconnected from their seemingly "unreal" physical surroundings for a while... then compare that description to the symptoms of depersonalization/derealization disorder.
I mean, it's a damn good thing modern-day VR didn't exist during the Cold War, let alone Nazi Germany. I honestly think being involuntarily restrained and fully-immersed in an intentionally-malicious VR environment designed to fuck you up as badly as possible would be worse than sensory deprivation. The sad fact is that intense, fully-immersive virtual reality is kind of like being in a relationship with an abusive spouse you can't bring yourself to leave because you also have so much fun together.
If you think you're immune to VR sickness, get an Oculus Go and try playing a game like immersive first-person VR Quake for an hour. And if by some miracle THAT doesn't get you sick, try playing the "ISS" game... but move around smoothly using the D-pad instead of lurching from grab-bar to grab-bar or teleporting.
This is why I'm such a huge fan of mixed and augmented reality... mixed/augmented-reality doesn't make me get sick. My brain can deal with having things synthesized and anchored into my surroundings... it can't deal with the sensory assault of having my senses in total contradiction. IMHO, immersive virtual reality that doesn't involve using cameras to transform it into augmented reality is an evolutionary dead end. With immersive VR, every sensory problem you solve just creates 5 NEW (and worse) problems. With mixed reality, you can abseil through the uncanny valley and laugh at the contradictions. With fully-immersive VR, it's more like parachuting into the uncanny valley while getting shot at with real bullets.
Slashdot Mirror
"thousands of miles across a desert" is kind of an exaggeration. The Great Pyramid is about 4 miles from downtown Cairo, itself adjacent to the Nile. Modern-day Cairo literally sprawls to the base of the pyramids. Back in ancient times, you could have probably seen the pyramids from just about anywhere along the Nile within 10-20 miles of Giza.
This 360-degree photo vividly illustrates just how close the pyramids are to Cairo:
https://www.google.com/maps/@2...
Another pic that really makes it shockingly clear just how adjacent they are to Cairo:
https://www.google.com/maps/@2...
> in order to warehouse a few humans
On one hand, the pyramids were an extravagant waste of money if you consider only their official intended purpose. On the other hand, considering how much money they generate for Egypt's tourist industry year after year, they were arguably one of the most robustly-profitable long-term capital investments in the history of human civilization.
Part of the problem is that these services have too much blind faith in their ability to make predictions based upon incomplete knowledge. They REALLY need to come up with a way for users who end up pigeonholed and seeing endless recommendations for content to indicate, "Alright, enough already! I read a goddamn article about something while I was bored & taking a dump. Go back to recommending the kind of stuff I'm NORMALLY interested in."
It's like the way TiVo used to be. A few years ago, my brother's family came down for a weekend. I recorded two episodes of a show for my niece & nephew. For the next 3 months, my Tivo was absolutely HELLBENT on endlessly recommending shows on Disney & Nickelodeon, despite the fact that I had about 40 open-ended scheduled recordings for shows that were about as close to being polar opposites of Disney & Nickelodeon kids' shows as you can get. It's like their algorithm said, "Oh, JOY!!!! Someone who now has small kids!!!! Now they're ensnared in the parent-industrial complex forever!!!"
Because Google has decisively and intentionally made its services into infrastructure with a direct, demonstrable impact upon interstate commerce. Pretty much every single Supreme Court decision over the pasty century has reinforced and reaffirmed the right of Congress to regulate anything that significantly affects interstate commerce, including actions that themselves only involve actions taking place entirely within a single state (and only indirectly affect interstate commerce).
Here's an illustrative example. Suppose a city allows a private company to build toll roads through its present-day hinterlands, and agrees to exclusivity agreements that prohibit the city from building (or allowing others to build) any infrastructure that might "compete" with that company's toll roads for the next 100 years (with "compete" being interpreted as anything that might be an alternative to the road, including rail lines, bike paths, helicopter landing pads, or even dirt paths not blocked by fences and "no trespassing" signs). Fast forward 50 years. Land that used to be desolate swamp or desert has become the metro area's second (and maybe third or fourth) central business district. Most of the metro area's best job opportunities and residential areas are now there as well.
One day, out of the blue, the company that owns the toll roads decides that certain individuals are no longer allowed to travel on its roads... even as passengers in vehicles driven by others... and deploys a network of private investigators and security guards to make sure that buses and taxis aren't carrying banned individuals as passengers (knowingly OR unknowingly). The company feels no need to explain why, and asserts both its right to exercise unlimited discretion in whom it accepts as customers (direct or indirect) and disavows any need to justify it.
That policy would almost INSTANTLY be swatted down by legal challenges, on so many possible legal grounds it's hard to even know where to start.
Yes, we had a similar debacle with the "No-Fly List"... but at least the No-Fly List was ultimately subject to constitutional safeguards. It was a hot clusterfuck of an unholy mess... but at least anyone who ended up on the list could feel confident that their case would EVENTUALLY be reviewed by real people who actually CARED about facts and evidence... which is more than you can say for anyone who's ended up on the receiving end of Google's automated wrath.
Putting it more starkly, suppose you were one day cornered by an evil, sadistic being with deity-like powers who told you, "I've decided to ruin your life as much as possible... but I don't want to be thought of as COMPLETELY evil, so I'll let you pick between two alternatives:"
1. You get put on the 'no-fly' list for a reason that will be readily apparent as an error the moment someone officially reviews your case.
2. Lifetime banishment from all services provided by Google (including indirectly, as the user of a service that itself depends upon Google services), with no right to review by a human... or any right to review and due process AT ALL.
As bad as #1 would be, I think just about everyone would agree that #2 would be ENORMOUSLY worse in the long run (and, on strictly narrow constitutional grounds, would severely harm your present and future ability to engage in interstate commerce... and in aggregate with others similarly affected, would have a significant effect upon interstate commerce overall).
Google doesn't have to be micromanaged by the government... but if it wants to be an inescapable provider of business infrastructure that's inextricably woven into the very fabric of America's economy, it needs to start ACTING like it, and respect the safeguards that have traditionally made America a safe place to do business. Google is presently engaged in arbitrary acts of economic violence that will ultimately harm our economy if allowed to continue unchecked.
> Ah played with Enlightenment, have you?
Pfft. 20 years ago, I went on a multi-week holy
quest to try and find a way to make Enlightenment work with networked X11 and a headless Linux box. It was an act of hopeless futility (Enlightenment needed capabilities that X11 can't provide over a network, and I later discovered that for various unintuitive reasons, networked X11 usually has worse performance than VNC).
BTW, for anybody who's wondering, networked X11 is NOT the Linux equivalent of RDP with Windows. It's roughly ANALOGOUS to it, but they're products of different eras. Networked X11 hasn't aged gracefully AT ALL, and BOTH RDP and the entire architecture of Windows display drivers evolved hand in hand to support each other.
Sadly, there really is no RDP-equivalent on the horizon for Linux. VNC sucks, but it's perceived as "good enough" because there's nobody willing to finance & shepherd 10 calendar years of development into Linux video architecture to
come up with a new standard that's simultaneously high-performance, networkable, and yet capable of being used in stripped-down form on lesser hardware. Both X.org and Wayland have struggled to fully replace legacy X11, and Wayland's developers EXPLICITLY decided ~5 years ago that RDP-like networkability was off the table, and not even an 'aspirational' long-term goal, while X.org decided to settle for maintaining legacy compatibility with some minor tweaks to improve security.
The fundamental problem is that Google has increasingly put indie developers in impossible positions by changing the rules, deciding to retroactively apply them to apps that were published via Google Play literally YEARS ago under different rules, then swooping down and suspending them without warning, and perma-banning any developer who gets "too many" apps suspended. And perma-banning (for life) the accounts of anyone whom their AI determines is somehow "linked" to the account that was banned for having old apps that were retroactively determined to be in violation of rules that didn't even exist at the time they were published.
It's as if Google sat down, read about China's "social credit score" (which dings individuals merely for "associating" with anyone whose social credit score is low), then enthusiastically decided to roll it out as the new model for all Google services. There are people who've invested literally YEARS of their careers in Android development who've not only had their portfolios and/or ad revenue cut off without warning, they've been rendered UNEMPLOYABLE as Android developers because any company that hires them would risk getting "linked" to them by association and punished as well. If you're American, you're at risk. If you're from a country like Canada, Britain, France, or Germany, you're at slightly greater risk. If you're from India or eastern Europe, Google will ban you on the slightest whiff of suspicion without a second thought. All with no meaningful route to clear your reputation (or even find out what exactly they think you did that was horrible enough to justify destroying your career), and officially... for the rest of your life.
Yes, Google really HAS become that completely evil and bad. Frankly, I'm shocked it hasn't been the plot of at least a few Hollywood movies yet.
I haven't personally gotten banned, but the extreme danger faced by anyone who develops Android apps and depends upon any Google service has forced me to step back from Android and intentionally minimize my future exposure to Google's potential wrath. Google has now taken it upon themselves to be judge, jury, and economic executioner... based upon algorithms with confirmed, known false positives and literally ZERO accountability or pretense of due process.
For a developer, the implications of getting banned for life by Google goes WAY beyond merely being unable to publish apps via Google Play. Getting banned ALSO locks you out of the entire Google Play ecosystem, so you can't use Play Location Services or Google Maps API for apps published independently of Google Play, either. It can result in the loss of access to every Android app you've ever purchased through Google Play, and could get you permanently locked out of any third-party web site that uses Google's authentication services.
And once again, people have gotten such bans not for publishing malware, but merely for having ever published an app that was completely acceptable to Google at the time it was published, but later failed to comply with Google's changed requirements. Most outrageously of all, Google won't even settle for allowing you to preemptively unpublish your now-noncompliant app, because even unpublished apps remain accessible to people who've purchased them in the past. There are documented cases of developers who've unpublished a now-noncompliant app from Play, then ended up getting that now-unpublished app suspended at some later time ANYWAY (possibly triggering a lifetime ban of the developer's own account).
Google has NEVER been known for particularly caring about anyone who falls victim to its policies as collateral damage... but this is seriously the kind of thing that's going to end up putting Google on the receiving end of a class-action lawsuit that would probably end up getting appealed all the way to the US Supreme Court (basically, asking the court to decide whether a company that intentionally injects itself into so many cross-cutting aspects of interstate commerce ought to be held to a higher
Ok, so limit the subsidized portion to the nearest paved road or existing utility pole on public right of way, whichever is closer. That would eliminate the most expensive 1% or so that would likely account for 40-50% of the subsidy costs.
Even now, I'd guess that at least 80-95% of remote small towns with 50-100 residents now have existing fiber within 10 miles, probably less. Towns don't crop up in random locations... they develop around transportation routes. If you factor out the least-populous 1% of American settlements, the remainder pretty much ALL fall along visually obvious lines. Even in places like rural Nebraska... you have a widely-spaced grid of roads with family farms that are uniformly narrow along a public road & really deep. In Alaska, just about any settlement with electricity falls along a public road connecting lots of similar settlements. The truly isolated & outrageously expensive to serve ones (without commercial electricity) wouldn't qualify under my standard, anyway.
A major limit TODAY isn't the cost of getting fiber to the nearest public road, it's the cost of running fiber down a quarter-mile driveway. The feds could allow those people to finance its construction at 0% interest and 25-year payback schedule, tied to the land as a lien if it goes unpaid.
We don't demand 100% geographic availability for electricity or landline telephone... some areas ARE genuinely too remote and expensive to serve. But getting to 80-90% is cheap, and getting to 99% (up to the point where the paved public ROW ends) is fairly cheap considering fiber is a 100+ year infrastructure investment.
Suppose I write an Android app that uses Google Maps & requires an API key. I dutifully follow Google's instructions, build my app with the key in Strings.xml, compile it, sign it, and publish it to Google Play.
What, exactly, is there to stop someone from obtaining my app through Google Play, ripping it from their phone, deodexing the binary, extracting my API key, then writing THEIR OWN Maps-using app that uses my API key and distributing it to a million users in China (or anywhere else in the world) so the API calls of ITS users end up getting charged against MY account?
I mean, I certainly hope that Google at least does binary-analysis and would reject an app uploaded to Play that attempted to re-use MY API key... but that still does nothing to address API key security in apps NOT distributed via Google Play.
Likewise, Google could theoretically do some form of sanity-checking, and pass along BOTH my API key AND an ID tied to that specific user via Google Play Services, and reject the key's use if the user had never actually installed my app... but that wouldn't help with something like Amazon API keys.
I could see it being secure if API keys offloaded responsibility for registration and payment directly to end users, so that apps would be distributed with dummy keys that were replaced by "real" ones after end users directly authenticated THEMSELVES to Google Maps, Amazon AWS, etc., and used MY app with THEIR key at THEIR OWN expense... but I just don't see how the current way API keys are used with things like Android apps is in any way even REMOTELY secure against key-hijacking.
This is a MAJOR reason why I've always been afraid to publish any Android app that depends upon having an AWS key. At least Google will allow you to distribute a Maps-API-using app with a key that simply gets disabled if you go over the free limit. Amazon won't. They'll give you a certain free allowance, and it might even be fairly high... but Amazon WILL NOT give you the courtesy of setting any kind of absolute circuit breaker and tell them, "if my app exceeds {free-allowance | some-absolute-limit}, just kill it dead and stop any additional charges from accruing". Even worse, Amazon's billing isn't realtime... you can set up all the safeguards you want to notify you if your usage exceeds some amount and kill your account, and even to try and kill it via scripted means... then see the amount you own CONTINUE to skyrocket AFTER you've pulled the plug due to use that happened before you suspended the service, but AFTER the most recent balance update.
Frankly, Amazon's AWS billing policies (above and beyond any concerns about the security of distributing an app with my API key compiled into it) scare me shitless, and apparently I'm far from being the only one who feels that way. I, for one, will NEVER willingly give someone a literal blank check to bill me into bankruptcy.
Exactly whom are you talking about?
* Americans with college degrees? Bzzzt. Under NAFTA, any American or Canadian with a college degree can go work in the other country, as long as they aren't barred from entry for some other reason.
* Americans without a college degree? Unlikely. From what I've heard, it's damn near IMPOSSIBLE for an American without a college degree to officially get permission to move to Canada and work (and vice-versa). There are a few edge cases, mostly in the entertainment industry, but not many.
* non-Americans who came to America as H1-B and went to Canada as the equivalent of H1-B after losing their job in the US? I suppose it's not impossible, but I believe someone who moved to the US under H1-B, lost their job, quickly applied for a job in Canada, and managed to get hired & moved there before the US officially kicked them out would STILL have to make a final documented trip from the US back to their own country before flying to Canada to begin their official employment there, which would instantly nuke a few thousand dollars right off the top.
Personally, I think there are already too many stupid barriers between the US and Canada. It's not like there are masses of impoverished Americans or Canadians huddled along the border desperately yearning to flee in EITHER direction. If an American wants to move to Canada, or a Canadian wants to move to the US, fine. Let them. Any cost borne by either country (and the respective states or provinces) would probably be piddling compared to the cost of enforcing laws that literally EVERYONE thinks are patently absurd.
Hell, I'd go so far as to extend the deal to just about ANY country with an economy that's basically equivalent to that of the US, with approximately the same number of people who want to move in both directions. Just to pick another comparable English-speaking country as an example, let's say the UK. The fact is, relocating across the Atlantic is incredibly expensive, and it's not like someone who's indigent in either country could possibly afford to just casually move to the other, EVEN IF the border and immigration formalities were minimal and frictionless.
If US citizens and British citizens could freely move in both directions, I'd guess that the absolute number moving in both directions would be approximately equal, and that the overwhelming majority of people doing the moving would either be recent college grads who think living in the other country would be cool, or people who ended up in a relationship with someone from the other country & decided to move to the same city as a sensible next step. For the first year or two, there might be an influx of British construction workers naive enough to think they could spend the winter working in Florida... until word got out that half the construction workers in the northern US have the exact same idea at some point in their lives, and the amount they could earn working in Florida during the winter is so insultingly low compared to what they'd make in London, they'd come out ahead financially if they just literally spent the winter collecting British unemployment benefits instead of bothering to try working in a state with third-world wages and first-world cost of living.
Update... just did some more research about 802.11ad. According to what I've read,
* 60GHz can't penetrate anything (including fleshy lifeforms), but absolutely DOES reflect from most surfaces. Its max distance is approximately 100 feet, measured along the signal's path (including any reflections necessary to reach the receiving antenna).
* In an area like an enclosed conference room that's approximately 12x20 feet, with the AP itself located in a spot that's sane (ie, not inside a cabinet or deliberately hidden behind/below something), but not otherwise chosen with any particular care, you can realistically expect 1gbps in 99% of the room, 2gbps in 90-95% of the room, and 4gbps in 60-80% of the room.
* It appears that the real-world performance difference between two single-antenna 802.11ad network adapters directly communicating as peers is PROFOUNDLY worse than the performance you'd get with a proper access point operating in 'infrastructure' mode with beamforming, hanging from the ceiling near the center of the room. In the former case, bodily obstruction could make a HUGE difference, because the alternate paths might exceed more than 100 feet after factoring in multiple reflections... multiplied by all that potential multipath interference. In the latter case, the AP would constantly be probing around to find the ideal beam direction that maximizes signal strength and minimizes multipath interference... simultaneously increasing signal quality and minimizing echo-like background noise.
* Supposedly, 802.11ad has extraordinarily low latency compared to 802.11ac and older standards... like, 10 microseconds. Apparently, it's low enough to use as the transport layer for PCI Express as long as the transmission conditions are basically ideal (like, a wireless laptop dock that's nevertheless within a foot or two of the laptop, with clear line of sight between the antennas).
So... it looks like that with a proper access point in an intelligently-chosen location and a halfway-reasonable attempt to keep the client's antenna in a reasonably visible location, you could feel absolutely confident of sustaining 1gbps just about everywhere within 10-20 feet of the AP, 2gbps nearly all the time, and 4gbps most of the time. Of course, this all assumes that the Quest has a viable interface to the outside world, and that its USB port (for example) would not itself be the primary bottleneck.
---
Side thought... I'll be absolutely SHOCKED if a future teardown of the Quest doesn't reveal the presence of at least a few "test" pads on the circuit board that expose the signals needed to connect Qualcomm's 802.11ad chip and/or implement Rift-like HDMI connectivity, EVEN IF Oculus has literally no intention of ever officially supporting their use by end users. The fact is, it's a lot cheaper to have one of their engineers grab a production Quest and hack it into an experimental prototype than to go through the effort and expense of building one-off prototype headsets for internal use from scratch. Chances are, the Quest prototypes that were being made a few months before it went to manufacturing (and before the official specs were finalized) had circuit boards that implemented "everything" (802.11ad via Qualcomm's extra chip, a HDMI-like video link, etc), then later prototypes simply omitted the components to implement the unnecessary functionality. Even if they subsequently pruned away the component footprints, they almost certainly would have left the pads, just in case someone down the road at Oculus needed some in-house prototypes that re-implemented the desired functionality.
> and the &%$^ Volvo can't outrun a Yugo.
I think a morbidly obese woman in a motorized wheelchair scooter could have outrun a Yugo.
The main issue with 802.11ay is that 802.11ad exists today at a cost that's within the realm of 'sane', even though it's still pretty niche. 802.11ay, not so much. Not everything involving 802.11 turns to gold. Just look at 802.11y (basically, 802.11n with tweaks & extensions to operate in the lightly-licensed 3.6ghz band).
Back when AT&T still had a 1gb monthly data cap, I would have totally bought a home 802.11y access point & license, and a pocket-sized access point that used 802.11y for the backhaul & 802.11n for connections from my phone, because it would have enabled me to have free ~256kbps(ish) data within ~10km of my house for approximately what a year of monthly overage fees from AT&T (if I'd used it without restraint) would have cost, then paid for itself thereafter.
The only problem was, as far as I can tell, 802.11y-2008 gear never actually EXISTED as off-the-shelf products. The closest I found was a mPCIe module (by Microtik, I think) that *might* have been usable to make my own access points... but even now, I'm not 100% sure the module was 802.11y (the description circa 2012 mentioned wi-fi and 3.6ghz, but never came out and specifically said, "802.11y"). Until an 802.11* standard is at least mature enough that someone can choose between at least two off-the-shelf APs, and has at least one or two USB, mPCIe interfaces available, it's too risky to depend upon.
That said, I *am* kind of surprised that 60ghz is literally SO line of sight that it can't even work if you're 10 feet from the AP, but blocking the direct signal path with your body. I know it has no ability to PENETRATE anything, but I expected that it could at least REFLECT off of walls, the floor, the ceiling, etc.
Does the Vive just have a really, really shitty implementation (poor antenna, less than max legal transmit power, poor RF design vulnerable to noise or overloading, etc)? Or is that how bad 60ghz 802.11ad is in general?
Or worse... in the name of "democracy", the AI itself would be developed by elected officials with the approximate programming skill of the people who wrote horrific Visual Basic programs and Word/Excel macros & scripts with absolutely NO CONCEPT of security, maintainability, scalability, or code quality in general back in the late 90s/early 00s... ready to be pwn3d by the first group of hackers who find the AI's weakness, with organized crime, foreign governments, and extremist political groups laying the foundation for much more ambitious, longer-term complex multi-stage exploits.
So... we still need human oversight. But then, how do we pick those humans? In elections most people won't bother to vote in, by voters who can be systematically manipulated by social media campaigns that might be driven by the AI itself? At best, we end up with a system with checks & balances that's even more tortured and obtuse than what we have now. At worst, we end up with a system that lacks most of the protections given to us by those checks & balances.
As it stands, a company like Google can casually render you a non-person (potentially, with devastating results), for no specific stated reason, by having something (deserved or not) trigger one of their algorithms, ultimately ending with a declaration that their decision is final and there is no appeal, without ever having to even pretend that the decision was even reviewed by an actual human, let alone held to any objective standard of guilt and innocence. Do we REALLY want to subject ourselves to that same degree of scorched-earth indifferent bureaucracy from hell at the GOVERNMENT level as well?
Compressing with something like h.264/265 that depends upon having a few frames to reference adds latency. Doing things like HuffyUV... YPbPr with 4:2:2, RLE, etc, is fast, because it doesn't depend upon knowledge of anything besides the current frame.
The big delay with most codecs isn't literal calculation time, it's the need to wait until you have at least 2 or 3 frames in the pipeline before you can even START compression. For a modern GPU, matrix transformations between RGB & YPrPb or between 4:2:2 and 4:4:4, are practically instantaneous.
The key to making something like this work with a 1-2gbps link is to forget about codecs designed to be maximally-efficient, and instead look at codecs designed to be fast & "efficient ENOUGH".
Well, if you have an expensive video card that can do it without breaking a sweat & would otherwise just sit there unused going to waste, why NOT?
Effects like that might be wasteful if the computer is struggling to do the task at hand, but if you have that much raw horsepower just sitting around unused going to waste, you might AS WELL take full advantage of it.
It would be like running a stripped-down minimalist Linux distro on a 5GHz 8-core i9 with 1tb SSD instead of Ubuntu. You certainly could... but WHY? It would be like buying a Lamborghini, then using it only to drive around the neighborhood at 30mph running errands.
Interesting note... the Quest uses a Snapdragon 835 SoC, which was designed to cheaply support 60ghz 802.11ad with the addition of a single chip and some passive components. While that chip obviously isn't in the Quest, I can't help but wonder whether Carmack might have been able to pull some strings and find a way to expose the pins needed to interface with that chip so it could be implemented as an external add-on.
In most Android devices, the USB port is actually connected to the USB root hub through a crossbar chip that enables the port's literal pins to be connected to multiple different circuits inside the phone, and used for purposes that have nothing whatsoever to do with USB. For example... JTAG, I2S digital audio, analog audio, a TTL serial port, whatever.
I don't have an Adreno 835 datasheet in front of me, nor do I have any idea how the Quest is wired up internally. But... given how badly Carmack WANTED the Quest to support Rift-like usage, I'm going to go on a limb and theorize that if there's any way the engineers could have exposed the necessary pins to connect the Qualcomm 802.11ad chip to the 835 through the crossbar and USB-C port without raising the manufacturing cost... they almost certainly DID. Carmack is someone who absolutely HATES to slam the door on a future possibility if there's any possible way he can leave it propped open for free. He might have lost the battle to add the extra hardware to support something like DisplayPort-over-USB-C, but exposing a data bus through a crossbar that's already "there" using lines that would otherwise have gone unused is another matter ENTIRELY.
Another possibility: if at least a few of the pins on the USB-C interface are connected to pins on the 835 that can be tri-stated, and the pins on the 835 that are needed to connect to Qualcomm's 802.11ad chip can be tri-stated, Oculus could have conceivably dispensed with the crossbar entirely and just connected the two sets of pins in parallel. It would complicate the software initialization slightly (if something caused the 802.11ad-interface pins to go high or low, like a firmware bug, it could cause the USB interface to malfunction), but in hardware terms, it would basically be free. Worst-case, they might have to add some pull-up or pull-down resistors that they might have gotten away with omitting if the lines were single-use, but officially are required for standard-compliance ANYWAY.
On the downside, I'm not sure someone actually COULD viably sell such an 802.11ad interface, even IF the signals were exposed as described. The problem is FCC certification. If someone built a module that used an already-certified mPCIe 802.11ad module and connected to the Quest via literal USB 3.1, getting it past the FCC would be easy... they'd just have to prove it didn't emit excessive RFI, and that the 802.11ad module itself was already certified. In contrast, if they tried to roll THEIR OWN 802.11ad module using Qualcomm's bare chip, they'd have to go through a much more rigorous and expensive certification and approval process that would likely result in an 802.11ad add-on interface that cost $25 to manufacture and had to sell for $600 to cover the cost of getting it certified in the first place.
Ugh, the math actually isn't correct. I realized a half second after hitting submit that it should be 1440 x 1600 x 2 x 90 = 414,720,000 PIXELS/second. Assuming 32-bit alpha-blended color, that would be a little over 13gbps (415 million pixels x 32 bits/pixel).
That said, my idea might still be do-able... assuming the left and right frames are relatively similar, you could get lossless compression approaching 2:1 right off the top, reducing it to ~6.5gbps. Converting the video to 4:2:2 YUV with 2-4 bit RLE-compressed alpha-blending should easily chop at least a third of that away, getting us down to 4gbps. Dropping back to 4:2:0 color for the first frame after a radical scene change and referencing the previous frame can probably get us down to 2-3gbps. It would probably mean we'd have to do all the local image-recognition onboard instead of streaming the onboard cameras directly to the remote host since we'd already be maxing out the best-case USB bandwidth, but it should still be do-able since that would be just about the only thing (besides rendering the remotely-streamed video directly to the screen in the Quest, possibly after overlaying it on the local passthrough video in a genlock-like manner) we'd have to DO on the Quest itself.
So... I think my idea might still work, but only if the Quest's USB interface really, truly can sustain 2gbps at the bare minimum, and would be risky unless it could reliably sustain 4gbps.Any lower bitrate, and we'd probably have to forget about uncompressed (or lightly compressed) video from the host PC (or at least, settle for major visual artifacts whenever there's a radical scene change, since we'd only be able to reference past frames without adding latency and any completely new frame would be limited to the data we can fully transfer within 1/90th of a second)
Or built 802.11ad ("WiGig") into the Quest, and allowed anyone with a suitable access point (or PC via peer-to-peer) within 3-10 meters in the same room to basically stream 90fps uncompressed video directly to it with minimal latency. From what I understand, short-distance line of sight 60GHz 802.11ad is capable of easily sustaining 4-6gbps with a minimal implementation, potentially faster with a more sophisticated implementation.
Assuming my math is correct, 1440 x 1600 x 2 x 4 x 90 = 1.659gbps. With 4-6gbps to play with, there's plenty of headroom left to stream the Quest's own video and sensor data straight back to the host PC (without delay or compression).
If I understand correctly, and the Quest's own cameras can be used to capture eye-level stereo video suitable for passthrough AR, having 802.11ad onboard would also potentially enable you to do something like this:
* Grab a pair of raw video frames at the camera's fastest framerate, plus all the sensors that the host PC has subscribed to.
* Throw them across the network at the host PC without compression for it to use for things like object/gesture-recognition.
* A moment later, the next pair of frames arrives from the host PC (either without compression, or some low-latency mostly-lossless fast compression that only compresses the delta between the left and right frames), with 8-bit alpha channel. Merge them with the most recent local passthrough frames, and display them.
The advantage of doing genlock-type overlaying of PC-generated video with locally-captured passthrough video is latency... when doing passthrough VR, even a single frame of latency is painfully noticeable, and two or more is downright nausea-inducing. By keeping the passthrough-AR video's processing realtime and local, you could shave the frame or two of latency you'd otherwise end up with if you had to wait for it to get to the host PC, get edited into the next frame, then get sent back.
Remember... with VR, and even moreso with passthrough AR, latency is EVERYTHING. Anything you can do to reduce it is going to profoundly improve the user experience. If you're going to just overlay remotely-generated content into video captured locally ANYWAY, it makes no sense to add the latency of sending that local passthrough video to the remote PC just so it can be edited into the scene and transmitted right back. The Quest has more than enough horsepower to do THAT job locally.
Anyway, that's my view. 802.11ad has plenty of bandwidth to stream high-framerate video with minimal latency in both directions, so you'd get the best of both worlds... you could use the Quest's own processor to do locally things that would take longer to roundtrip, while nevertheless offloading the really heavy lifting to a PC across the room that's as powerful as it needs to be to do whatever you want.
Now, the good part. IF (big "if") the Quest actually has a USB 3 port with enough bandwidth to sustain anything close to 2gbps+, and Oculus exposes enough functionality to allow a thirdparty to pull it off, some thirdparty (or grad student looking for a cool thesis project) could conceivably make their OWN 802.11ad interface for the quest, and do exactly what I've described. Say, built around an off-the-shelf 802.11ad mPCIe module, in a belt/pocket-mounted case the approximate size of a RasPi with its own battery, connected to the Quest via USB. Ideally, the Quest supports being a USB host... but even if it doesn't, implementing the module as a USB host and connecting to the Quest via OTG isn't all that big of a hurdle. The biggest unknown is whether the Quest's USB implementation is actually fast enough to sustain the kind of transfers using an external 802.11ad card would require.
I'll believe realtime raytracing -- classic, physically-based, or otherwise -- has really arrived when a future version of Windows gives us everything Aero was supposed to have been in the first place, including accurately-blurred semi-translucency with refraction, crystal-like window chrome, and everything else. Not faked translucency, but literal "window content is rendered onto semi-translucent dark smoked virtual glass, with obscured content that's somewhat visible through it accurately updated in realtime". And does it on a row of three 3840x2560 desktop-extending displays at 120fps with zero glitches or slowdown.
I don't think that's too much to ask for. If a game can do 4k at 144fps with water effects, accurate shadows, and 400 moving elements, is it REALLY expecting too much for Windows to be able to run Word with a vaguely-translucent milky-white background that vaguely hints (accurately) at the scrolling output from a command prompt running behind it while making the window chrome sparkle with faux diffracted light?
At the moment, the best passive long-term storage medium we have is the original (high-to-low) standard for single-layer BD-R.
Note this is NOT the newer & cheaper "low-to-high" (LTH) standard that came out a few years later.
HTL starts out as a shiny substrate that gets melted & dulled by the laser. LTH uses organic dyes (like DVD+/-R) that fade over time, especially if exposed to light or heat.
Players capable of reading them might not be common cheap consumer items 25-100 years from now, but they absolutely WILL exist as items for libraries, universities, governments, etc (so they might not be CHEAP, but they'll definitely exist & be reasonably available).
Avoid multi-layer discs. Lower layers START OUT with (recoverable) errors, and only get worse over time.
The main advantage of HTL (non-LTH) BD-R is the fact that it decouples the reading apparatus & electronics from the media. If your only copy of something is on a 40 year old SATA hard drive that no longer works, you're going to spend an UNHOLY amount of money to recover the data... if it can be recovered AT ALL.
Flash storage is COMPLETELY unfit for long-term storage... it's like a leaky bucket. And newer flash is LESS long-term stable, because the margin for error in MLC flash is a fraction of what it was with SLC flash.
By all means, keep additional backups in the cloud or on hard drives... but if you have to gamble everything on a single media type, go with HTL (non-LTH) BD-R.
Also... use common, open, well-documented & non-proprietary formats. Think twice about using encryption & ask whether you'd be more traumatized by disclosure or permanent loss... and assume the lesser evil you choose WILL happen.
Assume anything that's DRM-protected is likely to be gone in the long-term... by obsolescence & obscurity, if not outright disappearance.
I think the IPv6 privacy extension goes a step further & shares a short privacy prefix among a large number of the ISP's users... so you, as the customer, would get TWO prefixes:
* a 48-64 bit prefix that's either fixed, or at least infrequently-changing
* a much longer prefix with a much shorter lease, from among a short prefix shared by a large number of users, to use for tasks like anonymous web-browsing.
That said, I think I remember reading that many US ISPs currently take the middle ground... they assign a 56-64 bit prefix, and have a web proxy available for customers to optionally use for privacy-sensitive traffic that does address-scrambling. I think the push for doing it at the IP level is to satisfy government logging requirements. With the proxy approach, the ISP has to log (and retain) literally every http request (or at least, the origin, destination, and timestamp). With the IP approach, the ISP only has to log the IP assignments (lowering the compliance storage burden enormously).
> Please focus on solutions that work for everyone.
Nothing EVER literally works for "everyone"... but if you really want to be pedantic about it, the app is for user convenience.
If push really came to shove, even somebody with a https://en.wikipedia.org/wiki/... could call their telephone service provider's customer service number to generate and obtain another batch of 10-25 40-digit numbers assigned to their phone and write them down on a page of the phone's paper "phone book" using its included pencil... crossing them off the list (ideally, with a note indicating whom they assigned the number to) as they use them one by one.
Or, someone could buy a million randomly-generated phone numbers, print them into 10,000 booklets of LITERAL "one time pads" with 100 of those numbers apiece, and provide a customer service number on the back that the purchaser could call to instantly associate the 100 numbers in that book with their "real" phone number. Maybe print 5 numbers per credit card sized perforated tear-off sheet, so the buyer could rip of a sheet at a time & carry it in their wallet to use as the need for a number arises.
The point is, it's 2019, and even someone who's dirt poor can buy a piece of shit throw-away Android phone at Walmart for $30... or get one that's practically free from a pail at a flea market or Goodwill store.
There you have it... an entire spectrum suitable for 99% of people who care enough about avoiding unwanted calls to at least lift a finger and do something about it, ranging all the way from convenient apps to numbers written on scraps of paper.
> Obviously the fail here is when they start using your known contacts that were leaked out by social media and other parasites
That's the beauty of giving everyone a different number to call you at... if the phonebook of a friend or relative gets inhaled by malware, all that's been compromised is LITERALLY a single phone number used by exactly one person to call you. It's a lot easier to nuke a number used by only one person to contact you and give them a new number to reach you at than to change your One and Only phone number and update everyone ELSE to use it instead.
This is why I started using adhoc email aliases more than 15 years ago... everyone who emails me gets a different address to reach me at. Part of my reason for starting to use adhoc aliases was precisely the fact that people like my dad kept getting their addressbooks vacuumed up by malware and ruining my email addresses by disclosing them to spammers. The solution was to limit the scope of damage from any one addressbook-slurping to an address used by exactly one person. If a business extorts my email address from me and starts spamming me, I don't have to bother asking them to stop emailing me... I just add the alias to my mail server's nuke list, and future email from them gets blackholed directly to /dev/null.
As an alternative, they could possibly extend SS7 so that it uses the first {n} digits to ROUTE the call, but PRESERVES and PASSES ALONG an additional {x} digits as the tail end of the caller ID string so people could treat those additional digits as customer-defined routing codes, inbound-ring passwords, whatever. It would only be used by tech-savvy users for a few years, but eventually someone like Apple or Verizon would start selling services to intercept inbound calls and decide how to handle them based upon the additional digits dialed along with the number itself. The only catch to make THIS work would be the need for a federal regulation requiring that any business that DEMANDS the disclosure of a phone number be capable of accepting registrations with the additional digits (put another way, a shitty web site that just wants a phone number for no specific reason and doesn't actually REQUIRE you to provide a number could still get away with only allowing 10-digit numbers, but someone like Domino's, Uber, Citibank, or whatever who won't allow you to proceed with registration or an order without disclosing a valid phone number would be required by law to accept those long numbers).
Building on random-dialing prevention, they could set aside all the 40-digit numbers so that attempting to dial an invalid number cost the caller 10 cents, but dialing a valid number was free. That alone would quickly reduce random dialing by telemarketers by destroying the profitability of dialing random numbers.
The only way keeping your phone number a secret might reduce spam calls is if the current successor to NANPA (Neustar?) takes a currently-unused areacode, then uses it as the prefix for a random 40-digit phone number (approx. number of decimal digits in the largest unsigned 128-bit value), then allows consumers to link an unlimited number of randomly-picked numbers to your "real" one (and allow you to know what number an incoming call dialed, so you could program your phone to ignore incoming calls to your "real" number, but allow incoming calls to one of your incoming 40-digit numbers to ring).
Then, whenever you had to give someone "your number", you'd peel an unused 40-digit number from the metaphorical stack & give it to them (probably, via an app running on your phone).
If a specific incoming number of yours started attracting too many junk calls, you could unceremoniously nuke it & unlink it from your real number. Likewise, since you'd give a unique inbound number to everyone, you could do 'traitor tracking' & punish businesses that failed to safeguard your number.
Random dialing would cease to work, because a robocaller could literally try random numbers for HOURS before hitting a valid one... especially if the system were designed to detect and frustrate such attempts.
The same service could reserve the shorter numbers (say, 12-16 digits) for more public purposes. Say, I might buy a 16-digit number & post it to social media after linking it to a service that charges callers $20 to complete the call (if I answer) & pays ME $15 for answering it if I agree to talk to the caller for at least a minute. We could ALL have the equivalent of 1990s-era 900/976 numbers to give out to the public & use dollars as a tool for screening our calls. I might even set up one number with a $5 charge explicitly FOR telemarketers to call me at, agreeing to give them 5 minutes of my time in exchange for paying me to listen.
Or... I could point one number to a bot that answers the call, then makes the caller play "Simon Says" & spend 10-20 minutes answering captcha-like puzzles for the privilege of making my phone ring (or the privilege of leaving me a message) for free.
If you read the article, the summary omits a very important detail... he spent most of his time with a headset that had a live video feed of his surroundings. So, he didn't spend a week in "VR" as much as spend a week with a simulated visual impairment.
This is important. If you involuntarily spent an entire week immersed in a true immersive VR environment, you'd either become VIOLENTLY ill, you'd experience a literal dissociative psychotic break after a few days, or both. Seriously, read the descriptions of what it's like for someone who's relatively "VR-adapted" to take off the headset and feel oddly disconnected from their seemingly "unreal" physical surroundings for a while... then compare that description to the symptoms of depersonalization/derealization disorder.
I mean, it's a damn good thing modern-day VR didn't exist during the Cold War, let alone Nazi Germany. I honestly think being involuntarily restrained and fully-immersed in an intentionally-malicious VR environment designed to fuck you up as badly as possible would be worse than sensory deprivation. The sad fact is that intense, fully-immersive virtual reality is kind of like being in a relationship with an abusive spouse you can't bring yourself to leave because you also have so much fun together.
If you think you're immune to VR sickness, get an Oculus Go and try playing a game like immersive first-person VR Quake for an hour. And if by some miracle THAT doesn't get you sick, try playing the "ISS" game... but move around smoothly using the D-pad instead of lurching from grab-bar to grab-bar or teleporting.
This is why I'm such a huge fan of mixed and augmented reality... mixed/augmented-reality doesn't make me get sick. My brain can deal with having things synthesized and anchored into my surroundings... it can't deal with the sensory assault of having my senses in total contradiction. IMHO, immersive virtual reality that doesn't involve using cameras to transform it into augmented reality is an evolutionary dead end. With immersive VR, every sensory problem you solve just creates 5 NEW (and worse) problems. With mixed reality, you can abseil through the uncanny valley and laugh at the contradictions. With fully-immersive VR, it's more like parachuting into the uncanny valley while getting shot at with real bullets.