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 [email protected], 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.
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.
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.
Yes, such things are nice. The well-known URI [0] system is also sometimes used for this, at least there's one entry for Thunderbird under the "autoconfig/mail" subdirectory. Having some of those auto-config methods available for git send-mail could be nice, as it would lower the barrier a bit further, even if most devs are probably able to check their SMTP endpoint and port.
Oh, sorry, you actually need to figure out the maintainers, so you can send it directly to them too to get it reviewed faster, so yeah a call to `./scripts/get_maintainer.pl -f <files>` ok, now it got impossible for the modern dev – cannot expect those are able to actually understand basic systems.
Then reply to the review replies you get, if there's still anything to change, how would gerrit making that easier in any way?
Home is a little farm in the steep slopes of the Alps in South Tyrol.
https://thomas.lamprecht.org/