Touchpads wouldn't be so awful if they at least emulated thumb-trackballs like mid-90s laptops did. Sometime around 1999, they all quit emulating trackballs & started being optimized for use by an index finger (instead of a thumb). Why can't manufacturers at least expose the raw touch data, so a custom driver could give us back faux-trackball ballistics?
Example of thumb-optimized ballistics: recognizing that the thumb isn't equally-agile in all directions... straightening out arcs, spreading out horizontal motion vs vertical motion, etc.
Exactly. Your monitor goes from looking like a really high-res computer monitor, to looking like the brightly-illuminated output of a laser printer. My Nexus 6P has a ~480dpi screen, and I've gotten so spoiled by razor-crisp text, 200dpi text on a more average tablet now makes my eyes feel like they're bleeding.
I actually bought a Chuwi Hi12 (2160x1440 12" display) JUST to use for ebook reading, because I couldn't stand to read ebooks on my older tablets anymore. It's a little too heavy to use as a "tablet" per se, but for reading pdf ebooks 2 pages at a time, it's *awesome* (at lower budgets, I'd recommend the Teclast x89 Kindow, which is the tablet I use for normal "tablet" tasks... it's under a hundred bucks, really light, and has a beautiful 1080x1440 3:4 display that's almost exactly the right aspect ratio for reading single pages of a pdf ebook... the hi12 is basically like having two x89 tablets side by side). Another decent tablet is the Teclast x98 pro... I almost bought one before discovering the Chuwi Hi12. As of late November, a x89 went for around $90 (I bought mine for ~$65 on eBay), an x98 Pro w/64gb went for around $150, and I paid around $230 for my Hi12. My only complaint about the Hi12 -- its clip-on keyboard SUCKS. The Hi12's active stylus is definitely worth $10-20, but the keyboard was a total waste of $50 (mostly because it misses keystrokes all the time). I'd still buy the Hi12, but wouldn't have bothered with the keyboard.
Actually, virtual reality needs higher resolutions, but it needs higher framerates even MORE. 60fps is enough to produce fluid video when passively watched (though synthetic video still needs some amount of added motion blur to be really convincing), but it's absolutely NOT fast enough for immersive video. When there's at least 1/60th of a second lag between your hand's motion and seeing your virtual hand move, you'll DEFINITELY notice the lag. 1/60th second lag feels, well... "laggy". 1/30th second lag feels downright sloppy.
Human vision is hard to quantify. Your foveal vision (generally, color from cones) is relatively low-res and low-framerate, but your peripheral vision (generally monochrome from rods) is EXTREMELY sensitive to framerate at high contrast (as in, you have to be up around 300-600fps before it really, truly starts to become a non-issue for all users). And although your foveal vision is almost entirely cones, some people DO have enough foveal rod cells to act like pseudo "cyan cones" with the same contrast and motion sensitivity they'd have as peripheral vision (proof: over the years, researchers have found at least 2 or 3 men who appeared to be anomalous protan trichromats, but were REALLY deuteranopes with enough foveal rod cells to act like pseudo-"green" cones under the right lighting conditions). This is also why marijuana can sometimes make colors appear to be "psychedelic" -- it enables rod cells to continue functioning in brighter light than they normally would, and they start to act like cyan-sensitive cone cells. In other words, the stoned individual is temporarily "kind of" tetrachromatic, and perceives it as "seeing weird colors".
100-150fps is a definite step up from 50-60fps, and a quantum improvement over 24/25/30fps. You can absolutely see the difference, even if you view them sequentially. This is also roughly the point where your eyes make their own motion blur, and you can stop worrying about having to create it in the source video itself.
300-600fps is the next major step up, though at THIS rate you might have to see a simultaneous left/right comparison to accurately notice the difference. From what I've read, this is actually the point where you start falling into the uncanny valley. At 300-600fps, your eyes will blur frames together, but anomalies in motion from frame to frame will start to become "creepy". Basically, your eyes are telling your brain that you're seeing a real, live scene... but tiny parts of it aren't quite moving in PRECISELY the right way to BE a real, live scene.
With a 55" TV, the biggest benefit comes from having 4K **content** and a good scaler. By the time 2160p24 gets compressed down to something Netflix can handle, you MIGHT end up with the PQ of real, minimally-compressed 1080p24. Basically, 4K shaves away the shittiness that has gradually crept into mainstream "2k" HD video.
For an illustrative example, think about a non-HDTV with s-video input and either cable or satellite TV. You can feed it a "SD" channel, or you can feed it a downrezzed "HD" channel. The TV might not have the resolution or bandwidth to take full advantage of HD, but the downrezzed HD channel will STILL look at least twice as good as the native SD channel.
Put another way, we'll need "8k" HD to give us the PQ of uncompressed "4k", the same way we now need "4k" HD to give us the PQ of uncompressed "2k" HD. It's always better to get your own copy of the "good" source and do your own downrezzing locally, because when you delegate the downrezzing to the TV content provider, they'll always and invariably cut even MORE corners and make it look like shit by the time it gets to you. You can always throw away unnecessary detail, but once it's gone you can never really get it back. Just TRY watching live 1080i60 on a LCD... it'll either get BOB'ed down to 1920x540, or you'll get to see two footballs moving across the screen. Deinterlacing works for film content because it's 24fps duplicated 2 or 3 times to get 60fps. Deinterlacing fails MISERABLY for NATIVE interlaced content, because THEN you're trying to synthesize real detail that's gone forever... and trying harder just creates weirder and weirder artifacts (like things that YOU KNOW went away magically reappearing, because the video processor has no knowledge of context, and just knew that something appeared in that area a few frames ago).
Frankly, I don't really understand why cable and satellite companies even still BOTHER delivering SD channels, instead of just having the box downrez the HD channel locally. It's not like it's hard or expensive to do anymore, and it would free up hundreds of megahertz of spectrum (or dozens of satellite transponders) and make room for things like 4k, 3D, etc.
To a certain extent, Google HAS been isolating more & more potentially-vulnerable libraries used by the OS itself into packages that can be updated through Google Play (like WebView). Kernel-level stuff still requires manufacturers to fix, but Google can fix a newly-discovered Javascript vulnerability and deploy the fix to semi-recent devices all by itself.
I'm not totally sure where the AppCompat library/framework fits in... I think it's statically compiled into the.apk at build time, but I'd be shocked if it didn't delegate most of its actual work to a component that's updatable via Google Play.
That's because dropping what you call "legacy support" would have erased their main advantage over ARM -- raw balls-to-the-wall no-compromise performance. In car terms, an i7 is like a maxed out Tesla Model S P90D with "ludicrous mode" switched on... by comparison, an ARM is like a Chevy Volt.
Also, a CRT capable of only 480i60, 480p60, and 1080p60 can cut corners that would be impossible to cut on a true multisync CRT. I'm not 100% sure, but I think CRT HDTVs line-doubled 480i60 to treat it like 480p60, and padded both to give them 1080i60 timing to avoid the expense & complexity of PC multisync monitors. In other words, most CRT 1080i60 HDTVs displayed ONLY 1080i60, and relied on their scaler to turn 720p60 into 540p60 (the REAL reason why 720p60 appeared to have such low resolution compared to 1080i60... almost a third of its detail got thrown away, then half of its temporal detail got thrown away.)
Not exactly... there's not enough bandwidth to stream 2160p60 that's captured & compressed in realtime for live tv, but 2160p24 would be *totally* achievable with ~19mbps if ATSC allowed h.265 with long GOPs & you did the compression offline.
The REAL reason ATSC doesn't allow 1080p60 is that RAM was *horrifically* expensive back in the early 90s, realtime compression of 1080p60 was still just an engineering fantasy, and both broadcasters & TV manufacturers opposed making it something all receivers *had* to be capable of decoding. Most broadcasters were totally in the 'interlaced' camp, and even 720p60 was a tough sell to CRT manufacturers (I think Monivision made one of the very, very few 32"+ 720p60-native TVs). Why? Because 1080i60 is equivalent to 540p60 as far as a CRT is concerned, and not much more demanding than 480p60 (~34MHz bandwidth vs ~31MHz bandwidth). However, 720p60 required ~45MHz, and 1080p60 would have required a staggering ~65MHz of bandwidth... simply put, a CRT capable of 1080p60 would have been VERY expensive compared to one that can only do 480i60, 480p60, and 1080i60.
The problem is, your health insurance would just add a clause giving them priority for any revenue from your organs. So if your final bill came out to $120,000 (with $24,000 co-insurance, but limited to $5,000 out of pocket) & your kidneys earned $20,000, your family would be *lucky* if it saw a cent, or even got to at least apply the first $5,000 of it towards the deductible, instead of having the insurance company swallow the whole amount by claiming your final bill cost them $115,000 after applying your coinsurance payment.
Custom characters were actually quite easy to do on the Vic-20 and C64. Hell, I didn't even understand the concept of binary at the time (I was in 5th grade). I just knew that you took a sheet of graph paper, drew a box around an 8x8 area, wrote "128, 64, 32, 16, 8, 4, 2, 1" at the top of each column, and added them up to get the row's value.
In fact, the Vic-20 didn't actually have a traditional "bitmap" mode. To kludge it, you put it into a mode where it used 8x16 characters instead of 8x8 characters, then wrote them to the screen in a 21x12 or 22x11 grid (character 0, then character 1, then character 2, and so on until you got to character 256), then poked directly into the custom character definition block of ram to set the individual pixels. It wasn't commonly done, though, because a stock vic-20 didn't have enough RAM to pull it off, so you had to have at least one ram expander (and if that ram expander wasn't the 3k version or a Super Expander cartridge, you also had to deal with the video ram getting moved to another block of addresses). Or you had to leave the characters as 8x8 instead of 8x16, and limit your pseudo-bitmap area to whatever dimensions you could kludge out of 256 8x8 characters.
Now... multicolor characters were another matter entirely. I'm kind of ashamed to admit that I never really understood how to use them at the time, and it wasn't until years later that I looked back at a book on c64 programming and thought, "oh... THAT'S how they worked..."
(Confession: it wasn't literally my first Vic-20 program... it was the first program I wrote on MY Vic-20. I'd actually been playing with my best friend's Vic-20 for months at that point)
~35 years ago, I got a Vic-20 for Christmas. It took me an hour to write my first program, including the custom character design. Today, if you got a new Dell laptop for Christmas, you'd be lucky if Windows Update finally allowed you to even *do* anything within the first hour or two. Fuck, even a brand new Xbox One or Wii-U (and probably a PS4) will make you wait at least 30-60 minutes for mandatory updates before it'll allow you to play your first game.
Replacing a screen has a hard cost to LG of a few hundred dollars for the replacement part. Putting a flashdrive image on a ftp server with instructions for using it has per-tv marginal costs approaching zero.
> I mean Android is just a use of an OS kernel and some standard services, including application security, and some UI conventions.
And Google's very, very proprietary, non-opensource, and defacto-required (if you don't want your phone to be crippled) Google Play Services, which are required for installing apps from Google Play, using Google Maps, using Google-assisted location services, Google Pay, and plenty of other things. Over the past couple of years, Google has been systematically moving more and more of Android's core functionality into Google Play Services.
Yep. Most people don't realize that NOT EVEN NEXUS DEVICES have official buildscripts available to create a ROM with everything in the official factory ROM (including binary blobs that aren't open source). You can build and install generic AOSP, but generic AOSP is a subset of what's part of an official Nexus 6P ROM. AOSP on a Nexus 6P is no better than it was on the Galaxy S3 (IMHO, the S3 was the Golden Era of AOSP, and the closest we ever got to being able to flash a semi-device-nonspecific ROM the way you'd boot Debian or Ubuntu on a PC... almost everything since the S3 has been a slide downhill compared to what we had).
Much of the recent blame should be placed on the new universality of using SSL/TLS for everything.
The problem is, negotiating a cold SSL/TLS handshake from scratch takes a certain amount of time... and there's very little you can do to speed it up with current standards. Adding certificate-revocation lookups compounds the problem and adds even more time. In the past, a site that "used SSL" might need to do one or two key exchanges for one or two different hosts. Now, a single page might require a dozen or more key exchanges... and some of those key exchanges might not even be known by the browser to be necessary until after it's done the first few (because some script delivered via https references some other asset via https on a different host).
SSL/TLS itself is generally a good thing... but the WAY it's currently being used was NEVER seen as a realistic use case 20 years ago when it was first implemented. Simply put, SSL/TLS key exchange and CRL doesn't scale well in their current form.
This is also part of the reason why it's so common to end up with "five bars of LTE signal strength, but no working data-connectivity" -- mobile apps are "chatty" to begin with, and many of them do a shit job of keeping https sessions alive between requests, so every single background https request requires yet another new handshaking and revocation-lookup. In areas where you have a cell site with limited backhaul connectivity and occasional surges in the number of users (say, a cell tower near a large state park serviced by only a T-1 line or two... on July 4th, when 60,000 people might descend on the park for a few hours), the endless key exchange traffic ITSELF can almost fully-saturate the tower's backhaul capacity.
Spoiler: he showed the guy's adult selfies, online dating profiles, Google searches, and more. The moral: if you want to keep your data safe, use robust encryption and access security. If you'd rather get your computer back (or at least, hours of entertainment at the thief's expense), configure it with auto-login (so the thief won't even BOTHER to reinstall the OS) and remote control software w/DDNS client.:-D
CDMA2000 does, in fact, have an official SIM-like standard: the USIM, which is a literal superset of the GSM SIM card standard that has CDMA's own R-UIM card grafted onto it. The catch is, Qualcomm made it an optional part of the standard, and Sprint & Verizon were perfectly happy to pretend it didn't exist. Ditto for Telus in Canada, which was (at the time) a wholly-owned subsidiary of Sprint with identical phones and policies (but they STILL wouldn't let you use a Sprint phone on Telus, or a Telus phone on Sprint... they could roam on both networks just fine, but neither network would allow you to actually sign up for local service using a phone from the other country AS your "real" phone).
Elsewhere in the world (New Zealand, Australia, Singapore, India), you could ABSOLUTELY buy non-carrier-branded CDMA2000 phones, get a R-UIM or USIM card from your carrier, and use it as effortlessly as using a GSM phone on a GSM network.
As a historical quirk, there WAS actually one popular Sprint phone that had a R-UIM socket (or at least a place to solder one) that was covered by a black sticker -- the HTC PPC-6700. Apparently, they had a brief second life of popularity in India after someone figured out they could buy old (or new old stock) American PPC6700s for a pittance, hack them slightly, and sell them as fully-working phones in India (at a point in time when phones running Windows Mobile were OUTRAGEOUSLY expensive in India, and WinMo CDMA phones like the PPC6700 basically didn't officially exist at all)
One small detail -- Chinese is AT LEAST as genderless as English. It's one somewhat unique feature both languages got RIGHT. The only real advantage English has over Chinese re: gender is that English might make it slightly easier to be intentionally vague about a PERSON's gender. Neither language has silliness like "boats are female (unless they're submarines), chairs are male, and teenage girls are neuter". Or that radio is male if it's an electronic device, but female if it's broadcast content.
Dude, do you have *any* idea how robust encryption schemes like AES, and hashes like SHA are?
Not even the NSA has the resources to bruteforce 128+ bit AES or 256+ bit SHA. If the NSA worked hand-in-hand with their Russian, Chinese, and Israeli counterparts and threw literally every computer resource at their disposal at bruteforcing AES or SHA, they MIGHT have ~50% likelihood of success after 10-25 years IF they managed to discover some as-yet undiscovered weakness. Not even organized crime, buying 100% of Amazon's on-demand computing power, could hope to bruteforce either scheme within any viable timeframe.
Modern encryption doesn't get cracked by bruteforcing keys... it gets cracked by bruteforcing people or devices with ACCESS to the keys (say, pointing a gun or court warrant at them, or obtaining physical control of a PKI hardware key's container).
This is NOT a trivial problem that script kiddies can defeat between classes and WoW tournaments. Even SHA-1 has been "compromised" only to the extent that someone with substantial resources and good luck could discover a meaningless pseudorandom chunk of data that produces the same hash as the original hashed data.
FPGAs (and GPUs) can radically compromise "Proof of Work" algorithms like Blowfish, but that's ONLY because those algorithms made assumptions about resource scarcity that Bitcoin miners have been highly-motivated to surpass. AES & SHA(-2) are entirely different beasts... THEIR hardware constraints & key length move the time scales to "longer than the Earth has existed... or with as-yet nonexistent hardware, maybe the length of recorded human civilization."
Unless it transmits a cryptographically-signed VIN as part of the broadcast, and receivers log that VIN to some kind of persistent storage if they rely on its data. It wouldn't necessarily prove that a specific INDIVIDUAL is guilty, but it could ABSOLUTELY pin financial liability on the owner of the vehicle associated with that VIN for negligently allowing a car he owns to spoof bad data.
I know that in Florida, you can't get license plates without registering the VIN, and I'd be shocked if any state DIDN'T require VIN-registration as a condition of getting license plates.
Since realtime certificate lookups are obviously out of the question, they'd probably issue certs good for a year at a time simultaneously with license plate renewal, and cars would be programmed to either ignore, or at least seriously question the validity of, expired certs.
China's dialects and writing systems work quite well. They're just optimized in slightly different ways than English.
English has lots of what computer scientists would call "forward error correction" -- you can really, REALLY fuck up and mangle English, yet still be understood. In contrast, you could say that Chinese has built-in spatial & temporal data compression... at the expense of error-tolerance.
For an understanding of how tones work, think about all the different meanings the word "fuck" can have depending on how your pitch changes. Chinese tones are just a systematic way of describing those pitch changes.
Likewise, Chinese is notoriously hard to *write*, but can actually be slightly easier to *read* than English (at least, if you're comparing difficulty for semi-illiterate native speakers).
IMHO, 100-500 years from now, English will be the planet's dominant language, but it will probably have imported a few hundred one- and two-character words from Chinese (with 'man', 'woman', 'year', 'month', and 'day' being among the first ones) and use them the exact same way Japanese uses kanji -- as an alternate, more compact way to write common words that could be legitimately written using an alphabet.
The truth is, you can learn to read and write more than 100 Chinese words in just a few hours. Once you know how to write 'one' through "seven", you only need to learn the character for 'day' to name the days of the week. Learn "eight" through "12" plus the character for "month", and you can name the months in a year. You can even cheat & use arabic digits, effectively learning to name 19 days+months with just two learned characters. Contrast that with the mess we have with English day & month names. In some ways, Chinese has elements of logical order that English lacks.
TL/DR: The Chinese language works perfectly well for people in China.
The real problem is that any VR that's hobbled by 60fps video will *never* feel interactively-immersive. 60fps is enough to appear smooth for passive viewing (when augmented by appropriate motion blur), but feels sloppy & laggy if it tries to be immersive & track your real-world gestures. 120-240fps is the point where latency becomes acceptable, and your own eyes provide the moton blur.
Not really. If oil were replaced by a true "global power grid", US dollars would simply become the currency of choice for buying & selling it.
The value of a US dollar is mainly its liquidity... you could walk into a bar or open-air market in the most backwards country on Earth and buy almost anything with US dollars. Even in Europe, if you walked into a random McDonalds, you could probably find someone in line who'll HAPPILY sell you a 10-Euro note for US$20 by the time it was your turn to order.
Currency exchange is expensive, so companies try to trade in US dollars AND KEEP THEM STORED as US dollars whenever possible. When an American buys something for 200 Euros on his Citibank Visa card, and a European buys something for $200 with HIS Citibank Visa card (or some national bank that's owned by Citibank anyway), Citi doesn't buy $200 worth of Euros at market rates and 200 Euros worth of Dollars at market rates... it CHARGES both cardholders as if it did, but REALLY just keeps the Dollars as Dollars, and Euros as Euros, unless it literally runs out of one or the other & can't borrow the shortfalling currency for less than the exchange rate. At worst, our hypothetical 200 Euro & Dollar transactions MIGHT result in ~$40 actually being exchanged.
THAT's why the US Dollar is dominant... you can buy goods and services with it almost anywhere AND often pay less than if you'd uses that country's official currency.
We *already* have the tech to flawlessly replace CRTs with no compromises besides sacrificing flatness & light weight: bright OLED light engines projecting onto much larger screens. Think: DLP or LCoS-type RPTVs, but with a 10-20" OLED projection source instead of a 2" chip that either reflects or filters light from a bright halogen bulb.
There's also FED, which literally EVERYONE circa 1995 expected to be the next core display technology (basically, take a sheet of r/g/b phosphor-coated glass, then put a solid-state electron emitter behind each subpixel (so that instead of having one powerful electron beam that sequentially refreshes row by row, column by column, you have a few MILLION weak (but individually-addressable & continuous) electron beams. FED's main drawback is energy use... it draws as much power as a comparable CRT, so it's unsuitable for portable devices.
LCDs are truly a technology that *nobody* seriously expected to become dominant for anything besides laptop displays, precisely because they suck so badly at things that CRTs (and 3-laser DLP, and FED, and projected OLED) can all do well, at the trade-off of maybe a foot or two in depth, or a few hundred watts of power draw.
Personally, I'm keeping my kick-ass 3-laser DLP TV until 120fps finally kills it (even if it can't do "4k", a suitable scaler allows 3840x2160 to be scaled down to high-bandwidth uncompressed 1920x1080 that will look 98% as good as 'true' 4k, because TODAY's "1080i" is now compresed to the point where it's achieving less than HALF its theoretical potential. Just compare the picture quality you get from a 20 year old CRT displaying 720p60 content through a scaler via s-video to the PQ that SAME TV used to have with broadcast TV. The difference? 20 years ago, it was displaying a video source with ~3-5MHz bandwidth. Now, it's scaling a video source with 45MHz bandwidth (720p60) down to maxed-out s-video's ~12MHz of bandwidth (~16MHz, if you hacked the tuner to take component video 480i60). Basically, compressed "4k" TV ends up having as much/little REAL detail & PQ as fully maxed-out balls-to-the-wall ~50mbps 1080i60 does (BROADCAST 1080i60 is limited to 20mbps, but HDMI 2.0 can deliver raw 4:4:4 RGB at more than twice that rate without breaking a sweat.
Is it *really* that big a deal outside the sealed & laminated Apple universe to just stick a mPCIe slot on the mobo's underside, cover it with a tiny hatch, and pre-embed suitable antennas for it in the display & run the wires to that same hatch/slot? Most mid+ end laptops *already* have an extra mPCIe slot (though only high-end corporate laptops usually advertise it as a feature & make it officially accessible for things like cellular modems... in most mid-range laptops, it's more like a forgotten, semi-vestigial socket that exists only for factory-installed modules).
The truth is, unless the laptop mfr is an asshole & explicitly locks out "unapproved" mPCIe cards in the UEFI BIOS, as far as Windows & Linux are concerned, they're just normal 1x (4x?) PCI Express slots waiting to be used for something (warning: MANY such slots can work as EITHER mSATA or mPCIe, but the two DO have different pinouts despite having the same form factor & connector... if they don't support mSATA, you'll need a MUCH more exotic & expensive mPCIe SSD with embedded SATA controller like the ones Apple uses in iMacs for flash/ssd or fusion drives).
Likewise, most gaming laptops w/discrete video cards use cards that are electronically-compatible... what makes them proprietary is the fact there's no real standard for dimensions, hole-placement, or cooling of laptop video cards, so you could end up with a laptop that can use an arbitrary video card, but will cook it in seconds, not allow it to be properly mounted, or not have enough room for it).
Slashdot Mirror
Touchpads wouldn't be so awful if they at least emulated thumb-trackballs like mid-90s laptops did. Sometime around 1999, they all quit emulating trackballs & started being optimized for use by an index finger (instead of a thumb). Why can't manufacturers at least expose the raw touch data, so a custom driver could give us back faux-trackball ballistics?
Example of thumb-optimized ballistics: recognizing that the thumb isn't equally-agile in all directions... straightening out arcs, spreading out horizontal motion vs vertical motion, etc.
Exactly. Your monitor goes from looking like a really high-res computer monitor, to looking like the brightly-illuminated output of a laser printer. My Nexus 6P has a ~480dpi screen, and I've gotten so spoiled by razor-crisp text, 200dpi text on a more average tablet now makes my eyes feel like they're bleeding.
I actually bought a Chuwi Hi12 (2160x1440 12" display) JUST to use for ebook reading, because I couldn't stand to read ebooks on my older tablets anymore. It's a little too heavy to use as a "tablet" per se, but for reading pdf ebooks 2 pages at a time, it's *awesome* (at lower budgets, I'd recommend the Teclast x89 Kindow, which is the tablet I use for normal "tablet" tasks... it's under a hundred bucks, really light, and has a beautiful 1080x1440 3:4 display that's almost exactly the right aspect ratio for reading single pages of a pdf ebook... the hi12 is basically like having two x89 tablets side by side). Another decent tablet is the Teclast x98 pro... I almost bought one before discovering the Chuwi Hi12. As of late November, a x89 went for around $90 (I bought mine for ~$65 on eBay), an x98 Pro w/64gb went for around $150, and I paid around $230 for my Hi12. My only complaint about the Hi12 -- its clip-on keyboard SUCKS. The Hi12's active stylus is definitely worth $10-20, but the keyboard was a total waste of $50 (mostly because it misses keystrokes all the time). I'd still buy the Hi12, but wouldn't have bothered with the keyboard.
Actually, virtual reality needs higher resolutions, but it needs higher framerates even MORE. 60fps is enough to produce fluid video when passively watched (though synthetic video still needs some amount of added motion blur to be really convincing), but it's absolutely NOT fast enough for immersive video. When there's at least 1/60th of a second lag between your hand's motion and seeing your virtual hand move, you'll DEFINITELY notice the lag. 1/60th second lag feels, well... "laggy". 1/30th second lag feels downright sloppy.
Human vision is hard to quantify. Your foveal vision (generally, color from cones) is relatively low-res and low-framerate, but your peripheral vision (generally monochrome from rods) is EXTREMELY sensitive to framerate at high contrast (as in, you have to be up around 300-600fps before it really, truly starts to become a non-issue for all users). And although your foveal vision is almost entirely cones, some people DO have enough foveal rod cells to act like pseudo "cyan cones" with the same contrast and motion sensitivity they'd have as peripheral vision (proof: over the years, researchers have found at least 2 or 3 men who appeared to be anomalous protan trichromats, but were REALLY deuteranopes with enough foveal rod cells to act like pseudo-"green" cones under the right lighting conditions). This is also why marijuana can sometimes make colors appear to be "psychedelic" -- it enables rod cells to continue functioning in brighter light than they normally would, and they start to act like cyan-sensitive cone cells. In other words, the stoned individual is temporarily "kind of" tetrachromatic, and perceives it as "seeing weird colors".
100-150fps is a definite step up from 50-60fps, and a quantum improvement over 24/25/30fps. You can absolutely see the difference, even if you view them sequentially. This is also roughly the point where your eyes make their own motion blur, and you can stop worrying about having to create it in the source video itself.
300-600fps is the next major step up, though at THIS rate you might have to see a simultaneous left/right comparison to accurately notice the difference. From what I've read, this is actually the point where you start falling into the uncanny valley. At 300-600fps, your eyes will blur frames together, but anomalies in motion from frame to frame will start to become "creepy". Basically, your eyes are telling your brain that you're seeing a real, live scene... but tiny parts of it aren't quite moving in PRECISELY the right way to BE a real, live scene.
With a 55" TV, the biggest benefit comes from having 4K **content** and a good scaler. By the time 2160p24 gets compressed down to something Netflix can handle, you MIGHT end up with the PQ of real, minimally-compressed 1080p24. Basically, 4K shaves away the shittiness that has gradually crept into mainstream "2k" HD video.
For an illustrative example, think about a non-HDTV with s-video input and either cable or satellite TV. You can feed it a "SD" channel, or you can feed it a downrezzed "HD" channel. The TV might not have the resolution or bandwidth to take full advantage of HD, but the downrezzed HD channel will STILL look at least twice as good as the native SD channel.
Put another way, we'll need "8k" HD to give us the PQ of uncompressed "4k", the same way we now need "4k" HD to give us the PQ of uncompressed "2k" HD. It's always better to get your own copy of the "good" source and do your own downrezzing locally, because when you delegate the downrezzing to the TV content provider, they'll always and invariably cut even MORE corners and make it look like shit by the time it gets to you. You can always throw away unnecessary detail, but once it's gone you can never really get it back. Just TRY watching live 1080i60 on a LCD... it'll either get BOB'ed down to 1920x540, or you'll get to see two footballs moving across the screen. Deinterlacing works for film content because it's 24fps duplicated 2 or 3 times to get 60fps. Deinterlacing fails MISERABLY for NATIVE interlaced content, because THEN you're trying to synthesize real detail that's gone forever... and trying harder just creates weirder and weirder artifacts (like things that YOU KNOW went away magically reappearing, because the video processor has no knowledge of context, and just knew that something appeared in that area a few frames ago).
Frankly, I don't really understand why cable and satellite companies even still BOTHER delivering SD channels, instead of just having the box downrez the HD channel locally. It's not like it's hard or expensive to do anymore, and it would free up hundreds of megahertz of spectrum (or dozens of satellite transponders) and make room for things like 4k, 3D, etc.
To a certain extent, Google HAS been isolating more & more potentially-vulnerable libraries used by the OS itself into packages that can be updated through Google Play (like WebView). Kernel-level stuff still requires manufacturers to fix, but Google can fix a newly-discovered Javascript vulnerability and deploy the fix to semi-recent devices all by itself.
I'm not totally sure where the AppCompat library/framework fits in... I think it's statically compiled into the .apk at build time, but I'd be shocked if it didn't delegate most of its actual work to a component that's updatable via Google Play.
That's because dropping what you call "legacy support" would have erased their main advantage over ARM -- raw balls-to-the-wall no-compromise performance. In car terms, an i7 is like a maxed out Tesla Model S P90D with "ludicrous mode" switched on... by comparison, an ARM is like a Chevy Volt.
Also, a CRT capable of only 480i60, 480p60, and 1080p60 can cut corners that would be impossible to cut on a true multisync CRT. I'm not 100% sure, but I think CRT HDTVs line-doubled 480i60 to treat it like 480p60, and padded both to give them 1080i60 timing to avoid the expense & complexity of PC multisync monitors. In other words, most CRT 1080i60 HDTVs displayed ONLY 1080i60, and relied on their scaler to turn 720p60 into 540p60 (the REAL reason why 720p60 appeared to have such low resolution compared to 1080i60... almost a third of its detail got thrown away, then half of its temporal detail got thrown away.)
Not exactly... there's not enough bandwidth to stream 2160p60 that's captured & compressed in realtime for live tv, but 2160p24 would be *totally* achievable with ~19mbps if ATSC allowed h.265 with long GOPs & you did the compression offline.
The REAL reason ATSC doesn't allow 1080p60 is that RAM was *horrifically* expensive back in the early 90s, realtime compression of 1080p60 was still just an engineering fantasy, and both broadcasters & TV manufacturers opposed making it something all receivers *had* to be capable of decoding. Most broadcasters were totally in the 'interlaced' camp, and even 720p60 was a tough sell to CRT manufacturers (I think Monivision made one of the very, very few 32"+ 720p60-native TVs). Why? Because 1080i60 is equivalent to 540p60 as far as a CRT is concerned, and not much more demanding than 480p60 (~34MHz bandwidth vs ~31MHz bandwidth). However, 720p60 required ~45MHz, and 1080p60 would have required a staggering ~65MHz of bandwidth... simply put, a CRT capable of 1080p60 would have been VERY expensive compared to one that can only do 480i60, 480p60, and 1080i60.
The problem is, your health insurance would just add a clause giving them priority for any revenue from your organs. So if your final bill came out to $120,000 (with $24,000 co-insurance, but limited to $5,000 out of pocket) & your kidneys earned $20,000, your family would be *lucky* if it saw a cent, or even got to at least apply the first $5,000 of it towards the deductible, instead of having the insurance company swallow the whole amount by claiming your final bill cost them $115,000 after applying your coinsurance payment.
Custom characters were actually quite easy to do on the Vic-20 and C64. Hell, I didn't even understand the concept of binary at the time (I was in 5th grade). I just knew that you took a sheet of graph paper, drew a box around an 8x8 area, wrote "128, 64, 32, 16, 8, 4, 2, 1" at the top of each column, and added them up to get the row's value.
In fact, the Vic-20 didn't actually have a traditional "bitmap" mode. To kludge it, you put it into a mode where it used 8x16 characters instead of 8x8 characters, then wrote them to the screen in a 21x12 or 22x11 grid (character 0, then character 1, then character 2, and so on until you got to character 256), then poked directly into the custom character definition block of ram to set the individual pixels. It wasn't commonly done, though, because a stock vic-20 didn't have enough RAM to pull it off, so you had to have at least one ram expander (and if that ram expander wasn't the 3k version or a Super Expander cartridge, you also had to deal with the video ram getting moved to another block of addresses). Or you had to leave the characters as 8x8 instead of 8x16, and limit your pseudo-bitmap area to whatever dimensions you could kludge out of 256 8x8 characters.
Now... multicolor characters were another matter entirely. I'm kind of ashamed to admit that I never really understood how to use them at the time, and it wasn't until years later that I looked back at a book on c64 programming and thought, "oh... THAT'S how they worked..."
(Confession: it wasn't literally my first Vic-20 program... it was the first program I wrote on MY Vic-20. I'd actually been playing with my best friend's Vic-20 for months at that point)
~35 years ago, I got a Vic-20 for Christmas. It took me an hour to write my first program, including the custom character design. Today, if you got a new Dell laptop for Christmas, you'd be lucky if Windows Update finally allowed you to even *do* anything within the first hour or two. Fuck, even a brand new Xbox One or Wii-U (and probably a PS4) will make you wait at least 30-60 minutes for mandatory updates before it'll allow you to play your first game.
Replacing a screen has a hard cost to LG of a few hundred dollars for the replacement part. Putting a flashdrive image on a ftp server with instructions for using it has per-tv marginal costs approaching zero.
> I mean Android is just a use of an OS kernel and some standard services, including application security, and some UI conventions.
And Google's very, very proprietary, non-opensource, and defacto-required (if you don't want your phone to be crippled) Google Play Services, which are required for installing apps from Google Play, using Google Maps, using Google-assisted location services, Google Pay, and plenty of other things. Over the past couple of years, Google has been systematically moving more and more of Android's core functionality into Google Play Services.
Yep. Most people don't realize that NOT EVEN NEXUS DEVICES have official buildscripts available to create a ROM with everything in the official factory ROM (including binary blobs that aren't open source). You can build and install generic AOSP, but generic AOSP is a subset of what's part of an official Nexus 6P ROM. AOSP on a Nexus 6P is no better than it was on the Galaxy S3 (IMHO, the S3 was the Golden Era of AOSP, and the closest we ever got to being able to flash a semi-device-nonspecific ROM the way you'd boot Debian or Ubuntu on a PC... almost everything since the S3 has been a slide downhill compared to what we had).
Much of the recent blame should be placed on the new universality of using SSL/TLS for everything.
The problem is, negotiating a cold SSL/TLS handshake from scratch takes a certain amount of time... and there's very little you can do to speed it up with current standards. Adding certificate-revocation lookups compounds the problem and adds even more time. In the past, a site that "used SSL" might need to do one or two key exchanges for one or two different hosts. Now, a single page might require a dozen or more key exchanges... and some of those key exchanges might not even be known by the browser to be necessary until after it's done the first few (because some script delivered via https references some other asset via https on a different host).
SSL/TLS itself is generally a good thing... but the WAY it's currently being used was NEVER seen as a realistic use case 20 years ago when it was first implemented. Simply put, SSL/TLS key exchange and CRL doesn't scale well in their current form.
This is also part of the reason why it's so common to end up with "five bars of LTE signal strength, but no working data-connectivity" -- mobile apps are "chatty" to begin with, and many of them do a shit job of keeping https sessions alive between requests, so every single background https request requires yet another new handshaking and revocation-lookup. In areas where you have a cell site with limited backhaul connectivity and occasional surges in the number of users (say, a cell tower near a large state park serviced by only a T-1 line or two... on July 4th, when 60,000 people might descend on the park for a few hours), the endless key exchange traffic ITSELF can almost fully-saturate the tower's backhaul capacity.
The filmmaker was a wimp. This presentation at DEFCON by a guy who got his Mac stolen was EPIC:
https://youtu.be/Jwpg-AwJ0Jc
Spoiler: he showed the guy's adult selfies, online dating profiles, Google searches, and more. The moral: if you want to keep your data safe, use robust encryption and access security. If you'd rather get your computer back (or at least, hours of entertainment at the thief's expense), configure it with auto-login (so the thief won't even BOTHER to reinstall the OS) and remote control software w/DDNS client. :-D
Actually, it's a bit more complicated than that.
CDMA2000 does, in fact, have an official SIM-like standard: the USIM, which is a literal superset of the GSM SIM card standard that has CDMA's own R-UIM card grafted onto it. The catch is, Qualcomm made it an optional part of the standard, and Sprint & Verizon were perfectly happy to pretend it didn't exist. Ditto for Telus in Canada, which was (at the time) a wholly-owned subsidiary of Sprint with identical phones and policies (but they STILL wouldn't let you use a Sprint phone on Telus, or a Telus phone on Sprint... they could roam on both networks just fine, but neither network would allow you to actually sign up for local service using a phone from the other country AS your "real" phone).
Elsewhere in the world (New Zealand, Australia, Singapore, India), you could ABSOLUTELY buy non-carrier-branded CDMA2000 phones, get a R-UIM or USIM card from your carrier, and use it as effortlessly as using a GSM phone on a GSM network.
As a historical quirk, there WAS actually one popular Sprint phone that had a R-UIM socket (or at least a place to solder one) that was covered by a black sticker -- the HTC PPC-6700. Apparently, they had a brief second life of popularity in India after someone figured out they could buy old (or new old stock) American PPC6700s for a pittance, hack them slightly, and sell them as fully-working phones in India (at a point in time when phones running Windows Mobile were OUTRAGEOUSLY expensive in India, and WinMo CDMA phones like the PPC6700 basically didn't officially exist at all)
One small detail -- Chinese is AT LEAST as genderless as English. It's one somewhat unique feature both languages got RIGHT. The only real advantage English has over Chinese re: gender is that English might make it slightly easier to be intentionally vague about a PERSON's gender. Neither language has silliness like "boats are female (unless they're submarines), chairs are male, and teenage girls are neuter". Or that radio is male if it's an electronic device, but female if it's broadcast content.
Dude, do you have *any* idea how robust encryption schemes like AES, and hashes like SHA are?
Not even the NSA has the resources to bruteforce 128+ bit AES or 256+ bit SHA. If the NSA worked hand-in-hand with their Russian, Chinese, and Israeli counterparts and threw literally every computer resource at their disposal at bruteforcing AES or SHA, they MIGHT have ~50% likelihood of success after 10-25 years IF they managed to discover some as-yet undiscovered weakness. Not even organized crime, buying 100% of Amazon's on-demand computing power, could hope to bruteforce either scheme within any viable timeframe.
Modern encryption doesn't get cracked by bruteforcing keys... it gets cracked by bruteforcing people or devices with ACCESS to the keys (say, pointing a gun or court warrant at them, or obtaining physical control of a PKI hardware key's container).
This is NOT a trivial problem that script kiddies can defeat between classes and WoW tournaments. Even SHA-1 has been "compromised" only to the extent that someone with substantial resources and good luck could discover a meaningless pseudorandom chunk of data that produces the same hash as the original hashed data.
FPGAs (and GPUs) can radically compromise "Proof of Work" algorithms like Blowfish, but that's ONLY because those algorithms made assumptions about resource scarcity that Bitcoin miners have been highly-motivated to surpass. AES & SHA(-2) are entirely different beasts... THEIR hardware constraints & key length move the time scales to "longer than the Earth has existed... or with as-yet nonexistent hardware, maybe the length of recorded human civilization."
Unless it transmits a cryptographically-signed VIN as part of the broadcast, and receivers log that VIN to some kind of persistent storage if they rely on its data. It wouldn't necessarily prove that a specific INDIVIDUAL is guilty, but it could ABSOLUTELY pin financial liability on the owner of the vehicle associated with that VIN for negligently allowing a car he owns to spoof bad data.
I know that in Florida, you can't get license plates without registering the VIN, and I'd be shocked if any state DIDN'T require VIN-registration as a condition of getting license plates.
Since realtime certificate lookups are obviously out of the question, they'd probably issue certs good for a year at a time simultaneously with license plate renewal, and cars would be programmed to either ignore, or at least seriously question the validity of, expired certs.
China's dialects and writing systems work quite well. They're just optimized in slightly different ways than English.
English has lots of what computer scientists would call "forward error correction" -- you can really, REALLY fuck up and mangle English, yet still be understood. In contrast, you could say that Chinese has built-in spatial & temporal data compression... at the expense of error-tolerance.
For an understanding of how tones work, think about all the different meanings the word "fuck" can have depending on how your pitch changes. Chinese tones are just a systematic way of describing those pitch changes.
Likewise, Chinese is notoriously hard to *write*, but can actually be slightly easier to *read* than English (at least, if you're comparing difficulty for semi-illiterate native speakers).
IMHO, 100-500 years from now, English will be the planet's dominant language, but it will probably have imported a few hundred one- and two-character words from Chinese (with 'man', 'woman', 'year', 'month', and 'day' being among the first ones) and use them the exact same way Japanese uses kanji -- as an alternate, more compact way to write common words that could be legitimately written using an alphabet.
The truth is, you can learn to read and write more than 100 Chinese words in just a few hours. Once you know how to write 'one' through "seven", you only need to learn the character for 'day' to name the days of the week. Learn "eight" through "12" plus the character for "month", and you can name the months in a year. You can even cheat & use arabic digits, effectively learning to name 19 days+months with just two learned characters. Contrast that with the mess we have with English day & month names. In some ways, Chinese has elements of logical order that English lacks.
TL/DR: The Chinese language works perfectly well for people in China.
The real problem is that any VR that's hobbled by 60fps video will *never* feel interactively-immersive. 60fps is enough to appear smooth for passive viewing (when augmented by appropriate motion blur), but feels sloppy & laggy if it tries to be immersive & track your real-world gestures. 120-240fps is the point where latency becomes acceptable, and your own eyes provide the moton blur.
Not really. If oil were replaced by a true "global power grid", US dollars would simply become the currency of choice for buying & selling it.
The value of a US dollar is mainly its liquidity... you could walk into a bar or open-air market in the most backwards country on Earth and buy almost anything with US dollars. Even in Europe, if you walked into a random McDonalds, you could probably find someone in line who'll HAPPILY sell you a 10-Euro note for US$20 by the time it was your turn to order.
Currency exchange is expensive, so companies try to trade in US dollars AND KEEP THEM STORED as US dollars whenever possible. When an American buys something for 200 Euros on his Citibank Visa card, and a European buys something for $200 with HIS Citibank Visa card (or some national bank that's owned by Citibank anyway), Citi doesn't buy $200 worth of Euros at market rates and 200 Euros worth of Dollars at market rates... it CHARGES both cardholders as if it did, but REALLY just keeps the Dollars as Dollars, and Euros as Euros, unless it literally runs out of one or the other & can't borrow the shortfalling currency for less than the exchange rate. At worst, our hypothetical 200 Euro & Dollar transactions MIGHT result in ~$40 actually being exchanged.
THAT's why the US Dollar is dominant... you can buy goods and services with it almost anywhere AND often pay less than if you'd uses that country's official currency.
We *already* have the tech to flawlessly replace CRTs with no compromises besides sacrificing flatness & light weight: bright OLED light engines projecting onto much larger screens. Think: DLP or LCoS-type RPTVs, but with a 10-20" OLED projection source instead of a 2" chip that either reflects or filters light from a bright halogen bulb.
There's also FED, which literally EVERYONE circa 1995 expected to be the next core display technology (basically, take a sheet of r/g/b phosphor-coated glass, then put a solid-state electron emitter behind each subpixel (so that instead of having one powerful electron beam that sequentially refreshes row by row, column by column, you have a few MILLION weak (but individually-addressable & continuous) electron beams. FED's main drawback is energy use... it draws as much power as a comparable CRT, so it's unsuitable for portable devices.
LCDs are truly a technology that *nobody* seriously expected to become dominant for anything besides laptop displays, precisely because they suck so badly at things that CRTs (and 3-laser DLP, and FED, and projected OLED) can all do well, at the trade-off of maybe a foot or two in depth, or a few hundred watts of power draw.
Personally, I'm keeping my kick-ass 3-laser DLP TV until 120fps finally kills it (even if it can't do "4k", a suitable scaler allows 3840x2160 to be scaled down to high-bandwidth uncompressed 1920x1080 that will look 98% as good as 'true' 4k, because TODAY's "1080i" is now compresed to the point where it's achieving less than HALF its theoretical potential. Just compare the picture quality you get from a 20 year old CRT displaying 720p60 content through a scaler via s-video to the PQ that SAME TV used to have with broadcast TV. The difference? 20 years ago, it was displaying a video source with ~3-5MHz bandwidth. Now, it's scaling a video source with 45MHz bandwidth (720p60) down to maxed-out s-video's ~12MHz of bandwidth (~16MHz, if you hacked the tuner to take component video 480i60). Basically, compressed "4k" TV ends up having as much/little REAL detail & PQ as fully maxed-out balls-to-the-wall ~50mbps 1080i60 does (BROADCAST 1080i60 is limited to 20mbps, but HDMI 2.0 can deliver raw 4:4:4 RGB at more than twice that rate without breaking a sweat.
Is it *really* that big a deal outside the sealed & laminated Apple universe to just stick a mPCIe slot on the mobo's underside, cover it with a tiny hatch, and pre-embed suitable antennas for it in the display & run the wires to that same hatch/slot? Most mid+ end laptops *already* have an extra mPCIe slot (though only high-end corporate laptops usually advertise it as a feature & make it officially accessible for things like cellular modems... in most mid-range laptops, it's more like a forgotten, semi-vestigial socket that exists only for factory-installed modules).
The truth is, unless the laptop mfr is an asshole & explicitly locks out "unapproved" mPCIe cards in the UEFI BIOS, as far as Windows & Linux are concerned, they're just normal 1x (4x?) PCI Express slots waiting to be used for something (warning: MANY such slots can work as EITHER mSATA or mPCIe, but the two DO have different pinouts despite having the same form factor & connector... if they don't support mSATA, you'll need a MUCH more exotic & expensive mPCIe SSD with embedded SATA controller like the ones Apple uses in iMacs for flash/ssd or fusion drives).
Likewise, most gaming laptops w/discrete video cards use cards that are electronically-compatible... what makes them proprietary is the fact there's no real standard for dimensions, hole-placement, or cooling of laptop video cards, so you could end up with a laptop that can use an arbitrary video card, but will cook it in seconds, not allow it to be properly mounted, or not have enough room for it).