Some comments from the J.Atwood post that offer contrary insights:

In favor of touch-typing :

Another argument again the importance of touch typing is that assuming the programming is a form of communication surely there is programming analogous to the blather (as to 'talk rapidly without making much sense').I've heard the argument that human (especially women) when socializing talk too much for various topics but that non-sensical talk acts as a socia-glue and it's very important (but in the social context not communicating with machinces!)

But again.. i've read stories of RMS being in nirvana codding state hacking teco and other programs in his mit ailab eden back in the 1970s where he seemingly was programming like talking to the machine.

And i think (sorry if i repeated that argument) that the idea-image of a programmer touch-typing-programming it has manager-wetdreams vibes. As a manager i would like to see my payed workforce sweat and be productive. And maybe that is the easies but perhaps the most erroneous way to judge programming productivity by expecting your programmers to touch-typing constantly like crazies.

golinux thanks for correcting my misplaced forum post .

As for your latest response. if you refer to the spiritual side i think you are right for the need of a spiritual awakening.

stargate thanks for the links. I found some interesting.

I think i've made a mistake .I should have posted this post in Offtopic. Can be transferred there?. Sorry.

Anyway i think the elevation of the touchtyping skill to a necessity (especially the way it was presented by it's original author) misses entirely the ergonomics and health issues side. The hands needs protection. And i forgot to mention that touch-typing could become obselete not by LLM-AI but by LLM-powered-speech assistant

I think programmers should support and try that tech . I imagine my self dictating code by voice to my computer even when my hands's nerves would become too fragile.

I propose a separate subforum for ergonomics and health issues of Devuan admins - users- programmers. The subforum would cover also accessability aspects of devuan. (elderly,disabilities etc).

greenjeans i aggree.That's why i stressed the -ultra hype- aspect of current LLM driven AI processes. I found also :  @ AI coders think they’re 20% faster — but they’re actually 19% slower

@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...