Indeed, and that's a question that has bamboozled me for years.

As far as I can tell, Devuan 100% reactive, rather than proactive. Upstreams leaning on user-services has been a known problem for years, other distros have been developing solutions and exploring alternatives.
Devuan just waits. Waits to see what Debian does, waits to find out what the next Debian release breaks, waits to see what packages will be "banned" rather than fixed.

We could have openrc user-services, but we don't, "because Debian". Because this isn't really a distribution in it's own right, it's a Debian "respin" and 99.99% of packages are verbatim pulls from the Debian repos.
That's fine when you stick to the Debian way of doing things, but deviating on something as foundational as systemd and then refusing to deviate on potential fixes and replacements... Mark my words: when KDE depends on systemd, Devuan will just "ban" it, loose yet another major package, and slide further into irrelevance.

Pretty much every patch or alternative implementation that has found it's way into Devuan came from another distro (usually Gentoo, e.g. elogind, eudev, opentmpfiles), I'm probably missing some minor tweaks, but the fact I can't name a single significant systemd-free solution invented by this systemd-free distro is concerning to say the least.

Devuan isn't about finding alternatives to systemd, it's about clinging stubbornly to systems long abandoned by everyone else, then shouting at the weather like senile old fools when the rest of the world moves on. Compare the post-count for "here's a cool new feature in Devuan" to "bastards at $outgroup changed something again, the world is going to shit, bah humbug" and the direction is pretty clear - wilful fossilisation.

Yes, much. I got tired of the constant jank and driver-kernel incompatibilities. amdgpu just works, and it's included in the kernel.

Sure, when I have time. Mostly stuff a few years old though.

It's getting old now by "gamer" standards, but it's adequate so long as you don't want raytracing.

There is. The version of openrc in Devuan is, as usual, many versions behind.

I find the benefit you get from any given activity is usually proportional to the time and effort you put into it. Only you can define your comfortable compromise on that sliding-scale from "out of the box, no effort" to "full control, much work".

OTOH, once you do have things set up the way you want, day-to-day Gentoo is pretty much just Arch (or any other rolling-release distro), except updates take longer to install, your PC doubles as a space-heater, and the community is far less obnoxious.

I'd say "definitely is", and probably soon. IME KDE will do what they always do - death by a thousand bugs. Let [thing they want gone] rot until the userbase is sufficiently annoyed, then trot out a replacement that requires [thing they want to depend on] and use it as justification for never fixing what used to work...
Just like X11 support and the "x11-only never ever fix these, they're meant to be annoying" tag on the bugtracker.

SDDM has problems sure, but it certainly isn't beyond saving. KDE could have just adopted it as-is (and as initially implied) or pitched in with maintenance, but instead it's an excuse for yet another rewrite, to use systemd user-services for session management... Which will inevitably spread to KDE in general, as D.E. has been not-so-subtly hinting is "the best way forward" for a while now.

Same reason every new app for KDE that runs a background service (e.g. KRDP) and every new control-panel applet that touches services (e.g. plasma-firewall) also depends on systemd, usually for no convincing reason.
Several influential developers want to move all of KDE's various daemons and services to systemd user-units, so they can get rid of KDED & co. They have for quite some time.
The old "sure we support BSD, we've always supported BSD... You just miss out on some new stuff" pot of totally-not-boiling-yet water is the best way to make that happen with a minimum of screaming, so we get "stay calm, it's just an optional feature. SDDM will still work (for now)".

With any luck Gentoo will patch things to use openrc user services, or Sonic DE will gain the traction and the manpower to be an X11-first and systemd-optional KDE fork.
Both efforts would stand to benefit from some cross-distro support and packaging, but as far as Devuan goes who knows. As far as I can see we're still at "read forum, figure it out yourself" for pipewire, with nary a sign of an official proposition (let alone a solution) for user services more generally.

One example? Probably not, portage touches everything.
In general, you can enable or disable features or use software combinations that require setup at compile time. One can, for example, run a system without udev or dbus, or build the whole OS with clang instead of GCC, or use musl rather than glibc as the system C library, or build binaries that run only on $shiny-new-cpu using every possible optimisation.
Usually that kind of thing means a whole separate specialised distro, with Gentoo it's just user choice and some mucking about in config files.

