If you haven't yet check out the single for that song. It goes really deep into the aesthetics and experiements with Trent Reznor's sensibilities. It's like Reznor shacked up in a cabin for the weekend to bang out some remixes. Warning, they get dark and noisy fast.
I went to the Ansible conference in London last year. We were looking into whether or not to use Ansible, thinking that going to the conference would shed some light.
To be honest, we were put off by the (I use this word advisedly) fanboyism. There was a huge amount of "Ansible is amazing!" and (in my opinion) not much actual substance. It felt like there was lots of back-slapping.
Toward the end of the day there was a presentation which presented features (possibly new ones) demonstrating how they were contorting (presumably declarative) YAML into a new programming language with control structures (and templating, my memory is hazy). It felt like "our deployment scripts were over-complicated so we took out the complexity and put it in a declarative non-executable format. Then we had to put the features back because we needed them after all, except now it's in new less powerful language".
Anyway, the conference was informative, but probably not in the way intended.
That said, if you can give some substantial reasons why to use Ansible, it would be great to hear them.
This is pretty much where I'm at. By the time you bolt back in everything that Ansible removes "for simplicity" because you realize that, hey, you stepped on that rake and would like to not step on it again, you've more or less reinvented Chef with YAML (I forget who around here called YAML the new S-expressions, but it's uncomfortably true) instead of a usable programming language as your DSL. The overwhelming volume of the community (edit: I called them "fanboys" before, and that's not fair; I think they're unreasonable but I'm not in their heads) makes me wonder at times whether or not it's trying to ignore picking the slower horse by being really enthusiastic about it.
My current client paid me to drop Ansible and rewrite the experimental Ansible service in Chef, and it's under half the lines of committed code in our repo and they don't have to deal with the bogus state of Ansible dependency management.
>That said, if you can give some substantial reasons why to use Ansible, it would be great to hear them.
I'm using Ansible, but with a handful of powerful plugins that I developed and haven't contributed back (sorry, but I don't have the time to do support for that ugly-ish code).
I use it because:
- Having an agentless setup is ideal (anyone that tells you that Chef/Puppet agents have never cost him/her time is either a new user or trying to sell you something)
- The YAML, then Jinja2 parse can be annoying, but it's ultimately not that painful once you're used to it
- N-number of SSH Bastion/Ansible-runners fed from a git branch scales better than Chef Server
- I'm a Python developer and I've found it reasonably easy to "monkey-patch" in behaviors that I prefer/need
- Ansible doesn't force a workflow on you, so you can just focus on "getting shit done"
- I plan on taking the YAML that my team generates and feeding it into a different system and the fact that it's in a popular format makes that easier than the alternatives
I had the same experience as you after attending an AnsibleFest and dialed-back on my time spent supporting users in IRC and contributing to the project after. I expected a collection of hackers and instead came away disheartened by the number of sales or marketing bros/chicks and how corporate-smarmy it all felt.
> - Having an agentless setup is ideal (anyone that tells you that Chef/Puppet agents have never cost him/her time is either a new user or trying to sell you something)
An agentless setup is ideal iff you have an effective method of service discovery and strongly consistent data storage. Most of my clients don't, and chef-server is the closest thing. My own systems use chef-zero, which is agentless; since they're generally immutable servers, this just gets dropped into AWS userdata, much as I do when I use Ansible, for a one-shot configuration and I'm off to the races.
> - The YAML, then Jinja2 parse can be annoying, but it's ultimately not that painful once you're used to it
It's significantly worse than "if (var) { block }", though, yeah? I mean, yes, it works, but I think that having a programming language with conventionally understood data structures and functions, to say nothing of a parsed configuration spec that you can do transforms over, is a decent bit more useful in the general case. Faster to write, easier to read, and, over the long term, I tend to think it's easier to maintain.
I mean--I'm a programmer. Programming things is easier for me than maintaining YAML files. =)
> - I'm a Python developer and I've found it reasonably easy to "monkey-patch" in behaviors that I prefer/need
This is really the big plus to Ansible that I can see; if you're a Python person and not a Ruby person, I can see some value here. (I am a Ruby person.)
> - Ansible doesn't force a workflow on you, so you can just focus on "getting shit done"
Chef Zero here too (though Berks tends to be helpful anyway). Running chef-zero over `ssh` is a pretty fair approximation of what most folks use Ansible for.
All that said, I'm not saying you shouldn't use Ansible, and I dig that you have some perspective about it. Just offering a different point of view. =)
>An agentless setup is ideal iff you have an effective method of service discovery and strongly consistent data storage.
Sure, or use tag and/or have AWS (aws can be used as a node classifier).
>It's significantly worse than "if (var) { block }", though, yeah? I mean, yes, it works, but I think that having a programming language with conventionally understood data structures and functions
I'm not sure what you mean -- it's YAML + Jinja2. It's just powerful enough that you can hand it off to an Ops team and they can get stuff done.
>I mean--I'm a programmer. Programming things is easier for me than maintaining YAML files. =)
Agreed. I actually hit a point that I said "fuck this" and almost just wrote chunks of python to stitch together with jinja includes, then base64, send and run. I didn't because with Ansible, I can just point others at a doc that I don't maintain (not to say the docs aren't garbage).
>(though Berks tends to be helpful anyway)
Ha -- petty, but I hate the amount of memes like "berkshelf" in the Ruby/Chef toolchain. "berks" is enough to make me involuntarily scoff.
>All that said, I'm not saying you shouldn't use Ansible, and I dig that you have some perspective about it. Just offering a different point of view. =)
Didn't take it that way :) I spent over a year with Chef+agent/Chef-zero/Chef-solo, about a year with Puppet, before using Ansible. I find that Ansible "just goes away" with less effort and doesn't just grow until it eats your entire ops team.
There are a lot of reasons to use ansible, but in my opinion the one thing that sets it apart from other orchestration frameworks (saltstack, puppet, chef) is that it's agentless. You don't need anything installed on the node servers except for ssh and python 2.4+ (which means pretty much any major distro but coreos). There is no master node to keep up, and no specialized daemons running on the managed nodes.
Because of this difference it's really easy to incorporate into an existing infrastructure with no current frameworks. Pretty much every job i've had started off with a bunch of existing servers they set up ad-hoc, which we then wanted to add automated orchestration to.
It's also really easy to use your defined playbooks against different contexts (just use the hosts file switch to run against staging, or a cluster of test vms, or a bunch of lxc containers).
Chef needs to be installed, but it can be (easily!) run in an agentless mode via chef-solo or chef-zero. It can be installed from Rubygems and requires no master node.
I think using sshkit and chef-solo you could easily achive the agentless model ansible provides with a more mature toolset and community. I never really understood peoples aversion towards agents though. You literally can create a golden image with chef-client and your done. There is very little cpu or memory overhead from the chef-client and it only runs when requested unless you run it in daemon mode. I think Ansible capitalized on people's wariness/lack of experience using chef rather than there experience causing them to look for an alternative.
Sure, even salt supports an agentless mode, but these are designed as afterthoughts. When you look at all the agentless mode versions of these tools you find that it doesn't fully support everything the framework is capable of (i.e., see the main page of chef-solo). Thus, the adoption is low and you'll likely find breakage as the tool matures (new features being developed without consideration of the audience using it in an agentless mode) and you're likely to find little help when you ask for it. Contrast this with ansible, where this is the basis of the framework, so everything built around it works in agentless mode.
So no, nobody is saying you can't run chef/salt in agentless mode, but in practice nobody wants to because it's a lot of work. And it's not like ansible doesn't also run in a managed-by-master-node mode, that's the entire basis of ansible tower.
And to be clear, it's not that I like ansible because it's agentless. It's because the benefits of the tool being designed-from-the-ground-up as agentless leads itself to beneficial properties.
> You literally can create a golden image with chef-client and your done
This is a lot more work than you let on. That client needs to be configured to point to a particular master node. So yes, you can create a golden image, and it'll talk to one master node, and run on one platform. Good luck getting your golden AMI to run locally in VMWare, or virtualbox, or in a LXC container. Good luck adding in the functionality to make your client dynamically select a different master. It's not impossible, it's just not dead easy. The fact that this is an annoying thing to do is proven by the existence of salt-bootstrap (it's a tool that SSH'es into a node and sets it up as a salt client, hrm, now where else have we seen a tool that manages a node only using ssh?)
> I think Ansible capitalized on people's wariness/lack of experience using chef
I think this is a rather unfair generalization to make. I've personally had many years of production experience with chef/puppet/fabric and the only reason I have no actual production experience with salt is because ansible came out soon after (I still follow their development with interest). In my experience, the people I know who use ansible are neckbeard admin types with battle scars from other orchestration frameworks.
I can only compare Ansible to Puppet, but I've had great success with rewriting a ton of hacky bash stuff directly in Ansible and having it feel much more 'maintainable.'
Perhaps if you're already using puppet/chef/salt it's not completely worth it to just suddenly switch to it, but it does feel "simple" to use; in my opinion it's worth use over Puppet solely due to the fact that you can really crank up the errors and get good messages.
Yeah. Same here. I used puppet but it's documentation is horrible (at least for newbies),the errors are not informative, the simple stuff is complicated and the puppet did not run things in order IIRC. In the end, I had a very fragile puppet based system and some bash scripts which I could not rewrite in puppet.
I moved everything to ansible and couldn't be happier. The documentation is excellent and since ansible executes in the order you specify, the flow is much easier to follow
I had the same problem with puppet (which I ran agentless). One downside to Puppet that Ansible solved for me was no dependency graph. When Puppet breaks, it's error messages are sometimes completely uninformative as to why or even where. When Ansible breaks, you know exactly where it broke and usually why.
The second downside of Puppet was that it freaks the hell out and refuse to work if it sees the same command in two different places. If I have two roles and in those roles I'm installing a single package in the same manner, Puppet throws a wobbly and won't run, even if the conf for them is identical. The official answer is "write a module for anything used twice", but sometimes it's just so trivial.
In any case, I think Ansible is certainly much better suited to small deployments than (agentless) Puppet.
I went to Ansible Fest 2014 in SF. IMO, the conference was pretty worthless outside talking to DeHaan and a few of the core developers. It was very sales focused and lacked much technical depth (what tech conference actually goes into any depth these days?).
This being said don't let that deter you. Ansible itself is an excellent project. I won't rehash what's already been said but both our dev and ops teams were able to transition off Chef and onto Ansible within a week. The time to onboard is miniscule compared to Chef, Puppet or CFEngine. There's been very little friction building customizing modules or contributing to an otherwise fantastic community.
As someone who moved from CFengine to Puppet to Chef and now Ansible I've been extremely happy.
FWIW, I'd argue that it's easier to fix a Python/YAML/Jinja error in your Ansible play/role/template than it is to try to track down attribute precedence and override issues or Ruby behaviors which aren't very Ruby like in Chef.
Sort of agreed. I'm not convinced the alternatives are actually that much better, and I really like the agent-less design, but it has tripped me up in unexpected ways often enough to be quite wary. ("Why doesn't this variable substitution work?", core modules clobbering config files because they are not allowed to contain specific magic strings, ...) And a lot of it seems like stuff that a better encoding than YAML could probably fix. Right now it feels like an awkward mix of a programming language and a not powerful enough encoding that's great for simpler stuff.
Let's not dream, let's get started! A few challenges (list gets longer every day, some asymmetric features), but I think it's a great idea. Since it's got to be grown/updated constantly, where should it live, maybe a github page? Benchmarks is pretty close via this: https://github.com/GoogleCloudPlatform/PerfKitBenchmarker I'm interested; what parts do you think you could contribute? It strikes me as a thing that's far more valuable if the community does it.
Spendology is the company >>> spendology.net. Our new service is called Blue Apex Digital. I just used Google DNS and Google Compute Engine to publish >>> blueapexdigital.com. Thanks GCP!
I do have a quick question. I am running a LAMP stack with the A standing for Apache. I put an "Index.html" and an "Index.php" file in my "www" folder. I realize that new files append old files. However, I want to add a ".htaaccess" file with DIRECTORY prioritization for the PHP file over the HTML.
I tried copying an htaaccess file via the gcloud command line tool but I got an error. I've been looking through help, faqs, and searched but haven't seen a solution as of yet. Did I miss something? Thanks!
fwiw, this is currently my favourite site to check for possible optimizations, I ran the test so you wouldn't have to wait 30 seconds in the queue ^_^ http://yellowlab.tools/result/e7v314ikq3
I have noticed that all google cloud services now require credit card information for validation. Can this be be made optional and instead rely on their Gmail accounts ? (Especially for people just wanting to tinker with new services for fun)
I suspect that it's unlikely that google can remove this because bad guys tend to spin up many free trial instances and do bad things (sharded bitcoin mining, DDoS'ing, etc). Privacy is #1 so they aren't allowed to look inside your machines or inspect your traffic...so that leaves billing / such metadata to fight abuse.
That makes perfect sense, and I don't argue with this logic at all. But since you're here, I'd like to say something (that isn't horrible :P) that I've actually wanted to [have the opportunity to] get out there about GCP for a while now.
The "Heroku-style free" tier is likely to be all I can manage for the short to medium term future, due to a variety of factors.
As a result, the two go-to systems I would turn to if I need code hosting are Heroku and OpenShift, and I have accounts with these platforms (although I'm leaning toward the latter lately). I am yet to do anything generally interesting with them myself, but these are the systems I take into account when talking to others, because I have no experience with GCP. (I wonder if this is true for others too, and how big that number is.)
I have zero idea how Heroku are fending off precisely what you refer to. I've heard about situations where individuals' AWS accounts have been hacked by automated systems that spin up "instances with everything", but once it was established with billing that the account was hacked, the charges (which in one case were 5 figures) were fully reversed. Perhaps this fact is relevant here.
I think the problem can be solved before it (theoretically) gets to that point, however.
Serving up webpages, doing the occasional database transaction, etc, produces a significantly different CPU load than bitcoin mining does. I don't consider instance CPU usage monitoring a violation of my privacy, so I think it would be perfectly fair to throttle back continuous high CPU usage, but allow for short bursts of high usage. (In fact, I think this kind of thing is already standard...?) For bonus points, make the system track instance CPU usage and adjust its thresholds to allow for periodic high burst usage :P (since, thinking about it, masquerading as a web server and doing 30 seconds of mining every 5 hours is going to work out to zero gain).
I wouldn't consider it at all unfair to offer a free tier with exceptionally aggressive CPU-time QoS; in fact, it would probably suit me (and a lot of other people) perfectly, giving the funemployed community the option to do things like spin up fascinating new environments like Erlang, Dart, Rust, etc, and play with these environments (which are not yet available on Google's cloud hosting infrastructure) for web serving and similar. (For more bonus points, I'd extend the heuristic CPU-time tracking I mentioned before to classify instances as "friendly" over the long term, and let them have exceptionally low latency! :D)
In short, there's a whole demographic of people out there that you're definitely excluding, including people like myself who are just at the "messing around" stage, to nervous types who don't like deadlines and run from the "free for X period of time" part of GCP.
I realize and recognize that your response here is only your opinion, not Google's, and I'm very happy to respond here or via email (my address is in my profile) if you'd like to discuss any of any of the things I've said. ^^
We're building a team of senior architects for breaking down interesting customer problems, building up technical solutions that help those customers succeed, and then publishing them for the world. We're the folks building this: http://cloud.google.com/solutions
It's an interesting problem - the issue is that our trials are both money & time based ($300 for 60 days). So technically you've "used" your trial even if you do nothing for 2 months.
We do appreciate the feedback and are looking hard at the right next way to solve this. If it wasn't for bitcoin miners and/or bot nets, this would all be a lot easier :(
Ah, interesting -- I thought it was for a year. Then I don't feel like I'm missing out quite so much, because I would have a hard time spending that much credit in 2 months anyway :)
I loved this movie, and immediately commented to a few movie-buff friends of mine that I was certain that they'd get an oscar for the sound editing. The actual movie edit was artful and amazing, but the sound edit.. talk about meticulous.. every single drum hit?! Called it! http://www.nabshow.com/thought-gallery/oscar-winner-ben-wilk...
Sorry to be pedantic, but Whiplash won the Academy award for best sound mixing; the award for best sound editing went to American Sniper. Mixing involves the spatial and tonal quality of the sound; editing the temporal and semantic quality.
But either way yes, it is very meticulous, and I think you'd be even more shocked to look at the project files, because each individual sound you hear in a film often involves multiple layers of sound or multiple treatments of a single source sound through different mix busses. As a rule of thumb there are bout 10 edits on the sound track for every cut you see on screen. Thankfully there are some tools available to partially automate the process, but in the it requires a huge amount of work and near-endless reserves of patience.
Source: movie sound is what I (mostly) do for a living, though I haven't won an Acamdemy award for it.
Have there been blinded tests done to gauge audience impact? I hobbied a bit with sound and when I see, for instance, the result of "professional mastering" side by side, I've often thought the pre-mastering version was better. No doubt this isn't always the case, but it makes me wonder. Especially given how much myth and superstition seems to happen in audio, even coming from pros.
Not to come across as rude - I'm just ignorant and curious.
Not really. There are some loudness measuring standards and conventions about the 'right' level for dialog vs peak volume, but really it's down to the combined tastes of the mixing engineers, the director, and the producer, with the latter having priority. Thus there are fads about particular sounds (eg notice how every big exposion in a sci-fi film now is announced with the same falling sub bass sound...) and pressure to push the volume envelope on action pictures (Michael Bay is notorious for this sensory overload approach to both picture and sound).
The same thing you said, though in a more abstract way. By temporal I mean where they go on the timeline, and by semantic I mean the content of the sound. Much of the time what you hear simply matches what you see on the screen, either from production sound or from a sound effects library or by a foley artist, eg if you see a glass bottle smash on the floor you will probably just use a natural sound for that. But then you have to look at what it means in the context of the story - suppose the bottle is being smashed on the floor by an alcoholic who has finally decided to fight his addiction? You migh choose to emphasize that with music, or you might emphasize it by layering in other sounds from elsewhere in the soundtrack or some purely expressionistic sound like a heavy lock opening. Also, you'll frequently use sound to speed up or slow down the action by transitioning into the next scene before or after the camera cut.
Mixing involves setting the levels of the different sounds, but it also includes some decisions about how the sound moves, what sort of reverb and coloration are used (spatial) and how it's balanced against the music, how it's EQed (tonal).
Sound editors are responsible what to include in the track and when, sometimes much more or less than what the mics on set picked up.
Sound mixers are like sound engineers in the rest of the business, crafting relative levels, dynamics, tonal transformations like EQ, and spatial transformations like reverb.
Wow! I was instantly sure that this came down to someone at some DAW making a few million little tweaks on individual drum hits... Thanks for the correction and the detail!
Oh I think it amounts to the same thing. Automation can help but it's fundamentally painstaking stuff. As a general example, imagine someone walking down the street, but you don't like the original recording for some reason and decide to replace it. All the footsteps have to be matched up and that's tedious. There are plugins that will match the peak sounds of one recording to another to save you aligning every footstep (or word if you're replacing dialog) but you often end up having to do things by hand. Then if it's one person alone the footsteps may sound too simple so you need to add some fabric swish for their clothes. Or if it's two people, you need to have two different sets of footsteps which is really really annoying. Three people walking is fine because nobody can keep up with that so you can completely fudge the timing and nobody will notice.
The big challenge in movie sound is not to distract from what's going on in the story, which often means throwing away sounds that are present in the real environment but with are excluded by the picture frame, and whose presence thus becomes confusing to the audience because they don't know where the sound is coming from. I hate shooting in restaurants for example, because most restaurants have very loud refrigerators and of course most of them can't be switched off for food safety reasons. When you eat dinner don't notice this because there's music, other diners, maybe the person(s) you went to have dinner with, and the sound of your own body chewing and swallowing - so your brain just filters all the background noise away and lets you focus on the conversation or whatever. But when you watch the same thing on a screen, your brain is like 'what's that big machine noise? why does the lead actress sound like a farm animal? why is it all so echoey?' Total nightmare :-)
I haven't seen Whiplash yet but I'm looking forward to it.
