LAN Manager was multiuser. The client wasn't but that doesn't make much difference as the non-multiuser smartphones phones using apps and websites today proves quite well.

I see turbidostato below made the same point.

OS/2 had networking (really good networking) and multitasking. Lan Manager (based on OS/2) as well as Novell (worked with OS/2) had file permissions. So they produced a product with those 3 facets.

Apple today only sells to the "high end" of the market. They mostly sell $500+ and they have some share $400-500 with no share below that. Their phone is already niche in the way you claim it will eventually be.

Why does Apple feel the compulsion to plow money into an inferior map service?

I think

1) They don't want to be held hostage
2) They can provide a high degree of integration and services on their mapping service than they could using Google's offering.

It only benefit their iphone niche until they can't sustain a lower end iphone market.

I don't understand this. I'm not sure they won't be moving down market not up market given they own the entire up market. Why wouldn't they be able to sustain a lower end iphone market?

RDBMS engines are designed to convert routines of in memory row by row or group by group statistical operations and figure out good (optimal) disk / memory organizations. That's one of the things they are very very good at.

Check your math on that, please. 8*3600*3 = 84.375 GB, not 85.5 PB.

You are correct. Sorry.

And if your tracking 3 MB per second per user, you're tracking bots, not users

Absolutely. You are mostly tracking network security events, computers talking to other computers. What you are generally looking for is unusual activity. Server 2047 never talks Asia all the sudden it is talking to Vietnam regularly. But to do that you need to know who is talking to what across the network.

SQL can handle all of it if you design your database sanely

Yes and no. Obviously if you knew in advance ever type of message, designed good ways of getting it in there, good aggregates then a RDBMS would be better. But with: formats of data poorly understood, bad understanding of the types of data, complex matches, unclear rules about to normalize... SQL Server's engine won't hold up. Of course you can just throw it in a table but then you can't do much with it at reasonable performance. That's what Big Data engines are for. Once (if everO you do understand the data well enough to get it into a RDBMS of course you would rather use an RDBMS.

. You pay a penalty for your poor design, sure, but everything works.

No it doesn't. RDBMS don't scale as well as Big Data systems. As the number of CPUs, total memory, total disk increases (particularly in cluster configuration) their performance does not increase linearly or even nearly linearly. You can't just pay a penalty and solve the problem by hardware.

I don't think they are going to make 2020 at this point. The replacement for 1xRTT voice is going to be VoLTE. I have it on my phone. I have it disabled on my phone since the 1xRTT network is go good, the data network is much more spotty and I care about voice reliability. But that will resolve itself over the next decade. It wouldn't shock me if on my next phone I'm using VoLTE all the time for voice.

Even if they were going to make the switch by 2020 (again I'm thinking 2025 or something is more likely) the cost of VoLTE phones in 2020 would be likely be $50 or lower. Giving out 100m of these for free would likely be cheaper than keeping the old network up and running.

Supporting old (non standard) phones is a serious cost, so good point.

Good examples.

SQL server is based around the idea of small amounts of changes with data retention being long.

Assume a system throwing off 3mbs of data which many companies can have if they are aggregating simple stuff like all customers on the websites and sequencing page by page access to look for correlations. There are 28,500 seconds in a workday (more if you have multiple locations). That's 85.5 petabytes of data per day. You need to aggregate this data fast. SQL Server's engine isn't designed for that.

Or for example SQL Server doesn't handle queries against unstructured information. Imagine that each record has a field of text and you want to do joins based on fuzzy matching between these text fields. Even with a few gigs of data SQL Server will die.

/. is so paranoid when it comes to companies. The cost of processing 911 calls isn't that much and the local 911 centers are good customers, heck these fraudulent calls might well be net profitable for the telcos. Where the costs are incurred is the 911 centers processing the calls and then even worse police and fire departments in responding to them. This policy change is the federal government helping out local government. It has nothing to do with "corporate oligarchy".

That's easy the big 5:

1) Datasets to big to use an RDBMS
2) 360 view of customers (CRM consolidation, sales systems consolidation...)
3) Security data from network security devices.
4) Stream in huge amounts of operational data (GPS on employees, physical sensors, machine health...) and do integrated data analysis
5) data warehouse consolidation

Agree with both your comments. That's from a developers perspective it was certainly easier to use Oracle once setup in 1995 than it was to use Hadoop today (by a bit). What the thread was about was setup. What wasn't understood well in 1995 was how to package complex enterprise software so that sysadmin times to get it installed were reasonable. The original poster was talking about the complexity from scratch.

Hadoop didn't exist in 2005. 1.0 release was December 2011 earliest versions I know of were floating around in 2007.

As for using SQL, Hadoop supports SQL (mostly). Problem with Hadoop is the data sets are too big for RDBMS engines to handle. It has nothing to do with developer skill it has to do with the type of database engine and how data is being handled.