c'est vrai, vous parlez toujours du nostub vs kernel en tant que programmeur.
donc, je vais faire différent
les seuls arguments que j'avanceraient ne seront pas techniques ni ceci ni cela, seulement de l'expérience vécue, en tant qu'utilisateur. (pas forcément que les miennes)
nostub: ça marche direct
kernel:
faut le kernel
faut les libs
vous direz stdlib résoud le poblème. non, parceque à chaque fois que vous utilisez un prog en mode kernel il doit décompresser les libs à utiliser, et justement, très souvent plusieurs.
Ce qui fait qu'un prog compressé en ppg est très souvent plus rapide à lancer qu'un prog en mode kernel.
Résultat: j'avais dans ma calc toutes les libs décompressées. (et on m'a vite imité)
imaginez: txtrider, vous voulez voir 1 texte deux secondes, vous devez attendre l'extraction de trois libs pour pouvoir lancer txtrider lui même.
vous attendez plus longtemps à attendre l'extraction que de lire la petite ligne que vous vouliez....
imaginez, des images créées avec tigrayimage (oui, d'accord, complétement obsolète
mais extrèmement utilisé par les utilisateurs moyens (simple d'utilisation)), quatres lib à extraire, pour une photo!
n'importe quel prog a ce problème...
gain de place >> poubelle, ou alors, gain de vitesse >> poubelle (vous avez le choix,
)
ensuite, l'histoire des versions "obsolètes" des libs:
c'est si courant que des progs aient leur propres libs (pctools
tbo crockman juste quelques exemples de prog que j'ai vu être très utilisés) et à chaque fois un message "lib pas à jour"...
*hahem*
ensuite, oui, c'est vrai il faut relancer le kernel à chaque reset, oup's on l'a déjà dit, et comme j'ai vu plus de progs kernel buguer que de progs nostub....
parceque "crash intercepted", c'est sympa, ça redonne la main, mais de toute façon après un truc du genre, on ne peut plus relancer d'autres progs de toute façon, (error: memory) donc reset oblige quand même.
L'argument comme quoi le kernel récupère les crashs est totalement nul.
ensuite *compatibilité* vers la fin de cette même année un type est venu me voir il avait une 89 y avait rien dessus, et en vrai nioob il veut que je lui installe deux trois progs (c'était courant ça)
J'ai sauté au plafond quand je me suis rendu compte que c'était une hw1 ams1... mais c 'etait pas ma calc, et donc mise à jour je pouvais pas, et essayer de faire comprendre ça à quelqu'un c'est dur .
bref, je devais faire avec ce qu'il avait parceque lui c'était "je comprend pas, je te comprend pas"
et ben je peux vous dire que preos dessus ça foire, et un reset sous ce genre de modèle et version d'ams on récupère rien.
résultat>> il n'eu que du nostub, aucun soucis, oui, bien sûr certains progs ne fonctionnaient pas au cause de l'ams trop vieux, mais c'est tout de même mieux que le prog nostub ne se lance pas du tout qu'un prog kernel se lance et fasse planter la calc..... Et très rares sont les progs qui demandent une ams très élevée, à part des progs comme id ou agenda qui ont bien sûr besoin des toutes dernières ROM_CALL, ces mêmes prog sont minoritaires, et sur une hw1 ams1 on peut jouer à spacedementia 1 et 2 sans risque (pourtant pas vieux du tout comme prog)
et on peut continuer des heures
les arguments kernel vs nostub courants ne concernent qu'un (très) faible pourcentage des utilisateurs de TI.....
j'ai toujours vu marcher un prog nostub, l'équivalent en kernel est difficile à obtenir....
[edit, ah si, avec pedrom, un prog kernel est aussi pratique qu'un nostub sous ams
, enfin c'est pareil, l'argument ne concerne que très peu d'utilisateur de TI]