31–40 of 42 posts
This would be interesting on a Spark or two. I don't know how seamless the GPU and networking cluster setup would be when resource sharing between agent and post-training VMs.
A good alternative is incus and running LXC and or OCI containers, GPU works in those and can be shared with multiple instances
Corpo-only support, Q: Can I run Proxmox VE on a Raspberry Pi or a similar single-board computer? A: No. An arm64 host must boot through UEFI and describe its hardware through ACPI. Device-tree-only boards and legacy boot are not supported. Basically no consumer facing arm SBCs, NAS boxes, etc will work with this. Frankly, I see this as a good thing though: Maybe it'll make the SBC market get its stuff together and s…
>Maybe it'll make the SBC market get its stuff together and start actually doing UEFI instead of every board needing a custom build. If your board needs custom build, it's probably because there's no SPI flash with the bootloader. The board can't describe itself. This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you conca…
This is what NixOS does as well, but it still requires the kernel to effectively have support for your specific SoC.
On ARM ACPI/UEFI, ACPI abstracts many parts away reducing the need for this.
Corpo-only support, Q: Can I run Proxmox VE on a Raspberry Pi or a similar single-board computer? A: No. An arm64 host must boot through UEFI and describe its hardware through ACPI. Device-tree-only boards and legacy boot are not supported. Basically no consumer facing arm SBCs, NAS boxes, etc will work with this. Frankly, I see this as a good thing though: Maybe it'll make the SBC market get its stuff together and s…
Earlier quoted context omitted.
> Certainly the fact that Proxmox heavily uses perl is a strike against it. Besides that being very outdated view of our tech stack, given that we have used Rust for every new development for seven years already and migrated lots of Perl code to it - what's actually wrong with using Perl? Is all Perl, Python, etc., generically just categorally unusable for someone? Or is the fact that Perl - just like Python and many…
> Is all Perl, Python, etc., generically just categorally unusable for someone? I am not the OP but my take as someone who is not keen on Perl or Python: 1. Perl has a dense programming style and is quite opaque to new maintainers. You also have CPAN dependencies to keep track of. 2. Python is more readable than Perl, but has its own issues (dependency hell etc.) and still does not address the issue of dynamic typing…
"Python still does not address the issue of dynamic typing and the inability to test correctly"
The only issue with Python is performance, which is only an issue if you need performance.
Earlier quoted context omitted.
The Orange Pi 6 Plus is full UEFI and boots things like FreeBSD natively. It's a bit higher end than a Raspberry Pi, but they're definitely in the SBC market. I'd assume they'll work with Proxmox if they support the newish 5G ethernet chips out of the box.
That thing is apparently $366 USD with 16GB of RAM, so my first thought is really "it had damn well better boot things properly if it costs so much".
The price on SBCs is insanity right now because they have RAM.
I literally am in the process of migrating away from proxmox because they said publicly they would not support arm. This was necessary, but guys you got the memo too late
Earlier quoted context omitted.
>Maybe it'll make the SBC market get its stuff together and start actually doing UEFI instead of every board needing a custom build. If your board needs custom build, it's probably because there's no SPI flash with the bootloader. The board can't describe itself. This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you conca…
> This could be solved https://sd-card-images.johang.se/ style: single kernel+rootfs OS image, with the small board-specific bootloader + dtb, which you concatenate to the OS image. This is what NixOS does as well, but it still requires the kernel to effectively have support for your specific SoC. On ARM ACPI/UEFI, ACPI abstracts many parts away reducing the need for this.
Corpo-only support, Q: Can I run Proxmox VE on a Raspberry Pi or a similar single-board computer? A: No. An arm64 host must boot through UEFI and describe its hardware through ACPI. Device-tree-only boards and legacy boot are not supported. Basically no consumer facing arm SBCs, NAS boxes, etc will work with this. Frankly, I see this as a good thing though: Maybe it'll make the SBC market get its stuff together and s…
> Device-tree-only single-board computers, such as the Raspberry Pi, are not supported > Virtual machines always boot through UEFI, provided by the ARM build of OVMF (AAVMF). SeaBIOS is not available on arm64. Few things to be wary of..!