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

181–190 of 324 posts

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

#181

Post by HorstG »

tetha wrote: post #160
HorstG wrote: post #120

Earlier quoted context omitted.

Agreed, up to a point: Ever tried to security-update a vendor-provided container which you should never touch because of the vendor's support and warranty conditions? And even if allowed to touch it, the mess that it usually is: app running as root in the container, stuff chmodded a+rwx -R, weird base distro, build script is just a wget, cp -R or "this binary magically appears from somewhere". With a helping of " onl…

But that's vendors, not containers. You can say exactly the same about vendors on a VM - applications running as root, bad passwords set, reboots impossible, patching impossible, backups... Or a virtual appliance. Or a third party application you installed and cannot upgrade due to a weird dependency on libc, or java, or a specific windows versions. Vendors like that are always a mess, no matter the technology. Conta…

Agreed. Most vendors supply an unholy mess of weird setup.exe, shellscript installers, omnibus packets or appliances as well, containers are not alone here.

Edit: To clarify, containers and VMs are somewhat special in that it is very easy to do the wrong thing, and that you get a lot of rope to hang yourself with. The application developer by. default takes responsibility for the whole OS stack (maybe except the kernel with containers) but usually doesn't handle it very well. Whereas with packages or even setup.exe, the default case in most IDEs and tools is to package very little, and only upon request (using omnibus e.g.) to include the whole shebang

edit2: the definition of 'vendor' of course includes a lot of OSS projects who are just as bad as most commercial vendors in this regard, as exemplified by all the aforementioned Apache Foundation Java Crapware

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

#182

Post by grosswait »

adamtulinius wrote: post #174
dsr_ wrote: post #97

Earlier quoted context omitted.

See that "keep track" bit? It's expensive unless you build a tool to do it for you -- which is what I said previously.

You don't have to keep any more track than you do with your OS; it's just a different button you hit when updating containers. Or don't keep track at all: Just rebuild and redeploy often enough.

Except the OS is one place, one org. With containers it could exponential.

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

#183

Post by u801e »

IAmEveryone wrote: post #112
y0y wrote: post #69

Earlier quoted context omitted.

I know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s. A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was av…

People adapt to the situation they experience. Github (and other repositories) tend to be stable, so they are used. Network speeds have increased, so we use the network and expend less efforts on local caching etc. There's nothing "complacent" about this: previous generations also relied on infrastructure and didn't plan for prolonged power outages or had backup ham radio network links for when AOL was down. People u…

> There's nothing "complacent" about this: previous generations also relied on infrastructure and didn't plan for prolonged power outages or had backup ham radio network links for when AOL was down.

A lot of the protocols for asynchronous communication allowed for operating in offline mode. So if you didn't have an internet connection, you could still compose and send emails, but the client would only actually connect to the network when were actually connected and send the emails all at once (as well as downloading emails from the POP or IMAP server).

git actually has commands that leverage email for sending an receiving patches, so that code review and development can take place without requiring a connection at all other than to send and receive when needed.

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

#184

Post by xchaotic »

HorstG wrote: post #118
pjc50 wrote: post #109

Earlier quoted context omitted.

> unwilling to play nice with "external" dependencies But that's a policy decision - the dependencies should themselves be packages, because that's the only way to guarantee reliability. The inability to install multiple versions is probably the only serious problem with the dpkg model. Even then we might argue that the dependent software should be fixed so that it's not so fussy about specific dependency versions.

Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed. Of course this is work for applica…

I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.

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

#185

Post by Avamander »

GordonS wrote: post #176
Avamander wrote: post #158

Earlier quoted context omitted.

You don't have the opportunity in the latter case. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Sorry, I don't follow. If I have a makefile, I can inspect it and see what it does. If I have shell script (or indeed a makefile!) that calls `curl | bash`, I can inspect that shell script and see the URL that is used with curl, and then inspect the contents that the URL returns.

You can't see what comes from `curl | bash` before you actually pipe it to bash, click the link and read the article please.

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

#186

Post by rumanator »

Zyst wrote: post #156
rumanator wrote: post #121

Earlier quoted context omitted.

> jealous, insisting that every language has to conform to their way of doing things Let's ignore for a moment all your baseless assertions and focus on the following question: how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access? Is jealousy the only explanation that comes up to you?

Oh, check out Nix https://nixos.org/nix/ I use it for most of my dependencies, and software in OS X/Windows WSL/Linux It is a lovely environment to work with. Has completely changed how I feel about package management and the like. I know you were asking figuratively but something does happen to slot in that space.

> Oh, check out Nix

Nix is a non-sequitur. Nix requires specific packages and package versions to be specified, and Nix requires the build process to be "free from side effects". That fails to address both problems stated by the OP, and actually try to reimplement what Debian's package building process already does. Other than trying to publicize Nix, your comment adds nothing to the discussion.

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

#187

Post by markhahn »

Doxin wrote: post #91
eejjjj82 wrote: post #47

Earlier quoted context omitted.

would you feel better if your Makefile looks like this: install: [ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing | /bin/sh it goes back to what jve said - it's a matter of trust. how often do you blindly run 'sudo make install' w/o reading the entirety of the build script? all the time I bet - it's because you trust the source

Basically all makefiles you run into in the wild for mature projects allow you to install it with a prefix. e.g. into the home folder. No need to sudo anything if you do that.

This is an important point lost in the noise.

The problem is that cattle should apply only to containers, not hosts or VMs. Why? root. Which is also why Docker is a nonstarter for anyone who wants to use containers securely.

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

#188

Post by forgottenpass »

ekidd wrote: post #144
jwr wrote: post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

> without relying on any third-party servers being available and without pulling in dependencies that might have changed. There are two different issues here: 1. Not pulling in changed dependencies. This is what "lock files" are for: To limit builds to known version of every dependency. npm was terrible about this for a long time. Most other language package managers are better. 2. Not relying on third party servers…

>I've lost maybe two days of work because of package server outages [...] For the clients and employers in question, this was acceptable downtime.

Even if the downtime is fine, I don't find it goes over too well if framed as "we rely on a 3rd party service, that we have no contract with nor any guarantees of reliability or product longevity."

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

#189

Post by jeltz »

phaedrus wrote: post #167
y0y wrote: post #69

Earlier quoted context omitted.

I know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s. A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was av…

I'm 36 and recently was assigned to mentor a new employee in his 20s. We had a moment of miscommunication when I asked him to use git to clone a local repository. He was confused when he couldn't find it on github.com (what I'd sent him was a path to our private network share). I had to explain that, yes you can use the github.com client if you want, but "git" is different from "github". I honestly couldn't tell if h…

I am the same age as you, but I do not think this is about age, at least not mainly about age. My father who is almost 70 has no issue understanding what git and github are and I have worked with people under 25 who have not had an issues with this distinction either. And there are plenty of open source developers I have met who are pushing 70 who keep up with technology just fine.

Sure, I notice that younger developers do not know some things, like they never experienced the Java EE hype, so they can fall into some traps which are well known among older engineers.

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

#190

Post by [deleted] »

GordonS wrote: post #176
Avamander wrote: post #158

Earlier quoted context omitted.

You don't have the opportunity in the latter case. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Sorry, I don't follow. If I have a makefile, I can inspect it and see what it does. If I have shell script (or indeed a makefile!) that calls `curl | bash`, I can inspect that shell script and see the URL that is used with curl, and then inspect the contents that the URL returns.

[deleted]
Post reply on HN