HTML is supposed to be platform agnostic. This is explicitly balkanizing it.
But haven't we passed that already? You have the many years old plugin support which isn't even browser agnostic on the same platform, and we also have the video tag which does not define an agnostic codec. Heck, Google is trying to add native code support to HTML5 which is actually PROCESSOR specific.
A LOT of the HTML spec already is browser or platform specific bits. People seem to be suggesting that somehow HTML5 DRM support is somehow a worse solution than every site implementing it's own plugin (or using Silverlight, or using Flash), when it appears it's the same difference. Even the current HTML5 video support everyone here is pining for is already browser or platform specific due to the codec.
There are actual recorded interviews with Gene Roddenberry about how Trek was never "dark" and "edgy" and that completely missed the point of it...
Yet he made plenty of dark and edgy Trek, Wrath of Kahn being one example. The Best of Both Worlds is certainly a dark episode, and was made right at the end of his tenure. Every show ended on a positive beat, but you can't really claim Trek under Roddenberry was never dark or violent. Roddenberry left a trail of red shirts in his wake...
Final Cut Pro X is a steaming turd when the old Final Cut Pro was best in class software.
Honestly, I know a lot of video editors (I'm not one of them) who would not consider Final Cut Pro best in class. They complained about it constantly. Strangely enough, those are the same people who complained about FCPX.
Most of the people who are complaining FCPX switched to Premiere a years ago, and complain constantly even though they're not using FCPX. It's mostly to continue justifying their transition to Premiere when FCS got long in the tooth. "Well of course I made the right choice in switching to Adobe! FCPX is crap!"
That's not to say FCPX doesn't have downgrades. But they are the sort of downgrades that probably aren't all that important (like no tape workflow, who still REALLY needs a tape workflow out there built into the editor?), but are the sort of features that people say they might possibly use someday for nitpicking purposes.
Again, not that FCPX doesn't have it's issues, but a lot of the stuff these days is wildly overblown, and usually from the same corners that didn't like FCPS either.
2) DRM in HTML kills web pages: Documents and web pages are timeless. Any web page that exists today, if it is archived, can be displayed 10 years from now. But in 10 years, the DRM content will be impossible to read because either the authentication servers are gone, or your credentials no longer work, or the product has been discontinued, etc. Either way, a web page becomes corrupted for reading. Documents are archivable. Digital rights are not.
In Netflix's case, that's kind of the point, isn't it? Netflix is a rental service, not a purchasing service. The entire point is you don't get the perceptual ability to view the content.
The great thing about Silverlight is its ability to stream content as your internet line can take it. This means Silverlight will dynamically adjust the video and audio bitrate so that even users on less-than-fast lines can stream Silverlight video content.
Huh? Most video is at 24 fps. Even if we generously triple that, we're nowhere near 120 fps. Hobbit 3D's highest encode was 48 fps which was considered super high quality, and most theaters were still at 24.
That claim by someone claiming to be from Apple is contradicted by someone claiming to be from Google in the same thread, is unsupported by any evidence, and is, apart from all that, quite dubious on its face (since if Apple wanted it WebKit, since it wasn't closed source, they could have brought it into WebKit whether or not Google agreed, and, if they preferred the Google approach, then one would have expected that when they went and made their own implementation, it wouldn't have followed a different basic approach.)
I really doubt the explanation is actually that Apple refused Google's patch, and then went and coded the exact same thing. It makes for an interesting story, but doesn't pass the sniff test, especially because it meant fragmenting the repo. What advantage would Apple have to refusing Google's patch and then having to code the same thing?
And, even if it was true, it still is not relevant to the changes Google wants to make now that they have cited regarding the split (where they have identified the specific barriers preventing them from making the changes within the WebKit project), as it relates to an earlier point of divergence between Chrome and WebKit.
It is somewhat. The changes they want to make now are mostly changes that Apple offered to bring into mainline, and then they refused. And now Google is complaining about the changes not being present in mainline. Could it be Google wanted to withhold certain work from mainline WebKit2 to put Apple at a disadvantage? Couldn't be, that would be evil.
WebKit isn't a standard, its a particular implementation...
Let's just stop there for a second.
WebKit is a defacto standard, especially if you've done any mobile development. It may not be a written standard like the W3C standard, but let's face it, the W3C is arbitrary and not complete. We're talking about a standard that defined a video tag, but no codec to go with, among other things. I'll call the W3C "suggestions" at best.
Given that, WebKit has been the closest thing to a real world standard we've got.
and Google forking its rendering engine from WebKit won't "extinguish" WebKit unless Google was the only party who cared enough about WebKit to make it viable (in which case, this is more of a name- and governance-change for WebKit)...
No, what they're doing is building up a browser base based on WebKit's open success, and then within the next few months doing an automatic silent update to all Chrome users to push them onto their own engine. And I would be surprised if that moved into them quietly "adding" new "features" to HTML. Basically, they've been given command of a lot of users on the web with no committee or discussion about what they're shoving into their branch. If they wanted to add "GoogleActiveX" tomorrow, they could do so, get 40% of the web on that overnight, and then use it as a stick to beat their competitors with.
Them being on WebKit means they're at least playing ball and co-operating with the other players, and it meant whatever they did would be at least available elsewhere. Now it doesn't.
So that's why I said embrace and extinguish. It's the exact same thing Microsoft did with Java in the 90s. Support the standard, ship your own messed up proprietary version, and break the standard enough so that your's is the only usable one. Google has done the first, they're signaling they're moving into the second part, and I would not be surprised at all to see them accomplish the third part. Especially if they want to protect their ad revenue and eyeballs. It's a total conflict of interest.
Additionally, Blink is open source, so the triple-E model of destroying open standards in favor of proprietary solutions which others aren't free to implement hardly works.
I think this is an interesting point, but I don't buy that open automatically means one can't subvert a sta
Chromium and WebKit have divergent goals and it has become increasingly burdensome trying to reconcile them.
Except that Apple said they would have been perfectly happy to have Google contribute the changes Google wanted to make, except Google refused: https://news.ycombinator.com/item?id=5490242
Yeah, I know, you have to pay up a few hundred to Apple. But it let's you distribute apps among your friends/colleagues with no device registration simply by sending a link to your app (or attachment) to iOS devices. It's not meant for public distribution, but I use it for private apps all the time, and it totally bypasses the app store review process (which is an intended consequence.)
Or to translate from flamebait to English: They'll share with anyone else who shares. Same concept as the GPL, though admittedly in a somewhat more vague and less legally-binding manner.
Correction: They'll share with anyone else who shares, but as long as they're the only ones profiting from it.
It's better than some companies, but hardly the slam dunk or sea change it's made out to be.
Honestly, their lawyers probably already told them that it wasn't worth going after any open source projects because in a lot of cases there wasn't money in it.
When CPUs go idle, they consume less power. By keeping them pegged at full capacity, you're using more power, not the same amount. I'm not even sure how this is green at all, ignoring the whole Bitcoin angle.
I know this is probably bound for Mod'ed-Trollville, but the in app memory management APIs are leagues better on iOS (for context, despite my nick, I write code for both Android and iOS).
iOS is much better about letting an application use memory heap without concern, and it has APIs to handle this exact situation. Applications on iOS manage caching (due to the Apple provided caching and memory APIs) based on the device running out of available memory over all processes, not arbitrary limits.
1- MHL is cheap, there are plenty of $2 MHL cables. If you like paying for brands and stickers, that's your choice... they have nice ones with golden connectors and one-way flux optmizations, I'm told.
1b- MHL is cheap, the cost to implement it is nowhere near whatever Apple are doing with their fake video cable.
True, but I can't find anything under $10 that doesn't have bad reviews on Amazon, and that's not including the cost of the MHL encoder that get's eaten by the device price.
2- MHL is a standard. The fact that some chose not to have the feature does not change that. A bit like.. you know... you're PC not being an FM radio does not make FM radios un-standard...
And H.264 streaming is a standard, which is probably why Apple opted to use it. They already have a H.264 encoder on the device, why would they throw an MHL encoder on there too?
3- are you trying to imply that MHL is as expensive as having a failed proprietary interface + **active** components to fake a high-def video link, but that just the cost are split differently ? I can assure you that Apple's "solution" is several times more expensive both to implement in the device, and for the cable. And wayyyyy worse in terms of quality.
Well first, MHL is ALSO active. Unless I missed something and micro USB suddenly spawned a few more pins, it doesn't have enough pins to passively pass through HDMI. The only passive cables are ones for if your TV has an MHL decoder (which means they aren't really HDMI adaptors as much as MHL over HDMI adaptors.)
I'm also not sure it's more expensive. If you've already got an H.264 encoder, all you have to do is stick a decoder at the other end. MHL requires the cost of both an additional encoder (because once again, it's active, as the MHL protocol implementation guide seems to nicely hint at), and a decoder.
If MHL was cheaper, then why wouldn't Apple have just gone with MHL?
So that's why all the android devices with MHL outputs are so much more expensive than the iPhone? oh wait... they aren't.
They aren't? I just cited one device the dropped MHL to stay cost competitive.
It's true that Apple is probably sucking some of that up into their margin, but when you have a popular device like the Nexus 7 dropping MHL because it's too expensive, you can't say it's not a problem.
If you look at the full list of Android devices with MHL it's actually not common for Android devices to have it. http://meetmhl.com/DoIHaveMhl.aspx
I don't even see the Nexus 4 on there, do you? All the Android devices? Hardly.
Thing is, MHL sends uncompressed 1080p over a cheap, standardized cable. Apple's standard, evidently, does not. And like you said, it's worse than the old docking cable in this regard. Regression is extra silly.
Looking at most MHL cable prices from vendors, they're cheaper than Apple's adaptor, but not cheap.
And as I mentioned, MHL drives up device prices because it requires additional circuitry in the device. Standardized cable you say? Try plugging an MHL cable into a Nexus 7. Won't work? That's because the chips required for MHL were too expensive and they were left off the Nexus 7.
Shifting half the expense to the device and half the expense to the cable isn't cheaper, it's just moving costs.
Remember when Apple was known (at least by the general public) as being the company with simple, elegant engineering?
How the mighty have fallen. Really, needing a computerized cable is just silly.
The problem is likely that Lightening likely doesn't have enough pins to just pass through HDMI like the old connector.
Silly? Maybe, but all of Apple's competitors are doing something similar because micro USB also lacks sufficient pins to pass through HDMI. (http://en.wikipedia.org/wiki/Mobile_High-Definition_Link) Except they're shoveling half the chips into the device, which increases costs on that side.
Proves that more intelligent people are gamers... as more computer illiterate people use Mac than linux.
Almost ever single OSX users who is someone who rejected a platform where gaming is great (Windows) to move to a platform where gaming was so/so. Given the capacities are not hugely different and price leans higher that means that anyone who picked OSX over Windows probably doesn't game much. Moreover the Apple crowd in general has been aging and I suspect Steam type gaming is much more popular ages 10-30 than ages 30-50.
In the case of Linux the capacities are hugely different. The more advanced Linux window managers have no Windows or OSX equivalents. There are no GUI desktop environments with the level of configurability of KDE for Windows or OSX. Many of the applications for Linux have no equivalents, though they have competitors which are vastly more expensive. ETC...
I think it is not unreasonable you are looking at two very different populations.
Or, the other obvious conclusion. Mac users who wanted Defenders Quest on Steam have already been able to download it, because it's been available this entire time. Linux users represent pent up demand.
At Mac launch, Macs represented 8.9% of Steam users (http://www.electronista.com/articles/10/06/04/win.7.overtakes.xp.mac.gets.significant.share/). That puts the launch percentage of Mac users significant higher than the launch numbers for Linux.
I'd argue against your armchair assessment of the Mac market, but at this point, the entire basis for it is in question.
This isn't necessarily true. Apple has been shipping this for years as a developer features (open Quartz Debug, set your UI scale, logout, login.)
Yes, they did. Have you ever tried actually enabling this option? It didn't just break third-party apps - it broke the core OS UI, such as the top-level app menu. I don't know on what level the UI stack actually supports this, but it clearly doesn't extend to all stock widgets.
You had to log in and out. Processes didn't scale until they were restarted, so you had to restart the process that controlled the menu.
Yes, it worked fine for stock widgets. Apple had/has an entire framework dedicated to the stock widgets required. They redid a lot of them as pdf/vector. I spent a lot of time going through the innards of the system.
This entire system is still in place and shipping on the Retina machines. The only difference is Apple has hardcoded it to 2x, 1.5x, and 1.0x scales. But it's the same underpinnings. You can even force 2x on a non-Retina computer.
So for something that supposedly breaks all the apps, it seems to be working pretty darn well on shipping hardware.
Sure, it has that code - but its UI stack does not use it for widgets etc. Which is why it still doesn't have an option to e.g. make text bigger in all applications, like you can in Windows or most Linux DEs.
This isn't necessarily true. Apple has been shipping this for years as a developer features (open Quartz Debug, set your UI scale, logout, login.) Apple seems to have given up on this path and is instead doing Retina/Non-Retina (along with a lot of fancy software scaling algorithms to do things like 1.5x UI), but the UI stack certainly does support this.
The real reason Apple didn't go that route is because vector graphics aren't really usable for everything, and most developers are still using bitmaps.
See, that's where you are mistaken, right there in that last sentence. Perhaps that's the source of your misconception.
In Surface Pro, (win32) existing applications all run just fine on touch screens. Buttons push. Check boxes check, data entry fields pop up on screen keyboards, scroll bars scroll, all with just a finger tap. Zero rewrite needed. RT not needed.
Hell, this much even worked under Windows 7 on prior versions of the windows tablets such as the HP Slate. Finger is mouse, except when a keyboard appears. And it just knows when a keyboard is appropriate.
So, a full win32 Surface Pro works fine with legacy software, and you can even get some level of integration with the desktop UI to some extent (icons etc) with no reprogramming.
You're right. They run. Exactly the same as they did on Windows 7 for Tablets, Windows Vista for Tablets, and Windows XP for tablets.
So what exactly does Windows 8 bring that new for legacy apps?
How is it different? I should have thought that would be obvious. Windows 8 is designed for touch from the ground up, not having touch bolted on in slapdash fashion after the fact. Being smaller lighter and easier to use than prior tablets, it has a chance of being successful.
But you're talking about running legacy non-RT software, which is NOT designed for touch from the ground up. It's the same software using the same touch unfriendly widgets present in every single prior version of Windows. Yes, the RT layer is touch friendly, but it doesn't run legacy software. To get your software as touch friendly, you have to port to RT, thus defeating the whole legacy software argument. At that point you might as well port to iPad.
I find it funny you're talking about the touch layer not being bolted on slapdash, when in fact the opposite is true, the legacy software layer was bolted on slapdash.
Running legacy non-RT software gives you the exact same experience Windows 7 for tablets did.
Slashdot Mirror
HTML is supposed to be platform agnostic. This is explicitly balkanizing it.
But haven't we passed that already? You have the many years old plugin support which isn't even browser agnostic on the same platform, and we also have the video tag which does not define an agnostic codec. Heck, Google is trying to add native code support to HTML5 which is actually PROCESSOR specific.
A LOT of the HTML spec already is browser or platform specific bits. People seem to be suggesting that somehow HTML5 DRM support is somehow a worse solution than every site implementing it's own plugin (or using Silverlight, or using Flash), when it appears it's the same difference. Even the current HTML5 video support everyone here is pining for is already browser or platform specific due to the codec.
They don't call it this, of course; but it's a plugin, albeit one that is invoked in the 'video' tag rather than the 'object' tag.
No CDM for your platform? No playback.
So it sounds like we're replacing the current system of platform specific plugins, with a new system of platform specific plugins.
I fail to see the controversy.
There are actual recorded interviews with Gene Roddenberry about how Trek was never "dark" and "edgy" and that completely missed the point of it...
Yet he made plenty of dark and edgy Trek, Wrath of Kahn being one example. The Best of Both Worlds is certainly a dark episode, and was made right at the end of his tenure. Every show ended on a positive beat, but you can't really claim Trek under Roddenberry was never dark or violent. Roddenberry left a trail of red shirts in his wake...
Final Cut Pro X is a steaming turd when the old Final Cut Pro was best in class software.
Honestly, I know a lot of video editors (I'm not one of them) who would not consider Final Cut Pro best in class. They complained about it constantly. Strangely enough, those are the same people who complained about FCPX.
Most of the people who are complaining FCPX switched to Premiere a years ago, and complain constantly even though they're not using FCPX. It's mostly to continue justifying their transition to Premiere when FCS got long in the tooth. "Well of course I made the right choice in switching to Adobe! FCPX is crap!"
That's not to say FCPX doesn't have downgrades. But they are the sort of downgrades that probably aren't all that important (like no tape workflow, who still REALLY needs a tape workflow out there built into the editor?), but are the sort of features that people say they might possibly use someday for nitpicking purposes.
Again, not that FCPX doesn't have it's issues, but a lot of the stuff these days is wildly overblown, and usually from the same corners that didn't like FCPS either.
2) DRM in HTML kills web pages: Documents and web pages are timeless. Any web page that exists today, if it is archived, can be displayed 10 years from now.
But in 10 years, the DRM content will be impossible to read because either the authentication servers are gone, or your credentials no longer work, or the product has been discontinued, etc. Either way, a web page becomes corrupted for reading. Documents are archivable. Digital rights are not.
In Netflix's case, that's kind of the point, isn't it? Netflix is a rental service, not a purchasing service. The entire point is you don't get the perceptual ability to view the content.
The great thing about Silverlight is its ability to stream content as your internet line can take it. This means Silverlight will dynamically adjust the video and audio bitrate so that even users on less-than-fast lines can stream Silverlight video content.
HTML5 has this as well. (Documentation being linked to is Apple's.)
https://developer.apple.com/resources/http-streaming/
https://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html%23//apple_ref/doc/uid/TP40008332-CH102-DontLinkElementID_24
According to the original data, Apple sales dropped 7.5% as well. 's good to see that Windows 8 is killing Apple as well!
Gartner, however, says they are even (while agreeing that Windows sales are down.)
3D or High Framerate: 120 fps
Huh? Most video is at 24 fps. Even if we generously triple that, we're nowhere near 120 fps. Hobbit 3D's highest encode was 48 fps which was considered super high quality, and most theaters were still at 24.
That claim by someone claiming to be from Apple is contradicted by someone claiming to be from Google in the same thread, is unsupported by any evidence, and is, apart from all that, quite dubious on its face (since if Apple wanted it WebKit, since it wasn't closed source, they could have brought it into WebKit whether or not Google agreed, and, if they preferred the Google approach, then one would have expected that when they went and made their own implementation, it wouldn't have followed a different basic approach.)
I really doubt the explanation is actually that Apple refused Google's patch, and then went and coded the exact same thing. It makes for an interesting story, but doesn't pass the sniff test, especially because it meant fragmenting the repo. What advantage would Apple have to refusing Google's patch and then having to code the same thing?
And, even if it was true, it still is not relevant to the changes Google wants to make now that they have cited regarding the split (where they have identified the specific barriers preventing them from making the changes within the WebKit project), as it relates to an earlier point of divergence between Chrome and WebKit.
It is somewhat. The changes they want to make now are mostly changes that Apple offered to bring into mainline, and then they refused. And now Google is complaining about the changes not being present in mainline. Could it be Google wanted to withhold certain work from mainline WebKit2 to put Apple at a disadvantage? Couldn't be, that would be evil.
WebKit isn't a standard, its a particular implementation...
Let's just stop there for a second.
WebKit is a defacto standard, especially if you've done any mobile development. It may not be a written standard like the W3C standard, but let's face it, the W3C is arbitrary and not complete. We're talking about a standard that defined a video tag, but no codec to go with, among other things. I'll call the W3C "suggestions" at best.
Given that, WebKit has been the closest thing to a real world standard we've got.
and Google forking its rendering engine from WebKit won't "extinguish" WebKit unless Google was the only party who cared enough about WebKit to make it viable (in which case, this is more of a name- and governance-change for WebKit)...
No, what they're doing is building up a browser base based on WebKit's open success, and then within the next few months doing an automatic silent update to all Chrome users to push them onto their own engine. And I would be surprised if that moved into them quietly "adding" new "features" to HTML. Basically, they've been given command of a lot of users on the web with no committee or discussion about what they're shoving into their branch. If they wanted to add "GoogleActiveX" tomorrow, they could do so, get 40% of the web on that overnight, and then use it as a stick to beat their competitors with.
Them being on WebKit means they're at least playing ball and co-operating with the other players, and it meant whatever they did would be at least available elsewhere. Now it doesn't.
So that's why I said embrace and extinguish. It's the exact same thing Microsoft did with Java in the 90s. Support the standard, ship your own messed up proprietary version, and break the standard enough so that your's is the only usable one. Google has done the first, they're signaling they're moving into the second part, and I would not be surprised at all to see them accomplish the third part. Especially if they want to protect their ad revenue and eyeballs. It's a total conflict of interest.
Additionally, Blink is open source, so the triple-E model of destroying open standards in favor of proprietary solutions which others aren't free to implement hardly works.
I think this is an interesting point, but I don't buy that open automatically means one can't subvert a sta
Chromium and WebKit have divergent goals and it has become increasingly burdensome trying to reconcile them.
Except that Apple said they would have been perfectly happy to have Google contribute the changes Google wanted to make, except Google refused:
https://news.ycombinator.com/item?id=5490242
Smells like Embrace and Extinguish to me.
Tel my how I can write an app on the iPad, and then share it with whomever I want. How do I just send it to my friend across the table?
Enterprise Provisioning.
http://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
Yeah, I know, you have to pay up a few hundred to Apple. But it let's you distribute apps among your friends/colleagues with no device registration simply by sending a link to your app (or attachment) to iOS devices. It's not meant for public distribution, but I use it for private apps all the time, and it totally bypasses the app store review process (which is an intended consequence.)
Or to translate from flamebait to English:
They'll share with anyone else who shares. Same concept as the GPL, though admittedly in a somewhat more vague and less legally-binding manner.
Correction:
They'll share with anyone else who shares, but as long as they're the only ones profiting from it.
It's better than some companies, but hardly the slam dunk or sea change it's made out to be.
Honestly, their lawyers probably already told them that it wasn't worth going after any open source projects because in a lot of cases there wasn't money in it.
When CPUs go idle, they consume less power. By keeping them pegged at full capacity, you're using more power, not the same amount. I'm not even sure how this is green at all, ignoring the whole Bitcoin angle.
I know this is probably bound for Mod'ed-Trollville, but the in app memory management APIs are leagues better on iOS (for context, despite my nick, I write code for both Android and iOS).
iOS is much better about letting an application use memory heap without concern, and it has APIs to handle this exact situation. Applications on iOS manage caching (due to the Apple provided caching and memory APIs) based on the device running out of available memory over all processes, not arbitrary limits.
And it's my right to take my business elsewhere.
I'm pretty sure that's exactly what he wants.
You're being extremelly disingenuous:
1- MHL is cheap, there are plenty of $2 MHL cables. If you like paying for brands and stickers, that's your choice... they have nice ones with golden connectors and one-way flux optmizations, I'm told.
1b- MHL is cheap, the cost to implement it is nowhere near whatever Apple are doing with their fake video cable.
True, but I can't find anything under $10 that doesn't have bad reviews on Amazon, and that's not including the cost of the MHL encoder that get's eaten by the device price.
2- MHL is a standard. The fact that some chose not to have the feature does not change that. A bit like.. you know... you're PC not being an FM radio does not make FM radios un-standard...
And H.264 streaming is a standard, which is probably why Apple opted to use it. They already have a H.264 encoder on the device, why would they throw an MHL encoder on there too?
3- are you trying to imply that MHL is as expensive as having a failed proprietary interface + **active** components to fake a high-def video link, but that just the cost are split differently ? I can assure you that Apple's "solution" is several times more expensive both to implement in the device, and for the cable. And wayyyyy worse in terms of quality.
Well first, MHL is ALSO active. Unless I missed something and micro USB suddenly spawned a few more pins, it doesn't have enough pins to passively pass through HDMI. The only passive cables are ones for if your TV has an MHL decoder (which means they aren't really HDMI adaptors as much as MHL over HDMI adaptors.)
I'm also not sure it's more expensive. If you've already got an H.264 encoder, all you have to do is stick a decoder at the other end. MHL requires the cost of both an additional encoder (because once again, it's active, as the MHL protocol implementation guide seems to nicely hint at), and a decoder.
If MHL was cheaper, then why wouldn't Apple have just gone with MHL?
So that's why all the android devices with MHL outputs are so much more expensive than the iPhone? oh wait... they aren't.
They aren't? I just cited one device the dropped MHL to stay cost competitive.
It's true that Apple is probably sucking some of that up into their margin, but when you have a popular device like the Nexus 7 dropping MHL because it's too expensive, you can't say it's not a problem.
If you look at the full list of Android devices with MHL it's actually not common for Android devices to have it.
http://meetmhl.com/DoIHaveMhl.aspx
I don't even see the Nexus 4 on there, do you? All the Android devices? Hardly.
That's only true if there's a 1:1 relationship between tablets and cables.
True, but if there is a 1:0 relationship between tablets and cables, integrating into the cable wins.
Thing is, MHL sends uncompressed 1080p over a cheap, standardized cable. Apple's standard, evidently, does not. And like you said, it's worse than the old docking cable in this regard. Regression is extra silly.
Looking at most MHL cable prices from vendors, they're cheaper than Apple's adaptor, but not cheap.
And as I mentioned, MHL drives up device prices because it requires additional circuitry in the device. Standardized cable you say? Try plugging an MHL cable into a Nexus 7. Won't work? That's because the chips required for MHL were too expensive and they were left off the Nexus 7.
Shifting half the expense to the device and half the expense to the cable isn't cheaper, it's just moving costs.
Remember when Apple was known (at least by the general public) as being the company with simple, elegant engineering?
How the mighty have fallen. Really, needing a computerized cable is just silly.
The problem is likely that Lightening likely doesn't have enough pins to just pass through HDMI like the old connector.
Silly? Maybe, but all of Apple's competitors are doing something similar because micro USB also lacks sufficient pins to pass through HDMI. (http://en.wikipedia.org/wiki/Mobile_High-Definition_Link) Except they're shoveling half the chips into the device, which increases costs on that side.
Proves that more intelligent people are gamers... as more computer illiterate people use Mac than linux.
Almost ever single OSX users who is someone who rejected a platform where gaming is great (Windows) to move to a platform where gaming was so/so. Given the capacities are not hugely different and price leans higher that means that anyone who picked OSX over Windows probably doesn't game much. Moreover the Apple crowd in general has been aging and I suspect Steam type gaming is much more popular ages 10-30 than ages 30-50.
In the case of Linux the capacities are hugely different. The more advanced Linux window managers have no Windows or OSX equivalents. There are no GUI desktop environments with the level of configurability of KDE for Windows or OSX. Many of the applications for Linux have no equivalents, though they have competitors which are vastly more expensive. ETC...
I think it is not unreasonable you are looking at two very different populations.
Or, the other obvious conclusion. Mac users who wanted Defenders Quest on Steam have already been able to download it, because it's been available this entire time. Linux users represent pent up demand.
At Mac launch, Macs represented 8.9% of Steam users (http://www.electronista.com/articles/10/06/04/win.7.overtakes.xp.mac.gets.significant.share/). That puts the launch percentage of Mac users significant higher than the launch numbers for Linux.
I'd argue against your armchair assessment of the Mac market, but at this point, the entire basis for it is in question.
This isn't necessarily true. Apple has been shipping this for years as a developer features (open Quartz Debug, set your UI scale, logout, login.)
Yes, they did. Have you ever tried actually enabling this option? It didn't just break third-party apps - it broke the core OS UI, such as the top-level app menu. I don't know on what level the UI stack actually supports this, but it clearly doesn't extend to all stock widgets.
You had to log in and out. Processes didn't scale until they were restarted, so you had to restart the process that controlled the menu.
Yes, it worked fine for stock widgets. Apple had/has an entire framework dedicated to the stock widgets required. They redid a lot of them as pdf/vector. I spent a lot of time going through the innards of the system.
This entire system is still in place and shipping on the Retina machines. The only difference is Apple has hardcoded it to 2x, 1.5x, and 1.0x scales. But it's the same underpinnings. You can even force 2x on a non-Retina computer.
So for something that supposedly breaks all the apps, it seems to be working pretty darn well on shipping hardware.
Sure, it has that code - but its UI stack does not use it for widgets etc. Which is why it still doesn't have an option to e.g. make text bigger in all applications, like you can in Windows or most Linux DEs.
This isn't necessarily true. Apple has been shipping this for years as a developer features (open Quartz Debug, set your UI scale, logout, login.) Apple seems to have given up on this path and is instead doing Retina/Non-Retina (along with a lot of fancy software scaling algorithms to do things like 1.5x UI), but the UI stack certainly does support this.
The real reason Apple didn't go that route is because vector graphics aren't really usable for everything, and most developers are still using bitmaps.
See, that's where you are mistaken, right there in that last sentence. Perhaps that's the source of your misconception.
In Surface Pro, (win32) existing applications all run just fine on touch screens. Buttons push. Check boxes check, data entry fields pop up on screen keyboards, scroll bars scroll, all with just a finger tap. Zero rewrite needed. RT not needed.
Hell, this much even worked under Windows 7 on prior versions of the windows tablets such as the HP Slate. Finger is mouse, except when a keyboard appears. And it just knows when a keyboard is appropriate.
So, a full win32 Surface Pro works fine with legacy software, and you can even get some level of integration with the desktop UI to some extent (icons etc) with no reprogramming.
You're right. They run. Exactly the same as they did on Windows 7 for Tablets, Windows Vista for Tablets, and Windows XP for tablets.
So what exactly does Windows 8 bring that new for legacy apps?
How is it different? I should have thought that would be obvious. Windows 8 is designed for touch
from the ground up, not having touch bolted on in slapdash fashion after the fact. Being
smaller lighter and easier to use than prior tablets, it has a chance of being successful.
But you're talking about running legacy non-RT software, which is NOT designed for touch from the ground up. It's the same software using the same touch unfriendly widgets present in every single prior version of Windows. Yes, the RT layer is touch friendly, but it doesn't run legacy software. To get your software as touch friendly, you have to port to RT, thus defeating the whole legacy software argument. At that point you might as well port to iPad.
I find it funny you're talking about the touch layer not being bolted on slapdash, when in fact the opposite is true, the legacy software layer was bolted on slapdash.
Running legacy non-RT software gives you the exact same experience Windows 7 for tablets did.