HN user
Doing CTO, rust, backup, HA, clustering, and general virtualization stuff @ Proxmox
Home is a little farm in the steep slopes of the Alps in South Tyrol.
https://thomas.lamprecht.org/
Interesting comparision with NeoVim, given that it was basically created to provide a better default (config) experience than classic vim. We might be close to PostNeoVim (or is helix [0] already that?).
[0]: helix: A post-modern text editor. https://helix-editor.com/
Has anybody experience with using this with strong dialects, like e.g. bavarian-family (German) based ones? Or other languages one too, as I'd figure basic behavior and approaches to improve detection of such is often similar in principle for dialect style variants of a language.
I mean, I naturally should try myself, and plan to do so, but slightly lower on my free time priority list and I figured someone else might have explored this already.
It's because all the frequent comment that this pelican is in the trainings set now also got into the trainings set and models adapt. /joking (I hope)
Interesting to read. I actually did not really looked into the rest of Italy's fibre build out state, but FWIW here in South Tyrol - basically the other end of the country - there's fully build out fibre access into every municipality since 2013. And basically every village (outside the cities most municipalities consist of a handful of villages here) got access a few years too, even the ones with sub 1k population.
Sure, but Qualcomm upstreaming their support to mainline would also have broad benefits for them and be a win-win. Their C-suits & bean counters are seemingly just not getting that themselves nor having anyone that knows that high enough the hierachy...
FWWI, we did evaluate and benchmark microVMs back in 2020. Back then it was not really seen worth it the maintenance cost compared to what it brought to the table, but it makes sense to re-evaluate that again soonish; with native dynamic load balancing and affinity rules (and further orchestration improvements being lined up) they might be better leveraged today.
Oh, and mailing lists are a bliss to use compared to (barely loading) forges, at least to me and especially with public inbox and tools like b4 and lei for patch review, management and applying. For the sending side it's basically a git send-email command to pve-devel@list.proxmox.com, see https://git-send-email.io for a simple tutorial.
Sure, if you're fine with double standards, every issue from Windows is a non-issue, even something simple as using a local account-or being forced to view ads even after paying (!) for the OS.
It's certainly subjective, but the amount of tech support I have to give has dropped significantly since switching the few people I care enough about to help from Windows to a mature Linux distro like Debian, while they are certainly not less productive.
I cannot even install a Windows system with a local account anymore without having to open the terminal and enter some obscure commands.
A modern Debian or Fedora with KDE is a breeze otoh, I set that up for relatives and my SO, and they're all more than happy with it. Bugs exist, like in all software, but the friction is way less compared to wrangling with Windows nowadays.
At work, we do what I wrote frequently, and it works very well and adaptions are rather the outlier than the norm, especially as we focus on backporting only important bug fixes and especially security fixes. We do also pour quite a bit of effort into separating changes into actual sensible commits (not just PRs), which is a bit of work but pays off dramatically if one has older releases they want to provide security and (grave) bug fix support. I.e., this is not just some random thought experiment, my staff and I successfully employ this approach for well over a decade (and about another decade before my time at the company).
Sure, not all workflows are a good fit for this, that's why I started with a disclaimer. But, if you want to do stable release in general, then it's IMO better to adapt the general workflow to that (which provides other benefits too, like on bisecting or when writing actually good release notes), than trying to force that on a not so compatible workflow.
But I'd be happy to hear alternatives, like how you solve this; always interesting to read others perspectives that lay out their solutions (not just why mine doesn't work 1:1 for you, which is basically a given for any non-trivial project).
In that case one can just branch off a stable-x.y branch from the respective X.Y release tag as needed.
It really depends on the whole development workflow, but in my experience it was always easier and less hassle to develop on the main/master branch and create stable release or fix branch as needed. With that one also prioritizes on fixing on master first and cherry-pick that fix then directly to the stable branch with potential adaptions relevant for the potential older code state there.
With branching of stable branches as needed the git history gets less messy and stays more linear, making it easier to follow and feels more like a "only pay for what you actually use" model.
Your CAD experience level sounds like it is similar, but a bit higher than mine (2 years hand drawing, 2 years CAD, some more hobbyistic CAD & 3D modelling over the years for personal projects), so yeah SweetHome3D might not be that much help for you over using some CAD software directly.
I found furniture handling OK, but certainly has its rough edges. Good thing is that one can just import 3d models and so create the relevant pieces of furniture themselves; or use the generic boxes that SH3D has, if it's just for 2d space usage.
I did a few office space modellings with it, i.e. to get a feeling of how the space could be used best, and for that I found it quite OK. The result I got compared to the time invested was pretty good for my taste.
The one (docker compose) builds on top of the other (OCI images & runtimes).
We would have required to implement runtime integration anyway, and I hardly see any benefit in not releasing that lower level integration earlier.
PVE itself is still made of a lot of perl, but nowadays, we actually do almost everything new in rust.
We already support CPUsets and pinning for Container VMs, but definitively can be improved, especially if you mean something more automated/guided by the PVE stack.
If you have something more specific, ideally somewhat actionable, it would be great if you could create an enhancement request at https://bugzilla.proxmox.com/ so that we can actually keep track of these requests.
It makes no sense to add an extra layer, and we definitively do not want to make us and our users dependent of docker project.
There exist many OCI runtimes, and our container toolkit already provides a (ball parked) 90% feature overlap with them. Maintaining two stacks here is just needless extra work and asking for extra pain for us devs and our users, so no, thanks.
That said, PVE is not OCI runtime compatible yet, that's why this is marked as tech preview, but it can be still useful for many that control their OCI images themselves or have an existing automation stack that can drive the current implementation. That said, we plan to work more on this in the future, but for the midterm it will be not that interesting for those that want a very simple hand-off approach (let's call it "casual hobby homelabber"), or want to replace some more complex stack with it; but I think we'll get there.
Correction: In Proxmox VE we're not using virsh/libvirt at all, rather we have our own stack for driving QEMU on a low-level, our in-depth integration, especially with live local storage migration our Backup Servers dirty-bitmap (known as change block tracking in vmware worlds) would be possible in the form we have it. Same w.r.t. our own stack for managing LXC container.
The web UI part is actually one of our smaller code bases relative to the whole API and lower level backend code.
For that purpose Sweet Home 3D might be easier to use, especially if one has not that much CAD experience.
No, it's not. And if that's what confuses one, it will not be the actual source of these problems.
Obviously, but additionally, providing validation on the frontend can help UX a lot. Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission. And one solution for that problem can be using a native picker.
FWIW, the few non-techie people in my life that I care enough to administer their notebooks and provide support all run KDE on Debian happily.
While I had some reservations about acceptance when I made the switch from Windows 7, it turned out that it was one of my better choices of my life, and resulted in much less work for me compared to what Windows caused for me previously. And GNOME just did not work out well for most of these people and the workflows they are used to.
I like pass and use it a lot, especially as it provides a good and safe backup for the case my vaultwarden instance goes up in smokes.
There is also a drop-in replacement with has some extra features and a bit better UX in some parts, personally I only really use it for the better support for handling multiple GPG keys, as I got some physical backup keys and it can be also nice teams for a shared vault.
There was a time when people said that about AMD.
Don't get me wrong, Intel's outlook is IMO currently indeed rather bleak, but I would not completely write it off just yet.
Is it like writing frontend code in Rust and compiled to WASM ?
Exactly, it's actually quite lightweight and stable plus mostly finished, so don't let the slower upstream releases discourage you from ever trying it more extensively.
We build a widget library with our products as main target around Yew and native web technologies, you can check out:
https://github.com/proxmox/proxmox-yew-widget-toolkit
And the example repo:
https://github.com/proxmox/proxmox-yew-widget-toolkit-exampl...
For code and a little bit more info. We definitively need to clean a few documentation and resource things up, but we tried to make it so that it can be reused by others without tying them to our API types or the like.
FWIW, the in-development Proxmox Datacenter Manager also uses our Rust / Yew based UI, it's basically our first 100% rust project (well, minus the Linux / Debian foundation naturally, but it's getting there ;-)
The linked forum post has an FAQ entry, this was a carefully weighted decision with many factors playing a role, including having more staff available to manage any potential release fall-out on our side. And we're in general pretty much self-sufficient for any need that should arise, always have been that way and provide enterprise support offerings that back our official support guarantees if your org would have the need for that.
Finally, we provide bug and security updates for the previous stable release for over a year, so no user has any rush to upgrade now, they can safely choose any time between now and until August 2026.
We manage anything, including package builds, ourselves if the need should arise; we also monitor Debian and release critical bugs closely, we see no realistic potential for any Proxmox relevant package to disappear, at least nothing higer compared to that happening after the 9th.
FWIW, we got staff members that are also directly involved with Debian which makes things a bit easier.
now how do I log in to rewrite the ifcfg file when the interface wasn't brought up with the correct config because it has a different name?
Unlike most desktops, basically all servers got out-of-band management (e.g. IPMI) and a NIC swap is something that needs a tech physically near the server, so even a simple serial console is easily plugged in. Or how will that new NIC work with the whole network, like any basic networking setup or firewall won't allow traffic from arbitrary MACs, so normally this needs to be coordinated already anyway in an enterprise setting, e.g. through a change management process.
And why would one optimize the whole design for network naming for the edge case and not the much more common one like simple software updates.
And the design is not even being able to guarantee it for the edge case. Plugin that NIC in a different PCI slot, or let the firmware to a blip and report it differently–all things that happened!–and you still got no network with net naming scheme. Worse, you reboot after a systemd update, and you can have no network either. Or the kernel learns that your NIC supports virtual functions, guess what, no network because the (seemingly just-in-time) predictable naming scheme now sees that information changing its previous prediction.
I never will be able to understand how one can argue for breaking the common use case, nobody argues that there isn't a real problem or that there is the One True Way™ to solve it (at least I do not intend so), but arguing for using a certainly not ideal default that optimized for an edge case feels a bit like some sunk cost fallacy to me.
Sorry for my wall of text, I would really like to care less, but at $work I am exposed to this mess directly, not only for our infra but for all users of our projects, can all be done and managed, sure, but the churn and hours I have to put in thanks to this feels unnecessary and could be used for much more useful things.
Note that I'm neither a "sales people", nor is the one that made the original post, as that is Olaf from the Perl foundation, who reached out to me after I made a contribution to one of his Perl projects, if you must know. Tbh. I didn't even know that he would post this on some channels like here or reddit before getting pinged by a colleague that we were mentioned on the front page of HN. And for a fact, I actually know (and enjoy!) several people from the QEMU and libvirt developer community actively posting on other sites comment sections, or is that now a bad thing too?
And FWIW, I tried several times to point out that QEMU itself is only a small part of what we provide–even if not, just providing a good API abstraction around that is significant work, especially if it should allow two decades (and counting!) of stable upgrade paths and _without_ libvirt. And we nowhere hide the underlying technologies, we're proudly building upon–and trying to give back–to all projects we use, be it Debian, QEMU/KVM, LXC (which we co-maintain), Linux kernel, FRR, rust, or–like here–Perl...
But as you're rather dismissive and now even start to call people trolling I hardly see any need to take your writings as serious discussion, they do not seem to be done in good faith, and IMO doing it this way certainly won't help to promote FLOSS, that should be possible without being dismissive to others work.
As long as you only got NICs with different permanent MAC addresses installed that does not matter for getting actually long-term stable names.
And for the other case you can still fallback to the other policies, it still will be much more stable by default.
Please note that I don't say that MAC is perfect, but using something that is actually tied to a NIC itself would fare much better by default compared to the NICs position as determined by a bunch of volatile information, and what normally does not matter to me at all, as e.g., I will always use a 100G NIC as ceph private network while the 25G ones as public one, no matter where they are plugged in. That someone configures something by location is the excpection, not the norm.
Yeah, the permanent MAC address (i.e., the one the card actually reports to the system not the one dynamic one it can use) would be the safest bet, as that is the most stable thing there is, and more importantly, it is very relevant for switches and firewalls in enterprise settings, so if it changes it's often likely that network access will be broken any way, so one basically can only win with using the MAC as main identifier IMO, at least compared to the current status quo.
Scam is probably the wrong word, and it's choice might be a bit feeling fueled, but it's really not true that this only depends on the HW.
systemd also changes behavior in what naming policies are the default and what it considered as input, it did that since ever but started to version that since v238 [0]. Due to that the HW can stay exactly the same but names still change. I see this in VMs that stay exactly the same, no software update, not change in how the QEMU cli gets generated, really nothing changed from the outside virtual HW POV, interface name still changes.
The underlying problem was a real one, the solution seems like a bit of a sunken cost fallacy, and it added more problem dimensions than there previously exist.
Besides, even if the HW would change, shouldn't a _predicatble_ naming scheme be robust to not care about that as long as the same NIC is still plugged in somewhere?
Disclaimer, as stated elsewhere: I really like systemd, I'm not one that speaks out against it lightly, but the IF naming is not something they got right, but rather made worse for the default case. Being able to easily pin interface names through .link files is great, but requiring users to do that or have no network after an upgrade, especially for simple one-NIC use cases in a completely controlled environment like a VM is just bonkers.
[0] https://www.freedesktop.org/software/systemd/man/latest/syst...
Kill? no, definitively not. But 1) not adding a lot of extra and 2) applying the Pareto principle here are a huge difference. I.e. making the essential parts approachable enough to get one started while not being blocked too much by upfront (steep) learning curve, while not blocking one later by limiting one to just the predefined path.
Anything touching SDN or clustered storage, in any ecosystem, will need dedicated in-house experts that know networking, storage, Linux and how Proxmox (or Kubernetes) approaches those domains.
There are widely different level of expertise needed though, and the setups that often are managed by admins with not in-depth expertise in clustering or SDN can still get things done with Proxmox VE, and if they are out of idea we got our enterprise support and naturally also the very active and friendly community forum to help.
Unless you are just using Proxmox for small VM labs, in which case it ought to be compared with libvirt and standalone QEMU.
Yeah, I really do not get that point, you basically invalidate 95% of Proxmox VE's feature set because it might not be fully leveraged by a specific user group and because there are some different solutions that also allow one to do similar things. That would also invalidate Kubernetes, it's not completely unpopular in small labs either after all.
To be honest, to me, it feels a bit to me like a justification attempt for the initial post in this chain here that brushed off Proxmox VE as just some small UI/UX wrapper around QEMU/KVM and all the Real Work™ being done by others, possibly because you never actually used it, but I might read it the wrong way, and I'm certainly not offended in any way, just find it a bit odd.