If they didn't already have a tested deployment procedure, that is a bigger indictment upon their professionalism than the woeful communication during the incident.
By that argument, no physical tokens (secureid, yubikey, etc) add another factor - they also _could_ be stolen at the same time as your laptop is stolen.
While I admit to only skimming that link, all the examples I read discussed a single company tying purchase of one of their products to one of their other products.
Apple does not sell DUNS numbers, as they are not Dun & Bradstreet.
It also mentioned the anticompetitive nature of tying a weak/new product to a stronger one. DUNS numbers are not new or esoteric (although I do think of them as being old-fashioned and enterprisey).
So, I struggle with the notion that this could be illegal, but I'd be fascinated to learn more about it.
Sure is developer hostile and counter-productive, though.
Alternatively, the ET44 is a portable electronic device, Apple Calc is a piece of software. The T3 is a radio receiver, the iPod is a stored music decoder.
Why not point out that the T1000 is a radio, and the PowerMac contains bluetooth and wlan radios? Or that both are electronic devices?
By all means, argue that the distinctions don't matter (and that the distance in time excuses nothing), but putting these examples in the same box as the Apple/Samsung ones is surely disingenuous.
If you're looking for book suggestions, I'd recommend "Growing Object-Oriented Software, Guided By Tests" by Steve Freeman and Nat Pryce. It's pretty pragmatic, and the treatment of the subject is pretty thought-provoking (at least, I thought so when I read it).
The idea sounds like it might be interesting, but I can't imagine how this works and neither your website nor the facebook page linked at the bottom tell me anything about it.
I might suspect that if I signed up with Facebook Connect that there might be more information, but it's not clear whether that's the case - and I wouldn't try it on the off chance.
I would suggest that there needs to be more up-front information to explain what happens if I use Facebook Connect to login. How does giving you my credit card work? On the face of it, that sounds like a scam. Is this service for everyone, or only people in the USA? After signing up, how easily can I opt out? etc etc.
Trying to push to a client the crappiest implementation that seems to work is certainly everything you say that it is - but that's not the same thing as delivering the simplest implementation that works.
That's fair - Sun at least had the option of relicensing (given that the required contributors to sign an IP agreement).
FWIW, it saddens me to watch Solaris stumbling towards its grave. Remaining available only on hardware sold by Oracle renders it worthless to me.
I can't make that shift now, which means that I need to build my own credible alternatives to using Solaris. And when I am in a position where I could afford Solaris on Oracle hardware, I won't be so inclined - because I'll have my homebrew alternatives, and a bitter taste in my mouth.
I'm sure I'll get knocked for this (again), but if you want to pick nits, it's the GPL that prevents the commingling, not the CDDL.
Why not just say that the licenses are incompatible?
That's the simple truth, and that's not a slight on either of them.
The real problem here is that there doesn't appear to be an OpenSolaris development community outside of Sun^WOracle. It's much like Mozilla in its early days, though with an even smaller chance of success. Mozilla's competitive landscape was devoid of credible open-source alternatives - that's not the case for OpenSolaris.
Were all of Facebook's service free software, that wouldn't guarantee interoperability.
Conversely, providing effective interoperability doesn't require free software.
I'd say it's more like the organisers of a suit convention not allowing a hotdog vendor to operate inside.
This upsets the people who understand the risks associated with eating hotdogs while wearing their suits, while protecting other suit-wearers who don't appreciate the risk of soiling.
The problem with this analogy is that while any reasonable person can foresee condiment spillage, the average consumer is utterly unaware of the tradeoffs that Apple appears to be concerned about. Nor should they need to be.
It's one thing to suggest that the police will pay greater attention to high profile cases (with which I'd agree), and quite another thing to imply that the raid happened because Apple requested it.
Beyond that, could you point out the source of your assertion that Apple requested this? I missed it in the article, and that's the conspiracy you've raised.
While the title of this article is misleading (it's really about communication, not scheduling), it is food for thought.
Though I can't help but boggle at the author encouraging a team to abandon all milestones/deadlines in the pursuit of quality. While perhaps the given team really was looking for a convenient excuse for any quality problems, I can't help but look at it as pragmatism.
"Take all the time you need - but make sure it's perfect," is a good way to discourage completion.