Because Enterprise customers aren't satisfied with control over virtual machines or ONE of your device's potentially-multiple operating systems... they demand complete control so they can remotely wipe your whole device (including your personal files) without warning if they decide to lay off your entire team.
When you allow your company to install MDM software on your device, there's almost no technical limit to what they can do. They might *voluntarily* exercise restraint, but there's literally nothing to stop an evil company (or rogue admin... or malware running with an administrator's credentials) from doing their worst.
I wish Android allowed you to use microSD as primary storage, but use the phone's (usually) much-faster internal flash as a delayed cache (always writing to internal flash & reading from it when possible, but periodically saving updates to microSD when the UI is inactive & the phone would otherwise be asleep... kind of like the way Intel allows you to do on a PC to cache your laptop's slow 2TB+ hard drive to a special partition on your mSATA SSD)
It's REAL market is more likely to be, "people who want to use their phone (or at least, its case) for company email & groupware, but don't want to hand over control of what's literally their most intimate and private data, to their company's IT staff... or at least, compromise the functionality & performance of their own phone by installing invasive MDM software".
In other words, it's a sacrificial device to let your company's IT staff fuck up so you can spare your REAL one from the same fate.
Why iPhone? Because it's just about the only phone whose models sell enough identical-form devices AND has a market life longer than the 9-15 months typical for most Android devices. The Galaxy S3 was one of the very, very few Android phones that ever came close (re both total sales AND useful market life). The S8 might sell more in 6 months than the S3 sold in two years, but it'll probably be replaced by the S9 6-9 months after the S8's release, and officially discontinued the same day.
I can DEFINITELY see someone like Huawei or HTC making a future phone that's basically two independent Android devices sharing one battery. Samsung, probably not, because then they'd have to admit that consumers have legitimate complaints about Knox (complaints mostly due to later changes made at the demand of large enterprise customers... Knox infrastructure ITSELF is fairly benign, but the MDM software used to configure & administer it is as bad as any other MDM thanks to LATER demands imposed by large enterprise customers who insisted upon having complete control over the entire device, as opposed to settling for complete control over Knox's VM and virtual encrypted filesystem).
It's worse in Florida. ~25 years ago, the Florida utility regulators agreed to let BellSouth basically DOUBLE the cost of local phone service to finance laying fiber to ~80% of customers within 10 years. The deadline came & went, and circa 2010, someone in the state capital who examined AT&T's actual deployment discovered that 99% of the fiber laid by AT&T since ~2006 was serving (... drumroll...) nothing but AT&T cell towers. AT&T was counting potential wireless customers within range of a fiber-connected tower as 'served by fiber', and filed documents claiming that U-verse was available in areas were there wasn't even a VRAD.
It was a scandal so brazen & outrageous, even for a state that has historically been anti-regulation, that what's left of the state public service commission was threatening to levy HUGE fines against AT&T (and possibly seek prosecution for actual fraud). At the last second, AT&T somehow convinced them it was an honest mistake, and got them to let them have 5 more years to make U-verse available in all the places where they'd claimed it existed all along.
There were also areas like MY neighborhood, where they claimed U-verse was 'available to __-thousand residents', but was *really* limited to a few hundred, because they were running it from a distant VRAD whose capacity had been maxed out for YEARS. I know, because when I bought my house, I made a POINT of verifying that DSL was available... then found out that I couldn't actually GET it unless someone else quit AND I got lucky enough to call them after the port became available, but before someone else took it (not even a formal waiting list... literally, random luck)).
In Florida, AT&T acts like it's benevolently giving the gift of fiber (to the curb, mostly), but the truth is, Floridians have been PAYING for BellSouth & AT&T's fiber-laying since the 90s, and somewhere along the line, they were allowed to forget that.
(in BellSouth's defense, THEY mostly kept their end of the bargain. The problems began after AT&T bought BellSouth and 're-aligned' their capital improvement priorities).
If the US shifted its timezones by a half hour, Canada and Mexico would almost certainly follow, and Britain would probably do it within a year (most of my British friends like the later sunsets of BST, but despise the twice-annual clock changes).
Two timezones would suck, but three would make more sense... eastern = utc+4.5, central = utc+5.5, and Pacific=utc+7. Basically, splitting the difference for eastern & central, and making dst year-round in pacific. SoCal has ABSURDLY early sunrise & sunset compared to the east coast.
In theory, there IS a way to store passwords in a way that works kind of like a reversible hash... use RSA in "deterministic" mode ("RSA/ECB/NoPadding"). Basically, generate your keypair, and keep the private key offline and physically secured. When users register, use the public key to encrypt the salted password. When users subsequently authenticate, encrypt whatever they entered with the correct salt & compare the results, just like you would for a hash function. And if you someday ever need to do some kind of software migration that would otherwise require wholesale password resets, you can bring the private key out of storage and use it (on an offline computer) to decrypt a copy of the current passwords, then re-encrypt/hash them by whatever new means you're using.
Note that this is NOT the way RSA normally works. Usually, random padding gets added to the plaintext before encryption (and thrown away after decryption), to ensure that two identical plaintext inputs won't produce the same plaintext output. And even fairly LONG RSA keys can only encrypt a relatively small number of bytes. A 2048-bit RSA key is probably long enough to directly encrypt a 16-character password (assuming worst-case UTF-8 encoding and 4-6 bytes per character), and 1024 bits MIGHT be enough, but I'm pretty sure that 1024 bits would be the smallest power-of-two big enough to directly encrypt arbitrary passwords of reasonable length.
There are some sobering things to consider, though:
1. There's no official PKCS standard for doing this, which means you'll be using a scheme that hasn't been peer-validated, and has zero high-level support by any off the shelf software product. In regulated industries, the fact that it's not a PKCS standard will probably disqualify it outright.
2. There's more to encryption than dumping bytes into a black box, ESPECIALLY when it comes to RSA (google "textbook RSA OAEP" (sans quotes) for the gory details of what happens when you try using Schneier's "Applied Cryptography" as an implementation cookbook rather than as a high-level introduction). Reference: http://crypto.stackexchange.co...
3. If you're planning to use BouncyCastle, I'm pretty sure I remember reading that deterministic RSA ciphertext isn't deterministic across platforms. In other words, if you encrypted a given plaintext with key in a C# program under Windows, you wouldn't necessarily get the exact same output if you ran a program written in C++ running on Linux with the same plaintext and key. They'd both DECRYPT to the same original plaintext, but the encrypted bytes wouldn't necessarily be identical on both platforms.
Is this more secure than storing the passwords in plaintext? Unquestionably.
Is this more secure than encrypting the passwords with AES, using a key protected only by filesystem security? Probably.
Is this more secure than storing the original passwords using the most robust mode of RSA currently available, alongside a salted SHA256 hash that's used for routine authentication? I don't know. I'm pretty sure that giving attackers two copies derived from the same plaintext reduces their aggregate security, but I don't know whether the resulting, diminished security would be better or worse than using deterministic RSA to encrypt the password instead.
The gold standard, probably enshrined in at least one PKCS standard, would almost certainly involve hardware PKI... very, very expensive hardware PKI.
TL/DR: deterministic RSA is probably the least-bad option available to someone not required to follow PKCS standards, but it's kind of like transpolar air traffic(*)... a few guidelines, but you're pretty much on your own and fucked if anything goes wrong.
Because browser-based webapps fscking SUCK compared to any halfway-competent native app. Javascript is dog-ass slow on mobile devices, and the user experience is AWFUL. Go ahead, go compare the experience of using walmart.com, amazon.com, or homedepot.com to the experience of using their native apps. It's a night & day difference. The webapps are a minefield of continually-reflowing content with a knack for changing the spot you were trying to touch 250ms ago into some goddamn other link. My blood pressure usually goes up by at least 40mmHg due to frustrated rage whenever I'm forced to use some awful webapp on a mobile device (especially when content reflows the moment before I touch the screen, triggering something that takes 30 seconds or more to recover from).
> Seriously, unless you're part of a big corp with big corp lawyers > and money behind you why develop for Apple?
Ok, here's a challenge: write an Android-only app to collaborate or organize some kind of group activity, then try to get any real-world group (besides literal Android developers) to USE it. The moment somebody realizes it can't be used by group members with iPhones & iPads, your app will become dead and irrelevant to that group, unless it's LITERALLY a group overwhelmingly comprised of Android users (or whose leaders can get away with brushing off the complaints of iOS users). To be viable and be taken seriously now, you HAVE to support both platforms.
If you can live with 25gb capacity, the most cost-effective current medium you can get is non-LTH BD-R.
M-Disk is just a non-LTH BD-R disc with the spiral geometry and pit dimensions of a DVD. It's a nifty idea, but unless you LITERALLY have to be able to stick the disc into a consumer DVD player and watch it directly, you'll get the same data-durability and save a substantial amount of money by just ripping your DVDs to.iso files & writing several of them to a single BD-R disc. Likewise, unless you need to be able to read your files on a PC that can't read Blu-Ray discs, there's NO GOOD REASON to buy M-Disks instead of non-LTH BD-R discs.
Well, OK, I can think of one... even if you know what you're looking for, trying to buy non-LTH BD-R discs is kind of like trying to buy a multi-TT USB hub... it's rarely advertised as an explicit feature, so you can spend literally HOURS combing through product listings at Amazon & Newegg looking for the non-LTH needle in a growing haystack of LTH discs (searching rarely works, because the fucking search algorithms at Amazon and Newegg treat "LTH" as a match for "non-LTH". Whereas if the disc is branded "M-Disk" and has a capacity of 25gb, you know beyond doubt that it's non-LTH BD-R.
Or, a hundred times worse than QIC... QIC-EXtra, which only really worked with Verbatim's own backup software.
Verbatim's scam:
1. Bundle a free "SE" version of their backup software that could "sort of" make backups under Windows 9x, but crashed too easily and often to reliably restore files from the backup later.
2. Release an expensive "Pro" edition of the backup software that fixed the worst of those bugs.
3. Excuse the SE version's near-unusability by saying, "well, maybe the Windows 9x SE version IS kind of buggy... but the free DOS version should still work". Except the DOS version had no concept of long filenames, so it couldn't be used to restore a full system backup to a blank hard drive. Using it to restore a backup was more like picking through the wreckage that used to be your house after a hurricane reduces it to a debris pile.
The thing is, most of those old games WEREN'T 'really' 30hz... they were 60fps.
A NTSC display could only display 30 complete frames per second, but the video chips on most legacy games didn't send complete frames... they sent 60 FIELDS per second (each of which contained ONLY the odd or even scanlines from each frame). CRT TVs were "dumb", and depended on the video signal itself to tell them whether the next field was odd or even (with one shifted vertically to fill the gaps between the other). So games simply never TOLD the CRT that a field should be shifted, allowing those 60 fields to be repeatedly drawn over the same half of the scanlines while the remaining half remained dark.
This actually caused problems with a lot of first-gen LCD TVs. They'd buffer a field, buffer the next, then freak out when they couldn't decide which one was supposed to be "even" and which one was supposed to be "odd". The usual result was either an empty blue screen (possibly with something like "invalid signal" displayed as well), or a mangled mishmash with what were SUPPOSED to be two independent 60fps frames forcibly-interleaved into the same 60fps frame and shown twice in a row.
In any case, even if the native framerate WERE 30fps, high-bandwidth VRAM can solve the problem for you... buffer a few scanlines, then do the effects processing in the time it takes a later scanline to do its horizontal retrace and output the whole thing through the VRAM's back door, so you're only adding a few scanlines' worth of latency instead of an entire frame's worth.
Actually, you're allowed to make a 'reasonable' number of phone calls, though after repeated refused or unanswered calls to friends & family members, you might be told you're going to have to wait a while unless you want to call someone like a law firm that's almost guaranteed to answer. The 'one phone call' meme is a Hollywood construct that would never survive legal challenge, though there's probably room to disagree about the definition of 'reasonable'.
Moore's Law is merely an observation about the NUMBER OF TRANSISTORS on a die, not computing power.
In theory, Intel and AMD could probably make 64-core CPUs a retail reality within a year or two... but with current programming languages, it would be almost pointless. Multithreading exists, of course... but few apps besides raytracing can genuinely put it to good use. As a practical matter, 99% of the benefit from having multiple cores comes from being able to run Windows UI threads on one core, and whatever app is in the foreground on the second. With Windows itself spinning off API calls from the app onto cores 3 and beyond when it gets the chance to do so.
Windows does a decent job of passively putting multiple cores to good use, but its ability to do that mostly depends upon having access to the benefits of x86/AMD64 architecture at its disposal. Historically, Linux has done a TERRIBLE job of passively putting multiple cores to good use without explicit multithreading attempts by the app's programmer, due to two main lines of reasoning:
a) If the developer intended for the program to multithread, he would have written it that way... IMHO, more of an excuse, because the fact is, current programming languages aren't all that great at handling concurrency without major gymnastics. 25 years ago, we had spaghetti code as an anti-pattern. Now, we have a rat's nest of spaghetti async threads that are almost impossible to grasp without referring to a wall-sized UML diagram.
b) Many of the things Windows does to passively put multiple cores to good use depend upon the "strong" memory model of x86/AMD64 CPUs. I believe this is actually the biggest current reason why Linux doesn't try as hard as Windows to passively multithread apps written to be single-threaded... and the reason why there were several entire generations of multi-core Android phones that didn't actually do a single damn thing with the extra cores besides brag about them in the marketing literature. Basically, on x86/AMD64, if thread #1 updates a byte of ram, thread #2 running on another core attempts to read it, the CPU will automagically make the change instantly visible to the second core. On ARM, that's rarely/never the case. With a language like Java, x86/AMD64 hides lots of programming sins that will cause the exact same code to crash and burn on ARM.
TL/DR: we COULD have CPUs with a lot more cores than 4, 6, or 8... but current software wouldn't put them to good use, so there's almost no real market for them besides servers and mainframes.
You'll need "Prime Luna", which will probably cost about $890 million/year (but include free Terrestrial Prime for up to 10,000 friends & family members, plus unlimited one-hour(*) digital delivery to the moon of media content). If they launch monthly, shipping will be free with delivery within 2 months, $3 million for next-month, and $11 million for next-launch.
(*) when we're finally on the moon for real, broadband internet (with high latency and frequent outages, but respectable average throughput over the span of an hour) will probably be a given, limited mostly by the ability to aim and focus lasers between geostationary satellites & earth (in theory, you could put the relay stations along the literal equator & aim straight up or down to/from geostationary satellites, and achieve near-fiber throughput... at least, on non-cloudy nights).
On the downside, lots of PC games are semi-dysfunctional if you insist on playing them with a gamepad on a TV across the room, because they were developed for mouse+keyboard play while seated at a desk.
Illustrative case in point: "Flockers" for xb1 & Steam. The Steam version is literally unplayable on a HTPC across the room with XBox-like gamepad. And this is almost the golden porting scenario... a game that *has* perfectly-usable controls on the console version, and one is almost a verbatim port of the other.
Sadly, it's far from being the only one. I bought Super Giana Sisters for *both* Wii-U and Steam. The Steam version is much, MUCH harder to play with a gamepad (it feels 'twitchy' compared to the wii-u version)... and this is a game where they explicitly TRIED to fully-support gamepad play.
As I understand it, the problem lies with the fact that the analog sticks are interpreted by the gamepad hardware, and they all come up with slightly different values for a given position. With a Wii-U, you know beyond doubt that player 1 is using a specific controller with known response, but with PCs, every stick is slightly different.
The problem is, it's *NOT* "more screen", because they're the same size and resolution as similar phones that *have* dedicated buttons. It's a pure anti-feature that companies have somehow managed to spin into a selling point.:-(
Case in point: Nexus 6P vs Galaxy Note 4. Literally identical displays, but the 6P technically doesn't even get detected as 'widescreen' (for layout alternate resource purposes) because Android subtracts the height of the softkey area from the vertical resolution, and the resulting ratio ends up being.00000001% below the threshold for 'widescreen'.
er... any "text message" you send with embedded photos, more than ~160 characters, or to multiple people, is REALLY sent as MMS (by the default text-message app that comes with Android Nexus phones, at least).
News of MMS's death are wildly exaggerated. If anything, it's the de-facto current standard *for* "text" messages.
There's a straightforward reason why lots of web apps continued to use MD5 *long* after it was deprecated: MySQL had a function for md5() almost from the start, but didn't have an inline function for SHA() until 4.0.2... and 4.x didn't become the default version in long-term stable server-oriented distros until 2006 or later. Getting a new release to run on YOUR development computer? Easy. Convincing an enterprise sysadmin to let you have it on a production server before it has become the 'stable' default *and* the servers have been upgraded to the new distro release? Good luck. Most developers don't have the social capital & stamina to campaign for newer versions from stubborn admins, and will just say 'fuck it' and use MD5 if their boss isn't ready to fight that battle for them.
> You get a massive speed increase if you switch to a better filesystem: > btrfs or f2fs.
For the record, no stock Android kernel I'm aware of allows you to use anything besides FAT, FAT32, or exFAT on a microSD card since sometime between Jellybean and KitKat (some custom kernels restore that capability), for reasons known only to Google.:-(
As bad as their random-read performance is, their random-WRITE performance is usually much, MUCH worse. And almost none do their own wear-leveling, so a Linux swapfile can literally max out the lifetime writes of a microSD card in 1-3 months (because the multi-million stat assumes well-distributed block erasures & writes... if you're scrubbing away at the same few blocks, you'll wear it out in a FRACTION of the rated write-life. That's why AOSP Android ROMs (generally) won't allow you to create a swap partition on internal flash... you could ruin the entire phone.
Slashdot Mirror
Because Enterprise customers aren't satisfied with control over virtual machines or ONE of your device's potentially-multiple operating systems... they demand complete control so they can remotely wipe your whole device (including your personal files) without warning if they decide to lay off your entire team.
When you allow your company to install MDM software on your device, there's almost no technical limit to what they can do. They might *voluntarily* exercise restraint, but there's literally nothing to stop an evil company (or rogue admin... or malware running with an administrator's credentials) from doing their worst.
I wish Android allowed you to use microSD as primary storage, but use the phone's (usually) much-faster internal flash as a delayed cache (always writing to internal flash & reading from it when possible, but periodically saving updates to microSD when the UI is inactive & the phone would otherwise be asleep... kind of like the way Intel allows you to do on a PC to cache your laptop's slow 2TB+ hard drive to a special partition on your mSATA SSD)
^--- Argh. "It's" --> "Its". Damn mobile Slashdot, with its goddamn lack of preview-before-post and tiny 4-line input box. :-(
It's REAL market is more likely to be, "people who want to use their phone (or at least, its case) for company email & groupware, but don't want to hand over control of what's literally their most intimate and private data, to their company's IT staff... or at least, compromise the functionality & performance of their own phone by installing invasive MDM software".
In other words, it's a sacrificial device to let your company's IT staff fuck up so you can spare your REAL one from the same fate.
Why iPhone? Because it's just about the only phone whose models sell enough identical-form devices AND has a market life longer than the 9-15 months typical for most Android devices. The Galaxy S3 was one of the very, very few Android phones that ever came close (re both total sales AND useful market life). The S8 might sell more in 6 months than the S3 sold in two years, but it'll probably be replaced by the S9 6-9 months after the S8's release, and officially discontinued the same day.
I can DEFINITELY see someone like Huawei or HTC making a future phone that's basically two independent Android devices sharing one battery. Samsung, probably not, because then they'd have to admit that consumers have legitimate complaints about Knox (complaints mostly due to later changes made at the demand of large enterprise customers... Knox infrastructure ITSELF is fairly benign, but the MDM software used to configure & administer it is as bad as any other MDM thanks to LATER demands imposed by large enterprise customers who insisted upon having complete control over the entire device, as opposed to settling for complete control over Knox's VM and virtual encrypted filesystem).
It's worse in Florida. ~25 years ago, the Florida utility regulators agreed to let BellSouth basically DOUBLE the cost of local phone service to finance laying fiber to ~80% of customers within 10 years. The deadline came & went, and circa 2010, someone in the state capital who examined AT&T's actual deployment discovered that 99% of the fiber laid by AT&T since ~2006 was serving (... drumroll ...) nothing but AT&T cell towers. AT&T was counting potential wireless customers within range of a fiber-connected tower as 'served by fiber', and filed documents claiming that U-verse was available in areas were there wasn't even a VRAD.
It was a scandal so brazen & outrageous, even for a state that has historically been anti-regulation, that what's left of the state public service commission was threatening to levy HUGE fines against AT&T (and possibly seek prosecution for actual fraud). At the last second, AT&T somehow convinced them it was an honest mistake, and got them to let them have 5 more years to make U-verse available in all the places where they'd claimed it existed all along.
There were also areas like MY neighborhood, where they claimed U-verse was 'available to __-thousand residents', but was *really* limited to a few hundred, because they were running it from a distant VRAD whose capacity had been maxed out for YEARS. I know, because when I bought my house, I made a POINT of verifying that DSL was available... then found out that I couldn't actually GET it unless someone else quit AND I got lucky enough to call them after the port became available, but before someone else took it (not even a formal waiting list... literally, random luck)).
In Florida, AT&T acts like it's benevolently giving the gift of fiber (to the curb, mostly), but the truth is, Floridians have been PAYING for BellSouth & AT&T's fiber-laying since the 90s, and somewhere along the line, they were allowed to forget that.
(in BellSouth's defense, THEY mostly kept their end of the bargain. The problems began after AT&T bought BellSouth and 're-aligned' their capital improvement priorities).
India is UTC+5:30
If the US shifted its timezones by a half hour, Canada and Mexico would almost certainly follow, and Britain would probably do it within a year (most of my British friends like the later sunsets of BST, but despise the twice-annual clock changes).
^--- argh, I meant utc-4.5/-5.5/-7
Two timezones would suck, but three would make more sense... eastern = utc+4.5, central = utc+5.5, and Pacific=utc+7. Basically, splitting the difference for eastern & central, and making dst year-round in pacific. SoCal has ABSURDLY early sunrise & sunset compared to the east coast.
In theory, there IS a way to store passwords in a way that works kind of like a reversible hash... use RSA in "deterministic" mode ("RSA/ECB/NoPadding"). Basically, generate your keypair, and keep the private key offline and physically secured. When users register, use the public key to encrypt the salted password. When users subsequently authenticate, encrypt whatever they entered with the correct salt & compare the results, just like you would for a hash function. And if you someday ever need to do some kind of software migration that would otherwise require wholesale password resets, you can bring the private key out of storage and use it (on an offline computer) to decrypt a copy of the current passwords, then re-encrypt/hash them by whatever new means you're using.
Note that this is NOT the way RSA normally works. Usually, random padding gets added to the plaintext before encryption (and thrown away after decryption), to ensure that two identical plaintext inputs won't produce the same plaintext output. And even fairly LONG RSA keys can only encrypt a relatively small number of bytes. A 2048-bit RSA key is probably long enough to directly encrypt a 16-character password (assuming worst-case UTF-8 encoding and 4-6 bytes per character), and 1024 bits MIGHT be enough, but I'm pretty sure that 1024 bits would be the smallest power-of-two big enough to directly encrypt arbitrary passwords of reasonable length.
There are some sobering things to consider, though:
1. There's no official PKCS standard for doing this, which means you'll be using a scheme that hasn't been peer-validated, and has zero high-level support by any off the shelf software product. In regulated industries, the fact that it's not a PKCS standard will probably disqualify it outright.
2. There's more to encryption than dumping bytes into a black box, ESPECIALLY when it comes to RSA (google "textbook RSA OAEP" (sans quotes) for the gory details of what happens when you try using Schneier's "Applied Cryptography" as an implementation cookbook rather than as a high-level introduction). Reference: http://crypto.stackexchange.co...
3. If you're planning to use BouncyCastle, I'm pretty sure I remember reading that deterministic RSA ciphertext isn't deterministic across platforms. In other words, if you encrypted a given plaintext with key in a C# program under Windows, you wouldn't necessarily get the exact same output if you ran a program written in C++ running on Linux with the same plaintext and key. They'd both DECRYPT to the same original plaintext, but the encrypted bytes wouldn't necessarily be identical on both platforms.
Is this more secure than storing the passwords in plaintext? Unquestionably.
Is this more secure than encrypting the passwords with AES, using a key protected only by filesystem security? Probably.
Is this more secure than storing the original passwords using the most robust mode of RSA currently available, alongside a salted SHA256 hash that's used for routine authentication? I don't know. I'm pretty sure that giving attackers two copies derived from the same plaintext reduces their aggregate security, but I don't know whether the resulting, diminished security would be better or worse than using deterministic RSA to encrypt the password instead.
The gold standard, probably enshrined in at least one PKCS standard, would almost certainly involve hardware PKI... very, very expensive hardware PKI.
TL/DR: deterministic RSA is probably the least-bad option available to someone not required to follow PKCS standards, but it's kind of like transpolar air traffic(*)... a few guidelines, but you're pretty much on your own and fucked if anything goes wrong.
Because browser-based webapps fscking SUCK compared to any halfway-competent native app. Javascript is dog-ass slow on mobile devices, and the user experience is AWFUL. Go ahead, go compare the experience of using walmart.com, amazon.com, or homedepot.com to the experience of using their native apps. It's a night & day difference. The webapps are a minefield of continually-reflowing content with a knack for changing the spot you were trying to touch 250ms ago into some goddamn other link. My blood pressure usually goes up by at least 40mmHg due to frustrated rage whenever I'm forced to use some awful webapp on a mobile device (especially when content reflows the moment before I touch the screen, triggering something that takes 30 seconds or more to recover from).
> Seriously, unless you're part of a big corp with big corp lawyers
> and money behind you why develop for Apple?
Ok, here's a challenge: write an Android-only app to collaborate or organize some kind of group activity, then try to get any real-world group (besides literal Android developers) to USE it. The moment somebody realizes it can't be used by group members with iPhones & iPads, your app will become dead and irrelevant to that group, unless it's LITERALLY a group overwhelmingly comprised of Android users (or whose leaders can get away with brushing off the complaints of iOS users). To be viable and be taken seriously now, you HAVE to support both platforms.
For anyone who's interested, here's how to forcibly format a drive with UDF under Windows:
format [driveletter]: /fs:UDF
It MUST be done from a command prompt. It MIGHT require an admin command prompt (don't remember offhand). You can't do it via Windows Explorer.
If you can live with 25gb capacity, the most cost-effective current medium you can get is non-LTH BD-R.
M-Disk is just a non-LTH BD-R disc with the spiral geometry and pit dimensions of a DVD. It's a nifty idea, but unless you LITERALLY have to be able to stick the disc into a consumer DVD player and watch it directly, you'll get the same data-durability and save a substantial amount of money by just ripping your DVDs to .iso files & writing several of them to a single BD-R disc. Likewise, unless you need to be able to read your files on a PC that can't read Blu-Ray discs, there's NO GOOD REASON to buy M-Disks instead of non-LTH BD-R discs.
Well, OK, I can think of one... even if you know what you're looking for, trying to buy non-LTH BD-R discs is kind of like trying to buy a multi-TT USB hub... it's rarely advertised as an explicit feature, so you can spend literally HOURS combing through product listings at Amazon & Newegg looking for the non-LTH needle in a growing haystack of LTH discs (searching rarely works, because the fucking search algorithms at Amazon and Newegg treat "LTH" as a match for "non-LTH". Whereas if the disc is branded "M-Disk" and has a capacity of 25gb, you know beyond doubt that it's non-LTH BD-R.
Or, a hundred times worse than QIC... QIC-EXtra, which only really worked with Verbatim's own backup software.
Verbatim's scam:
1. Bundle a free "SE" version of their backup software that could "sort of" make backups under Windows 9x, but crashed too easily and often to reliably restore files from the backup later.
2. Release an expensive "Pro" edition of the backup software that fixed the worst of those bugs.
3. Excuse the SE version's near-unusability by saying, "well, maybe the Windows 9x SE version IS kind of buggy... but the free DOS version should still work". Except the DOS version had no concept of long filenames, so it couldn't be used to restore a full system backup to a blank hard drive. Using it to restore a backup was more like picking through the wreckage that used to be your house after a hurricane reduces it to a debris pile.
4. ???
5. Profit.
The thing is, most of those old games WEREN'T 'really' 30hz... they were 60fps.
A NTSC display could only display 30 complete frames per second, but the video chips on most legacy games didn't send complete frames... they sent 60 FIELDS per second (each of which contained ONLY the odd or even scanlines from each frame). CRT TVs were "dumb", and depended on the video signal itself to tell them whether the next field was odd or even (with one shifted vertically to fill the gaps between the other). So games simply never TOLD the CRT that a field should be shifted, allowing those 60 fields to be repeatedly drawn over the same half of the scanlines while the remaining half remained dark.
This actually caused problems with a lot of first-gen LCD TVs. They'd buffer a field, buffer the next, then freak out when they couldn't decide which one was supposed to be "even" and which one was supposed to be "odd". The usual result was either an empty blue screen (possibly with something like "invalid signal" displayed as well), or a mangled mishmash with what were SUPPOSED to be two independent 60fps frames forcibly-interleaved into the same 60fps frame and shown twice in a row.
In any case, even if the native framerate WERE 30fps, high-bandwidth VRAM can solve the problem for you... buffer a few scanlines, then do the effects processing in the time it takes a later scanline to do its horizontal retrace and output the whole thing through the VRAM's back door, so you're only adding a few scanlines' worth of latency instead of an entire frame's worth.
Actually, you're allowed to make a 'reasonable' number of phone calls, though after repeated refused or unanswered calls to friends & family members, you might be told you're going to have to wait a while unless you want to call someone like a law firm that's almost guaranteed to answer. The 'one phone call' meme is a Hollywood construct that would never survive legal challenge, though there's probably room to disagree about the definition of 'reasonable'.
Moore's Law is merely an observation about the NUMBER OF TRANSISTORS on a die, not computing power.
In theory, Intel and AMD could probably make 64-core CPUs a retail reality within a year or two... but with current programming languages, it would be almost pointless. Multithreading exists, of course... but few apps besides raytracing can genuinely put it to good use. As a practical matter, 99% of the benefit from having multiple cores comes from being able to run Windows UI threads on one core, and whatever app is in the foreground on the second. With Windows itself spinning off API calls from the app onto cores 3 and beyond when it gets the chance to do so.
Windows does a decent job of passively putting multiple cores to good use, but its ability to do that mostly depends upon having access to the benefits of x86/AMD64 architecture at its disposal. Historically, Linux has done a TERRIBLE job of passively putting multiple cores to good use without explicit multithreading attempts by the app's programmer, due to two main lines of reasoning:
a) If the developer intended for the program to multithread, he would have written it that way... IMHO, more of an excuse, because the fact is, current programming languages aren't all that great at handling concurrency without major gymnastics. 25 years ago, we had spaghetti code as an anti-pattern. Now, we have a rat's nest of spaghetti async threads that are almost impossible to grasp without referring to a wall-sized UML diagram.
b) Many of the things Windows does to passively put multiple cores to good use depend upon the "strong" memory model of x86/AMD64 CPUs. I believe this is actually the biggest current reason why Linux doesn't try as hard as Windows to passively multithread apps written to be single-threaded... and the reason why there were several entire generations of multi-core Android phones that didn't actually do a single damn thing with the extra cores besides brag about them in the marketing literature. Basically, on x86/AMD64, if thread #1 updates a byte of ram, thread #2 running on another core attempts to read it, the CPU will automagically make the change instantly visible to the second core. On ARM, that's rarely/never the case. With a language like Java, x86/AMD64 hides lots of programming sins that will cause the exact same code to crash and burn on ARM.
TL/DR: we COULD have CPUs with a lot more cores than 4, 6, or 8... but current software wouldn't put them to good use, so there's almost no real market for them besides servers and mainframes.
You'll need "Prime Luna", which will probably cost about $890 million/year (but include free Terrestrial Prime for up to 10,000 friends & family members, plus unlimited one-hour(*) digital delivery to the moon of media content). If they launch monthly, shipping will be free with delivery within 2 months, $3 million for next-month, and $11 million for next-launch.
(*) when we're finally on the moon for real, broadband internet (with high latency and frequent outages, but respectable average throughput over the span of an hour) will probably be a given, limited mostly by the ability to aim and focus lasers between geostationary satellites & earth (in theory, you could put the relay stations along the literal equator & aim straight up or down to/from geostationary satellites, and achieve near-fiber throughput... at least, on non-cloudy nights).
On the downside, lots of PC games are semi-dysfunctional if you insist on playing them with a gamepad on a TV across the room, because they were developed for mouse+keyboard play while seated at a desk.
Illustrative case in point: "Flockers" for xb1 & Steam. The Steam version is literally unplayable on a HTPC across the room with XBox-like gamepad. And this is almost the golden porting scenario... a game that *has* perfectly-usable controls on the console version, and one is almost a verbatim port of the other.
Sadly, it's far from being the only one. I bought Super Giana Sisters for *both* Wii-U and Steam. The Steam version is much, MUCH harder to play with a gamepad (it feels 'twitchy' compared to the wii-u version)... and this is a game where they explicitly TRIED to fully-support gamepad play.
As I understand it, the problem lies with the fact that the analog sticks are interpreted by the gamepad hardware, and they all come up with slightly different values for a given position. With a Wii-U, you know beyond doubt that player 1 is using a specific controller with known response, but with PCs, every stick is slightly different.
The problem is, it's *NOT* "more screen", because they're the same size and resolution as similar phones that *have* dedicated buttons. It's a pure anti-feature that companies have somehow managed to spin into a selling point. :-(
Case in point: Nexus 6P vs Galaxy Note 4. Literally identical displays, but the 6P technically doesn't even get detected as 'widescreen' (for layout alternate resource purposes) because Android subtracts the height of the softkey area from the vertical resolution, and the resulting ratio ends up being .00000001% below the threshold for 'widescreen'.
er... any "text message" you send with embedded photos, more than ~160 characters, or to multiple people, is REALLY sent as MMS (by the default text-message app that comes with Android Nexus phones, at least).
News of MMS's death are wildly exaggerated. If anything, it's the de-facto current standard *for* "text" messages.
There's a straightforward reason why lots of web apps continued to use MD5 *long* after it was deprecated: MySQL had a function for md5() almost from the start, but didn't have an inline function for SHA() until 4.0.2... and 4.x didn't become the default version in long-term stable server-oriented distros until 2006 or later. Getting a new release to run on YOUR development computer? Easy. Convincing an enterprise sysadmin to let you have it on a production server before it has become the 'stable' default *and* the servers have been upgraded to the new distro release? Good luck. Most developers don't have the social capital & stamina to campaign for newer versions from stubborn admins, and will just say 'fuck it' and use MD5 if their boss isn't ready to fight that battle for them.
> You get a massive speed increase if you switch to a better filesystem:
> btrfs or f2fs.
For the record, no stock Android kernel I'm aware of allows you to use anything besides FAT, FAT32, or exFAT on a microSD card since sometime between Jellybean and KitKat (some custom kernels restore that capability), for reasons known only to Google. :-(
As bad as their random-read performance is, their random-WRITE performance is usually much, MUCH worse. And almost none do their own wear-leveling, so a Linux swapfile can literally max out the lifetime writes of a microSD card in 1-3 months (because the multi-million stat assumes well-distributed block erasures & writes... if you're scrubbing away at the same few blocks, you'll wear it out in a FRACTION of the rated write-life. That's why AOSP Android ROMs (generally) won't allow you to create a swap partition on internal flash... you could ruin the entire phone.
Except for one small problem: the Declaration of Independence carries NO weight in constitutional law.