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.
Hadoop is open source. The companies building it are LinkedIn, Yahoo, Facebook and then the Hadoop vendors: Hortonworks (tightly tied to Microsoft), IBM, Cloudera (enterprise support vendor)...
You are overestimating the difficulty at this point. This not compsci anymore and hasn't been for many many years. It isn't even hard administration. It is probably easier to get a big data system running in 2015 than it was to use Oracle in 1995.
As far as your examples you went way too big. GE is a huge DevOps shop, they know what Big Data is. Exxon has massive supercomputing datasets. I would bet they were doing big data long before it got cool. Pfizer has an IT department that is some of everything but they have many many data warehouses so I can't imagine they aren't playing with data lakes.
I don't see any evidence that Oracle is heavily invested in either Solaris or Sparc. They were dying technologies when Oracle bought them and they have done little to revive them. Oracle has the cash for a massive push for Solaris or Sparc innovation and they haven't done it. They've let them fade.
Anyway I've met the thought leaders for Oracle Linux. Their work right now is focused on really large customer support. Oracle is using Oracle Linus to get further into the hosting / cloud / IaaS reoccurring revenue business (think classic Terremark, Sungard...) The people are strong. Areas like application centric virtualization, and virtual compute appliance (Oracle's cheap version of Netezza / Exadata) are where the focus is. Just not the sort of stuff the
There are two issues here
XFS has changed the way it repairs. That has nothing to do with systemd.
Systemd does, as you say, old things in new ways. Which means config files are probably worse than they used to be. This is a reasonable concern. There is a one time training hurdle, just like when you changing end user's applications. There does need to be some improvement in best practices as we move from a more mature set of configurations to a much less mature set of configurations.
OK show me the grep command to pull all variants that every application on a Linux system uses in syslog to refer to a drive failure?
My answer was clear. The original poster and yourself are both wrong. The disk is not in the middle. In journald.conf set Storage=none and log remotely. Then the journal won't touch the local disk at all yet the export to other systems still works fine. There is an application running and it is sending data from memory to multiple streams. It is simply not true that a disk is required to send data.
systemd allows you to configure logging however you want and is more flexible than the init based systems of years ago. Which was my answer. You are gaining not losing flexibility. The system has more easily (to a developer) hooks. And as the external tooling develops there will be far more hooks for system admins.
Solaris had a process manager years before Linux did. The ideas for systemd came from big box Unixes.
First off grep is generally bad with minor variations. It would work if there was a good uniform identifier system. But because there isn't using grep to search a large log you can get lots of false positives and false negatives.
For example if the error says
or it could say
OK what enterprise applications have indicated they have problems with systemd?
Why bother with that rubbish when proper text logs are so superior and easy to handle?
They aren't superior they are simpler. A list of random sentences of news articles is less valuable than a hierarchical index of the news stories. Similarly for computer events. Organization and hierarchy helps? How do I ask a text log to give me all events related to a particular hard drive hardware errors in the last 2 weeks easily?
Two things:
a) Oracle has to deliver stability. They have stability guarantees in their contracts
b) He specifically cited Oracle, so that's why I brought them up.
I do think highly of Oracle. There are certainly problems. But partially those are caused by over promising and partially those are caused by being held to a much higher standard than other vendors where. Oracle can be jerks but there is a good reason they have grown the way they have. So FWIW I would consider their judgement good.
I thought it was a close call on init systems (and to be fair, systemd isn't exactly the mature, rock-solid solution a replacement init should be!)
It depends when you mean. The first vote upstart and OpenRC were falling behind. By the second vote they were far behind. There was no viable replacement. At that point the question was
a) Whether to support multiple init systems
b) Whether to unify
There weren't many upstream dependencies so this was close. Then the upstream dependencies started to spread like wildfire through Debian and the choice became:
a) Spend a ton of resources fighting the tide and offering multiple systems. Unclear how to do this.
b) Switch at Jessie
c) Hold out for one more version
There were some subtle aspects but mainly it was never really close. Systemd pulled way ahead and created dependencies.
The votes for a replacement on the Debian list should have gone with Upstart IMHO as it was the most popular option
Again when? By the time of the final vote, by now upstart isn't viable.
Still, it doesn't really matter now - what does matter is that the init system is rock-solid, has buy-in from the customer base (ie the community who use Linux, including server admins) and doesn't require too much re-training to understand and administer it. I'm not sure it has any of those 3 currently.
That's not going to be the criteria. I don't think init based systems are all that stable. Closer using your list is going to be:
a) Has buy in from the developer base
b1) offer a total environment that is more stable than init's
b2) Is designed to be a standard API replaceable with an IaaS for better stability without applications needing to be changed
c) Be easy to administer.
The 1990s concept of stability where one is worried about the stability of individual instances is being replaced by the virtualization concept of cloud stability.
It is clear that the individual who persecutes a man, his brother, because he is not of the same opinion, is a monster. - Voltaire
