Yes, and I just don't believe them. It's super-bad press for them a week before they release their new device.
The core problem is that in order to improve iCloud use they have actively encouraged users during the signup process to enable iCloud syncing - and default settings push all of your photos, docs and data. For a time-pressed celeb who may not be that tech savvy this is just asking for trouble.
I'm a bit surprised by the number of people who send around naked photos of themselves though. I must be in the prurient minority.
Yep I totally agree! I watched it at the with my son on the big screen and actually found it lovely and moving - although unfortunately I have a feeling it lacks the star appeal to get itself top billing for an Oscar. Storyline was great, I found the script a bit weak in places, but for junior geeks I thought a great message about brains over brawn.
Japan is doing fine with the iPhone - not a runaway success but the articles claiming that it was failing there were exposed as wrong. The Japanese love things Apple.
Regarding Thailand, there's a good reason the iPhone isn't popular there - I don't believe it has Thai language support.
I don't believe a word of it. Generally speaking the only way that WinMo could be calculated as second largest worldwide is on some perversion of "shipping devices" - just because there are 50 devices available which run WM doesn't mean anyone is buying them. RIM is the second largest smartphone platform and if Apple isn't now third (ahead of Windows Mobile) I'll eat my hat.
This may have been true some time early in 2008 but I call bollocks on this.
You really should get your hands on the American Beauty soundtrack! Great for coding to and very soothing. Other posters mention the Riven soundtrack which is also brilliant.
Many years ago I worked at the Harvey Norman computer chain in Australia and the games guys often took games home at the weekend to check out. The reasoning was simple - if you've played a game and a customer wants advice on which game to buy you're in a position where you actually know what you're talking about rather than just staring at them blankly.
This was before the days of the internet being widely available, but I think the policy still holds true. If you're buying a game at a marked up price from your local software mart then the staff there better know what they're selling - otherwise how can you justify the retail space and the markup?
So far from being a scandal, I call this sensible business practice.
...because although Tokeneer has been released as open source the SPARK toolchain is owned by a company and the specification for SPARK is fully controlled by them. Has money changed hands somewhere?
This simply isn't true. BREW, used by Verizon's Get It Now service, Alltel and other CDMA carriers in the USA have a "single point of origin" system in place as well. All applications are centrally submitted and tested via QUALCOMM and these are placed in a centralised application database which carriers can select applications from. This ridiculous claim that Apple is somehow the first to do this or the big nasty one for doing this needs to be put to bed - they have replicated and tweaked a business model for mobile application development which is proven.
"I've been through two wars and I know. I've seen cities and homes in ashes. I've seen thousands of men lying on the ground, their dead faces looking up at the skies. I tell you, war is hell!"
You aren't fighting a war to be nice. You are fighting to win and to do so you need to do whatever it takes.
These things mentioned are unpalatable but then again - so is war. Moral of the story - avoid it. But sometimes you will have to fight, and when you do, fight hard and fight to win.
CDMA is not only used in the US - that is false. KDDI in Japan, Reliance and Tata in India, Pelephone in Israel, Vivo in Brazil - the list goes on and on. CDMA is still very popular, even though it is playing second fiddle to GSM.
I was working with a teacher on Sunday night trying to prepare a presentation in OpenOffice (it was running incredibly slowly) and she said "I hate OpenOffice". She isn't a geek, she doesn't particularly like computers, but to her it was a huge disappointment to have to use OpenOffice instead of being able to use PowerPoint.
So far from a knockout punch, I think OpenOffice barely registers in terms of it's disruptive influence. I don't use it, my employees don't use it and everyone I know who has to use it hates it. Perhaps it's time as a community we considered alternatives. The "quality" of OpenOffice isn't something I think people are particularly happy with.
Not so easy with the points-based immigration system. Just being able to "do IT" won't get you the visa, unfortunately, and the Oz government is much stricter on foreign applicants now...
Ben - just a big thankyou for all of your work on SVN. It has definitely changed my company's life for the better and all of your energies are appreciated!
I can't wait for better merge tracking, that's my number one hot-button issue.
You've made a good argument there but the problem is not the labour cost - if it were just that then it would be less of a concern. The problem is that there are project-related issues (delivery dates for example) which make a lost repository a far more significant issue than just the labour cost of retyping the code.
Regarding costs of backup - basically the repository is just mirrored on a daily basis - so recovering the entire repository is probably not half a day but an hour at most. And the chances of losing it on a RAIDed server with all the usual bells and whistles are basically insignficant.
You're right about hard disk cost and reliability, I see fewer and fewer losses as a result of hard disk crashes every year and so maybe my position is starting to look a bit lame.
But I tell you what. I'll experiment with using DVCS on a project soon and will see if the shortcomings are less significant than I am making out. More reliable branching and merging could be sufficient to change my mind, even if there is some potential loss of data security (however small the chance). It will also have the side benefit (if Linus is telling the truth - why would he lie?) of making me a genius who is irresistable to women. Who could pass up that offer;-)
I understand just fine how a DVCS works. The problem I see in a corporate environment is that it encourages working from a local repository (it's not a backup - it's a real, living, breathing repository that exists entirely independently from the source) rather than encouraging working centrally.
Contrary to what you say, it doesn't seem to me that you can force people to push all of their changes through to a blessed server. People can work independently until it is time to release and this is made possible (encouraged?) by the loosely-coupled independent repository nature of DVCS.
I think the key issue is - which behavior is more desirable in your particular space? In Open Source, I can certainly see the argument that the independence of DVCS is advantageous. But in the corporate world I see more risk than reward.
I'm not fully convinced by this argument. When people use SVN they naturally get nervous about having uncommitted changes and so they commit regularly - and are encouraged to do so.
Seeing what people are up to is also a lot easier in a centralized system if people are committing - having to go and dig around in a bunch of private repositories is a major pain. And the visibility into work in progress requires publishing their private repository, so that needs to be enabled just the same as it needs to in SVN.
Ultimately though, what is clear to me is that this isn't an issue about what CAN be done with either tool. The issue is the behavior that each tool encourages. DVCS encourages independence. CVCS encourages interdependence.
I appreciate that this is an advantage or working in a DVCS - but I think a better way of addressing this issue would to have better branch/merge support in SVN rather than independent local repositories.
You may consider them "bits of crap" - but I'd rather have your work, no matter how crap you consider it, somewhere where I'm relatively certain I can recover it if your laptop or PC craps out. You can still have them on a private branch (this is what I encourage - so they are backed up!) and you get the subtask advantage you mention without the risk of losing a local repository.
I don't defend SVN's branching though, because it's garbage. I wonder how many people are DVCS fans because the branching is so much better - this would certainly be my key priority if I were planning what to do next with SVN.
It's less of a concern because the pattern of behaviour that is encouraged. DVCS encourages independent working in an "uncontrolled" independent repository whereas CCVS encourages working interdependently in a centralized repository. So it's less of a concern because unless you really go out of your way to be a psycho (weeks without committing a change) you will naturally commit your changes for fear of losing your version history.
It's always possible to have some psycho who does an svn export and makes his own little repository somewhere away from the rest of the team. Yes, I've seen it done too. But tools naturally support certain ways of working and DVCS I think encourages behavior which would not be desirable in corporate software development.
It's not that I don't understand how it works, I do - and I appreciate that you can use any tool irresponsibly - but I'm not convinced that for the type of software development that most companies do DVCS makes sense.
The worst-case loss in the event of a total failure of a single computer is one developer's local changeset(s), but that's the exact same risk when working with a centralized system as well. A developer's uncommitted work can always be lost if precautions aren't taken. That's slightly disingenuous - in a DVCS you are more likely to have local changesets than you are to have uncommitted work in a CVCS. So saying that it's the exact same risk I think is a bit unfair.
Slashdot Mirror
Not prurient. Whatever the opposite is.
Yes, and I just don't believe them. It's super-bad press for them a week before they release their new device.
The core problem is that in order to improve iCloud use they have actively encouraged users during the signup process to enable iCloud syncing - and default settings push all of your photos, docs and data. For a time-pressed celeb who may not be that tech savvy this is just asking for trouble.
I'm a bit surprised by the number of people who send around naked photos of themselves though. I must be in the prurient minority.
Replying to myself - as it turns out, the plot thickens:
http://www.huffingtonpost.com/...
There's about a third of the globe between the two...
Yep I totally agree! I watched it at the with my son on the big screen and actually found it lovely and moving - although unfortunately I have a feeling it lacks the star appeal to get itself top billing for an Oscar. Storyline was great, I found the script a bit weak in places, but for junior geeks I thought a great message about brains over brawn.
Oh, and thanks a lot, you useless reptile :-)
Japan is doing fine with the iPhone - not a runaway success but the articles claiming that it was failing there were exposed as wrong. The Japanese love things Apple.
Regarding Thailand, there's a good reason the iPhone isn't popular there - I don't believe it has Thai language support.
I don't believe a word of it. Generally speaking the only way that WinMo could be calculated as second largest worldwide is on some perversion of "shipping devices" - just because there are 50 devices available which run WM doesn't mean anyone is buying them. RIM is the second largest smartphone platform and if Apple isn't now third (ahead of Windows Mobile) I'll eat my hat.
This may have been true some time early in 2008 but I call bollocks on this.
You really should get your hands on the American Beauty soundtrack! Great for coding to and very soothing. Other posters mention the Riven soundtrack which is also brilliant.
Many years ago I worked at the Harvey Norman computer chain in Australia and the games guys often took games home at the weekend to check out. The reasoning was simple - if you've played a game and a customer wants advice on which game to buy you're in a position where you actually know what you're talking about rather than just staring at them blankly.
This was before the days of the internet being widely available, but I think the policy still holds true. If you're buying a game at a marked up price from your local software mart then the staff there better know what they're selling - otherwise how can you justify the retail space and the markup?
So far from being a scandal, I call this sensible business practice.
"Chief Barry Burns, of Esparto Fire Department" :-)
...because although Tokeneer has been released as open source the SPARK toolchain is owned by a company and the specification for SPARK is fully controlled by them. Has money changed hands somewhere?
This simply isn't true. BREW, used by Verizon's Get It Now service, Alltel and other CDMA carriers in the USA have a "single point of origin" system in place as well. All applications are centrally submitted and tested via QUALCOMM and these are placed in a centralised application database which carriers can select applications from. This ridiculous claim that Apple is somehow the first to do this or the big nasty one for doing this needs to be put to bed - they have replicated and tweaked a business model for mobile application development which is proven.
As General William Sherman said;
"I've been through two wars and I know. I've seen cities and homes in ashes. I've seen thousands of men lying on the ground, their dead faces looking up at the skies. I tell you, war is hell!"
You aren't fighting a war to be nice. You are fighting to win and to do so you need to do whatever it takes.
These things mentioned are unpalatable but then again - so is war. Moral of the story - avoid it. But sometimes you will have to fight, and when you do, fight hard and fight to win.
Not true! Zapp in Romania (part of Europe now!) is a CDMA carrier.
http://www.zapp.ro/
CDMA is not only used in the US - that is false. KDDI in Japan, Reliance and Tata in India, Pelephone in Israel, Vivo in Brazil - the list goes on and on. CDMA is still very popular, even though it is playing second fiddle to GSM.
I was working with a teacher on Sunday night trying to prepare a presentation in OpenOffice (it was running incredibly slowly) and she said "I hate OpenOffice". She isn't a geek, she doesn't particularly like computers, but to her it was a huge disappointment to have to use OpenOffice instead of being able to use PowerPoint.
So far from a knockout punch, I think OpenOffice barely registers in terms of it's disruptive influence. I don't use it, my employees don't use it and everyone I know who has to use it hates it. Perhaps it's time as a community we considered alternatives. The "quality" of OpenOffice isn't something I think people are particularly happy with.
Not so easy with the points-based immigration system. Just being able to "do IT" won't get you the visa, unfortunately, and the Oz government is much stricter on foreign applicants now...
Ben - just a big thankyou for all of your work on SVN. It has definitely changed my company's life for the better and all of your energies are appreciated!
I can't wait for better merge tracking, that's my number one hot-button issue.
You've made a good argument there but the problem is not the labour cost - if it were just that then it would be less of a concern. The problem is that there are project-related issues (delivery dates for example) which make a lost repository a far more significant issue than just the labour cost of retyping the code.
;-)
Regarding costs of backup - basically the repository is just mirrored on a daily basis - so recovering the entire repository is probably not half a day but an hour at most. And the chances of losing it on a RAIDed server with all the usual bells and whistles are basically insignficant.
You're right about hard disk cost and reliability, I see fewer and fewer losses as a result of hard disk crashes every year and so maybe my position is starting to look a bit lame.
But I tell you what. I'll experiment with using DVCS on a project soon and will see if the shortcomings are less significant than I am making out. More reliable branching and merging could be sufficient to change my mind, even if there is some potential loss of data security (however small the chance). It will also have the side benefit (if Linus is telling the truth - why would he lie?) of making me a genius who is irresistable to women. Who could pass up that offer
I understand just fine how a DVCS works. The problem I see in a corporate environment is that it encourages working from a local repository (it's not a backup - it's a real, living, breathing repository that exists entirely independently from the source) rather than encouraging working centrally.
Contrary to what you say, it doesn't seem to me that you can force people to push all of their changes through to a blessed server. People can work independently until it is time to release and this is made possible (encouraged?) by the loosely-coupled independent repository nature of DVCS.
I think the key issue is - which behavior is more desirable in your particular space? In Open Source, I can certainly see the argument that the independence of DVCS is advantageous. But in the corporate world I see more risk than reward.
I'm not fully convinced by this argument. When people use SVN they naturally get nervous about having uncommitted changes and so they commit regularly - and are encouraged to do so.
Seeing what people are up to is also a lot easier in a centralized system if people are committing - having to go and dig around in a bunch of private repositories is a major pain. And the visibility into work in progress requires publishing their private repository, so that needs to be enabled just the same as it needs to in SVN.
Ultimately though, what is clear to me is that this isn't an issue about what CAN be done with either tool. The issue is the behavior that each tool encourages. DVCS encourages independence. CVCS encourages interdependence.
I appreciate that this is an advantage or working in a DVCS - but I think a better way of addressing this issue would to have better branch/merge support in SVN rather than independent local repositories.
You may consider them "bits of crap" - but I'd rather have your work, no matter how crap you consider it, somewhere where I'm relatively certain I can recover it if your laptop or PC craps out. You can still have them on a private branch (this is what I encourage - so they are backed up!) and you get the subtask advantage you mention without the risk of losing a local repository.
I don't defend SVN's branching though, because it's garbage. I wonder how many people are DVCS fans because the branching is so much better - this would certainly be my key priority if I were planning what to do next with SVN.
It's less of a concern because the pattern of behaviour that is encouraged. DVCS encourages independent working in an "uncontrolled" independent repository whereas CCVS encourages working interdependently in a centralized repository. So it's less of a concern because unless you really go out of your way to be a psycho (weeks without committing a change) you will naturally commit your changes for fear of losing your version history.
It's always possible to have some psycho who does an svn export and makes his own little repository somewhere away from the rest of the team. Yes, I've seen it done too. But tools naturally support certain ways of working and DVCS I think encourages behavior which would not be desirable in corporate software development.
It's not that I don't understand how it works, I do - and I appreciate that you can use any tool irresponsibly - but I'm not convinced that for the type of software development that most companies do DVCS makes sense.
There isn't any difference, you're right - but I think DCVS tools encourage disconnected behaviour whereas CCVS tools don't.
You can use any tool badly, but some tools are easier to use badly than others.