I think this would depend on Virtio-GPU Native Context which, if I recall correctly from the qemu-devel mailing list, is the next natural progression from Virtio-GPU Vulkan

Edit: Can't substantiate further, but this is what Huang Rui, the prior steward of the Venus patchset, said: https://lore.kernel.org/all/20240411102002.240536-1-dmitry.o...

Edit 2: For further clarity, Virtio-GPU Native Context would permit running the native GPU drivers (with some modifications, minimal is what I remember being claimed) inside a VM

What do you mean by stable? 2.2.7 supports the 6.12 kernel if I'm not mistaken

Of course, 2.2.7, what was released checks notes 1 hour ago. So I think GP was correct at the time of their post.

https://github.com/openzfs/zfs/releases/tag/zfs-2.2.7

Then look back to 2.2.6, it supported up to 6.10. A far cry from only supporting only up to 6.6 so I'm not seeing where they were going with with their initial statement until they define what they mean by stable.

https://github.com/openzfs/zfs/releases/tag/zfs-2.2.6

Edit: changed sentence to make more sense

Edit 2: And if we are to interpret stable as in Linux LTS, then that would be 6.12 which is supported by 2.2.7 as you said

Linux kernel 6.10 is EOL.

Non-LTS kernels very frequently go EOL before OpenZFS supports them, or there is only a very brief window that there is support for a non-EOL kernel.

In practice, it's hard to use a non-LTS kernel with openzfs for any significant duration.

That's a fair point and I don't disagree. I guess my main point of contention was the implication that either a) ZFS wasn't stable on anything non-LTS or b) the Linux kernels themselves were unstable outside of a LTS.

What stable means in this case is subject to individual use cases. In my case, I don't find having to wait a bit for ZFS to catch up despite being on an EOL kernel to be catastrophic, but after having some time to think, I can see why someone would need an LTS kernel.

I think we are on the same page. To clarify: if your goal is to be on stable ZFS AND non-EOL Linux kernel, then LTS kernel is usually the only option. There may be windows where there are non-LTS-non-EOL kernels supported, but non-LTS kernels go EOL very quickly, so those windows are fleeting.

This impacts distributions like NixOS in particular, which have a strict policy of removing EOL kernels.

I wasn't aware NixOS prunes EOL kernels, thanks for letting me know; this throws a bit of wrench/damper in my personal machine plans.

Woah woah woah don't let me dissuade you from NixOS. I am still a happy NixOS+ZFS user, and my fingers are crossed that I'll soon get to upgrade to kernel 6.12 :)

No worries on that front, I expect that fun fact to be just a minor setback but I'm still pretty dead set on making my personal infrastructure declarative, reproducible, and anti-hysteresis.

Honestly I wouldn't even try running ZFS on anything else but a distro that ship it like ubuntu or its variant or a distro with long term support like almalinux 9.

Virtio-GPU Venus is similar to Virgl except it passes through Vulkan commands rather than OpenGL

Most likely they did not adjust +P which bumps the max process limit

Sorry for the segue, but how your team's experience with C# on VSCode? Any recommendations for plugins? I've heard of a lot of people recommend Rider but not much, aside from neonsunset, talk about VSCode.

Great.

C# DevKit is really all you need (and the same plugins you would normally have like GitLens, etc.).

Refactoring experience isn't as good as Rider (JetBrains are kings of refactoring tooling). But for all other cases VS Code is fast and ergonomic.

Rider does have some nice things for supporting working with SQL databases that I do envy once in a while.

Just in case: DevKit is optional and requires an account, you can just use the base C# extension which is what provides the language server and the debugger, if you prefer VSCodium there's a fork of it which packs Samsung-authored netcoredbg instead of vsdbg so that is covered too.

For F# - Ionide works great, I like it a lot, integrates seamlessly with existing C# projects.

To be pedantic for a moment...

> You can't use Go to write a kernel ...

Not a production kernel, but MIT did use Go to "study the performance trade-offs of using a high-level language with garbage collection to implement a kernel" [1]

There is also gVisor [2] which implements, as best as I can describe, a kernel in user space. It's intent is to intercept syscalls made in containers and to redirect its execution in a sandbox.

> ... program a microcontroller ...

I'm not sure if one would classify this as a microcontroller, but USB Armory did write a, iirc, Go compliant runtime for bare metal ARM and RISC-V [3].

There is also TinyGo [4] with the following listed microcontroller support [5]

[1] https://github.com/mit-pdos/biscuit

[2] https://gvisor.dev/

[3] https://github.com/usbarmory/tamago

[4] https://tinygo.org/

[5] https://tinygo.org/docs/reference/microcontrollers/

The article is talking about ChromeOS merging to an Android base.

Ninja edit: this article should clarify some things: https://blog.chromium.org/2024/06/building-faster-smarter-ch...

It's possible your previous knowledge was based on HiPE, which to my understanding was kind of sucky.

The new JIT in Erlang/OTP 26 is called BeamASM and is based upon asmjit

Most prolific example was this: https://news.ycombinator.com/item?id=30758651

Not a big one, but this was of personal note: https://github.com/bytecodealliance/wit-bindgen/issues/306

A caveat that bears mentioning is that an export of a Bitwarden vault does not contain attachments.