Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

Post reply on HN
Print view View original

161–170 of 435 posts

Re: The sad state of sysadmin in the age of containers (2015)

#161

Post by eropple »

mcguire wrote: post #148
eropple wrote: post #70

Earlier quoted context omitted.

Sure. All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade . And besides: if I can install bash, I can install something specifically better for whatever I'm doing instead.

Speaking as an (ex- (sort of)) sysadmin, " All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade. " Wrong question. A better one: Is it more clunky, opaque, and harder to work with than every other language that's appeared in the last decade? Because no one seems to agree on what is specifically better.

I disagree that it is the wrong question. "Every other language" doesn't matter because I don't value homogeneity and I think that homogeneity of programming language is a fool's errand. I am comfortable shipping production code in most of the languages in current use; in my estimation, none of the major build systems out there are as opaque or difficult to use correctly as make/shell.

(And I am what a current sysadmin would be if we did not call ourselves "devops engineers" now.)

Re: The sad state of sysadmin in the age of containers (2015)

#162

Post by Fritsdehacker »

Fritsdehacker wrote: post #90

I work for a hosting company and we host our own Openstack based public cloud. We have a hard demand that for production systems we build all binaries we use from source. We actually build these in docker and use that to deploy to production. What I'm trying to say is that the one doesn't exclude the other. And we actually use make quite extensively. I do however see the ops point, building from source hasn't gotten…

In the case of Openstack though, the community made it really easy to build docker containers from source.

Re: The sad state of sysadmin in the age of containers (2015)

#163

Post by bitwize »

colanderman wrote: post #104
jiveturkey wrote: post #87

Earlier quoted context omitted.

careful, your dinosaur scales are showing. make is so bad you need automake to manage it. there are much better tools. sadly, nothing LCD (least common denominator) so as to gain wide traction. That said, for anyone distributing software, shame on them for not packaging their custom build so as to be runnable via ‘make all’ (just using make to drive everything else).

I've used make for 15 years and never once needed automake. The company I'm currently at uses straight make without problems for a 500 kLOC code base of multiple languages, 3rd-party code, code generators, and unit tests. Our make code totals 1000 lines. I've seen plenty of messes using scons and ant, more so than I've seen with make. Make is a solid tool.

Across multiple operating systems (unix and windows)? Does it fetch and install 3rd party dependencies? Can a noob maintain the makefile without pulling their hair out?

Re: The sad state of sysadmin in the age of containers (2015)

#165

Post by user5994461 »

spiderjerusalem wrote: post #149
ex_amazon_sde wrote: post #63

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service. Believe me or not, most of the underlying infra does not run on the popular technology of the year. Far, far from it. That's why it works. Modern devops, with its million tools that break backward compatibility every month sometimes be…

What fascinates me about this is, and sorry for being morbid, but what happens when y'all die? Does knowledge of the lower levels of the stack go away with your generation, or will there be enough of us young ones picking the important stuff up?

Everyone will be running on AWS, Google Cloud and Azure, who know how to operate infra that doesn't crash all the time.

Re: The sad state of sysadmin in the age of containers (2015)

#166

Post by sudosteph »

loteck wrote: post #23

The clearest explanation of why this happens is at the end: Before, admins would try hard to prevent security holes, now they call themselves “devops” and happily introduce them to the network themselves! 1) The merging of devs into the sysadmin role was a product of: the work of sysadmins (particularly systems change control and security compliance) not being valued in our culture. 2) Devs delighted to be free of th…

I feel like there has always been a contingent of sysadmin / ops folks who preferred the "Better to ask for forgiveness than permission" model. They still hate when things break, (so not quite fans of developers with a "move fast and break things" philosophy) but they care more about big picture improvements and ease of upkeep than enforcing any particular process. Detecting problems and being able to roll back is typically more valuable than preventing mistakes in many cases. It may be somewhat driven by laziness, but it actually works out pretty well for collaborating with the fast-moving developer types. It also does depend on being in an environment that is tolerant to occasional mistakes or outages.

