1
point
compumike
Joined 4,323 karma
Co-founder of HeyOnCall: https://heyoncall.com/
Co-founder of CircuitLab (YC W13): https://www.circuitlab.com/
Formerly I ran Growth at Triplebyte (YC S15): https://triplebyte.com/
- Lots of people are speculating that the price spike is AI related. But it might be more mundane:
I'd bet that a good chunk of the apparently sudden demand spike could be last month's Microsoft Windows 10 end-of-support finally happening, pushing companies and individuals to replace many years worth of older laptops and desktops all at once.
- There's a tradeoff and the assumption here (which I think is solid) is that there's more benefit from avoiding a supply chain attack by blindly (by default) using a dependency cooldown vs. avoiding a zero-day by blindly (by default) staying on the bleeding edge of new releases.
It's comparing the likelihood of an update introducing a new vulnerability to the likelihood of it fixing a vulnerability.
While the article frames this problem in terms of deliberate, intentional supply chain attacks, I'm sure the majority of bugs and vulnerabilities were never supply chain attacks: they were just ordinary bugs introduced unintentionally in the normal course of software development.
On the unintentional bug/vulnerability side, I think there's a similar argument to be made. Maybe even SemVer can help as a heuristic: a patch version increment is likely safer (less likely to introduce new bugs/regressions/vulnerabilities) than a minor version increment, so a patch version increment could have a shorter cooldown.
If I'm currently running version 2.3.4, and there's a new release 2.4.0, then (unless there's a feature or bugfix I need ASAP), I'm probably better off waiting N days, or until 2.4.1 comes out and fixes the new bugs introduced by 2.4.0!
- I appreciate that, thank you! :)
- Could always just use a status page that updates itself. For my side project Total Real Returns [1], if you scroll down and look at the page footer, I have a live status/uptime widget [2] (just an <img> tag, no JS) which links to an externally-hosted status page [3]. Obviously not critical for a side project, but kind of neat, and was fun to build. :)
[1] https://totalrealreturns.com/
[2] https://status.heyoncall.com/svg/uptime/zCFGfCmjJN6XBX0pACYY...
- Not sure if it’s a fit for what you’re looking for, but maybe https://ultimateelectronicsbook.com/ (maybe more theoretical than practical).
I’ve heard good things about “Practical Electronics for Inventors” but haven’t gone through it myself.
- You can simulate a bunch of these (and edit too) in your browser in CircuitLab:
Diode half-wave rectifier https://www.circuitlab.com/editor/4da864/
Diode full-wave (bridge) rectifier https://www.circuitlab.com/editor/f6ex5x/
Diode turn-off time https://www.circuitlab.com/editor/fwr26m/
LED with resistor biasing https://www.circuitlab.com/editor/z79rqm/
Zener diode voltage reference https://www.circuitlab.com/editor/7f3ndq/
Charge Pump Voltage Doubler https://www.circuitlab.com/editor/24t6h3ypc4e5/
Diode Cascade Voltage Multiplier https://www.circuitlab.com/editor/mh9d8k/
(note: I wrote the simulation engine)
- 3 points
- For fun, playing with Meshtastic https://meshtastic.org/ and contributing to the open source firmware and apps. They have something cool but need lots of help. I've patched 3 memory leaks and had a few other PRs merged already.
For work, https://heyoncall.com/ as the best tool for on-call alerting, website monitoring, cron job monitoring, especially for small teams and solo founders.
I guess they both fall under the category of "how do you build reliable systems out of unreliable distributed components" :)
- Inflation adjusted chart for the GLD ETF:
https://totalrealreturns.com/s/GLD
(Not quite the same due to the compounding 0.40%/year expense ratio of the ETF, but probably close enough for this conversation.)
- Just thinking out loud here: an ACME DNS-01 challenge requires a specific DNS TXT record to be set on _acme-challenge.<YOUR_DOMAIN> as a way of verifying ownership. Currently this is a periodic check every 45 or 90 or 365 days or whatever, which is what everyone's talking about.
Why not encode that TXT record value into the CA-signed certificate metadata? And then at runtime, when a browser requests the page, the browser can verify the TXT record as well, and cache that result for an hour or whatever you like?
Or another set of TXT records for revocation, TXT _acme-challenge-revoked.<YOUR_DOMAIN> etc?
It's not perfect, DNS is not at all secure / relatively easy to spoof for a single client on your LAN, I know that. But realistically, if someone has control of your DNS, they can just issue themselves a legit certificate anyway.
- It's strange: SSL certificates (and maybe domain name registrations?) are one of the only "ticking time bomb" elements present in every modern web stack, whether a static site or not. By "ticking time bomb" I mean that there's a hard date N weeks/months from now where your site will definitely stop working, unless some external pile of dependencies work smoothly to extend that date.
Software didn't have that sort of "ticking time bomb" element before, I think?
I think I understand why it's necessary: we have a single, globally shared public namespace of domain names, which we accept will turn over their ownership over the long run, just like real estate changes hands. So we need expiration dates to invalidate "stale" records.
We've already switched over everything to Let's Encrypt. But I don't think anyone should be under the delusion that automation / ACME is failproof:
https://github.com/certbot/certbot/issues?q=is%3Aissue%20ren...
https://github.com/cert-manager/cert-manager/issues?q=is%3Ai...
https://github.com/caddyserver/caddy/issues?q=is%3Aissue%20A...
(These are generally not issues with the software per se, but misconfiguration, third-party DNS API weirdness, IPv6, rate limits, or other weird edge cases.)
Anyway, a gentle reminder that Let's Encrypt suggests monitoring your SSL certificates may be "helpful": https://letsencrypt.org/docs/monitoring-options/ (Full disclosure: I wrote the most recent addition to that list, with the "self-hosted scripts".)
- PostgreSQL defaults to: "fsync = ON" and "synchronous_commit = ON".
ClickHouse defaults to: "fsync_after_insert = false".
A more fair comparison might at least do "SET synchronous_commit TO OFF" on the PostgreSQL side. (But for this UPDATE benchmark, I think the results would still largely be the same.)
- 6 points
- 1 point
- Oof, you're right, that's rough that it's so soon after they discontinued their email service!
I wrote this blog post a few weeks ago: "Minimal, cron-ready scripts in Bash, Python, Ruby, Node.js (JavaScript), Go, and Powershell to check when your website's SSL certificate expires." https://heiioncall.com/blog/barebone-scripts-to-check-ssl-ce... which may be helpful if you want to roll your own.
(Disclosure: at Heii On-Call we also offer free SSL certificate expiration monitoring, among other things.)
- I appreciate the "How to monitor the monitor?" section. Always need a meta-monitor! :)
Hope you might give us a try at https://heiioncall.com/ and let me know if that fits. (Disclosure: our team is building and operating it as a simple monitoring, alerting, on-call rotations solution.) We have the cron job heartbeats, HTTP healthchecks, SSL certificate expiration, etc etc all in one simple package. With mobile app alerts (critical and non-critical), business hours rules, etc. And a free tier for homelabbers / solo projects / etc. :)
Edit: since you mentioned silencing things in your post, we also have very flexible "silence" buttons, which can set silence at various levels of the hierarchy, and can do so with a predefined timer. So if you know you want things to be silenced because you're fixing them, you can click one button and silence that trigger or group of triggers for 24 hours -- and it'll automatically unsilence at that time -- so you don't have to remember to manually manage silence/unsilence status!
- Blocks me too. (Infinite loop "Verifying...") Firefox on macOS. No VPN.
- Interesting! It could be a confounder as well. For example, maybe people who live in dense (loud) urban dwellings also tend to have more day-to-day life stress generally, leading to reduced sleep quality. (Of course, reduced sleep quality could also be a source of more life stress...)
Would your userbase be up for a little experiment: adding white/pink/rainfall/etc noise at various volumes? I bet you'd see an inverted U shaped curve, with sleep quality increasing at relatively low volume levels, and then hitting some maximum and decreasing when it gets too loud! (Agree with other comments about looking at intra-night variance in noise level.)
This is probably the same kind of "one new row per month" assumption that many data pipelines with any sort of primary date/time column make!