Ever since they released their iPhone app customers have been asking them for sync. This being a productivity app sync is very important. Things for the longest time has had WiFi sync. It is a pain for two reasons:
1. I have to remember to sync my devices every time I make changes. This is not rest of my productivity apps work. My calendars sync automagically, my email inbox sync automagically, my filesystem syncs automagically, BUT my _productivity_ app does not!
2. Wireless syncing doesn't always work because in some environments they block the underlying protocol. Then I have to setup an AdHoc network etc. etc.
Failure on CC's part, IMO, is the lack of understanding, perhaps, of how important sync is to their customers. A good approach would have been to incrementally introduce support for sync, using Dropbox or MobileMe or what not. Instead what it looks like happening is they are building a whole new infrastructure that we will have to use to sync Things. My problem is that I already pay for two good sync solutions that work well. I don't see the point in paying for another one just for syncing.
Some how this all sounds like they are gearing up to develop a Things specific sync service. Last thing I want is another service I have to pay to sync my data. Already paying for Dropbox and MobileMe.
Recently I wrote "...user data is scattered among many web properties..." In essence it is "data scatter" Decentralization, in my mind, implies some sort of planning on where to put data (say to prevent failure or enhance efficiency...) but I don't think users plan.
Not necessarily all evil. Only text-book implementations require that one allocate individual nodes. Most implementations I have seen in Linux and FreeBSD can pool allocate the nodes. One can also pull off neat tricks to append link chains in these implementations to expand the list without the need to reallocate memory as needed by arrays.
People who can authoritatively talk about such attacks can't or don't talk. So, information out there is mostly anecdotal at best or just plain speculation. These cables add to that stack of information but from a much higher level of involvement. It may not be new or news but it's certainly from more credible source than what we usually hear from.
One of the big problems is there is no incentive for repeating or asserting previous results/findings. So even if someone is doubtful of an assertion made there is no incentive to follow up and verify the assertion in general. I don't think sharing code or secret data cleaning methods is going to bring much change unless someone is rewarded for repeating the results.
Can we turn down this 'author-is-using-a-cheap-trick-to-attract-audience' volume around here. I don't think Bruce Eckel needs to attract audience so badly that he will do it purposefully. Granted, title is not reflective of the content but give the authors some benefit of the doubt. Let's do a quick Google search on authors before we write stuff like this.
This is one of the questions I ask every interviewer who interviews me.