Hate to break it to you, but both eudev and elogind are systemd, or at least "liberated" parts of it. What both those (Gentoo, hence the "e") projects do is split out systemd components that we want into standalone packages.

Sure, for some definition of "functioning".

AFAIK X only needs [e]udev for video and input device permissions, you could set those up manually (and fool apt with equivs)...

[e]udev doesn't create the devtmpfs at /dev, the kernel does. What udev does do is handle dynamic creation of nodes there for device hotplug.

Way back when, /dev was a static directory and we made device nodes by hand when we installed new hardware (also automatic module loading when the corresponding node was accessed).
Then came devfs, where /dev was a virtual filesystem managed by the kernel and you mostly didn't need to think about mknod (unless you were fancy and had USB).
Finally udev (now absorbed into systemd) was created to deal with all the newfangled hotplug stuff, so now nobody even knows what it is they just plugged in or what driver it uses .

I know of people running Gentoo and Slackware systems with static /dev, but how well that works for Devuan is a good question. I see no reason it shouldn't, but you will obviously give up (most) hotplug functionality and anything else in the udev rules.

TPM functionality isn't necessarily anti-freedom in itself, but it does provide some fairly obvious mechanisms for abuse... Personally I am almost as sceptical of Canonical's motives as I am of IBM/Redhat, and I suspect this will be yet another attempt to get a foot in the door in for something more unpleasant in the future.

IOW, same shit, different day. Same sub-optimal solutions.
The general public doesn't think enough to see through the "for your safety" bullshit or care enough to resist, and the legislators are either completely tech-illiterate or bought-and-paid-for.
So aside from (futile IME) "education", the only real answer is the same as it has always been: Reject these technologies, wear the "less safe convenient" hair-shirt, and when things get really screwed up - help build something that is less so.

Also, like, give the FSF and DBD some money or something. You get fun badges and stuff.

Your input website is without value visitors unless you can provide an alternative solution.

FTFY.

@Xe Fixed my arse. What you mean is "Found a slightly different way to break the web".
Actually "fixed" would be "gone".

I am still not going anywhere near any site that intentionally wastes my CPU cycles, particularly when it does so with a bunch of javascript it would otherwise not need at all.

