I don't think the seasoned admins will argue that systemd is bad because it doesn't follow history, they'll argue it's bad because it doesn't follow well established design principles.

(I'd also dispute that there really were a large percentage of Network engineeres who really disliked Ethernet. I heard some complaints 20 years ago from people who did real-time process control systems, but that's quite a small nitch.)

I've been doing Linux admin in some fashion or another for 20+ years, so in many ways I'm part of the "old guard". The argument about small being better, making programs that do one thing well, etc is a good design element that's worked for years. At the same time I've also often been bitten by the problem of having to port "yet-another-shell-script-for distributiion-X" problem that seems like it should have a more standardized way of doing things. So from a replacing init-scripts perspective, I can see the appeal.

I'm not heavily involved in administration like I once was, so I don't have experience with systemd as of yet. (My systems run Ubuntu or Debian, no RHEL7). With that said, the monolithic design and trying to do everything sounds like a major design flaw to me.

Your question is far too generalized. You don't mention what your product is, what your firm does, or what the risks you're trying to protect from. Nobody can give you any meaninful advice unless you provide real details. What is it you're afraid of exposing? What's the IP you're afraid of diluting? Is your company a 100 person shop, or a 10,000 person shop? It matters.

Those risks may be illusory, depending on what this code is. I've had a few project I'd like to release as OSS, but there's zero IP dilution and zero risk of exposing anything. Despite what people tend to think, code isn't a commodity. The specifics matter quite a bit. The only answers you're going to get with the information you provided are very generalized useless ones.

C has been replaced with C++, C# and Java.

In some cases, yes. But that doesn't mean C is dead or dying. It's just not as dominant as it once was. Languages are like living things, they compete with other languages for space. There's still a TON of applications written in C. The linux kernel is a major example. C isn't as dominant as it once was, but that's a natural development of diversity. Greater diversity doesn't mean the death of what was once dominant, only that what was once dominant fills a smaller niche.

You just listed 3 buzzwords. None of them are "big ideas", they're vague concepts, of which a subset of the vague concepts are good ideas.

Java is a programming language. Can you expound on what exactly Java is missing to embrace whatever it is you think is good about them?

Java is becoming the new COBOL.

