The sad state of sysadmin in the age of containers (2015) • Hacker News Board

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

#241

Post by eeZah7Ux » Mon, Dec 09, 2019, 5:45 PM UTC

oblio wrote: post #224

eeZah7Ux wrote: post #103

Earlier quoted context omitted.

> jealous, insisting that every language has to conform to their way of doing things Not at all. The large majority of packaging systems have reasonable and similar requirements for upstreams, like not bundling dependencies or not hardcoding paths. > fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package That's com…

While you could argue about: > install packages for a single user because of the security angle, Not allowing this: > install multiple versions of the same package is completely indefensible. Who are you, package manager, to decide that I shouldn't be able to use different versions of the same package? Do you know more about my context than I do?

> Who are you, package manager, to decide that I shouldn't be able to use different versions of the same package?

That's one of main point of a distribution, rather that simply throwing software on a hard drive.

The maintainers have to work hard to guarantee that a specific set of packages and version work well together. Well enough for most users to deploy 99% of the packages without surprises.

And then backport security updates (often faster than upstream), for 3 years, often 5.

And various companies provide longer term updates and maintenance.

Oh, and provide license checking and vetting.

Turns out that it's a lot of work and no serious distribution would consider supporting multiple version of packages while guaranteeing the same level of quality.

> Do you know more about my context than I do?

Given your statements about distributions... most likely yes.

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

#242

Post by asdfman123 » Mon, Dec 09, 2019, 5:52 PM UTC

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…

You'll get blank stares and resistance whenever you throw a bunch of jargon at people that they don't understand, though. It makes people feel insecure.

You can't expect new programmers who sound like primarily front-end devs to learn all the hot new stuff and all the old stuff, too.

If you want someone with that kind of knowledge, you need to hire a senior dev with 20 years of experience.

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

#243

Post by moonbug » Mon, Dec 09, 2019, 6:01 PM UTC

lmm wrote: post #119

moonbug wrote: post #113

Earlier quoted context omitted.

Not so obviously as you might think. But, if they are going to do it, they should clearly do it well

Right, but my experience is that Java (and a few others) have succeeded in this space. I actually wish that I could use maven to install system software rather than having to rely on something like apt.

I wish that I could do literally anything else in my life but use maven.

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

#244

Post by u801e » Mon, Dec 09, 2019, 6:10 PM UTC

chefandy wrote: post #198

phaedrus wrote: post #167

Earlier quoted context omitted.

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've worked with developers that have used git for 10 years who didn't fully realize what all of the 'git reset' options entailed, and I don't blame them. Git is complicated and you could certainly have a perfectly effective workflow with it for your whole career without using most of the features. If you'd only worked in environments in which code was entirely managed in GitHub, you probably wouldn't know that eithe…

> I've worked with developers that have used git for 10 years who didn't fully realize what all of the 'git reset' options entailed

While knowing some of them, if you use git reset on a frequent basis is expected, knowing where to find information on the other options is essential. I frequently go back and read through the man pages for various git commands so that I understand what will happen if I use a particular set of options and also to learn new things while reading through them.

So, the proper answer for a developer who doesn't realize what a git command is capable of is to refer to the man page for that particular command.

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

#245

Post by AnIdiotOnTheNet » Mon, Dec 09, 2019, 6:35 PM UTC

pjc50 wrote: post #109

lmm wrote: post #94

Earlier quoted context omitted.

It's not just a question of being in the official repos. Even if you're running a private repository, the deb tooling is not suitable for building many kinds of software: it's unwilling to play nice with "external" dependencies, and still single-platform and limited in its functionality.

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

> The inability to install multiple versions is probably the only serious problem with the dpkg model.

Also can't install to separate disks.

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

#246

Post by AnIdiotOnTheNet » Mon, Dec 09, 2019, 6:37 PM UTC

HorstG wrote: post #203

xchaotic wrote: post #184

Earlier quoted context omitted.

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.

"Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.

As we are all aware, the most secure software is software that doesn't work at all because of library conflicts.

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

#247

Post by kbr2000 » Mon, Dec 09, 2019, 6:48 PM UTC

JustSomeNobody wrote: post #59

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…

I don’t think it’s age so much as it’s “well, that’s just what everyone does now”. If you want to work in this industry you have to follow the herd; for better or worse. I certainly don’t agree with it, but people have bills to pay.

Managers and C-levels surely have appetite for this. In the end it just degrades mostly to trial-and-error, which I'm sure is no problem because the people have to do the real work get sick of it and get replaced (sometimes voluntarily, sometimes with force), or play the game nice out of fear losing their job (thus feeding the beast).

It's not very surprising since 'products' nowadays are more like 'services' instead, and offer some kind of encapsulation: people are not interested much in how something ticks behind the scenes, and so it can drive down the behind-the-scene quality. They also are conditioned to accept lousy excuses (including none) for outages and breakdowns, because they got sold 'magic', and boy that is magical..

You'll might have to work in obscurity to keep up operations quality, which is in turn a driver for your own demise. Game over.

I'd like to suggest to you the following reading material:

- Bullshit Jobs (David Graeber, 2018)

- The Dilbert Principle (Scott Adams, 2000)

- Future Shock (Alvin Toffler, 1970)

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

#248

Post by [deleted] » Mon, Dec 09, 2019, 6:52 PM UTC

dcolkitt wrote: post #229

buzzkillington wrote: post #48

Earlier quoted context omitted.

Spark is worse because you need Scala as well as regular Java. I've tried building it for my day job, I would rather have a colonoscopy without sedation. It's more pleasant and dignified.

FWIW, the below linked Dockerfile will download, build and install Spark in a single step. https://gist.github.com/Mister-Meeseeks/1ebf875b6e1262449cbc...

[deleted]

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

#249

Post by cuillevel3 » Mon, Dec 09, 2019, 6:59 PM UTC

jve wrote: post #14

This all boils down to trust. `curl | sudo bash` is no different than .\install.exe. The question is about trusting the SOURCE and trusting the DISTRIBUTION channel (that HTTP download from scala-lang.org violates this). Where did you get it? from https://microsoft.com/.. . or from https://micro.soft.com/... ? Whom you trust more? The same with pre-built VM image or whatever... do you trust the party that made this i…

It also no different from using 'make install' or installing packages from a community repository, like Ubuntu Universe, homebrew, Arch AUR and so on.

There is an absurd amount of trust put in distributions and their package managers. Unless people are paying for it, or use very old software, they probably don't get the level of security they expect.

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

#250

Post by hodgesrm » Mon, Dec 09, 2019, 7:26 PM UTC

lmm wrote: post #77

You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…

> Platform package managers like maven have been far more successful because they provide a much better user experience, and frankly I suspect this is if anything because they're so thoroughly isolated from the platform package manager.

This is just wrong. Package managements support simple models by design so you don't end up with a mess of conflicting and potentially insecure dependencies in deployment environments.

Use maven in your build pipeline, fine, but distribute a minimal package using tarball/RPM/APT/etc. so that only the minimal runtime dependencies install on the deployment target. In fact, I built my first RPM using the maven rpm plugin. It takes just minutes to set up and use.