rcoder

I think the core problem isn't that the Noise "API" is confusing, it's that Noise is a framework for building reasonably-secure protocols. If you don't know how to build or evaluate cryptosystems, you shouldn't assume that just dropping in a library will somehow make your novel network protocol secure.

"Don't roll your own crypto" gets a lot of lip service (and a fair number of eye rolls) but it's really, truly something worth considering because it isn't just the algorithms or libraries you choose: it's about the whole package, including things like wire serialization, internal handshakes/security, etc. Just grabbing a Noise tutorial and building your own implementation is a Bad. Idea.

And this is only getting worse now that people can prompt their way through building a "secure" system only to realize they really didn't understand what that means. No amount of Markdown saying, "don't introduce a cryptographic vulnerability in this code" is going to save you if you don't know what to do in the first place.

But also: the vulnerability was literally visible using basic Wireshark/pcap traffic sniffing. I'm sorry, but if you don't even bother (or know how) to do that kind of basic security analysis you should stop and look for someone who does to check your system in the real world before you tell people to depend on it for serious work.

(That being said, if someone had just typed 'find me a vulnerability in this protocol' in a code agent backed by Fable or Astra with any kind of access to network traffic dumps it probably would have taken about 15 minutes to discover this issue. Might even be significant part of how the above author found it, given the other LLM-ish fingerprints in the writeup.)

Also: if you need a streaming box to see your AirPlay or UPnP devices for “casting” it necessarily has to be on the same VLAN as the devices it’s connecting to. Sonos speakers have this problem when subject to client isolation setups based on VLANs or switch-level packet filters.

And any kind of multicast (used for local service discovery and media streaming) has the same limitations.

Depends on your networking setup. A good switch will simply refuse to route packets between clients on different VLANs, and hide the existence of the tags that determine which VLAN a host is on.

A bad switch or router (which almost certainly includes a ton of crappy home APs and routers, compromised by the same actors who ship these devices) could let clients see VLAN tags and ignore them.

And an Ethernet “hub” does no filtering at all.

I wouldn't minimize the potential contribution of the teams building + evaluating the models, either.

If you have an entire office full of "lib-left" hackers, executives, et. al., their biases are going to have an effect on the models they build, irrespective of source material.

As an example: there's a lot of well-established science in support of anthropocentric climate change. And yet, interpretations (or even acceptance) of that science have become political dogma.

I think it's probably safe to say that engineers broadly trust science, whatever their personal views on social or economic policy. So models that are trained and evaluated on following scientific consensus will easily be tagged as "left-leaning."

The "dock" comment made sense to me because I don't think that true "road warrior" laptop use and 10G Ethernet deployments would coincide all that often.

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.

In California, yes; median income is around $100k. And of course, if you have kids, a mortgage, etc., you can qualify for plenty of tax incentives. OTOH, if you have kids your food, clothing, and transportation budget are almost certainly higher, and your ability to (say) relocate to find better wages are even more limited.

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.

The perspective from over here in HN land is very skewed.

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

That's a DoS attack, not "jamming". RF jamming usually relies on flooding frequencies with garbage which doesn't get interpreted as valid protocol traffic but does "crowd out" legitimate use.

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 <neighborhood>", etc.

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

How remote is "remote"?

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).

In many cases the people deploying these cameras have no idea the feeds are being resold to Flock. It’s not like they have a consumer brand and people are saying, “oh yeah, Flock, they’re the license plate camera folks…I definitely want one of those in my locker room.”

For some people, an Anthropic outage brings work to a halt.

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.

Fingerprinting devices once you’re installed on them isn’t much harder than doing so in a web browser.

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.

But we’re not taking about a 80-year gap here (“blaming modern Germans”); we’re talking about people who are in the global top 5% of income and prestige choosing _today_ to contribute to these organizations.

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.

"Justifying lower insurance rates" is just algorithmic bias described from the perspective of someone it doesn't (currently) harm. See also: credit scoring, insurance claim acceptance, job applications, etc., etc.

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.

Likewise interested in the authoritative answer, but: if I needed to write a decent chunk of code that had to run as close to wire/CPU limits as possible and run across popular mobile and desktop platforms I would 100% reach for Rust.

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

This sounds like an excellent distillation of the will to procreate and persist, but I'm not sure it rises to the level of "morals."

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.

I think that any kind of “modern ops” necessarily includes coding, even if there isn’t a ton of Python or Rust being generated as part of the workflow.

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.

AdaFruit and SparkFun both provide MCUs, sensors, and other peripherals that integrate well. Couple that with copious libraries and example projects and you may be up and running without having to stare at data sheets and wiring diagrams and JTAG output just to (say) get a temperature reading and display it on a tiny OLED screen.

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.

In ~25 years or so of dealing with large, existing codebases, I've seen time and time again that there's a ton of business value and domain knowledge locked up inside all of that "messy" code. Weird edge cases that weren't well covered in the design, defensive checks and data validations, bolted-on extensions and integrations, etc., etc.

"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.

You’re totally right; I got myself spun around thinking AES instead of of ChaCha because the product I work on (ZeroTier) started with the initially and moved to AES later. I honestly just plain forgot that WireGuard hadn’t followed the same path.

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

A Raspberry Pi 4 can manage something like 70Mbps of raw AES en/decryption flow: https://github.com/lelegard/aesbench/blob/main/RESULTS.txt

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.

I’m just gonna leave this here: https://docs.zerotier.com/protocol/#bridging

