I've put a disproportionate number of hours and $$$ into my homelab over the years, and I still only have 2.5G Ethernet switches deployed. Most offices' (much less home/coworking space/etc.) network traffic is passing through single-gigabit switches.

I stand by the core point: the median household income leaves very little room for major spikes in essential costs like fuel, housing, and health care. Any single cost jumping from $5k -> $10k is potentially ruinous.

According to the US Census, median household income in 2024 was $80,000. Add federal and state income tax* of 30%, and you're left with $56,000. Rent in lower-cost areas is around $12,000 ($1k/mo.) and health insurance (assuming ACA, not fancy private plans) is another $7000. Utility prices vary wildly but average something like $450-500 (so $6000 per year). if you don't live in a particularly high-cost area and skip luxuries like home Internet service or media subscriptions.

That's just over $30,000 left over per year for all household expenses, including "luxuries" like food, clothes, and car and home maintenance. Heaven forbid you have loans (car, student, etc.) or any revolving credit debt.

The difference between $5k and $10k in fuel costs is therefore easily 15% vs. 35% of total "inessential" spending. With food and other goods consistently been driven up by inflation and tariffs, there's just no margin for an "average" family.

(Sources vary for the above; US Census comes data from its own website, rent from TIME, health costs from Forbes, and utilities from move.org. Feel free to find better reference numbers if you doubt the above.)

*- yes, not all states charge income tax; most of the ones that don't have other taxes (sales, gas, property) to make up the gap

The protocol-aware class of attack you describe does require some knowledge of the radio parameters being used, since LoRa runs on very narrow bands and uses both time and frequency-hopping to avoid congestion on any one virtual channel. They even apply (very basic) encryption to messages to prevent unknown senders from flooding the channel.

Unfortunately, both systems come preconfigured out of the box to use a default configuration which most users never override. So like cheap FRS/GMRS walkie talkies, all it takes is a few jerks who don't care about common use to overwhelm everyone with bogus messages. If you fire up a new device running the default Meshtastic firmware in any kind of dense urban environment, odds are it will more or less immediately get inundated with spam: "ping", "test", "hello from ", etc.

And since MT + MC both flood the shared channels to push messages across intermediary nodes, they pretty much self-DDoS by doing...nothing.

If you're talking about a few miles/KMs between nodes, plain old LoRaWAN might be more than sufficient, esp. for the sensor use case. The nice thing about using LoRaWAN is that's it's literally providing an IPv6 overlay so you can run e.g. MQTT or a text-based messaging protocol designed for regular TCP/IP use. UDP is preferable to avoid frequent session resets and keepalive traffic chewing up your available bandwidth.

Meshtastic and MeshCore can theoretically provide "infinite" range so long as there are peers between the nodes you want to connect. Theoretically, mobile peers can also serve as store-and-forward nodes so that reachability doesn't need to be constant, just frequent enough to handle the messaging you want to do.

I would absolutely not rely on either for a safety-critical application, though. If you want emergency comms in case something happens while you're out on the mountain, use a satellite communicator. There are a ton of these marketed for outdoor/portable use, and they have much more robust "SOS" capabilities (up to and including direct dispatch of search-and-rescue).

For me (and I suspect for many others here) not being able to log in to their 1P vault to create and update credentials is a bigger deal.

Have Instagram installed on your phone? Great, now every Meta-owned app _or advertiser running on their platform_ has a pretty good shot at identifying you based on IP, location, app usage, etc.

There is a ton of signal about identity available just by virtue of running alongside other apps. Screen size, OS version, and IP are pretty good proxies for unique identity, especially if all you care about is _probable_ matches.

If you believe that your labor is worth something — which I’m pretty sure this crowd does — by working for a given firm, you’re voting with the value of your time in support of what your employer does.

Which, to be clear, is 100% your choice! I’m not going to accuse anyone of being a “bad person” because they decide that stable, high-paying employment is more important than taking a particular ethical (or political) stand at work.

But it _is_ a choice that you make every day by showing up for work.

In my view this is even more relevant for tech workers who receive equity. If you’re a shareholder in addition to being an employee, you’re now voting _twice_ in favor of what management is doing, and benefitting directly from both pay and ownership.

You only get offered a discount if most other customers are being compelled to pay full (or even increased) prices for the same offering. Otherwise revenue goes down and company leadership finds itself finding other ways to cut costs and increase profits.

Go has a lot of strengths, but embedding performance-critical code as a shared library in a mobile app isn't among them.

Fungi adapt and expand to fit their universe. I don't believe that commonality places the same (low) burden on us to define and defend our morality.

Kubernetes deployment configurations and Ansible playbooks are code. PromQL is code. Dockerfiles and cloud-init scripts are code. Terraform HCL is code.

It’s all code I personally hate writing, but that doesn’t make it less valid “software development” than (say) writing React code.

All of that plus maintaining inventory nearer their customers, doing effective QC on units they ship, writing good docs, etc. means you’re getting something a lot more like a “big OEM” experience from the hardware vendor, even if you’re ordering a handful of parts.

The generic AliExpress vendors, in my experience, do not do most of those things. They all support Arduino and/or PlatformIO, and sometimes a “native” SDK like mbed, but you’re often on your own figuring out how to integrate that bare MCU with other devices you need for a complete solution. Docs are often incomplete or untranslated, and it can be hard to know exactly which chip (or associated components like onboard sensors and BME) is on there. It can change between board revisions, or even identically-named parts from different vendors.

There are other players like M5 and RAK who make nice modular platform as well, but their prices tend to be up there with AF and SF.

"Just rewrite it" is usually -- not always, but _usually_ -- a sure path to a long, painful migration that usually ends up not quite reproducing the old features/capabilities and adding new bugs and edge cases along the way.

An embarrassing slip, TBH. I’m gonna blame pre-holiday brain fog.

That CPU is pretty much a toy compared to (say) a brand-new M5 or EPYC chip, but it similarly eclipses almost any MCU you can buy.

Even with fast AES acceleration on the CPU/MCU — which I think some Cortex MCUs have — you’re really going to struggles to get much over 100Mbits of encrypted traffic handling, and that’s before the I/O handling interrupts take over the whole chip to shuttle packets on and off the wire.

Modern crypto is cheap for what you get, but it’s still a lot of extra math in the mix when you’re trying to pump bytes in and out of a constrained device.

Disclosure: I work at ZeroTier :)

Hilariously, the official Terraform provider for GitHub is full of N+1 API call patterns — aka exponential scaling hotspots — so even generating a plan requires making a separate (remote, rate-limited) API call to check things like the branch protection status of every “main” branch, every action and PR policy, etc. As of today it takes roughly 30 minutes to do a full plan, which has to run as part of CI to make sure the pushed TF code is valid.

With this change, we’ll be paying once to host our projects and again for the privilege of running our own code on our own machines when we push changes…and the bill will continue to grow exponentially b/c the speed of their API serves to set an artificial lower bound on the runtime of our basic tests.

(To be fair, “slow” and “Terraform” often show up and leave parties at suspiciously similar times, and GitHub is far from the only SaaS vendor whose revenue goes up when their systems get slower.)

Unfortunately, firmware and OS support are hard for any vendor, especially one as small (compared to, say, Lenovo or HP) and fast-moving as Framework. Spreading that to yet another ISA and driver ecosystem seems like it would drag down quality and pace of updates on every other system, which IMHO would be a bad trade.