fleventynine

Have your panic handler call an extern "C" function that doesn't exist, and the linker will complain if there's any calls to that function that weren't optimized out. Alternately, you can look for the symbol in the output elf file and fail if it's there, which is a bit more graceful as panicking binaries can still be produced during development.

The way I see it, there are a limited number of ways that a bare-metal component with no heap can "catastrophically fail":

1. "Undefined behavior" due to typical memory bugs: code written in 100% safe Rust cannot trigger this behavior.

2. "Undefined behavior" due to a stack overflow: this can happen in safe Rust, but you can provably guard against it by banning recursion and dynamic dispatch, and doing static stack depth analysis on your program.

3. Panic/abort: naively written bare-metal Rust typically has many potential calls to panic!() due to bounds checks, integer overflows, .unwrap(), etc, and if these get called the system will typically fail catastrophically. I like to solve this by having CI fail if the optimized binary contains ANY call-sites to the panic handler. This forces the developer to handle these edge cases with idiomatic error handling before they can merge their code (but can cause some development pain/brittleness when the optimizer heuristics change).

4. Infinite loops: in most bare metal systems, if a section of code doesn't complete within some reasonable time, a watchdog will fire and the system will crash. Ideally there would be some static analysis that could tell me whether some particular code is capable of exceeding the allotted time bounds, but I'm not aware of such tooling, and need to resort to hacky solutions such as fuzzing and handling resets "gracefully" at runtime.

> Fortunately, whenever you create a superintelligence, you obviously have a choice as to whether you confine it to inside a computer or whether you immediately hook it up to mobile robots with arms and fine finger control. One of these is obviously the far wiser choice.

Today's computers, operating systems, networks, and human bureaucracies are so full of security holes that it is incredible hubris to assume we can effectively sandbox a "superintelligence" (assuming we are even capable of building such a thing).

And even air gaps aren't good enough. Imagine the system toggling GPIO pins in a pattern to construct a valid Bluetooth packet, and using that makeshift radio to exploit vulnerabilities in a nearby phone's Bluetooth stack, and eventually getting out to the wider Internet (or blackmailing humans to help it escape its sandbox).

> the rest of your program doesn't have to be an explicit state machine; it can use structured control flow with nested loops and conditionals and subroutines

This works well until the requirements change and you have to run two structured control flows simultaneously. If I find myself in such a situation and have no SRAM for a second thread, rust async may be the quickest way to accomplish the goal without a major rewrite into manual event driven code.

As I see it, if you need everything to run on a single cpu core, the alternatives are to either implement threads (wasting memory on redundant stacks) or to write the event-driven state machines manually. Whether the state machine is pumped by interrupts or not doesn't change anything IMHO.

Because of RAM constraints, all the bare-metal projects I've worked on have used manually-written state machines, and I'm comfortable enough with this approach. But sometimes these state machines can be hard to understand when the control flow is complicated, and I am seriously considering adding some compiler-generated state machines that will fit nicely into my existing model.

Can you go into more details? Most of the criticism I've read tends to be more abstract ("I don't like how ALL my blocking-style calls need to be async"), and doesn't propose an alternative mechanism to async that can provide a similar coding style in the same tight RAM footprint.

Everything had tradeoffs, but the composability of the state machines built by the compiler's async support allows you to easily build multi-tasking bare-metal systems with thousands of "tasks" and no RTOS (or SRAM-wasting threads). I highly recommend playing with Embassy for a week before discounting this approach for embedded software.

If you care about RAM consumption, you need to share the stack between tasks, forcing you to write event-driven code. Rust async makes this easy, and a bit of function coloring is no big deal compared to converting blocking code into event-driven code the traditional way...

The redundant GND pins are necessary for signal integrity and low EMI when running at higher speeds; the high speed signals need a return current path with as little loop area as possible, so you want those signal pins close to GND on the connector.

Yes, but it has far fewer pins for the same bandwidth, so it's feasible to make a "PCIe switch" that will fit in a typical IC package.

Sounds like a terrible local government. Have you considered moving away? Local governments compete with each other to attract taxpayers, and if enough people leave they'll be forced to change their political structure.

Private equity will only benefit if the supply of housing is artificially restricted or they are able to capture a substantial portion of the market. Both these problems can be solved by adjusting the local regulatory levers to make construction easy and collusion/anticompetitive behavior hard.

"Buying an entire development" is arguably anticompetitive behavior and can be prevented by the government.

> but these blood clot deaths with negative COVID tests were not unique to the AstraZeneca vaccine

I think Johnson and Johnson's covid vaccine (also an adenovirus vaccine) was also associated with blood clots, but do you have any evidence of clots with the mRNA vaccines? I recall reports of Myocarditis in younger men that got little value from the mRNA vaccines, but this is the first I've heard of blood clots.

> does the global medical establishment even have a chance at salvaging the reputation of mRNA?

