The fact is, many open source software projects provide their own Dockerfile (and in many cases, images). Using these is akin to downloading and deploying a release tarball.
The sad state of sysadmin in the age of containers (2015)
101–110 of 435 posts
Re: The sad state of sysadmin in the age of containers (2015)
#102Earlier 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.
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.
Re: The sad state of sysadmin in the age of containers (2015)
#103Earlier quoted context omitted.
There are over 2.9 million lines of code in Apache Hadoop alone, not counting dependencies. If you can't trust Apache, you can't trust Hadoop, regardless of whether or not you can compile it yourself.
There are nearly 10 million lines of code in libreoffice, and yet I can and have built it from source just by typing: 1. $ git clone git://anongit.freedesktop.org/libreoffice/core 2. $ apt-get build-dep libreoffice 3. $ ./autogen.sh && make Just because something has a large code base doesn't mean we shouldn't be able to build it from source ourselves.
I think the point isn't that we can build from source, but why. If its a huge codebase you can't independently audit that source code. So ultimately if you compile it or the organization making it doesn't matter for purposes of trusting that code not to be malicious.
Re: The sad state of sysadmin in the age of containers (2015)
#104Earlier 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…
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.
Re: The sad state of sysadmin in the age of containers (2015)
#105The 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 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…
> Don't build your containers from public, un-trusted images! Build your own images. Run your own, protected, registry. You still have all of the compliance and validation necessary and you don't end up debugging failed builds because one machine out of a thousand is running on some minor shared library version not supported by your software.
You have just lost all the speed to production advantages of containers.
Re: The sad state of sysadmin in the age of containers (2015)
#106This has been my complaint from day one. Instead of docker have something like ports or pkgsrc and simply create tools that simplify sandboxing, like cgexec, a google kafel -> ebpf filter then all the package manager has to do is well package. Docker IMO is a mudball of concerns that need to be separated.
Re: The sad state of sysadmin in the age of containers (2015)
#107Earlier quoted context omitted.
But they're also not particularly good. Million+ line codebases got errm made with make. In my experience people most sneering at it have far lesser demands on their tool...
Million+ line codebases were written entirely in COBOL. The world advances.
Some were, I guess, but hardly all of them. The Linux kernel is built with Make, for example.
Re: The sad state of sysadmin in the age of containers (2015)
#108Earlier 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.
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.
Re: The sad state of sysadmin in the age of containers (2015)
#109Earlier quoted context omitted.
But they're also not particularly good. Million+ line codebases got errm made with make. In my experience people most sneering at it have far lesser demands on their tool...
Million+ line codebases were written entirely in COBOL. The world advances.
It's weird that you use the word "advances" to refer to JavaScript-based build processes.
Re: The sad state of sysadmin in the age of containers (2015)
#110To bake a pie from scratch, first you must compile Hadoop.