It's just that saying C++ is more complex than Java has little bearing on C. C++ is an immensely complex language: loading and using C++ programs is slow. The overhead of using C++ is immense. It's incredible. Name mangling causes tons of comparisons in initialization and during lazy look-up; while classes require constant indirect look-ups through the virtual method table as a matter of course.

In C, you have none of that. memcpy() is just memcpy(), and it's in the PLT. A call to memcpy() doesn't invoke a look-up through the virtual method table to determine which pointer to use for a call %register,$pointer; it's just stuffed into the PLT, and a call to it causes a hard-coded call %register,$offset.

There are no template functions in C because of no name mangling.

In Project Management, procurement management involves advertising and bidding contracts, selecting sellers, writing up the statement of work, quality guidelines, etc., then continuing with performance reviews and metrics to track the quality of work and determine if it meets the contract and the project needs.

Obviously, that didn't happen.

"Better" is not a purely subjective term. Something with higher quality and lower cost is objectively better.

Well, the statement was made 2 days ago, so "last year" doesn't count. Until last year, your girlfriend was single, so having sex with her last night was okay, right?

That argument is stronger. Your argument was, "If it wasn't there at the start...." which is irrelevant when speaking about proportion.

You substituted "100%" for "majority", which need only mean "50% plus some". Linux was released 23 years ago; ICC version 6 was released in 2002, 12 years ago. That's 11 years before ICC version 6.0 for Linux and 12 years with it; I don't have numbers for pre-6.0, but assume earlier releases came at chronologically earlier points in time. Given its rapid development in that period, the earliest likely release was 2000 or so; but 2002 is the earliest release I have data for.

Except the Intel C compiler, which is inappropriate for other reasons stated (i.e. it's shitty for non-Intel architectures). Still, given the argument--a GCC bug on x86/x86-64--and the twelve years of potential tuning for icc to support high-performance situations (i.e. embedded architecture, where 16% speed-up matters), broad compiler support is reasonable. It's not like LLVM just becoming useful last year and triggering a scramble to rebase onto CLANG.

2002 was the year of Gnome 2.0, of Linux entering the 2.5 development cycle (2.4 was state-of-the-art), of SuSE 8.0, of single-core CPUs and no AMD64. It was a long time ago, a different age, when journaling file systems were hip and new and Hans Reiser hadn't murdered Nina yet.

You see my point, though. Knowing your administrator log-ins isn't a never-happens situation. People get user lists all the time.

Why does TFA not mention we should maybe consider a little personal responsibility, eh? What is this, you let hackers take your identity? Maybe you should have refused to provide Sony with any information that would allow them to take out loans in your name!

Oh, you have an address, and a credit card number? No social security number? Well, I guess you can spend credit card money; and the owner can chargeback the money, freeze the card, and get a new one.

Sony wants your SSN, bank account details, and DOB? Dude fuck them. Go get Wii.

The banks gave people a loan without your Driver's ID, SSN, etc? Just with your name and address? Dude, I can put an address into city services and get the names of the residents and their property tax payment dates and amounts, and any bill due. Tell the judge the bank is retarded for not getting actual ID.

A true agile process has an incremental delivery schedule. Rather than building the full deliverable and delivering, it identifies milestones as deliverable product. For example: a waterfall process for building a car would intake requirements and output a car; an agile process would produce the platform for inspection by the customer, followed by the suspension system, the engine, the drive train, interior, and so on, in some useful order.

For a software product, this involves delivering partial functionality to the customer, who then examines it or even integrates it with his workflow. If there are issues, the functionality can be cheaply reworked; building on top of broken functionality could incur major rework when an issue is encountered, so this process actually reduces work.

Agile is not Rapid Application Development. RAD has consistently been shown to be a large joke. Agile software project management accomplishes what RAD could not.

If you can handle two afternoons' worth of reading, I will direct you here (technical) and here (soft skills). These cover stakeholder management, which is "working with people". Part of that is working with SMEs.

If you want to argue from an actual competent stance, you'll need to bother reading the (horrifically dry) PMBOK, fifth edition, particularly chapters 5 (scope management) and 10 (communications management). I found chapter 9 (human resource management) fascinating as well; chapter 11 (risk management) is a favorite of mine. Much of the content may sound like gibberish out of full context; reading the book from start to finish is like that, too, because they forward-reference things in the beginning (integration management immediately starts talking about the requirements traceability matrix, IIRC, which is 4 chapters later).

The short of it is: there are many ways to get information out of people. Meetings are a good method, and arranging good meetings is a skill. Meetings have three isolate purposes: to share information, to develop alternatives, and to make decisions. Never perform more than one in the same meeting; you will make horrific decisions.

To put this into perspective: We've worked closely with SMEs here, and done things wrong. Sometimes, meetings occur without the SMEs, and decisions are made contrary to what the SME recommended; others, the tech workers (network engineers, programmers, etc.) were consulted separately, and then excluded from decisionary meetings. The result is often people making decision and dropping impossible, poorly defined, or useless shit on you. Then you implement it, and they tell you it's wrong.

By the by, one of the most important features of a good meeting is it's short.