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/
The sad state of sysadmin in the age of containers
381–390 of 466 posts
Re: The sad state of sysadmin in the age of containers
#382Earlier 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…
Re: The sad state of sysadmin in the age of containers
#383This 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 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
#384Re: The sad state of sysadmin in the age of containers
#385Earlier 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.
Re: The sad state of sysadmin in the age of containers
#386Earlier 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.
Re: The sad state of sysadmin in the age of containers
#387Earlier 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…
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
#388Earlier 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.
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
#389Earlier 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.
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
#390Earlier 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?
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.