All while the FBI knows how to break in, giving everybody a false sense of security.
Judge: What was the source of this information?
FBI: Uhm... a hunch?
Yeah, you see, they'd have to admit the ability in open court for it to be useful. Otherwise, they have to explain to the court how they got information that only existed in one place: on the phone. And if they make up some bullshit, while the court may buy it in isolation, that bullshit does not live in isolation, it lives in a world where the defense attorney can point out that the data the FBI claims to have only exists on the device the FBI claims they can't access, so the data is inadmissible as evidence because either the FBI is lying about the content (e.g. they made the data up because they couldn't actually get at it) or lying about how they got it.
Our legal system has its flaws; this is not one of them.
Ladies and gentlemen, what we have here is an example of a well-thought-out solution! As expected, it came from someone other than the poster of the initial suggestion (who rather opted to defend it in the face of a critical flaw). This is the kind of discourse that used to make Slashdot great; is Slashdot becoming great again?
While this does solve the inability to employ any theft (or abuse) detection measures by keeping one of the signatures local, and prevents the 3rd party from abusing the key (through the same measure), it still doesn't address the issue of Apple signing dozens, if not hundreds, of binaries daily in the course of development and testing. It's possible (likely, even, given that you replied this far up in the thread) that you had not read those objections to anwyn's similar (but severely flawed) suggestion, so I won't hold that against your suggestion; I'll just point out that, from a practicality standpoint, the signing process needs to be able to happen as quickly as possible, which can't happen when a 3rd party is involved.
I'm interested to hear any solutions you may have for that which don't involve compromising the security of the system (e.g. allowing Apple to push to the 3rd party's system for automated signing, which would require leaving that system accessible via the internet, potentially allowing anyone else to do the same -- after coercing the other key from Apple).
And this is why I still believe that it is best for Apple to keep the one and only key local and employ theft (and abuse) detection measures. They can immediately release one final update signed with the stolen (or abused) key, to update devices to no longer honor that key, replacing it with a new one. In that way, only devices which people refuse to update remain vulnerable to update exploits via the stolen key, which we can consider to be a non-issue, since it is unlikely that a user who isn't installing any updates will install a rogue update. Sure, it could be forced onto their device by someone with physical access, but those really aren't the users we're worried about here, anyway.
Apple should ride this out, let the DOJ sue and, if the DOJ wins, hand over the source and key, then do the above.
As for why an additional 3rd party signature actually makes this less secure: a knowledgeable attacker would already have access to the other key before going after the key Apple keeps locally. Then, it becomes a race; can the attacker get their exploit distributed before the 3rd party signer signs Apple's fix? By taking the 3rd party out of the equation, you take away the attacker's potential advantage; only Apple needs to sign the fix and Apple can do that quite quickly.
Sure, that wouldn't help in this instance, with this phone. But, as has been repeated throughout every discussion on this topic, this isn't about this phone, it's about all the others.
Never is the only option for something like leaking or misuse of a signing key used to authenticate binaries for a supposedly unbreakable system. If that key ever gets out without Apple's knowledge, the security of the system disappears entirely. If it's in-house, they can at least employ theft detection measures and immediately release an update to invalidate the old key and replace it with a new one, limiting the potential damage to those few who refuse to update (who won't be affected by a rogue update anyway because, well, I'll let you figure that one out yourself).
Requiring multiple signers also requires that the individual signers do not know anout each other, so they can't track each other down and collaborate. The other issue with 3rd party signing, which comes into play at that point, is that someone still needs to know who each signer is (multiple someones, because bus problem) and the signers really have no idea what they're being asked to sign. For security, of course, you would send them the binary to sign, they would send it back, you would send it to the next signer, lather, rinse, repeat; you wouldn't give them access to your systems, where a single bad actor outside of your jurisdictiom might be able to access proprietary information or learn who the other signers are (for the above-stated reason). This means that anyone who knows who the signers are can request that they sign pretty much anything and, since the internal detection mechanism can't exist with external signing, you would never know they did it.
But, ignoring all of that, let's look at the practical aspect of this: Apple signs dozens, if not hundreds, of binaries every single day during the course of development and testing. That needs to be able to happen as quickly and reliably as possible. Period.
It was a good thought, on the surface. You clearly didn't step back and actually look for flaws, though. That's okay, that's what open discourse is for. Hopefully you take this opportunity to learn something, rather than taking the common Slashdot path of ignorance.
Right, because people of good character can never be coerced into becoming bad actors. Right. I guess, if you find someone with no remaining living relatives or friends and no addictions or unmet needs, you'll have found the one person in the world nobody can leverage in any way. Good luck with that.
They could, but then that foreign contractor could sign anything as Apple; and they'd be outside of a jurisdiction where Apple could reasonably have any recourse.
This is one of the rare instances where that won't work, as the value of the property is measured in $US; the value will increase as the value of the dollar decreases as more are printed for the purchase, meaning more would need to be printed to offset that increase, lather, rinse, repeat.
While it will, technically, eventually reach an equilibrium, consider that $600B is half of the $1.2T currently in circulation; by printing 50% more cash than is currently in circulation, the value of the dollar will be reduced by 1/3. You're printing 50% more money ($1.8T in circulation), driving up the value of everything else by 50% in the process, and the value of the IP becomes $900B. Printing another $300B ($2.1T in circulation) reduces the value of the dollar by another 14.29% (or, rather, increases the value of the IP by another 16.667%, to $1.05T). Printing the $105B ($2.205T in circulation) to cover that drops the value of the dollar by another 5%, effectively increasing the value of the IP to $1.105T (5.24%). Printing the additional $55B ($2.26T in circulation) to cover that drives up the value of the IP to $1.13T (2.26%). Printing the additional $25B ($2.285T in circulation) increases the value of the IP to $1.1425T (1.11%). It continues for a few more iterations before the discrepancy falls to an acceptable level for this type of "purchase".
By the time this happens, we've more than doubled the amount of money in circulation, doubled the cost of everything, and the top 1% wealth holders would be rendered middle class (and everyone below them, including the politicians pulling the money strings, poor) by printing all of this money, having given half the nation's wealth to a handful of Apple execs.
All to unlock a few phones.
Nope, if they want it, they'll wipe their asses with the constitution and take it. And we'll just sit back and watch because we're a nation of little whiny bitches. Even those of us who would do something are rendered powerless by the inaction of our fellow citizens. It will take a majority of the populace to fix this, while only a handful of us even know there's a problem and and even smaller number of that group might be willing to stand up to change it in the first place.
Do it, DOJ. Go ahead and do it. Apple will push one final update with that signing key, updating the signing key for future updates, them immediately push another update, signed with the new key, to disable rollbacks. You'll be able to use the source and signing key for devices which don't receive that first update, which will include any currently in your possession, but you won't get shit beyond that.
Actually, if the 1TB drive is using 2 500GB platters, they'd be lowering the density whether they used 1 or 2 platters. Or, perhaps they use a single 500GB platter and underprovision it, so they're saving on one platter while using existing parts and capitalize on a marketing opportunity.
Unless my understanding of math is wrong and 314 is suddenly more than 500.
And there are transaction rollback procedures in place in case that engineer or IT guy misbehaves. If Bangledesh Bank hadn't revoked the credentials, then why should the Federal Reserve bank not have trusted them? Your transaction credentials are your identity in the banking system; telling another bank not to trust your (valid and not revoked or reported compromised) credentials is effectively telling them not to trust you. I'll repeat myself: if that's what Bangledesh Bank wants, it's what they should get. they don't want their credentials to be trusted by foreign banks, let foreign banks not trust them, remove them from the world banking system, and see how long it takes them to take responsibility for their own security, fix the issue that allowed this in the first place, and come begging to once again participate in the world banking system. I give them a day or two to take responsibility and start begging, before being told to fix their shit and try again, a year or so to fix it (we're talking about government, i'm being generous), and another year to redevelop their relationships with the rest of the world banks.
You don't play soccer without a cup, then blame the other players, take your ball, and go home when you get a cleat to the nuts. That's basically what Bangledesh is doing here.
I'm not sure where you get "be a crook" from Aighearach's comment, even if you only consider the portion you quoted.
because they can't force me to watch their content
That would seem to imply that, if they wish to force the ads, the remaining option is to simply not watch, rather than steal. In fact, the very next sentence confirms this:
I would give up their content before watching ads
Most people choose to build their strawmen from straw, you seem to have chosen to use willful ignorance. No matter, really, as both burn equally well.
You do realize that Firefox has, and has had, add-on functionality for most of its existence, right? System integration is already in the hands of the user, I'm merely proposing that some features that aren't central to the role of a web browser not be included as native functionality but, rather, as add-ons, utilizing the add-on functionality that already exists. The risk of adding inefficiency would be minimal, as the add-on functionality already exists, while doing so would introduce the ability to increase efficiency by stripping out functionality we don't want or need. Currently, the only way most users can remove such functionality is to use an add-on to hide it; the functionality is still present, only now you're running additional code and further reducing efficiency to give the appearance that the functionality has been removed. And, by bundling the default set (and activating them by default), you're not sticking the user with a system integration task,; from their perspective, if they don't want the task, they'd be getting exactly the same thing they're getting now, it would literally be no different for those users.
<sarc>But yes, of course, you're right, what we have now is many time more efficient and making it possible for power users to better customize the browser and make it more resemble what once made it great, while providing regular users with the same out-of-box experience they currently enjoy would just be a horrible idea.</sarc>
In reality, you just sound like a Mozilla developer afraid he might have to implement some of this at some point.
So you don't disagree with me at all, then; they should bundle a default set of add-ons that most people will use, so there is no confusion about which add-ons to "pull down". they could ship with the exact same functionality they do today, just with most of it as (bundles) add-ons, which can be removed if not wanted.
Perhaps, if you had read my entire post, you'd get that you basically just argued for exactly what I was saying: make any extra functionality an add-on (so users like you and I can remove the cruft we don't want) and bundle a set of defaults (so everyone else doesn't have to remember what to install).
I get it, though. I really do. You're sitting here arguing against doing any extra work, how could I possibly expect you to do the "extra" work of reading and understanding what I've written before you reply?
Right. You shouldn't need an add-on to remove functionality from your browser! Mozilla, do you hear this?! All these features and crap they're shipping native were the entire reason for add-ons in the first place. If they wanted to ship with these features, they should have developed them as add-ons and bundled those with the distribution; then, anyone who didn't want the features could simply remove them and make their browser faster and lighter rather than the current situation, where one must install addons to disable the functionality, making the browser heavier and slower.
Mozilla had the browser market wrapped up precisely because of how powerful their add-ons were, allowing an ultra-light stripped-down browser where that was wanted and a super-massive do-everything browser where that was preferred. Now? Now, we have the option of a super-massive do-everything browser, or a super-massive stripped-down (by way of add-ons to remove functionality, rather than add it) browser, in a world where Windows tablets with 2GB of RAM aren't uncommon. Sadly, this has made me switch to Chrome, which has its own set of issues I'd also rather not deal with. All because Mozilla couldn't be assed to eat their own dogfood and develop features not every user might be interested in as add-ons, which they could bundle with the browser and allow the user to remove if they don't want them.
My suggestion to Mozilla, which I'll submit to them directly in addition to posting here, is to implement any features above and beyond those required for a basic functional modern web browser (that list includes rendering HTML and CSS pages, javascript mostly because it is required for add-ons in the first place, and support for common protocols: HTTP and HTTPS, possibly SPDY) natively and re-implement everything else as add-ons. Go ahead and bundle them, but make it possible for users to remove (not just disable) them. And if you're concerned with performance, implement a native add-on API, so you can compile those add-ons along with the browser (but, again, as their own separate executables), rather than developing them in javascript.
In short, give us the ability to once again have a browser that is both bare-bones and lightweight, while retaining the ability to add on every function under the sun. You know, what made Firefox great a decade ago.
You can use a 16x lane PCIe 3 in a breakout box now? Remember, we're talking about modern high-end GPUs, which will "work" in a PCIe 2.0 slot, but the performance would be roughly equivalent of simply sharing the faster 16x PCIe 3.0 connected GPU already in the machine. For reference, Thunderbolt 1 and 2 offer the same two 4x lanes, Thunderbolt 2 simply allows the lanes to be combined and used as an 8x lane. Whoops, I guess you can't do that, then. You could in the towers, but then, the best of those only supported PCIe 2.0 and, thus had the same problem. In fact, the new Mac Pro 40GB/sec of PCIe bandwidth, of which 32GB/sec will be used by the two FirePro GPUs leaving, at best, a single 8x lane. Even if Apple's claimed 40GB/sec is after the GPUs (which are in a crossfire configuration so no, you can't deditate one to one VM andthe other to another), you still can't get around Thunderbolt's 8x lane limitation, nor can you duplicate its internal setup (which is two 16x PCIe GPUs in a crossfire configuration) in one. On a multi CPU Xeon system (and I've personally seen systems with 4), there are enough 16x lanes to do this 8 times over (16 GPUs) in a proper tower; though, admittedly, you may run into issues finding a motherboard and case to support it. Too bad you can't run OS X on that, though. But even not going that high-end, a dual-CPU Xeon PC could support 8 16x PCIe 3.0 GPUs in 4 crossfire or SLI pairs, something you just can't do with any Mac. Oh, and proper cooling so the system doesn't throttle itself under extended periods of high load, such as those a proper workstation in the hands of someone who actually needs that level of compute power will see on a regular basis.
This isn't a stab at Apple, either, just a cold statement of fact. I wish it weren't true, I wish I could get the performance out of a Mac that I can get out of a PC, but I simply can not, so I have to use a PC for such things. Even on the laptop side of things, I can't buy an Apple product today that competes with the MSI gaming rig I picked up in November, a model that is a combination of slightly thinner, somewhat lighter, roughly half the price, and faster overall (and without the thermal throttling that my Retina MBP experiences under load; neigh the hottest this machine gets under extended full load is just barely warmer than the rMBP at idle) than the fastest laptop Apple offers. That's without mentioning that the 970M with 6GB of GDDR5 absolutely eats the lunch of anything Apple offers, with the exception of the Mac Pro, which can be configured with GPUs that will outperform it (and admittedly by a large margin) for certain tasks.
Again, I wish the above weren't true, but there you have it. Facts are facts and Macs aren't for heavy lifting; even Photoshop and other Adobe apps that used to absolutely run better on a Mac have been better off on a mid-range (and much cheaper) PC for some time now.
Apple has a target market and they serve it very well. I'm simply not in that market and, as I have interest in getting actual work done, won't attempt to shoehorn myself into that market. Nobody else with any knowledge and a need for true performance would, either. They're great consumer machines, I have one (that I don't use for work), and I hope to see them completely dominate that market, but lets be real here, they haven't sold a true workhorse of a system (with proper cooling and the ability to run full-tilt for a few minutes, let alone hours or days, without throttling) since Jobs died; the last refresh of the Mac Pro tower was a joke, with hardware one generation newer than the last refresh but still a generation behind.
I'll ask you again, since you keep making the same false claim: the trash-can models that are currently being sold new? Or the old tower models that haven't been updated in half a decade? Because this discussion os about the former but I'm beyong positive you keep ranting about the latter.
In the trash-can model? Because that's what we're talking about here. And no, Thunderbolt breakouts don't really work if you need the performance of a 16x lane.
What you can't do ia the thing I was actually talking about doing: assign each guest OS its own desicated physical GPU, network interface, etc. You can't do this because you literally can not install the hardware into a current Mac. You could on the towers but you can't on the trash can; that is the complaint. You literally can not use the most useful features of a proper hypervisor on a current Mac.
You don't know whay a proper hypervisor is, then, so allow me to explain. A proper hypervisor is, itself , the host OS. It occupies a small bit of RAM and a few CPU cycles, allowing for most hardware to be directly accessed by the guest OSes, though certain things (video and networking for instance) are often virtualized when there are more guests needing access to the hardware than there is physical hardware. That is to say, a proper hypervisorballows you to literally run multiple OSes on the same physical machine, each with its own dedicated hardware if you happen to have it available. You can't utilize dedicated, non-virtualized graphics and networking in this way on a Mac, though, because you can't install multiple graphics or network cards in one.
An example of a proper hypervisor is VMWare ESXi, which is its own OS and does not run on OS X (it would actually be the other way around). While OS X can run on ESXi, it can only do so on Apple hardware, which, as mentioned above, can't utilize the most useful features.
I'll admit I havent played WoW in literally forever (as in.. never) and got my wife to stop years ago, so I haven't seen it on a whike, but it was pretty textur-rich last time I saw her play. Cartoonish, yes, but not all solids and blocks. It also uses shaders, lots and lots of shaders, which workstation cards tend to have fewer of.
Slashdot Mirror
Because they're a US company, so what happens here affects all phones they sell, and not just the ones they sell in the UK.
All while the FBI knows how to break in, giving everybody a false sense of security.
Judge: What was the source of this information?
FBI: Uhm... a hunch?
Yeah, you see, they'd have to admit the ability in open court for it to be useful. Otherwise, they have to explain to the court how they got information that only existed in one place: on the phone. And if they make up some bullshit, while the court may buy it in isolation, that bullshit does not live in isolation, it lives in a world where the defense attorney can point out that the data the FBI claims to have only exists on the device the FBI claims they can't access, so the data is inadmissible as evidence because either the FBI is lying about the content (e.g. they made the data up because they couldn't actually get at it) or lying about how they got it.
Our legal system has its flaws; this is not one of them.
Ladies and gentlemen, what we have here is an example of a well-thought-out solution! As expected, it came from someone other than the poster of the initial suggestion (who rather opted to defend it in the face of a critical flaw). This is the kind of discourse that used to make Slashdot great; is Slashdot becoming great again?
While this does solve the inability to employ any theft (or abuse) detection measures by keeping one of the signatures local, and prevents the 3rd party from abusing the key (through the same measure), it still doesn't address the issue of Apple signing dozens, if not hundreds, of binaries daily in the course of development and testing. It's possible (likely, even, given that you replied this far up in the thread) that you had not read those objections to anwyn's similar (but severely flawed) suggestion, so I won't hold that against your suggestion; I'll just point out that, from a practicality standpoint, the signing process needs to be able to happen as quickly as possible, which can't happen when a 3rd party is involved.
I'm interested to hear any solutions you may have for that which don't involve compromising the security of the system (e.g. allowing Apple to push to the 3rd party's system for automated signing, which would require leaving that system accessible via the internet, potentially allowing anyone else to do the same -- after coercing the other key from Apple).
And this is why I still believe that it is best for Apple to keep the one and only key local and employ theft (and abuse) detection measures. They can immediately release one final update signed with the stolen (or abused) key, to update devices to no longer honor that key, replacing it with a new one. In that way, only devices which people refuse to update remain vulnerable to update exploits via the stolen key, which we can consider to be a non-issue, since it is unlikely that a user who isn't installing any updates will install a rogue update. Sure, it could be forced onto their device by someone with physical access, but those really aren't the users we're worried about here, anyway.
Apple should ride this out, let the DOJ sue and, if the DOJ wins, hand over the source and key, then do the above.
As for why an additional 3rd party signature actually makes this less secure: a knowledgeable attacker would already have access to the other key before going after the key Apple keeps locally. Then, it becomes a race; can the attacker get their exploit distributed before the 3rd party signer signs Apple's fix? By taking the 3rd party out of the equation, you take away the attacker's potential advantage; only Apple needs to sign the fix and Apple can do that quite quickly.
Sure, that wouldn't help in this instance, with this phone. But, as has been repeated throughout every discussion on this topic, this isn't about this phone, it's about all the others.
Never is the only option for something like leaking or misuse of a signing key used to authenticate binaries for a supposedly unbreakable system. If that key ever gets out without Apple's knowledge, the security of the system disappears entirely. If it's in-house, they can at least employ theft detection measures and immediately release an update to invalidate the old key and replace it with a new one, limiting the potential damage to those few who refuse to update (who won't be affected by a rogue update anyway because, well, I'll let you figure that one out yourself).
Requiring multiple signers also requires that the individual signers do not know anout each other, so they can't track each other down and collaborate. The other issue with 3rd party signing, which comes into play at that point, is that someone still needs to know who each signer is (multiple someones, because bus problem) and the signers really have no idea what they're being asked to sign. For security, of course, you would send them the binary to sign, they would send it back, you would send it to the next signer, lather, rinse, repeat; you wouldn't give them access to your systems, where a single bad actor outside of your jurisdictiom might be able to access proprietary information or learn who the other signers are (for the above-stated reason). This means that anyone who knows who the signers are can request that they sign pretty much anything and, since the internal detection mechanism can't exist with external signing, you would never know they did it.
But, ignoring all of that, let's look at the practical aspect of this: Apple signs dozens, if not hundreds, of binaries every single day during the course of development and testing. That needs to be able to happen as quickly and reliably as possible. Period.
It was a good thought, on the surface. You clearly didn't step back and actually look for flaws, though. That's okay, that's what open discourse is for. Hopefully you take this opportunity to learn something, rather than taking the common Slashdot path of ignorance.
Right, because people of good character can never be coerced into becoming bad actors. Right. I guess, if you find someone with no remaining living relatives or friends and no addictions or unmet needs, you'll have found the one person in the world nobody can leverage in any way. Good luck with that.
They could, but then that foreign contractor could sign anything as Apple; and they'd be outside of a jurisdiction where Apple could reasonably have any recourse.
This is one of the rare instances where that won't work, as the value of the property is measured in $US; the value will increase as the value of the dollar decreases as more are printed for the purchase, meaning more would need to be printed to offset that increase, lather, rinse, repeat.
While it will, technically, eventually reach an equilibrium, consider that $600B is half of the $1.2T currently in circulation; by printing 50% more cash than is currently in circulation, the value of the dollar will be reduced by 1/3. You're printing 50% more money ($1.8T in circulation), driving up the value of everything else by 50% in the process, and the value of the IP becomes $900B. Printing another $300B ($2.1T in circulation) reduces the value of the dollar by another 14.29% (or, rather, increases the value of the IP by another 16.667%, to $1.05T). Printing the $105B ($2.205T in circulation) to cover that drops the value of the dollar by another 5%, effectively increasing the value of the IP to $1.105T (5.24%). Printing the additional $55B ($2.26T in circulation) to cover that drives up the value of the IP to $1.13T (2.26%). Printing the additional $25B ($2.285T in circulation) increases the value of the IP to $1.1425T (1.11%). It continues for a few more iterations before the discrepancy falls to an acceptable level for this type of "purchase".
By the time this happens, we've more than doubled the amount of money in circulation, doubled the cost of everything, and the top 1% wealth holders would be rendered middle class (and everyone below them, including the politicians pulling the money strings, poor) by printing all of this money, having given half the nation's wealth to a handful of Apple execs.
All to unlock a few phones.
Nope, if they want it, they'll wipe their asses with the constitution and take it. And we'll just sit back and watch because we're a nation of little whiny bitches. Even those of us who would do something are rendered powerless by the inaction of our fellow citizens. It will take a majority of the populace to fix this, while only a handful of us even know there's a problem and and even smaller number of that group might be willing to stand up to change it in the first place.
Time to stock up on Vaseline and KY.
Do it, DOJ. Go ahead and do it. Apple will push one final update with that signing key, updating the signing key for future updates, them immediately push another update, signed with the new key, to disable rollbacks. You'll be able to use the source and signing key for devices which don't receive that first update, which will include any currently in your possession, but you won't get shit beyond that.
Go for it.
And we appreciate you whipping slash into shape, Whipslash ;)
Actually, if the 1TB drive is using 2 500GB platters, they'd be lowering the density whether they used 1 or 2 platters. Or, perhaps they use a single 500GB platter and underprovision it, so they're saving on one platter while using existing parts and capitalize on a marketing opportunity.
Unless my understanding of math is wrong and 314 is suddenly more than 500.
And 9 is?
And there are transaction rollback procedures in place in case that engineer or IT guy misbehaves. If Bangledesh Bank hadn't revoked the credentials, then why should the Federal Reserve bank not have trusted them? Your transaction credentials are your identity in the banking system; telling another bank not to trust your (valid and not revoked or reported compromised) credentials is effectively telling them not to trust you. I'll repeat myself: if that's what Bangledesh Bank wants, it's what they should get. they don't want their credentials to be trusted by foreign banks, let foreign banks not trust them, remove them from the world banking system, and see how long it takes them to take responsibility for their own security, fix the issue that allowed this in the first place, and come begging to once again participate in the world banking system. I give them a day or two to take responsibility and start begging, before being told to fix their shit and try again, a year or so to fix it (we're talking about government, i'm being generous), and another year to redevelop their relationships with the rest of the world banks.
You don't play soccer without a cup, then blame the other players, take your ball, and go home when you get a cleat to the nuts. That's basically what Bangledesh is doing here.
because they can't force me to watch their content
That would seem to imply that, if they wish to force the ads, the remaining option is to simply not watch, rather than steal. In fact, the very next sentence confirms this:
I would give up their content before watching ads
Most people choose to build their strawmen from straw, you seem to have chosen to use willful ignorance. No matter, really, as both burn equally well.
This. It's almost like they don't want anyone trusting their credentials ever. I'd be game for that, actually.
You do realize that Firefox has, and has had, add-on functionality for most of its existence, right? System integration is already in the hands of the user, I'm merely proposing that some features that aren't central to the role of a web browser not be included as native functionality but, rather, as add-ons, utilizing the add-on functionality that already exists. The risk of adding inefficiency would be minimal, as the add-on functionality already exists, while doing so would introduce the ability to increase efficiency by stripping out functionality we don't want or need. Currently, the only way most users can remove such functionality is to use an add-on to hide it; the functionality is still present, only now you're running additional code and further reducing efficiency to give the appearance that the functionality has been removed. And, by bundling the default set (and activating them by default), you're not sticking the user with a system integration task,; from their perspective, if they don't want the task, they'd be getting exactly the same thing they're getting now, it would literally be no different for those users.
<sarc>But yes, of course, you're right, what we have now is many time more efficient and making it possible for power users to better customize the browser and make it more resemble what once made it great, while providing regular users with the same out-of-box experience they currently enjoy would just be a horrible idea.</sarc>
In reality, you just sound like a Mozilla developer afraid he might have to implement some of this at some point.
So you don't disagree with me at all, then; they should bundle a default set of add-ons that most people will use, so there is no confusion about which add-ons to "pull down". they could ship with the exact same functionality they do today, just with most of it as (bundles) add-ons, which can be removed if not wanted.
Perhaps, if you had read my entire post, you'd get that you basically just argued for exactly what I was saying: make any extra functionality an add-on (so users like you and I can remove the cruft we don't want) and bundle a set of defaults (so everyone else doesn't have to remember what to install).
I get it, though. I really do. You're sitting here arguing against doing any extra work, how could I possibly expect you to do the "extra" work of reading and understanding what I've written before you reply?
Sadly, I think you're right.
Because they all got the ask.
Right. You shouldn't need an add-on to remove functionality from your browser! Mozilla, do you hear this?! All these features and crap they're shipping native were the entire reason for add-ons in the first place. If they wanted to ship with these features, they should have developed them as add-ons and bundled those with the distribution; then, anyone who didn't want the features could simply remove them and make their browser faster and lighter rather than the current situation, where one must install addons to disable the functionality, making the browser heavier and slower.
Mozilla had the browser market wrapped up precisely because of how powerful their add-ons were, allowing an ultra-light stripped-down browser where that was wanted and a super-massive do-everything browser where that was preferred. Now? Now, we have the option of a super-massive do-everything browser, or a super-massive stripped-down (by way of add-ons to remove functionality, rather than add it) browser, in a world where Windows tablets with 2GB of RAM aren't uncommon. Sadly, this has made me switch to Chrome, which has its own set of issues I'd also rather not deal with. All because Mozilla couldn't be assed to eat their own dogfood and develop features not every user might be interested in as add-ons, which they could bundle with the browser and allow the user to remove if they don't want them.
My suggestion to Mozilla, which I'll submit to them directly in addition to posting here, is to implement any features above and beyond those required for a basic functional modern web browser (that list includes rendering HTML and CSS pages, javascript mostly because it is required for add-ons in the first place, and support for common protocols: HTTP and HTTPS, possibly SPDY) natively and re-implement everything else as add-ons. Go ahead and bundle them, but make it possible for users to remove (not just disable) them. And if you're concerned with performance, implement a native add-on API, so you can compile those add-ons along with the browser (but, again, as their own separate executables), rather than developing them in javascript.
In short, give us the ability to once again have a browser that is both bare-bones and lightweight, while retaining the ability to add on every function under the sun. You know, what made Firefox great a decade ago.
You can use a 16x lane PCIe 3 in a breakout box now? Remember, we're talking about modern high-end GPUs, which will "work" in a PCIe 2.0 slot, but the performance would be roughly equivalent of simply sharing the faster 16x PCIe 3.0 connected GPU already in the machine. For reference, Thunderbolt 1 and 2 offer the same two 4x lanes, Thunderbolt 2 simply allows the lanes to be combined and used as an 8x lane. Whoops, I guess you can't do that, then. You could in the towers, but then, the best of those only supported PCIe 2.0 and, thus had the same problem. In fact, the new Mac Pro 40GB/sec of PCIe bandwidth, of which 32GB/sec will be used by the two FirePro GPUs leaving, at best, a single 8x lane. Even if Apple's claimed 40GB/sec is after the GPUs (which are in a crossfire configuration so no, you can't deditate one to one VM andthe other to another), you still can't get around Thunderbolt's 8x lane limitation, nor can you duplicate its internal setup (which is two 16x PCIe GPUs in a crossfire configuration) in one. On a multi CPU Xeon system (and I've personally seen systems with 4), there are enough 16x lanes to do this 8 times over (16 GPUs) in a proper tower; though, admittedly, you may run into issues finding a motherboard and case to support it. Too bad you can't run OS X on that, though. But even not going that high-end, a dual-CPU Xeon PC could support 8 16x PCIe 3.0 GPUs in 4 crossfire or SLI pairs, something you just can't do with any Mac. Oh, and proper cooling so the system doesn't throttle itself under extended periods of high load, such as those a proper workstation in the hands of someone who actually needs that level of compute power will see on a regular basis.
This isn't a stab at Apple, either, just a cold statement of fact. I wish it weren't true, I wish I could get the performance out of a Mac that I can get out of a PC, but I simply can not, so I have to use a PC for such things. Even on the laptop side of things, I can't buy an Apple product today that competes with the MSI gaming rig I picked up in November, a model that is a combination of slightly thinner, somewhat lighter, roughly half the price, and faster overall (and without the thermal throttling that my Retina MBP experiences under load; neigh the hottest this machine gets under extended full load is just barely warmer than the rMBP at idle) than the fastest laptop Apple offers. That's without mentioning that the 970M with 6GB of GDDR5 absolutely eats the lunch of anything Apple offers, with the exception of the Mac Pro, which can be configured with GPUs that will outperform it (and admittedly by a large margin) for certain tasks.
Again, I wish the above weren't true, but there you have it. Facts are facts and Macs aren't for heavy lifting; even Photoshop and other Adobe apps that used to absolutely run better on a Mac have been better off on a mid-range (and much cheaper) PC for some time now.
Apple has a target market and they serve it very well. I'm simply not in that market and, as I have interest in getting actual work done, won't attempt to shoehorn myself into that market. Nobody else with any knowledge and a need for true performance would, either. They're great consumer machines, I have one (that I don't use for work), and I hope to see them completely dominate that market, but lets be real here, they haven't sold a true workhorse of a system (with proper cooling and the ability to run full-tilt for a few minutes, let alone hours or days, without throttling) since Jobs died; the last refresh of the Mac Pro tower was a joke, with hardware one generation newer than the last refresh but still a generation behind.
I'll ask you again, since you keep making the same false claim: the trash-can models that are currently being sold new? Or the old tower models that haven't been updated in half a decade? Because this discussion os about the former but I'm beyong positive you keep ranting about the latter.
In the trash-can model? Because that's what we're talking about here. And no, Thunderbolt breakouts don't really work if you need the performance of a 16x lane.
What you can't do ia the thing I was actually talking about doing: assign each guest OS its own desicated physical GPU, network interface, etc. You can't do this because you literally can not install the hardware into a current Mac. You could on the towers but you can't on the trash can; that is the complaint. You literally can not use the most useful features of a proper hypervisor on a current Mac.
You don't know whay a proper hypervisor is, then, so allow me to explain. A proper hypervisor is, itself , the host OS. It occupies a small bit of RAM and a few CPU cycles, allowing for most hardware to be directly accessed by the guest OSes, though certain things (video and networking for instance) are often virtualized when there are more guests needing access to the hardware than there is physical hardware. That is to say, a proper hypervisorballows you to literally run multiple OSes on the same physical machine, each with its own dedicated hardware if you happen to have it available. You can't utilize dedicated, non-virtualized graphics and networking in this way on a Mac, though, because you can't install multiple graphics or network cards in one.
An example of a proper hypervisor is VMWare ESXi, which is its own OS and does not run on OS X (it would actually be the other way around). While OS X can run on ESXi, it can only do so on Apple hardware, which, as mentioned above, can't utilize the most useful features.
I'll admit I havent played WoW in literally forever (as in.. never) and got my wife to stop years ago, so I haven't seen it on a whike, but it was pretty textur-rich last time I saw her play. Cartoonish, yes, but not all solids and blocks. It also uses shaders, lots and lots of shaders, which workstation cards tend to have fewer of.