For real business purposes, though, you'd be bonkers to accept bitcoins.
Bonkers like Newegg, and Dish Network? Both of which accept bitcoin.
This is exactly what I'm talking about. Yes, it has worked for years, and that's why you like it. You (we?) are now that "old generation" that I was referring to, and I'm not about to become a grumpy old admin.
Some things are basic to design. The design philosophy of Unix/Linux has nothing to do with technology, and everything to do with human beings. Technology changes, human being stay the same. I'm a developer now, and that same design philosophy is how people create good programs. It's the same human element at work.
Simple designs are really quite lauded across all of design. It's not just software. Complexity is what you get when you don't have any other choice. It's not really an old fashioned value at all. Einstein said "Everything should be as simple as possible, but no simpler".
Worked just fine. I also worked for vendor J, who used one big binary: rpd handles just about every routing protocol you can imagine. Is J bad and is R good? According to the market, J is doing very well, while R has been acquired and assimilated by a another company.
Well, that might be OK. From an admin perspective, what's the difference since routing is really routing. One binary is easy to deal with. If they architected the software in a sane way and devided the big binary into sane objects, it might even be easy to code as well. It makes sense because networking is networking. I just don't see the same thing being true for system services. Starting up services is ENTIRELY different from mounting a share. Why would you group those two functions together?
But really though you're judging the goodness/badness from the wrong angle. Which company is successful has zero to do with which is a better design. Success has as much to do with marketing, price, luck, branding, and golf outings as it does with the design. Deisgn is just a small part of success.
The question should be, which did YOU find easier to deal with, and which one do the software developers find easier to code and add new features to.
a) the ubiquitous availability of information is a relatively new thing. Public libraries didn't even really exist until the latter 19th/E20th centuries. The internet is less than a generation old.
b) governments and power structures have controlled such information throughout the span of human history.
I'm not even 100% convinced that the ideal of universal access to information is an unalloyed good.
Nothing is pure good. Fortunately that's not the standard for good. Unfettered access to the Internet merely has to be better than government censorship of the internet. That's the real choice, not internet vs no internet. Unfettered access to information is one the founding principles of Democracy. Western nations have embraced this idea for around 200 years. Developing nations that aren't particularly democratic or are newly democratic are having to come to grips with this fact.
A country where the Government gets to censor what we see and hear can't function as a democracy. Democracy relies on the citizens being able to freely communicate. That can't happen under censorship. In the US the founding fathers reconized this because they were subject to a government that tried to control them. That's why the created the first amendment, and why other countries equally recongized this basic fact of a functioning democracy.
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).