What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it again at some point, but working in a team through Github PRs that was my main barrier to entry.

It might be OK to place some bets on an initiative or feature, but if we all understand we're placing a bet, this is an area to load up on debt and really minimize the investment. This also requires an org that is mature about cutting the feature if the bet doesn't materialize, and if the market signal is generated will reinvest in paying down the debt. And also has the mega-danger territory of a weak market signal, where it's not clear if there is market signal or not, so the company doubles down into the weak signal.

Also these bets shouldn't be done in isolation in my view, well executed product and market discovery should also provide lots of relevant context on the ROI.

I suspect this is most apparent on things like meeting culture. Something happens and all of a sudden there is another recurring meeting on the calendar, with 15 attendee's, costing x dollars in wages, that produces no value for the customers because the lesson was already learned.

Or when reacting to an incident of some sort, it's so easy to have a long list of action items that may theoretically improve the situation, but in reality are incredibly expensive for the value they produce (or the risks they reduce). It's too easy to say, we'll totally redesign the system to avoid said problem. And what worries me, is often those very expansive actions, then cause you to overlook realistic but small investments that move the needle more than you would think.

And as a hot topic I also think the costs are an input into taking on tech debt. I know we all hate tech debt with a passion, but honestly, I think of it as a tool that can be wielded responsibly or irresponsibly. But if we don't know what our attention costs, we're going to have difficulty making the responsible choices about when and where to take on this debt. And then if we're not conscious about the debt, when it comes do it stings so much harder to pay down.

I think the most fun I had with the page cache was when one of the vendors "fixed" a bug where the memory calculation has previously excluded the page cache. These boxes were all network services, they didn't rely on the disk for anything more than holding the binaries, configuration, and logs. Where the fun comes in is the first time you grep through the logs, which fills the page cache, and sets off the alarms that the cellular network is about to die. ;)

Anyways, important concept to know and understand when it comes to how software performs when interacting with a host.

This happens with managed services and I understand the frustration, but vendors are just as fallible as the rest of us and are going to have wonky behaviour and outages, regardless of the stability they advertise. This is always part of build vs buy, buy doesn't always guarentee a friction free result.

It happens with the big cloud providers as well, I've spent hours with AWS chasing why some VMs are missing routing table entries inside the VPC, or on GCP we had to just ban a class of VMs because the packet processing was so bad we couldn't even get a file copy to complete between VMs.

I think this is the issue, is these datasets are out there and at least big tech companies have them since they're used to assist with GPS. I was about to post the same thing as above but saw vessenes beat me to it.

Without thinking about it too hard, the two directions I see are either making observations of the environment in real-time that is only relevant at that time (IE sniffing actual wireless frames, even if they're encrypted and making observations on them, however, most devices won't let you go into promiscuous mode and do this) or encrypting the messages in flight so only participants can decrypt them (IE a model like the signal protocol with E2E message encryption).

Anyways, this is a cool approach, but that risk occurred to me as well about the ability to just brute force the entire dataset to decode every location.

I ponder how effective this would be against an adversary sufficiently motivated to look like they're not using a VPN. And then does it result in a false sense of trust, since a user thinks the system more reliably detects a VPN then it does. Or an adversary who has bypassed the system to then point to it to build additional trust.

But from the article, turning off fsync and expecting to only lose a few ms of updates. I've tried to recover etcd on volumes that lied about fsync and experienced a power outage, and I don't think we managed to recover it. There might be more options now to recover and ignore corrupted WAL entries, but at that time it was very difficult and I think we ended up just reinstalling from scratch. For clusters where this doesn't matter or the SLOs for recovery account for this, I'm totally onboard, but only if you know what you're doing.

And similar the point from the article that "full control plane data loss isn’t catastrophic in some environments" is correct, in the sense of what the author means by some environments. Because I don't think it's limited to those that are management by gitops as suggested, but where there is enough resiliency and time to redeploy and do all the cleanup.

Anyways, like much advice on the internet, it's not good or bad, just highly situational, and some of the suggestions should only be applied if the implications are fully understood.

So I get a contract and am told it's been vetted and I should sign it. What I found was outrageous.

- If we cancelled for any reason, including if they just didn't do any of there terms in the contract, we owed the full price of the remaining contract immediately.

- The way they structured it was also as a rental, so we were paying full price for purchase of the equipment embedded into the term of the contract, but it was the vendors equipment, so if we cancelled we still paid them full price for the equipment, and they got to keep it.

- If there were any legal disputes, no matter which party was at fault, my side would pay for all the lawyers.

I said nope, can't do it. And my staff were pissed at me for like a year because everyone just signs those things.

Vanguard asset allocation ETFs are at like $1.3T [2]. 4 Of Canada's Big banks appear to add up to just over 2T Assets under management based on what Google just gave me as summary. So while I think this is a great outcome for a startup (even with Power backing them), to me it seems in a similar space as the above article that we're still talking a relatively small market share, and likely still closer to early adopter status.

[1] - https://en.wikipedia.org/wiki/Wealthsimple#:~:text=As%20of%2... [2] - https://www.vanguard.ca/en/product/investment-capabilities/a...

I'd say in addition to entrepreneurs, it's an important book for product teams / product engineers to understand what the Mom Test teaches, and tune the filter on asking the right questions to get the highest signal, and ensure the solution closely matches the value prop for the customer. Then sales and marketing get a whole lot easier when you've asked the right questions and solved the right problems.

If you are specifically getting targeted, there might be a slight delay by having the adversary try and exploit the honeypot ports, but if you're running a vulnerable service you still get exploited.

Also if you're a vendor, when prospective customers security teams scan you, you'll have some very annoying security questionnaires to answer.

To just expand a bit, I believe some of the confusion around printing of money comes from the way some economics reports are built. As a micro example, Assume a 10% required reserve, If Alice deposits $100 and the bank lends $90 to Bob. Alice ($100 deposits) + Bob ($90 cash) think they have $190 in total.

This is mainly useful for economists to understand, study, and report on. However, when the reports get distributed to the public, it looks like the banks printed their own money, as we now see $190 on the report when there is only $100 of cash in our example system.

Whether the system should work on a fractional reserve is it's own debate, but we need to know what it is to debate the merits and risks of the system.

In another view, this might just be a fancy way of doing snapshot testing, use AI to generate all the inputs to produce a robust snapshot, but realize the output isn't unit tests, it's snapshots that report changes in outputs that devs will just rubber stamp.

Each running process had a backup on another blade in the chassis. All internal state was replicated. And the process was written in a crash only fashion, anything unexpected happened and the process would just minicore and exit.

One day I think I noticed that we had over a hundred thousand crashes in the previous 24 hours, but no one complained and we just sent over the minicores to the devs and got them fixed. In theory some users would be impacted that were triggering the crashes, their devices might have a glitch and need to re-associate with the network, but the crashes caused no widespread impacts in that case.

To this day I'm a fan of crash only software as a philosophy, even though I haven't had the opportunity to implement it in the software I work on.

The second order problem I've found is when you dig in there are plenty of people who ask for certs but when push comes to shove really want functionality where when user access is cancelled all active sessions get torn down immediatly as well.