Well, of course they would. And a line developer, at some point, may have to worry about their job being driven down to call center wages, especially as higher-level languages get easier and easier and cover more of the day-to-day computing needs of the industry and businesses as a whole.

But effective problem-solvers, no matter what their line of work, rarely need to worry about being underpaid. Even in technical support, which has been nearly, if not completely, commoditized to the point of being scripted at the lower tiers, if you're a crack troubleshooter that's specialized in a highly complicated system or software, you can command the same six-figure salary or better than I get as a senior/de facto lead infrastructure engineer.

The startups that are doing well are the ones paying for talent. Facebook, Google, etc. need swarms of maintenance coders and the like for established products, and those developers don't exactly need to be the top notch ones. They save the top notch ones for the new products, or for adding features to flagship products. Right now, I only really need to hire one or two more really senior people on infrastructure, and the rest of the slots I want to fill in with juniors so that myself and the other seniors on my team don't spend our (expensive) time in the weeds, while a junior that'll learn something from it can do it and get trained up to backfill one of us seniors when we head off to the next exciting project.

Well, middle-management has to justify themselves somehow.

I learned BASIC really early, but I never did anything more advanced than that until high school, and frankly, I didn't get any good at or enjoy coding until my 30s. I liked doing the systems side of the house better, because writing glue code and BASH scripts to make other people's tools all work together to run my systems was like playing with Legos to me.

Once coding had a practical use for me to build tools that I needed to solve problems that I couldn't solve with a few shell scripts and cron jobs, it's amazing how much more I enjoyed doing it.

...in a systems or software engineer is one that's not taught, and that's the drive to tinker, to figure out why something does what it does.

Everything else -- programming languages, systems design, best practices and processes, etc. -- can be taught to someone with the drive to tinker and learn. Really, corporations should be doing less of the "let's teach the world to code" crap, and do more convincing people with that hacker spirit to apply their skills and drive to computer engineering, rather than quant finance or law or other career paths taken up by people with that drive.

Completely understandable. This is why I did it for you once I realized my error!

That would matter if overflow traffic from AWS wasn't also similarly throttled. It was even originally done so clumsily that for customers of some ISPs (Verizon included), they were throttled while trying to work from home if their kit was based in EC2 or their static content hosted in S3/Cloudfront.

Amazingly enough, business class service didn't have this issue.

I think anyone that's had to deal with Cogent understands that they're a pack of assholes who have no business being a Tier 1 network provider, and I'm not absolving them of their role in this shitshow, but they're actually the least evil of the network providers in this situation. Given the choice between delivering their customers what they want (Netflix wasn't charging for the cache boxes they ended up paying the large last-mile ISPs to host) and fucking over their customers, the large last-mile ISPs decided to fuck over their customers, despite the fact that Netflix traffic wrecking their shit was an implicit admission of the oversubscription problem they've had since the rise of video on the 'Net.

Damn liberal arts majors...

You do know that both HBO and Netflix use AWS, right? It has nothing to do with the hosts. It has to do with your ISP throttling the competition for their in-house streaming video service.

Actually, it's more like it's okay for her boyfriend to beat off to her photo, but not anyone else, and I find that to be a completely reasonable argument. I'm sorry that you weren't raised to have respect for other people and their belongings. It really is that simple. You are a respectful, respectable person, or you aren't.

Having read this before, I was about to blast you for copypasta without attribution.

Then I looked at your username, looked at where I saw this, and realized that mseeger is probably Martin Seeger.

So, rather than blasting you for plagiarizing yourself, here's a thank you instead!

What parent said. Online societal ethics still have a long way to go before they catch up with meatspace ones.

Given that roughly half of Snapchat's userbase is between the ages of 13-17, you very likely do not want to subscribe to this if you value your freedom.

Exactly. Hey, if Red Hat thinks that Fedora/RHEL for desktop is going to pay their bills instead of people in my shoes, good for them. I'll go to a vendor that wants my dollars.

Because unlike the people touting systemd and wanting it for the desktop, laptop, or mobile, I'm actually paying for this shit.

There are zero enterprise-level installations of Fedora on the infrastructure side of the house. RedHat's internal servers aren't taking a million or so requests per second, nor does their infrastructure buildout hit the 5 digit+ range of servers and instances. Someone's collection of LAMP stack instances behind an ELB is not representative of what I have to deal with every day.

As far as the rest of it? Systemd tries to solve problems that don't need to be solved at the enterprise level. If I don't like to use xinetd as a superserver, I can use supervisord. In reality, I'm using neither because I have monit scripts in place to manage server processes I care about.

I don't manage my system configuration at the system level -- that's what Chef or Puppet or Ansible or Salt does for me. I template it out and let central config management keep the servers in sync. At the scale I work at, the rule "do it once by hand, script it if you have to do it more than once" breaks down, because if I'm doing something once on one server in production, I'm probably wrong.

This is why in the eyes of infrastructure engineers with an installation large enough to justify the use of config management software, systemd offers nothing except a headache for large, existing installations. Meanwhile, I can very safely state that certain vendors are going to be very, very unhappy when they start losing seven-figure+ contracts over this, or only get them under the requirement that they continue to support and patch the last good non-systemd release.

Either that, or it'll finally let me convince my boss that it's time to start rolling our own distro and I can use that saved money to hire some engineers to maintain it.

All your posts are doing is showing that you haven't had to deal with a large-scale installation in your career. That's fine -- there's plenty of rockstar engineers in startups and medium-scale shops. Just don't try to tell me what's good for me when you haven't experienced it for yourself.

Please look up "not being a dick when being wrong." In the case of a natural monopoly, they absolutely do get fat and sloppy, but still manage to be able to deliver the service at better rates/higher efficiency than a competitor, hence the need for nationalization or profit capping/other form of regulation. This is not a controversial concept. Plenty of books on it, scholarly articles, etc. The controversy comes in ideologues arguing whether government should regulate them or not, not over whether or not they exist. Asking for the proof on this is the economics equivalent of asking for a proof that the sky is blue. Don't be surprised when you're told "Look up, yo."