Actually, Adobe's design tools also suck now. There is a designer revolt underway, but unfortunately, since Adobe bought Macromedia there is no competition anymore (thanks Bush administration!) You would not believe the bugs in a copy of Creative Suite, which costs more than a Mac.
No, you are totally wrong. That is the myth, not the facts.
Apple executed the iPhone launch and App Store launch exactly according to plan. Nobody bullied them into anything. When the iOS SDK was released one year after iPhone, that gave it these very significant advantages over being released earlier:
- there was a user base of 6 million enthusiastic users who were getting a little tired of their 10-12 built-in apps and had their wallets out for new apps, plus something like 3 million iPod touch users - there was a developer base that was worked up much more than after a Steve Ballmer dance number because iPhone had seemed to them like forbidden fruit for a year, and those 6 million hungry users looked like they were walking around on plump turkey legs - the concept of what an iOS app looks like and feels like and how it acts were better developed, and better understood by people inside Apple, by users, by developers - there was an international version of the phone remember, original iPhone was US-only, it was sort of a beta test
They were always going to have CocoaTouch apps. iPhone very specifically cleared the way for iPad. The reason iPad had 500 full-size apps at launch and 1000 by a week later and 10,000 by a few months later was because there were already many thousands of iOS developers and lots of iOS app code in the world by then. The apps that sell iPads and iPhones are not Web apps, they are the really rich, media-heavy Mac class apps, many of them from the Mac. Of course Apple was going to leverage all the pre-iPhone OS X code when they put OS X on a phone.
Also, the SDK that Apple released in mid-2008 had been worked on for years. It's crazy to say that Apple threw it together in 6 months when they saw that the people wanted apps.
The HTML5 or CocoaTouch choice on iOS is perfectly designed. It was always going to be that way. The 2 together are a yin yang of apps. Any particular app you may want to make can be made for iPhone because either HTML5 or CocoaTouch will be perfect for it. They are much better together than if you had just one or the other.
> Android had to allow native apps because iOS did.
Android does not have native apps, it has Java-like apps running in a virtual machine. App Store launched in mid-2008, and Android launched in late 2008. There wasn't enough time there for Google to create Dalvik as an answer to App Store. Dalvik was already built way before that.
There are too many people who don't have room in their philosophies for any balance.
What we see on iPad is perfect: a great native C/C++ platform with rich frameworks that exponentially speed up development, heavy duty multimedia, advanced graphics and animation, deep access to the core of the device BUT ALSO a great HTML5 Web platform with rich typography, color managed graphics, hardware accelerated animations, fast JavaScript, great usability, local installation, home screen icons. Between the 2, you have the whole world. They are a yin yang of apps. You need both.
You should actually learn about HTML5, because you sound like an ass. What is in the HTML5 spec is what the browsers do TODAY. Right now. If they aren't all doing it, it doesn't go in the spec. It's not an aspirational, academic spec like the failed HTML4, that describes how the Web ought to be, it is a practical spec that describes how the Web fucking is.
All of today's browsers use an HTML5 parser by default. For some years now, actually. The overwhelming majority of HTML5 is the parts of HTML4 that browsers actually supported. The overwhelming majority of HTML5 has been supported in browsers for over 5 years. And what little there is that is new in HTML5 has backwards compatibility built-in. For example, you can put a link to an audio file inside an audio tag, and modern browsers will play the audio tag, and older browsers will show the user the link so they can open the audio in a helper application. Today's browsers actually support more of HTML5 than they support of HTML4!
JavaScript is all we have if we want to reach the whole fucking world. Yes, we want to do that. Yes, that is much more important than your quaint ideas of software ballsiness. Sorry that JavaScript is not butch enough for you. Who gives a shit? HTML5 (which now includes both CSS and JavaScript by default) is the best write-once run-anywhere solution ever created. It is the most open API ever created. It is the most widely-deployed API ever created. Yes, it has its flaws. So fucking what. So does everything. What matters is what you make out of it. Whether you accomplish something great, share information broadly, create a great experience for the user.
Further, you can create an HTML5 interface and you can call out in the background to a server that is running Python if you like. That is the only practical way to deploy Python today because most of the world's computers are not PC's, and most of the world's computer users are not nerds.
> The end result is that the browser should not be used for anything more than displaying and linking documents.
I cannot begin to tell you how stupid that sounds. The idea that the Web has "documents" on it is a FICTION. You fell for the illusion. It is a client-server application platform. When you load the plainest HTML into a browser, a DOM is still built. Even if you have no JavaScript behaviors in your app, the browser puts in a default set. Even if you have no CSS in your app, the browser puts in a default set. The same system that enables you to change the DOM so that a heading is blue instead of black (surely, that is allowable in your special documents world?) enables you to change the DOM so that you can provide additional interactivity or application behaviors as appropriate. There is no such thing as pure HTML or pure HTML+CSS, there is just pure DOM.
Those are already all tied together by HTML5. That is how you make a single app to run everywhere. Native apps are the opposite, they are how you make an app to run just in one device. To exploit the specific features of that device. To be an alternative to the Web. Between the 2, you can have any kind of app you like. If you only had one or the other, then you are hopping on one leg.
Well, iOS proves you totally and completely wrong. Although your bigoted ignorant tone is somewhat entertaining to other slashdotters, I'm sure.
There are plenty of apps on iOS that cannot be done as Web apps. There are many apps from the Mac like Keynote and iMovie. There are many music and audio apps that do multitrack audio, send MIDI over Wi-Fi, all kinds of things that Web apps are not even dreaming of yet. There are console games, there are hardware accelerated graphics and animations everywhere. There are limited resources that make it an advantage to code in native C/C++ for speed and responsiveness. There is a massive object-oriented framework that does the work of 10 additional coders for you as you work alone. I worked for a company whose Web app cost 10 times as much to make as their iPhone app.
The Command Line is irrelevant. The main tool you need for setting up a Web server is a UTF-8 text editor and some kind of file manager. Doesn't matter if it is BBEdit and Finder running in the lush Mac GUI. Whether you want to use the command line is just a completely separate issue. I know how to do everything from bash, but it is too f'ing slow compared to the Mac.
Those are your only rational choices. Either invest the time in learning Linux so you can take advantage of Linux, or invest the money in a Mac so you can take advantage of the Mac. If you have more time than money, use Linux; if you have more money than time, use a Mac. The only work you will have to do with the Mac is the actual writing of the code. There will not be any configuration to do at all.
Why use Windows to run Unix tools? I don't see that you are taking any advantage of Windows at all, yet you've introduced viruses, malware, endless patching, OS upgrade fees, DOS line endings, weird Windows text encodings all not only not helpful, but detrimental. Even with Apache, PHP, MySQL, you are still missing dozens if not hundreds of other great tools. You say "if you know Windows" how does knowing Windows help you to configure Apache? The fact that you are on a strange platform actually means you have more chance of trouble and fewer help resources.
If you find Linux is not to your taste, get a Mac. It has a full Unix as well as a full set of GUI tools. And a Mac uses UTF-8 text encoding and Unix line endings throughout, just like the Web. No viruses, it patches itself, it is $29 every 2 years to upgrade the OS, and it is f'ing stable like a rock.
> All of the things you mentioned above are _positive_ things, in that you would have to be crazy > to use the bios for anything other than loading the os and getting the hell out.
Unless you want to load the OS from a >2TB volume over a network. Which is a feature of shipping Macs, which use EFI.
> All that is being done by making the boot process more complex is letting people add more bugs to firmware, do not want.
No, EFI makes the boot process simpler, not more complex.
You fell into the trap of thinking that because EFI is bigger, it is more complex. No. There is a huge amount of complexity around BIOS because everything that interacts with it is 30 years newer than it is supposed to be. The BIOS has to be tricked at every step to work with systems that have exponentially more of everything than it expects them to have. That is extremely complicated.
Further, support for modern computer hardware makes things simpler, not more complicated. If you are using a computer with Bluetooth keyboard and mouse/trackpad and you want to boot from a different volume, the fact that your mouse and keyboard continue to function when you go into the firmware to choose a new boot volume makes things simpler, not more complex. Another feature of shipping Macs.
Yeah, but EFI systems can do a full boot in under 10 seconds, with no fucking around. EFI systems can boot off the network faster than you are booting off local disk.
All of these arguments are empty. Nobody gives a shit about 30 year old computing. People want fast boots, instant sleep/wake, network booting, they want no viruses, they want solid state everything, they want reliability like an iPad. Every year for the past few years, the number of BIOS PC's as a percentage of the overall market goes down. It's going to keep going down until none are left. End of story.
What's more important: booting from a floppy, or booting from a server over the Internet? Because thanks to EFI, I can boot the Lion installer from a server at Apple, but Lion cannot fit on a floppy. The same is true of any modern operating system. A Live CD is utter bullshit compared to booting off an Internet server.
Both iPad and the proposed Microsoft iPad clone have W3C HTML5 app platforms, ISO MPEG4 audio video platforms, run ePub (XML) books, JPEG photos, PDF documents, and other vendor neutral open standards. How can you get vendor lock-in in that case?
> So, once again we're going to end up having to replace a metric shit ton of applications because of an OS change.
Software is designed to be replaced. That is why it is not burned into hardware.
I think you have your head screwed on 180 degrees backwards. The iPod did not make your CD's less valuable, it gave you a new way to exploit the value of your CD's. You could still run them in a CD Player, same as before, or you could choose to also run them on iPod. Same with iPad: it does not make your PC apps less valuable, you can still run them on a PC as usual, or you can choose to exploit the value of those apps in a new way, by running them on new devices in new places. On the Apple side, buying a $5 iMovie for iOS did not make me feel that the $20 I spent on iMovie for Mac was wasted, I felt like the app is now more valuable when I can use it in both places.
I sort of sympathize, because I know Windows software costs an arm and a leg, but if you can't afford to run Windows, you should get a Mac.
You are right, a dual core 1GHz ARM actually *is* enough for any task a user will run on a tablet. We know this because well over 90% of tablets have dual core 1GHz or less and users love them and run 500,000 native C/C++ iOS apps on them.
Well, iPad is 100% malware free because of what you describe as being "crippled by DRM." People like that way, way more than devices that are crippled by malware.
iPad is over 90% of tablets... it has set the standard. It's trouble-free, right? It doesn't crash, get malware, and the apps are really cheap because there is very little bootlegging. The apps are creative tools and games and educational things, not task killers and anti-virus and diagnostics. It is very popular with the consumer users who make up 75% of the computer market.
You're making the mistake of thinking ARM is another PC CPU. It is not.
Porting from PowerPC to Intel is like moving a load from the back of one truck to another. Straightforward. Porting from either of those to ARM is like moving a load from the back of a truck into the back of a sports car. You are going to have to leave some stuff back in the truck. There are design decisions to make, i.e. "which of the stuff in the truck do I need the most, which can I easily live without, how can I compensate for some of the stuff I would like to have but had to leave out?" This requires work by humans, not checking a box to run your code through a second compiler.
Compiling, universal binaries... not relevant. It could be an Intel SoC in iPad, if it runs at 1 watt you are going to have to rewrite your desktop app to run on there. If your app does not spend most of its time trying to avoid killing the battery, then you are going to have to rewrite your desktop app to run on iPad.
That is why Apple said, "you might as well make a new touch interface as well." All-new apps were always going to be needed for mobile. It is a different kind of computing from desktop in every way.
Slashdot Mirror
Actually, Adobe's design tools also suck now. There is a designer revolt underway, but unfortunately, since Adobe bought Macromedia there is no competition anymore (thanks Bush administration!) You would not believe the bugs in a copy of Creative Suite, which costs more than a Mac.
No, you are totally wrong. That is the myth, not the facts.
Apple executed the iPhone launch and App Store launch exactly according to plan. Nobody bullied them into anything. When the iOS SDK was released one year after iPhone, that gave it these very significant advantages over being released earlier:
- there was a user base of 6 million enthusiastic users who were getting a little tired of their 10-12 built-in apps and had their wallets out for new apps, plus something like 3 million iPod touch users
- there was a developer base that was worked up much more than after a Steve Ballmer dance number because iPhone had seemed to them like forbidden fruit for a year, and those 6 million hungry users looked like they were walking around on plump turkey legs
- the concept of what an iOS app looks like and feels like and how it acts were better developed, and better understood by people inside Apple, by users, by developers
- there was an international version of the phone remember, original iPhone was US-only, it was sort of a beta test
They were always going to have CocoaTouch apps. iPhone very specifically cleared the way for iPad. The reason iPad had 500 full-size apps at launch and 1000 by a week later and 10,000 by a few months later was because there were already many thousands of iOS developers and lots of iOS app code in the world by then. The apps that sell iPads and iPhones are not Web apps, they are the really rich, media-heavy Mac class apps, many of them from the Mac. Of course Apple was going to leverage all the pre-iPhone OS X code when they put OS X on a phone.
Also, the SDK that Apple released in mid-2008 had been worked on for years. It's crazy to say that Apple threw it together in 6 months when they saw that the people wanted apps.
The HTML5 or CocoaTouch choice on iOS is perfectly designed. It was always going to be that way. The 2 together are a yin yang of apps. Any particular app you may want to make can be made for iPhone because either HTML5 or CocoaTouch will be perfect for it. They are much better together than if you had just one or the other.
> Android had to allow native apps because iOS did.
Android does not have native apps, it has Java-like apps running in a virtual machine. App Store launched in mid-2008, and Android launched in late 2008. There wasn't enough time there for Google to create Dalvik as an answer to App Store. Dalvik was already built way before that.
> One size doesn't fit all.
There are too many people who don't have room in their philosophies for any balance.
What we see on iPad is perfect: a great native C/C++ platform with rich frameworks that exponentially speed up development, heavy duty multimedia, advanced graphics and animation, deep access to the core of the device BUT ALSO a great HTML5 Web platform with rich typography, color managed graphics, hardware accelerated animations, fast JavaScript, great usability, local installation, home screen icons. Between the 2, you have the whole world. They are a yin yang of apps. You need both.
You should actually learn about HTML5, because you sound like an ass. What is in the HTML5 spec is what the browsers do TODAY. Right now. If they aren't all doing it, it doesn't go in the spec. It's not an aspirational, academic spec like the failed HTML4, that describes how the Web ought to be, it is a practical spec that describes how the Web fucking is.
All of today's browsers use an HTML5 parser by default. For some years now, actually. The overwhelming majority of HTML5 is the parts of HTML4 that browsers actually supported. The overwhelming majority of HTML5 has been supported in browsers for over 5 years. And what little there is that is new in HTML5 has backwards compatibility built-in. For example, you can put a link to an audio file inside an audio tag, and modern browsers will play the audio tag, and older browsers will show the user the link so they can open the audio in a helper application. Today's browsers actually support more of HTML5 than they support of HTML4!
JavaScript is all we have if we want to reach the whole fucking world. Yes, we want to do that. Yes, that is much more important than your quaint ideas of software ballsiness. Sorry that JavaScript is not butch enough for you. Who gives a shit? HTML5 (which now includes both CSS and JavaScript by default) is the best write-once run-anywhere solution ever created. It is the most open API ever created. It is the most widely-deployed API ever created. Yes, it has its flaws. So fucking what. So does everything. What matters is what you make out of it. Whether you accomplish something great, share information broadly, create a great experience for the user.
Further, you can create an HTML5 interface and you can call out in the background to a server that is running Python if you like. That is the only practical way to deploy Python today because most of the world's computers are not PC's, and most of the world's computer users are not nerds.
> The end result is that the browser should not be used for anything more than displaying and linking documents.
I cannot begin to tell you how stupid that sounds. The idea that the Web has "documents" on it is a FICTION. You fell for the illusion. It is a client-server application platform. When you load the plainest HTML into a browser, a DOM is still built. Even if you have no JavaScript behaviors in your app, the browser puts in a default set. Even if you have no CSS in your app, the browser puts in a default set. The same system that enables you to change the DOM so that a heading is blue instead of black (surely, that is allowable in your special documents world?) enables you to change the DOM so that you can provide additional interactivity or application behaviors as appropriate. There is no such thing as pure HTML or pure HTML+CSS, there is just pure DOM.
Those are already all tied together by HTML5. That is how you make a single app to run everywhere. Native apps are the opposite, they are how you make an app to run just in one device. To exploit the specific features of that device. To be an alternative to the Web. Between the 2, you can have any kind of app you like. If you only had one or the other, then you are hopping on one leg.
Well, iOS proves you totally and completely wrong. Although your bigoted ignorant tone is somewhat entertaining to other slashdotters, I'm sure.
There are plenty of apps on iOS that cannot be done as Web apps. There are many apps from the Mac like Keynote and iMovie. There are many music and audio apps that do multitrack audio, send MIDI over Wi-Fi, all kinds of things that Web apps are not even dreaming of yet. There are console games, there are hardware accelerated graphics and animations everywhere. There are limited resources that make it an advantage to code in native C/C++ for speed and responsiveness. There is a massive object-oriented framework that does the work of 10 additional coders for you as you work alone. I worked for a company whose Web app cost 10 times as much to make as their iPhone app.
An iOS is running on a workstation class core
A well managed Windows box is worse than a poorly admined Mac.
If the guy needs easy Unix, he needs a Mac. DUH.
If he wants an easy Unix, that is the Mac, duh. There is no reason to bring Windows into a discussion about Apache and PHP.
If you want Unix, then either do it the easy way with Apple or the hard way with everyone else. At least in both cases you will do it right.
The Command Line is irrelevant. The main tool you need for setting up a Web server is a UTF-8 text editor and some kind of file manager. Doesn't matter if it is BBEdit and Finder running in the lush Mac GUI. Whether you want to use the command line is just a completely separate issue. I know how to do everything from bash, but it is too f'ing slow compared to the Mac.
Notice he said user-friendly and he is referring to a Mac. That means he is talking about so easy that it requires absolutely no work at all.
Those are your only rational choices. Either invest the time in learning Linux so you can take advantage of Linux, or invest the money in a Mac so you can take advantage of the Mac. If you have more time than money, use Linux; if you have more money than time, use a Mac. The only work you will have to do with the Mac is the actual writing of the code. There will not be any configuration to do at all.
Why use Windows to run Unix tools? I don't see that you are taking any advantage of Windows at all, yet you've introduced viruses, malware, endless patching, OS upgrade fees, DOS line endings, weird Windows text encodings all not only not helpful, but detrimental. Even with Apache, PHP, MySQL, you are still missing dozens if not hundreds of other great tools. You say "if you know Windows" how does knowing Windows help you to configure Apache? The fact that you are on a strange platform actually means you have more chance of trouble and fewer help resources.
If you find Linux is not to your taste, get a Mac. It has a full Unix as well as a full set of GUI tools. And a Mac uses UTF-8 text encoding and Unix line endings throughout, just like the Web. No viruses, it patches itself, it is $29 every 2 years to upgrade the OS, and it is f'ing stable like a rock.
> All of the things you mentioned above are _positive_ things, in that you would have to be crazy
> to use the bios for anything other than loading the os and getting the hell out.
Unless you want to load the OS from a >2TB volume over a network. Which is a feature of shipping Macs, which use EFI.
> All that is being done by making the boot process more complex is letting people add more bugs to firmware, do not want.
No, EFI makes the boot process simpler, not more complex.
You fell into the trap of thinking that because EFI is bigger, it is more complex. No. There is a huge amount of complexity around BIOS because everything that interacts with it is 30 years newer than it is supposed to be. The BIOS has to be tricked at every step to work with systems that have exponentially more of everything than it expects them to have. That is extremely complicated.
Further, support for modern computer hardware makes things simpler, not more complicated. If you are using a computer with Bluetooth keyboard and mouse/trackpad and you want to boot from a different volume, the fact that your mouse and keyboard continue to function when you go into the firmware to choose a new boot volume makes things simpler, not more complex. Another feature of shipping Macs.
Now they are x64. x86 has been renamed x32.
Yeah, but EFI systems can do a full boot in under 10 seconds, with no fucking around. EFI systems can boot off the network faster than you are booting off local disk.
All of these arguments are empty. Nobody gives a shit about 30 year old computing. People want fast boots, instant sleep/wake, network booting, they want no viruses, they want solid state everything, they want reliability like an iPad. Every year for the past few years, the number of BIOS PC's as a percentage of the overall market goes down. It's going to keep going down until none are left. End of story.
What's more important: booting from a floppy, or booting from a server over the Internet? Because thanks to EFI, I can boot the Lion installer from a server at Apple, but Lion cannot fit on a floppy. The same is true of any modern operating system. A Live CD is utter bullshit compared to booting off an Internet server.
What pieces are missing?
Please don't say keyboard, because only a jackass would not know that you can attach a Bluetooth keyboard to an iPad.
Both iPad and the proposed Microsoft iPad clone have W3C HTML5 app platforms, ISO MPEG4 audio video platforms, run ePub (XML) books, JPEG photos, PDF documents, and other vendor neutral open standards. How can you get vendor lock-in in that case?
> So, once again we're going to end up having to replace a metric shit ton of applications because of an OS change.
Software is designed to be replaced. That is why it is not burned into hardware.
I think you have your head screwed on 180 degrees backwards. The iPod did not make your CD's less valuable, it gave you a new way to exploit the value of your CD's. You could still run them in a CD Player, same as before, or you could choose to also run them on iPod. Same with iPad: it does not make your PC apps less valuable, you can still run them on a PC as usual, or you can choose to exploit the value of those apps in a new way, by running them on new devices in new places. On the Apple side, buying a $5 iMovie for iOS did not make me feel that the $20 I spent on iMovie for Mac was wasted, I felt like the app is now more valuable when I can use it in both places.
I sort of sympathize, because I know Windows software costs an arm and a leg, but if you can't afford to run Windows, you should get a Mac.
You are right, a dual core 1GHz ARM actually *is* enough for any task a user will run on a tablet. We know this because well over 90% of tablets have dual core 1GHz or less and users love them and run 500,000 native C/C++ iOS apps on them.
The architecture is not the point.
If there is an Office for Metro, it will look and work differently than Office for Windows.
And they have also said it won't ship like that.
Well, iPad is 100% malware free because of what you describe as being "crippled by DRM." People like that way, way more than devices that are crippled by malware.
iPad is over 90% of tablets ... it has set the standard. It's trouble-free, right? It doesn't crash, get malware, and the apps are really cheap because there is very little bootlegging. The apps are creative tools and games and educational things, not task killers and anti-virus and diagnostics. It is very popular with the consumer users who make up 75% of the computer market.
You're making the mistake of thinking ARM is another PC CPU. It is not.
Porting from PowerPC to Intel is like moving a load from the back of one truck to another. Straightforward. Porting from either of those to ARM is like moving a load from the back of a truck into the back of a sports car. You are going to have to leave some stuff back in the truck. There are design decisions to make, i.e. "which of the stuff in the truck do I need the most, which can I easily live without, how can I compensate for some of the stuff I would like to have but had to leave out?" This requires work by humans, not checking a box to run your code through a second compiler.
Compiling, universal binaries ... not relevant. It could be an Intel SoC in iPad, if it runs at 1 watt you are going to have to rewrite your desktop app to run on there. If your app does not spend most of its time trying to avoid killing the battery, then you are going to have to rewrite your desktop app to run on iPad.
That is why Apple said, "you might as well make a new touch interface as well." All-new apps were always going to be needed for mobile. It is a different kind of computing from desktop in every way.