I work for a company that makes money supporting FLOSS. Our members pay fairly hefty membership fees because they have a vested interest in their chips being well supported by Linux and the wider ecosystem. That money funds common projects they all benefit from all well as numerous maintainers in projects keeping those projects ticking.

The engineers on the project I mostly work on are predominantly paid to work on it. We value our hobbyist itch scratchers (~10% off contributors) but it’s commercial money that keeps those patches reviewed and flowing.

Magic Wormhole - it’s been around awhile but it’s super useful for moving files from your internet connected server to your phone without going through multiple hops copying stuff to you local machine and finding a cable.

That’s how it starts. Before you know it you’ll be buying no-name smart bulbs from Ali Baba and investigating custom firmware for full local only control.

QEMU is always going to focus on emulation fidelity first and there are few shortcuts. With floating point the differences aren’t generally in the numbers but in how the NaNs and other edge cases are handled. If you want to execute FP heavy code you should be cross compiling anyway.

QEMU absolutely will use hardware floating point where it can but only when it will give the correct results. FEX and Box64 are user mode emulators which achieve their speed by avoiding emulation where they can buy thunking at API boundaries.

Other way around. Loyalty cards have always been about getting that sweet sweet data about customer habits.

Btrfs never really worked out for me (I think default COW doesn’t play nice with VM images) and ext4 works great.

Pretty much. From v8.0 onwards all the extra features are indicated by id flags. Stuff that is relevant to kernel mode will generally be automatically handled by the kernel patching itself on booting up and in user space some libraries will select appropriately accelerated functions when the ISA extensions are probed. There are a bunch off advisory instructions encoded in the hint space that will be effectively NOPs on older hardware but will enhance execution if run on newer hardware.

If you want to play with newer instructions have a look at QEMUs “max” CPU.

Virt-manager isn’t super scriptable but the underlying libvirt can be controlled by virsh which is a shell interface to libvirt. You can use both at the same time, e.g. start and stop via virsh and access to gui container via virt-manager/virt-viewer.

TIL

It’s called vrms (virtual RMS) and Debian at least packages it.

Why do the $20 subscription when the API pricing is much cheaper, especially if you are trying different models out. I’m currently playing about with Gemini and that’s free (albeit rate limited).

I wrote a bit of BASIC on my Spectrum but there was a reason they had keyword shortcuts on that keyboard. It wasn’t until I got my Dragon 32 which had I proper keyboard that I really got into coding.

My dad failed his 11+ so was sent to a technical school so he actually learnt how to lay a row of bricks or how to beat out lead flashing. He did end up doing a PhD in Physics but I suspect his early school years explain why he’s always been much more practical than me. My wife was a stage tech during uni so I’ll happily defer to her for joinery. I can just about solder a copper pipe or big pads on a PCB.

SystemReady is already a thing. When it becomes mandatory for design wins hopefully it will become more common place.

I wouldn’t say that, it’s just there is a lot in vendor kernels and little incentive to upstream stuff for older SoCs that have already shipped. It’s true Google has come around to the importance of not drifting too far from upstream and hopefully we are starting to see the results of that change in attitude.

As I understand it my colleges in the QC landing team @ Linaro spend a lot of time getting stuff into the various upstreams.

It really depends how you see the firmware boundary. You can either treat it as a set of magic numbers you load onto the hardware so it works or see it as an intrinsically programmable part of your system that you should be able to see the source code for or live without support for the device.

I run Circe in Emacs because it’s lightweight and integrates with the modeline for not overly distracting notifications.

If the system is SystemReady then the EFI boot chain is fairly straightforward now. My current workstation just booted off the Debian usb installer like any other pc.

It’s a web of trust. If the package maintainer is doing due diligence they should at least be aware how the upstream community runs. If it’s a one person passion project then it’s probably possible to give the changelog and diffstata once over because things don’t change that fast. Otherwise they are relying on the upstream not shipping broken stuff.