The premise of the article, that Apple killed HC because they didn't want users to create content, only consume it, is absurd. Among other things, Apple gives away their entire (extremely good) development toolchain, docs, etc., because they want to make it as easy as possible for people to develop software.
The reason that HyperCard died is that while everyone loved it, nobody could make a business case for it. That is, while people will pay for word processors, spreadsheets, databases, etc., nobody was willing to pay for HyperCard. So when HC was moved out of Apple (where it was a free part of the OS, subsidized by hardware sales) to Claris (where it had to generate revenue) it became doomed. Because while HC was a great tool for non-technical users to build apps, it couldn't compete as a commercial tool for building apps, because professionals were better off using Director, etc., which were much harder to use but which gave them more control.
The later thing that kept it from making a comeback (when Claris basically got rolled back into Apple) is that Apple realized that the web would replace HyperCard, in that all of the nifty things that people used to do in HyperCard stacks were now being done as web apps, and it didn't make sense to try to fight that battle. So instead Apple focused in ObjC/IB for native apps, and scripting, doing things like allowing you to make apps using IB and AppleScript, which in theory is similar to HyperCard (though in reality nowhere near as non-engineer friendly).
It's a shame, since there's no way to build web apps that's accessible to non-technical users the way HyperCard was. The closest tool now is Excel, which is still where the vast majority of non-technical "app building" takes place. And Excel is a much less creative tool than HC.
Personally, I would love to have seen Apple open source HyperCard, and keep bundling it on every Mac, because that would have allowed the creativity to continue without the cost structure. And I'd love to see a HC runtime on every iPad.
"if you have time to work on automation, its probably because you don't need it... those who really need automation don't have the time to implement it."
This is only the case if resources are absolutely fixed, the you can't prioritize your work. And in my experience, situations are never that doomed - they just feel doomed when you're in them, and you don't get "out of the box" to change the situation. If automation really saves more work than implementing it, you can find a way to defer the manual work long enough to automate it, or bring in a contractor to do the manual work (or the automation), justified by the time saved once it's automated.
It's the same short-sighted logic that junior people make, where they're "too busy to interview/hire/train" so they never add capacity to improve their situation, so they have in effect created a trap, walked in, then complained about being trapped.
The answer is to be smart, and to invest a little time automating because that's a much more efficient way to work than doing everything manually.
As an example, at my last startup we built and deployed everything as debian packages, generated straight from the build boxes, so we could do a software build, automated regression test, and deploy of a complex distributed system to hundreds of servers, by one person in an hour. Sure, it took some time to get all of that completely automated, but we had no alternative - as a startup, we couldn't afford NOT to automate, because the work required to do every software build, QA, and release manually, forever, was vastly more than the one-time cost of scripting builds, regression testing, and deployment.
The trick, in my experience, is to hire very smart, lazy, cranky sysadmins. The kind that get pissed off the second time they do something manually, then script it so they can get their work done more easily.
"For the sake of efficiency, drive API's will lie about data having been being persisted."
No. The ability to control write-through cache has been quite explicit for decades. If applications need performance most, which is the case 99% of the time, they use a normal write, which is written to the drive's controller buffer and considered "written" even though it's actually written to disk later. Applications that need to ensure that data is written to disk (e.g. databases) explicitly force the write not to be confirmed until the data is safely on disk. This can be explicitly controlled by the application, the RAID controller, the drive's controller, etc., so that systems can be tuned (by the owner and/or OS vendor) for the tradeoff between performance and data integrity.
If a drive manufacturer's drives violated the API spec and claimed that data was written to disk while it was still just in the buffer, without being configurable to disable this for critical applications, nobody would ever buy the drives.
So how do hybrid drives decide what's stored in the SSD vs the disk? From working in the hard drive business, I can think of several ways to tackle this - which is it?
1. Drive observes usage patterns and stores data on SSD vs disk based on that. This would be cool since it's transparent to the OS, etc., so it can work by "magic" (e.g. like bad block remapping), but it feels like it might be less effective than the other strategies depending on how good a job it does guessing how data is used. Also, there are some cases that are 'rare' (such as boot time) but which are important to optimize, even if statistically it wouldn't appear so.
2. Driver/OS controls what's stored where. This could be great, since they can have much more knowledge of what's going on than the drive.
3. SSD and disk are distinct 'drives'. This would allow the user to optimize (e.g. put boot OS and swap on SSD, big files on disk, etc.). But it requires users to understand and manage tradeoffs explicitly, which most people probably don't want to deal with.
I'll second that about the lack of marketing. I'm a HUGE Lego fan (I have my VIP card, went to Lego Florida on opening day, bought the T-Shirt, etc.) and I only saw Lego Universe promoted once - at CES a year before it launched! And then the next time I saw it, it was a random, abandoned-looking box in a Game Stop's PC software section. No posters, no online marketing (other than it being discussed on fan sites), nothing. And if they can't sell ME a copy of Lego Universe, a lego-loving geek with disposable income, they can't sell it to anyone.
I pretty much use Mac (client) and Linux (server) for everything.
But I still use Windows because there are some specific, very useful apps, that are Windows native, so I run them on a PC or on Parallels. Yes, there are web-based alternatives, but, to be honest, they suck to use - the web app UIs are clunky and slow compared to a native app. In the long run, I hope that web based alternatives surpass the native Windows apps, but right now it's more important that I be able to work efficiently than be cross-platform. Parallels is cheap and works fine, so I can run Windows apps on my Mac and they nearly feel like native apps.
Of course, the problem wasn't the battery, but a software bug that causes the phone to draw more power than it absolutely needed to. So the fix is a software update (already released to developers), not a replacement battery.
The point of 3D printers, of course, is that they can make unique items. It'd be fun to algorithmically generate unique shells to see what the hermit crabs like.
The thing that people here seem to be forgetting is that this is just a weird art project, like all of the "contests" that Makerbot runs. They're not seriously trying to save hermit crabs, any more than they were trying to get people to wear plastic printed bow-ties, or collect things based on a model of Stephen Colbert, or any of their other contests. They're just trying to come up with fun things for people with 3D printers to do.
There are models that include human activity as inputs and models that ignore human activity. The former are much more accurate predictors of the actual climate.
If you think that the models are "highly simplified" then you haven't seen any of the models. That is, unles you think that models with hundreds of variables and millions of data points are simple.
When new data comes out, it's only right to adapt the models to take that data into account. Remember, in science you start with observed facts and you try to work out how things work. It's not science when you decide on how things work first and ignore new facts.
The models predict global climate destabilization, so while the overall temperature goes up, the destabilized weather patterns lead to more extreme storms and snows as well as droughts and record high temperatures. Some people simplied this complex interaction into "global warming", which is in a simple sense what is going on, but in reality the models were ALWAYS more complex than that simple phrase.
If anything, the changes in the models have been that the changes are coming faster and are more extreme than the early predictions.
You've got cause and effect backwards. Gore has been trying to get people to do something about global climate change for decades, at the start of which nobody cared about the issue and it probably hurt him politically to keep pushing it, and has invested his personal money in companies that are working to do what he advocates.
If you think that people trying to do something about the global climate change are using deception, tricking people, etc., please provide some examples that are supported by evidence. "We don't like it" and "we don't want to pay for it" aren't arguments of fact.:-)
Of course there are "anthropogenic climate change models" - I suspect that you don't know what is meant by a climate change model. So a little Climate Science 101:
The models take data other than the measured temperature data, such as forestation, solar activity, human population, etc., and the OUTPUT of the model is predicted temeratures. They then compare those predictions to the observed temperatures to validate the model.
The models that include human activity as an input ("anthropogenic models") predict the actual observed temperatures much better than models that ignore human activity. Thus, human activity is strongly believed (98% of climate scientists) to be a cause of global climate change.
And even if you ignore the science, and believe that humans aren't CAUSING global climate change, we still want to stop the change that is taking place (i.e. we don't want to flood coastal cities, etc.). There's no doubt that it is going on, and that human behavior can affect what is going on. So even if the global warming were caused entirely by sun spots, we would still want to reduce our carbon emissions in order to cool the planet off.
Or are you saying that because you think that we're not causing it, we should do nothing? That doesn't seem like a good long term plan. Do you have kids, or friends?
So you're saying that climate scientists have a strong financial incentive for there to be controversy on the subject, but that against their self-interest they (98%) keep concluding that global climate change is taking place and is caused by human activity? That's a pretty strong argument in favor of global climate change actually taking place.
On the other side, climate change deniers have a strong financial incentive for it not to be taking place, as they are all funded by companies that would be "hurt" if we started trying to do anything about global climate change. That's a pretty strong indicator that their arguments being financially motivated (i.e. not related to the truth).
QNX and Linux are _really_ different. QNX is a realtime OS for embedded applications, since as controlling car engines and factory equipment. This means that performance is extremely reliable (realtime OSs guarantee no glitching/slowdowns), it never crashes, and it runs efficiently on very limited hardware, on pretty much any CPU. For example, QNX is the OS running 200+ models of cars, in 20m+ cars on the road. It's proprietary and expensive, but for some applications you don't care about that as much as you care about those other adjectives. In the mobile market, this means that QNX should allow RIM to produce devices that are more reliable and have better performance, while running on cheaper/smaller hardware and getting a longer battery life. All of the other options are running stripped down desktop OSs, which are much larger and resource intensive than QNX. Of course, if RIM piles a bunch of bad software on top of QNX it'll still suck.:-) But that wouldn't be the fault of QNX.
To elaborate, people tend to own only one phone, so in terms of app sales each phone's market is a separate market, which you would independently decide whether to sell into. That is, you're not choosing either to sell into Apple or RIMs market, you're choosing each one independently. If you can sell enough to be profitable as an iOS app, you will do that, and (assuming you have the resources) if you can sell enough to be profitable as a RIM app, you will do that. And so on for each mobile OS. The equation of whether you can sell enough to be profitable is complex, involving the total installed base, the buying behavior, the market share that you think you can get, and the distribution costs. So, for example, Apple's 30% margin means that you'd have to sell more. Or (to make up a hypothetical) if RIM is harder to develop for that'll raise development costs, meaning that you have to sell more to be profitable. And WebOS' market is tiny, so nothing could justify investing effort (except as a hobby). The extreme case is BREW, which was at one point the mobile platform with the largest installed base, but the development tools and licensing terms were so amazingly bad that there were almost no BREW apps.
I agree that what developers (companies, not always individuals) care most about is being able to make a profit on their investment. And on that front iOS wins, because they provide the best app store, and have trained millions of users to pay for software.
This is as distinct from the Android store, which is not as good, and which sells far less software per person.
But a close second (first for many individuals) is how easy it is to write software for the platform. As an extreme example, iOS is very easy to write good software for, because the APIs are rich and consistent. So even when the platform was new and the market was tiny, developers liked writing for the iPhone because it was fun and easy. This is not true of anything RIM has produced.
Though I have some hope. QNX used to be a great little OS, and perhaps it's still cool and fun, as well as stable and efficient. Even if it's in a RIM product.
If they tracked a stolen laptop to your IP address, I would guess that it's in a neighbor's house and connecting to your WiFi. Rather than sending everyone away, you might want to suggest to them to try the neighbors.
Re:What he took away is more precious than given
on
Steve Jobs Dead At 56
·
· Score: 1
While I'm all for freedom, I think that we have to admit that Apple achieved a balance between control and openness that in part explains why they're succeeding while everyone else isn't. While you may see Apple as being the most controlling company, because you're only comparing it to desktops. But in the mobile and consumer electronics space space the large majority of devices are MUCH more locked down than the iPhone. Apple's app approval process is highly developer friendly when compared with any video game console or "feature" phone, RIM, etc. Certainly Apple is more locked down than Android, but in return they provide a much more consistent user experience. But if you ever went through BREW certification, or shipped a game on Playstation/Nintendo/Xbox, you would never again complain about Apple's app store approval process. For comparison, to ship a video game on any console, you have to pay the Sony/MS/Nintendo $12/unit to manufacture the packaged game, up front, for the entire run. So if a game sells for $40, $16 or so goes to the retailer, $12 goes to the console owner, and you get the rest ($12, which has to pay for development, marketing, etc.). And there are games which, after $millions spent on development, aren't allowed to ship, or which have to be majorly redesigned because Sony/Nintendo/MS have final approval over everything. It sucks from the developer's perspective, but arguably it's smart of the platform owners to exert those controls, because it's in their interest for their platform to have only extremely high quality games - they're all terrified of what happened to the NES when Nintendo lost control over game distribution, and the platform was crushed under a flood of "shovel-ware" that scared off consumers. Keep in mind that the platform company fronts the $billions to develop and launch the platform, and they have to make it all back (and more) on licensing and distribution fees. Failing to do so kills companies (e.g. Sega, Atari). But as much as the closed platform sucks from a technical perspective, it's arguably good for game companies in business terms, in that they know that the investment required forms a barrier to entry, limiting competition and thus maximizing sales for the games that do ship for the platform.
Good point. But while I think that Woz is a brilliant engineer (his Apple ][ floppy disk controller made personal computers feasible), there are great engineers at all sorts of companies, and very few companies that can have a clear, unified vision and execute on it. So as much as I admire Woz, it was Jobs that had the vision and the drive to take Woz' technical brilliance, Ives' industrial design, etc., and drive them to produce brilliant products.
The methodology he used (asking people to volunteer to take the survey) means that, as he quite rightly says, the results aren't statistically valid. So they certainly don't prove anything. In particular, broadcasting a survey and asking people to take it doesn't ensure that the people that take the survey are representative of the developer population - they could (for example) be more likely to be non-commercial developers, because the commercial developers might not be allowed by their employers to share informatiom like this. And so on.
That being said, it's not all all surprising that a tiny percentage of 'hits' would be responsible for the mzjority of the revenue, as that's true in many businesses. For example, in music the top 2% of music makes enough money to pay for the other 98% that loses money. Book publishers similarly lose money on most books, paid for by the 'hits'. Pharmaceutical companies lose money on almost all of their research, but the 'hits' pay for everything. VC's lose money on the large majority of their startups, and the 'wins' pay for everything. Most videogames lose money, paid for by the big hits. I think that it's a natural dynamic in any creative field where you're creating something new, rather than a commoditized business - you are taking a risk, and most of the time it doesn't pay off, but when it does it's huge, making the risk worthwhile. And in all of those markets it's something like 1-2% of hits that generate all of the real money.
There's also a dynamic in the market that once something 'breaks out' it accellerates. For example, when an album 'breaks out' by hitting a certain success level that gets it attention, it starts getting more promotion, it shows up in best seller lists, etc., giving it wider exposure and thus more sales. And in the iTunes store, when something starts doing well it gets better placement, reviewers write about it, etc., all of which drive up sales.
So between the two, you end up with a huge pool of new games/songs/... trying to make it, and the occasional breakout that moves up to the top tier and becomes a hit. It makes it all exciting!
In July of 1798, Congress passed – and President John Adams signed - “An Act for the Relief of Sick and Disabled Seamen.” The law authorized the creation of a government operated marine hospital service and mandated that privately employed sailors be required to purchase health care insurance.
Keep in mind that the 5th Congress did not really need to struggle over the intentions of the drafters of the Constitutions in creating this Act as many of its members were the drafters of the Constitution.
And when the Bill came to the desk of President John Adams for signature, I think it’s safe to assume that the man in that chair had a pretty good grasp on what the framers had in mind.
So much for the claim that “The Constitution nowhere authorizes the United States to mandate, either directly or under threat of penalty.”
As for Congress’ understanding of the limits of the Constitution at the time the Act was passed, it is worth noting that Thomas Jefferson was the President of the Senate during the 5th Congress while Jonathan Dayton, the youngest man to sign the United States Constitution, was the Speaker of the House.
Keep it in perspective - 80% of software written is not written to be sold as a product, but as a tool to be used. Open source software is hard to sell (though it's been done), but it's fantastic for the large majority of software developers, who work for companies that aren't in the software business but who need software to solve their problems. There's much more money using open source software to solve problems (i.e. as a systems integrator or developer who uses open source components) than in trying to sell the open source software. So while it's fantastic that Red Hat is doing well, they're tiny compared to IBM professional services (for example), who use tons of open source components.
There are plenty of good reasons to hire outside contractors, even though they almost always cost more per hour than employees.
1) You can satisfy temporary "bumps" in demand without hiring and then firing people. It's routine to need a lot of dev capacity while building, then scale down when the system is complete so you're doing maintenance and enhancements rather than heavy lifting.
2) You can save a lot of time, because you can get an entire team of developers via contract in a matter of weeks, while the process of approving hires, recruiting, hiring, etc., to build an entire team can take months.
3) You can get access to specialized skills that you may not need ongoing,
4) You can get access to people that aren't willing to work for the published government pay scales. Govnment salaries are fixed by regulations, so you can't negotiate salary. The result is that people who are highly skilled can make 2x as much in private industry than the government is legally allowed to pay. So to get access to the best dev's, you pretty much have to hire them as consultants. Especially since government salaries have been frozen for decades (falling badly behind private industry), benefits are getting cut, and job security isn't what it used to be. So if you're good, you don't end up working as a government employee unless the government is REALLY lucky.
I love the idea of this. I have to wonder, though - does sending a POST message to a web server have any legal meaning? It'll just end up in some web server log, ignored by the app and never notified to a person, so I'd think it wouldn't be a very strong argument. Now, if your app could figure out where to email a modified TOS, that would be much stronger, but of course that's a lot more work.
Realistically, though, no consumer web site can afford to negotiate individual contracts for individual users, so the best you can really achieve would be to get them to change their standard TOS to have better terms. To that end, I would suggest that you could extend this widget so that it not only nofied the site owner, but also collected a database of TOS objections. Imagine if you could say "10,000 people objected to site X's standard TOS, and 75% of the objections were to paragraph Y." That might pressure companies to change their TOS.
I'd be happy to build and host the server side, if you'd like. I don't know much about client side JavaScript, but servers are easy.:-)
Keep in mind that ISPs cannot identify which computer did anything, just what external IP address did. Since pretty much everyone on broadband runs NAT and WiFi, anyone in or near the house can be behind your IP address. Is the person who pays for a broadband connection responsible for the actions of (for example) a neighbor who freeloads on their WiFi? (Keeping in mind that wireless security is far from perfect, and your neighbor has plenty of time to crack your security).
Slashdot Mirror
The premise of the article, that Apple killed HC because they didn't want users to create content, only consume it, is absurd. Among other things, Apple gives away their entire (extremely good) development toolchain, docs, etc., because they want to make it as easy as possible for people to develop software.
The reason that HyperCard died is that while everyone loved it, nobody could make a business case for it. That is, while people will pay for word processors, spreadsheets, databases, etc., nobody was willing to pay for HyperCard. So when HC was moved out of Apple (where it was a free part of the OS, subsidized by hardware sales) to Claris (where it had to generate revenue) it became doomed. Because while HC was a great tool for non-technical users to build apps, it couldn't compete as a commercial tool for building apps, because professionals were better off using Director, etc., which were much harder to use but which gave them more control.
The later thing that kept it from making a comeback (when Claris basically got rolled back into Apple) is that Apple realized that the web would replace HyperCard, in that all of the nifty things that people used to do in HyperCard stacks were now being done as web apps, and it didn't make sense to try to fight that battle. So instead Apple focused in ObjC/IB for native apps, and scripting, doing things like allowing you to make apps using IB and AppleScript, which in theory is similar to HyperCard (though in reality nowhere near as non-engineer friendly).
It's a shame, since there's no way to build web apps that's accessible to non-technical users the way HyperCard was. The closest tool now is Excel, which is still where the vast majority of non-technical "app building" takes place. And Excel is a much less creative tool than HC.
Personally, I would love to have seen Apple open source HyperCard, and keep bundling it on every Mac, because that would have allowed the creativity to continue without the cost structure. And I'd love to see a HC runtime on every iPad.
It's too late for that, sadly.
"if you have time to work on automation, its probably because you don't need it ... those who really need automation don't have the time to implement it."
This is only the case if resources are absolutely fixed, the you can't prioritize your work. And in my experience, situations are never that doomed - they just feel doomed when you're in them, and you don't get "out of the box" to change the situation. If automation really saves more work than implementing it, you can find a way to defer the manual work long enough to automate it, or bring in a contractor to do the manual work (or the automation), justified by the time saved once it's automated.
It's the same short-sighted logic that junior people make, where they're "too busy to interview/hire/train" so they never add capacity to improve their situation, so they have in effect created a trap, walked in, then complained about being trapped.
The answer is to be smart, and to invest a little time automating because that's a much more efficient way to work than doing everything manually.
As an example, at my last startup we built and deployed everything as debian packages, generated straight from the build boxes, so we could do a software build, automated regression test, and deploy of a complex distributed system to hundreds of servers, by one person in an hour. Sure, it took some time to get all of that completely automated, but we had no alternative - as a startup, we couldn't afford NOT to automate, because the work required to do every software build, QA, and release manually, forever, was vastly more than the one-time cost of scripting builds, regression testing, and deployment.
The trick, in my experience, is to hire very smart, lazy, cranky sysadmins. The kind that get pissed off the second time they do something manually, then script it so they can get their work done more easily.
"For the sake of efficiency, drive API's will lie about data having been being persisted."
No. The ability to control write-through cache has been quite explicit for decades. If applications need performance most, which is the case 99% of the time, they use a normal write, which is written to the drive's controller buffer and considered "written" even though it's actually written to disk later. Applications that need to ensure that data is written to disk (e.g. databases) explicitly force the write not to be confirmed until the data is safely on disk. This can be explicitly controlled by the application, the RAID controller, the drive's controller, etc., so that systems can be tuned (by the owner and/or OS vendor) for the tradeoff between performance and data integrity.
If a drive manufacturer's drives violated the API spec and claimed that data was written to disk while it was still just in the buffer, without being configurable to disable this for critical applications, nobody would ever buy the drives.
So how do hybrid drives decide what's stored in the SSD vs the disk? From working in the hard drive business, I can think of several ways to tackle this - which is it?
1. Drive observes usage patterns and stores data on SSD vs disk based on that. This would be cool since it's transparent to the OS, etc., so it can work by "magic" (e.g. like bad block remapping), but it feels like it might be less effective than the other strategies depending on how good a job it does guessing how data is used. Also, there are some cases that are 'rare' (such as boot time) but which are important to optimize, even if statistically it wouldn't appear so.
2. Driver/OS controls what's stored where. This could be great, since they can have much more knowledge of what's going on than the drive.
3. SSD and disk are distinct 'drives'. This would allow the user to optimize (e.g. put boot OS and swap on SSD, big files on disk, etc.). But it requires users to understand and manage tradeoffs explicitly, which most people probably don't want to deal with.
So which is it? Does anyone know?
I'll second that about the lack of marketing. I'm a HUGE Lego fan (I have my VIP card, went to Lego Florida on opening day, bought the T-Shirt, etc.) and I only saw Lego Universe promoted once - at CES a year before it launched! And then the next time I saw it, it was a random, abandoned-looking box in a Game Stop's PC software section. No posters, no online marketing (other than it being discussed on fan sites), nothing. And if they can't sell ME a copy of Lego Universe, a lego-loving geek with disposable income, they can't sell it to anyone.
I pretty much use Mac (client) and Linux (server) for everything.
But I still use Windows because there are some specific, very useful apps, that are Windows native, so I run them on a PC or on Parallels. Yes, there are web-based alternatives, but, to be honest, they suck to use - the web app UIs are clunky and slow compared to a native app. In the long run, I hope that web based alternatives surpass the native Windows apps, but right now it's more important that I be able to work efficiently than be cross-platform. Parallels is cheap and works fine, so I can run Windows apps on my Mac and they nearly feel like native apps.
Of course, the problem wasn't the battery, but a software bug that causes the phone to draw more power than it absolutely needed to. So the fix is a software update (already released to developers), not a replacement battery.
The point of 3D printers, of course, is that they can make unique items. It'd be fun to algorithmically generate unique shells to see what the hermit crabs like.
The thing that people here seem to be forgetting is that this is just a weird art project, like all of the "contests" that Makerbot runs. They're not seriously trying to save hermit crabs, any more than they were trying to get people to wear plastic printed bow-ties, or collect things based on a model of Stephen Colbert, or any of their other contests. They're just trying to come up with fun things for people with 3D printers to do.
There are models that include human activity as inputs and models that ignore human activity. The former are much more accurate predictors of the actual climate.
If you think that the models are "highly simplified" then you haven't seen any of the models. That is, unles you think that models with hundreds of variables and millions of data points are simple.
When new data comes out, it's only right to adapt the models to take that data into account. Remember, in science you start with observed facts and you try to work out how things work. It's not science when you decide on how things work first and ignore new facts.
The models predict global climate destabilization, so while the overall temperature goes up, the destabilized weather patterns lead to more extreme storms and snows as well as droughts and record high temperatures. Some people simplied this complex interaction into "global warming", which is in a simple sense what is going on, but in reality the models were ALWAYS more complex than that simple phrase.
If anything, the changes in the models have been that the changes are coming faster and are more extreme than the early predictions.
You've got cause and effect backwards. Gore has been trying to get people to do something about global climate change for decades, at the start of which nobody cared about the issue and it probably hurt him politically to keep pushing it, and has invested his personal money in companies that are working to do what he advocates.
If you think that people trying to do something about the global climate change are using deception, tricking people, etc., please provide some examples that are supported by evidence. "We don't like it" and "we don't want to pay for it" aren't arguments of fact. :-)
Of course there are "anthropogenic climate change models" - I suspect that you don't know what is meant by a climate change model. So a little Climate Science 101:
The models take data other than the measured temperature data, such as forestation, solar activity, human population, etc., and the OUTPUT of the model is predicted temeratures. They then compare those predictions to the observed temperatures to validate the model.
The models that include human activity as an input ("anthropogenic models") predict the actual observed temperatures much better than models that ignore human activity. Thus, human activity is strongly believed (98% of climate scientists) to be a cause of global climate change.
And even if you ignore the science, and believe that humans aren't CAUSING global climate change, we still want to stop the change that is taking place (i.e. we don't want to flood coastal cities, etc.). There's no doubt that it is going on, and that human behavior can affect what is going on. So even if the global warming were caused entirely by sun spots, we would still want to reduce our carbon emissions in order to cool the planet off.
Or are you saying that because you think that we're not causing it, we should do nothing? That doesn't seem like a good long term plan. Do you have kids, or friends?
So you're saying that climate scientists have a strong financial incentive for there to be controversy on the subject, but that against their self-interest they (98%) keep concluding that global climate change is taking place and is caused by human activity? That's a pretty strong argument in favor of global climate change actually taking place.
On the other side, climate change deniers have a strong financial incentive for it not to be taking place, as they are all funded by companies that would be "hurt" if we started trying to do anything about global climate change. That's a pretty strong indicator that their arguments being financially motivated (i.e. not related to the truth).
QNX and Linux are _really_ different. QNX is a realtime OS for embedded applications, since as controlling car engines and factory equipment. This means that performance is extremely reliable (realtime OSs guarantee no glitching/slowdowns), it never crashes, and it runs efficiently on very limited hardware, on pretty much any CPU. For example, QNX is the OS running 200+ models of cars, in 20m+ cars on the road. It's proprietary and expensive, but for some applications you don't care about that as much as you care about those other adjectives. In the mobile market, this means that QNX should allow RIM to produce devices that are more reliable and have better performance, while running on cheaper/smaller hardware and getting a longer battery life. All of the other options are running stripped down desktop OSs, which are much larger and resource intensive than QNX. Of course, if RIM piles a bunch of bad software on top of QNX it'll still suck. :-) But that wouldn't be the fault of QNX.
Good point.
To elaborate, people tend to own only one phone, so in terms of app sales each phone's market is a separate market, which you would independently decide whether to sell into. That is, you're not choosing either to sell into Apple or RIMs market, you're choosing each one independently. If you can sell enough to be profitable as an iOS app, you will do that, and (assuming you have the resources) if you can sell enough to be profitable as a RIM app, you will do that. And so on for each mobile OS. The equation of whether you can sell enough to be profitable is complex, involving the total installed base, the buying behavior, the market share that you think you can get, and the distribution costs. So, for example, Apple's 30% margin means that you'd have to sell more. Or (to make up a hypothetical) if RIM is harder to develop for that'll raise development costs, meaning that you have to sell more to be profitable. And WebOS' market is tiny, so nothing could justify investing effort (except as a hobby). The extreme case is BREW, which was at one point the mobile platform with the largest installed base, but the development tools and licensing terms were so amazingly bad that there were almost no BREW apps.
I agree that what developers (companies, not always individuals) care most about is being able to make a profit on their investment. And on that front iOS wins, because they provide the best app store, and have trained millions of users to pay for software.
This is as distinct from the Android store, which is not as good, and which sells far less software per person.
But a close second (first for many individuals) is how easy it is to write software for the platform. As an extreme example, iOS is very easy to write good software for, because the APIs are rich and consistent. So even when the platform was new and the market was tiny, developers liked writing for the iPhone because it was fun and easy. This is not true of anything RIM has produced.
Though I have some hope. QNX used to be a great little OS, and perhaps it's still cool and fun, as well as stable and efficient. Even if it's in a RIM product.
If they tracked a stolen laptop to your IP address, I would guess that it's in a neighbor's house and connecting to your WiFi. Rather than sending everyone away, you might want to suggest to them to try the neighbors.
While I'm all for freedom, I think that we have to admit that Apple achieved a balance between control and openness that in part explains why they're succeeding while everyone else isn't. While you may see Apple as being the most controlling company, because you're only comparing it to desktops. But in the mobile and consumer electronics space space the large majority of devices are MUCH more locked down than the iPhone. Apple's app approval process is highly developer friendly when compared with any video game console or "feature" phone, RIM, etc. Certainly Apple is more locked down than Android, but in return they provide a much more consistent user experience. But if you ever went through BREW certification, or shipped a game on Playstation/Nintendo/Xbox, you would never again complain about Apple's app store approval process. For comparison, to ship a video game on any console, you have to pay the Sony/MS/Nintendo $12/unit to manufacture the packaged game, up front, for the entire run. So if a game sells for $40, $16 or so goes to the retailer, $12 goes to the console owner, and you get the rest ($12, which has to pay for development, marketing, etc.). And there are games which, after $millions spent on development, aren't allowed to ship, or which have to be majorly redesigned because Sony/Nintendo/MS have final approval over everything. It sucks from the developer's perspective, but arguably it's smart of the platform owners to exert those controls, because it's in their interest for their platform to have only extremely high quality games - they're all terrified of what happened to the NES when Nintendo lost control over game distribution, and the platform was crushed under a flood of "shovel-ware" that scared off consumers. Keep in mind that the platform company fronts the $billions to develop and launch the platform, and they have to make it all back (and more) on licensing and distribution fees. Failing to do so kills companies (e.g. Sega, Atari). But as much as the closed platform sucks from a technical perspective, it's arguably good for game companies in business terms, in that they know that the investment required forms a barrier to entry, limiting competition and thus maximizing sales for the games that do ship for the platform.
Very different from the desktop market.
Good point. But while I think that Woz is a brilliant engineer (his Apple ][ floppy disk controller made personal computers feasible), there are great engineers at all sorts of companies, and very few companies that can have a clear, unified vision and execute on it. So as much as I admire Woz, it was Jobs that had the vision and the drive to take Woz' technical brilliance, Ives' industrial design, etc., and drive them to produce brilliant products.
The methodology he used (asking people to volunteer to take the survey) means that, as he quite rightly says, the results aren't statistically valid. So they certainly don't prove anything. In particular, broadcasting a survey and asking people to take it doesn't ensure that the people that take the survey are representative of the developer population - they could (for example) be more likely to be non-commercial developers, because the commercial developers might not be allowed by their employers to share informatiom like this. And so on.
That being said, it's not all all surprising that a tiny percentage of 'hits' would be responsible for the mzjority of the revenue, as that's true in many businesses. For example, in music the top 2% of music makes enough money to pay for the other 98% that loses money. Book publishers similarly lose money on most books, paid for by the 'hits'. Pharmaceutical companies lose money on almost all of their research, but the 'hits' pay for everything. VC's lose money on the large majority of their startups, and the 'wins' pay for everything. Most videogames lose money, paid for by the big hits. I think that it's a natural dynamic in any creative field where you're creating something new, rather than a commoditized business - you are taking a risk, and most of the time it doesn't pay off, but when it does it's huge, making the risk worthwhile. And in all of those markets it's something like 1-2% of hits that generate all of the real money.
There's also a dynamic in the market that once something 'breaks out' it accellerates. For example, when an album 'breaks out' by hitting a certain success level that gets it attention, it starts getting more promotion, it shows up in best seller lists, etc., giving it wider exposure and thus more sales. And in the iTunes store, when something starts doing well it gets better placement, reviewers write about it, etc., all of which drive up sales.
So between the two, you end up with a huge pool of new games/songs/... trying to make it, and the occasional breakout that moves up to the top tier and becomes a hit. It makes it all exciting!
In July of 1798, Congress passed – and President John Adams signed - “An Act for the Relief of Sick and Disabled Seamen.” The law authorized the creation of a government operated marine hospital service and mandated that privately employed sailors be required to purchase health care insurance.
http://www.scribd.com/doc/29099806/Act-for-the-Relief-of-Sick-DisabledSeamen-July-1798
Keep in mind that the 5th Congress did not really need to struggle over the intentions of the drafters of the Constitutions in creating this Act as many of its members were the drafters of the Constitution.
And when the Bill came to the desk of President John Adams for signature, I think it’s safe to assume that the man in that chair had a pretty good grasp on what the framers had in mind.
So much for the claim that “The Constitution nowhere authorizes the United States to mandate, either directly or under threat of penalty.”
As for Congress’ understanding of the limits of the Constitution at the time the Act was passed, it is worth noting that Thomas Jefferson was the President of the Senate during the 5th Congress while Jonathan Dayton, the youngest man to sign the United States Constitution, was the Speaker of the House.
http://bakka111.wordpress.com/2011/02/01/the-individual-mandate/
Though perhaps modern day Republicans know the founders' intentions better than John Adams?
Keep it in perspective - 80% of software written is not written to be sold as a product, but as a tool to be used. Open source software is hard to sell (though it's been done), but it's fantastic for the large majority of software developers, who work for companies that aren't in the software business but who need software to solve their problems. There's much more money using open source software to solve problems (i.e. as a systems integrator or developer who uses open source components) than in trying to sell the open source software. So while it's fantastic that Red Hat is doing well, they're tiny compared to IBM professional services (for example), who use tons of open source components.
There are plenty of good reasons to hire outside contractors, even though they almost always cost more per hour than employees.
1) You can satisfy temporary "bumps" in demand without hiring and then firing people. It's routine to need a lot of dev capacity while building, then scale down when the system is complete so you're doing maintenance and enhancements rather than heavy lifting.
2) You can save a lot of time, because you can get an entire team of developers via contract in a matter of weeks, while the process of approving hires, recruiting, hiring, etc., to build an entire team can take months.
3) You can get access to specialized skills that you may not need ongoing,
4) You can get access to people that aren't willing to work for the published government pay scales. Govnment salaries are fixed by regulations, so you can't negotiate salary. The result is that people who are highly skilled can make 2x as much in private industry than the government is legally allowed to pay. So to get access to the best dev's, you pretty much have to hire them as consultants. Especially since government salaries have been frozen for decades (falling badly behind private industry), benefits are getting cut, and job security isn't what it used to be. So if you're good, you don't end up working as a government employee unless the government is REALLY lucky.
I love the idea of this. I have to wonder, though - does sending a POST message to a web server have any legal meaning? It'll just end up in some web server log, ignored by the app and never notified to a person, so I'd think it wouldn't be a very strong argument. Now, if your app could figure out where to email a modified TOS, that would be much stronger, but of course that's a lot more work.
Realistically, though, no consumer web site can afford to negotiate individual contracts for individual users, so the best you can really achieve would be to get them to change their standard TOS to have better terms. To that end, I would suggest that you could extend this widget so that it not only nofied the site owner, but also collected a database of TOS objections. Imagine if you could say "10,000 people objected to site X's standard TOS, and 75% of the objections were to paragraph Y." That might pressure companies to change their TOS.
I'd be happy to build and host the server side, if you'd like. I don't know much about client side JavaScript, but servers are easy. :-)
Keep in mind that ISPs cannot identify which computer did anything, just what external IP address did. Since pretty much everyone on broadband runs NAT and WiFi, anyone in or near the house can be behind your IP address. Is the person who pays for a broadband connection responsible for the actions of (for example) a neighbor who freeloads on their WiFi? (Keeping in mind that wireless security is far from perfect, and your neighbor has plenty of time to crack your security).