@SteveM your approach and experience  , althought more close to lowlevel and hardware , makes me think . Could it be that low level programming is less 'forgiving' ?  Thus more caution is needed to control the behavior of a programs to the bit level . And maybe the more higher we get to the data types used and more close to the human user then a program has more space to 'play' , data types get more fuzzy and thus a programmer could have more flexibility moving away from strict formal protocols ?

And isnt it true that AI (even in it's current LLM, hyped form) exemplifies that fluent - space - where we humans feel cosy and speak with ease and speed letting our wished flow to the AI agent ?

So when a programmer uses the highest level possible of APIs (thus a level below an AI-LLM guided programming) doesnt also have a taste of that fluent programming -amenable perhaps tp bigger speeds and thus favored by touch typing skills- ?

That @LLM assisted approach reminds me also of @literate programming.
I thing the goal here was to allow a more fluent and thus speedy programming style.

So to wrap my thoughts up. It seems that speed in coding would be lost as we move more closely to fixed hardware confronting more 'friction'. And i would add that friction also comes when we move into an environment where a software's subsystem written by one must conform-align to many other subsystem's interfaces.Of course it could be argued that the programmer should just write the code!! All the difficulties i previously wrote it's not his/her job!!. But if we follow that line of thinking that that bare coding is perhaps a skill that indeed need touch-typing but the same time easily replaceable by LLM agents.

Although solved i still cant understand why on earth secureBOOT is needed if i add a gpu driver in my kernel. Wouldnt be enough to sign a module with a sysadm priv key in a kernel's keyring?

@kernel email list / Re: [GIT PULL] Load keys from signed PE binaries (2013)

@ Linus vs Matthew Garrett on secureboot . (2019)

shim source deb packages has an issue #990311 that although is reported again an older version of shim it's related to nvidia gpu driver.

The timing issue is the reverse of what i say. I have trouble using mokutil of the shim and not enrolling the keys from inside the uefi setup utility.

[SOLVED] by enroll-ing the nvidia pub key from inside the bios.
         

• 1. we move  nvidia-modsign-crt-89A7BE16.der in /boot/efi/EFI/debian

• 2. we start uefi setup

• 3. advanced / menus / boot / secure boot / keymanagement / append default db

But i still havent figured why  sudo mokutil --import nvidia-pubkey.der  didnt work neither the error with the persistent nvidia daemon.

I guess you refer to the XSMP. Another 'manager' of clients !.. It's getting crowded. Too many managers for the petites processes... I wonder if XSMP is a 'manager' that should be also managed by the 'system service manager' or by a user service manager..

It seems a petite process could grow big to become 'manageable' by many managers.
I guess a 'manager' could start feel lonely if no one responds to it's calls...

EDX-0   'shed' you mention used the scripted way. But i dont understand the problems that you refer to and why they would be related intrinsically to an interpreted service manager .

Also i find it interesting that you refer (in the shed project site) to efforts of other projects to make programs demonized.  It seems that the different service managers are creating pressure for user apps to have various perhaps incompatible 'APIs' to be 'manageable' by the various service managers.

ralph.ronnquist i should study more sysvinit and runit  i guess. My idea was that by using a scripted service-system supervisor you make the system less complex (in comparison to having a another -hardcoded- supervisor). But you argue that shell-scripted control leads to less coherence due to more offered flexibility. So as a metaphore ,the system's services supervisor should be a brick to hold the userspace and not a quicksand ?

@ralph.ronnquist  I was off for a while so unfortunately i couldnt sync to your proposed X conf race :-) 
but thanks for the solution.

It worked but only to one of my host where i start X from a tty shell with startx.
In the other xfce host with xdm as display manager it didnt work.

I will try to read to xdm conf.
I think it's :

/etc/X11/xdm/Xservers
:0 local /usr/bin/X :0 vt7 -nolisten tcp

Changing -nolisten to -listen it'll be effective after restarting the whole system.Logging out from XDM and
llogginh again in didnt work.

Also it seem's appropriate since i started that thread to quote the security note from /etc/X11/xdm/Xservers
and remind to fellow devuan readers that what drives me is the curiosity to learn some basic of how network
trasnaperncy works with X.

Speaking of 'security' in the context of X can have more finegrained control than xost + that i tried for experimentation's sake.
So i think that ssh forwarding could 'overdone it' for a home lan. I guess having access restricted inside the lan hosts could be a far more better and less computational intesive approach. Last, i prefer the term 'workflow isolation' than security. Security make me think of badass criminals and police. But when i work on my table for me 'security' is not allowing other family members messing with my workspace. On the other hand i may have set a space to allow someone to laydown a snack or water.. (i wonder if that is a part of the desktop metaphor that was missed in the 80s..)