Having toyed around for a while in <a href="/tags/qemu/" rel="tag">#QEMU</a> <a href="/tags/vm/" rel="tag">#VM</a> boxes with <a href="/tags/freebsd/" rel="tag">#FreeBSD</a>, <a href="/tags/openbsd/" rel="tag">#OpenBSD</a> and <a href="/tags/netbsd/" rel="tag">#NetBSD</a> as well. I found that <a href="/tags/gpart/" rel="tag">#gpart</a> in FreeBSD is intuitive and easy to use for disk partition manipulation, followed by gpt in NetBSD. For me, powerful and flexible as fdisk is, it has always been mysteriously difficult and fighting.<br><a href="/tags/usebsd/" rel="tag">#UseBSD</a> <a href="/tags/runbsd/" rel="tag">#RUNBSD</a> <a href="/tags/bsd/" rel="tag">#BSD</a> <a href="/tags/foss/" rel="tag">#FOSS</a> <a href="/tags/unix/" rel="tag">#UNIX</a><br>
vm
Ciao, FediMeteo!<br><br>In the past few days FediMeteo seemed to be having some performance trouble. I dug into it and only found minor issues, until I realised the VM itself had fallen off a cliff. After several reboots it became clear that both bandwidth and I/O latency had dropped to absurd levels. I suspect the provider slapped a cap on it.<br><br>So I took the chance to move everything to another VM and provider, still at 4 euro per month. And starting today, forecasts will be delivered straight from Italy. The performance jump feels like going from a storm to clear skies.<br><br>FediMeteo’s mission goes on. More countries are coming (stay tuned!) and we will keep aiming to serve everything from a 4 euro VM. I do have powerful hardware available, but proving that the project can run on tiny resources is still part of the mission.<br><br><a href="/tags/fedimeteo/" rel="tag">#FediMeteo</a> <a href="/tags/fedimeteoannouncements/" rel="tag">#FediMeteoAnnouncements</a> <a href="/tags/fedimeteoservices/" rel="tag">#FediMeteoServices</a> <a href="/tags/vm/" rel="tag">#VM</a> <a href="/tags/runbsd/" rel="tag">#RunBSD</a> <a href="/tags/freebsd/" rel="tag">#FreeBSD</a><br>
<a href="/tags/proxlb/" rel="tag">#ProxLB</a> 1.1.11 for <a href="/tags/proxmox/" rel="tag">#Proxmox</a> clusters introduces many new features and now fully aligns with Proxmox’s native HA rules.<br><br>ProxLB 1.1.11 was released, focusing on deeper integration and smarter balancing for Proxmox VE clusters. This version introduces a beta integration with Proxmox’s native HA and affinity/anti-affinity rules (please report any kind of bugs!), allowing ProxLB to work seamlessly with existing placement constraints instead of duplicating them.<br><br>The balancing behavior has also been improved: operators can now prefer smaller or larger VMs during placement, and node memory reservations are respected to reduce overcommitment.<br><br>Overall, 1.1.11 makes ProxLB more predictable, safer, and better suited for production use, while paving the way for future HA-aware scheduling improvements.<br><br>Blog post: <a href="https://gyptazy.com/blog/proxlb-proxmox-ha-affinity-rules-version-1-1-11/" rel="nofollow" class="ellipsis" title="gyptazy.com/blog/proxlb-proxmox-ha-affinity-rules-version-1-1-11/"><span class="invisible">https://</span><span class="ellipsis">gyptazy.com/blog/proxlb-proxmo</span><span class="invisible">x-ha-affinity-rules-version-1-1-11/</span></a><br>Release/Changelog: <a href="https://github.com/gyptazy/ProxLB/releases/tag/v1.1.11" rel="nofollow" class="ellipsis" title="github.com/gyptazy/ProxLB/releases/tag/v1.1.11"><span class="invisible">https://</span><span class="ellipsis">github.com/gyptazy/ProxLB/rele</span><span class="invisible">ases/tag/v1.1.11</span></a><br>GitHub: <a href="https://github.com/gyptazy/ProxLB" rel="nofollow"><span class="invisible">https://</span>github.com/gyptazy/ProxLB</a><br><br><a href="/tags/virtualization/" rel="tag">#virtualization</a> <a href="/tags/vm/" rel="tag">#VM</a> <a href="/tags/vps/" rel="tag">#VPS</a> <a href="/tags/pve/" rel="tag">#PVE</a> <a href="/tags/prox/" rel="tag">#Prox</a> <a href="/tags/proxmoxve/" rel="tag">#ProxmoxVE</a> <a href="/tags/kvm/" rel="tag">#KVM</a> <a href="/tags/vmware/" rel="tag">#VMware</a> <a href="/tags/enterprise/" rel="tag">#Enterprise</a> <a href="/tags/homelab/" rel="tag">#Homelab</a> <a href="/tags/resourcescheduler/" rel="tag">#ResourceScheduler</a> <a href="/tags/affinity/" rel="tag">#affinity</a> <a href="/tags/antiaffinity/" rel="tag">#antiaffinity</a> <a href="/tags/devops/" rel="tag">#devops</a> <a href="/tags/tools/" rel="tag">#tools</a> <a href="/tags/python/" rel="tag">#python</a> <a href="/tags/debian/" rel="tag">#debian</a><br>
I always was interested in and kept my eye out for the <a href="/tags/bodhi/" rel="tag">#Bodhi</a> <a href="/tags/linux/" rel="tag">#Linux</a>, mainly because they use the different and characteristic <a href="/tags/enlightenment/" rel="tag">#Enlightenment</a> <a href="/tags/wm/" rel="tag">#WM</a>. <a href="/tags/e17/" rel="tag">#E17</a> was great when I tried it on bare metal and in <a href="/tags/vm/" rel="tag">#VM</a>. I knew their development was not the fastest but it was not necessarily an issue since it was stable and smooth to use. It was kinda mixed feeling when I knew they had to fork and develop the the <a href="/tags/moksha/" rel="tag">#Moksha</a>.<br><br><a href="https://mokshadesktop.github.io/Hello-World/" rel="nofollow">Introducing Moksha Desktop</a><br>