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

171–180 of 435 posts

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

#171

Post by digi_owl »

notyourday wrote: post #122
kazen44 wrote: post #75

Earlier quoted context omitted.

> Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out. Here we have another fundemental "problem" between dev and ops. The inherent friction because of different areas of concern. Dev's want to build fa…

Put devs on 24x7 escalation above your level-1 ("Is it actually broken?") NOC. Developer attitude would change immediately.

Sadly i have seen far too many devs go "you are holding it wrong"...

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

#172

Post by eropple »

shortusername wrote: post #168
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.

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 n…

You're right, there are clunkier, more opaque, and harder to work with constructs in programming. Like `sh` arguments. And like `sh` quotebarf.

And Busybox is commonplace. Systems that include Busybox usually do not include `bash`. And so, for my purposes, if I can specify `bash`, I can also specify, say, Ruby, which--while by no means perfect--makes life much, much easier.

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

#173

Post by gaius »

digi_owl wrote: post #147
gmfawcett wrote: post #107

Earlier quoted context omitted.

Some were, I guess, but hardly all of them. The Linux kernel is built with Make, for example.

There are been several attempts at introducing a new build system, but they have been all shot down over introducing dependencies.

If it ain't broke don't fix it!

How many features could people have implemented or bugs fixed or general progress made instead of obsessing over tooling?

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

#174

Post by untog »

mancerayder wrote: post #102
untog wrote: post #83

Earlier quoted context omitted.

Not really? A lot of build tools are chosen specifically to make the build process more reliable and understandable. For example, build tools like Maven handle dependency management, which is hugely beneficial in ensuring your builds are consistent and work the same in different environments. Makefiles are shell scripts.

Not taking sides here but you picked a bad example. Makefiles specifically handle dependency management, but designed from a compiled language perspective. Make sure you build this .so before you build this bin, or that this directory exists, and so forth.

That's fair, but it still reinforces the point: Makefiles are great from a compiled language perspective. Other build tools are better from other perspectives. It isn't wrong to choose a tool depending on your needs!

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

#175

Post by mcguire »

untog wrote: post #69
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…

> But I just don't understand why we have to have 47 half-built over-complicated build systems > Everyone repeat after me. I don't mean to pick on you specifically here because this attitude comes up a lot. In short, a lot of people are doing a thing, a thing that you aren't familiar with, and your gut reaction is to say "everyone: stop doing that, and do what I say!". Wait a second and consider that maybe there is a…

"Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out."

Have you considered that perhaps the previous commentor is familiar with the other tools? Or perhaps that the large number of developers have streamlined their particular workflows for their particular use case and have not considered the flexibility needed for other cases? Or perhaps that there is a cost associated simply with having 47 different build systems?

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

#176

Post by user5994461 »

brightball wrote: post #160
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…

Would be interested to get your opinion on Puppet/Ansible/Chef/CFEngine/SaltStack

CFEngine is basic text manipulation, it's not comparable to the rest.

Puppet and Chef was the first generation. I wouldn't recommend. All the companies and people I know using Chef migrated away from it after many disasters. Nowadays, it's only mentioned in interviews to find out if candidates have real world fire fighting experiences.

Ansible is good. Used that for managing hundreds of machines at multiple jobs (some who migrated from Chef). It's been bought by RedHat, it's well maintained and I think it will have the brightest long term future.

Not sure about SaltStack. Never had the opportunity to try. I'd be a bit worried though on the long term prospect because I don't think they have much backing or user base.

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

#177

Post by eropple »

colanderman wrote: post #169
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…

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

Ha, that's a neat trick! Trouble is, for either Python or Ruby it becomes tricky due to stuff like dependency management. You'll have to `bundle exec make` to get sane library paths for Ruby or `pipenv run` for Python, etcetera etcetera.

At that point I think you might as well just use a language-native one.

Great pull, though.

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

#178

Post by FraKtus »

wwweston wrote: post #150

Perhaps interestingly, I've had some similar complaints about package managers like homebrew. I've noticed over the last decade that a certain level of knowledge about building from source seems harder to find via search or engaging in a community forum/chat. The assumption is often that everyone will be using the package manager (I'd say that's especially true on macOS, but it might be an artifact of me spending mor…

I never installer homebrew on any mac I develop. When you see all the possibilities to customize projects, it's just ridiculous to want to build something with a one-liner and expect it will take thousand of decisions for you.

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

#179

Post by Animats »

If you thought having to deal with old COBOL programs was a problem, it gets much worse. When there are 10 year old containers in production, and the parts to rebuild them are long gone, then you have a real problem.

There's a reason that Google has internal systems which can and do rebuild everything from source.

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

#180

Post by mcguire »

untog wrote: post #83
kazen44 wrote: post #75

Earlier quoted context omitted.

> Wait a second and consider that maybe there is a reason why this incredibly large number of developers are using these tools. That perhaps they evaluated various different options and decided that what they are using is more suitable than make. Maybe you could find out. Here we have another fundemental "problem" between dev and ops. The inherent friction because of different areas of concern. Dev's want to build fa…

Not really? A lot of build tools are chosen specifically to make the build process more reliable and understandable. For example, build tools like Maven handle dependency management, which is hugely beneficial in ensuring your builds are consistent and work the same in different environments. Makefiles are shell scripts.

"Maven handle dependency management"

https://maven.apache.org/pom.html#Dependency_Version_Require...

Don't forget to go the extra mile with your dependency versioning to ensure you actually get repeatable builds.

Post reply on HN