Probably the most relevant (to devuan) example is systemd - there are many packages that require you to enable or disable systemd integration at compile time (or apply patches to remove it), so binary distros have to either choose one or the other for everyone (i.e. debian/devuan split), or maintain multiple versions of packages, complex dependency chains, or distribution "flavours" (which nobody can be bothered doing).

In Gentoo you just set a 'systemd' or 'openrc' system-wide USE flag (or better, select a profile that does that for you), and everything that can integrate with your chosen init will be built to do so, dependencies will be suggested to provide missing features, etc.
That's a big part of why Gentoo supports multiple init systems as "first-class citizens", and almost everything (including GNOME, for the most part) just works(tm).

Instead of "suggests", "recommends", zillions of split packages, and a bunch of removing optional junk after install, you set USE flags to define which features you want and the needed dependencies are pulled in to enable them.

Portage also makes patching software locally dead-easy. Instead of buggering about with quilt, debhelper, and doG knows what else to change and rebuild a package, you just drop your patch in /etc/portage/patches/[package name]/ and emerge applies it for you.

It offered better performance at the time, and ryzen had random motherboard/bios compatibility problems I didn't want to deal with.

It does, the installer is you.
More seriously, there are too many possible ways to build a gentoo system for an installer to be very useful, and it's not worth the development effort for something you probably only do once.

It's no worse than Archlinux, and plenty of people figure that out.

Devuan as a whole is largely fine, it's just the administration of this board.

Historically it was entirely source-based. Now there are binary packages available for common profiles, so if you don't customise your use flags (compile-time features etc.) you needn't compile anything.
Personally I think that kinda defeats the point... But then again the line is something like "here tools, do whatever you like", so I guess a binary Gentoo install is as reasonable as any other.

"Fast" is a matter of interpretation and patience. It tends to be a few packages (particularly web browsers) that take the the bulk of the time, if you use binary packages for those Gentoo is quite manageable even on fairly modest hardware. You can also use a build-host or distcc to offload work, e.g. have a fast desktop or server build updates for a slower laptop.

8 mechanical drives in the main raidz6 pool, plus 10 SSDs of various sizes in a couple of raid10 arrays. 64TB is really an approximation, it's considerably more than that in raw disk, and slightly less in "usable" space once you account for redundancy, overhead, and filesystem slop allowances.

Seagate ironwolf at the moment, but I've had WD drives in the past. That ZFS pool has been around a while now and I tend to replace drives gradually with whatever is the most reasonable price/capacity/reliability balance at the time, I consider researching specific models more relevant than brand-loyalty.

Lack of granular package management and dependency resolution. Packages are essentially just tarballs and as close to upstream as possible, it's up to the user to track dependencies or rebuild them if they want a different feature set (e.g. not all of KDE as one package). There are addons (e.g. slapt-get), but AFAIK the base distro is still that way to this day.
I am still "using" Slackware, in a manner of speaking... Slackware 7.0 on a "vintage" AMD K6-2 machine, much like I did back in '99 .

It's tangentially related to my job, but "hobby", if you call it that, came first. Really I just like to understand the things I use - that's as true for cars and dishwashers as it is for computers. If I can't take it apart and screw around with it, it's not worth having.

Well the gist does link directly to an "updated" version, with "thanks this works" posts as recent as 3 weeks ago...

https://packages.debian.org/sid/nvidia- … 0xx-driver
https://packages.debian.org/sid/nvidia- … gacy-340xx
Looks present and correct to me.

If you don't want to try, suit yourself.

   ..,,;;;::;,..
           `':ddd;:,.               ---------------
                 `'dPPd:,.          OS: Devuan GNU/Linux 6 (excalibur) x86_64
                     `:b$$b`.       Host: X9DRL-3F/iF 0123456789
                        'P$$$d`     Kernel: Linux 6.12.63+deb13-amd64
                         .$$$$$`    Uptime: 20 days, 23 hours, 31 mins
                         ;$$$$$P
                      .:P$$$$$$`    Packages: 1585 (dpkg)
                  .,:b$$$$$$$;'     Shell: bash 5.2.37
             .,:dP$$$$$$$$b:'       Terminal: /dev/pts/0
      .,:;db$$$$$$$$$$Pd'`
 ,db$$$$$$$$$$$$$$b:'`              CPU: 2 x Intel(R) Xeon(R) E5-2665 0 (32) @ 3.10 GHz
