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

51–60 of 180 posts

Re: Fucking Shell Scripts

#51

Post by agwa »

sbt wrote: post #38
agwa wrote: post #28

The nice thing about an approach like this is that you don't actually need to use shell for your scripts - you could use Perl, Python, etc. The point is you can just write in whatever scripting language you like/gets the job done and not need to worry about learning a new domain-specific configuration language. Does anyone else here see value in a configuration management system that centers around installing files a…

This does not manage a server, it provisions a server. The whole point of configuration management software is to bring your software into a desired state from any actual state the server may be in. This rests on the notion that configuration drifts, i.e. for long running services a server gets misconfigured eventually for a variety of reasons. Bottom line, if you are just running a small startup with a few servers a…

The CM system I'm using "journals" every change it makes to the system, so if you later remove or change a file or script in your CM repository, it undoes the old change. This eliminates virtually all configuration drift, provided you aren't making changes by hand outside of the CM system (which you should never do anyways).

This system has been managing about 100 servers and several hundred desktops at a single site since 2009, so the approach does scale. It has some problems that declarative solutions like Puppet solve, but at the same time it solves problems that Puppet/Chef/others have.

Re: Fucking Shell Scripts

#52

Post by dasil003 »

_Adam wrote: post #43
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…

I can imagine someone proposing this at some meeting with managers. "For our next product, we're going to use FUCKING SHELL SCRIPTS for configuration and deployment". What would the managers' faces look like... I wonder if this is what you guys had in mind when you came up with the name

Just say FSS, managers love acronyms!

Re: Fucking Shell Scripts

#55

Post by mpdehaan2 »

drewvolpe wrote: post #11
akerl_ wrote: post #6

So... this is basically just one module from Ansible, plus some obscenities?

Which is another way of saying it's Ansible without all of the stuff you don't need (plus obscenities).

We can add obscenities if you want :) We do have cowsay integration though. (There are some questionable cowsay modes!)

That all being said, the thing missing here between any of these tools is most obviously the resource model -- and the templating system and where you put variables and things to manage variance between systems. Thus, it will blast out some commands for you, but that is the easiest part of the equation -- not too much different than say, doing something from Capistrano or Fabric.

Even in Ansible, that's the part we built first.

Achieving idempotence in shell scripts is the reason most people move away from shell scripts, and also ... well, the desire to program less :) Then you'll want the rolling update features, or provisioning, or dry run, or a way to pull inventory from cloud sources, or... and you'll streamroller a bit.

The balancing act for us is achieving the right level of features vs language complexity and keeping in that sweet spot.

I still think you should have an easy time getting started, see also things like http://galaxy.ansible.com for community roles to download to go faster -- most people should be able to do basic things in a few minutes. The script module in particular is a great way of pushing a f'n shell script :)

http://docs.ansible.com/script_module.html

(full disclosure: I created Ansible, but I did not shoot the deputy)

Re: Fucking Shell Scripts

#56

Post by isaacb »

I really like the idea, but the name is somewhat offputting, especially if I were in a position where I had to sell it to management (luckily I'm not). Will definitely give it a whirl, but I strongly suggest considering a name change.

Re: Fucking Shell Scripts

#57

Post by fleitz »

colechristensen wrote: post #35
nawitus wrote: post #13

Earlier quoted context omitted.

Typically shell scripts are fine in the beginning, but over time the complexity rises and it becomes an unmaintanable mess, and you'll end up reimplementing it in a proper programming language. Shell scripts are not easily portable either, unless by "portable" you mean "works in Linux". Node.js scripts, for example, really (mostly) work on Linux and other platforms like Windows. Until you hit some nasty "path is long…

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....

Re: Fucking Shell Scripts

#59

Post by cmbaus »

qwerty_asdf wrote: post #10

"Wanna just use fucking shell scripts to configure a server? Read on!" Step 0: Install the gem # gem install fucking_shell_scripts # gem: command not found wat.

I agree. This would be far more awesome if you could install it with a fucking shell script. It is called fucking shell scripts. Not fucking ruby scripts.

Re: Fucking Shell Scripts

#60

Post by obsurveyor »

If you're going to use ruby, you may as well commit and use sprinkle. You still get to use all the shell scripts you want and you get the deployment power of capistrano. I've really enjoyed using it for my small provisioning requirements.
Post reply on HN