HN user

ghjm

124 karma

[ my public key: https://keybase.io/ghjm; my proof: https://keybase.io/ghjm/sigs/pA6yieTDyTYohxj3Ejth6eD-UcToXFwYNp7ZZE_cxe8 ]

Posts0
Comments29
View on HN
No posts found.

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.

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.

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.

Ok, so here's the problem. None of the recommendations in this are actually actionable. Consider:

- Be Interesting

Well, the company either is or it isn't. If you're an auto parts distributor who needs to convert your application from Cobol on AIX to ASP.NET on Windows, then well, you aren't really very interesting. And there's not one thing the recruiter can possibly do to change that.

* Care

Perhaps you genuinely care, but what if you don't? The recruiter is human too. Maybe they just want to do their job and go home. You can't decide to genuinely care. You either already do, or not. And we're saying they absolutely must not pretend to care. So ... the only remaining option is not caring.

* Acknowledge Applicants

I don't think Matt appreciates the sheer volume of resumés that come in for an advertised position. I know some HR departments that insist on sending an acknowledgement for every received application, and they spend a lot of man-hours on it, and are constantly having to defend this practice to executives. And honestly, why does the typical badly-formatted, ungrammatical resumé actually deserve a response, anyway? Matt may be a special unique snowflake, but trust me, all those other people aren't.

* Get to Know Programmers

You can't do this without getting to know programming. And the whole point of specialization of labor is that you shouldn't have to. You can hire a doctor, lawyer or plumber while knowing nothing about plumbing, doctoring or lawyering. Why should it be different for programmers? As a profession, why should the rest of the world bow to our desires, instead of us creating a better product for them to buy?

* Let Me Code, Dammit

This is the one piece of good advice. The best way to interview in any field is to engage the applicant in job-related task behaviors and observe the results. With programming, we're lucky that this happens to be pretty easy. But I don't understand how this squares with the earlier rejection of having the applicant code a Fibonacci function.

Well, with both Chrome and Firefox on rapid mandatory release schedules, all I can say is: Get comfortable supporting IE for large enterprise customers forever.

How I Fired Myself 13 years ago

This is correct and is the way it should be. So how come the programmers are always politically gunning for the keys to the production server cabinet, where you do have to be afraid to break things?

Stupid, Stupid xBox 13 years ago

They also lost more money in years prior. I think they're in the black since inception, but not by much.

Stupid, Stupid xBox 13 years ago

The overall division really did lose $4 billion that year. In 2011 they made $1.3 billion. Overall, I think they're about at break-even for the program since inception.

[dead] 13 years ago

People do understand that the certificate expiring does not affect security or encryption in any way, right? All it means is that some registrar wants to be paid now?

Okay, I'll admit it. I don't actually know what devops is. I know what developers do and what sysadmins do. Is devops just a buzzword for one person who can do both? Or does it mean something other than that?

Hacking my Vagina 14 years ago

This is a really cool hack, but my problem is that I don't understand the sex part. What's better about waving your hands around to control the motor speed, vs. using a dial?

This is not out of prurient interest. I just can't understand the engineering without understanding the use case. Maybe you have to be female to get this?

The content matters too. They are certainly spamming you if the email they send just says "<Person You Know> just sent you a message on <Service>!" and force you to log in to read the actual message. Just put it in the email, willya?

Suppose you could use a balloon to get to LEO altitude. You're still not in orbit. Anything that actially is in orbit will come hurtling at you faster than a bullet. Most of the fuel used in getting to LEO is used to achieve orbital speed, not orbital altitude. So the question of ground launch vs space launch is really one of where your engines operate most efficiently, or if you can avoid air friction in the dense lower atmosphere, or that sort of thing. Baumgarnter was nowhere close to "10% of the way to the ISS."

It may well be that cellphones present no danger to airliners, but I have had two occasions when forgetting to turn off a cellphone produced interference noise in my headset while flying a C172SP. Of course it was my own cellphone so I just turned it off.

Maybe it's not a problem on airliners because they are better shielded, or just bigger, than a Skyhawk. But I can say first-hand that it is at least possible for a cellphone to interfere with an aviation radio.

I can assure you that men with daughters understand the problem.

You can't really take reddit as a good sample of men in general. 56% of reddit is age 18-25, as compared to about 7% of the overall US population.

The reason this is a problem is that young adults are much more likely than average to exhibit poor judgment, inaccurate risk perception, perceived invulnerability and egocentrism. This has been shown in countless studies. Of course it is only true statistically, not necessarily of any particular individual.

So yes, reddit is full of hurtful crap, and it gets upvoted in the default subreddits. And you can legitimately take that as evidence that young men don't understand the problem.

But, eventually, they do grow up.

You are saying that Oracle's goal is to make sure that CentOS customers can access the resources of a billion dollar company in order to get security patches on time.

If that were all that was going on, then Oracle would just provide funding and engineering support to CentOS.

Since you aren't doing that, one of two things must be happening:

1. This is part of a long term strategy, which means it will somehow make a play for my wallet on some future date.

2. This is not part of a long term strategy, which means it is a low-level initiative. Most likely it will chug along until the responsible middle manager retires, transfers or gets bored with it. If by some happenstance it becomes successful enough to attract the attention of top management, then goto #1.

Bottom line - Oracle is a business and wants my money. I know it, and you know it. Using free products from Oracle is like accepting a favor from Tony Soprano. Sooner or later, the bill comes due.