9P is a filesystem protocol (like NFS or CIFS) rather than a local file system (like btrfs or NTFS). It's used to share files between the host and the guest. That way there's no need to copy files between the host and the guest.
virt-builder is an alternative to installing a guest OS from scratch. It has a selection of popular guest OSes template images that you can quickly install non-interactively.
It's convenient when you don't want to manually install a guest and also don't want to figure out preseed/kickstart/etc.
It makes creating new KVM guests easier and has handy features like the ability to copy in ssh keys so you can connect to the guest right away.
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things.
I downloaded v0.3.99 for Linux x86_64 and stripped the binary. It ends up at 31 MB. The .text section is 25 MB.
I'm surprised by the large size. On my system /usr/bin/git is 4.7 MB, although git is split up into multiple programs. I'm not comparing apples to apples, but this is weird.
If anyone digs into the binary size, please share what you find.
It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.
It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!
In Linux (Wayland) you can copy text from the terminal without pressing Ctrl+C at all. Just select the text. To paste it in another Window, press the middle mouse button.
This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.
I'm the presenter of the talk, but not an io_uring kernel developer or security expert.
The io_uring implementation is complex and the number of lines of code is non-trivial. On the other hand, as code matures and the number of bugs being reported falls, the trade-off between functionality gained and risk of security issues changes. More people will decide to use io_uring as time passes. People already rely on much larger and more complex subsystems like the network stack or file systems.
QEMU is a Software Freedom Conservancy member project like Git, OpenWRT, and many others. You can donate through the Conservancy link you posted and mention which project you wish to support.
It looks plausible: XFS's xfs_dio_write_end_io() updates the on-disk file size. Do you have a link to documentation that confirms this is true for Linux or POSIX filesystems?
Edit: POSIX 1003.1-2017 defines fdatasync(2) behavior in 3.384 Synchronized I/O Data Integrity Completion, where it says "For write, when the operation has been completed or diagnosed if unsuccessful. The write is complete only when the data specified in the write request is successfully transferred and all file system information required to retrieve the data is successfully transferred".
So I think POSIX does guarantee that a write at the end of the file with O_DSYNC/followed by fdatasync(2) (and therefore, Linux RWF_DSYNC) is sufficient. Thank you for pointing out that RWF_DSYNC is sufficient for appends, vlovich123!
io_uring is available from RHEL 9.3 onward. The catch is that it's disabled by default and needs to be enabled at runtime via the "kernel.io_uring_disabled" sysctl.
The Linux RWF_DSYNC flag sets the Full Unit Access (FUA) bit in write requests. This can be used instead of fdatasync(2) in some cases. It only syncs a specific write request instead of the entire disk write cache.
The article mentions getting SPEC CPU running but doesn't share performance results or scalability results (now the CPU can decode twice as many instructions, etc). Can someone who has been following the research in this area share some results?
I'm not familiar with this stuff and don't have time to fully read the specs plus the required background reading. Here is my guess based on skimming the spec:
The application may embed the VAPID public key while the VAPID private key is kept secret by the app developer. That way only the app developer can send valid push notifications. This approach doesn't work when the app running on an untrusted device sends push notifications directly though?
I guess the trick is for the app to treat the push notification purely as a hint to go fetch the latest state from the app server. Do not trust anything in the push notification message. Then it doesn't matter whether the messages are spoofed.
You linked to some Android Intents code in the firebase-message code. I guess that is related to preventing Intent spoofing, but I'm not sure?
Can you be specific about what cannot be configured on mounted embedded media?
systemd follows the drop-in config file model where configuration snippets are placed into directories (like .d/ directories in Debian). It should not be necessary to run utilities from the target system in order to configure it on mounted media.
Drop unit files for services, sockets, filesystem mounts, timers, etc onto the mounted media and they will be detected when the target system boots.
Keep in mind it doesn't magically wake up descheduled tasks. So it's necessary to go through the kernel if the destination task is not currently running on a CPU. The latency in that case will be similar to what we have today.
And in cases where you can guarantee that the destination task is running you can already uses shared memory for low-latency communication today (polling or mwait).
I'm not saying userspace interrupts are useless but they are not as convincing as it seems at first glance. I think more proof of concepts (enabling real applications) and benchmarking are needed to demonstrate the advantages.
crun-vm (https://github.com/containers/crun-vm) is similar to RunCVM in that it can launch container images (or VM disk images) in VMs. It's an OCI runtime so it fits into the podman, Docker, or Kubernetes model.
krunvm (https://github.com/containers/krunvm) is a standalone tool with a similar workflow where you can launch a VM from an OCI image. It predates Bootable Container Images, so I think it injects its own kernel.