You are so full of it.

Facebook most definitely does not use a single distro in production that uses systemd.

Neither does Netflix.

You don't work out here. I do. It's not that big of an industry when it comes to systems administration and DevOps out here. Don't make claims that anyone with a LinkedIn worth a damn can debunk with a few messages.

What's my side? Argue against what I've said, thanks. Where have I said anything about monolithic being a problem? I've been very clear about the gripes I have about it.

You don't administer systems. You don't design the internals of system architecture. I can't even tell from your LinkedIn (we're third degree contacts) that you've touched a Linux system in your life. You've been management for over a decade. You seriously don't think the same infrastructure that some shops you namedrop are -the- solution for every use case, especially out here, do you? Especially when they don't even use what you're advocating for?

You're not an engineer. You're an integrator. I'm sure you're great at it. But stick to your expertise and don't try to lecture engineers when you're out of your depth there. Thanks.

If you think platform setups are the most complex server installations out there, I've got some oceanfront property in Denver I'd like to sell you.

I still haven't seen anything that makes me want to use it on a server. There's a clear use case on desktop. Nothing you've posted changes that, or even bothers to make a case for it. It's all buzzword salad from you.

Yeah, that user tried the same thing with me as well a few day back.

While linking me to Red Hat's PaaS offering.

I've got the same complaints about systemd, namely that I either have to find engineering man-hours to convert all of the existing supporting infrastructure I have to a systemd world, or find engineering man-hours to maintain an in-house distro. Even if systemd is a clear upgrade over every single component it has its tentacles in (for the sake of argument), it isn't enough to justify refactoring a working infrastructure on a DevOps team that's already understaffed as it is.

I'm sure Red Hat has a Solutions Architect that's happy to have me pay tens-to-hundreds of thousands just to get my infrastructure back up to where it was prior to systemd, though!

It doesn't speed things up. It serves two purposes -- optics to bring it more customers, and ensure there's the optimal amount of orders going through the system for as long as possible. If you're hungry, and you see a long drive-through line, it may dissuade you from stopping at the restaurant. Two lanes merging into one hides some of that.

I've not had good experiences with Heroku.

Beyond that, if I want PaaS functionality, I've got Docker and/or Elastic Beanstalk for the simpler applications. PaaS is fine if you're running a simple app backend or a medium-traffic frontend. But a data warehouse isn't going there. Log analysis isn't happening there, as much as I'd ike to outsource that, but the expense is ridiculous, My time series metrics and monitoring isn't going there. Sensitive PII isn't going up there.

Those options (sans Heroku) are great if you're trying to get a proof-of-concept off the ground, or you've got high enough margins going that you can eat the pain when the cost of outsourcing so much of your infrastructure catches up with you. Thise "good problems to have" aren't so good to have as people think.

Tell you what. You go do that with RHEL/CentOS 7 or with the expected package set for Jessie, and tell me what you come back with.

In reality, if you think that process is any sort of worthwhile for large server installations, then you work for a small shop handling bullshit traffic or you're riding your coworker's coattails while you screw around with hobbyist installations -- and that's if you work as a server/infrastructure engineer at all.

Let's say that even works right now to give me a working box. I lead an infrastructure team, boss. My ass gets fired or my stock becomes worthless if I'm not working on a 5-10 year outlook plan. That might mean I'll have to go with a systemd-based distro, which means internal tooling and software chains need to retested, if not outright rewritten, much of the automation in place, along with additional monitoring on the new attack surface that systemd opens up.

The OS is supposed to the be base of this stack that's dumb as hell and a stable foundation for the software that does the actual work on top of it, and provides as few attack vectors as possible. The major distributions seem to be tossing away that role away, long with embedded systems, in favor or trying to beat iOS and Android on mobile and Windows and OSX on the desktop.

Noble goals, but that ain't what butters the bread, not what's kept Linux kicking for this long.

As someone who does spin up a metric fuckload of instances in the cloud (or more specifically, has his monitoring system trigger a set of scripts to do it based on site and API traffic), I can guarantee you that you are full of shit and haven't actually had to do those things as part of your career thus far.

I -love- new technology that makes my life easier. I'm a big fan of the Vagrant -> Docker -> Deploy workflow for apps where that flexibility outweighs the overhead costs. There's now way I could manage my cluster in a sane matter without the central config management apps.

Systemd ain't the way. At best, it's a large attack surface and single point of failure. At worst, it's an anti-pattern.

Why do I want the extra overhead of that? Yes, it's tiny. Tiny adds up at scale.

I'm all for having systemd available as a choice, or even having a "desktop" spin that defaults to it. While I can't speak for everyone, I don't mind the concept of systemd, because there are use cases where the market has decided that they value speed over stability -- see mobile apps, desktops, etc.

I don't want it as the init system for my servers, though. Even if I think it's cool for the init system, I sure as hell don't want it handling login, messaging, logging, acting as a superserver, etc. My metal boxes reboot when a security patch requires it. The virtual instances boot the first time and never again. My log aggregator wants plaintext logs. I already have supervisord or monit keeping an eye on my daemon processes. Systemd could be $DEITY's gift to UNIX, and it still wouldn't go on an existing cluster of mine because any gains from it are offset in the engineer man-hours I'd have to pay out to thoroughly test all of the software I run against, convert all of our in-house tooling and software to it, etc.

Then, as the holder of the patent, you have the option to not license the patent to them if the monetary offer for a license is not sufficient. If that blows up the hiring process, consider yourself lucky that you fund out the sort of assholes you'd be working for prior to signing the paperwork and starting the gig. If you've got patents under your belt, it's not like you'll be hurting for work, since it pretty much acts as a credential signifying that you'll do good work.

...not your patent portfolio.

If they want the use of your patented IP, they can license the technology or buy the rights to the IP from you.

All I know is that if I were amoral and running a corporation in the US of A, I'd be cheating every damn way possible. It's fairly obvious to even the most casual observer that as long as I don't fuck with the stock market, I can fuck with anything and anyone else and get a comparative slap on the wrist for a fine and pocket the rest of the illegally acquired scratch.

And employers wonder why I leave for the next best thing all the time.

Same goes for the third-party recruiter as well. They are not on your side when it comes to getting you the highest pay possible, despite what they tell you, for the same exact reason. They (or their firm) get payment based on a percentage of your first year's salary, and while you might want to negotiate for that extra $10k, they will try to talk you out of it because that only gets them chump change and threatens to blow up the deal.

If a student has the drive to tinker and learn, most public schools here offer enough of a basic education to get them going in the right direction.

Those are the people that FaceGoog don't want to pay unless they failed at a startup a few times and got absorbed via acqui-hire.

I've gotten recruiter emails (from internal recruiters, which usually aren't nearly as bad as the third-party types) that contained job descriptions looking for 3+ years of Swift experience.

Mind you, there are 3 or 4 people that meet that standard, but I don't think they're getting poached away from Apple anytime soon, nor do they want to make shitty mobile apps rather than develop the language itself.