Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

431–440 of 466 posts

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

#431
post #377
post #376

Earlier quoted context omitted.

C++ does usually require a runtime.

C++'s runtime is small and ubiquitous. Depending on how the software is written (if it allows disabling exceptions and rtti), it might be the same size as C's runtime, which is practically (but not totally) nonexistant. I'm not an expert on Java, but my experience with it is that it's runtime is fairly huge and requires custom installation.

C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.

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

#432

Earlier quoted context omitted.

Funny tumblr but makes me care-confused. I understand that curl pipe sh could have security problems but I also don't see it as that much different than the "normal" and "ok" way of doing things. I would consider something like the below pretty normal. wget https://whatever.io/latest.tgz tar xzf latest.tgz cd whatever-stable ./configure && make sudo make install Because of familiarity, we aren't going to be too worri…

Outside of a development environment, you'd run that ./configure && make install step on a build slave that creates a nice RPM or Debian package of it for you which you can install without fear that the build scripts install backdoors, download obsolete software or wipe the filesystem. With a good build system (eg. autotools) writing an RPM spec takes almost no time at all and if you have the proper infrastructure in…

> With a good build system (eg. autotools)

Yikes. Have we sunk this far?

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

#433
post #64
post #12

Earlier quoted context omitted.

> Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. While I agree with the articles main points - the GNU build system is far from simple. Basically an arcane syntax limited to unix-based systems and 5 or 6 100+ page manuals to cover. It doesn't excuse it - but I think it's easy to see wh…

> the GNU build system is far from simple Which is why there's alternatives – cmake, waf, …

> Which is why there's alternatives – cmake, waf

Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...)

Personally I like make. I understand it. I've used it for something like 20 years now. If there are problem domains it doesn't work for, they aren't problem domains I encounter. (Like so much of Linux software in the past 5 years or so, I find myself saying "this seems like an interesting way to solve a problem I simply don't have".)

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

#434
post #45

Earlier quoted context omitted.

Signed packages isn't about just being signed. I could sign anything I like, but that doesn't make it any more secure for you to curl it into /bin/bash. Signatures are about who signs it, and that's not something mvn has solved at all. Mvn is a free-for-all of binary code that very well could own my system, wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by…

> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. This comes with a huge tradeoff, and I guess it's that tradeoff that makes developers like myself opt to sometimes even pipe the cURL to bash. I almost never download any software I actually plan to use through official system reposi…

> whatever comes out of apt-get, it's almost always two years behind the last release and missing half the features I need

As a sysadmin, I love that, but I've had to come to terms with the fact that some developers have the attention span of hummingbirds who had Cap'n Crunch for breakfast ("two years old" is still very new software from an administration perspective).

So, I've basically accepted the fact that whatever stack the developers use I'll build and maintain directly from upstream -- with the price being that the version and extensions/whatever used are frozen from the moment a given project starts.

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

#435
post #37
post #2

"Stack is the new term for "I have no idea what I'm actually using"." - this made my day!

Same for "framework" which is: I have no idea what I'm doing

"Framework" at least pretty reliably means some form of code generation is going on.

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

#436
post #400
post #368

Earlier quoted context omitted.

Cool concept, I didn't realise this existed. Can you run Hadoop and friends under this? I've worked at companies with over 500 servers in a Hadoop cluster and literally never once heard about anything other than using Oracle's JRE aside from one proposal to use OpenJDK which was shot down pretty quickly.

Way back in the day, GCC's gcj compiler would do AOT compilation of Java, however I believe it stopped being developed at jdk5 support.

If I am not mistaken most the developers abandoned the project to work on the Eclipse compiler and OpenJDK when those projects became available.

GCC only keeps gcj around due to its unit tests.

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

#437

Earlier quoted context omitted.

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 emb…

$15M sounds like a rounding error for Sony. It sounds like a rounding error as well when compared to the cost of brand-name IT solutions when deployed in a company of Sony's size.

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

#438

Earlier quoted context omitted.

Nah, man pages are usually completely useless. I use man when I remember exactly what I want to do and just aren't sure if the flag was -f or -F. For everything else there's google.

Can you give an example of what you might turn to google for (and what you'd search for) that is more productive than checking a manpage/help output?

I too find it much easier to google for actual working examples of commands rather than the abstract documentation in the manual.

Rsync for example, where trailing slashes make a difference and it's not obvious from skipping over the manual.

Looking at working code/commands often works better than piecing it together from the manual imo.

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

#439

Earlier quoted context omitted.

I think part of this is because there aren't any trusted, fully open source, artifact repositories that work with the various package indices out there. Like, most of the way deployment should work is that you come up with some collection of packages that need to be installed and you iterate through and install them. Bob's your uncle. Thing is, all the packages you need live out in the wild internet. Ideally, you'd j…

With docker, as referenced in TFA... you can simply vet a base image, and use that for your application... upgrades? create a new/updated base image and test/deploy against that.

And how do you "simply vet a base image"?

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

#440
post #64

Earlier quoted context omitted.

> the GNU build system is far from simple Which is why there's alternatives – cmake, waf, …

> Which is why there's alternatives – cmake, waf Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...) Personally I like make. I understand it. I've used it for something like 20 years now. If there are problem domains it doesn't work for, they aren't problem domains I encounter. (Like so much of Linux software in the past 5 years or so, I find myself…

> Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...)

Each their own poison. Personally I don't like them either, but pretending it's autoconf or curl|sh is an oversimplification.

Post reply on HN