The market is smaller (maybe, I'm not sure what the statistics are) but it would be interesting to see how Xen stacks up; also stuff like gVisor or libkrun. The latter is probably implicitly the same as Firecracker…
I think it's pretty likely they are since they gave a talk at Code BEAM Europe 2025: https://www.youtube.com/watch?v=tC435RGwRCI
> https://github.com/zabbly/incus/issues/89#issuecomment-30764... > I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending. This one…
Can you substantiate this? The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
There is .NET support for FreeBSD but it is relatively recent; FreshPorts lists it as added in January 2024. See: - https://www.freshports.org/lang/dotnet/ - https://wiki.freebsd.org/.NET -…
This is deliberate misinformation. You can easily see that versions prior to Beta 1.8 were obfuscated just by downloading the .jar for the older versions on minecraft.wiki. You can even view some of the old MCP mappings…
This looks more like a wrapper over Qemu/KVM
I think things are swinging back the other way if I have understood the more recent PVHv2 stuff correctly.
This has been one personal pet peeve with the documentation surrounding Incus. As a stack, Incus has been exceptional, it has largely replaced Proxmox and Podman Quadlets for me. For context, I homelab so I cannot…
I think you could also add Xen to that list. IIRC, the old Xen PV mode was purely paravirtualized without using any hardware extensions.
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.
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.
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…
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.…
What do you mean by stable? 2.2.7 supports the 6.12 kernel if I'm not mistaken
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
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
> (which btw recently was in the news for more significant negative reasons) Do you by chance mean CVE-2024-{39924, 39925, 39926}?
It doesn't need to, IPv6 has unique local addresses which is are non-globally reachable; I recall those had it's own can of worms depending on deployment but it's an option for private, local addresses. EDIT: I also…
To add on to your experience, my first encounter with Digital River was back around a decade a ago when I bought Battlefield 2142 from EA (pre-Origin)
Would the async experiment also imply better interop between .NET languages? One issue I’ve heard from F# devs was the lack of ability to comfortably call C# asynchrony methods
Sorry I want to apologize, I made an error in my initial statement and meant Erlang _External_ Term Format instead of Erlang Term Format. Does this change anything w.r.t your response?
This might be answered elsewhere but how does LVN in its current state handle server disconnects (and for prolonged periods of time, in say no coverage zones)?
The market is smaller (maybe, I'm not sure what the statistics are) but it would be interesting to see how Xen stacks up; also stuff like gVisor or libkrun. The latter is probably implicitly the same as Firecracker…
I think it's pretty likely they are since they gave a talk at Code BEAM Europe 2025: https://www.youtube.com/watch?v=tC435RGwRCI
> https://github.com/zabbly/incus/issues/89#issuecomment-30764... > I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending. This one…
Can you substantiate this? The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
There is .NET support for FreeBSD but it is relatively recent; FreshPorts lists it as added in January 2024. See: - https://www.freshports.org/lang/dotnet/ - https://wiki.freebsd.org/.NET -…
This is deliberate misinformation. You can easily see that versions prior to Beta 1.8 were obfuscated just by downloading the .jar for the older versions on minecraft.wiki. You can even view some of the old MCP mappings…
This looks more like a wrapper over Qemu/KVM
I think things are swinging back the other way if I have understood the more recent PVHv2 stuff correctly.
This has been one personal pet peeve with the documentation surrounding Incus. As a stack, Incus has been exceptional, it has largely replaced Proxmox and Podman Quadlets for me. For context, I homelab so I cannot…
I think you could also add Xen to that list. IIRC, the old Xen PV mode was purely paravirtualized without using any hardware extensions.
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.
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.
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…
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.…
What do you mean by stable? 2.2.7 supports the 6.12 kernel if I'm not mistaken
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
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
> (which btw recently was in the news for more significant negative reasons) Do you by chance mean CVE-2024-{39924, 39925, 39926}?
It doesn't need to, IPv6 has unique local addresses which is are non-globally reachable; I recall those had it's own can of worms depending on deployment but it's an option for private, local addresses. EDIT: I also…
To add on to your experience, my first encounter with Digital River was back around a decade a ago when I bought Battlefield 2142 from EA (pre-Origin)
Would the async experiment also imply better interop between .NET languages? One issue I’ve heard from F# devs was the lack of ability to comfortably call C# asynchrony methods
Sorry I want to apologize, I made an error in my initial statement and meant Erlang _External_ Term Format instead of Erlang Term Format. Does this change anything w.r.t your response?
This might be answered elsewhere but how does LVN in its current state handle server disconnects (and for prolonged periods of time, in say no coverage zones)?