Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

381–390 of 466 posts

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

#381
post #160

Earlier quoted context omitted.

> Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2] Not only "previously", it's the current recommended way to install rvm. From their front page: >> curl -sSL https://get.rvm.io | bash -s stable [1] http://rvm.io/

It's also (one of the) recommended ways to do it for Docker[1]. I've noticed a few blog posts that touch on "here's how to use Docker for X" suggest piping it straight into `sudo sh` without so much as looking at what's going to be run first. Sigh. [1] http://get.docker.io/

[deleted]

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

#382
post #362
post #355

Earlier quoted context omitted.

> no new features Go gets us better performance and concurrency out of the box.

> Go gets us better performance Than Java? At best, GO performs on par with Java, but is often measured 10-20% slower.[1][2][3] This is usually attributed to the far more mature optimizing compiler in the JVM, which ultimately compiles bytecode down to native machine code, especially for hot paths. Java performance for long running applications is on par with C (one of the reasons it's a primary choice for very high…

Hell, if we look at real-world-ish applications, the techempower benchmarks show go at easily 50% slower than a bunch of different Java options.

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

#383
post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…

I honestly don't see the issue.

I see the issue with doing it for the general public ala RVM, but internally where you control everything I don't see the issue with curl into sh.

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

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

How are people missing the sarcasm of this comment?

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

#385

Earlier quoted context omitted.

I'd like to think this post is an exaggeration.

Unfortunately not there are a lot of developers can only use phpmyadmin or thier CMS's gui - and from what I am told being able to code basic sql joins is not something you can take for granted.

Crazy talk. And these 'developers' are pulling in six-figure?

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

#386

Earlier quoted context omitted.

>Although the trend of many data breaches certainly wouldn't decline in that case. Exactly. Successful and profitable are not mutually exclusive with "secure" or "well-architected". At least until those last two come to bite you later and start eating into your profits.

Sony is a great example of this.

Did the PR hit actually translate into a monetary hit and eat into their profits?

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

#387
post #313
post #237

Earlier quoted context omitted.

Am dealing with this situation right now. Apparently wget -qO- https://get.docker.com/ | sh as root[1] is the "supported" way of installing Discourse [1]: https://github.com/discourse/discourse/blob/master/docs/INST...

No, that's Discourse install instructions quick, hand-wavy way of telling you to install Docker if you don't already have it. If your cloud environment already has Docker installed, you can skip that step. Are you really trying to say that the instructions for installing Docker should be considered in-scope for a guide to install Discourse on a cloud server? They've included a short snippet that will get you a Docker…

I concur - to elaborate, I'm not actually the one installing Discourse. I support a 'Kumbaya' group of data scientists who have never heard of docker.

Quick directions like these aren't questioned by users who just want to get things done, and they invite security risks just as the parent & article suggest.

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

#388
post #175

Earlier quoted context omitted.

> You cannot reasonably expect developers to package and maintain all their dependencies properly. Why not? This is exactly what developers are expected to do. Every developer must manage dependencies for their application to work. What you mean is they can't be reasonably expected to do it well . In most situations, this is truly a trivial amount of investment relative to the overall cost of developing and maintaini…

> In most situations, this is truly a trivial amount of investment relative to the overall cost of developing and maintaining an application. I wouldn't say that creating and owning packaging for, say 50 libraries (assuming you only deploy to a single platform) represents a "trivial amount of investment" for a standard small developer team.

Honestly, if a particular development environment for a project required tracking 50 libraries not supported by any distro community and my development team was so small that I couldn't do that in a sane manner...

I might reevaluate the suitability of that particular language for the project.

On a side, it only takes marginally more time to build a package for a distro as it does to build the package by itself. If you've already got the build done, 3 experienced guys could knock out 50 packages in a week. Inexperienced (in this task), but competent, devs should be able to do it in 2 weeks.

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

#389

Earlier quoted context omitted.

> 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 system. They also have a great track record at it. The analog of the aspects of what Debian does that you're talkin…

But the problem is that the ones doing the vetting (i.e. Debian) have given up on making a vettable distribution because the build is so broken.

But Debian isn't the Debian of Hadoop. Cloudera is.

Why should we assume the Debian Foundation is the sole trusted source of every type of software?

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

#390

Earlier quoted context omitted.

Sony is a great example of this.

Did the PR hit actually translate into a monetary hit and eat into their profits?

I don't know about the cost of the negative PR, but the compromise itself cost them $15 million in real costs (http://www.latimes.com/entertainment/envelope/cotown/la-et-c...) and potentially much more (http://www.reuters.com/article/2014/12/09/us-sony-cybersecur...) once you count the downtime involved and potential lawsuits, settlements, and other fallout over the breach of information. IIRC there were some embarrassing emails released regarding some Hollywood big-wigs, for example.

It should be a huge cautionary tale for any big organization that doesn't have good internal security, but unfortunately this isn't the first such case in history, and it almost certainly won't be the last.

But that doesn't mean there aren't other smart businesses out there.

Post reply on HN