SirGiggles

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 given the ancestry of the libraries used.

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 is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example.

Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project)

As a whole, the project has left the choice of web interface up to the user: https://discuss.linuxcontainers.org/t/incus-6-7-has-been-rel...

> But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.

This is getting dangerously close to a mischaracterization of events surrounding the Linux Containers and Canonical split.

See: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde... in addition to: https://linuxcontainers.org/incus/announcement/

EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me.

> And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.

So far from my two years of interaction (both as a lurker and commenter) on the forums and purveyor on the issue tracker, I've yet to see anything that resembles treating Canonical LXD as any form of upstream especially since the split.

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 - https://github.com/dotnet/runtime/issues/14537

Currently it looks like it's currently just 9.0.10

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 here: https://archive.org/details/minecraftcoderpack

According to another message chain, this is also in part related to/influenced by Dockyard no longer funding Elixir projects [1].

Also that the next evolution of "LVN" is likely not going to be Elixir based going by [2]

[1] https://x.com/bcardarella/status/1973535143186014708

[2] https://x.com/bcardarella/status/1973521004174647516

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 generalize my claim to SMB or enterprise.

But the documentation has been very end user oriented, information regarding specifics like seccomp as you mentioned are only discoverable with the search bar and that leads to various disparate locations; and that also isn't taking into account that some of the more nitty gritty information isn't on the Incus portion of linuxcontainers.org, see the LXC Security page for example: https://linuxcontainers.org/lxc/security/

Linux Containers, or LXC, came before Docker and OCI standardization.

As the others have mentioned, Incus is the community fork led by former members of the LXD team.

I think you could also add Xen to that list. IIRC, the old Xen PV mode was purely paravirtualized without using any hardware extensions.

In the context of Incus, they are the same.

Incus and LXC internally use umoci to manipulate the OCI tarball to conform to how LXC runs containers.

See: - https://umo.ci/ - https://github.com/lxc/lxc/blob/lxc-4.0.2/templates/lxc-oci....

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.

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.

12th gen and newer had some form of SR-IOV support in the i915 driver, but I'm not sure whether or not Intel fully upstreamed that.

Here's a project that, iirc, backported and made a DKMS for from Intel's tree: https://github.com/strongtz/i915-sriov-dkms

I also recall from that time that Intel had SR-IOV code for the iGPU (and I think their dGPUs) in the new Xe driver

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

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

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

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.

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.

> (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 understood the GP comment to be getting around the problem of long IPv6 addresses and not actually making every machine globally accessible.