Kwozyman
I’m assuming you’re running a Linux hypervisor with kvm and just the vm is Apple.
I can’t attest to the performance of the GPU, but you will encounter a different problem – the “AMD reset bug”. You will not be able to reboot the VM without rebooting the host as the GPU doesn’t know how to properly reset itself and will go in a unrecoverable state upon VM reboot. There is a kernel module called vendor-reset that mostly fixes the issue, but I’m not 100% sure it still works on newer kernels (it also contains a much better explanation of the issue and has a table with the affected hardware).
tl;dr If you’re buying a new board, I would avoid this specific model.
Would Microsoft say…it just works? :D
I don’t think Arch (or any rolling distro for that matter) is the best solution for a server deployment. If you update rarely, you’re bound to have to do manual interventions to fix the update. If you update too often, you might hit some distro breaking bug and you’re rebooting very often as well. Those two options are not great on something requiring stability.
For all my non-compliant, non-supported hosts I started using Fedora CoreOS quite successfully.
If you package your applications as containers, you should have a very easy time with it. It’s based off ostree, which means a couple of things:
- immutable (so not easy to break, I guess?)
- atomic upgrades, which means you upgrade in a single step
- atomic and full rollbacks, which means if an upgrade breaks your host, you can rollback to the exact previous version booted simply by choosing it from grub
- still based on rpm, so you will still have a grasp of it, even though many things are completely different
- other benefits I forgot, I’m sure :)
All with the added benefit that once you go towards containers you can change your distro with minimal effort, so there’s that.
I’ve been using the same Silverblue installation for about two years (maybe even more than that). Initially, I did a lot of tweaking because I didn’t really know how to approach toolbox and flatpaks, especially because I don’t use Gnome as my desktop environment, so this system went from standard Silverblue to Silverblue+i3 overlayed, then to Silverblue+sway overlayed, recently it got rebased to Sericea and it’s still running like day one. It also got upgraded from version 35(-ish) to 38 still without any issues (well, I did have some issues, but I simply rolled back and that fixed it).
I’m also deploying several Fedora CoreOS servers with a similar level of success, but those mainly tend to just run some containers, so I would say I mess way less with those, it’s been mostly just update/upgrade to the latest, check if podman is still running my containers and let them be.
Well, Red Hat doesn’t really get paid (of course, I’m not arguing RH is not making or doesn’t have enough money) – they would get payed for one or a very small number of licenses. At the same time, Rocky (and Alma and more importantly Oracle) wants to actually sell (albeit only support) the same product put together by Red Hat so it’s not really a community RHEL clone. I think that’s the real issue here. I wouldn’t have a problem with this workaround if it were coming from the community, without the commercial asterisk attached.
I don’t think Red Hat is violating GPL. For sure it’s not violating the legal terms of it (I’m fairly certain the army of lawyers RH and IBM have at their beck and call made sure of that) and I don’t think it’s violating it’s spirit (at least not yet) – they are still contributing any changes and their customers still get access to the source code. And (for now!) it doesn’t even seem they are making it super difficult to do so either. The way I see it, RH wants to be the only game in town providing service contracts for their own product which is fair game, imho. The problem with Rocky is that they also stand to make money out of the same source code which is the disingenuous part, in my opinion.
I honestly don’t know why Rocky made this announcement, even if their intentions are noble, they do come out as the bad guys in all this mess. They could have simply put out some generic announcement that “we are working towards a legal way” and kept doing what they are doing.
And to be clear: I believe the true people that stand to lose in this are the users and the community. I’ve been a user of CentOS (the old style, not this new breed of RHEL beta) for a long time and even an occasional Rocky user in recent times, but that will have to change.
Well, I don’t know how fair they play now, but for sure that wasn’t always the case.
In the FTPD logs, do you see the initrd file being pulled? Could it be a mismatch between the kernel and initrd you’re serving?
