porpoisemonkey

> I have to assume they made similarly confused choices with their Consul and Nomad setups as well.

I found their explanation about why they wrote Corrosion confusing since most Hashicorp services (including Consul) already support data sync via a gossip-based protocol (Serf).

It doesn't sound like this would have helped in this particular case since they were unable to contact the customer.

To reiterate half of what you've said, but maybe in a slightly different way, the defense security clearance process is designed to determine how likely you are to be incentivized or coerced into revealing classified information.

The point of the deep dive is not to prove you've always been an upstanding citizen, but to look for factors that make you an easier target for foreign intelligence services such as:

1. Do you have any financial problems that could make you easier to buy off? (Bad credit, gambling problems)

2. Do you have any (real or perceived) addictions that might impair your judgement or can be leveraged against you? (drugs and DUIs)

3. Are you currently attempting to hide any criminal activity that you could be blackmailed with?

4. Do you have any sensitive foreign connections or other possible allegiances?

That’s an unfortunate situation, but I’m not surprised to hear this.

I worked in a single-location pizza shop when I was in high school and there is a lot more customer-benefitting coordination going on between the inside and the drivers than may be obvious. (These applied to my shop; I’m not sure if the big chains actually do this kind of stuff.)

* Most shops have a delivery radius of less than 10 miles and it’s pretty impressive how detailed a driver’s address knowledge of the area can get after just a few months.

* The people taking orders over the phone were often delivery drivers waiting between runs and will clarify addresses and locations as well as delivery instructions (drop off locations, gate codes, etc.).

* The inside crew will typically batch deliveries headed for the same area and time the oven to get all the food out around the same time.

* If for any reason a delivery can’t be made (car accident, flat tire, made a wrong delivery and no longer have the right food for the order, etc.) the driver will call the shop which will remake the order and send it with either another driver or an inside crew member.

Not the OP, but in one of the smaller companies (~30 people/~12 engineers) you describe that's currently looking for a tool like this.

I can't actually see the pricing because it's behind a nebulous "contact us" link, but if this is more than about $5/user/month I would definitely balk at the price.

Larger companies already have dedicated platform and tooling teams with enough technical talent and bandwidth to build this sort of solution (I've seen something eerily similar to this at a previous employer that had about ~75 engineers). IMHO it's the small companies that need off the shelf incident management because they have very few people to dedicate to solving this problem and need a way to manage the communication chaos that incidents can cause.

> Also, iCloud photos are not encrypted[2].

According to the table on the second link iCloud Photos are encrypted on the server (at rest). Am I missing something?

I'd like to see them make their customers whole by forcing them to refund the monthly payment for every month that a customer with an "unlimited" plan was capped or throttled.

I think that people perceive being on call and having to work with messy legacy infrastructure as a restriction on their personal freedom and an anti-perk. We also don't compensate well for oncall shifts so that might be part of the reason that people see it as a lesser form of work and not as a special status that's only given to the best engineers. At other organizations it may be different... I hear FAANG companies compensate their on call shifts quite well (typically a percentage of base salary banded by SLA)

> I can't imagine that responsibility for MY code in production (and delivery of the said code to production) lies on a different team/department that are possibly not even on the same floor/building I'm at.

I recently did some interviews with our devs to find out what features we could add to our platform that would provide them with value. The result was interesting and I found that people typically fall into one of two camps: 1) I want to know everything about my deployed service and have tools that alert me and allow me to intervene, or 2) I don't want to know anything about the deployed service runtime and expect operations to handle my issues and alert me when there's a problem.

It sounds like you might be in the former. =)