Humble Bundle gives a cut to the publishers, just like any other store. They just have better PR.
Beyond that, if you think people aren't wise to the fact that gaming journalism is in it thick with gaming companies, and that there's quite a bit of personnel passing back and forth, and weren't without GamerGate, then you simply aren't paying attention. What's the number one non-industry place of employment for game designer prior an industry gig? Game journalist. Between layoffs, what do game designers do? Write about games.
I couldn't care less whether or not GamerGate is misogynistic or not, trolling or not, or what-have-you. I think it's hilarious a bunch of people identifying as "core/hardcore" gamers are bitching about something that any gamer worth a damn already knew -- don't trust publishers that don't provide a demo, gaming reviews have grade inflation worse than public school, and review sites and the game industry trade personnel and promotion opportunities.
Stop whining like an entitled brat. If you want something, like good games, honest publishers, and trustworthy media, do it yourself. After all, it must be a successful business model with all those GGers out there, and there's an obvious market opportunity.
Or there's not, and even the non-SJWs are laughing at your dumbass for pointing out the obvious and claiming that this whole charade is for great justice and to improve an industry that thinks you're a joke because you still pay them their money.
Either way, we know what people like you, who are lacking the skills, ambition, and expertise (other than that as a herded consumer lapping at the trough) will do -- nothing of consequence while bleating for someone else to do something.
But at the end of the day, money talks and bullshit walks, and if you keep reading the sites you hate and buying games from companies whose business practices you dislike, and you don't bother to compete with them, you've made it known exactly what you're supporting, despite whatever speech you've Twittergrammed to @nobodycaresifyourebuyingwhatyourebitchingabout.
That doesn't mean they are bad people. You just have to understand their motivations while you are dealing with them.
Yep. I try to scare them off first at this point by stating my salary and benefit requirements up front -- if Hired.com did one thing right, it's removing some of the taboo of talking pay before the phone screen -- which is top 10% for the area.
Plus, now that I'm hiring for my team, I've had conversations with those good ones from the other side of the situation. Makes it even easier to know who I'm going to message first if I ever decide to look again.
...that have matched me to some awesome roles I've had. Those ones are worth their weight in gold.
The best signs I've seen that a recruiter is quality are:
They don't call during the workday
They don't spam you with every gig they have available that you match a keyword search for
They don't push back on when high salary requirements are communicated
Those would seem to be three pretty simple signs, but it's amazing how many recruiters fail those tests, ESPECIALLY the third sign, which is arguably the most important.
See, with open floor plans abound, calling me during the workday assures that I'm not going to get to talk to you (and everyone suspects the person stepping away from his desk all the time to take calls of looking for a new gig). The spray-and-pray recruiting method tells me that you don't give a crap about actually mapping people to jobs, you just want as many "sales" as possible.
Finally, any recruiter that pushes back on pay requirements is afraid of losing their entire commission by having what seems to be a good match go up in flames over the candidate going for top dollar -- after all, they don't have an incentive to get you the best possible salary they can (even though they'l all say that), but they have the incentive to get you to accept an offer as fast as possible to bring in a constant stream of commissions. Negotiations falling apart over, say, asking for $160,000/yr rather than settling for $150,000/yr means that if they're seeing a 5 percent commission on first year's salary, means they're risking $7,500 to push for your extra ten grand, which only gets them another $500 if successful.
Up until the Goldwater Republicans fiscal conservatives wrested control of the party from the law-and-order business Republicans in the late 70s, the Republicans were actually very, very responsible -- at least, they implemented policy with responsibility in mind, rather than governing with the intent to make government not work. They believed in spending on infrastructure, and making sure the budget was something resembling balanced, not just as small as possible.
Even 1994's GOP is to the left of where it is today.
AS far as personality cults go, though, Ted Cruz scares the crap out of me. He strikes me as the sort that'd make Joe McCarthy look like a reasonable man.
MighyYar's right, and this is coming from a bleeding heart California liberal that is not happy the GOP is going to get rewarded for its antics with increased power in DC, and is also really not happy that Silicon Valley (also known as where I work and live) is starting to tilt to the right.
The current difference between the two parties right now is pretty solely on wedge issues. They have the same monetary policy, the same foreign policy, neither party is realistic about tax policy on the middle class (it needs to be higher, along with the high earners), neither party wants to bust the cap on Social Security and Medicare (while I appreciate the extra bucks at the end of the year, I think those programs need it more than me), etc.
For all the hype about the "core differences" in the 2012 election, Mr. Romney and Mr. Obama were so close on the political compass that it was a John Jackson vs. Jack Johnson situation.
I happen to feel that the social issues are important enough for the Democratic party to be the clear choice, but to get back to MightyYar's point -- Silicon Valley is very business-driven, and CA law would preserve nearly all protections that the Republicans could take away at the federal level (barring the PPACA) as far social politics are concerned. From a Silicon Valley business perspective, both parties are roughly the same when considering the direct effect they'd have, and even more so when you realize that FWD.US and other H1-B visa supporters are realizing that they only way they'll get those increased H1-Bs they want is to get some sort of immigration reform done, even if that means supporting an odious Republican policy rather than a Democratic solution that isn't showing any signs of life.
Not to mention that most Republicans in the Bay Area would be considered Democrats down in Bakersfield or Orange County.
You need to use systemd.automount and/or have it managed by an/etc/nfstab entry to ensure that a remote filesystem is available to include it as a dependency for bringing up the service rather than just ensuring autofs is running as a dependency, which may or may not have actually mounted the filesystem in question.
Only despair lies down the path of trying to make those two coexist.
My LinkedIn's in the homepage link (hint: I write code for a living).
Post yours, and quit whining because a sysadmin wouldn't push your broke-ass code to production.
All it takes is one buggy release, or a junior admin making the sort of bonehead error that we all made while earning our stripes.
$DEITY forbid that you want to remount your NFS shares because you're cutting over to a snapmirror of your Netapp to perform maintenance (or have the vendor perform it). Pardon my language, but systemd absolutely shits the bed when that happens.
These are edge cases, to be fair, but they're edge cases that affect many common enterprise-grade setups, and I'd hope that it's common sense to expect that an application-level edge case won't crater my systems. Like another poster had said earlier, I really wish they'd split off systemctl from the rest of it. systemctl's a sweet piece of software that does handle services much, much better than previously. It's the rest of the bundle that turns systemd from a plus into a liability.
If I'm at a shop that has 5 9s SLAs, I don't want a superserver crash to take out my whole OS. If supervisord or inetd craters and does so in a fashion that doesn't allow it to come back up without intervention, I want the option of running in a degraded state by bringing up the supervised processes via init.d until I can either troubleshoot the superserver, or chalk it up to gremlins and bring up a replacement instance or spare box.
If there's one fatal flaw in systemd's design, it's that system designs based around systemd assumes that systemd will never crash. The best software out there crashes or locks up to the point of being a de facto crash, so as a systems architect, I need to have failsafes to keep me running in a degraded state so I don't fail my SLAs, and systemd tells me "Don't worry, I won't fail!".
RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.
If they stick with CentOS, sure. That's not a given at this point, and it's definitely not likely to happen until systemd is more ready for primetime. It's why I took issue with your 2018 time frame: systemd is going to be the way forward, whether people like it or not. The issue is that it's -not- ready for primetime, or to be the default init system for 95% of the market. Because of this, the OS upgrade road, which is always difficult to begin with, is going to be slower than usual, because no sane VP of Engineering or CIO is going to risk their ass on being the first one to do a wide deployment without a compelling reason to do so, and there's not a compelling reason to do so.
I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.
I'm pretty confident that the production engineers over there know what they're working with.
I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.
Fair enough, but the hardware certification is a marketing point Red Hat sells, not anything useful for day to day configs. Incompatible hardware very quickly becomes compatible when you have Facebook money to throw at the problem. I'll be happy to tell you stories of vendor chats I had when working at Apple, and how the threat of losing seven-and-eight figure contracts quickly turns unsupported use cases into supported use cases, including the backporting of kernel patches for a kernel that wasn't the vendor's preferred one.
Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating.
My explanation is why it's unsuitable for servers. Just because you can run servers with it doesn't mean it's anywhere near the best tool for the job, and it introduces more headaches than it solves. Can that change? Of course. Given that the vendors are shoving it down our throats and I'll probably have to upgrade to it within the next few years, I'm not just advocating against it for now, I'm doing what I can to make sure that it gets shored up.
You picked Facebook from my list:
a) They run CentOS. Cent OS is switching
b) They get their hardware certified by RedHat who is the single largest proponent of systemd.
I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.
Hey, it'd be nice if I could do less infrastructure. But when we've tried to switch over to platforms, it hasn't gone well. Our Chef setup was handled by Opscode until it became unreliable and their suggestion was to run our own. We've tried a few vendors for platforms, and they can't handle our traffic patterns when a petition goes viral.
I'm not comfortable going into more detail about our infrastructure on a public forum (unsurprisingly, we get targeted a lot by parties getting sunlight shone on them), but you're welcome to email me at jpierce at change dot org and I can go into the troubles we've had relating to vendors and external platforms.
Facebook had been on a CentOS variant running on hardware certified by RedHat Labs for years. RHEL is systemd. Whether they have switched yet or not I don't know, but by 2018 or earlier they will be on systemd. If it isn't in production, it isn't in production yet.
RHEL 6 (and its CentOS variants) are upstart, not systemd. Just admit you were wrong about them using it. You forget to mention that it's in testing alongside other, non-systemd Linux variants.
Also, Facebook's been rolling its own hardware for quite a while now, dude.
I don't work out there. Absolutely not. But PaaS is much bigger than the Valley. The ideas and technologies developed for DevOps are being deployed much more broadly
The point is that if you knew engineers working at those companies out here, you could have found out what they were actually running on by asking rather than making claims you can't back up.
Maybe time to use your real name if you are going to play that game.
Hi. I'm Jeff. My LinkedIn is the Homepage link next to my name. My apologies for not having it there previously.
No you haven't. You've said that you have to change stuff you do for an existing infrastructure. That's about it. Lots of hyperbole and nonsense claims about desktop.
Well, we've already established that you've been lax about doing your research before making claims.
I don't administer systems. I most certainly do design the internals of system architectures. What do you think happens when you sell a solution that you put together random parts without thinking about how they work? I've done the specialist job when you knew every little detail of a system, and I went through large scale changes before as an engineer. I remember when I was an engineer people like you gripping about the change over from DECnet to IP and how the sky would fall. I was intimately involved in the migration of working systems from Metacode to Postscript and AFP. The systems are far better today for progress.
From my experience, given that for many of my jobs I've been the guy hired to clean up after a "systems integrator" with a cost sheet full of buzzwords and marketing woo came in and sold some magic beans to bigwigs who didn't listen to their engineers, your line of work tends to over-engineer a "solution", under-calculate cost of operations, and end up leaving a company with severe vendor lock-in disease and an engineering staff with a new solution that's outside of the team's core expertise, which leads to staff churn, high retraining costs for those that do stay, and dissatisfaction all around.
When was the last time you actually acted as an implementor on one of your plans?
If you're one of the rare good ones out there, then please accept my most heartfelt apologies. But thus far, I don't see it. Your argument is "It must be fine because vendors use it and my consulting firm deploys it!" and that size of installation equals complexity of installation. You haven't provided a technical argument in favor of systemd on the server in the slightest.
As far as progress is concerned, systems are better than before because of it. However, just because something is new and shiny doesn't mean it's progress. There was rapid adoption of Puppet and Chef because those tools massively increased productivity and added flexibility to cluster design. Docker has taken off because the cost in system performance is outweighed by the man-hours savings in testing on/for multiple platforms, and because they successfully implemented a Linux equivalent to Solaris zones and/or BSD jails.
I have, Unix since 1988, Linux since 1995. I've also touched a wide range of the big box Unixes, zSeries, iSeries and VMS. Which gives some perspective on having seen styles of solutions for process management over the year
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.
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.
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.
Slashdot Mirror
Humble Bundle gives a cut to the publishers, just like any other store. They just have better PR.
Beyond that, if you think people aren't wise to the fact that gaming journalism is in it thick with gaming companies, and that there's quite a bit of personnel passing back and forth, and weren't without GamerGate, then you simply aren't paying attention. What's the number one non-industry place of employment for game designer prior an industry gig? Game journalist. Between layoffs, what do game designers do? Write about games.
I couldn't care less whether or not GamerGate is misogynistic or not, trolling or not, or what-have-you. I think it's hilarious a bunch of people identifying as "core/hardcore" gamers are bitching about something that any gamer worth a damn already knew -- don't trust publishers that don't provide a demo, gaming reviews have grade inflation worse than public school, and review sites and the game industry trade personnel and promotion opportunities.
Stop whining like an entitled brat. If you want something, like good games, honest publishers, and trustworthy media, do it yourself. After all, it must be a successful business model with all those GGers out there, and there's an obvious market opportunity.
Or there's not, and even the non-SJWs are laughing at your dumbass for pointing out the obvious and claiming that this whole charade is for great justice and to improve an industry that thinks you're a joke because you still pay them their money.
Either way, we know what people like you, who are lacking the skills, ambition, and expertise (other than that as a herded consumer lapping at the trough) will do -- nothing of consequence while bleating for someone else to do something.
You can speak about whatever you like.
But at the end of the day, money talks and bullshit walks, and if you keep reading the sites you hate and buying games from companies whose business practices you dislike, and you don't bother to compete with them, you've made it known exactly what you're supporting, despite whatever speech you've Twittergrammed to @nobodycaresifyourebuyingwhatyourebitchingabout.
So don't read the sites and don't give them clicks.
Don't pre-order the games and buy on day one if they're that terrible -- wait for patch 1 or the Steam discount.
If you think you can do better, start your own gaming site with reviews and such, or start your own gaming company.
If you can't, well, beggars can't be choosers, my friend.
Yep. I try to scare them off first at this point by stating my salary and benefit requirements up front -- if Hired.com did one thing right, it's removing some of the taboo of talking pay before the phone screen -- which is top 10% for the area.
Plus, now that I'm hiring for my team, I've had conversations with those good ones from the other side of the situation. Makes it even easier to know who I'm going to message first if I ever decide to look again.
The best signs I've seen that a recruiter is quality are:
They don't call during the workday
They don't spam you with every gig they have available that you match a keyword search for
They don't push back on when high salary requirements are communicated
Those would seem to be three pretty simple signs, but it's amazing how many recruiters fail those tests, ESPECIALLY the third sign, which is arguably the most important.
See, with open floor plans abound, calling me during the workday assures that I'm not going to get to talk to you (and everyone suspects the person stepping away from his desk all the time to take calls of looking for a new gig). The spray-and-pray recruiting method tells me that you don't give a crap about actually mapping people to jobs, you just want as many "sales" as possible.
Finally, any recruiter that pushes back on pay requirements is afraid of losing their entire commission by having what seems to be a good match go up in flames over the candidate going for top dollar -- after all, they don't have an incentive to get you the best possible salary they can (even though they'l all say that), but they have the incentive to get you to accept an offer as fast as possible to bring in a constant stream of commissions. Negotiations falling apart over, say, asking for $160,000/yr rather than settling for $150,000/yr means that if they're seeing a 5 percent commission on first year's salary, means they're risking $7,500 to push for your extra ten grand, which only gets them another $500 if successful.
Up until the Goldwater Republicans fiscal conservatives wrested control of the party from the law-and-order business Republicans in the late 70s, the Republicans were actually very, very responsible -- at least, they implemented policy with responsibility in mind, rather than governing with the intent to make government not work. They believed in spending on infrastructure, and making sure the budget was something resembling balanced, not just as small as possible.
Even 1994's GOP is to the left of where it is today.
AS far as personality cults go, though, Ted Cruz scares the crap out of me. He strikes me as the sort that'd make Joe McCarthy look like a reasonable man.
MighyYar's right, and this is coming from a bleeding heart California liberal that is not happy the GOP is going to get rewarded for its antics with increased power in DC, and is also really not happy that Silicon Valley (also known as where I work and live) is starting to tilt to the right.
The current difference between the two parties right now is pretty solely on wedge issues. They have the same monetary policy, the same foreign policy, neither party is realistic about tax policy on the middle class (it needs to be higher, along with the high earners), neither party wants to bust the cap on Social Security and Medicare (while I appreciate the extra bucks at the end of the year, I think those programs need it more than me), etc.
For all the hype about the "core differences" in the 2012 election, Mr. Romney and Mr. Obama were so close on the political compass that it was a John Jackson vs. Jack Johnson situation.
I happen to feel that the social issues are important enough for the Democratic party to be the clear choice, but to get back to MightyYar's point -- Silicon Valley is very business-driven, and CA law would preserve nearly all protections that the Republicans could take away at the federal level (barring the PPACA) as far social politics are concerned. From a Silicon Valley business perspective, both parties are roughly the same when considering the direct effect they'd have, and even more so when you realize that FWD.US and other H1-B visa supporters are realizing that they only way they'll get those increased H1-Bs they want is to get some sort of immigration reform done, even if that means supporting an odious Republican policy rather than a Democratic solution that isn't showing any signs of life.
Not to mention that most Republicans in the Bay Area would be considered Democrats down in Bakersfield or Orange County.
You need to use systemd.automount and/or have it managed by an /etc/nfstab entry to ensure that a remote filesystem is available to include it as a dependency for bringing up the service rather than just ensuring autofs is running as a dependency, which may or may not have actually mounted the filesystem in question.
Only despair lies down the path of trying to make those two coexist.
My LinkedIn's in the homepage link (hint: I write code for a living). Post yours, and quit whining because a sysadmin wouldn't push your broke-ass code to production.
All it takes is one buggy release, or a junior admin making the sort of bonehead error that we all made while earning our stripes.
$DEITY forbid that you want to remount your NFS shares because you're cutting over to a snapmirror of your Netapp to perform maintenance (or have the vendor perform it). Pardon my language, but systemd absolutely shits the bed when that happens.
These are edge cases, to be fair, but they're edge cases that affect many common enterprise-grade setups, and I'd hope that it's common sense to expect that an application-level edge case won't crater my systems. Like another poster had said earlier, I really wish they'd split off systemctl from the rest of it. systemctl's a sweet piece of software that does handle services much, much better than previously. It's the rest of the bundle that turns systemd from a plus into a liability.
My counter to that:
If I'm at a shop that has 5 9s SLAs, I don't want a superserver crash to take out my whole OS. If supervisord or inetd craters and does so in a fashion that doesn't allow it to come back up without intervention, I want the option of running in a degraded state by bringing up the supervised processes via init.d until I can either troubleshoot the superserver, or chalk it up to gremlins and bring up a replacement instance or spare box.
If there's one fatal flaw in systemd's design, it's that system designs based around systemd assumes that systemd will never crash. The best software out there crashes or locks up to the point of being a de facto crash, so as a systems architect, I need to have failsafes to keep me running in a degraded state so I don't fail my SLAs, and systemd tells me "Don't worry, I won't fail!".
Real name for said user is available by clicking the Homepage link.
Fail.
RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.
If they stick with CentOS, sure. That's not a given at this point, and it's definitely not likely to happen until systemd is more ready for primetime. It's why I took issue with your 2018 time frame: systemd is going to be the way forward, whether people like it or not. The issue is that it's -not- ready for primetime, or to be the default init system for 95% of the market. Because of this, the OS upgrade road, which is always difficult to begin with, is going to be slower than usual, because no sane VP of Engineering or CIO is going to risk their ass on being the first one to do a wide deployment without a compelling reason to do so, and there's not a compelling reason to do so.
I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.
I'm pretty confident that the production engineers over there know what they're working with.
I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.
Fair enough, but the hardware certification is a marketing point Red Hat sells, not anything useful for day to day configs. Incompatible hardware very quickly becomes compatible when you have Facebook money to throw at the problem. I'll be happy to tell you stories of vendor chats I had when working at Apple, and how the threat of losing seven-and-eight figure contracts quickly turns unsupported use cases into supported use cases, including the backporting of kernel patches for a kernel that wasn't the vendor's preferred one.
Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating.
My explanation is why it's unsuitable for servers. Just because you can run servers with it doesn't mean it's anywhere near the best tool for the job, and it introduces more headaches than it solves. Can that change? Of course. Given that the vendors are shoving it down our throats and I'll probably have to upgrade to it within the next few years, I'm not just advocating against it for now, I'm doing what I can to make sure that it gets shored up.
You picked Facebook from my list:
a) They run CentOS. Cent OS is switching b) They get their hardware certified by RedHat who is the single largest proponent of systemd.
I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.
Hey, it'd be nice if I could do less infrastructure. But when we've tried to switch over to platforms, it hasn't gone well. Our Chef setup was handled by Opscode until it became unreliable and their suggestion was to run our own. We've tried a few vendors for platforms, and they can't handle our traffic patterns when a petition goes viral.
I'm not comfortable going into more detail about our infrastructure on a public forum (unsurprisingly, we get targeted a lot by parties getting sunlight shone on them), but you're welcome to email me at jpierce at change dot org and I can go into the troubles we've had relating to vendors and external platforms.
Facebook had been on a CentOS variant running on hardware certified by RedHat Labs for years. RHEL is systemd. Whether they have switched yet or not I don't know, but by 2018 or earlier they will be on systemd. If it isn't in production, it isn't in production yet.
RHEL 6 (and its CentOS variants) are upstart, not systemd. Just admit you were wrong about them using it. You forget to mention that it's in testing alongside other, non-systemd Linux variants.
Also, Facebook's been rolling its own hardware for quite a while now, dude.
I don't work out there. Absolutely not. But PaaS is much bigger than the Valley. The ideas and technologies developed for DevOps are being deployed much more broadly
The point is that if you knew engineers working at those companies out here, you could have found out what they were actually running on by asking rather than making claims you can't back up.
Maybe time to use your real name if you are going to play that game.
Hi. I'm Jeff. My LinkedIn is the Homepage link next to my name. My apologies for not having it there previously.
No you haven't. You've said that you have to change stuff you do for an existing infrastructure. That's about it. Lots of hyperbole and nonsense claims about desktop.
Well, we've already established that you've been lax about doing your research before making claims.
I don't administer systems. I most certainly do design the internals of system architectures. What do you think happens when you sell a solution that you put together random parts without thinking about how they work? I've done the specialist job when you knew every little detail of a system, and I went through large scale changes before as an engineer. I remember when I was an engineer people like you gripping about the change over from DECnet to IP and how the sky would fall. I was intimately involved in the migration of working systems from Metacode to Postscript and AFP. The systems are far better today for progress.
From my experience, given that for many of my jobs I've been the guy hired to clean up after a "systems integrator" with a cost sheet full of buzzwords and marketing woo came in and sold some magic beans to bigwigs who didn't listen to their engineers, your line of work tends to over-engineer a "solution", under-calculate cost of operations, and end up leaving a company with severe vendor lock-in disease and an engineering staff with a new solution that's outside of the team's core expertise, which leads to staff churn, high retraining costs for those that do stay, and dissatisfaction all around.
When was the last time you actually acted as an implementor on one of your plans?
If you're one of the rare good ones out there, then please accept my most heartfelt apologies. But thus far, I don't see it. Your argument is "It must be fine because vendors use it and my consulting firm deploys it!" and that size of installation equals complexity of installation. You haven't provided a technical argument in favor of systemd on the server in the slightest.
As far as progress is concerned, systems are better than before because of it. However, just because something is new and shiny doesn't mean it's progress. There was rapid adoption of Puppet and Chef because those tools massively increased productivity and added flexibility to cluster design. Docker has taken off because the cost in system performance is outweighed by the man-hours savings in testing on/for multiple platforms, and because they successfully implemented a Linux equivalent to Solaris zones and/or BSD jails.
I have, Unix since 1988, Linux since 1995. I've also touched a wide range of the big box Unixes, zSeries, iSeries and VMS. Which gives some perspective on having seen styles of solutions for process management over the year
I fail at reply.
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.