Why do some software have tangled layers like M$ windows?

Project Discussion
, , , ,
1

  • Authselect manages profiles and all… providing intuitive “profile” management mainly through the authselect command. Without breaking PAM stacks

  • But why intermediate PAM confs then? Why not PAM and authselect be merged to some extent, reading from the same authselect confs?

  • Then there comes polkit which too could be quite integrated…

  • ===========

  • /etc/{passwd,group,shadow,gshadow} , then systemd-userdbd has a “default” root user ideal for usage, /etc/systemd/userdb can be used to incrementally define things like group memberships for such users and even “traditional” usernames… or full users…

  • systemd-sysusers could use /var/lib/systemd/userdb for the “random UIDs”, generating files to be used by systemd-userdbd, per-system randomness all maintained, fixed-UID system users just use /usr/lib/systemd/userdb “normally”.

  • Right now we have glibc NSS, systemd-userdb, 2 “central” systems for…. resolving usernames with properties like UIDs. Why not converge into the userb idea?

  • ============

  • udev-settle.service, lvmetad I needn’t elaborate on this, mostly out anyway.

  • ============

  • systemd-logind has a seat, assigns it to a “login” session which is mostly inactive, as all actual programs including the compositor and the XWayland instance running in CGroup-bound units in a “systemd-user” session.

  • They somehow access the seat through libsystemd APIs, I am unclear of the programming nuances,

  • Why there is such a bifurcation into the two sessions? Usually the ONLY program in the traditional “login” session is a stub one meant for “starting” or a DM “session worker”.

  • systemd supports assigning the user session systemd as the one to inherit and reap zombies among all it’s spawned children, and it does so.

  • So… shouldn’t a “login” just initiate the systemd-user service manager, maybe the 1st service can hooked by the DE to adjust other things based on other conditions (${XDG_RUNTIME_DIR}/systemd/ allows to modify quite a few things at runtime)

  • The seat, session management logic, everything, be centered around this systemd-centric session? It can take care of $SHELL just like the system instance takes care of “emergency mode”.

  • As a plus point, if that shell crashes it shall be restarted at least once.

  • As for “non-systemd” systems, they use their own primitive equivalents like gnome-session in the traditional “login” session, so there isn’t to be any lack of those.

  • I am aware of the situation regarding the kernel limitation not allowing systemd to track a login session as a systemd-launched one, but why is it there for so long? (I am curious what are the blockers)

  • =============

  • Continuing the tangle of session management, the TTYs and switching.

  • If systemd-logind handles most of the actual work of session management, including quite a few keyboard shortcuts like Ctrl + Alt + Esc,

  • I am curious as to why can’t it full-on replace the TTY switching system, either dropping the idea of multiple sessions completely (not that acceptable) or invent a new logind-centric “multiple sessions per seat” concept…

  • A mini wayland compositor with simpleDRM or whatever at the least, with a barebones kitty-graphics compatible term emulator…. would serve for the “shell” as a TTY.

  • The “kernel backup if userspace fails” idea, like the init=/bin/sh idea, is no longer applicable with complex userspace components in play.

  • The kernel-level TTYs are only useful for recovery until the userspace logind-centric components are ready.

  • =================

  • systemd-homed the portable home manager. Great, but how portable exactly? It has flaws. And inflexibilities. Too much to “just cover up” excluding SElinux gaps.

  • LUKS enc option adds a clunky GPT table onto the loopback image, but you can’t exactly create other partitions without breaking homed. So it’s vestigal here.

  • Why not support a homectl enroll or homectl include or homectl enable or similar command which takes a path, UUID, a precursor unit like var-home.mount and store the reference to the home area (like the non-secret parts of .identity) somewhere under /var/lib/systemd/home?

  • It could be a physical disk, partition, loopback, script-generated zram (for potential “guest” mode), systemd-homed just knows it by the details in its registry, and uses that. Without bothering of what type of disk it is (Except during FS creation).

  • It (ideally) fails off if the disk doesn’t exist. With a simple warning.

  • Same for all other things

  • Currently it’s even less portable unless you know CLI acrobatics.

  • ==================

  • And more, slowly I might reply with them…

So what’s your opinion?

1 Like