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

151–160 of 324 posts

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

#151

Post by tonyarkles »

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…

I half agree with you, and am chuckling a little bit about the "very masculine hunting and zombie-defending skills" part, but... I'd like to offer some perspective.

I'm 36 and work on a pretty broad set of consulting projects: some schematic/PCB/mechanical design, firmware, some lower-level desktop/server code, and up and up to web/mobile apps. "Full full stack" if you will.

I live in a "major" Canadian city (although not in the top 15 by population), and I also own two wonderful properties about an hour out of town in a quite rural area. One is a cabin on a lake, and the other is a church from the 1910s. Sometimes I head out to one of these places to do the "Deep Work" thing, distraction-free, and sometimes it's to take time off, but end up getting an emergency call from a client. In either case, my Internet connectivity is limited to tethering, and depending on a few factors, that can either work fantastically well or poorly.

Going from the lowest-level to the highest-level projects, there's a very clearly declining probability of the project being able to build during a low-connectivity event. The embedded stuff pretty much always works just fine (it's a Makefile, or CMake). The C desktop/server stuff? Always works fine (any dependencies were pre-installed). Python/Ruby/Elixir web backend projects usually go OK, although I've occasionally ran into issues where the package manager wants to check for updates. Node front-end builds sometimes start to fall apart, and Android (via Android Studio) often refuse to build at all! (Some kind of weird Maven/Gradle thing that needs to go out and check something, even though the dependencies have all been pre-installed...)

It's extraordinarily frustrating when you can't change a line of code and hit "Build" to test a change locally. Everything's already present on the machine! It worked just fine 5 minutes ago!

To your prepper comment, and the previous comments about infrastructure, there's a significant population of the world that doesn't have 100% reliable infrastructure, even in Canada and the US. The tools we have used to work just fine in that environment, but are getting progressively worse.

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

#152

Post by Spivak »

celticmusic wrote: post #135
pojntfx wrote: post #88

Earlier quoted context omitted.

18yo JS/Ruby/Go dev here. `make` is certainly known to us; it's just that platform-specific build systems (`mage` for Go, `rake` for Ruby, `gulp` for JS etc.) are simply more sane to set up per languages than using `make` for all languages and allows for efficient code reuse.

You have make call the platform specific build systems.

What's the point in a project that only uses a single build system? You're essentially getting nothing out of make except indirection. Might as well just have a build.sh at the root of the repo.

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

#153

Post by pojntfx »

celticmusic wrote: post #135
pojntfx wrote: post #88

Earlier quoted context omitted.

18yo JS/Ruby/Go dev here. `make` is certainly known to us; it's just that platform-specific build systems (`mage` for Go, `rake` for Ruby, `gulp` for JS etc.) are simply more sane to set up per languages than using `make` for all languages and allows for efficient code reuse.

You have make call the platform specific build systems.

I have done so in the past. This leads to a lot of duplication though.

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

#154

Post by kube-system »

Using stuff blindly from Docker Hub is a bit sketch, but it’s not a hard problem to fix. Read the dockerfile before using it, adjust if you don’t like it, and build and push to your own repo. Then run your vulnerability scans of choice on them nightly.

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

#155

Post by boxy310 »

itg wrote: post #67
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.

And then add PySpark on top of that. Couldn't leave my last job fast enough when they decided to use Hadoop/PySpark when the largest incoming files we received were at most a few GBs.

I once had a consulting gig where the customer desperately wanted to build a Spark/Scala ML pipeline, for a dataset that was 10 MB. We spent 3 months hammering it together for a flat Python process that would've taken us 2 weeks.

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

#156

Post by Zyst »

rumanator wrote: post #121
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…

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

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

#158

Post by Avamander »

GordonS wrote: post #125
LockAndLol wrote: post #73

Earlier quoted context omitted.

No. I think I have never run `sudo make install`. Things I install come from package managers. Docker or a VM is used to test other software. And of course trust is important, but if I encounter things like `curl | bash`, my trust is lost.

Whether it's `sudo make install` or `curl | bash`, in both cases you have the opportunity to first inspect the code that will be executed.

You don't have the opportunity in the latter case.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

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

#159

Post by SkyPuncher »

was_boring wrote: post #54
pwagland wrote: post #37

Earlier quoted context omitted.

Don't turn it into an ageist thing, unless you are particularly old, there will be plenty of older developers that also don't understand this. It largely comes from understanding _why_ reproducibility is a good thing, and there are _lots_ of open source maintainers that understand this that are likely "younger than you". The vast majority of developers though focus on other things, that SQL injection attacks are stil…

It is way bigger then security, and hits upon quality of life and reliability. Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.

> Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.

I use to have this concern, but it's really not an issue with modern package managers. Even without a checksum in a lock file (e.g. gem bundler), I haven't actually had a deployment break because of dependencies changes. The biggest issue is being blocked for a couple hours because a package repo went down.

Most of this is solved by using a self-hosted or 3rd party proxy package manager.

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

#160

Post by tetha »

HorstG wrote: post #120
pram wrote: post #6

Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

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. Containers can turn into an equal mess, yes, but that's up to the build chains and ecosystem built around the containers.

Post reply on HN