Disclosure: I work at ZeroTier :)

We host a fair bit of Terraform code in a repos on GitHub, including the project that bootstraps and manages our GH org’s config: permissions, repos, etc.

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.)

I’m a huge Framework fan: preordered the 13 and Desktop, have done mainboard + LCD upgrades on personal and work machines, etc. Likewise, I’ve used ARM machines as general-purpose Linux workstations, starting with the PineBook Pro up to my current Radxa Orion. It seems like a great combo!

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.

I bought the InkPalm a while back, and the Palma recently. (Note: I have a "thing" when it comes to e-Ink devices and so tend to just pull the trigger on new interesting ones when they come out.)

They're superficially similar, but the InkPalm feels like a very limited device by comparison. No Play Store, slower refresh, much older Android build, and a mostly-Chinese localized UI with partial English translation.

If you really just need a basic e-reader that can handle MOBI and ePub files and are willing to put up with a somewhat frustrating experience, the InkPalm is fine. OTOH, if you spend a lot of time reading long-form text but also want to occasionally run other apps -- Termux in particular is a pretty great tool to have on a small e-Ink device when paired with a small BT keyboard -- the Palma is meaningfully better.

The official unemployment rate is calculated by the Bureau of Labor Statistics by surveying a representative sample of US households, not a literal count of people "on the job hunt": https://www.bls.gov/cps/cps_htgm.htm

So while you should expect the numbers to broadly track together, there can and will be some variance month-over-month in the impact and durability of new jobs' contribution to the overall level of employment.

Choose one:

1. Full-on libre: speech, financial flows, technical architecture, etc. (i.e., basically the entire raison d'être for Nostr)

-or-

2. Live and work inside the walled garden of Apple + Google's app stores

You really can't have it both ways.

Since it sounds like very few folks in this thread have actually fired up Spin and built a thing, I thought I might offer a few observations based on my experience working on a little app over the last 2-3 weeks.

First, the good stuff:

- As a Rust developer, the SDK tooling is really good. I went from running the installer to generating a templated app to dropping in my own app logic in about 15 minutes.

- Local development iteration is also very fast and low-friction. Building everything as small WASM components means you effectively get hot module reloading for free, without needing to shim in a bunch of extra dev-mode-only code loading logic (with all the inherent incompatibilities and heisenbugs)

- The component reuse model feels a lot easier for me to reason than interminable chains of Express middleware (YMMV, of course)

- You get actual static (WASM) binaries, which can be as small as your compiler makes them. I'm normally pretty thrilled to get a production app container down to <100MB, and the app I've been working on, even without really paying any attention to my dependency graph, is around 2MB. Storage may be cheap, but pulling ~GBs of new container layers for a given release or deployment isn't free or instantaneous.

There are some less-great things:

- The "outbound" DB adapters are _very_ bare-bones. You only have access to a small list of datatypes, and you can't really layer higher-level libraries on top b/c the APIs aren't compatible with standard backend drivers. (Furthermore, if you want to use e.g. MongoDB, Clickhouse, Dynamo, etc., etc.: sorry, I hope you have some sort of HTTP adapter lying around ready to use.)

- WIT (WebAssembly Interface Types) is a cool _emerging_ standard, but like a lot of WAS* community stuff it's still in a fractured "draft" state, and many of the actual interfaces exposed in Spin are unique to their runtime. (This also means that _extending_ something like the PG bindings requires a ton of indirection code spelunking; I gave up trying to add a few new native types after realizing I would also have to support them for MySQL and every other backend DB.)

- The development environment, while relatively complete and usable on its own, doesn't really play nice with Nix or other high-level dev environment tooling. (There are literally invocations of `rustup` inside the top-level `build.rs` for the project, so good luck providing your own paths for e.g. `rustc`.)

On balance, I'm enjoying the experience thus far and starting to think about more thing-ish was to apply the tools. I'm also looking forward to trying out more of the self-hosted infrastructure stack. I'm not opposed to paying for managed hosting, but I do occasionally build things that need to run in "offline" or air-gapped environments, so being able to bring up a full hosting environment is pretty clutch.

If you have Node apps running in Lambda and are happy with the architecture, cost, and operating model: great! You've done good work and/or are very lucky and there's no need for you to rip everything out and start over.

Heck, even if you're curious about WASM and want to try some experiments with (say) fast Rust crypto libraries or embedded database engines w/o the risk of flaky native code crashing your V8 runtime: again, you can just run WASM from a Node worker thread and keep cruisin'.

For those of us who _don't_ have a huge investment in Node, have hard requirements around e.g. memory usage, cold start times, or even just plain old _cost_ (which can become a major factor when you consider the AWS lock-in) that Lambda doesn't meet really benefit from another option.

Your good fortune in finding a stack that works well doesn't mean that folks who have different needs or constraints are dumb, ignorant, or lazy.

As an aside, I think you also might be underestimating the depth of experience and knowledge of the Fermyon crew when it comes to containers, cloud runtimes, and serverless development. This is substantially the same team that built Helm, and a lot of other Kubernetes and cloud-native ecosystem projects along the way.

Neon at least has open-sourced their core offering, which provides a migration path for folks who make bigger bets on their platform. So yeah, there's every possibility they'll go away at some point, but unlike a lot of SaaS offerings, it's all Postgres over the wire and under the hood, so you have plenty of migration options (OSS, another managed Postgres vendor, Aurora, Cloud SQL, etc.)