I'd like to be the first to say... huh? I'm sure Java will become a legacy language some day, but hipsters don't really define much of anything. Hipsters are against anything that's popular (because popularity by definition isn't hip), and go for the obscure things. That's why PBR became popular. It's not good, but among the younger set microbrews are very popular, so a hipster has to go for something unpopular to distinguish themselves from what's popular.

20 years ago people used to say that about C. C is dying, C is going to be replaced, etc, etc. Didn't happen. By popularity C has a lot more competition, but it's alive and well and not going away. People hate COBOL because it was a badly designed language. If anything is the new COBOL, it's PHP. I've known several PHP programmers, and many of them have switched to another language not because of a lack of jobs, but because they hate the language. I'm not old enough to have been around for the COBOL era, but I'd guess it was the same then.

The death of a language starts when developers leave it in droves for something else. I don't see that happeneing for Java. Do you?

Sure, you're probbably right that documenting skills and coding skills are mostly orthogonal to one another. But my point is more that the documenting at the very end is the wrong approach. Producing documentation should be integral into the process, not an afterthought. That doesn't mean it has to be done by the same person, only that it's not the last thing you do, and has to be overcome with people feeling like they're asking "dumb questions"

The programmer you're referring to has a very narrow scope. Software development is big, and we don't all have the same problems. People are often very narrow in their view of the world, and assume THEIR view of the world and their problems are the only one that exists. Thus the C programmer who thinks that Java programmers are inferrior because they don't have to deal with memory management. (i.e. you don't feel our pain, so you're not one of us).

I can equally tell you that C programmers don't understand OO principles. If you don't do OO, that's fine. Just like if you don't need to deal with all the memory management issues, that's fine too.

Your programmer is just doing the same cultural bullshit that's been going on for decades "These kids these days aren't any good because they have/didn't-have BLAH-1. Back in MY day we had BLAH-2". 40 years ago (and outside of the software world) it was that doggone rock music.... "back in my day we appreciated Henry Miller, not these blasted Beatles and their long hair!"

People become attached to their view of the world and can't imagine it without it. This is the pitfall of age and experience.

The article says he won' be eligible for $2500-$3000. It's hardly worth it. Getting worldwide attention, and a good reputation for finding a major security vulnerability in a major website is worth a LOT more than $3000, especially when you've waited 60 days after disclosing it.

I'd say the bounty should be about 10x for major problems like this that are easily reproducible, and have a high impact.

Coders are too busy writing code and making changes to what they write to give time for accurate documentation to be written....
  In the age of using github as a distribution and code changes between today and tomorrow, the documentation is suddenly invalid before it's written. Even then, it requires a lot of stupid questions asked by the documentation staff to coders who think they have better things to do.

You've just described an extremely flawed development model. For some reason you can still get away with this with documentation since it's still thought of as not all that important and can be done last. People used to think of security in the same way (and some people still do this), but 20 years of people saying you have to bake security in at the start has resulted in nobody seriously considering doing that as a last step. But yet we still think of documentation this way, by and large.

The point being, if you want documentation, it needs to be part of the process, and part of the job. If a developer changes a major part of how people interact with the software, everyone in the project should know about that and it shouldn't just be this big surprise at the end.

I think what you've discovered is that you can't put up ads for something similar to what people are searching for, thinking they'll consider buying your product instead. Searching for somethng is a very narrow task. "Is THAT what I want?... no. Is THAAAT what I want?". It's not really a time when people are open to new ideas.

So I don't think Google adswords is a "scam". If it was, Google would have been out of business long ago. What you need to realize about marketing is you need to get the consumer at the right TIME. There's periods of time when people are far more open to something new and interesting. But it's most certainly not when they're looking for something specific.

Shit, if people actually DO that, I'd put out ads specifically so competitors would go try to click on them. Why? Because every minute they spend clicking on ads is a minute they aren't doing any work trying to compete with me.

1) This service will survive for all of two weeks tops - it's him against the collective power of Google. I put my money on Google.

And if that were the matchup, I'd agree. But remember Google is an enormous company, with many problems. This is a minor little annoying fly buzzing around the office. If the fly lies low, it can survive for quite a while. If it bites the wrong person, or becomes too annoying, it's going to get swatted rather quickly.

So far it looks like the fly has managed to lie low enough to not be much of a concern (The article mentions the service has been around for 2 1/2 years).

>("Getting the job done" does not, and has never required being abusive to others. Getting the job done while being abusive is not proof that being abusive is required or even was part of, "getting the job done.")

Hmmm.. I'm going to disagree here. Being verbally abusive is a technique to demand change in an organization. We all like to think leaders all command respect and everyone just follows them because they're the leader. Bullshit. One technique, employed by MANY leaders is being a total fucking asshole, at least part of the time. You think anyone would be talking about this GCC bullshit (and if what Torvalds says is right, it's really completely fucked up, and not excusable) if Linus just put a nice, politely worded request to just fix shit? I don't think so. But even if he was nice and polite, and got the thing fixed, there's little or no consequence for the fuckup, so it can happen again. If you're coding GCC, maybe you might at least sub-consciously think "boy, I better not release utter shit, or I'll catch some serious shit from that asshole Linus Torvalds... what a cock gobbling asshole that Torvalds is".

This idea you have that everything can work in a nice polite society where everyone has mutual respect for each other can work sometimes, in limited capacities. But the norm is for assholes like Linus to sometimes throw shit-fits, and others to work in fear of having a shit-fit thrown at them sometimes.

Is that the ONLY way to run an organization? Probably not, but as another thread points out, it's a common pattern of effective leaders.

The post was about comparing a woman looking at a mans strength, to a man looking at a linebackers strength. It wasn't about men being stronger than women, which is obvious.

The claim, at least as someone else could find out, was totally false. So yes, I think scrutinizing peoples claims is extremely important.

Can you please post those stats, and a source? When people make claims like this, it's important to back them up and they be scrutinized.

And if you're reply is "look them up yourself", well, I'm not the one making the claim. It's your responsibility to provide evidence.