[deleted]
Fucking Shell Scripts
171–180 of 180 posts
Re: Fucking Shell Scripts
#172I'm all for anything that makes managing servers easier, but why use swear words in the name? It is unprofessional.
Re: Fucking Shell Scripts
#173Earlier quoted context omitted.
It's pretty funny, but it's an example of where we do NOT want to be headed. The Unix philosophy is a set of tenets based on assumptions that held in the 1970s and 1980s, but don't really hold today. One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct." This may have been true in an era when every site had to roll a…
> One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct." Having been a Unix admin since long before Linux existed, I find this statement to be complete bullshit.
I think it's the chinese whisper effect applied to http://www.jwz.org/doc/worse-is-better.html [0] and as such more cult than information. As witnessed by the discussion around here.
[0] ("Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.")
Re: Fucking Shell Scripts
#174Earlier quoted context omitted.
How would you take a template file, fill in some values, copy it to a certain path on the server and give it the right permissions? With, say, Python, I'd have to read the file, using mako or jinja to fill in the values, scp the file to some temporary file, then somehow run Python code on the server using SSH to copy the file and give it the right permissions. With Ansible, this is a single line.
Let's see... I would take the template file, fill in some values, scp it up to it's final location on the server, and run chmod on the server. I guess I could learn the "one-line" ansible way to do it, but I'd also have to learn to set up ansible. And I'm guessing it's not as flexible as, say, shell scripts.
The cool thing about Ansible is that there's no set up. You install it, write the config and run "ansible-playbook ". It connects to the nodes using SSH and runs without having to be installed in them.
As for not being as flexible as shell scripts, I'd say that's technically impossible, since it has a command for running shell scripts :) Personally, I never had to use it, but it's there.
Re: Fucking Shell Scripts
#175Earlier quoted context omitted.
> One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct." Having been a Unix admin since long before Linux existed, I find this statement to be complete bullshit.
I think it's the chinese whisper effect applied to http://www.jwz.org/doc/worse-is-better.html [0] and as such more cult than information. As witnessed by the discussion around here. [0] ("Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.")
Interesting theory. Considering the ignorance displayed, I think you're correct. Microsoft quality anti-Unix FUD.
Re: Fucking Shell Scripts
#176Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing t…
I agree. If someone claims Ansible is hard, they should go RTFM. Then if that doesn't work, they should go back to grade school. Ansible is easier than shell scripts by virtue of not having to write shell code. Then once Ansible Galaxy is out, config management will be trivial.
Re: Fucking Shell Scripts
#177Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing t…
Ansible is easy compared to Puppet/Chef specifically because it doesn't use Ruby. That doesn't make it good.
Re: Fucking Shell Scripts
#178Earlier quoted context omitted.
Shell scripts are extremely portable and should be the preferred method for a large set of tasks. Properly written, a shell script can run on a 20 year old Solaris machine, any version of Windows (with installed tools like Cygwin) and any modern Unix variant... claiming Node.js is more portable is ridiculous on so many levels. The problem is so many programmers don't take the time (or care to take the time) to learn…
Ahh yes, the much vaunted Hammer Factory Factory. http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
Completely off topic, but very interesting -- the author of that post wrote a book about surviving the Costa Concordia! http://www.amazon.com/gp/product/B00AUYIKNK/ref=as_li_qf_sp_...
Seems like he really did need some tools.
Re: Fucking Shell Scripts
#179Earlier quoted context omitted.
It's pretty funny, but it's an example of where we do NOT want to be headed. The Unix philosophy is a set of tenets based on assumptions that held in the 1970s and 1980s, but don't really hold today. One of these tenets is, "make the implementation as simple and as correct as possible; it is better for an implementation to be simple than to be correct." This may have been true in an era when every site had to roll a…
I knew this was a systemd advocate after the second sentence. Hilarious.
Uh, most of the Linux community consists of systemd advocates now. Systemd is now a fait accompli on all the major distros, and most of the users I encounter just want the bickering to stop. It would have stopped long ago were it not for a small but loud contingent of haters.
Re: Fucking Shell Scripts
#180Earlier quoted context omitted.
The user of a piece of software is more important than its current or future maintainers.
Yes but current or future users want reliability, features, and speed. If you care about your users in the long term you should care about the project's maintainers.
I suggested a relative ordering of importance; nowhere did I imply that one was important and the other was not.