To be fair you shouldn't have to, something must be going wrong in the byzantine mess that is oracles init script...
The init script that I didn't see on cursory examination of the package because it's copied from /usr/lib/virtualbox by the byzantine postinst-common script, which is in turn called from another postinst script...
The init script that takes 20KB of shell to load 3 frickin modules, and clearly doesn't manage to do it reliably.
Sheesh, commercial vendors and their overengineering.

You could try debugging it, or you could just stick with those 3 lines in /etc/modules... I know which one I'd choose.

VirtualBox was in the repos back then (It was dropped for buster due to oracle being "uncooperative" IIRC), so presumably you were using those packages rather than the ones from oracle, no?

Well that all looks fine. Rats.

Does the root account actually have a password?

Fortunately almost every GUI today (with the notable exception of anything related to GNOME) works just fine with plain ALSA... So long as you don't compile it against pulseaudio, which unfortunately Devuan has, and it doesn't assume pulseaudio is available because libpulse0 was installed, which unfortunately Devuan does.

I'm going to go with "not".

Pretty much every sound-related application in the repos which can be linked to pulseaudio has been...

Because apparently upstream Debian just loves needless bloat these days, and dubious "features" like lobotomising your ability to configure your system properly by burying everything behind a GUI and a wall of XML or JSON (then adding a daemon or two and a dbus interface for good measure) is progress.

This is one of the reasons I'm not running Devuan (or any "modern" binary distro for that matter) on my desktops.
A minimal server install is still quite feasible, but as soon as you want a usable web browser or a DE, the tendency for distro maintainers to compile in everything including the kitchen sink bites you in the ass.

Devuan:
apt install <pretty much anything>
...
I see you're installing $software, would you like bloat with that? Too bad, we compiled everything we could find with '--install-lennart --enable-bloat --enforce-more-latency --everyone-uses-laptops --bug-policy=redhat'
The following 900 packages you don't need or want will be installed...

Gentoo:
USE="-pulseaudio alsa" emerge --newuse @world && emerge --depclean
...
Bask in the complete and satisfying eradication of libpulse, Firefox without nasty LD_PRELOAD hacks, XFCE with full ALSA support, etc. etc.

We certainly won't if your only interaction with this community is to drop in and say "Devuan is too hard, I'm going to use Mint."

Feel free to use whatever distro you want. If no-reading one-click installs are your thing, Devuan probably isn't for you.

If you have questions about Devuan, we're happy to provide answers.
If you have a problem to solve, we'll probably enjoy helping you.
If you have constructive ideas on how to make Devuan better (ideally with some code to share), we'll gladly discuss them.

If you're just here to (passive aggressively) complain and make pointless comparisons to $newb_friendly_distro though, I'm pretty sure this conversation is over.

What is with all the noise about this "brave" browser recently anyway? Is it demonstrably better than Firefox/Iceweasel or a degoogled chromium build?
Personally I'd be highly suspicious of a new browser that is advertised as heavily as this one appears to be...

Ed. Yup, that's pretty much what I expected. "Have our ads and tracking instead of theirs". Free cryptocurrency woo and virtue signalling included.
No thanks, I'll stick to my adblockers and javascript defangers.

Gentoo

Yeah, that'll take a while.
Dunno if a modern kernel would build on that, it has grown some. Guess I try it next time I have a free week to watch paint dry...

I think you mean 8MB, LOL. My 386 had 4, and it sure couldn't run Doom. 16MHz CPU, hercules monochrome graphics, and a spacious 80MB HDD.
Another dumpster special, and the first PC I could call "mine".

I still play (GZ)Doom from time to time, and it's still awesome. Fairly sure I have enough WADs to last me until the heat death of the universe too:

~ $ du -ch `find Games/Doom/Mods -iname '*.wad'` | tail -1
3.4G    total

Aside, I highly recommend timidity++ & the soundfonts from arachnosoft for full appreciation of Dooms epic soundtrack.

Because at the time (~2000 - 2003), a hopped-up 486 (120Mhz CPU, unofficial 40MHz bus, 2(!) VLB cards, 32MB RAM) junk-bin special was all I had.