Further, to exhume a nugget from the '90s I thought we all grasped by now:
"Stop obsessing over user-agents" (because now you've created #269).

To pull some more gems from your own bugtracker:
"Congratulations, you just broke the web"
"this is a problem for this entire class of software"
"we only support IE6" and "we've known that's bad practice for 25+ years"

Your answer to #269:
"Anubis is going to implement TLS fingerprinting support and that discrepancy between a Windows user agent with a Linux TLS fingerprint will be caught as suspect instantly."
Will break sites for anyone running a privacy-centric browser or extension that always supplies a windows UA regardless of platform, something several currently do.

Go away. Stop breaking sites for non-mainstream browsers and people with user-agent switchers or anti-fingerprinting extensions. User-agent is an advisory header only, and the user can set it however they wish. (ab)using it the way you are is broken design.

You've already (disingenuously) removed mention of "proof of work" because you know people hate it, now you're going to draw the ire of anyone  who has a problem with browser fingerprinting (ya know, that thing every asshat corporation does to track you) in general.

Uhh, congratulations on all the new enemies I guess?

Carrier branded phones might well have a locked bootloader as well (it's an option a carrier can request from the OEM), but IME that level of dickery is mostly a 'murican thing. Down here carrier locks of any kind are a rarity (outside of hire-purchase type arrangements), as is carrier branding in general... because we still have consumer-protection laws 'n stuff.

Personally I just refuse to deal with any provider that doesn't allow BYOD, and refuse to buy any device that's locked to a specific provider.
That usually means purchasing the hardware up-front at full price (or the used market, which I am a big proponent of in general), as opposed to the whole "sign up and get $phone on discount / glorified hire" thing. I'll gladly do that if it means I actually get to own my stuff. Matter of fact, everything I own I actually own, as a matter of principle.

My current phone came from England via ebay, and I did my own research on radio frequencies, carrier compatibility, lock status, parts availablilty and third-party OS support.
It was certainly more work than "sign up with $provider, get phone, use phone", but OTOH this one is mine, and I get to do whatever I want with it, for as long as I want (or at least until the next ridiculous [X]G hype-wave).

Or, to put it another another way...

"I like offending people, because I think people who get offended should be offended."
        — Linus Torvalds, 2012

That is was easily fixed by flashing an AOSP-based bloatware (and touchwiz) free ROM, of which there are were many. These days that's a non-starter, as most modern samsung phones use their in-house (exynos) SOC, and that requires unobtainable proprietary modem firmware for VoLTE and 5G support.
You can still root and debloat the stock ROM, and that's still a serious improvement, but AOSP builds are kinda dead until someone reverse engineers the modem.

If you want a reasonably priced bootloader-unlockable phone that ships (mostly) bloat-free OOTB and works well with third-party AOSP builds, I suggest Motorola. They're also not bad to work on, for when you inevitably smash the LCD or need to replace a port.
Google works too of course, and third-party ROM support is probably the best of all... It's just the price that stings. I really don't need a high-end device, and I have no interest in "premium" features or 50 cameras.

It's just the bloatware and custom UI really, and that can mostly be fixed if you're willing to root it (and trip knox). Hardware and build-quality wise, Samsung are pretty good.
It could be worse... Most cheap Chinese brands are bootloader-locked and unrootable, and some even ship literal malware in the stock OS.

Dude, seriously, just a plain-old USB cable. The kind that comes in the box with pretty much every tech gadget and multiplies in everyone's desk drawers.
So long as it has appropriate plugs for the things you want to connect it to (likely USB-A[male] -> USB-C[male]) and all the wires (i.e. not a "charging only" cable, if those even still exist), it'll be fine.

Well, you're not raging at the sky or slandering anyone in this thread. vOv

Hmm... One finger is very rude, two fingers is "I can still shoot you", three fingers is... More fun?

Close... While those do often require 3 fingers... they're not "gestures".

Methinks OP is referring to those newfangled things you drag your phalanges around on smear grease all over. Sometimes they're part of the display so the grease blurs your terminal and you scratch the tube trying to wipe it off, but more often they're in the palmrest of a luggable so as to catch coffee and be as irritating as possible while you're trying to type.
Horrid idea all around if you ask me, but that's what the kids are into these days.

@OP: I have no idea, I hate trackpads with a passion. Best try it and find out, push-comes-to-shove just use touchegg or similar (which I expect you will need to build yourself) to convert hand-waving into proper keybinds. That should work with any DE or WM, and any action you can bind keys to (provided libinput supports multi-touch for your hardware to begin with).

As for X on laptops, sure... A thinkpad with real mouse buttons and a nipple nub whatever the red rubber thing is that makes it so I don't have to take my fingers off the keyboard to move the cursor around.

Why thank you, the donkey is a noble creature, hard-working and uncomplaining.
As for your respect... vOv? Do I sound like I care?

Sure reads like one, and I was gunna say it... But benefit of the doubt and all that. They could also just be a noob, copy-pasting the usual outdated blog-post garbage.

Then again, the Large-Regurgitation-Model hypothesis would neatly explain things like missing the "No longer maintained for kernel > 6.0.0" bit (it's an image, not plaintext), and the inane "Okay, great!  Thanks for next step!" reply (while clearly not understanding the advice)...

You haven't compiled the replacement driver successfully yet, so blacklisting the in-kernel one is completely irrelevant at this point.

Without addressing (or even reading it seems) what I posted above, so...

Of course they do.

I just told you what the compiler errors mean, a search engine won't tell you anything different - even of it has indexed that exact line, which it probably hasn't.

Nor will an Artificial Idiot.

Already provided: Get a driver that is maintained and compatible with your kernel version... Or learn enough C and kernel programming to find and fix all the deprecated function calls in the broken one you seem determined to use.
One of these is easy, the other is hard. Your choice.

Uhh, whut? Why would that matter, it's a configuration file for modprobe. Try 'man modprobe' and 'man modprobe.d' instead of flailing randomly.

If you read the README in that github repo and followed the link, I expect you would have resolved this already by yourself.
The maintained driver repo even includes DKMS packaging instructions, which I suggest you follow so you get a .deb package and automatic rebuilds on kernel changes.

Autoconf 'configure' scripts are stored in the source directory, but 'make' is a binary in system path. So './configure [--option]' and 'make [target]'.
In this case however...

The source in question does some (sort of) autoconf from the makefile (and a bunch of other crazy besides), there is no configure script.

They did. Read the makefile.

Debian instructions wrt porting packages also apply to devuan, e.g. https://wiki.debian.org/CreatePackageFromPPA