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

vitavonni.de

Post reply on HN
Print view View original

101–110 of 466 posts

Re: The sad state of sysadmin in the age of containers

#101

Post by dschiptsov »

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from

  ./configure --prefix=/xxxx && make && make -s install
with or without following

  chroot /yyyy
The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java/etc installation with all packages and its dependencies in your [home] project directory) solves no real problem, only pushes it to the next guy (what they call devops).

Some idiots even advocating to have a whole snapshot of an OS attached to your "hello world", and even to make it what they call "purely functional" or even "monadic" (why not, of someone pays for that).

Unfortunately, there is no way to ignore complexity of versions and package dependencies or easily pushing it to "devops". Creating a zillion of "container images" with just your "reproducible development environment" or a whole "OS snapshot" just multiplies entities without a necessity.

Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do.

btw, the GNU autotools (which gives us ./configure) is somewhat evolved real-world solution - you have to explicitly check each version of each API both at the compile (build) time and refuse to build in case of unsatisfied dependencies and at the install time (and package manager must refuse to install if case of mismatch). This is the only way back to sanity, however "painful" it is.

Re: The sad state of sysadmin in the age of containers

#102

Post by mike_hearn »

mercurial wrote: post #81

I love a good rant as much as the next guy, but unfortunately, rants are rarely actionable. > Maven, ivy and sbt are the go-to tools for having your system download unsigned binary data from the internet and run it on your computer. The root of the problem is that out of the total number of libraries available in language X, only a small subset is packaged in Debian/RHEL. This may be more egregious with large, Java e…

Maven packages aren't actually unsigned either. They're downloaded over SSL and to get into Maven Central you need to sign with a GPG key.

The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. That's the fault of the web of trust (more accurately called "handful of strings of trust").

Debian/Red Hat code signing doesn't prove very much either. All it proves is that the package came from Debian or Red Hat. But did they modify the software along the way, doing some kind of MITM attack on the upstream developers? Quite possibly! At least with Maven you don't have that problem.

Re: The sad state of sysadmin in the age of containers

#103

Post by mercurial »

highmastdon wrote: post #53
skratlo wrote: post #37

Earlier quoted context omitted.

Same for "framework" which is: I have no idea what I'm doing

Same goes for 'abstraction', it hides the essence of what is happening. Therefore every abstraction is evil.

Hopefully this is sarcasm. Code without abstraction can also very efficiently hide what is happening by having a disastrous signal-to-noise ratio, combined with all the potential for errors you get when repeating the same pattern many times.

Re: The sad state of sysadmin in the age of containers

#106

Post by davexunit »

kibibu wrote: post #75
rlpb wrote: post #61

Earlier quoted context omitted.

There's a huge difference. > Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed. This is certainly still true for Debian - not being a…

Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or whatever you used to download/distribute the code)

This is where reproducible builds [0] come in. We can trust our binaries much more if the same build inputs yield the same build output.

Building on that, could we find a fixed point where the OS builds the exact same bootstrap binaries that were used to bootstrap the OS to begin with? [1] That would give us even more confidence that the binaries we're using are as they should be. Interesting place for experimentation.

[0] https://reproducible.debian.net/reproducible.html [1] https://gnu.org/software/guix/manual/html_node/Bootstrapping...

Re: The sad state of sysadmin in the age of containers

#107

Post by willstepp »

highmastdon wrote: post #53
skratlo wrote: post #37

Earlier quoted context omitted.

Same for "framework" which is: I have no idea what I'm doing

Same goes for 'abstraction', it hides the essence of what is happening. Therefore every abstraction is evil.

Abstractions are necessary to write software, unless you speak binary code, so calling them evil is a bit hyperbolic. My point is at some level you have to trust the abstractions of a system or else nothing would get done. That doesn't mean you shouldn't have a conceptual understanding of the lower levels, but they aren't evil!

Re: The sad state of sysadmin in the age of containers

#108

Post by mike_hearn »

geocar wrote: post #25
lmm wrote: post #11

make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…

Makefiles don't really enter into it and getting software signed by the developer isn't that valuable or useful. The value of debian is not that they package (or repackage) everything into deb files but that they resolve versioning and dependancy conflicts, slip security fixes into old versions of libraries (when newer version break API/ABI), and make it possible to integrate completely disparate software into a syst…

Debian has a terrible track record. Just look at the OpenSSL/Valgrind disaster. As a former upstream developer myself (on the Wine project), all Linux distros found unique ways to mangle and break our software but Debian and derived distros were by far the worst. We simply refused to do tech support for users who had installed Wine from their distribution the level of brokenness was so high.

You may feel that developers are some kind of loose cannons who don't care about quality and Debian is some kind of gold standard. From the other side of the fence, we do care about the quality of our software and Debian is a disaster zone in which people without sufficient competence routinely patch packages and break them. I specifically ask people not to package my software these days to avoid being sucked back into that world.

As a sysadmin you shouldn't even be running Maven. It's a build tool. The moment you're running it you're being a developer, not a sysadmin. If there are bugs or deficiencies in the software you're trying to run go talk to upstream and get them fixed, don't blame the build tool for not being Debian enough.

Re: The sad state of sysadmin in the age of containers

#109

Post by mrweasel »

__mp wrote: post #24

As an ex sysadmin I really like the container infrastructure. Manage the whole configuration on the main machine with puppet and deploy the blackbox applications (everything ruby and java related) with docker/rocket.

It's nice to have the option. Containers are awesome for many things/projects, but sometime you just want to run the damn application on a server of your choice, without any container stuff.

I can't remember what the application was, but I've seen an application where the only installation instructions where for Docker. That's just plain silly.

My concern with containers is that the wrong people will use it. There is a ton of software out there with just barely runs and make all kinds of assumption about it's environment. I fear that rather than design better, more correct software, these people/companies will start packing up their development environments as containers (more or else) and just ship those. Of cause that's no reason to discourage the use of containers, we just need to be critical of what is inside them.

Post reply on HN