The more recent install was simply a case of finding I still had enough old parts to assemble a retro box, and doing so for the hell of it.
IBM branded SFF 486 desktop, circa 1994. All the right bits, and worth a surprising amount nowadays as they're starting to become "vintage". Runs a stripped-down Gentoo, dual booting PC-DOS for DooM and Duke Nukem.
Ed. One of these. Top spec 100MHz model.

Plenty. The pentium brought many new instructions, as well as widespread PCI bus support.
Multimedia was especially painful on 486-class boxes, if you wanted to play MP3s at realtime you pretty much had to compile mpg123 with special optimisations. MMX changed all that.

Unless you're talking about really specialised embedded boards, there's no reason to use a 486 for anything but a nostalgia trip. i586 is better in every way... Well, except for that embarrasing FPU bug in the early pentium chips of course.

Most late-model 486 boards supported 64MB, but finding compatible SIMMs wasn't particularly easy. 32MB was a lot more common.
I believe there were some server boards that supported 128MB, but I've never actually seen one.

16MB was considered a standard desktop for most of the era, and if you had more than that you usually had to map an address-space hole for the video memory... So although mine had 32MB installed, I could only use 30MB due to my 2MB graphics card. Had to bugger about with kernel patches to get that working too IIRC.

Indeed. Shame beowulf hasn't actually been released yet.

Until informed to the contrary by a developer, maintainer, or long, long-awaited release announcement, I'm going to assume that the Devuan "testing" repository is still in testing, and has the same purpose and meaning as the Debian "testing" branch.
As such I'll not recommend it to anyone, unless they first communicate a desire to use an unstable, unreleased, non-production-ready branch.

The PHP version in Devuan stable is far too old for a great many purposes. So yes, as of right now there is a need for third-party repositories on Devuan. There has been for about a year now.

Gentoo is a fantastic desktop / workstation / dev box, and it's probably the most flexible GNU/Linux distro ever devised. I wouldn't run it on a server or muggle-kiosk though, it's too needy WRT frequent updates and user-intervention.

Arch is a lot like gentoo in those regards, but without all the customisation that makes Gentoo Gentoo. Unstable, a PITA to update if you don't do it often enough, and additionally I found that it sometimes suffers from binary linking issues if your update server goes out of sync... But it does have much Shiny New Shit and the AUR user-provided packages if that's what you're into.

As far as I can see: The point of Archlinux is bleeding-edge software. The point of Gentoo is customisation.

That was the conclusion I came to when looking for a systemd-free server OS. My standards for such are quite exacting, and revolve around it being well-supported, low-maintenance and receiving regular security patches.
There were very few distros that fit the bill before the systemd invasion (i.e. pretty much Debian or RedHat), and there are fewer still now.

I always thought of Antix as a livecd distro, so I've not considered it.

*Gentooer since 2002*

Sabayon & Redcore spring to mind. Both are Gentoo derivs with optional binary repos.

Sabayon uses it's own package manager (entropy) for binary packages, alongside portage for source installs.

Because why would you? Building packages from source is the entire point of Gentoo, and all the magic happens in portage.
Gentoo source repos are generally just clones of upstream, it's portage that does the patching required to make them "gentoo sources" at build/install-time. The only real exceptions are where gentoo _is_ upstream, e.g. eudev. How/why would you use apt instead?

Again, why?
Portage is gentoo, gentoo is portage. Slackware is stoatally different.
If you want slackware with apt-like package management, slapt-get is a thing. I don't see how throwing portage and/or gentoo patches into the pot as well would make anything easier... More likely it'd make it quite the opposite.

Not as far as I am aware, and if you're talking binary packages it'd be effectively impossible due to every user setting their own USE flags and compiler options - everyone's binaries therefore being incompatible.
Not using your own USE flags / compile-time options defeats the point of Gentoo.

It's not particularly difficult to implement this yourself locally, but a centralised setup really only works for a binary-only distro.

sed 's/cool/non-trivial/g'
The things that make all those distros unique are also things that make mixing them pretty impractical IMO.

I've used Gentoo, Slackware, Debian and Arch extensively (Gentoo & Devuan right now, Slackware was my first GNU/Linux but package management is still a PITA), and they're completely different animals. I don't see anything to be gained from trying to mix them except a bunch of wheel-reinventing.