Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fucking Shell Scripts

fuckingshellscripts.org

Post reply on HN
Print view View original

131–140 of 180 posts

Re: Fucking Shell Scripts

#131

Post by da02 »

mattjaynes wrote: post #127
garyrichardson wrote: post #122

Earlier quoted context omitted.

I used to work for a little company called The Internet Marketing Center. I'm not sure who taught you how to market this way, but I definitely giggled a little when I saw your site using IMC style long copy to sell tech ebooks. I may even buy a copy :)

Thanks Gary :) I got most of my inspiration from Kathy Sierra and Why the Lucky Stiff. They're waaaay better than me in this regard, but they taught me that most brains love a little whimsy. I try to add a little since systems engineering can slip into dryness pretty quickly if you're not careful. Little jokes like the borg cow can lighten things up: https://devopsu.com/newsletters/ansible-weekly-newsletter.ht... An…

I remember this genius edu. researcher (Alan Kay) talking about his dog: "...and my little dog, Watson..." I wondered why he would emphasize the diminutive nature of his adult dog. The closest guess I came to was: Even though this guy had no kids, his mind/body still is "programmed" to respond to baby-like features. That might explain why your cute pictures calm the trolls. Then again, I'm no neuro-socio-biologist.

Re: Fucking Shell Scripts

#132

Post by felixgallo »

bitwize wrote: post #82
dogas wrote: post #16

Coauthor here. Well, this is a surprise! This project was mainly borne out of our frustrations with Chef and then Ansible for configuring our servers. A few thoughts: 1) This project is incomplete and is more of a concept than anything. We wrote it literally in an afternoon, and were giggling like schoolgirls the whole time. 2) There is value in what Ansible provides. It does a lot of things for you. FSS did not repl…

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.

Re: Fucking Shell Scripts

#133

Post by gerhardlazu »

mattjaynes wrote: post #123
rdtsc wrote: post #120

Earlier quoted context omitted.

> Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. Well not blow your brains out difficult but "learn a new syntax, behavior, rules, depend on a new package" difficult if a few shell commands is all you want to do. I can see where they are coming from. I can go a long way just using shell script to configure (and yes, you can make them idempotent too). From your site: > Yo…

Good point: "if a few shell commands is all you want to do." Agree totally. If you're doing something tiny, then a few shell commands are what is needed, not a CM tool. I'm speaking mostly about serious systems that businesses run on. Ansible is not for everyone. Each tool has strengths and weaknesses. I generally push Ansible because it's the easiest to get started with, but can also scale to 10K+ nodes. If somethin…

I'm all Ansible & Docker on my personal projects / servers, what a blast! http://gerhard.lazu.co.uk/ansible-docker-the-path-to-continu...

More focus on the "why", less on the "how" http://thechangelog.com/ansible-docker/

Re: Fucking Shell Scripts

#134

Post by billpg »

Please do not wget files over HTTP (no S) and just run them, as the example script does. Have the script run the downloaded file through sha256sum and check the output matches what you expect.

I know that was only an example script, but we don't want to be encouraging bad practices here.

Re: Fucking Shell Scripts

#135

Post by mercurial »

mattjaynes wrote: post #81

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

> A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely.

They're idempotent only as long as the configuration stays the same. If you removed this "apt: package=XXX state=present" line, XXX is not going to be magically uninstalled, but you may have a nasty surprise the next time you attempt to provision a second server with the same configuration and realize you're missing a runtime dependency. That's what I find fascinating about NixOS/NixOps: you can describe the entire state of the machine in a single configuration file (if you use the declarative style of package management). Of course, it won't help you if:

- you already have a large number of non NixOS systems

- you need many packages not present in NixOS

- you'd like polished package management (the Nix package management still has a way to go before it reaches yum/apt ease of use)

Re: Fucking Shell Scripts

#136

Post by mercurial »

jamiesonbecker wrote: post #105
bitwize wrote: post #82

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

Simple is almost always Correct. Conversely, complex is almost always incorrect.

"Simple enough is almost always correct". "Too simple for the problem domain" is almost always a synonym for "build a heap of absolutely terrible and verbose pile of complexity on top of the 'simple' system". See also sysvinit.

Re: Fucking Shell Scripts

#137

Post by kelnos »

jamiesonbecker wrote: post #105
bitwize wrote: post #82

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

Simple is almost always Correct. Conversely, complex is almost always incorrect.

Strongly disagree. Often complexity in your implementation is necessary to present a simple interface to your user.

Re: Fucking Shell Scripts

#138

Post by darklajid »

mattjaynes wrote: post #81

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

In my experience (playing with ansible, on and off, for quite a while) limitations or bugs in the tool often lead to your ansible scripts to become .. shell scripts.

The more raw/command/shell modules you have to use, the uglier the whole approach seems to me - and maybe not worth the trouble in the first place. If it can't be done 100% 'right', should I bother?

I put my efforts on hold so far. Ansible improved greatly (especially the documentation) lately, but .. it still feels cumbersome and hackish for my usecases.

Re: Fucking Shell Scripts

#139

Post by stevekemp »

dogas wrote: post #16

Coauthor here. Well, this is a surprise! This project was mainly borne out of our frustrations with Chef and then Ansible for configuring our servers. A few thoughts: 1) This project is incomplete and is more of a concept than anything. We wrote it literally in an afternoon, and were giggling like schoolgirls the whole time. 2) There is value in what Ansible provides. It does a lot of things for you. FSS did not repl…

You definitely win points for working over pure SSH, I love tools that do that. (Which include 'fabric', 'ansible', and similar.)

Me? I like perl and I decided I'd write something that just executed "primitives" locally. Then setup a flexible system of pulling them from git, via rsync, etc.

My tool is largely ignored, but modelled after CFENgine 2.x, and is here:

http://www.steve.org.uk/Software/slaughter/

Re: Fucking Shell Scripts

#140

Post by herokusaki »

mercurial wrote: post #135
mattjaynes wrote: post #81

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

> A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely. They're idempotent only as long as the configuration stays the same. If you removed this "apt: package=XXX state=present" line, XXX is not going to be magically uninstalled, but you may have a nasty surprise the next time you attempt to…

Are there VPS providers that offer NixOS by OOTB?
Post reply on HN