As you pointed out yourself, the difference between your original statement and my correction is there. It may not be large, but there is a delta. Many independent film makers don't care about the DRM stuff, and they're a growing group. Netflix probably doesn't care much for the DRM stuff either for what they produce - also growing, and very good quality.

Like GPS and accelerometers in mobile devices, if developers have confidence that more/all users will have access to a certain technology, it's more likely they will try to come up with useful ideas.

Also, don't forget that the Kinect 2 is vastly improved over the Kinect in terms of depth resolution and AI capabilities. That alone could give developers what they need to take their games and other software to the next level.

If FCC had to decide an obscentity question, it would use a test derived from the one in Miller v. California. The most important of the three tests in that is whether the item lacks literary, artistic, scientific, or political value. Would that such a standard were applied to Slashdot!

Well, I really do appreciate that we keep folks who can't articulate themselves without resorting to swear words out of the ham community, and that they have to take a test as well. The people we talk with on ham radio meet a higher standard than you'd meet in the local bar, or come to think of it, on Slashdot. And I'm not the slightest bit interested in lowering that standard.

I'd argue that people flipping out over feeling like their privacy is being violated is nothing like people flipping out because they think that there is a chance that they might actually cease to be alive.

And besides... privacy is an illusion. In public, it really only exists because most people would rather pay attention to things that actually concern them than be bothered with other people.

Just a few requirements from last week:

REQ.1: A report will be provided with an overview of the number of incoming, delivered and processing cases.
REQ.2: A case will be counted as "incoming" when the creation_date is filled with a valid date(*).
REQ.3: A case will be counted as "delivered" when the status = "Final" and the delivery_date is filled with a valid date.
REQ.4: A case will be counted as "processing" when REQ1. has been satisfied but REQ.2 has not.
REQ.5: All cases can be counted per "purchasing organization", "business unit" and "order month".
REQ.6: A purchasing organization has a level called "organization', which consists of the full name of the organization (ORG.FULL_NAME).
etc.

Non-functional requirements deal with exceptions, missing values, auditing, logging, security, backup & recovery, scheduling, etc. etc.

While the set above is not complete, it does show a bit of standard requirements.

(*) I'm sure you can nitpick about edge cases where the database suddenly gets corrupt. We ignore that explicitly.

In the software I wrote the specs for (last year) we had requirements like "The MEDICATION field has to hold a valid value that is present in table X, or the entire record will be referred to the basket for manual processing". It really doesn't need to be more complex than that, for a lot of cases.

I don't think you use "use case" entirely in the way I normally use it. A use case is what it says: something where someone or something uses the code to achieve some desired result. Error handling is just a part of it to make sure you actually complete the use case.

Logging, auditing and security are all non-functional requirements. You can find whole libraries on this but the basics are pretty simple. Note: non-functional requirements. They're not in any use case.

As for checking the returns of any function: I completely agree! Just give your co-worker a good kick in the behind and tell him it's from me. But it is just one effing non-functional requirement at best (and usually not even that, but it's just part of the coding standards), not a use case.

Yes, don't let any of the folks doing any work talk to a user for crying out loud! Make sure to insulate them by as many unemployed cousins as possible, enabling you to make a tidy profit, and preventing the client from having to talk to those dreadful nerds. A win-win all around.

Do you work for Accenture by any chance? Because you sound familiar...

In Agile development this is called "building inventory" and it's a net cost, not an asset waiting to be used. It takes a while before people understand the whole "inventory == cost" concept but once they do, it really helps to avoid this scenario.

Have you considered that people who already regularly get pussy don't need to take charity from corporations in order to have a nice pair of tits in their face?

Yes, that's exactly right.

I appreciate a pretty woman (and, fortunately, am married to one), but I'd rather not have that appreciation manipulated for someone else's commercial gain.

I resent that some business is attempting to grab me by the balls rather than by my rational self.

Wouldn't this make the medium a much more relevant and useful tool in the modern age

No, it really would not.

What it would make it is duplicative of functionality of internet, the cellular network, WiFi and WiMAX, and point-to-point links on Part 15 bands. You can already use all of those to do whatever you want, including commercial and obscene material.

One of the most important means of preserving it as a sandbox for experimenters is that the whole commercial world is excluded. So, there's room for us.

And why would you believe anything de Icaza says? Especially as it relates to Microsoft?

TCP works pretty well in environments with high packet loss. Just as good as UDP does. There is a point of no return there though.

Now, I do agree, TCP doesn't hog bandwidth. In fact, it limits an applications ability to flood the network. Each TCP stream can typically use at most 33.33% of the network. You can get around that by using multiple TCP streams, which also happens to be the best way to handle high packet loss environments (such as SatComm).

And yes, I've worked in those environments.