AstraZeneca's Covishield is not an mRNA vaccine; it is a viral vector vaccine, using Adenovirus. The small possibility of blood clots was acknowledged by medical authorities after a few months of use, with some jurisdictions going so far as to suspend its use, citing the mRNA vaccines as a safer alternative.

https://en.wikipedia.org/wiki/Oxford%E2%80%93AstraZeneca_COV...

I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).

The current calling convention is terrible for small platforms, especially when using Result<> in return position. For large enums, the compiler should put the discriminant in a register and the large variants on the stack. As is, you pay a significant code size penalty for idiomatic rust error handling.

Yes, but they're in a better position than most of us, and they would be wise to reconsider their ongoing dependencies on networked infrastructure and modern supply chains for anything life-critical. It's ok to rely on an off grid solar system or an electric truck as long as you disconnect them from the Internet and maintain a cache of replacement parts.

The more I learn about how fragile our modern IT infrastructure and economy is, it seems the Amish are building a more robust society. Maybe they'll inherit the earth after our horrendously complex web of dependencies is destroyed by war or by accident.

I hope most Amish communities can avoid the following:

1. Off-grid solar systems that eventually shutdown if they lose network connectivity.

2. Tractors and other agricultural equipment connected to the internet, likely susceptible to remote security vulnerabilities that could threaten the harvest.

3. Complex supply chains that require cloud services and network connectivity to function.

I'd never terminated fiber before, so I just watched some youtube videos to teach myself. The main trick was making sure that the cleaver was cutting clean, and the fusion splicer would do most of the rest of the work. Every so often the splicer would detect a bad splice and I'd have to re-do. Since I did the work 5 years ago, none of the splices have had any issues, even the ones painfully terminated in a cheap splice tray behind the wall before I figured out the pre-termination trick.

The cable TV shield is grounded where it enters the house. The POTS lines aren't grounded (they're differential, like 1000base-T), but the telephone company installs some sort of protection device in the exterior box that allows sparks to jump across to the local ground if the voltage differential gets too high.

Voltage differentials in the earth that exceed 1500V will occur even without a lightning strike, and the greatest danger is when the ground is dry. Even something as simple as a strong wind blowing on a tree can charge things up significantly...

No, but they weren't spending $1000 on a gigabit switch in 2004 either.

If you're serious enough about home networking to run cables through your walls, $700 for a switch is nothing compared to the labor cost.

I was averaging around 15 minutes per splice. I think I spent more time pulling the cable through the walls and attic, and that would have been a huge pain with the pigtails still attached (not to mention the increased risk of damaging the fragile pigtails).

I consider these consumer-priced switches:

https://www.servethehome.com/mikrotik-crs504-4xq-in-a-4x-100...

https://mikrotik.com/product/crs510_8xs_2xq_in

I strongly recommend against this unless you have bonded earth connections between the buildings. During a storm the ground potential between the locations is likely to exceed the 1500V rating of the magnetics in your switches, and your equipment will be destroyed. Fiber is the only safe option at this distance.

Multi-mode standards change too frequently, and it's not really much cheaper. Prefer single-mode.

It's mostly about future-proofing. If I had renovated my house 20 years ago, the "best" copper cable I would have installed was cat5e, which will never get much beyond 2.5G. But if I had installed SMF instead (which was available at the time), it would be compatible with terabit networking hardware that is available today, and the petabit networking hardware that is likely to be available 20 years from now.

When the lifetime of cables in the walls is typically more than 40 years, it makes sense to avoid limited technologies like copper or multi-mode fiber.

I think I paid $800 for a brand new SignalFire AI-8, but that was 5 years ago. Compared to the $9,000 Fujikura units used by pros, it was inexpensive :)

During a renovation, I ran 6-strand single-mode fiber to various locations in my home. I found the termination process (using an inexpensive Chinese fusion splicer) to be somewhat of a pain, especially for connections behind wall jacks rather than in a proper splicing cabinet.

What I found worked best was to buy a bunch of 50 meter pre-terminated plenum-rated cables and cut them in half. I'd plug the pre-terminated ends into the wall-jack coupler, then weave the cut end through the walls back to the splicing cabinet, where I'd leave several turns of slack and fusion splice the pigtail which I plugged into the patch panel.

I use Kicad regularly, and I encourage others who also use it to donate an amount similar to an annual license for the proprietary competitors. The team has already proven that they can maintain such a useful tool with a tiny budget, imagine what they could do if they had the same annual budget as Altium...

I thought it was obvious, but in a world where most people have solar battery setups, peak demand occurs after 2-3 days of cloudy weather, and stays consistently high 24 hours a day until the sun comes out. The rest of the year the grid is pretty much idle.

I don't believe I'm moving any goalposts. From the first paragraph of my original comment:

> Imagine a world where everyone in the state has an overbuilt solar battery system installed, but still relies on the grid those few times a year with extended cloud cover.