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

61–70 of 435 posts

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

#61

Post by Joeri »

megaman22 wrote: post #14
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

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…

Many of these are tools which download code dependencies from package repositories and integrate them into a codebase or build. Make doesn’t do that, even configure doesn’t do that.

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

#62

Post by djsumdog »

megaman22 wrote: post #14
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

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…

Well you use the right tool for the job. I hope to god you're not using a Makefile for a Java or Scala project. You better be using Gradle, SBT or Maven.

If you're building in Elixir, I hope you're using Mix and not a Makefile. If you're building in Rust, I hope you're using Cargo, or some other Rust specific build tool.

And Makefiles do get stupid complicated when you need things portable and to work on Linux, Mac and FreeBSD; or allow them to have optional dependencies. That's why we have autoconf and all that ./configure && make && make install craziness.

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

#63

Post by ex_amazon_sde »

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 becomes the running joke at lunch.

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

#64

Post by trhway »

repolfx wrote: post #36
dagss wrote: post #24

Earlier quoted context omitted.

I wish there was something like an updated Make, a tool that works for everything but updated to 2018. For instance Make works based on timestamps and therefore works very poorly together with git. Switch to another branch and you can get weird effects based on what files were updated and not and often trigger needless rebuilds. And everyone uses git these days. GNU Make, just using hashes instead of timestamps, woul…

That'd require hashing every file on every run to figure out what changed. Not a good idea. There are modern tools that work for many things. Gradle supports native compilation these days as well as any JVM language. Bazel supports compiling many kinds of languages, and there's still scons.

>That'd require hashing every file on every run to figure out what changed. Not a good idea.

it is using time stamp to check whether to hash to check for changes.

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

#65

Post by vlowther »

eropple wrote: post #50
GalacticDomin8r wrote: post #40

Earlier quoted context omitted.

> but the world is more complex than what /bin/sh can see That is blatantly false, but I get the premise behind it. Writing and maintaining complex stuff in bourne or bash is not fun or easy. I always use bourne until certain level of complexity or awkwardness is reached. It's pretty easy to write and dead simple to troubleshoot.

Blatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software , because build pipelines are software . It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the…

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

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

#66

Post by lbenes »

dagss wrote: post #24
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 wish there was something like an updated Make, a tool that works for everything but updated to 2018. For instance Make works based on timestamps and therefore works very poorly together with git. Switch to another branch and you can get weird effects based on what files were updated and not and often trigger needless rebuilds. And everyone uses git these days. GNU Make, just using hashes instead of timestamps, woul…

> GNU Make, just using hashes instead of timestamps

Sounds like you're describing make on a system with ccashe installed. Hashing incurs a significant performance hit. The first build with ccashe is 20% slower than building without it[1]. Your modern make would likely be slower for people who just build something from source once and aren't doing incremental development.

https://ccache.samba.org/performance.html

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

#68

Post by eropple »

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.

I'm pretty comfortable in both, but I'll pretty regularly use Ruby via Pry for stuff I know I can do in bash. It's easier to write, much much much easier to write correctly, and it presents a unified interface to other developers.

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

#69

Post by untog »

megaman22 wrote: post #14
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

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

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

#70

Post by eropple »

vlowther wrote: post #65
eropple wrote: post #50

Earlier quoted context omitted.

Blatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software , because build pipelines are software . It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the…

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.

Post reply on HN