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.

My Organic maps has a download screen for the maps which regularly update outside of the app itself.

I think you underestimate how much storage those tiles take up compared to the vector map data.

The data updates are handled separately in app

Won’t it? I thought you just needed to enable the apps you want. My fdroid AntennaPod is certainly usable in it.

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.

I write assembly for test cases and early setup code. I read far more assembly than I write.

Lindsay Ellis did a nice video essay on the guy which I enjoyed which said something similar. Unfortunately I can’t seem to find it now - it might only be on nebula.

TIL

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

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.

Self hosting takes time and energy and most open source developers join projects because they are interested in the project not becoming admins. On top of that building a CI system is an expensive undertaking when a lot of hosting solutions provide a fair amount of compute for free to qualifying projects.

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.

I’m not sure if that is the op or Lemmy cropping stuff. I’ve seen similar when I’ve tried to post stuff.

I don’t think Kamikaze’s came about until much later in the war. I’m sure a few heavily damaged planes went down taking targets with them though.