Two problems with that:

#1 Age appropriate is pretty much impossible to automate. Every entry would have to be human-reviewed, and that's expensive.

#2 What you consider age-appropriate, someone else may note, and vice-versa. It's not objective, it's subjective.

The flip side of this is that my parents point-blank told me they would not come visit me because I did not produce grandchildren for them.

On the other hand, they seem to have no problem with calling me for tech support.

If I was representing the truckers, I'd say "Sure, no problem, we just won't transport any loads carrying your goods anymore."

See how quickly they decide a few dollars in licensing revenue is not worth losing all retail sales.

And OO is not a complicated extra of programming, it is a simple ideology that makes programming so much easier when you know it.

I'll admit that OO does make programming easier in the long run. Though to do it right, you MUST spend a fair amount of time planning before throwing down that first line of code.

However, OO is just not suitable for all programming tasks. I currently work with an app that processes over 70,000 transactions per second. I doubt I could get a tenth of that performance with any OO language. Even in C, I spend quite a bit of time looking for ways to cut down on the number of conditionals, etc, since eliminating just one IF statement in the right place can get me as much as a 5% performance increase.

I fully agree that one should learn to program well procedurally FiRST, before tackling OO. If you don't have a firm grasp of that basics, you will never reach your full potential/

Call me confused, but what exactly is the correlation here? The SMS bug involves messages being sent to the wrong # under certain circumstances. It has nothing to do with stored data. That's like saying I should stop using Ubuntu for code development because there's a bug in the audio drivers.

Seriously, you would send confidential data over SMS?

And getting around the Android SMS bug is easy enough, get a Google voice account and use it for SMS instead of the native app. I still don't think I'd use it for confidential data though.

Agreed, someone comes up with something new to solve a very specific issue, and all of a sudden someone's predicting how it will completely replace everything else in the next month.

Grow up.

Physical storage and relational databases aren't going anywhere anytime soon. in-memory this and non-relational that are all well and good for the specific problems they were designed for, but physically stored and relational data fits the needs of 90% of data storage and retrieval. I sure as HECK don't want my bank storing my financial data purely in memory.

So keep yelling to yourselves about how the sky is falling on traditional techniques. Meanwhile the rest of us have real work to do.

The originating network of the client.

Caching would not have to be turned off, but it would get a lot more complicated.

Note that the draft expired, but I expect someone will eventually resurrect it.

EDNS Client IP

No, it's not particularly elegant. But on the other hand, split-horizon DNS is nothing new or magical either. Nor would I classify it as "abuse". The capability has been there since the early days of BIND.

In the DNS trade, we refer to it under the category of "stupid DNS tricks"

That said, it does have some significant advantages over other techniques.

#1, It's protocol-independent. Sure you can do intelligent redirects with HTTP, but not everything in the world is HTTP
#2, Even with HTTP, in order for it to work, you have to now change the name of the server, and often the links to internal content. Your initial request to www.domain.com will now have to be redirected to hostx.domain.com or www.location.domain.com etc., and links on the pages to content servers will also have to be altered. This can be confusing to end-users, and may require additional SSL certs. It's also a code maintenance issue.
#2a, While the renaming seems trivial on first glance, it has HUGE implications for search engines, etc, since those "local" servers will get indexed instead of a generic name
#2b, It also means that a calculation will have to be made by the web server deciding where to redirect you to, then the actual redirect, increasing load and latency. DNS solutions are "pre-computed" and thus do not have similar issues.
#2c, If you solve 2a by checking every request at every location, you make 2b much worse
#3, It's simple.

Downsides:

#1, Third-party DNS recursive services throw it off. (There is a proposed RFC that would allow for such recursives to pass the originating network in the request)
#2, It makes DNSSEC a right royal PITA (Much more than it already is)

It doesn't. But it makes a nice straw-man, doesn't it?

For someone with control of the root, DNSSEC makes things only slightly more difficult, but definitely does not make it easier.

This is definitely theoretically possible. However, you're going to have to convince the major application developers to play along.

Though to be fair, it would only be the equivalent of the cheaper certs that only verify domain control for authority when issuing certs. The higher-level certs truly do involve a third-party verification of identity of the cert recipient.

Sure, they could pressure the parent to supply bogus records. On the other hand, they always could have pressured them to change the NS records, which they would also have to do if they published bogus DS records.

So at absolute worst, no security was gained from the "government". It cannot be made worse, because any theoretical compromise by the governing agency was already possible, and much easier before.

Actually, .net was enabled sometime around 16:00 GMT yesterday. They just didn't announce it until today.

I was doing testing of a DNSSEC system yesterday, and one of my test cases change state on me unexpectedly. (Signed zone in an unsigned parent)

You really don't know what DNSSEC is, do you?

What DNSSEC does: DNSSEC provides a means for an end-user to determine the authenticity of the DNS data they receive by proving that only someone in control of the domain could have served the record.

What DNSSEC does not do: DNSSEC does not provide for the security of data being exchanged between systems.

With DNSSEC, each domain admin holds their own private keys. Nobody else should ever see them. Chain of authenticity is provided by each parent domain signing the delegation records provided by the child domain.

So, for the "government" to "exert control" over your domain, they would have to completely spoof every parent of your domain. This would affect not just your domain, but all domains in that TLD. Pretty sure if everyone in .com all broke at the same time, someone would notice. In short, this makes it harder for someone to take control of your DNS. If the "government" wanted it to be easier, they never would have allowed the root to be signed.

And let's face it, DNSSEC was not designed for you. DNSSEC is designed for businesses, banks and other large entities who are trying to protect their customers from being spoofed. It is just another tool like SSL. And, IMO, anyone who uses SSL certs should use DNSSEC. If you don't use SSL, it's highly unlikely you need DNSSEC.

But hey, if all you want to do is spew ridiculous conspiracy theories, never mind, rant on.

Anyone want to start a pool on how long it will take someone to crack the system and start sending bogus alerts?