scottlamb

tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.

In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?

> Edit: I might also be misinterpreting what I am seeing and it's actually weak logic that created the keys, in the sense that one could guess the private key?

As I understand it, the private key is supposed to be a number in the range [0, 2^256), but they actually generated a number in [0, 256) for these 8 intermediate certificates. Once you know there are so few possibilities, you can try them all ~instantly, so effectively everyone has the private keys. (And when I say "you can", I actually mean you, not some hypothetical more skilled version of you: even if you don't know anything about public key infrastructure, if you have access to an LLM, it can do it for you with a single prompt.)

> But doesn't their value lie in getting you access to the core of the OS that you wouldn't be able to touch otherwise? What if your network stack was a library you could instrument just like you do with the rest of your app code?

Yes and no. The traditional separate kernel exposes one set of interfaces that these tools use. A library version might expose a different set of interfaces that accomplish the same thing. Your application could then use those to provide similar observability. But maybe not—that consideration was mostly absent from this article. And with new tools, you need to retrain your developers, SREs, LLM agents, etc. If your new tools are that much better, it might be worth it. But these articles have fallen far short of making that claim.

> Also, I don't need a tool to tell me I'm being punished by the IO or CPU scheduler if I am the only one using the CPU and IO :)

Disagree. Embedded programs still have IO and CPU scheduling problems, including priority inversions. You don't need different programs to have CPU scheduling problems, just different threads, or different tasks with an async scheduler. Any time you have concurrency you need to consider scheduler observability.

I'd love to read more about your debuggable/benchmarkable/observable unikernel architecture and interfaces. Much more interesting than these "unikernels are the future" articles which make little reassurance they've replaced what they've dropped.

This is the second unikernel article this week I think, and the second that really undersells the benefits of having a full OS. Let's just swap out a couple of words:

> With a unikernel, the [observability] surface is much smaller. If the functionality isn't in the application (the operating system), then the [SRE] is screwed. There's no next hop.

Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value. The article mentions some nice things for observability ("structured logging, OTel") but so much gets thrown away.

You're never going to get promoted with that attitude!

I'm joking...but not entirely. It sounds impressive on a promo packet when you say you've saved 100 TB of RAM / $$$ through whatever technique. But it sounds a lot less impressive when you say if this system grows to this size in x years, I will have saved 100 TB, especially when no one yet knows how large the system will really be in that time or what the cost of RAM will be. I dunno, maybe if you say that x years ago, I made a decision that now is saving us 100 TB, that's kinda impressive, but you're also getting credit for it x years after you did the work. It also doesn't have the implication that it must be inherently complex/hard because some other smart person chose the other way. And there is a bias to care more about recent accomplishments. So I don't really think it'd be valued the same at all.

Also, in general big tech (at least Google) prefers growing the userbase over improving efficiency. Periodically efficiency is rewarded, e.g. when RAM cost suddenly balloons or some big must-have feature has suddenly used up capacity planned for something else. You get rewarded for doing efficiency work on demand, not eagerly.

I once got a $100 peer bonus for finding 100,000 cores that were essentially stranded by an accounting error in another team's migration script.

> Now they're run based on the data, and the data says they have enough loyal-to-a-fault customers like the author that chronically understaffing is more profitable than providing a good experience.

If they are indeed saying understaffing doesn't matter because their current customers don't care, their loyalty numbers will only go up because of that sampling bias. Relatively upscale fast casual places (e.g. Chipotle) will replace McDonalds for the customers they lose. The circle of service industry life.

> They cherrypicked 15 countries.

The "world" chart shows an increase from 19% renewal to 34%. Did they cherry-pick that? (Also, "European Union" is more than one country.)

> I don't doubt that it's economical for individuals when the govt is subsidizing it.

Does that distinguish renewables from fossil fuels? Haven't governments been essentially subsidizing fossil fuels (not least by allowing environmental externalities to be ignored) for as long as they've been in use?

Some people actually care, but they can't always win the battle at their own companies when there are other priorities, much less go fix all the other websites, pour concrete at other businesses, etc. Is the solution for everyone to care? If, so how do you accomplish that? ("Americans with Disability Act" v2?)

The author is seeing that it's easier for one team to get backing (VC money, course credit, design awards, TED talk applause, etc.) for "solving" an accessibility problem than for us to enforce that entire industries follow good accessibility practices in new work and retrofit existing work. In theory industry-wide enforcement is the sort of thing legislation like the ADA solves, but obviously that hasn't been completely effective. Not sure how to fix it.

There was a subthread recently complaining about password managers and their UX problems. These aren't aimed specifically at "disabled" users, but I think it's a similar situation. We can't reliably enforce good standards for sign-in (whether that's just setting the autofill attribute correctly and choosing the correct event handlers for Javascript validators or something far more ambitious), so we expect a password manager to just deal with the web as it is. IMHO they work remarkably well given that constraint, but it's not optimal overall.

> I'm pretty sure doing janky things to the AC you don't own is a lease violation.

Why? Not all "janky" things are the same:

* Sloppy changes to the internal 240V wiring: yeah probably a violation of the lease, and legitimately likely to burn the place down, with associated liability.

* Temporarily mounting to the exterior this mechanism that turns the knob shaft, with no changes to the wiring, no holes, no nothing. I can't think what grounds they'd have for considering this a lease violation or a reason to keep any of the security deposit, as long as you pop the original knob back on when you move out. And as inigyou pointed out, how would they even know?