Incorrect. The problem with nuclear is the cost. There is a good reason no private companies will touch it without huge subsidies. Fusion might be feasible if we can get it to work but for large scale power generation nuclear fission is just too expensive if you actually include real decommissioning, waste and insurance costs. Compared to coal for example it is less polluting but IMO we should be pouring money into hydro, wave and solar to bring the costs down instead of building more coal gas and fission stations.
Read the first two sentences again; I didn't say paper covers cost more to design, I said the origination costs were the largest part of making a book (digital or paper), NOT the printing costs, unless you are selling hundreds of thousands. I'm sure we'll never get to the point where it isn't necessary to design a book properly for print or the web.
However as to everything else, colour is neither satisfactory nor cheap on eink just now, web browsing which works well is impossible due to refresh rates, video is similarly impossible, and stuff like a calendar etc doesn't really make commercial sense for Amazon when they are also pushing android apps via their store. Given the resources put into their android store I'd expect to see them move entirely to that at some point soon. So you may see android devices with an eink screen which can view PDFs etc, but at that point the limitations will become even more painfully apparent; stuff which requires scrolling is not going to work well if the refresh rate is still slow.
Origination costs (including cover art, typesetting etc) are by far the highest costs when producing paper books. Then there are publicity & promotions etc. None of those costs go away when publishing online. Publishers don't typically make a lot of money from books (paper or not) unless they happen to publish someone like Dan Brown,and their costs for digital publishing are not significantly lower, but they are obviously slightly lower. Probably the biggest bonus is not having to deal with storage, shipping and warehousing.
It's interesting that you mention hardback books as a fair markup as typically the extra cost to produce those is negligible - they are simple a way of making money from early buyers who want the book badly. The markup on them is nowhere near proportional to the costs of production.
Perhaps what you are hoping for just isn't possible with eink?
I'm sure if amazon could use eink for colour and *responsive* web browsing they would have done so. The fact that they have moved to LCD in order to cater to the people who do want exactly what you say you want should tell you something about the capabilities of the different screen techs and whether they see eink as ever doing well for web browsing and colour or interactive media.
Also, the addition of a touch screen to the normal kindle definitely is not a small step- it's a huge change in the way you interact with the device. If it weren't for the fire everyone would be more interested in it. If the fire does well I imagine they'll move all their eink readers to android too (hence the new touchscreen) so there's no point them developing lots of apps for an older kindle platform at this point. The kindle as a separate software platform from android will probably die off at some point, so really the fire is closer to future kindles than the kindle.
Can you prevent or even detect a jailbroken phone?
I'm glad you used the word phone there, and not iPhone, as it implies you understand that your point applies equally to any hardware once it is out in the wild and not in the hands of the IT department. People can root devices, they can impersonate devices, and they can use social engineering to get hold of information (passwords/pins) that they shouldn't have - it is impossible to provide total security. You have to deal with it if you provide internet-facing services of any sort, and device security is not something you can guarantee on any platform with a malicious and sufficiently motivated user, all you can do is do the best you can with that platform.
Mandating one platform may make your life easier as an IT dept., but when Blackberry and RIM go tits up or are bought out by MS in a few years (which is in my opinion inevitable given their recent performance), you've just bet the company on devices with no future and cost your boss an awful lot of money, all because it made your life easier.
That's why it would be a safe *business* decision to support open protocols and leave the portable devices up the user, and not try to guarantee security on devices you don't ultimately control, and for data that you can never sufficiently control.
Search the news and find articles saying pre-screening is bad for some reason, in prostrate, breast, and cervical cancer - that I have seen so far. Yes, false positives are bad, and could be the real issue here. And greedy insurance companies could be the issue too. We haven't get the evidence or research to prove either issue yet.
If you'd bothered to research the news articles, or even read this FA, you'd have seen that we do have the research, and it points to cancer screening often not being a net benefit in terms of saving lives, and the treatment that results affecting quality of life in a more negative way than the cancer would have for the majority of patients. That's pretty clear cut, explained in the article, and is backed up by research around the world, and is starting to lead to policy changes. Here is a quote as you clearly can't be bothered to click the link:
Two recent clinical trials of prostate cancer screening cast doubt on whether many lives — or any — are saved. And it said that screening often leads to what can be disabling treatments for men whose cancer otherwise would never have harmed them.
But I can't see the logic of dealing with false positives by eliminating testing altogether, especially via news articles, and frases such as "cancer screening is pointless and could be bad for you".
Sometimes too much testing is a Bad Thing, the article attempted to explain this to laypeople but is, believe it or not (I suspect you will choose not), based on solid research. Screening is unlikely to be entirely phased out, but a far more targeted approach is warranted, and would save lives, save money (which means saving lives in other areas), and lead to better outcomes for many people with non-agressive tumors late in life.
There are many unintentionally hilarious moments in this long document, but I like this one the best:
So please call this combined operating system "GNU/Linux" in all the publicity, in the titles and description of the session, track, event, etc., if and when you have reason to refer to it.
Many of these requirements are really of no interest to anyone save the narcissist author of the document.
I assure you that, in sending instructions to someone, more words are better than fewer.
On the contrary, a more succinct document is both are more likely to be read, and far more likely to contain only the information required, and no more. Not bullshit requests for small bottles of pepsi/not coke (really, he defines himself politically by his choice of sugary water, and by choosing a company just as evil?).
This is a document about how RMS works, not the rest of the world.
I'd say it's a better description of how RMS fails to work with or engage with the rest of the world.
Re:Just seems like a well thought out list
on
The RMS Tour Rider
·
· Score: 1
You are using the Special pleading logical fallacy.
And yes, a "serious" web application (NOT a webpage) requires a lot more than HTML/JS can currently reasonably and *efficiently* provide. I can (and do) design and implement apps in Flex in a fraction of the time it would take with the sloppy mess that results when you have a "huge variety of tools" that were never designed for the purpose of RIA and don't work together nearly as well. These applications are "serious" because they are expected to provide the ability for users to efficiently and correctly input non trivial data like GIS (map) data, scientific data, financials data and other similarly "serious" subjects.
There's nothing about HTML/JS which requires you to create a sloppy mess, and there's no need for one person to use a huge variety of tools - I was pointing out that the tools you use to server HTML can vary hugely, and can easily be interchanged without the user noticing, not that you are required to use a huge number of tools.
The disadvantages of http/html as opposed to desktop apps are in many cases actually strengths, and I wouldn't touch something like GWT either with a bargepole because they are working against the strengths of the web to try to make it into something it is not. Enforcing a stateless UI, being agnostic to the sort of device reading the data, and always serving the same resource at the same URI regardless who asks are huge advantages when it comes to data integrity and a stable, predictable UI even for what you consider 'serious' subjects. The concept of RIA is in itself questionable in my opinion, born of desktop developers moving to the web, and can easily result in the sort of mess you denigrate in your post as inevitable when using plain HTML.
The aim of plugins like Silverlight and Frameworks like Flex is to lock users into an ecosystem which they can't escape later, and also to try to reproduce all the flaws and failings of desktop UIs on the web, which is why I'd prefer to use other tools which do not lock me into using Adobe products. Personally I wouldn't trust Adobe with my career or my clients data by using Flex, but if you feel it's a stable platform to target, that's fine - doesn't mean you should denigrate other tools as toys or only capable of creating social networking sites - that's patently bullshit and just undermines your position.
I love people who use the word serious to describe what they do ( and by implication consider other approaches non-serious and unworthy of attention). If you can get over your disdain for the rest of the world you might find there are good reasons to avoid locking your content in a binary shell. You can stay in your silverlight/flash binary ghetto if you want, but in the meantime lots of people are building the most popular websites on the web without flash using a huge variety of tools but delivering plain old HTML- those websites don't need flash, silverlight or any other plugins ( though typically they use it for trivial stuff like ads, if at all), and yet they serve most of the content on the web. I guess they aren't serious though.
I don't view flash any more, haven't for a few years.
The only content I miss is video on some websites like the BBC which refuse to serve their video as video files, and graphics like the ones you mention at nytimes.com say ( though actually not many sites produce infographics worthy of the name).
Having graphic content in HTML is going to be a lot better for everyone (more accessible, easier to mash up, easier to extract data), and when adobe completes migrating their tools to produce HTML, there really will be no excuses left. Its actually pretty easy to build interactive content right now with HTML, but when the wysiwyg tools switch, all the laggards will switch with them.
Actually as a designer I'd say that adobe doesn't really get designers any more - their tools feel like quark in the 90's - entering a long slow decline where the marking department add useless features every year like Export for Microsoft word or magic repair features that could never work, while ignoring glaring ui inconsistencies, awful installers, and crashing bugs, and then gouge design departments for as much money as they can manage. The latest versions of their cs suites have been a disappointment to me for this reason. It feels like all the people who care about the quality of the products have left Adobe and Macromedia has been dead for years.
That's really a quote from Picasso, mangled by Jobs.
Jobs was feeling vindictive about Google because of the history of having Schmidt in the Apple board-room from 2006-2009. He may have had some reason to feel betrayed if he knew nothing about the first Google phone until the iPhone was quite advanced, however his overreaction made Apple blind to the hypocrisy of their position. Just to cite one small example, they blatantly stole notification ideas from Google (notifications in iOS were pitiful and really annoying till iOS 5), and yet they're complaining about Android devices having a similar grid of icons etc. It really is laughable given the number of ideas iOS has borrowed from elsewhere.
Instead of whining about others copying them, they should just continue to produce the best phones in the industry, and let Android fight over the bottom of the market. I'd expect to see Tim Cook normalise relations with Samsung etc in due course, as frankly they don't have much of a case, and it's really embarrassing to see them squabbling with the people who supply much of their hardware. It'd be a good way to step out of the shadow of Jobs and show they are confident about the future.
Everything that you like about open source BSD-licensed projects is simply encoded for legal enforcement in the GPL
People are not idiots, and for some reason lots of them choose BSD/MIT/CCA over GPL. Apparently you believe that everyone thinks like you (or will when they see the light), and everyone wants to restrict users of their code in perpetuity to releasing the code under the exact same license.
Strangely enough, lots of developers don't think like you and really do want to release the source without restriction so they choose an attribution only license instead of GPL. They don't choose BSD because they have made a mistake, or they forgot to cover the restrictions in GPL, they choose it because it is less restrictive.
You can do anything with the GPL as long as you include sources. If you disagree with this, you don't have to contribute to it.
You can do anything with BSD even if you don't include sources, as long as you include attribution. Obviously both have different uses, and BSD is less restrictive. GPL may be clearly preferable to you, but let's not get into sophistry about GPL being 'clearly more free'.
You don't have to try to convert the rest of the world to using the one true license, in fact arguments like this slagging off other licenses are exactly what puts people off going near GPL code.
Because clearly what we need is _yet another_ way to develop web applications.
Well, why not?
Doesn't matter to the end users what language was used for the back-end, and some programmers will be more familiar or comfortable with Perl. Maybe you don't need this, and I personally have no intention of using it, but some people might find it interesting.
Look at smartphones, Windows Mobile phones were around way before the iPhone, but they were never popular in the mainstream because they didn't have the "cool factor".
This is a reassuring geek fantasy (goes along with the 'great marketing' fantasy I suppose), but completely untrue.
Smartphones were made popular by the iPhone (and to some extent the blackberry before it) because it was better - better to look at sure, but more importantly better in design, better to use, and actually incredibly useful for the users who tried it. WM was a buggy, mediocre, hack-handed mess - people tried it and quite rightly gave up on it and went back to a simpler phone; not because it wasn't cool but because it crashed all the time, *and* top people at MS have no taste so it looked and felt awkward to use.
So, yes, Apple are great at what they do, but to say that they would be where they are without the competition is ridiculous.
Completely agree with you there - some things Apple do are duds (notifications in early iOS are a good example, they were terrible modal distractions), and some things they do are just OK till they see someone doing something better and copy it. Siri was bought in so it was not even developed at Apple, but they do know how to integrate things like that well, and how to steal ideas from competitors and do them better (Notifications from Android for example). One thing they do better than all of their competition though is to actually design their products (as opposed to letting them organically grow), throw out old ideas that aren't working, and to refine ideas which other people have had till they work really smoothly.
None of that is really 'cool', it's hard work and a willingness to go their own way when it suits them and shamelessly steal ideas when they see a better product. There's a lot of work that goes in behind the scenes to make iOS a pleasure to use (not just programming work).
They do need competitors to keep them at their best, without question.
The government can seize a server from your home, your ISP or anywhere else they wish. This has nothing to do with email being free or not, but where the server is based, and whether your government has power (or influence) over the local law enforcement at that location.
First time I've seen Apple's website go down (as opposed to the store) - someone messed up when updating the store perhaps?
http://www.apple.com/ Access Denied You don't have permission to access "http://www.apple.com/" on this server. Reference #18.47efd4d9.1317755036.25f60c38
The correct answer of course is to hire a van, not ask why your small compact cannot carry a sofa. Eink will never be suitable for browsing, so it's useless for most people except to read text-only books. If that is all you want to do great.
Any replacement(s) will be shitty, too. It won't matter who creates them, or how they're implemented. They will be shitty. That's just the nature of any attempt to have the browser host remotely complex applications. The browser is merely a document viewer and navigator; it is not an operating system of some sort. It will always fail as an operating system or an application host.
This is a debate with a long and storied history going back to Andreessen, and probably beyond. Browsers have taken over much of the work done by native apps on many operating systems, and whether you like it or not, that's a trend which is accelerating, notwithstanding the recent trend for mobile binaries. There are a good reasons for the way the web has taken over our computing lives, and also good reasons why binary solutions like Flash are gradually being deprecated - they break one of the main advantages of the web, which is that it works everywhere - even on devices which haven't been invented yet. That is also why various companies have attempted to introduce binary solutions to web problems - in order to gain a stranglehold on the market again, as they can easily do with binary apps (all the solutions you list were attempts to do this, from applets, to ActiveX to Flash).
It's interesting that you focus on javascript as a roadblock and blunder, as javascript is not actually the language the vast majority of the code in web apps is written in - it's used as a simple way to add interactivity and animation to documents, and occasionally to allow requests for page fragments. I suppose it makes a good rant if you can focus on javascript which, if you know nothing about it, seems an easy punch-bag. It's actually quite an interesting language, though I wouldn't try to create something large in it. The javascript involved in creating a modern web application is typically pretty minimal, and often reliant on libraries like query which smooth out a lot of the inconsistencies between browsers, so javascript is not really the question when comparing flash to html development to native binaries. It's not the technology in which the vast majority of time is spent for web app development - on the contrary, it is strictly optional. The languages used for actual web development vary wildly from C variants, perl, PHP (ugh), ruby, python, smalltalk etc etc. You can use whichever language or framework you like when developing web apps, and the beauty of it is, your users won't care, whether they are viewing it on a mac desktop from 2005 or a Windows phone from 2011.
The end result is that the browser should not be used for anything more than displaying and linking documents.
The vast majority of the work many people do all day includes displaying, editing and linking documents - for that the web is a perfect fit - a far better fit than binary apps like MS Word. For something like photoshop editing huge image files, a binary is still the answer, but it does have downsides. The real question is what trade-offs does your app face, and do the advantages of a web app (faster deployment, cross-platform, document based, stateless, collaborative) outweigh the disadvantages compared to binaries (slower performance, non-local, network dependent, limited file access etc). That's not an equation which has the same answer for all apps or all people, but it's clearly one which has worked out in favour of web technology for huge numbers of apps.
When you hear the word "play", don't think World of Warcraft; think golf. Or consider the full word "playbook" in the context of football, but when you think of football think executive suite at an NFL stadium.
Wow, that argument is almost as convincing as the one about 'keeping RIM in the corporate conversation'. Why would a playbook be more suited to a golf course, than the phone the executive already have - is there some masterful golf app tailored to the golfing style of company executives available? Does it come with a free executive caddy? The name sums it up really - a supposedly corporate device named as if it were a toy.
The Playbook is a completely directionless product which arrived without an email app (from RIM and no email!!), has done nothing to attract developers, is overpriced compared to the competition, and will not properly integrate with the Android ecosystem despite throwing away any possibility of its own app ecosystem long-term by saying they will support android. It is dead on arrival, and RIM would have done better not to produce it, as it shows just how incompetent and out of touch they are. Relying on a phone just to do email is a good example of how out of touch they are. They've recently massively dropped the price to clear inventory, but it will end in ignominious defeat soon enough when they cancel it and retreat to the phone market.
The key to tablets is their use-case: web, email, content consumption and apps. On none of those except perhaps web browser is the RIM tablet even remotely convincing out of the box.
Slashdot Mirror
Incorrect. The problem with nuclear is the cost. There is a good reason no private companies will touch it without huge subsidies. Fusion might be feasible if we can get it to work but for large scale power generation nuclear fission is just too expensive if you actually include real decommissioning, waste and insurance costs. Compared to coal for example it is less polluting but IMO we should be pouring money into hydro, wave and solar to bring the costs down instead of building more coal gas and fission stations.
Read the first two sentences again; I didn't say paper covers cost more to design, I said the origination costs were the largest part of making a book (digital or paper), NOT the printing costs, unless you are selling hundreds of thousands. I'm sure we'll never get to the point where it isn't necessary to design a book properly for print or the web.
PDFs definitely could (and should) be done.
However as to everything else, colour is neither satisfactory nor cheap on eink just now, web browsing which works well is impossible due to refresh rates, video is similarly impossible, and stuff like a calendar etc doesn't really make commercial sense for Amazon when they are also pushing android apps via their store. Given the resources put into their android store I'd expect to see them move entirely to that at some point soon. So you may see android devices with an eink screen which can view PDFs etc, but at that point the limitations will become even more painfully apparent; stuff which requires scrolling is not going to work well if the refresh rate is still slow.
Origination costs (including cover art, typesetting etc) are by far the highest costs when producing paper books. Then there are publicity & promotions etc. None of those costs go away when publishing online. Publishers don't typically make a lot of money from books (paper or not) unless they happen to publish someone like Dan Brown,and their costs for digital publishing are not significantly lower, but they are obviously slightly lower. Probably the biggest bonus is not having to deal with storage, shipping and warehousing.
It's interesting that you mention hardback books as a fair markup as typically the extra cost to produce those is negligible - they are simple a way of making money from early buyers who want the book badly. The markup on them is nowhere near proportional to the costs of production.
Perhaps what you are hoping for just isn't possible with eink?
I'm sure if amazon could use eink for colour and *responsive* web browsing they would have done so. The fact that they have moved to LCD in order to cater to the people who do want exactly what you say you want should tell you something about the capabilities of the different screen techs and whether they see eink as ever doing well for web browsing and colour or interactive media.
Also, the addition of a touch screen to the normal kindle definitely is not a small step- it's a huge change in the way you interact with the device. If it weren't for the fire everyone would be more interested in it. If the fire does well I imagine they'll move all their eink readers to android too (hence the new touchscreen) so there's no point them developing lots of apps for an older kindle platform at this point. The kindle as a separate software platform from android will probably die off at some point, so really the fire is closer to future kindles than the kindle.
Can you prevent or even detect a jailbroken phone?
I'm glad you used the word phone there, and not iPhone, as it implies you understand that your point applies equally to any hardware once it is out in the wild and not in the hands of the IT department. People can root devices, they can impersonate devices, and they can use social engineering to get hold of information (passwords/pins) that they shouldn't have - it is impossible to provide total security. You have to deal with it if you provide internet-facing services of any sort, and device security is not something you can guarantee on any platform with a malicious and sufficiently motivated user, all you can do is do the best you can with that platform.
Mandating one platform may make your life easier as an IT dept., but when Blackberry and RIM go tits up or are bought out by MS in a few years (which is in my opinion inevitable given their recent performance), you've just bet the company on devices with no future and cost your boss an awful lot of money, all because it made your life easier.
That's why it would be a safe *business* decision to support open protocols and leave the portable devices up the user, and not try to guarantee security on devices you don't ultimately control, and for data that you can never sufficiently control.
Search the news and find articles saying pre-screening is bad for some reason, in prostrate, breast, and cervical cancer - that I have seen so far. Yes, false positives are bad, and could be the real issue here. And greedy insurance companies could be the issue too. We haven't get the evidence or research to prove either issue yet.
If you'd bothered to research the news articles, or even read this FA, you'd have seen that we do have the research, and it points to cancer screening often not being a net benefit in terms of saving lives, and the treatment that results affecting quality of life in a more negative way than the cancer would have for the majority of patients. That's pretty clear cut, explained in the article, and is backed up by research around the world, and is starting to lead to policy changes. Here is a quote as you clearly can't be bothered to click the link:
Two recent clinical trials of prostate cancer screening cast doubt on whether many lives — or any — are saved. And it said that screening often leads to what can be disabling treatments for men whose cancer otherwise would never have harmed them.
But I can't see the logic of dealing with false positives by eliminating testing altogether, especially via news articles, and frases such as "cancer screening is pointless and could be bad for you".
Sometimes too much testing is a Bad Thing, the article attempted to explain this to laypeople but is, believe it or not (I suspect you will choose not), based on solid research. Screening is unlikely to be entirely phased out, but a far more targeted approach is warranted, and would save lives, save money (which means saving lives in other areas), and lead to better outcomes for many people with non-agressive tumors late in life.
Where? Which detail was needless?
There are many unintentionally hilarious moments in this long document, but I like this one the best:
Many of these requirements are really of no interest to anyone save the narcissist author of the document.
I assure you that, in sending instructions to someone, more words are better than fewer.
On the contrary, a more succinct document is both are more likely to be read, and far more likely to contain only the information required, and no more. Not bullshit requests for small bottles of pepsi/not coke (really, he defines himself politically by his choice of sugary water, and by choosing a company just as evil?).
This is a document about how RMS works, not the rest of the world.
I'd say it's a better description of how RMS fails to work with or engage with the rest of the world.
You are using the Special pleading logical fallacy.
And you are using wikiphilosophy ~
I "love" irony.
Me too; that's why I chose the handle.
And yes, a "serious" web application (NOT a webpage) requires a lot more than HTML/JS can currently reasonably and *efficiently* provide. I can (and do) design and implement apps in Flex in a fraction of the time it would take with the sloppy mess that results when you have a "huge variety of tools" that were never designed for the purpose of RIA and don't work together nearly as well. These applications are "serious" because they are expected to provide the ability for users to efficiently and correctly input non trivial data like GIS (map) data, scientific data, financials data and other similarly "serious" subjects.
There's nothing about HTML/JS which requires you to create a sloppy mess, and there's no need for one person to use a huge variety of tools - I was pointing out that the tools you use to server HTML can vary hugely, and can easily be interchanged without the user noticing, not that you are required to use a huge number of tools.
The disadvantages of http/html as opposed to desktop apps are in many cases actually strengths, and I wouldn't touch something like GWT either with a bargepole because they are working against the strengths of the web to try to make it into something it is not. Enforcing a stateless UI, being agnostic to the sort of device reading the data, and always serving the same resource at the same URI regardless who asks are huge advantages when it comes to data integrity and a stable, predictable UI even for what you consider 'serious' subjects. The concept of RIA is in itself questionable in my opinion, born of desktop developers moving to the web, and can easily result in the sort of mess you denigrate in your post as inevitable when using plain HTML.
The aim of plugins like Silverlight and Frameworks like Flex is to lock users into an ecosystem which they can't escape later, and also to try to reproduce all the flaws and failings of desktop UIs on the web, which is why I'd prefer to use other tools which do not lock me into using Adobe products. Personally I wouldn't trust Adobe with my career or my clients data by using Flex, but if you feel it's a stable platform to target, that's fine - doesn't mean you should denigrate other tools as toys or only capable of creating social networking sites - that's patently bullshit and just undermines your position.
I love people who use the word serious to describe what they do ( and by implication consider other approaches non-serious and unworthy of attention). If you can get over your disdain for the rest of the world you might find there are good reasons to avoid locking your content in a binary shell. You can stay in your silverlight/flash binary ghetto if you want, but in the meantime lots of people are building the most popular websites on the web without flash using a huge variety of tools but delivering plain old HTML- those websites don't need flash, silverlight or any other plugins ( though typically they use it for trivial stuff like ads, if at all), and yet they serve most of the content on the web. I guess they aren't serious though.
I don't view flash any more, haven't for a few years.
The only content I miss is video on some websites like the BBC which refuse to serve their video as video files, and graphics like the ones you mention at nytimes.com say ( though actually not many sites produce infographics worthy of the name).
Having graphic content in HTML is going to be a lot better for everyone (more accessible, easier to mash up, easier to extract data), and when adobe completes migrating their tools to produce HTML, there really will be no excuses left. Its actually pretty easy to build interactive content right now with HTML, but when the wysiwyg tools switch, all the laggards will switch with them.
Actually as a designer I'd say that adobe doesn't really get designers any more - their tools feel like quark in the 90's - entering a long slow decline where the marking department add useless features every year like Export for Microsoft word or magic repair features that could never work, while ignoring glaring ui inconsistencies, awful installers, and crashing bugs, and then gouge design departments for as much money as they can manage. The latest versions of their cs suites have been a disappointment to me for this reason. It feels like all the people who care about the quality of the products have left Adobe and Macromedia has been dead for years.
So how can you say that a model has any real meaning?
By comparing its predicted results with the real world data, just like any other scientific model.
"Good artists copy; great artists steal."
That's really a quote from Picasso, mangled by Jobs.
Jobs was feeling vindictive about Google because of the history of having Schmidt in the Apple board-room from 2006-2009. He may have had some reason to feel betrayed if he knew nothing about the first Google phone until the iPhone was quite advanced, however his overreaction made Apple blind to the hypocrisy of their position. Just to cite one small example, they blatantly stole notification ideas from Google (notifications in iOS were pitiful and really annoying till iOS 5), and yet they're complaining about Android devices having a similar grid of icons etc. It really is laughable given the number of ideas iOS has borrowed from elsewhere.
Instead of whining about others copying them, they should just continue to produce the best phones in the industry, and let Android fight over the bottom of the market. I'd expect to see Tim Cook normalise relations with Samsung etc in due course, as frankly they don't have much of a case, and it's really embarrassing to see them squabbling with the people who supply much of their hardware. It'd be a good way to step out of the shadow of Jobs and show they are confident about the future.
Everything that you like about open source BSD-licensed projects is simply encoded for legal enforcement in the GPL
People are not idiots, and for some reason lots of them choose BSD/MIT/CCA over GPL. Apparently you believe that everyone thinks like you (or will when they see the light), and everyone wants to restrict users of their code in perpetuity to releasing the code under the exact same license.
Strangely enough, lots of developers don't think like you and really do want to release the source without restriction so they choose an attribution only license instead of GPL. They don't choose BSD because they have made a mistake, or they forgot to cover the restrictions in GPL, they choose it because it is less restrictive.
You can do anything with the GPL as long as you include sources. If you disagree with this, you don't have to contribute to it.
You can do anything with BSD even if you don't include sources, as long as you include attribution. Obviously both have different uses, and BSD is less restrictive. GPL may be clearly preferable to you, but let's not get into sophistry about GPL being 'clearly more free'.
You don't have to try to convert the rest of the world to using the one true license, in fact arguments like this slagging off other licenses are exactly what puts people off going near GPL code.
Because clearly what we need is _yet another_ way to develop web applications.
Well, why not?
Doesn't matter to the end users what language was used for the back-end, and some programmers will be more familiar or comfortable with Perl. Maybe you don't need this, and I personally have no intention of using it, but some people might find it interesting.
Look at smartphones, Windows Mobile phones were around way before the iPhone, but they were never popular in the mainstream because they didn't have the "cool factor".
This is a reassuring geek fantasy (goes along with the 'great marketing' fantasy I suppose), but completely untrue.
Smartphones were made popular by the iPhone (and to some extent the blackberry before it) because it was better - better to look at sure, but more importantly better in design, better to use, and actually incredibly useful for the users who tried it. WM was a buggy, mediocre, hack-handed mess - people tried it and quite rightly gave up on it and went back to a simpler phone; not because it wasn't cool but because it crashed all the time, *and* top people at MS have no taste so it looked and felt awkward to use.
So, yes, Apple are great at what they do, but to say that they would be where they are without the competition is ridiculous.
Completely agree with you there - some things Apple do are duds (notifications in early iOS are a good example, they were terrible modal distractions), and some things they do are just OK till they see someone doing something better and copy it. Siri was bought in so it was not even developed at Apple, but they do know how to integrate things like that well, and how to steal ideas from competitors and do them better (Notifications from Android for example). One thing they do better than all of their competition though is to actually design their products (as opposed to letting them organically grow), throw out old ideas that aren't working, and to refine ideas which other people have had till they work really smoothly.
None of that is really 'cool', it's hard work and a willingness to go their own way when it suits them and shamelessly steal ideas when they see a better product. There's a lot of work that goes in behind the scenes to make iOS a pleasure to use (not just programming work).
They do need competitors to keep them at their best, without question.
1. No Free E-mail
The government can seize a server from your home, your ISP or anywhere else they wish. This has nothing to do with email being free or not, but where the server is based, and whether your government has power (or influence) over the local law enforcement at that location.
First time I've seen Apple's website go down (as opposed to the store) - someone messed up when updating the store perhaps?
http://www.apple.com/
Access Denied
You don't have permission to access "http://www.apple.com/" on this server.
Reference #18.47efd4d9.1317755036.25f60c38
Anyone else seeing this?
The correct answer of course is to hire a van, not ask why your small compact cannot carry a sofa. Eink will never be suitable for browsing, so it's useless for most people except to read text-only books. If that is all you want to do great.
He probably means this:
http://www.huffingtonpost.com/2010/12/08/wikileaks-reveals-that-mi_n_793816.html
This information about what your taxes are spent on was brought to you by Bradley Manning and wikileaks.
Any replacement(s) will be shitty, too. It won't matter who creates them, or how they're implemented. They will be shitty. That's just the nature of any attempt to have the browser host remotely complex applications. The browser is merely a document viewer and navigator; it is not an operating system of some sort. It will always fail as an operating system or an application host.
This is a debate with a long and storied history going back to Andreessen, and probably beyond. Browsers have taken over much of the work done by native apps on many operating systems, and whether you like it or not, that's a trend which is accelerating, notwithstanding the recent trend for mobile binaries. There are a good reasons for the way the web has taken over our computing lives, and also good reasons why binary solutions like Flash are gradually being deprecated - they break one of the main advantages of the web, which is that it works everywhere - even on devices which haven't been invented yet. That is also why various companies have attempted to introduce binary solutions to web problems - in order to gain a stranglehold on the market again, as they can easily do with binary apps (all the solutions you list were attempts to do this, from applets, to ActiveX to Flash).
It's interesting that you focus on javascript as a roadblock and blunder, as javascript is not actually the language the vast majority of the code in web apps is written in - it's used as a simple way to add interactivity and animation to documents, and occasionally to allow requests for page fragments. I suppose it makes a good rant if you can focus on javascript which, if you know nothing about it, seems an easy punch-bag. It's actually quite an interesting language, though I wouldn't try to create something large in it. The javascript involved in creating a modern web application is typically pretty minimal, and often reliant on libraries like query which smooth out a lot of the inconsistencies between browsers, so javascript is not really the question when comparing flash to html development to native binaries. It's not the technology in which the vast majority of time is spent for web app development - on the contrary, it is strictly optional. The languages used for actual web development vary wildly from C variants, perl, PHP (ugh), ruby, python, smalltalk etc etc. You can use whichever language or framework you like when developing web apps, and the beauty of it is, your users won't care, whether they are viewing it on a mac desktop from 2005 or a Windows phone from 2011.
The end result is that the browser should not be used for anything more than displaying and linking documents.
The vast majority of the work many people do all day includes displaying, editing and linking documents - for that the web is a perfect fit - a far better fit than binary apps like MS Word. For something like photoshop editing huge image files, a binary is still the answer, but it does have downsides. The real question is what trade-offs does your app face, and do the advantages of a web app (faster deployment, cross-platform, document based, stateless, collaborative) outweigh the disadvantages compared to binaries (slower performance, non-local, network dependent, limited file access etc). That's not an equation which has the same answer for all apps or all people, but it's clearly one which has worked out in favour of web technology for huge numbers of apps.
When you hear the word "play", don't think World of Warcraft; think golf. Or consider the full word "playbook" in the context of football, but when you think of football think executive suite at an NFL stadium.
Wow, that argument is almost as convincing as the one about 'keeping RIM in the corporate conversation'. Why would a playbook be more suited to a golf course, than the phone the executive already have - is there some masterful golf app tailored to the golfing style of company executives available? Does it come with a free executive caddy? The name sums it up really - a supposedly corporate device named as if it were a toy.
The Playbook is a completely directionless product which arrived without an email app (from RIM and no email!!), has done nothing to attract developers, is overpriced compared to the competition, and will not properly integrate with the Android ecosystem despite throwing away any possibility of its own app ecosystem long-term by saying they will support android. It is dead on arrival, and RIM would have done better not to produce it, as it shows just how incompetent and out of touch they are. Relying on a phone just to do email is a good example of how out of touch they are. They've recently massively dropped the price to clear inventory, but it will end in ignominious defeat soon enough when they cancel it and retreat to the phone market.
The key to tablets is their use-case: web, email, content consumption and apps. On none of those except perhaps web browser is the RIM tablet even remotely convincing out of the box.
There are rumours they have already cancelled production, which they should have done before it launched:
http://www.reuters.com/article/2011/09/29/rim-playbook-idUSS1E78S0TA20110929