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."

Seems to me that's the largest reason it's being pushed, and then got expanded to be everything from your syslogger to your messaging bus to your replacement for supervisord/xinetd, and so on and so forth. The secondary reason appears to have something to do with GUI application operation, which as an infrastructure engineer, I don't give a crap about. In the short term, it means I'm probably going to work on migrating to Amazon Linux in the short term, since it's the most RHEL-like distro not moving to systemd, while keeping an eye on how systemd fares at the enterprise level. If it becomes the new normal and gets some heavy, real-world testing on it and holds up, I'll switch to it then since it'll end up being the new normal on the enterprise. If it blows up under real-world conditions and threat vectors, it'll be someone else's installation that eats shit, not mine.

It's less about rewriting scripts (from my understanding, systemd does a bang-up job of supporting init scripts unmodified), and more about the major distributions in use on the server side of the house (RedHat and its derivatives, Debian and its derivates) making it the New Way Forward. It may very well be an improvement over the current init system. For desktops and mobile where boot time matters significantly more than stability, it should be the new way forward.

But on the server side, nobody gives a crap about boot time. If you're on physical hardware, it should be happening rarely. If you're using a cloud architecture, it should happen all of once per instance. To keep my log management installations working properly, I need to add the extra overhead layer of having systemd's binary logs reprocessed and forwarded to syslog. Not a big deal until you do the math and realize that an extra half percent of overhead is an extra box or instance needed per 200. I also ned to devote sysadmin or devops time to doing some thorough testing for stability.

This is all a very roundabout way of saying that it's unclear if systemd is an improvement for the server side of things, and that even if it is an improvement, it's not enough of one to be worth all of the resources needed in an enterprise-grade installation to justify switching to it, nor am I comfortable being an early adopter on anything other than my personal lab kit.

As far as the developer goes? He wrote software. It's not his fault that the project managers of the major distros have decided that shooting for the desktop and mobile is more important than supporting the server side people that have been paying their bills for decades. Be pissed at them for this.