If you leave out the JIT part, binary translation dates back to at least 1966 (Honeywell).

Still one of the GOATs, agree.

I did my master’s thesis on that device. I had a custom hypervisor running a guest kernel, virtualized networking, and a buildroot userspace. I could SSH into the host N810, then SSH into the guest. I even virtualized the framebuffer at some point and got the “dancing baby” animation playing from the guest. It only ran at a couple frames per second, but it was _amazing_.

I can't remember all the bugs, but I've definitely at least encountered all flavors of flickering bugs, stale updates, GPU crashes, failed copy and paste, failed screenshares, failed videoconferences...

From comments on this thread, it sounds like things have drastically improved and its probably time to take another look.

Does Wayland actually work now? I've tried it every few years for over a decade now and every time I ran into showstopper bugs (usually on nvidia cards).

Personally, I've found even the latest batch of agents fairly poor at embedded systems, and I shudder at the thought of giving them the keys to the kingdom to say... a radiation machine.

There are mitigation techniques like randomization of chirp frequencies, choosing different idle times between frames, and signal processing techniques to try to detect interference and filter it out. In the general case, FMCW techniques will always have interference problems.

This is one reason amongst many others that military radars do not use FMCW but instead coded pulse compression techniques.

Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorry state of affairs.

Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.

I don't even want to talk about the state of proprietary vendor tooling...

I work extensively in the embedded space and unfortunately C and C++ are still pretty much the only viable languages. I can not wait until the day rust or some other language finally supplants them.

It's time we moved on.

I looked through what I did and in the end, to bring in pw_result, I had to define a failure handler, pull in three separate cmake files for various definitions, define an ASSERT action (because a result type requires an ASSERT fail, apparently?), and set a backend and a handler for pw_assert. At some point I remember it complaining left and right about not having the right I/O methods for printing, etc. I just wanted to try the result type, and for some reason I needed to define I/O mechanisms for my platform.

Is this the correct procedure? I have no idea, because the cmake documentation had (has?) _zero_ examples. If they existed, I couldn't find them. I eventually got it to compile with the following snippet, but I can hardly believe that this is the "intended" way to do it.

  FetchContent_Populate(pigweed)

  include(${pigweed_SOURCE_DIR}/pw_build/pigweed.cmake)
  include(${pigweed_SOURCE_DIR}/pw_assert/backend.cmake)
  include(${pigweed_SOURCE_DIR}/pw_assert_basic/backend.cmake)

  add_compile_definitions(PW_ASSERT_BASIC_ACTION=PW_ASSERT_BASIC_ACTION_LOOP)
  pw_set_backend(pw_assert.check   pw_assert_basic.check_backend)
  pw_set_backend(pw_assert.assert  pw_assert_basic.basic_handler)

  add_subdirectory(${pigweed_SOURCE_DIR} ${pigweed_SOURCE_DIR})

I did end up getting it working, but it was clear that GN/Bazel is the blessed build system and CMake is just an afterthought.

In contrast, I pulled in expected-lite [1] with a single line of CMake's FetchContent, #include'd the header, and it just worked.

[1] https://github.com/martinmoene/expected-lite

- My real problem is disaster recovery. It would take me forever to replicate everything, if I could even remember it all. Router configurations, switch configurations, NAS, all the various docker containers scattered across different vlans, etc. I mapped out my network early on but failed to keep it up to date over time. Is there a good tool to draw, document, and keep up-to-date diagrams of my infra?

- Backup and upgrading is also a persistent problem for me. I will often set up a container, come back to it 6 months later, and have no idea what I did. I have dozens of containers scattered across different machines (NUCs, NAS, desktops, servers, etc). Every container service feels like it has its own convention for where the bind mounts need to go, what user it should be run as, what permissions etc it needs. I can't keep track of it all in my head, especially after the fact. I just want to be able to hit backup, restore, and upgrade on some centralized interface. It makes me miss the old cattle days with VM clone/snapshot. I still have a few VMs running on a proxmox machine that is sort of close, but nothing like that for the entire home lab.

I really want to get to a point, or at least move towards a solution where I could in theory, torch my house and do a full disaster recovery restore of my entire setup.

There has to be something simpler than going full kubernetes to manage a home setup. What do you guys use?

https://en.wikipedia.org/wiki/G%C3%B6mb%C3%B6c

My landers are designed to land sideways.