It's not just system administration...
Minecraft is a meta-game about downloading unsigned JARs from the 'net and running them with your own user account.
The sad state of sysadmin in the age of containers
351–360 of 466 posts
Re: The sad state of sysadmin in the age of containers
#352Earlier 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…
Because now your ability to install your mission-critical software is dependant upon https://whatever.io actually being up. Which it certainly won't be forever. Or, you know, maybe someone updated the whatever.io installer to make it 'better'. But you are trying to debug some problem and you made one image last month and another one this month and you're pulling your hair out trying to figure out why they are differe…
Good point. I guess you could still wget the script though. It's maybe like ./configure over http? I guess even if you could do it, it's probably not culture. A Dockerfile would probably just curl sh the thing and not wget it. So the default culture probably does depend on whatever.io being up.
Re: The sad state of sysadmin in the age of containers
#353Earlier quoted context omitted.
> 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".
I spent an entire day last week attempting to build hadoop with LZO compression support. There are many outdated guides on the internet about how to do this, and I eventually gave up and spent a few hours getting the cloudera packages to install in a Dockerfile so I could reproduce my work later. Figuring out which software packages I needed, how to modify my environment variables, which compiler to get, and where to…
> If it were written in Go instead of Java, I could have done `go get apache.org/hadoop`
This complaint is just about packaging, and not the language itself. Any project can have good or back packing scripts, and for Java there are plenty of ways to make it "good".
Not to mention, the BUILDING.txt document clearly states they use maven[1] and to build you just do: mvn compile
> Go's win is that it makes the actual running of real software in production better
This might just be a familiarity issue, because once you launch the program, all things are equal.
And yes, you can bundle a JVM with your java app, which makes it exactly like GO's statically linked runtime and just as portable without any fuss.
[1] https://github.com/apache/hadoop/blob/trunk/BUILDING.txt
Re: The sad state of sysadmin in the age of containers
#354make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…
Who can't read a Makefile? Who can't at least read the output of make -n? It's terrifying to me that you're suggesting that people can't and don't.
It's not even a security thing. I've had poorly-written Makefiles that would have blown things away thanks to an unset variable on a certain platform, for example.
Re: The sad state of sysadmin in the age of containers
#355Earlier quoted context omitted.
> 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".
I spent an entire day last week attempting to build hadoop with LZO compression support. There are many outdated guides on the internet about how to do this, and I eventually gave up and spent a few hours getting the cloudera packages to install in a Dockerfile so I could reproduce my work later. Figuring out which software packages I needed, how to modify my environment variables, which compiler to get, and where to…
> no new features
Go gets us better performance and concurrency out of the box.
Re: The sad state of sysadmin in the age of containers
#356Earlier quoted context omitted.
Go and modern C++ are both quite a bit more terse than Java. They also produce binaries which don't necessarily require a runtime to be available on every server (just ABI compatibility). (I have no horse in this race, I am just writing what I think the grandparent comment was referring to)
> They also produce binaries which don't necessarily require a runtime to be available on every server Just like Java[0]. It is just a matter of choosing the right compiler for the use case at hand. [0] - http://www.excelsiorjet.com/ (one from many vendors)
There's also things like exec4j which bundles everything including a JVM into an executable which one can just run... and things like AdvancedInstaller and Install4j will also allow one to bundle a JVM.
So producing a binary which doesn't require a separate runtime really isn't a problem.
Re: The sad state of sysadmin in the age of containers
#357Earlier quoted context omitted.
I think more disconcerting is the rise of "sysadmins" who think they're qualified sysadmins because they know how to bash and docker.
As a hiring manager, it's very easy to filter these people out at the interview stage. Being a system administrator requires a very specific personality type that has little to do with experience and more to do with attitude and critical thinking. Sadly, people are right that startups are skipping past admins, thinking they're not needed anymore. Then later they need to hire one to clean up the giant mess.
It's really that easy. Pick your favorite software that happens to have broken SSL certs (such as RVM as of a few months ago), and tell them to install it. If they balk a the prospect of disabling SSL cert checking on the wget command, then they're worth their weight in gold.
Re: The sad state of sysadmin in the age of containers
#358Earlier quoted context omitted.
> Linux containers were already a thing, and don't need an entire copy of an OS ported around with them. Neither do Docker containers. You can build off scratch and put the literal bare minimum you need in it. I've done it a few different times. It's rarely done because the time and effort almost never makes up for the complexity and cost, but if your old-school sysadmins are scoffing it's on them.
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.
Re: The sad state of sysadmin in the age of containers
#359Earlier quoted context omitted.
I never use man pages, to be honest, and I'm quite comfortable on a command line. Reading long-ish things in a terminal kind of sucks, for me, and even if I end up reading a man page in Chrome it's nicely formatted and has readable serif fonts and is easily scrolled with the trackpad on my laptop.
Your terminal doesn't scroll with wheel/trackpad?
It can do continuous scrolling of the terminal or line-by-line scrolling of the pager. Both are poor options for trying to actually read prose content inside the terminal, IMO, and opening a browser is easier.
Re: The sad state of sysadmin in the age of containers
#360So much truth spoken in the linked text. Thanks. It has to be said. Damn the containers and windowization of Linux.
To isolate closed-source programs containers are very helpful. I don't like to run steam within my normal debian system.