:$$$$$$$$$$$$b:'`                   GPU: Matrox Electronics Systems Ltd. MGA G200eW WPCM450
 `$$$$$bd:''`                       Memory: 29.90 GiB / 125.86 GiB (24%)
   `'''`

and

         -/oyddmdhs+:.                
     -odNMMMMMMMMNNmhy+-`              ---------------
   -yNMMMMMMMMMMMNNNmmdhy+-            OS: Gentoo Linux x86_64
 `omMMMMMMMMMMMMNmdmmmmddhhy/`         Kernel: Linux 6.12.63-gentoo-dist
 omMMMMMMMMMMMNhhyyyohmdddhhhdo`       Uptime: 1 day, 7 hours, 1 min
.ydMMMMMMMMMMdhs++so/smdddhhhhdm+`
 oyhdmNMMMMMMMNdyooydmddddhhhhyhNd.    Packages: 2145 (emerge)
  :oyhhdNNMMMMMMMNNNmmdddhhhhhyymMh    Shell: bash 5.3.9
    .:+sydNMMMMMNNNmmmdddhhhhhhmMmy    Display (CB272): 1920x1080 in 27", 75 Hz [External]
       /mMMMMMMNNNmmmdddhhhhhmMNhs:    Terminal: konsole 25.8.3
    `oNMMMMMMMNNNmmmddddhhdmMNhs+`
  `sNMMMMMMMMNNNmmmdddddmNMmhs/.       CPU: Intel(R) Core(TM) i9-10900KF (20) @ 5.30 GHz
 /NMMMMMMMMNNNNmmmdddmNMNdso:`         GPU: AMD Radeon RX 6700 XT [Discrete]
+MMMMMMMNNNNNmmmmdmNMNdso/-            Memory: 17.96 GiB / 62.68 GiB (29%)
yMMNNNNNNNmmmmmNNMmhs+/-`
/hMMNNNNNNNNMNdhs++/-`                                         
`/ohdmmddhys+++/:.`                                            
  `-//////:--.

I'm pretty sure there's also a laptop around here somewhere, but we don't talk about that.

...

(ref)
Rich innit, having a go at the author of a derivative distro and several utilities for their perceived lack of code contributions, while loudly proclaiming "I can't code".

As usual go, all you are "contributing" here is a bunch of crotchety barely-coherent bitching on the "state of humanity", irrelevant "in my day" rambling, and tired reruns of the same "somebody do the things I can't/won't" comments you seem to love dropping every time anyone dares make an even slightly productive suggestion.

On the OP: I don't disagree with the concept, but I'm not convinced making it "official" is a good idea.
As is painfully apparent in other threads here, the people wanting shiny-new software are often the same who never read the instructions... A user-curated build script repository will inevitably contain horribly broken junk, and "official" endorsement of that kind of thing will reflect negatively on Devuan as a whole, as well as likely clogging both the bugtracker and the forum with inactionable problem reports.
Put all the disclaimers you like on the thing, if it's on a devuan domain people will assume it's subject to devuan quality control and devuan support.

Yeah, that'll be Slackware. Prior to the more modern "S" logo it was either Bob Dobbs or Tux smoking a pipe, both are still considered "mascots".

Slackware is still alive and well, making it the oldest surviving major distro. It also hasn't changed very much since I first installed it some 25+ years ago, which is either its biggest strength or its biggest weakness, depending on who you ask.

TBH I'm kinda surprised a Devuan user isn't at least passingly familiar with Slackware, it's the OG old-school init holdout (BSD init) and one of the only two "big" distros (the other being the somewhat younger Gentoo) that didn't go all-in on systemd.

Devuan didn't write, implement, or encourage the use of that "tool". Here is the wiki page on setting the time in Debian (which also applies to Devuan, sans the systemd section). Notice there is no mention at all of any GUI.

You are the one insisting on using gnome-system-tool or whatever it is, nobody else.
Also, we don't. There are a multitude of Debian and Devuan systems that run just fine with no GUI at all.

s/casual users/people who refuse to read the documentation/g
FTFY.

By reading the documentation, instead of "working at Windows"

OP has a long history of running unstable (or better yet, mixing) releases, then complaining that "Devuan" is broken and things don't work "out of the box" when the inevitable bugs arise. Apparently "unstable is for testers and bug hunters" is also in documentation they refuse to read.

We used to have a whole thread for people to contribute to the community by serving as a warning to others over on FDN, before the big DEI takeover...