It makes sense that these types naturally gravitated towards the devops models. I'm really not sure where this leaves the more compliance-minded systems folks though.

Re: The sad state of sysadmin in the age of containers (2015)

#167

Post by eropple »

mst wrote: post #124
eropple wrote: post #19

Earlier quoted context omitted.

Makefiles aren't scary. But they're also not particularly good. I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). Shell plumbing is fine for informal and small-scale stuff, and I make my code conform if somebody down the line (who may be me) wants to get out their duct tape, but the world is more complex than what /bin/sh can see. Shell is the lowest common denominator. Expec…

> `JSON.parse` and a working subscript operator https://github.com/ingydotnet/json-bash source json.bash json='{"name":"Jason","friends":["Jimmy","Joe"]}' JSON.load "$json" joe=$(JSON.get /friends/1) JSON.put /friends/2 Jeff new_json=$(JSON.dump) It's still not as trivial as javascript, but "tooth-pullingly difficult" is a little unfair.

Again: sh, not bash. If I have the freedom to specify bash, I can specify something better than bash or sh.

Re: The sad state of sysadmin in the age of containers (2015)

#168

Post by shortusername »

eropple wrote: post #70
vlowther wrote: post #65

Earlier quoted context omitted.

Bash, but... > --show me its arrays declare -a > Show me hashes. declare -A > Show me sets. See above > Show me the basic building-block primitives of software, thing() { local localVar # Yes, it would be nice to have lexical scope as well as # dynamic scope, but... }

Sure. All of which are clunky, opaque, and harder to work with than any other language I have used in the last decade . And besides: if I can install bash, I can install something specifically better for whatever I'm doing instead.

Clunky is subjective -- I think we can probably agree that there are clunkier, more opaque, and harder to work with constructs in programming than a slightly different syntax for array declaration.

What are these build systems where you need to install Bash? Bash 4 was released in 2009: it's been in every major Linux distribution for at least two major versions, ditto for FreeBSD... heck, even Solaris ships with it now.

Re: The sad state of sysadmin in the age of containers (2015)

#169

Post by colanderman »

eropple wrote: post #19
megaman22 wrote: post #14

Earlier quoted context omitted.

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

Makefiles aren't scary. But they're also not particularly good. I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). Shell plumbing is fine for informal and small-scale stuff, and I make my code conform if somebody down the line (who may be me) wants to get out their duct tape, but the world is more complex than what /bin/sh can see. Shell is the lowest common denominator. Expec…

> I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever).

You can use Ruby in Make. I don't know Ruby but here's some Python:

  SHELL = python
  .SHELLFLAGS = -c
  .ONESHELL:
  .DELETE_ON_ERROR:

  foo.txt: bar.json
      import json
      with open('$
(Caveat: I've never actually tried this at scale.)

You can even use different languages for different recipes with per-recipe variable settings.

Re: The sad state of sysadmin in the age of containers (2015)

#170

Post by BurritoAlPastor »

cookiecaper wrote: post #123
agentultra wrote: post #78

Earlier quoted context omitted.

I recall the idea of "devops" from this book: https://landing.google.com/sre/book.html The stated goal of putting both systems administrators and software engineers on the same team is to reduce friction and increase communication. One of the worst, productivity-killing situations you can find yourself in when developing network software and services is caused by the traditional "old school" mentality of separating t…

The thing is that any separation in the roles in ineffective. Things shift around some if you embed an ops guy into the dev team directly, but it doesn't resolve the core problem. This applies to DBAs as well as ops or any other software-side segmentation as well. The core problem is that there are "ops guys" and "dev guys". That creates conflicting incentives, even within the same team. It creates tension and a dyna…

> But your core team can't tolerate being segmented out by component/implementation detail.

And yet tolerate it will, because it is somewhat impossible to hire a team composed entirely of people who are each experienced and competent in writing and designing frontends, writing and architecting backends, deploying and maintaining whatever backing services you've using, build and release engineering, Linux, networking, etc. And what are junior developers supposed to do?

Post reply on HN