Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

411–420 of 466 posts

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

#411
> And then hope the gradle build doesn't throw a 200 line useless backtrace

This is more the fault of the language Gradle chose for its build configuration language. Most build scripts are between 20 to 50 lines long, but reading through those Groovy stack traces eliminates its supposedly write-one-read-many-times benefits.

Hopefully Gradleware will fix this problem for Gradle 3. They've already enabled Gradle to be configured on the fly by Java code, and could by working towards allowing any dynamic language to be a build language through an API. Alternatively, they've just employed one of the ex-Groovy developers recently made jobless by Pivotal pulling funding from Groovy and Grails last month -- they might get him to write a better lightweight DSL from scratch that parses the existing syntax, but isn't weighed down by all of the present cruft.

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

#412
post #134

Earlier quoted context omitted.

I find it weird that you consider 'packaging' to be something a sysadmin should do, but 'building' to be something they should not do. Aren't they both forms of 'prepping code for use'? And then state that you don't want your own software packaged. So, if a sysadmin is not allowed to build and not allowed to package, how are they supposed to get your code into production? "curl foo | sh"?

I don't consider packaging to be a sysadmin task. On any sane OS (i.e. anything not Linux/BSD), packaging is done by the upstream developers. That doesn't happen on Linux because of the culture of unstable APIs and general inconsistencies between distributions, but for my current app, I am providing DEBs and woe betide the distro developer who thinks it's a good idea to repackage things themselves ...

Well, we're going to have to agree to disagree there, because I think Windows packaging is fucking insane.

One of the things I loved about my move to linux and .deb land was that if I uninstalled something, I knew it was uninstalled. I didn't have to rely on the packager remembering to remove all their bits, or even remembering to include an uninstall option at all. Or rely on them not to do drive-by installs (which big names like Adobe still do, out in the open). And not have every significant program install it's own "phone home" mechanism to check for updates. The crapstorm that is Windows packaging is a fantastic example of a place where developers love and care for their own product, but care not a jot for how the system as a whole should go together.

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

#413
post #192

Earlier quoted context omitted.

Response to exactly that idea from one of these guys: "Why do you need docker to just build an executable?"

I don't. But it helps make a straightforward deployable of highly coupled libraries and tools in a way that's more comprehensible to other people. But I'll get off your lawn now.

Ain't my lawn; I consider myself a mid-range sysadmin. I stepped out of support and into sysadmin land about 4 years ago. But I know some 'from-the-birth-of-linux' guys, who live and breathe this stuff in a way I never will. When I get home from staring at terminals, I want to watch movies and play video games, not swear at something on a breadboard :)

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

#414
post #324

I agree that many of these convenient setups are embarrassingly sloppy, but it's the sysadmin's responsibility to insist on production deployments being far more rigorous. No one can tell you how to build hadoop? Well, figure it out. Random Docker containers being downloaded? Use a local Docker repo with vetted containers and Dockerfiles only. I don't even allow vendor installers to run on my production systems. My e…

> it's the sysadmin's responsibility to insist on production deployments What decade are you from? No startups are hiring sysadmins to do any kind of work anymore. They're hiring "dev-ops" people, which seems to mean "Amateur $popularLanguage developer that deployed on AWS this one time." That's the whole problem with the dev-ops ecosystem. None of these dev-ops people seem to have any ops experience.

While I think that devops can be a useful term, lately most people take it to mean 'I'm a rails developer but I know how to use docker and the aws control panel'.

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

#415

Earlier quoted context omitted.

Also the installer is now signed via GPG. https://rvm.io/rvm/security

But then there's a circular dependency because the GPG key is retrieved by the bash script that is wget'd.

Same issue when people post GPG keys on their website. You can't verify them.

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

#416
post #371
post #311

Earlier quoted context omitted.

This is hardly a new problem- and in many ways, I'm not sure it's a problem at all compared to the company cultural issues brought up by skywhopper. Whether it's programming or system administration, you're always going to have new people getting excited about the sudden power they've learned. Being able to make computers do things opens up this whole new world, and when people find themselves in that world they may…

I've found that there isn't an easy ramp into system admin from university -- most of the talent comes from dogmatic self learning in computer repair shops or subpar IT shops. All the good guys at $BIG_SOFTWARE_COMPANY seem to be in their 30s after putting in years doing /tedious/, but extremely useful, work for little pay.

My uni used student sysadmins to run hosting for Open Source projects. Great experience on production infrastructure without big dollars on the line when mistakes are made.

http://osuosl.org/about

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

#417
A lot of big projects are terrible to build.

Once upon a time minimising dependencies was considered good practice. Now I get a pasting if I write clean code without reusing someone else's library... even if the suggestions don't solve my problem directly or at all and comes complete with a sloppy 'no one click build/deploy' configuration... the kind I was embarrassed to produce on my stand alone projects in my teenage bedroom days.

Shame on developers everywhere for tolerating this mess. I (am lucky enough to enjoy the freedom of choice that I) would leave a job if not allowed to start fixing such a situation from day one.

That being said, good sysadmins and developers should work out these problems properly instead of shortcutting through someone else's half arsed effort via Google.

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

#418

Earlier quoted context omitted.

That's why you get someone who is capable of understanding it. You wouldn't hire some high school kid who's just about taught themselves HTML by reading a book for a week, and get them to write your web application from ground up. You'd hire someone who knows what they're doing. Why is it seen as any different for Operations work? There is a reason systems administration is a skilled field, and a reason they're paid…

That high school kid needs to install a web server. Is he going to hire someone? No. He's going to copy a curl command.

I expect her to say "How do I install software on this platform?" "Oh! /(apt|yum|dnf)/!"

/(apt-get|yum|dnf) install (apache2|httpd|nginx|lighttpd)/

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

#419
post #317
post #300

Earlier quoted context omitted.

Hadoop is insane. The elephant is fitting. Is it really the best choice, or has someone done something cleaner in golang or c++11?

> Is it really the best choice, or has someone done something cleaner in golang or c++11? What does the language have to do with the program? Hadoop is what it is because it's a complex problem with a fittingly complex solution. Simply re-writing it in your pet language won't somehow make it "better".

>What does the language have to do with the program?

I happen to agree with you whole heartedly, if you spend enough time here though you'll see the inevitable comment about how anything made in php is worthless insecure garbage and anyone who spends their time developing a php application are amateurs at best.

This isn't really a comment at you, just wanting to point out how much that convention is challenged.

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

#420

Every once in a while someone figures out that we could entirely solve the dependency problem by packaging all the dependencies with the application. Everyone gets excited. After a while everyone gets unexcited when the problems associated with this approach become obvious. Docker is merely a more extreme example of the "package everything with the application" idea...

I'll bite. What's obviously the problem about it? Or, "if it's good enough for Google...."

Vendoring dependencies and static linking is quite popular in executables, not just docker. Dynamic linking and shared libraries seem to be becoming a relic, deservedly.

BTW, the extreme example of "package everything with the app" is the unikernel movement.

Post reply on HN