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

vitavonni.de

Post reply on HN
Print view View original

251–260 of 466 posts

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

#251

Post by mercurial »

jkyle wrote: post #175
mercurial wrote: post #81

I love a good rant as much as the next guy, but unfortunately, rants are rarely actionable. > Maven, ivy and sbt are the go-to tools for having your system download unsigned binary data from the internet and run it on your computer. The root of the problem is that out of the total number of libraries available in language X, only a small subset is packaged in Debian/RHEL. This may be more egregious with large, Java e…

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

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

#252

Post by eranation »

As a Java / Hadoop / Spark / Scala fan, all I can say is, it's a little embarrassing, not sure how the Java ecosystem around hadoop became so sloppy (I witness it first hand on a daily basis). I wish more people who are concerned with security / ease of build would turn into contributing to maven, sbt, ivy and the hadoop project. Instead of hating the Java ecosystem, why not join it and make it better? Hadoop is ubiquitous, maven (and ivy / sbt) are the de facto dependency management and built tools for that ecosystem, and if it's broken, (or alienating people who are used to just have make / rpm / deb for anything) then those people should join and try to make it better.

Whether you like java / maven / ivy / sbt or not, good chances you'll end up forced to work with Hadoop (Java) or Spark (Scala), both of which use maven / sbt for dependency and build.

I say, It's all open source, if it's broken, and you know where it's broken, I think the Hadoop / Java community will be happy to get suggestions / pull requests to improve it.

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

#253

Post by lmm »

gnaritas wrote: post #235
TeMPOraL wrote: post #206

Earlier quoted context omitted.

It isn't, but so aren't dozens or hundreds of other commands you encounter when working with the command line. I managed to memorize a few invocations of tar (I listed them in another comment) but, for instance, I very rarely create a new archive so I'm never sure what flag I need to use. Part of the problem is that each command line utility has its own flag language, and equivalent functions often have different let…

Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language, command -options, and are all easily documented by man command; it quite literally couldn't get any simpler and unnecessary to memorize since you can look up any flag on any command with the same man command. Those who find it confu…

> Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language

Except with cp , -R is the safe one and -r is the dangerous one. And there are tons of little inconsistencies like this.

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

#254

Post by lmm »

pjc50 wrote: post #223
shanemhansen wrote: post #187

Earlier quoted context omitted.

Sorry, I don't know what ISO9001 is, but isn't deploying an image extremely conducive to traceability? No non-deterministic scripts are ran on production servers.

http://www.askartsolutions.com/iso9001training/Identificatio... ISO9001 often turns into its Dilbert parody of bureaucracy, but the core ideas are sound: if you have some sort of failure of production, it's useful to know what went into the production process and where it came from. So in the case of deploying images, then yes: you get repeatable copies of the image. Provided you know where the image came from . Imag…

Have you ever seen it implemented in a way that added value? I agree that in theory ISO9001 makes sense, but it's been a slow-motion disaster everywhere I've seen it actually tried.

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

#255

Post by lmm »

Jare wrote: post #113
sltkr wrote: post #87

Earlier quoted context omitted.

> Using it is usually as simple as "configure;make;make install". "Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.

That's the same for "wget|sh", apt-get, npm or any other system. Now, if the argument is that configure tends to break more often and for more obscure reasons, I can tentatively agree with that.

I'd actually disagree with that. Auto* breaks less often than wget or npm, IME.

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

#256

Post by fs111 »

eranation wrote: post #252

As a Java / Hadoop / Spark / Scala fan, all I can say is, it's a little embarrassing, not sure how the Java ecosystem around hadoop became so sloppy (I witness it first hand on a daily basis). I wish more people who are concerned with security / ease of build would turn into contributing to maven, sbt, ivy and the hadoop project. Instead of hating the Java ecosystem, why not join it and make it better? Hadoop is ubiq…

In theory you are right, unfortunately at least the hadoop "community" is difficult to work with. Hundreds of JIRAs with patches in limbo state for month/years b/c nobody of the paid developers at cloudera/horton bothers to take a look. Also the political things happening behind the scenes are way more complex than you might think. It is frustrating...

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

#257

Post by [deleted] »

eranation wrote: post #252

As a Java / Hadoop / Spark / Scala fan, all I can say is, it's a little embarrassing, not sure how the Java ecosystem around hadoop became so sloppy (I witness it first hand on a daily basis). I wish more people who are concerned with security / ease of build would turn into contributing to maven, sbt, ivy and the hadoop project. Instead of hating the Java ecosystem, why not join it and make it better? Hadoop is ubiq…

[deleted]

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

#259

Post by lmm »

oskarth wrote: post #112

At my last job we used a micro-service architecture on AWS (EC2 and RDS). Using Ansible playbooks for various types of servers and roles for each service, we created a new server instance every deploy. All servers were running FreeBSD and using daemontools to control services. For testing, hotfixes, and manual checking of logs, it was easy to complement with manual ssh. Save old and new instance in case something goe…

sbt is an abomination, but unless you're in the library business you can just use maven, which is wonderful.

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

#260

Post by TeMPOraL »

lmm wrote: post #253
gnaritas wrote: post #235

Earlier quoted context omitted.

Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language, command -options, and are all easily documented by man command; it quite literally couldn't get any simpler and unnecessary to memorize since you can look up any flag on any command with the same man command. Those who find it confu…

> Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language Except with cp , -R is the safe one and -r is the dangerous one. And there are tons of little inconsistencies like this.

That's exactly my point.
Post reply on HN