the finger swipe is 'cool' but you know, its tiring and not all that efficient.
On iOS at least you don't have to swipe at all, you can tap the edge of the page - so you could easily navigate without moving your hands from the edge of the device.
Congrats on the superb UI and interesting os. We need real alternatives to Apple and webos is certainly light years ahead of Android and ahead of iOS in some areas. I use iOS but love the way webos has chosen a different direction in both UI and use of HTML, and the idea of cards is great.
As a developer I'd say I'm hesitant about supporting the plaform purely because of the political calculus - will the suits at hp stand behind this os for long enough to build a real ecosystem, and will they resist the strong pressure from their largest partner ms to kill this once it becomes popular? Unfortunately I don't have confidence that they will do the right thing, and strangely without hp backing it I would be a lot more confident about webos.
The problem is, it isn't a computer. It's a giant smartphone minus the phone.
Which happens to be what many normal people actually want from a computer. For the vast majority of people a tablet is actually a better browsing and email machine than a general purpose computer. I have a laptop (which I use for actual work) and a a tablet, which I use for reading, but the lines are starring to blur, and the tablet and even my phone is often used for emails and real work nowadays.
PS This message comes to you courtesy of one of those newfangled and apparently inferior tablet thingamajigs.
Why does that concern me? Apart from a bit of work/hobbyist related shell/Perl/Python scripter, I'm not a developer
If the article doesn't concern you, don't read it or post comments on it, and accept that other people may have different interests and find this story interesting. Slashdot was not set up entirely to cater to your desires, most of us really don't care whether you find this article interesting or not, and many will find it interesting.
Important thing to know is that your experience isn't typical.
His experience absolutely is typical, in that he has experienced inexplicable, infuriating and inconsistent behaviour from Xcode. Xcode 3 was never great, but 4.x is beta software, which has been rushed out the door without proper quality testing, and as of 4.2, still has serious issues (not just this one). I upgraded a few weeks ago to 4.0.2 as I saw it was now the official release version of Xcode, and am now realising that was a serious mistake. Just as one example, opening the archives window causes huge slowdowns and delays of 30 seconds or so before I can select a menu or perform any action related to archives. I haven't pinned down the reason yet, but that sort of bug never should have made it into production.
Re:Q: Why hasn't Mozilla considered a Firefox OS?
on
Where Is Firefox OS?
·
· Score: 1
Interesting that this dumb idea first came from Andreessen -
Netscape will reduce Windows to a poorly debugged set of device drivers - 1995
That's not to say I think its an idea whose time has come - Chrome OS has frankly been a distraction for Google as Android takes off, Apple tried and failed to go down the web only route for apps on their devices, and WebOS hasn't really gained traction. But it is an idea which has its attractions (though not to denizens of a site like this) - for many users not having to bother with a local file system would be a blessing, and for many developers not having to bother with local installs or creating platform binaries would vastly simplify deployment and upgrades. Our machines (even our phones!) are fast enough that many activities can be done over the network and many apps can happily be network-based. For example many people I know almost exclusively use webmail nowadays, which tells you something about desktop mail clients and their perceived value (I use a desktop client, but recognise that most people do not care to).
What has been happening is that services are moving onto the internet, and the internet is moving onto desktop machines in ways that we wouldn't have dreamed of previously, so in that sense the idea is coming to fruition, though often based on binaries rather than write-once deploy anywhere web apps.
Firefox could potentially expand into this space, but if they do so they are likely to end up gored by operating system vendors who react badly to people intruding on their turf. MS, Apple and Google are all quite capable of trying to cut off the oxygen supply of Firefox, and would happily do so if they started to encroach on operating systems or these vendors' own cloud ventures. Quite apart from that I don't know if Firefox really have the moxie to pull this off - they are struggling already to compete just as a browser with Chrome, Safari, and a newly revived IE. They need to focus on their core competency first.
As to Microsoft's new-found enthusiasm for HTML at the expense of Silverlight - this must have devs who trusted them and committed to Silverlight seething, and I wouldn't trust them at all to support that strategy going forward or deliver on their promises. The most likely outcome is that they have decided to again try to embrace and extend the web itself - they definitely will not let apps work well for long across anything which doesn't have a Microsoft brand on it, and might decide to change course again in a few years as they do seem a little rudderless at the moment.
Just think. With the death of paper books and the move to only digital copies (most of which will be slathered in DRM) you can eliminate the concept of resale, ensure that old editions of books become unusable, and revise history on the fly.
On the contrary, with the death of paperbacks all the classic literature from the past is available for free, forever, and has been copied so many times it will never be possible to modify it and get away with it. Revising history just got a lot harder, and books just got a lot more accessible (previously it was necessary to obtain a paper copy).
PS Most publishers abhor censorship and historical revisionism, I think you're confusing publishers with that DRM straw-man you want to knock down.
I have a rather extensive collection and though they mostly collect dust now I have no plans on ditching them
Unless you have an unusual book collection, the majority of your collection will be dust and glue in 40 years anyway - the paper and glue quality on current paperbacks is atrocious, and their useful lifetime is well below your life expectancy.
I have an extensive book collection which is shrinking rapidly, as I recognise that if I don't use them there is no point in keeping low-quality paperback editions. The first to go were the programming books (far too heavy, far too cumbersome), and gradually the novels are disappearing too. First option now for renting books is an online store - if I want to buy them and keep them of course I find them without DRM, but many novels I only read once. Future generations won't bother buying them - why buy cheap ephemeral paperbacks when the online version is cheaper, easier, searchable, instantly available, and the classics are free?
This shouldn't be seen as a bad thing - we are entering a golden age where all the classic literature and knowledge is available for free online to anyone in the world with an internet connection.
New books will still be published, but they will be a luxury, and they will be beautifully made again, and treasured, as they will be niche objects to record special events, celebrate the work of an artist, etc. People tend to forget the paper book (and indeed the novel) has only been with us a very short while, and is not an inevitable part of everyday life.
Actually, the vulnerability is in the protocol. Never, ever, ever keep critical state client-side.
This vulnerability would still be there if the critical state was server side as well, because the vulnerability is caused by improper access to data, not improper authentication. They may well have had no critical state client-side (and no, the account no is not critical state, they were guessing other account numbers).
Whatever you do with your POSTs that you learned through observation will still only allow to perform actions that our security engine deems to be appropriate for who you have been authenticated to be.
What the parent was pointing out is that there is no point in all the complicated obscurity involving ajax. If you control access to resources properly, it doesn't matter what the user requests, if they are allowed access it will be granted, if not, not.
Having data in the URL is not a problem if your server is properly secured, and there are many cases where having id nos in the URL makes a lot of sense - taking that info out of the URL does not make your server more secure, though of course exposing bank account nos is probably not a good idea.
It is a hack as incorrectly keeping state client-side is one of the trivial first things to look at when assessing web-application security.
The URL has nothing to do with where they kept session state, the session hash doesn't have to live in the URL either, it can live in a cookie. They could have had a URL with a session id hash (or a cookie), storing no state, and still be vulnerable to this if they were stupid enough not to check users were authorised to view the pages they requested. All you'd have to do is log in as a valid user, and you would have access to all the info if they have no proper access control, which would not be fixed by your suggested solution.
This does not have to be about session state being stored on the client-side, in fact it probably wasn't, it is because of inappropriate or non-existant access control.
Wow. Yes, I can see how making accounts accessible via an unhashed URL is really something no one would have guessed would be a problem.
The URL was not the problem (URLs should be readable and uniquely identify a resource, they are not really related to security) - the access control (non-existant) was the problem. Relying on hashes alone would just be security through obscurity. Although they are public information might have been advisable not to use bank account nos in the url, even on a secured connection, but hashed urls do not provide proper access control (which is what they should have had, to check that yes user a really can not look at user b's account, or 1000 others).
They had authentication but not authorization, that's the problem
To be fair, I don't think the intent of bitcoin was a pyramid scheme, but more of a thought experiment brought to life - what if we had a currency which it was impossible to devalue? An interesting concept, but one which unfortunately ignores the ingenuity of people in gaming a system for profit, even or especially one which was designed to be fair. It is fascinating in fact to see people's reactions to such a currency - as I understand it the original idea was not to make lots of money in fiat currencies but to attempt to supplant them, however the value of bitcoins in fiat currency seems to have become a fixation... I wonder if the value they store can be negative:)
Personally I wouldn't buy them, and I certainly wouldn't speculate on their value, but it's an interesting idea. My question for Amir Taaki would be:
Was the original intention of bitcoin to supplant national currencies, and if it did, what would the economic effects be in your opinion?
Isn't that true for most currencies? You know, being off the gold standard and all that. I'm not saying it's a good thing - I just note it.
The value of gold on the free market is also far above the intrinsic value - if fewer people saw gold *purely as a medium of wealth storage* then the value would plummet. Gold is in fact very like a fiat currency, right down to the production and distribution being controlled and manipulated by just a few big players, so its not as if the supply of it is constant or finite. It's not quite as vulnerable as a fiat currency to devaluation, but it is still only as valuable as people think it is.
Bitcoin is an interesting idea, in that it tries to provide a finite supply of coins (once the initial period of production is over) which will mean it cannot be devalued by issuing more - that would make it an ideal currency for a government and/or a public which valued fiscal responsibility. Unfortunately no-one does.
That's the kind of thinking that has cost Microsoft their empire. Those two UI libraries are there because of the fundamental difference between interacting with a desktop and a tablet or phone. To think that there is redundancy there, is to no understand the fundamentals of UI design, don't you think?
Evidently I think not, but I suppose you're trying to be sarcastic. I really don't think the quality of Microsoft's software has anything to do with the rise *or* fall of their empire, but that's a debate for another day.
The two UI libraries are most likely there because they wanted to start from scratch without all the baggage of the desktop, exposed file system, window furniture etc. and wanted to pick and choose what to take from OS X. Some of that is stuff which does not fit a touch UI (window close buttons, overlapping windows), the vast majority of the stuff in UIKit is not related to touch. They could (and probably will) build a revised desktop foundation on top of iOS, and I think the UI changes in OS X are to prepare the users for this. iOS for example has the concept of windows, although these are not really used presently in iOS, and pretty useless on a small device screen, I wonder why?
Building a touch OS on Mac OS would in my opinion be much harder, because lots of assumptions are baked in to cocoa which would make it hard to then try to add touch events etc. and hard to avoid developers porting crap from the old APIs. They could have done it, but obviously felt a rewrite was worthwhile (which is what UIKit mostly is - a rewrite of AppKit with hooks suitable for a touch UI and a lot of the cruft removed). I imagine there were lots of reasons for that decision, but it being impossible to base a touch OS on AppKit because of fundamental UI differences was not one of them.
So you seem to be mistaking the visual and top-level differences between iOS and Mac OS UIs for a fundamental difference in underlying toolkits - there is a lot of redundancy between any two given app toolkits, and in particular between these two, as you'd know if you'd worked with them rather than pontificating on the fundamentals of UI design. For example, we have UIWebView -> WebView, UIView -> NSView etc, etc and there is in fact a huge amount of redundancy and a huge amount of almost identical code. That doesn't mean Apple was wrong to develop UIKit in parallel, or that they didn't need to start again to reinvent their interface, but it does mean it will be painful for them to develop in future as every addition (like WebView) has to be added twice to the API, documented twice, and every developer has to learn two sets of APIs. I suspect eventually over the next 5 years or so they'll do away with the older API, as they have done with the Toolbox APIs, Carbon, QT, Java, etc. And end users won't really notice or care. For some developers like Adobe it will be a painful transition though.
First off, start at the basics: iOS isn't going to "replace" OS X, because they share the same codebase. I know some people here will balk at this description, but iOS is nothing but OS X optimized for mobile touchscreen devices. They're basically the same operating system.
They're the same operating system down at the level of things like NSString and core frameworks, but above that they are different (UIWebView,UILabel, etc etc), and most mac apps would need a pretty complete rewrite to run on iOS. Vice versa isn't quite so hard with a shim but still takes a lot of work (see Chameleon). What's interesting is that Apple have rewritten a lot of view classes etc which didn't need to be rewritten for iOS - they could have used NSView etc quite easily, but they threw it all out and started again, which implies they're going to want to replace NSView with UIView et al at some point.
To say that iOS is going to replace Mac OS (or that this is what Apple intends) would mean big changes. It'd mean dropping legacy Mac apps, and only allowing apps which conform to the new interface paradigm (iOS, UIViews etc) and file access APIs (sandboxed), and probably only apps which they approve to their store, as they have done with iOS. So you can take replacing Mac OS with iOS to mean:
* No more visible file system * No more third party APIs * Full lockdown and sandboxing * No more scripting, java, etc etc (already banned from the app store) * No more selling stuff except through apple (already banned from the app store) * Probably similar gesture based interface, using a larger trackpad (already in progress)
Quite possibly Apple will do this in a few years - it's an insane waste of time to maintain two similar sets of view hierarchies, two entirely different ui libraries etc. and they have shown a predilection for eliminating APIs like this where they can. It would also mean quite a few improvements for end-users in security and ease of use. Not sure if that's a world I'd want to live in though - it would mean massive changes to the way we use our computers for techy Mac users.
Possibly end-users won't notice much of a change if the transition is gradual, particularly those who didn't like folders and files anyway and would rather not see a Library folder etc, but developers would see a huge change (like the one from Carbon to Cocoa in scale).
So on what systems do you suppose these Apple devs are going to be working on if not something comparable to the current line of Mac OS X machines?
Probably ARM-based macs running a fully locked down iOS, but with Apple dev tools installed.
No reason Mac OS has to stick around, and there has to be a reason they've been busily deprecating every API except those which they directly control, and putting more and more emphasis on the interface of iOS as opposed to Mac OS. Lion is yet another underwhelming OS update, after Snow Leopard, and the inclusion of things like full-screen apps (previously anathema on Mac OS) does suggest a dramatic change of focus.
Back to the Mac may well become replacing the Mac at some point - it would dramatically simplify their support requirements, let them move much quicker on things like iCloud, let them charge anyone who wants to do anything using their systems, including developing apps, and as a bonus get rid of a lot of pesky old-school third party developers whom the new Apple seems to detest. I honestly think they could lose Adobe and MS at this point and survive, given their move into consumer systems and devices. For Apple that has to be a revolutionary feeling.
Interesting though that the Apple of 2011 is so close to the Microsoft of the 90s in looking for a vig on every transaction and pushing everything into walled gardens. I see the attraction for them but there are serious downsides for users and developers.
3) Most iTunes passwords are insecure, and are also used for other accounts like Sony
Though your option no.2 is a good description of Apple's reaction to the problem. They should probably offer another level of protection like a certificate per device for login.
It doesn't any more. Log in to your iTunes account and choose None as payment method, and no details will be kept on file. If you don't purchase regularly then it'll be no inconvenience to re-enter them.
Obviously something is wrong with Android's version of this management then, as is is a common complaint with android devices.
As to the ability to see network usage etc, that would be nice, I agree, but it should be optional, not something I actively have to manage - that's the os's job. The important point here is that the user should not *have* to care what apps are running, or how much of the device resources they use - that's a negotiation between app and os. All apps should be instant on and instant off, and take up virtually no resources when off - that is an ideal that iOS has managed to get quite close to.
iOS deals with this differently (just as an example). Apps which consume too much memory when in the background are culled while the user is not using them, and they have enforced strict restrictions on background processing (initially it was banned, now it must be done explicitly). That gets rid of the need for top or application manager or any such program, and is one way to deal with such a problem without involving the user in any way. They could probably be more draconian about this, but they already are quite strict. If an app takes too long to launch for example, the os just kills it. So the user knows the app just keeps dying on them, and the developer is forced to sort out their resources problem asap.
There are many things that suck on iOS (notification system for one), but this is one thing they have done right - apps behaving badly should be the programmer's problem, NOT the user's.
Slashdot Mirror
the finger swipe is 'cool' but you know, its tiring and not all that efficient.
On iOS at least you don't have to swipe at all, you can tap the edge of the page - so you could easily navigate without moving your hands from the edge of the device.
Congrats on the superb UI and interesting os. We need real alternatives to Apple and webos is certainly light years ahead of Android and ahead of iOS in some areas. I use iOS but love the way webos has chosen a different direction in both UI and use of HTML, and the idea of cards is great.
As a developer I'd say I'm hesitant about supporting the plaform purely because of the political calculus - will the suits at hp stand behind this os for long enough to build a real ecosystem, and will they resist the strong pressure from their largest partner ms to kill this once it becomes popular? Unfortunately I don't have confidence that they will do the right thing, and strangely without hp backing it I would be a lot more confident about webos.
The problem is, it isn't a computer. It's a giant smartphone minus the phone.
Which happens to be what many normal people actually want from a computer. For the vast majority of people a tablet is actually a better browsing and email machine than a general purpose computer. I have a laptop (which I use for actual work) and a a tablet, which I use for reading, but the lines are starring to blur, and the tablet and even my phone is often used for emails and real work nowadays.
PS This message comes to you courtesy of one of those newfangled and apparently inferior tablet thingamajigs.
the fact that I can't do shortcuts on the keyboard
This will be in iOS5.
Why does that concern me? Apart from a bit of work/hobbyist related shell/Perl/Python scripter, I'm not a developer
If the article doesn't concern you, don't read it or post comments on it, and accept that other people may have different interests and find this story interesting. Slashdot was not set up entirely to cater to your desires, most of us really don't care whether you find this article interesting or not, and many will find it interesting.
Important thing to know is that your experience isn't typical.
His experience absolutely is typical, in that he has experienced inexplicable, infuriating and inconsistent behaviour from Xcode. Xcode 3 was never great, but 4.x is beta software, which has been rushed out the door without proper quality testing, and as of 4.2, still has serious issues (not just this one). I upgraded a few weeks ago to 4.0.2 as I saw it was now the official release version of Xcode, and am now realising that was a serious mistake. Just as one example, opening the archives window causes huge slowdowns and delays of 30 seconds or so before I can select a menu or perform any action related to archives. I haven't pinned down the reason yet, but that sort of bug never should have made it into production.
Interesting that this dumb idea first came from Andreessen -
Netscape will reduce Windows to a poorly debugged set of device drivers - 1995
That's not to say I think its an idea whose time has come - Chrome OS has frankly been a distraction for Google as Android takes off, Apple tried and failed to go down the web only route for apps on their devices, and WebOS hasn't really gained traction. But it is an idea which has its attractions (though not to denizens of a site like this) - for many users not having to bother with a local file system would be a blessing, and for many developers not having to bother with local installs or creating platform binaries would vastly simplify deployment and upgrades. Our machines (even our phones!) are fast enough that many activities can be done over the network and many apps can happily be network-based. For example many people I know almost exclusively use webmail nowadays, which tells you something about desktop mail clients and their perceived value (I use a desktop client, but recognise that most people do not care to).
What has been happening is that services are moving onto the internet, and the internet is moving onto desktop machines in ways that we wouldn't have dreamed of previously, so in that sense the idea is coming to fruition, though often based on binaries rather than write-once deploy anywhere web apps.
Firefox could potentially expand into this space, but if they do so they are likely to end up gored by operating system vendors who react badly to people intruding on their turf. MS, Apple and Google are all quite capable of trying to cut off the oxygen supply of Firefox, and would happily do so if they started to encroach on operating systems or these vendors' own cloud ventures. Quite apart from that I don't know if Firefox really have the moxie to pull this off - they are struggling already to compete just as a browser with Chrome, Safari, and a newly revived IE. They need to focus on their core competency first.
As to Microsoft's new-found enthusiasm for HTML at the expense of Silverlight - this must have devs who trusted them and committed to Silverlight seething, and I wouldn't trust them at all to support that strategy going forward or deliver on their promises. The most likely outcome is that they have decided to again try to embrace and extend the web itself - they definitely will not let apps work well for long across anything which doesn't have a Microsoft brand on it, and might decide to change course again in a few years as they do seem a little rudderless at the moment.
Just think. With the death of paper books and the move to only digital copies (most of which will be slathered in DRM) you can eliminate the concept of resale, ensure that old editions of books become unusable, and revise history on the fly.
On the contrary, with the death of paperbacks all the classic literature from the past is available for free, forever, and has been copied so many times it will never be possible to modify it and get away with it. Revising history just got a lot harder, and books just got a lot more accessible (previously it was necessary to obtain a paper copy).
PS Most publishers abhor censorship and historical revisionism, I think you're confusing publishers with that DRM straw-man you want to knock down.
I have a rather extensive collection and though they mostly collect dust now I have no plans on ditching them
Unless you have an unusual book collection, the majority of your collection will be dust and glue in 40 years anyway - the paper and glue quality on current paperbacks is atrocious, and their useful lifetime is well below your life expectancy.
I have an extensive book collection which is shrinking rapidly, as I recognise that if I don't use them there is no point in keeping low-quality paperback editions. The first to go were the programming books (far too heavy, far too cumbersome), and gradually the novels are disappearing too. First option now for renting books is an online store - if I want to buy them and keep them of course I find them without DRM, but many novels I only read once. Future generations won't bother buying them - why buy cheap ephemeral paperbacks when the online version is cheaper, easier, searchable, instantly available, and the classics are free?
This shouldn't be seen as a bad thing - we are entering a golden age where all the classic literature and knowledge is available for free online to anyone in the world with an internet connection.
New books will still be published, but they will be a luxury, and they will be beautifully made again, and treasured, as they will be niche objects to record special events, celebrate the work of an artist, etc. People tend to forget the paper book (and indeed the novel) has only been with us a very short while, and is not an inevitable part of everyday life.
Every time I turn on my computer, another update... just do it silently already if it's such a problem otherwise I'm going to uninstall.
I already have. You won't miss much, and I doubt it'll stay the standard container format for web video much longer.
Actually, the vulnerability is in the protocol. Never, ever, ever keep critical state client-side.
This vulnerability would still be there if the critical state was server side as well, because the vulnerability is caused by improper access to data, not improper authentication. They may well have had no critical state client-side (and no, the account no is not critical state, they were guessing other account numbers).
Whatever you do with your POSTs that you learned through observation will still only allow to perform actions that our security engine deems to be appropriate for who you have been authenticated to be.
What the parent was pointing out is that there is no point in all the complicated obscurity involving ajax. If you control access to resources properly, it doesn't matter what the user requests, if they are allowed access it will be granted, if not, not.
Having data in the URL is not a problem if your server is properly secured, and there are many cases where having id nos in the URL makes a lot of sense - taking that info out of the URL does not make your server more secure, though of course exposing bank account nos is probably not a good idea.
It is a hack as incorrectly keeping state client-side is one of the trivial first things to look at when assessing web-application security.
The URL has nothing to do with where they kept session state, the session hash doesn't have to live in the URL either, it can live in a cookie. They could have had a URL with a session id hash (or a cookie), storing no state, and still be vulnerable to this if they were stupid enough not to check users were authorised to view the pages they requested. All you'd have to do is log in as a valid user, and you would have access to all the info if they have no proper access control, which would not be fixed by your suggested solution.
This does not have to be about session state being stored on the client-side, in fact it probably wasn't, it is because of inappropriate or non-existant access control.
Wow. Yes, I can see how making accounts accessible via an unhashed URL is really something no one would have guessed would be a problem.
The URL was not the problem (URLs should be readable and uniquely identify a resource, they are not really related to security) - the access control (non-existant) was the problem. Relying on hashes alone would just be security through obscurity. Although they are public information might have been advisable not to use bank account nos in the url, even on a secured connection, but hashed urls do not provide proper access control (which is what they should have had, to check that yes user a really can not look at user b's account, or 1000 others).
They had authentication but not authorization, that's the problem
To be fair, I don't think the intent of bitcoin was a pyramid scheme, but more of a thought experiment brought to life - what if we had a currency which it was impossible to devalue? An interesting concept, but one which unfortunately ignores the ingenuity of people in gaming a system for profit, even or especially one which was designed to be fair. It is fascinating in fact to see people's reactions to such a currency - as I understand it the original idea was not to make lots of money in fiat currencies but to attempt to supplant them, however the value of bitcoins in fiat currency seems to have become a fixation... I wonder if the value they store can be negative :)
Personally I wouldn't buy them, and I certainly wouldn't speculate on their value, but it's an interesting idea. My question for Amir Taaki would be:
Was the original intention of bitcoin to supplant national currencies, and if it did, what would the economic effects be in your opinion?
Isn't that true for most currencies? You know, being off the gold standard and all that. I'm not saying it's a good thing - I just note it.
The value of gold on the free market is also far above the intrinsic value - if fewer people saw gold *purely as a medium of wealth storage* then the value would plummet. Gold is in fact very like a fiat currency, right down to the production and distribution being controlled and manipulated by just a few big players, so its not as if the supply of it is constant or finite. It's not quite as vulnerable as a fiat currency to devaluation, but it is still only as valuable as people think it is.
Bitcoin is an interesting idea, in that it tries to provide a finite supply of coins (once the initial period of production is over) which will mean it cannot be devalued by issuing more - that would make it an ideal currency for a government and/or a public which valued fiscal responsibility. Unfortunately no-one does.
That's the kind of thinking that has cost Microsoft their empire. Those two UI libraries are there because of the fundamental difference between interacting with a desktop and a tablet or phone. To think that there is redundancy there, is to no understand the fundamentals of UI design, don't you think?
Evidently I think not, but I suppose you're trying to be sarcastic. I really don't think the quality of Microsoft's software has anything to do with the rise *or* fall of their empire, but that's a debate for another day.
The two UI libraries are most likely there because they wanted to start from scratch without all the baggage of the desktop, exposed file system, window furniture etc. and wanted to pick and choose what to take from OS X. Some of that is stuff which does not fit a touch UI (window close buttons, overlapping windows), the vast majority of the stuff in UIKit is not related to touch. They could (and probably will) build a revised desktop foundation on top of iOS, and I think the UI changes in OS X are to prepare the users for this. iOS for example has the concept of windows, although these are not really used presently in iOS, and pretty useless on a small device screen, I wonder why?
Building a touch OS on Mac OS would in my opinion be much harder, because lots of assumptions are baked in to cocoa which would make it hard to then try to add touch events etc. and hard to avoid developers porting crap from the old APIs. They could have done it, but obviously felt a rewrite was worthwhile (which is what UIKit mostly is - a rewrite of AppKit with hooks suitable for a touch UI and a lot of the cruft removed). I imagine there were lots of reasons for that decision, but it being impossible to base a touch OS on AppKit because of fundamental UI differences was not one of them.
So you seem to be mistaking the visual and top-level differences between iOS and Mac OS UIs for a fundamental difference in underlying toolkits - there is a lot of redundancy between any two given app toolkits, and in particular between these two, as you'd know if you'd worked with them rather than pontificating on the fundamentals of UI design. For example, we have UIWebView -> WebView, UIView -> NSView etc, etc and there is in fact a huge amount of redundancy and a huge amount of almost identical code. That doesn't mean Apple was wrong to develop UIKit in parallel, or that they didn't need to start again to reinvent their interface, but it does mean it will be painful for them to develop in future as every addition (like WebView) has to be added twice to the API, documented twice, and every developer has to learn two sets of APIs. I suspect eventually over the next 5 years or so they'll do away with the older API, as they have done with the Toolbox APIs, Carbon, QT, Java, etc. And end users won't really notice or care. For some developers like Adobe it will be a painful transition though.
First off, start at the basics: iOS isn't going to "replace" OS X, because they share the same codebase. I know some people here will balk at this description, but iOS is nothing but OS X optimized for mobile touchscreen devices. They're basically the same operating system.
They're the same operating system down at the level of things like NSString and core frameworks, but above that they are different (UIWebView,UILabel, etc etc), and most mac apps would need a pretty complete rewrite to run on iOS. Vice versa isn't quite so hard with a shim but still takes a lot of work (see Chameleon). What's interesting is that Apple have rewritten a lot of view classes etc which didn't need to be rewritten for iOS - they could have used NSView etc quite easily, but they threw it all out and started again, which implies they're going to want to replace NSView with UIView et al at some point.
To say that iOS is going to replace Mac OS (or that this is what Apple intends) would mean big changes. It'd mean dropping legacy Mac apps, and only allowing apps which conform to the new interface paradigm (iOS, UIViews etc) and file access APIs (sandboxed), and probably only apps which they approve to their store, as they have done with iOS. So you can take replacing Mac OS with iOS to mean:
* No more visible file system
* No more third party APIs
* Full lockdown and sandboxing
* No more scripting, java, etc etc (already banned from the app store)
* No more selling stuff except through apple (already banned from the app store)
* Probably similar gesture based interface, using a larger trackpad (already in progress)
Quite possibly Apple will do this in a few years - it's an insane waste of time to maintain two similar sets of view hierarchies, two entirely different ui libraries etc. and they have shown a predilection for eliminating APIs like this where they can. It would also mean quite a few improvements for end-users in security and ease of use. Not sure if that's a world I'd want to live in though - it would mean massive changes to the way we use our computers for techy Mac users.
Possibly end-users won't notice much of a change if the transition is gradual, particularly those who didn't like folders and files anyway and would rather not see a Library folder etc, but developers would see a huge change (like the one from Carbon to Cocoa in scale).
So on what systems do you suppose these Apple devs are going to be working on if not something comparable to the current line of Mac OS X machines?
Probably ARM-based macs running a fully locked down iOS, but with Apple dev tools installed.
No reason Mac OS has to stick around, and there has to be a reason they've been busily deprecating every API except those which they directly control, and putting more and more emphasis on the interface of iOS as opposed to Mac OS. Lion is yet another underwhelming OS update, after Snow Leopard, and the inclusion of things like full-screen apps (previously anathema on Mac OS) does suggest a dramatic change of focus.
Back to the Mac may well become replacing the Mac at some point - it would dramatically simplify their support requirements, let them move much quicker on things like iCloud, let them charge anyone who wants to do anything using their systems, including developing apps, and as a bonus get rid of a lot of pesky old-school third party developers whom the new Apple seems to detest. I honestly think they could lose Adobe and MS at this point and survive, given their move into consumer systems and devices. For Apple that has to be a revolutionary feeling.
Interesting though that the Apple of 2011 is so close to the Microsoft of the 90s in looking for a vig on every transaction and pushing everything into walled gardens. I see the attraction for them but there are serious downsides for users and developers.
You missed out:
3) Most iTunes passwords are insecure, and are also used for other accounts like Sony
Though your option no.2 is a good description of Apple's reaction to the problem. They should probably offer another level of protection like a certificate per device for login.
It doesn't any more. Log in to your iTunes account and choose None as payment method, and no details will be kept on file. If you don't purchase regularly then it'll be no inconvenience to re-enter them.
It's OK, I've seen state's on the internet before - here is the justification.
I mean, for $25 I get legal versions of every single—ahem, questionably procured, shall we say— tracks in my gigantic iTunes library?
$25 a year for life.
That's far less than a few people spend a year on music, but more than most people spend per year on music.
Obviously something is wrong with Android's version of this management then, as is is a common complaint with android devices.
As to the ability to see network usage etc, that would be nice, I agree, but it should be optional, not something I actively have to manage - that's the os's job. The important point here is that the user should not *have* to care what apps are running, or how much of the device resources they use - that's a negotiation between app and os. All apps should be instant on and instant off, and take up virtually no resources when off - that is an ideal that iOS has managed to get quite close to.
iOS deals with this differently (just as an example). Apps which consume too much memory when in the background are culled while the user is not using them, and they have enforced strict restrictions on background processing (initially it was banned, now it must be done explicitly). That gets rid of the need for top or application manager or any such program, and is one way to deal with such a problem without involving the user in any way. They could probably be more draconian about this, but they already are quite strict. If an app takes too long to launch for example, the os just kills it. So the user knows the app just keeps dying on them, and the developer is forced to sort out their resources problem asap.
There are many things that suck on iOS (notification system for one), but this is one thing they have done right - apps behaving badly should be the programmer's problem, NOT the user's.