This is the compromise. In exchange for having the ability to easily establish an encrypted connection to pretty much any public web service, the tradeoff is that the entire public internet's encryption is only as good as the operations of the weakest of the big public certificate authorities.

The first time you connect to google.com in your browser and get the google.com certificate, your web browser has to decide whether or not to trust that cert. It would be very complicated if every website on the internet had to prove its identity via some sort of out of band process, so web browsers, operating systems, etc all ship with a collection of trusted, institutionally-important certificates which are allowed to vouch for other certificates that aren't yet known to the browser, OS, etc.

Your browser (or whatever HTTPS client) basically says "I've never seen this certificate before, but Lets Encrypt (or Digicert or whoever) says they trust it and we trust Lets Encrypt, so we can treat it as trusted". You as a user are trusting that whatever verification/validation process the CA does is at least good enough to ensure that the owner of the domain is the entity giving you a certificate for that domain.

This is obviously not a perfect system. These CAs can be compromised and break the trust, and they have various levels of validation of the people and companies who come to them and ask to be included in their vouching network, etc. But its a compromise to make sure that users can connect to a wide variety of internet sites, using encryption, without needing to somehow decide whether they themselves trust the certificate provided by the website.

The most important thing to remember is that in most cases the CA is not vouching for the quality or integrity of the website - they are just vouching for whether the person/group who controls the domain/server is also the person/group providing the certificate for encrypted communication with the website. Its a protection against MITM attacks and snooping, not a protection against phishing or anything else that might happen once the connection is established.

The whole catch is that they can often be regenerated. But LLMs (on their own, in their parametric memory - which is the result of training) don't have any conception of whether what they've generated is a real reproduction of some training material or whether they've invented something false that seemed probable based on their encoded stats. When the probability produces something contrary to what was in the training material, you get hallucinations.

They're very, very good predictive text models and can be very, very powerful when hooked up to other tools or outside databases. But its fundamentally lossy technology and all the books having been fed in doesn't guarantee all of the knowledge from those books can be spat back out.

I live in an NYC apartment with a similar Mitsubishi ducted split system - very short run ductwork just because the apartment itself is small, but takes up way less space than traditional American-style air handlers, even the apartment sized ones. The entire air handler is suspended above my bathroom ceiling, in between the drywall and the slab above.

My system was originally installed with the 2-wire serial wall thermostat but I converted it to one of Mitsubishi's Redlink wireless units because I needed to relocate the thermostat. But since Redlink isn't wifi, and the Mitsubishi networked thermostats and cloud platform get pretty poor reviews... this project is super interesting to me.

Software engineers (myself included, over the years) often argue their real value isn't just writing code, its figuring out the gaps in requirements and how to resolve them. Sometimes that engineering process gets turned back into a formal spec. But much more often, the implementation functionally becomes the spec and contains many details that were never present in the original statement of the requirements.

Formal verification techniques in general are a harder sell until we get the industry to a point where there's broader agreement that what we call "implementation" is often a blurry mix of spec development, prototyping, and actual implementation all happening at the same time.

A security-only audit for a small company with a narrow product focus can indeed be very inexpensive. A full SOC 2 examination for a large organization with a mix of legacy and modern systems by a name-recognizable public accounting firm can be many hundreds of thousands of dollars, or more if you need a Big 4 firm.

In my opinion, there's not much value to the "cheap" audits... If you're doing enterprise sales to a certain kind of client, your partners who demand an audit are going to want a reputable auditor or they're just going to put you through their own in-depth procurement due diligence regardless. The segment of the industry where a SOC 2 attestation is mandatory to participate but where any random auditor will do feels pretty narrow.

Good security architecture has circuit breakers, even for people who are generally high-trust.

Developers and developer-adjacent, technical people tend to think this way on their own... but every business has dark corners where repetitive, manual things still happen. We're leaning a lot on training and even org-wide LLM instructions to try and let the LLM (by its own assessment) be the vehicle use to codify a process and turn it into some good old-fashioned reviewable, deterministic automation.

Which is to say: no shame in just settling for that simple C backend!

I have a hard time seeing a future where retail doesn't bifurcate even further into ultra low margin, happy-path optimized megastores and concierge-style high touch boutiques. Places like Crutchfield that split the difference nicely seem to be a dying breed.

I'm a pretty staunch defender of remote work for most roles, but outside of the smallest companies where the entire organization is on a single conversational thread, you really do lose the organic peripheral vision that comes with an office environment and deliberate effort is required to try and recreate some of that in your fully-remote org if you want some of the same upside. Even with deliberate effort, I'm not convinced you can match it perfectly.

A corporate purchaser is buying hundreds to thousands of Claude seats and doesn't care very much about percieved fluctuations in the model performance from release to release, they're invested in ties into their SSO and SIEM and every other internal system and have trained their employees and there's substantial cost to switching even in a rapidly moving industry.

Consumer end-users are much less loyal, by comparison.

Much easier if you can sell wholesale (sometimes via distributors) to a retailer or network of retailers, and the retailer is responsible for owning the customer relationship, dealing with their part of import/export, local regulations, etc. Retailers are businesses who will buy hundreds of your product at a time, can accept it as palletized freight, and pay you via bank EFTs instead of credit cards.

There are notable exceptions to this model like Amazon's FBA system, but they're the outliers. I'm sure we can all point to inefficiencies in legacy product distribution networks but they solve some real problems.

Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.

I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.

Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).

As a result, the entire packaged food industry is pumping up protein numbers and marketing it as the primary attribute of the food (where they might have previously marketed low fat or low sugar or whatever else in the past).

So, saturated market... but certainly one people are investing in now.

In startups I've put more effort into squeezing blood from a stone for far less change; even if the change was proportionally more significant to the business. Sometimes it would be neat to say "something I did saved $X million dollars or saved Y kWh of energy" or whatever.

With a credit card, if the card is compromised, its not my money being stolen - its the card issuer's money from my line of credit, and they were planning on settling up with me when my monthly statement closes. I still have to launch a fraud case with the issuer, but critically, _all of my money is still in my bank account_ and I can continue to pay my other bills and obligations as normal.

I think its reasonable to consider giving up that buffer to be additional risk for the debit card approach, setting aside any other advantages or disadvantages between the two.

Right now, yes, its true that a lot of my day to day purpose is driven by participating in the economy and setting myself up for the life I'd like to have in my later years, and I get genuine validation from solving problems and collaborating with people in my day job.

But sometimes, my purpose is to go snowboarding and forget about work. Or to help a friend fix their bicycle. Or to get lost in conversation with a new person I'm dating. As far as any of us know, we only get one turn to be alive on this rock, so we might as well purposefully enjoy it as much as we try to purposefully be useful.

If you look at Ginny Oliver from the article, it might be fair to question whether she was as useful on a lobster boat at 105 as she might have been in her youth. But I doubt she was concerned with usefulness since she had such sense of purpose.