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

Post by mcguire » Wed, May 16, 2018, 5:39 PM UTC

ebiester wrote: post #41

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…

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.

Post by endymi0n » Wed, May 16, 2018, 5:39 PM UTC

Post by usrusr » Wed, May 16, 2018, 5:40 PM UTC

Kalium wrote: post #39

kingbirdy wrote: post #17

Earlier quoted context omitted.

Systems besides make are used because they offer advantages make doesn't

For many of those systems, the biggest advantage is often that tasks are written in the language of the application. A lot of the Rake tasks I've encountered in my career would have been easier to write in bash. Not a majority, but a sizable minority. I suspect that in many cases, the gain was that the authors were more comfortable in Ruby than in bash.

Post by unethical_ban » Wed, May 16, 2018, 5:40 PM UTC

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…

Post by nickpsecurity » Wed, May 16, 2018, 5:41 PM UTC

kazinator wrote: post #120

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

Make is only bad under the Autotools mess. Every build-related struggle in an open-source project that uses Autotools can be traced to Autotools, not to make. Autotools wasn't invented to overcome deficiencies in make, but deficiencies in C portability across Unix flavors. Those deficiencies are greatly diminished today, both by POSIX standardization, and there being fewer viable surviving Unix variants that anyone c…