As I understand it, the section on "what not to do" features many things that Meshtastic does, though it does not say that explicitly. Perhaps the linked post wasn't clear to non hams (it is a newsletter targeted at hams), but the biggest issue is not flood routing, but using the same channel for networking and user access. It, by definition, cannot scale meaningfully. Many commercial networks solve this with either FDMA or TDMA.
Elsewhere in the newsletter, the author advocates for a form of FDMA, where users operate on different, dynamically allocated frequencies and all of them are received at once. P25 trunked radios used by almost all law enforcement in the US operate on a system like this.
I think the vitriol from those who are in the space either professionally or as an amateur comes from the fact Meshtastic is repeating mistakes we knew about in the 80s at the latest, for which reams if literature freely exists.
That's a reasonable take to an extent, but underlying all of that is the assumption that Meshtastic should be trying to scale up to support hundreds or thousands of active nodes on a single mesh. Since that's clearly almost impossible to achieve with an ad-hoc network of low-power LoRa radios, it's not entirely fair to criticize Meshtastic for not inventing a revolutionary solution to a very hard problem.
It would be more fair to criticize Meshtastic for not being clear enough about the tradeoffs and limitations inherent in a low-speed ad-hoc mesh network, and for not actively encouraging people to seek other hardware and software if their use cases are not well-matched to what Meshtastic hardware is capable of. A one size fits all solution simply isn't possible, and Meshtastic can't be the right answer for everyone.
This is also a fair response, however I'd argue that the current architecture, far from supporting hundreds or thousands, won't even support dozens in a small area with meaningful traffic being exchanged (e.g., not just heartbeats and routing data). The solutions exist and no revolutionary approach is needed. That's the crux of the complaints.
Now, for the hobbyist these solutions are harder to implement and that's not nothing, but I don't even see a movement to switch over to something more robust.
> Now, for the hobbyist these solutions are harder to implement and that's not nothing,
I'd argue it's everything. A network architecture that requires serious fixed infrastructure should probably be an entirely separate project from the ad-hoc mesh formed solely by cheap battery-powered portable/handheld gadgets. And everyone should be realistic about what "meaningful traffic" is for a network with a default data rate of ~1kbps; it's not reasonable to expect that to support the kind of chatter a busy IRC server would see.
It's the EU way. The only area where they produce world-leading innovation is regulatory regimes, so gotta use it to hit up American tech companies like an ATM.
Oh please. "The law" is a Kafkaesque patchwork that delegates authority to local officials and has enough complexity and wiggle room to make anything possible. We're not talking about a speed limit sign here. Show me the [company], I'll show you the crime.
I've been assured by people in this thread and others that, for example, if you "don't spy on users", you don't need cookie banners, and yet official EU sites have them.
Yeah, maybe that floats the people's boat wherever you live, but in other countries where people's health and well-being go above corporate interests, it is not common for companies to break the law.
> for example, if you "don't spy on users", you don't need cookie banners, and yet official EU sites have them.
Which is true, and you can understand that yourself by not relying on others, but reading the regulation yourself. It's actually pretty simple, and I think even someone who don't like regulations would be able to get through it if you apply yourself.
And yeah, even official EU sites could avoid it if they'd chose to not use tracking cookies. Not sure what the gotcha is supposed to be here? There is no inconsistency here.
"Area for future improvement: developers continue to improve the ensemble’s ability to create a range of forecast outcomes."
Someone else noted the models are fairly simple.
My question is "what happens if you scale up to attain the same levels of accuracy throughout? Will it still be as efficient?"
My reading is that these models work well in other regions but I reserve a certain skepticism because I think it's healthy in science, and also because I think those ultimately in charge have yet to prove reliable judges of anything scientific.
> My question is "what happens if you scale up to attain the same levels of accuracy throughout? Will it still be as efficient?"
I've done some work in this area, and the answer is probably 'more efficient, but not quite as spectacularly efficient.'
In a crude, back-of-the-envelope sense, AI-NWP models run about three orders of magnitude faster than notionally equivalent physics based NWP models. Those three orders of magnitude divide approximately evenly between three factors:
1. AI-NWP models produce much sparser outputs compared to physics-based models. That means fewer variables and levels, but also coarser timesteps. If a model needs to run 10x as often to produce an output every 30m rather than every 6h, that's an order of magnitude right there.
2. AI-NWP models are "GPU native," while physics-based models emphatically aren't. Hypothetically running physics-based models on GPUs would gain most of an order of magnitude back.
3. AI-NWP models have fantastic levels of numerical intensity compared to physics-based NWP models since the former are "matrix-matrix multiplications all the way down." Traditional NWP models perform relatively little work per grid point in comparison, which puts them on the wrong (badly memory-bandwidth limited) side of the roofline plots.
I'd expect a full-throated AI-NWP model to give up most of the gains from #1 (to have dense outputs), and dedicated work on physics-based NWP might close the gap on #2. However, that last point seems much more durable to me.
There's state-level law saying it's illegal to own or read some books on this list? Or just that it's illegal for school libraries to stock it and/or include it in curricula?
>There's state-level law saying it's illegal to own or read some books on this list?
Sorry, I'll edit my comment to be more clear. It is illegal for school libraries to stock it, even if they (teachers, the district, the parents, etc.) want it to be carried.
As a reminder for readers, the title of the article contains "in U.S. schools". It is probably a safe assumption to use that context for the comments in this thread.
Many of the ills currently befalling the US can be traced to the New Deal era. Including, of course, an HN favorite: our system of employer-sponsored health insurance.
I use Go every day at work and it's still the first thing I reach for when completing personal projects. It gets better every year. Keep up the good work Go team!
In the US, some have failed, some have worked. In my home state of Maryland, the PPP (P3) for redeveloping the Travel Plazas along I-95 is often cited as a success story and they are indeed widely considered top notch rest stops. It's a small-ish thing, but it did work.
Hi there - love Dillo. I use it on NetBSD and it works great. Once you're off GitHub will there be a way to get notified of releases? I use GitHub's RSS feeds for that now.
Elsewhere in the newsletter, the author advocates for a form of FDMA, where users operate on different, dynamically allocated frequencies and all of them are received at once. P25 trunked radios used by almost all law enforcement in the US operate on a system like this.
I think the vitriol from those who are in the space either professionally or as an amateur comes from the fact Meshtastic is repeating mistakes we knew about in the 80s at the latest, for which reams if literature freely exists.
reply