Thank you all for your responses. On Monday, 24 August 2020 13:02:56 BST Rich Freeman wrote: > On Mon, Aug 24, 2020 at 6:57 AM Neil Bothwick <n...@digimed.co.uk> wrote: > > On Mon, 24 Aug 2020 11:50:42 +0100, Michael wrote:
> > > I have a number of VBox VM systems, some with active software licenses > > > running on them and the VBox-bin is a low-maintenance and convenient > > > way to run them. I'd prefer to avoid emerging a non-bin VBox. Is there > > > some way I could keep older packages running in Gentoo, until more up > > > to date versions appear again in the tree (if ever)? > > > > Copy the ebuild to a local overlay and add app-emulation/virtualbox-bin > > to /etc/portage/profile/package.unmask. > > You would probably also want to grab a copy of all the distfiles and > keep them safe, because they'll disappear from the mirrors. > > Note that this is really only a stopgap. As packages that require > python 2.7 are removed from the repo, we may see more and more core > python packages removed as well over a longer timeframe. It will > probably become increasingly less practical to continue to use python > 2.7 as a result. > > You could in theory move all of this stuff into an overlay. As such > they will probably work "forever," but you will end up shouldering all > the work around maintaining security, compatibility, etc. I'm pressed for time presently and adding to my list of maintenance liabilities is the very thing I'm trying to avoid. ;-) > I would encourage using this as an opportunity to transition to something > else. Yes, good point. My workaround has been to look for MSWindows versions of any needed/desired applications and run these in a VM, or keep a couple of older binary distros in QEMU images. The VBox-bin was my preferred option for production PCs, because it required a short emerge time (VBox-bin plus VBox- modules) and little disk space taken up. > On a side note, I've used VirtualBox in the past, and it is pretty > simple to use. However, you might find KMS a much better solution > all-around. Virt-manager is a package that wraps a nice GUI around > it, and it isn't too different from Virtualbox. It is a little more > complex in that it is more layered - you could stick your VMs on Ceph > block storage or iSCSI or whatever, or build your VMs with > virt-manager and run them from virsh from the command line. One key > feature is that the kernel layer of it is built into the upstream > kernel and it is 100% FOSS, so you have a VERY robust level of > support. The complexity comes from the fact that > kernel/userspace/UI/etc is all separated into different packages, but > emerge virt-manager should give you everything (you might need to > enable KMS in your kernel as well, and maybe set up networking). I may give virt-manager a spin, because the users will require a GUI manager to launch VMs, but then if I start emerging packages at large I could emerge VBox from source instead. On my personal machine I just run QEMU, but I find plugin/unplugin USBs and other hardware via the QEMU monitor console to be rather clunky. I've stayed with QEMU over the years as a more minimalist solution. I preferred it as a more direct and simple solution to multiple virt layers, APIs and what not. > I'll also note that 95% of the time when you're using a VM running > Linux you're probably better-off using a container. I use QEMU to run full virtual OSs - MSWindows, Android, other Linux distros. A container wouldn't do this - but I have been thinking of deploying container(s) to sandbox/isolate specific desktop applications like e.g. Skype. It's just that I haven't yet invested the time to learn and try LXC/LXD/ namespaces and a plethora of management apps and frameworks for them.
signature.asc
Description: This is a digitally signed message part.
