Live data from Hacker News

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

vitavonni.de

311–320 of 435 posts

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

#311
post #264

Earlier quoted context omitted.

+1 for Ansible from me. Of all the tools, I first heard of Puppet first and so I'm assuming it was first on scene? From my limited experience, it seems Puppet is most widely used tool because of that reason. Not necessarily the best of the bunch, but first on the scene. Considering the effort required to roll it out, I am assuming whatever is deployed first will stay as the tool of choice. I've tried out Puppet, Salt…

I first heard of Puppet first and so I'm assuming it was first on scene? CFEngine was first, it's based on a kind of maths called "promise theory" and it solved the problem of you had many different kinds of Unix owned by many different groups and had to have a consistent way of saying "all machines belonging to group X need to have user Y and package Z" and it would abstract away the slightly differing syntax betwee…

> it's based on a kind of maths called "promise theory"

Promise theory is not math, despite its name. It doesn't predict anything, it doesn't explain any phenomena. It's an architectural approach. Brilliant, led to a really great software (CFEngine), but it's not "maths".

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

#312
post #108

Earlier quoted context omitted.

I've written a makefile from scratch. My challenge to you: I want a makefile that has 20 third party dependencies and can be built on osx, linux, and windows. I can do this within an hour with gradle, ant, or maven. The ecosystem doesn't exist for this in make, and anything I could come up with to make it possible would end up being a tool that would look like automake and the monstrosity that it entails.

That's a bit unfair, because make relies on the underlying system capabilities much more than Java does, and Windows' just isn't up to snuff. But for the other platforms, autotools definitely can do what you ask.

> But for the other platforms, autotools definitely can do what you ask

Ugg... autotools. Yeah, lets use what feel like build tools created way back in the 60's or something. Sure they "work" for some value of "work" but oh boy are they ugly and nasty. Good luck hiring anybody under the age of 40 who is gonna be willing to work on such a clunky old tool.

There is a reason why the world is moving to build systems that replace the Make toolchain.

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

#313

As a "major theme", the author takes: > Consider for example Hadoop. Nobody seems to know how to build Hadoop from scratch. It’s an incredible mess of dependencies, version requirements and build tools. And as the major introduction to the blog post: > I’m not complaining about old-school sysadmins. They know how to keep systems running, manage update and upgrade paths. Huh? Old-school sysadmins know how to keep syst…

I think the logic is, if we didn't rely on Containers and prebuilt VM's, Hadoop had to be easier to build to be useful.

That's like saying, "If we didn't invent the internet, we would have never had privacy issues". OK, so if we didn't rely on containers - would hadoop have had a perfect set of packages for every distribution? Let's say that the packages for Arch linux were broken. What next?

That's the whole problem with the article. It takes a problem (building Hadoop was bad), correlates it to a completely different tool (because we have docker, hadoop build scripts are bad), and goes on to rant about everything else.

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

#314
post #299

Earlier quoted context omitted.

My real issue is the constant wheel-making impulse, that leaves us with a shattered landscape of people tripping and falling over busted-ass and abandoned wheels. I have a JavaScript front-end project that uses three different package managers, and four different make-analog tools, plus some batch files sprinkled on top to orchestrate the common use cases of this monstrosity. Nothing that we are doing here is that co…

I’ve wasted enough time tinkering with gulp, grunt and webpack to sympathize

> I’ve wasted enough time tinkering with gulp, grunt and webpack to sympathize

And yet, those tools fill a need that would be very hard to replicate with the toolchains that came before it. Good luck doing half of what gulp / webpack do from, say, a Makefile.

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

#315
post #230

