I'm thinking it may actually be OpenRC, but to the point the setup depends on udev to work...

The code behind network setup is such a mess, requiring numerous scripts (in order):
/usr/lib/udev/rules.d/90-network.rules
/usr/lib/udev/net.sh
/etc/init.d/net.lo
/usr/lib/openrc/sh/functions.sh
/usr/lib/netifrc/sh/functions.sh
/usr/lib/artix/functions.sh

I still haven't worked through everything yet, but this is ridiculous

Whoever wrote this certainly didn't want people figuring out how networking works, or there wouldn't be so much bloat (needless code)

It's as if they think obscurity is somehow security, which seems to be a common trend I see amongst coders in many various languages...

Despite the fact so many security experts repeatedly say otherwise, but this is Linux, nobody listens to experts

EDIT: Ok so it's verified to not be OpenRC at all, at least not through shell scripts anyways...

I've grep-searched my entire /usr/lib/* folder for anything containing "\beth", and the only thing even remotely close (outside of commentary) to something capable of configuring "eth0" was openrc/console/keymap, which obviously wouldn't do anything like that XD

I also grep-searched /etc/* as well, which also was all commentary

So unless udev actually provides the "eth0" name for the scripts to configure, I can't see anything that would configure them otherwise...

There's just too much code I don't have the mental capacity to follow, if anything outside of udev configures this...

Localized code blocks just in case the link goes down (I'm tired of finding info that goes nowhere, so best not to add to that 10 years later)

Kernel modules required (compacted from the page):

    input.o - Input core (main driver)
    mousedev.o - If you need mouse support
    keybdev.o - If you need keyboard support (most likely you do)
    usbcore.o - For USB to work
    usb-[uoe]hci.o - USB host controller (either one: UHCI, OHCI, or the newest EHCI)
    hid.o - The HID driver handles all HID devices

    evdev.o - Needed for HIDNode driver to work

Standard devfs files those modules should provide:

    cd /dev
    mkdir input
    mknod input/mice c 13 63 # this is for USB mouse, if you own one

    mknod input/mouse0 c 13 32 # those are for applications that require
    mknod input/mouse1 c 13 33 # PS/2 - style mouse device
    mknod input/mouse2 c 13 34
    mknod input/mouse3 c 13 35 
    ...
    mknod input/mouse30 c 13 62 

    mknod input/event0 c 13 64 # this is for event devices required by HIDNode
    mknod input/event1 c 13 65 
    mknod input/event2 c 13 66
    mknod input/event3 c 13 67

I'll have to play around with these and make sure Xorg finds my mouse, next time I'm able to reboot

Disclaimer: This thread may occasionally go off topic due to the vast amount of coverage with the sheer knowledge involved with a project like this, and this post may also change (for the better) since I'm just bad at writing.

Future: I do intend to cover the history and motivations behind my decisions that lead me down such a painful path, but that's it's own can of worms regarding how much Linux has further devolved into a cloud-focused insecure monolithic abomination that's done nothing but abuse me since I started using it in 2012 after my primary WinXP (an OS which I still use to date) install corrupted itself

My personal goal is to have minimal static device configurations within initrd for setting up what udev would otherwise detect and configure, which from what I need really only needs to mount the mouse and network devices (if that) to a common location, as anything else I can mount after login...
(Ultimately I intend to remove my init system (OpenRC) entirely to have nothing at all running as root, but that's a goal for potentially another thread if Hyperbola is interested in providing similar options)

My current solutions to many various issues with this approach is simply just configuration scripts run from a custom user-level service daemon after login... (Although I AM building software to ease the tediousness of everything)
If anything needs root, I'm prompted with a terminal window to grant root to... (at least I know for certain what's running as root and when, unlike with OpenRC which does a ton of stuff behind the scenes you'll only know about via reverse-engineering)
One such example is a custom memory manager that properly clears swap and caches [echo 3 > /proc/sys/vm/drop_caches] to avoid Linux becoming sluggish when disk-cache would fill up the remaining unused RAM...
(I used to clear it every 10 seconds which worked quite nicely, but Wine would have problems finding my nvidia GPU (yet another thing to fix), so I reduced it to every minute as a workaround, which causes tolerable instability)

But regardless, that's getting off topic...

The first major hurdle to removing udev was Xorg and libinput, which was, despite the tediousness, actually quite easy to do...
All you need to do for xorg is remove the extension modules for libinput and libevdev, but additionally ensure you have the extension modules installed for the mouse and keyboard directly
The rest is just ensuring those devices are configured in Xorg.conf

The keyboard is extremely easy to configure, as the extension (if not Xorg itself) primarily gets that from the TTY (via the launch command [Xorg -nolisten tcp :0 vt1 -keeptty ...]):

Section "ServerLayout"
    ...
    
    InputDevice    "Keyboard0" "CoreKeyboard"
    ...

EndSection

...

Section "InputDevice"
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

(Bonus info, joystick, wacom, and even hyperpen and wiimote are also supported by Xorg directly with extensions, which not many seem to know about)
The mouse however... what little info I found about mounting the mouse via [mknod /dev/input/mice c 13 63] has failed to work, and I have yet to find any info that does

I assume a similar approach would be used to mount network devices, but I need some help figuring that out as [/sys/class/net/*] is empty without udev... >.>

IMPORTANT: Ensure your perms don't allow the user to freely read mouse/keyboard input, as that's the very reason why very many distros to date still run Xorg as root (ignoring the PE issues from doing so)
(Xorg should be ran as no more than user, or at least some mid-level group swapped to via newgrp, with the device nodes configured to allow Xorg to read them, but not the user, without granting full root access to Xorg)

But anyways, with Xorg out of the way, you should be able to remove udev without much issue...
The only thing that might stand in your way would be any packages depending on udev

dbus for example requires udev through libelogind, which obviously I don't have installed if I can remove udev XD
(The ONLY program I have that requires dbus at all is Nheko, which to make that work, I had to pack dbus into it's AppDir and run it with [dbus-run-session] which loads a shoddy script that runs a notification daemon and keepassxc under that)

So yeah, there ARE hurdles, but nothing too overly complex, especially if you focus on portability like I prefer (I guess it depends on what you prefer though, since I don't use a WM that can't live without dbus for example, heck I don't even use a login manager at this current moment)

I'll save the details of what I run for the history/pain thread, as I think it might already surprise a lot of people I even run Xorg