Launchpad does this for everything, as does sbuild/buildd in debian land. They generally make it work by both: running the build system in a neutered VM (network access generally not permitted during builds, or limited to only a debian/ubuntu/PPA package mirror), and going to some degree of invasive process/patching to make build systems work without just-in-time network access.
SUSE and Fedora both do something similar I believe, but I'm not really familiar with the implementation details of those two systems.
I’m only familiar with the Fedora system. The build is hermetic, but the source input come from fedpkg new-sources, which runs on the client used by the package developer.
A medium range trail/offgrid camera is perfect for this application. All the other solutions in the space are sdcard only, or dependent on some variant of LTE/5G.
I don't think most people really understand the compute complexity required for LTE and 5G terminals. It's telling that pretty much every discrete-ish full-speed LTE or 5G modem I've lain eyes upon is actually an embedded SBC running its own OS, with attendant power requirements.
The companies do that because by far the largest market for LTE/5G modems is smartphones.
They could make a more cut-down modem chip, but why would they? They already make hundreds of millions on smartphone SoCs. Just rebadge that silicon as modem ICs, no one cares that an LTE stick runs full Android.
Without limitations on authority and control, I worry more that the world will devolve into a multilateral legal hellscape, even moreso than exists today. Given how much is dependent on software, you are going to have the governments of pretty much any country with multinational exposure trying this in the next 10 years if recent UK and EU developments are any indicator.
The early MacOS era as well as pretty much the entire classic Mac OS era was infamous for being a more-or-less do it yourself environment for adding bits the OS didn't have or did sub-optimally for given use cases.
The wisdom of such a freewheeling ecosystem in today's era is maybe debatable, but given how user-hostile the mainline OS and software vendors can be, I say there's still plenty of room for that ecosystem and it should be preserved.
The old OS was awesome in that way. As extensions loaded the would appear in sequence at the bottom of the screen when a driver failed the boot would lock-up and one could reboot with extensions off change the boot order or remove the driver from the system folder. Very easy to mess with.
bios flashes are typically preflashed prior to soldering to boards -- some vendors route jtag or spi contacts, but you're more likely to need a vampire/pogo clip on for the TSOP or equivalent chip, or have fun with resoldering the bios flash if you're needing to recover from this.
It's not impossible to do in the field, but you can't really count on vendors surfacing that interface usually.
I've worked with automated EEPROM/Flash programmers (earlier versions of this line: https://www.bpmmicro.com/device-programmers/automated-progra...), and used pre-programming services from distributors, like Digi-Key, but that was the exception. It's almost exclusively faster, cheaper, and easier to load firmware from a test fixture. You need to test the assembly anyway, and it's much easier to update a test procedure, when a new firmware is developed, than to update and track inventory of pre-programmed devices, especially when different firmware versions are needed for different hardware variations.
Pogo pins are only really needed for mass production, especially for reducing repetitive stress injuries. For one-off updates, if a header isn't populated, it's easy to hold an unsoldered header in place, for long enough to flash an update.
the prior art in this area is going to be PCI&USB passthrough implemented in qemu and xen, with related but separate in-guest or 'in-host' virtual devices representing the bridged device.
Some related work in the SR-IOV & iommu space makes this a lot easier to implement as well. I would be very surprised if zero new security edge cases get discovered in the next five years or so however. Regardless, I'd look forward to seeing the results of RedoxOS's work here, as this would be a practical alternate implementation of driver domains like you see used in Xen and Qubes.
I agree, as we get even further away from the 90s and 2000s and data gets more valuable, having mechanisms like this to access old systems is vital now that it's getting harder to make "missing link" type machines that have parallel/scsi/ATA/FW/etc. to dump old data
reply