Earlier quoted context omitted.

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 (som…

CFengine, at least version 3, was probably the furthest away from string manipulation (and I was given the impression that text file content manipulation was considered a bad idea with it). What killed it was promise theory, which is actually a great theory and works quite well but made writing the bundles painfully hard and also hard to maintain. Also during the early days of v3 it was probably lacking a ton of esse…

I make my living as a CFEngine consultant. CFEngine runs every 5 minutes (it's lightweight enough to do that). The evolution was: CFEngine 1 ran once a day; CFEngine 2 ran once an hour; CFEngine 3 runs every 5 minutes. Self-healing infrastructure.

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

#316
post #311
post #264

Earlier quoted context omitted.

I first heard of Puppet first and so I'm assuming it was first on scene? CFEngine was first, it's based on a kind of maths called "promise theory" and it solved the problem of you had many different kinds of Unix owned by many different groups and had to have a consistent way of saying "all machines belonging to group X need to have user Y and package Z" and it would abstract away the slightly differing syntax betwee…

> it's based on a kind of maths called "promise theory" Promise theory is not math, despite its name. It doesn't predict anything, it doesn't explain any phenomena. It's an architectural approach. Brilliant, led to a really great software (CFEngine), but it's not "maths".

Basic concepts of promise theory (10 minute video by Mark Burgess who came up with it): https://www.youtube.com/watch?v=2TPsB5WuZgk

2014 introductory article: https://www.linuxjournal.com/content/promise-theory—what-it

Basic book on the subject: https://www.amazon.com/Thinking-Promises-Designing-Systems-C...

It's not "maths" like arithmentic but it's "maths" like graph theory:

Promise Theory, in the context of information science, is a model of voluntary cooperation between individual, autonomous actors or agents who publish their intentions to one another in the form of promises. It is a form of labelled graph theory, describing discrete networks of agents joined by the unilateral promises they make.

https://en.wikipedia.org/wiki/Promise_theory

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

#317
post #262

Earlier quoted context omitted.

It can reshape itself, and it most definitely understand network protocols It really, really can't! That quote about the Internet interpreting censorship as damage and routing around it? Or the one about information "wanting" to be free? Taken wildly out of context.

Then what about routing protocols such as RIP, OSPF, etc? I'm sorry, but I don't know what quotes you're referring to.

Routing protocols are how computers communicate network admin instructions to each other really really fast.

They're still just tools wielded by humans, even at a distance. Even today.

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

#318
post #264

Earlier quoted context omitted.

+1 for Ansible from me. Of all the tools, I first heard of Puppet first and so I'm assuming it was first on scene? From my limited experience, it seems Puppet is most widely used tool because of that reason. Not necessarily the best of the bunch, but first on the scene. Considering the effort required to roll it out, I am assuming whatever is deployed first will stay as the tool of choice. I've tried out Puppet, Salt…

I first heard of Puppet first and so I'm assuming it was first on scene? CFEngine was first, it's based on a kind of maths called "promise theory" and it solved the problem of you had many different kinds of Unix owned by many different groups and had to have a consistent way of saying "all machines belonging to group X need to have user Y and package Z" and it would abstract away the slightly differing syntax betwee…

Actually the sequence was CFEngine, Puppet, Chef.

See http://verticalsysadmin.com/blog/relative-origins-of-cfengin...

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

#319
post #294

Earlier quoted context omitted.

It's arbitrary when you claim there are no sensible divisions in software. I think your entire lengthy argument is a sort of elaborate fantasy about how much better the world would be if everyone was just like you or at least, just like you imagine yourself to be. It's fun but not a particularly realistic or constructive way to look at the world.

> It's arbitrary when you claim there are no sensible divisions in software. It's about the fungibility of the problem space. I don't know how you expect your core team to make reasonable decisions about the tradeoffs if they a) don't understand more than one of the platform elements; and/or b) don't have any responsibility or accountability for the tradeoffs that get made, because now it's another segment's problem.…

I don't know how you expect your core team to make reasonable decisions [...]

That's how most everything is made, not just software. In the case of software, Fred Brooks added an essay titled "Parnas was right, and I was wrong" in the 20th anniversary edition of The Mythical Man Month about this topic. Itself published over 20 years ago.

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

#320
post #129

Earlier quoted context omitted.

Did you read all those lines yourself? Did you even confirm checksums matched before running them? I think that's the parent's point. You can build from source, but how do you trust the source? Is it any more egregious to trust a prebuilt binary from a specific website than it is the raw source? If you can't trust the binary being hosted by the author/caretaker, can you really trust the source being hosted or maintai…

I don't think his point is so much about the source as it is about updating N containers. For instance, say there's a known libssl bug. Can you tell how many of your containers are running that version of libssl? And how do they get updated?

1) List the number of containers running pre-fix versions of images of libssl-using server software. 2) Bump the version of the images you're using as a base for your server images to post-libssl-fix and push.
Post reply on HN