ghjm

The question here is what motivates individual developers to write big projects and then release them as open source. I think vague dreams of million-dollar deals are part of this for a lot of people. As the developer community becomes more aware of what a grind open source maintainership is, people are already less interested in taking on that responsibility. If we also prevent big money buyouts from happening, I wonder what's left to motivate a future developer to create the next redis.

Maybe there's already a way to do this, but it seems to me that it would be useful to be able to refer to the answer on a previous line, like the Ans key on a TI calculator. So:

2 + 3 (=4)

Ans * 2 (=8)

Out of curiosity, would you be concerned with giving a managed service vendor all the passwords to everything in your infrastructure?

Even if your playbooks run everything as sudo, that doesn't mean you have to grant AWX/Tower users the ability to create arbitrary playbooks or run anything else as sudo. You certainly can do that, but the point of the RBAC feature of Tower is that you don't have to.

You are absolutely correct that these factors should be carefully considered prior to any deployment of AWX or Tower. You are granting Tower a lot of authority to your networks and systems, and should not do so without good reason. If you don't need the features of AWX/Tower, then the best practice is not to use it. There's a tremendous amount you can do with Ansible itself, without AWX/Tower, and lots of people use it happily that way.

That being said, I think you are overstating some of the risks. You don't need to grant every Tower user root access to everything on your network. If you're at a scale where Tower makes sense, you probably already have some sort of separation of privileges. I agree that a malicious Chrome extension could do a lot of damage - just like it could with all your other management tools like DRAC/ILO, network equipment GUIs and so forth. Yes, every web application carries the risk of CSRF/XSS or other vulnerabilities, and Tower is not immune to this, but we do spend a lot of time worrying about it, conducting audits, etc.

If your operation can succeed with nothing but a sudoers rule and command-line Ansible, then by all means use that. Nobody wants to force AWX/Tower on people who don't need it. But if you do need the feature set of Tower, I think it's one of the safer options available.

Yes - you can either use your own tooling to distribute your playbooks to the hosts and then run ansible-playbook using the 'local' connection method, or you can use ansible-pull, which retrieves the playbooks from an scm (git) repo and runs them locally. You don't need AWX/Tower for any of this.

Don't you have to give Jenkins the same credentials and attack surface that you would have had to give to AWX/Tower?

With the Jenkins model, can't someone just add a job that dumps the execution environment, and get all your credentials?

I would like to object to the following statement from the article:

> While lifeguards are taught all the possible signs of a person who is drowning, pilots don’t receive elaborate training on all the things that can go wrong, precisely because the many things that can go wrong so rarely do.

In fact, pilots are given extensive training in the failure modes of their airplanes. When Casner got his private pilot license, he should have been told to memorize the emergency procedures for his airplane. De novo private pilots are not given the same level of training as airplane pilots, but failure modes and "interesting-looking instrument panels" are crucial components of instrument training.

More generally, I don't disagree with his conclusions regarding the problems with cockpit automation, but they are hardly novel - the industry has been aware of this for years. However, the service life of an airliner is measured in decades, and the regulatory environment, for excellent reasons, doesn't allow us to change the avionics on existing airliners without re-certifying the new systems and re-training all the pilots.

Last but not least, I'd like to point out that even if the airplane is on autopilot, there is still plenty for the pilots to do. For example, they are supposed to brief the instrument approach procedure and the missed approach procedure every single time they fly it. A lot of pilots relax this discipline (if you've flown into the same airport hundreds of times, it's hard to argue that re-reading the procedure yet again has much value). But relaxing it to the point of just idly chatting all the way down the glideslope? That's not a problem with the cockpit systems, and it's hard to see how better human factors would have magically turned these incredibly irresponsible people into good pilots.

"Each agency may promulgate regulations, pursuant to notice and receipt of public comment, providing for the aggregation of certain requests by the same requestor, or by a group of requestors acting in concert, if the agency reasonably believes that such requests actually constitute a single request, which would otherwise satisfy the unusual circumstances specified in this subparagraph, and the requests involve clearly related matters."

They would just publish one response and send us all a link to it.

They want to be able to take large donations from wealthy contributors, without (a) having to pay tax on them as income, or (b) having to follow the normal reporting requirements for political groups.

I agree that the Mac packaging system is wonderful for installing programs, but I think this is because it does not even attempt to solve the problem of uninstalling programs.

Arguably, this is a good trade-off because users rarely uninstall software. But it means that if you ever become uncertain about the configuration state of a Mac, you're probably going to have to reinstall from scratch.

Just as a point of order, Windows has dynamic library versioning and multiple loading at least as good as sonames. This was first introduced in Windows 2000, 13 years ago.

In some jurisdictions, the owner of the truck can sue you for damages if the structure was constructed with the intent and purpose of damaging the truck.

Unless you're trying to hire geeks who can fit in to a standard office environment without weird platform demands. In which case, insist on .docx.