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.