I've been working on the MinPin platform (https://minpin.me) with Claude Code, trying to get my self-hosted server rack to at least partially pay for itself. Right now I've got a reusable framework I can use to sell various services:

* IPFS pinning

* Photo storage and backup with Immich

* Monitoring and Alerting with a status page

* Personalized browser history search with Hister

All the apps SSO against my identity provider so switching between them is pretty seamless, and billing is unified: instead of a bunch of independent Stripe charges, one subscription can grant access to multiple applications. One app is $5/month and four or more are $8/month, billed as a single charge, so Stripe's fixed 30¢ fee is paid once rather than four times.

I'm going through the "one (to|two|too) many" problem right now: picking the next app and working out how to present a growing list of products without the site turning into a junk drawer. Curious how others have handled that.

I was hoping there would be more discussion about the overlap of these two events.

The overlap between those two events is that digital security sucks ass and that attacks are much easier to mount in an era of agents.

I can see advantages to collating data for both organizations, but to it just raises the question, once again, of why simple appliances are connected to the Internet.

1. There's nothing simple about a commercial HVAC install, especially across a national chain.

2. Because they think (rightly or wrongly) that the benefits of monitoring and ease of maintenance and their contractor having direct access to the data outweigh the risks.

3. They think it outweighs the risk because IOT has been socially normalized, creating the wide perception that no, it's not that bad.

They almost certainly have insurance for this kind of event, and their insurer will almost certainly think real hard about the pros/cons of this, and will adjust rates accordingly. The grocer is free to take those rates into account when deciding on whether their next store will have an IOT HVAC.

That, and why there's not a company VPN in between.

These industrial networks are often not internal to a single company, sometimes by necessity. They also are often installed in places with inherent connectivity difficulties, so sometimes you are bridging weird networks that limit what is possible just to get the signal out.

These aren't consumer fridges with wifi. The situation on the ground is significantly more complex. There are a lot of embedded sensors and control systems in supply chains in order to minimize waste.

Because a main user of this is the third-party HVAC contractor, and there's a operational cost to getting him set up on the grocer's VPN. (He has thousands of clients, that's in aggregate a lot of customers that would need to give him VPN access. He will do whatever the client asks of him, but he will bill accordingly.)

One person's (not my) take on why to skip this: https://the.unknown-universe.co.uk/privacy-security/little-s...

TL;DR it's closed source and there's open source alternatives.

It's like the Swiss Cheese model where every system has "holes" or vulnerabilities, several layers, and a major incident only occurs when a hole aligns through all the layers.

https://en.wikipedia.org/wiki/Swiss_cheese_model

I use this model all the time. It's very helpful for explaining the multifactorial genesis of catastrophes to ordinary people.

Also perhaps worth a read:

https://devblogs.microsoft.com/oldnewthing/20080416-00/?p=22...

"You’ve all experienced the Fundamental Failure-Mode Theorem: You’re investigating a problem and along the way you find some function that never worked. A cache has a bug that results in cache misses when there should be hits. A request for an object that should be there somehow always fails. And yet the system still worked in spite of these errors. Eventually you trace the problem to a recent change that exposed all of the other bugs. Those bugs were always there, but the system kept on working because there was enough redundancy that one component was able to compensate for the failure of another component. Sometimes this chain of errors and compensation continues for several cycles, until finally the last protective layer fails and the underlying errors are exposed."

I've had that multiple times. As well as the closely related 'that can't possibly have ever worked' and sure enough it never did. Forensics in old codebases with modern tools is always fun.

> As well as the closely related 'that can't possibly have ever worked' and sure enough it never did.

I had one of those, customer is adamant latest version broke some function, I check related code and it hasn't been touched for 7 years, and as written couldn't possibly work. I try and indeed, doesn't work. Yet customer persisted.

Long story short, an unrelated bug in a different module caused the old, non-functioning code to do something entirely different if you had that other module open as well, and the user had disciverdd this and started relying on this emergent functionality.

I had made a change to that other module in the new release and in the process returned the first module to its non-functioning state.

The reason they interacted was of course some global variables. Good times...

By the way, a corollary I encountered, I think with one of the recent AWS meltdowns, is that a paradoxical consequence of designing for "reliability" is that it guarantees that when something does happen, it's going to be bad, because the reliability engineering has done a good job of masking all the smaller faults.

Which means 1. anything that gets through, almost by definition, is going to be bad enough to escape the safeguards, and 2. when things do get bad enough to escape the safeguards, it will likely expose the avalanche of things that were already in a failure state but were being mitigated

The takeaway, which I'm not really sure how to practically make use of, was that if a system isn't observably failing occasionally in small ways, one day it's going to instead fail in a big way

I don't think that's necessarily something rigorously proven but I do think of it sometimes in the face of some mess

That's a fairly common pattern. As frequency of incidents goes down the severity of the average incident goes up. There has to be some underlying mechanism for this (maybe the one you describe but I'm not so sure that's the whole story).

Global variables... the original sin if you ask me. Forget that apple.

I certainly don't get that cert. I'm seeing a LetsEncrypt cert for idtech.space with various SANs.

  # host code.idtech.space
  code.idtech.space is an alias for idtech.space.
  idtech.space has address 192.99.32.215
  idtech.space has IPv6 address 2607:5300:60:47d7::

Dvorak support/autodetection would be nice.

Love this, absolutely looking forward to some results.

https://leehite.org/Chimes.htm is the best source of information I've found on chime design and length. They go into great length about the lower octaves and how you can hear them (or not).

The linked site acknowledges Lee Hite actually. I suspect it's not a crowded field :)

The suspension point calc is particularly neat, I suppose putting it at a null node in the tube vibration so it doesn't damp it.

Thank you for providing this. In my firefox this article rendered as only the first paragraph then went straight to the comment section and I was very confused about why this was worthy of HN unless to talk about such a short content section!