Upstream would accept a patchset that exposed an independent Gunyah-specific UAPI (why not the same one as downstream — crosvm already supports that) instead of pretending to be KVM (it's not a "port", you can't port a hypervisor to a hypervisor).
KVM is available on current compute platforms (laptops) if you escape to EL2 via slbounce; and on Glymur (X2E) it will be available by default (yay!).
X1E laptops have fully working DisplayPort+USB3+USB2+PD over USB-C unlike Asahi Macbooks :p There really aren't that many gaps in X1E laptop support left.
EL2 is coming by default on Glymur (X2E) (yaaaay), can be enabled in config on some IoT platforms, and can be booted into via Secure Launch on previous compute platforms (Hamoa/Purwa aka X1E/X1P, SC8280XP), search for slbounce.
On phone platforms.. probably not? Or Android might want it for pKVM..
Only if you care deeply about always having the latest data, rather than just consistent data.
I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.
No, xf86 naming is still there, but you're kinda misunderstanding what a driver is. These xf86 things are tiny pieces for the xorg server. (Irrelevant with Wayland, obviously.) The real "meat" of the driver is in two places: Mesa and the kernel. The kernel module is the hard part. You can install the higher level parts without it, they just won't be useful. You can have the xf86 thing, and libdrm_nouveau, and Mesa dri_nouveau, they don't even require any porting, but they're absolutely useless without the kernel driver, they wouldn't have anything to talk to.
TeamViewer/AnyDesk/VNC is not "remote windowing", it's "remote access" to a whole desktop. And that's easily available for the wlroots ecosystem https://github.com/any1/wayvnc
But actually "remote windowing/apps" is even better supported, it's a universal proxy: https://gitlab.freedesktop.org/mstoeckl/waypipeAbsolutely does not require any support from the core protocol.
I don't think Nouveau ever was ported before. I actually tried it myself (unsuccessfully). Kind of a painful codebase.
> usually some versions behind
Currently on 5.4-5.5, only Big Navi is not supported yet. With the state of the GPU market right now, we'll probably catch up before the prices on those become sane :D
Funnily enough, it's Intel that's slowing the updates down more than anything. amdgpu is rarely an early adopter of new Linux kernel API surface. i915 is very much one, all the time.
That's how secure boot should work. Replacing the root of trust should require serious physical access that can be tamper-evident. And yeah, out of the box, the trust is with the vendor — who else would be trusted in a device that doesn't have an owner yet?
Haha, that's like an epic combo of things I dislike — x86, legacy BIOS, 32-bit OS on 64-bit CPU, unaccelerated graphics, and X :)
> signed booting
It's not like FreeBSD was an early adopter of that. Some kind of secure boot support things have landed in the last couple months, and veriexec for signed stuff, but very few people have started using this.
> separate ISOs
Or a "fat" ISO that has both 32 and 64 bit versions?
> nVidia proprietary drivers
With these, there's already an issue with which versions of that support which cards..
No way. Processes allocating terabytes (GHC Haskell compiled programs, AddressSanitizer, etc) work fine out of the box.
Reading tuning(7):
> Setting bit 0 of the vm.overcommit sysctl causes the virtual memory system to return failure to the process when allocation of memory causes vm.swap_reserved to exceed vm.swap_total. Bit 1 of the sysctl enforces RLIMIT_SWAP limit (see getrlimit(2)). Root is exempt from this limit. Bit 2 allows to count most of the physical memory as allocatable, except wired and free reserved pages (accounted by vm.stats.vm.v_free_target and vm.stats.vm.v_wire_count sysctls, respectively).
Soooo vm.overcommit=0 does not mean "no overcommit" (which would make sense), no, it seems to mean something like "no special flags like disabling overcommit" :D
Well, a 32-bit Linux binary on 64-bit FreeBSD can call into the GPU driver and render 3D, at least :) But I don't think anything is guaranteed for sure. 32-bit crap is not exactly a priority, haha.
On the other hand, syscalls across architectures of the same bitness are exactly the same, minus the newer architectures just not having some historical abominations like sbrk. (IIRC, syscalls are different between even aarch64 and amd64 on Linux, which is just… why?!?)
Because Google (even just search and mail) is extremely popular, and they ran a relentless advertising campaign, persistently telling everyone to install Chrome, right on the front page among other places.