211–220 of 466 posts
Is it a coincidence that all the technologies the OP complains about are Java (Hadoop, Apache Bigtop, Maven, ivy, sbt, HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch)?
Earlier quoted context omitted.
When you say anger, do you mean to threaten the developer who wants to run `chmod 777 /var/www` when their just-installed php app released in 2003 won't allow uploads? Edit: Maybe I should have added a /sarcasm to my comment?
"in anger" means used in a real-life situation, not just playing around.
Is it a coincidence that all the technologies the OP complains about are Java (Hadoop, Apache Bigtop, Maven, ivy, sbt, HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch)?
Running Java apps (especially Docker-ized Java apps) is less like installing a Unix package (even if it's masquerading as doing so), and more like starting an instance of some untrusted VM image on your (software-defined-)network. It can use some of your computer's resources, but it has no permissions to touch any of your data or services unless you grant them to it. It really is like an app, or a web page.
Earlier quoted context omitted.
https://xkcd.com/1168/ comes to mind. And yes, I Google half of the command invocations too (but usually type them in by hand so that I can remember them faster instead of copy-pasting).
I usually get tar right on the first try. I only have to remember 2 variants (extract file and create file): tar xf ./foo #automagically works with bz2 and gz files tar cf /tmp/out.tar . #add z for compression
tar cf
I think the author is mixing up a few different topics. If you're going to blame container frameworks for people sharing software in insecure ways you might as well blame the fact that executables are portable between compatible systems. Might as well blame the fact that there's a network while you're at it. We run docker throughout our infrastructure, but it is a deployment and dependency management technology, not…
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…
I have never under stood why some many people are not ok with using the command line. A few years back we had an issue where a mysql script was over the limit for phpmyadmin - my fairly experienced colleague he was unaware that you could log into the cli and use mysql from the cli.
https://github.com/cf-platform-eng/hadoop-boshrelease/tree/m...
Learning curve is a bit steep but it's another approach to this immutable infrastructure trend that's built for large production, enables rolling canary upgrades, etc.
Earlier quoted context omitted.
https://xkcd.com/1168/ comes to mind. And yes, I Google half of the command invocations too (but usually type them in by hand so that I can remember them faster instead of copy-pasting).
I usually get tar right on the first try. I only have to remember 2 variants (extract file and create file): tar xf ./foo #automagically works with bz2 and gz files tar cf /tmp/out.tar . #add z for compression
tar c . | gzip > /tmp/out.tar.gz
Stack is the new term for "I have no idea what I'm actually using".
This was great. It leaves me to wonder what "full-stack" means.
For one thing, we have a culture of trust inversion. I wrote about it in a blog post about a month ago: https://michaelochurch.wordpress.com/2015/03/25/never-invent... . The "startup" brand (and it is a brand) has won and most companies trust in-house programmers less than they trust off-the-shelf solutions. This tends to be a self-fulfilling prophecy. Because few corporations will budget the time to do something well (make it fast, make it secure, make it maintainable) it only makes sense to use third-party software heavily and use one's own people to handle the glue code, integration, and icky custom work. (That, of course, leads to talent loss, and soon enough, when it comes to build vs. buy your only option is to buy, because your build-capable people are gone.) At some point, however, you end up with a large amount of nearly-organic legacy complexity in your system that no one really understands.
Although it's not limited to one language or culture, this is one of my main beefs with Java culture. It has thoroughly given up on reading code. Don't get me wrong: reading code (at least, typical code, not best-of-class code) is difficult, unpleasant, and slow and, because of this, you invariably have to trust a lot of code without manually auditing it. But I like having the idea that I can. The cultures of C, OCaml, Haskell, and to a degree Python, all still have this. People still read source code of the infrastructure that they rely upon. But the Java culture is one that has given up on the concept of reading code (except with an IDE that, one hopes, does enough of your thinking for you to get you to the right spot for the bug you are fighting) and understanding anything in its entirety is generally not done.
Earlier quoted context omitted.
I would argue that anyone who is reasonably comfortable in a command line would resort to `man command`, `command --help` or `command -h` before googling for usage.
I think, occasionally, it's a lot easier to grok a command through googling than reading the built-in help. A fair amount of built-in *nix documentation I have run across is mediocre or unhelpful.