) et c'est con tu vois, mais si les utilisateurs veulent avoir des programmes a jour, ils devront les mettre a jour quand même
sBibi a écrit :
"C'est que je n'aime pas les programmeurs qui rabattent une partie de leur travail sur les utilisateurs. C'est au programmeur de mettre à jour une librairie, pas à l'utilisateur!"
ooooh! merde alorset c'est con tu vois, mais si les utilisateurs veulent avoir des programmes a jour, ils devront les mettre a jour quand même
squale92
a écrit : exact : c'est au programmeur de la libréairie de mettre à jour sa librairie, pas à l'utilisateur de la librairie. (aka le programmeur qui utilises la lib statique)
XDanger
a écrit : Nitro: "J'ai fait le loader nostub pour genlib parce que ceux qui ne veulent pas de kernel ne pouvaient pas s'en servir.": Certes, mais genlib ne marche toujours pas sur VTI, ce qui est un défaut grave pour une librairie qui se voudrait largement utilisée: VTI est un meilleur outil de debug que la calculette normale.
)... De toute façon à l'heure qu'il est, ce probleme est deja corrigé.) et les pro-kernels (dont moi) ne veulent pas admettre non plus que certains de leurs arguments sont nuls (kevin ou XDanger va me faire remarquer que je n'ai pas employé la même formule que pour les arguments du _nostub, etc, etc... eh oui, je n'ai pas un regard objectif, mais vous non plus)
) sur ca calc un kernel => il peut rentrer dans le vif du sujet plus vite !!
)
squale92 a écrit :
Kevin> oui, j'ai détourné tes propos... je n'ai pas pu résister à la tentation
(même si j'avais saisi ce que tu voulais dire)
Kevin> Admettons que, demain, je sorte KII en version finale, pas de bug ni quoi que ce soit qui puisse m'obliger à sortir un jour une nouvelle version, et que, ensuite, après-demain, je quitte définitivement la communauté.
Dans quelques mois, on se rend compte que les routines de décompression d'Extgraph que j'utilises comportent un bug...
Si je ne suis plus là, et vu que je n'aurai pas releasé les sources, KII ne seréa jamais corrigé.
Alors que si les routines de décompression étaient en librairie dynamique, il suffirait de changer la librairie...
Donc, dans ce cas, en lib statique, ça fait un programme buggué... alors qu'avec une librairie dynamique, il ne le resterai pas !
Ne me dit pas que ce cas n'arrive jamais : combien de programmeurs ont quitté la communauté dpeuis sa naissance ? certes, ce pb ne s'est pas encore bcp vu, car les codeurs nostub ne sont pas là depuis très très longtemps, et que peu d'entre eux sont partis... mais dans quelques années, qd certains seront parti, le problème que j'évcoque commencera à apparaitree !!!
sBibi
a écrit : franchement, le Kernel soulage les 2 côtés: le programmeur ET l'utilisateur. d'abord le programmeur: il n'a pas besoin de toucher son prog si une lib est mise a jour, ensuite l'utilisateur n'a qu'à envoyer la lib, pas le programme entier...
je me vois mal réinstaller CF sur ma calc juste pke une version plus récente de Genlib est sortie...
en ce qui concerne le fait de devoir aller sur plusieurs sites pour récupérer les libs/progs, puisque vous dites si bien que le programmeur doit épargner du travail a l'utilisateur, dans chacune des releases de ses progs, il devrait inclure la version la plus récente des libs nécessaires (sous l'accord de l'auteur des libs),
ou tout simplement mettre un lien... ne seraist-ce qu'un lien vers le kernel requis.
ce qui me fait bien marrer aussi, c'est qu'apparemment kevin se prend pas pour de la merde, notemment en insinuant que toutes les personnes qui ont conçu tous les systèmes d'exploitations actuels sont des cons de ne pas avoir tout programmé en _nostub (kevin: je n'ai pas oublié le underscore)... regrouper les routines récurrentes est une des bases de l'optimisation en taille, je ne vois pas qui pourrait me contredire la dessus, surtout toi kevin...
on trouve ça au niveau du code (bsr), au niveau des logiciels (libs), même dans la société... Kevin a été un des premiers a dire dans je ne sais plus que Topic que selon lui l'éducation était un peu trop généraliste... vous voyez un patron qui soit a la fois cuisinier, secrétaire, comptable, balayeur de chiottes, etc... non? ben moi je vois un peu le _nostub comme ça...
pour avoir la même efficacité, il faudrait plus de personnes comme ça qu'il n'en faut si elles sont spécialisées dans un domaine... un patron, une secrétaire, un cuisinier, un balayeur... c'est pareil avec les routines, avoir par exemple 4 ou 5 routines de sprite16 ne sert a rien, sinon a alourdir le prog, a entrainer des bugs, etc etc... pour les libs et les progs, c'est la même chose, en _nostub on a des tas de progs avec exactement les mêmes routines dans le ventre... avec le Kernel (uniquement dans l'idéal malheureusement) on a une seule routine par fonction... (que ça soit clair, je ne parle PAS des rom calls, mais de la diff libs statiques/dynamiques!)
ça peut vous paraitre stupide comme point de vue, mais c'est une façon comme une autre d'imager les choses... des progs _nostub peuvent avoir des libs statiques de différentes versions, certaines seront peut etre encore buggées, d'autres non, certaines seront rapides, d'autres encore pas très optimisées... avec les libs dynamiques, si la lib est buggée, on la change, un point c 'est tout.
XDanger>"sbibi:" j'en reviens pas que tu sois si borné et fermé d'esprit...": ne l'es-tu pas toi aussi ? Si on veut dire que des arguments ne tiennent pas (et je ne suis pas persuadé que ce soit le cas des arguments de Kevin), il faut faire des critiques qui tiennent debout..." je le suis déjà moins que Kevin, puisqu lui n'est apparemment pas capable de concevoir qu'il peut avoir tort...
des critiques qui tiennent pas debout? arf désolé, j'ai subi l'influence du syndrome de Kofler...
un mec vient de s'acheter une 89 -> tres bien, malheureusement dans 90% des cas, le temps qu'il apprenne a s'en servir...
il telecharge TIGCC -> ça pourrait vouloir dire qu'il sait programmer en C ou qu'il veut apprendre... dans le même ton on pourrait aussi avoir: il telecharge A68k -> ça pourrait vouloir dire qu'il sait programmer en ASM ou qu'il veut apprendre...
>il n'a pas besoin d'uploader (note de moi: on dit downloader
bof la aussi on pourrait avoir:
le temps que TIGCC finisse de se dl, A68k et le kernel seront dl depuis longtemps..., en même temps il aura makeprgm inclus dans PreOs, trois pour le prix de deux...
le temps que TIGCC s'installe, ça fait belle lurette qu'il a killé le graphlink, que le kernel se prélasse dans sa calc, et qu'il a tapé "preos()"+[ENTER]
) qui offre aussi le C en plus de l'assembleur prenne plus de place qu'un environnement préhistorique à base d'un fichier BAT et pour l'assembleur seulement.
gugusg a écrit :
c en machant le travail des nioubi (simplicite !!!du _nostub) que apres ils comprennent plus rien alors que si ils font l'effort de comprendre des le debut c mieux
Thibaut a écrit :
XDanger : "Les librairies des kernels ont plein de fonctions très vieilles et inutiles (Kevin les a citées), gardées par 5 ans de compatibilité (que le nostub ne traîne pas comme un boulet, lui, forcément)"
Ha ! Kevin et toi vous me faites rire.
Votre refus d'ajouter les ROM_CALLs des derniers AMS dans la bibliothèque de TIGCC afin de garder la compatibilité 1.0x, c'est pas "un boulet" ?
Comique va !
squale92 a écrit :
Thibaut> ils vont te répondre par le truc du define AMS_MIn_machinechose, qui me gave un peu en fait... obligé à chauqe fois de le supprimer
ExtendeD
a écrit : Ouais, là, je suis plutôt d'accord Thibaut.
Déjà qu'on envoie une nouvelle version de la librairie ou une nouvelle version du programme statiquement linkée, on n'envoi qu'un seul fichier dans les 2 cas, donc ça ne change rien. Et si le programmeur met à jour le programme et qu'il faut une nouvelle version de la librairie, soit parce que la nouvelle version du programme la veut, soit parce qu'on veut mettre à jour la librairie également? Ça fait 2 fichiers à mettre à jour avec une librairie dynamique, et un seul avec une librairie statique.
Dans ce cas, le problème est que PpHd a tout mis dans un installeur qui ne permet pas de choisir les composants à utiliser. Donc si on ne veut mettre à jour que le programme principal, on doit se taper toute l'installation. C'est un problème de l'installeur de CF (tinstall), pas du principe des librairies statiques.
)
Et où est la différence avec les librairies statiques? Avec ce que tu proposes, le programmeur doit quand-même mettre à jour son programme à chaque fois qu'une nouvelle version de la librairie sort.
Mais l'utilisateur doit quand-même suivre le lien, aller chercher le fichier dont il a besoin, le télécharger et le décompresser séparément. C'est lourd.
)
Non, pas du tout! Si pour avoir un seul programme, il faut installer 30 dépendances, on perd 3000% de place!!!
Justement, on en est très loin de ce cas "idéal" avec les librairies dynamiques. Malgré cette considération purement théorique, en pratique, les librairies statiques épargnent souvent de la place pour des raisons que j'ai déjà citées dans ma longue réponse à PpHd.
Si tous les programmes utilisaient les même routines, un bogue dans une de ces routines se retrouverait dans tous les programmes. Regarde ce qui s'est passé avec l'exploit zlib sous Linux récemment: de nombreux programmes linkaient avec cette librairie (soit statiquement, soit dynamiquement), et un grand nombre d'entre eux étaient à risque à cause de l'exploit. Le problème a vite été résolu en corrigeant zlib (et pour les programmes statiquement linkés, il a suffi de les recompiler, ça n'a pas été plus lourd que pour ceux linkés dynamiquement), mais tant que ça n'a pas été fait (il faut du temps pour corriger un bogue dans une librairie), il y avait beaucoup de programmes à risque d'exploit. Donc avoir le choix entre des routines différentes est une très bonne idée, même si ça pourrait te paraître du gaspillage.
mais bon, en ce qui concerne les Ti, compiler comme pour les PC, ça ne sert pas vraiment a grand chose... je mets 5 sec a compiler un prog de 20K sur un portable archi merdique, c'est quasi instantané sur mon pIII 500, quand on voit les procs a 1.7 GHZ ou plus, ne recompiler qu'un bout du code n'a plus vraiment bcp d'intérêt (tjrs pour les ti!)... mais bon la je ne connais pas trop le vocab linux/unix, mais apparemment ça ne s'applique pas aux progs sur ti, mais aux compilos, dc le pbl n'est pas la, au contraire ça favoriserait plutot les progs utilisant des libs dynamiques, puisqu'il ne faudrait corriger que la lib (enfin bon g ptet mal compris )
Évidemment que je peux avoir tort. Mais prouve-le moi. Pour l'instant, à chacune de tes critiques de mon raisonnement, j'ai pu te répondre pour le défendre.
Comme tu n'as plus d'arguments, tu passes aux attaques personnelles...
et de quels arguments j'aurai eu besoin pour répondre à ça? on me dit un truc gratuit, je répond par un autre truc gratuit la encore c'est votre pt de vue
Je te signale que la version officielle de A68k est celle de TIGCC. Toutes les autres sont des distributions non-officielles. Raison: c'est moi le mainteneur.
ça serait marrant que tu fasse un chck dans a68k pour savoir si tigcc est installé si il est pa installé, a68k lance ie a la page de le tict
C'est normal qu'un environnement moderne (vous aimez cette expression, donc je l'utilise ) qui offre aussi le C en plus de l'assembleur prenne plus de place qu'un environnement préhistorique à base d'un fichier BAT et pour l'assembleur seulement.
tigcc peut etre aussi, mais pour un crétin et un énorme paresseux comme moi, c'est plus simple, plus court, ConText compile pour moi (pas la peine de me dire que tigc aussi, chuis au courant lol), j'ai un compilo et un linker, je sais ce qu'ils font, j'ai pas le dossier de mon proj encombré avec des fichiers générés par une IDE que je sais même pas ce qu'ils viennent foutre la...
Bravo, tu as compris tout le principe de la facilité d'utilisation. Dans le cas où tu n'aurais pas compris tout de suite, la phrase ci-dessus était ironique!
Kevin Kofler a écrit :
Si tous les programmes utilisaient les même routines, un bogue dans une de ces routines se retrouverait dans tous les programmes. Regarde ce qui s'est passé avec l'exploit zlib sous Linux récemment: de nombreux programmes linkaient avec cette librairie (soit statiquement, soit dynamiquement), et un grand nombre d'entre eux étaient à risque à cause de l'exploit. Le problème a vite été résolu en corrigeant zlib (et pour les programmes statiquement linkés, il a suffi de les recompiler, ça n'a pas été plus lourd que pour ceux linkés dynamiquement), mais tant que ça n'a pas été fait (il faut du temps pour corriger un bogue dans une librairie), il y avait beaucoup de programmes à risque d'exploit. Donc avoir le choix entre des routines différentes est une très bonne idée, même si ça pourrait te paraître du gaspillage.
sBibi a écrit :
mon dieu t'as raison, que c'est fatiguant, bien plus que quand tu reset a cause d'un crash not intercepted et que tu dois reinstaller tt ce qui était en ram... (bon, je sais tu vas dire que les progs _nostub ne plantent pas...)
et si t'as 30 programmes?
et qu'il t'a répondu en disant que dans le cas de libs comme genlib ou 90% du code était indiscossiable, ça n'apportait RIEN, et qu'au contraire ça faisait perdre de la place...
très bon exemple, je connaissais pasmais bon, en ce qui concerne les Ti, compiler comme pour les PC, ça ne sert pas vraiment a grand chose... je mets 5 sec a compiler un prog de 20K sur un portable archi merdique, c'est quasi instantané sur mon pIII 500, quand on voit les procs a 1.7 GHZ ou plus, ne recompiler qu'un bout du code n'a plus vraiment bcp d'intérêt (tjrs pour les ti!)... mais bon la je ne connais pas trop le vocab linux/unix, mais apparemment ça ne s'applique pas aux progs sur ti, mais aux compilos, dc le pbl n'est pas la, au contraire ça favoriserait plutot les progs utilisant des libs dynamiques, puisqu'il ne faudrait corriger que la lib (enfin bon g ptet mal compris
Je ne parlais pas du temps de compilation, mais du temps pris pour modifier la source elle-même, quand je disais "il faut du temps pour corriger un bogue dans une librairie".
je sais
Sauf qu'on le mettrait à notre page, pas à celle de la TICT.
l'"environnement préhistorique" marche très bien
Nitro a écrit :
L'exemple est parfait... sur mon serveur FreeBSD j'ai plus d'une 20aine de programmes qui utilisent zlib.
Pour ceux qui linkent dynamiquement, aucun probleme, je download et j'installe le patch pour libz.so.. 2 commandes à taper, et c'est fini.
Pour ceux qui linkent statiquement, deja bonne chance pour les trouver... et comme le dit le site lui meme:
Various ports may statically link zlib or contain their own versions
of zlib that have not been corrected by updating the FreeBSD libz.
Efforts are underway to identify and correct these ports.
Et je lui ai répondu qu'il n'est pas difficile de changer genlib pour qu'il n'y ait plus 90% du code indissociable
Kevin Kofler a écrit :
Déjà pour mettre tellement longtemps à trouver des programmes qui linkent zlib statiquement, j'ai bien l'impression qu'ils ne sont pas doués. Ça doit bien se voir:
- dans les makefiles
- dans les headers utilisés
(Ceci présume un programme open-source. Pour un programme closed-source, c'est la responsabilité de celui qui le délivre de le corriger, pas du projet FreeBSD.)
FreeBSD c'est justement l'exemple où c'est le moins pire (avec les autres BSD qui ont un système de paquetage automatisé similaire), par contre sous Solaris ou sous Linux, c'est toi qui va devoir te taper le boulot toi meme pour trouver quel logiciel utilise zlib statiquement... alors là qui se tape le sale boulot, l'utilisateur ou le programmeur ?Kevin Kofler a écrit :
RedHat a mis à jour tout un paquet de programmes linkant statiquement (ou recopiant carrément) zlib en même temps que zlib elle-même. Il suffisait d'aller télécharger tous les errata (et il y a des moyens automatiques de le faire: up2date pour les abonnés, sinon apt4rpm ou alors des shell scripts qui traînent sur Internet). Donc désolé de te décevoir, mais on peut faire mieux que FreeBSD! Il y a même un scanneur automatique qui reconnait des programmes utilisant zlib en regardant le binaire seulement!
kevin a dit : Dans ce cas, le problème est que PpHd a tout mis dans un installeur qui ne permet pas de choisir les composants à utiliser. Donc si on ne veut mettre à jour que le programme principal, on doit se taper toute l'installation. C'est un problème de l'installeur de CF (tinstall), pas du principe des librairies statiques.
) il sortirait une version complète 3.29 BETA 2 ET une version UPDATE 3.29 BETA 1 to 3.29 BETA 2 qui ne réinstallerait QUE les fichiers mis à jours ?
Nitro
a écrit : C'est un cas particulier...
tu as tendance à penser que le monde doit etre parfait, mais bienvenue dans la vie réeelle, dans laquelle des milliers de machines sont insécures à cause de zlib linké statiquement. Le temps mis par les admins à corriger tout ça c'est de l'argent de perdu.
Pourquoi d'apres toi le ELF est consideré comme le format d'objet moderne et le COFF/AOUT/etc.. sont considerés obsoletes ? Parce que le ELF gere nativement le C++ et les libraries dynamiques.
Et je t'entends encore me dire "oui c'est bien beau sur les ordinateurs, mais la on est sur calculatrice, mémoire/proc limitée, etc etc...". Alors regarde du coté de RTEMS, noyau temps réel pour l'embarqué (tourne sur 68000 entre autres, prend 70 Ko avec la libc posix),
ils sont passés de COFF à ELF depuis un bout de temps.. regarde également du coté de uCLinux (noyau Linux qui tourne sur 68000, prend moins de 500Ko), ils sont également passés de COFF à ELF, pour les memes raisons.
Ca n'a plus grand chose à voir avec kernel/nostub, mais c'est juste pour essayer de te faire prendre conscience que l'immense majorité des OS utilisent des libs dynamiques et que tu ne peux pas te prétendre plus intelligent que tous leurs concepteurs.
):
Kevin Kofler a écrit :
La seule chose qui est particulière dans le cas de zlib est le nombre de programmes qui l'utilisent! Elle s'est retrouvée même dans des programmes de M$! Pour la plupart des autres librairies, les dégats seraient de loin plus petits.
Et puis les considérations de sécurité (comme dans le cas de zlib) n'ont pas du tout leur place sur TI-89/92+.
Si les admins ne sont pas foutus lancer up2date (une entreprise est censée être abonnée à RedHat Network), ils ne méritent pas d'être admins.
Et je sais bien que RedHat n'est pas la seule distribution *nix qui utilise zlib, mais pratiquement toutes (FreeBSD serait l'exception si tu dis vrai) ont mis à jour les paquets linkant statiquement zlib dans leurs erratas, et pratiquement toutes offrent un système automatique équivalent à up2date ou à apt-get de Debian.
Et ça complique inutilement le format, et ça crée des bogues. Surtout en combinaison. Il y a un thread entier sur ceci dans la mailinglist de GCC en ce moment, regarde les archives pour voir comment il est énorme. Et c'est tout dû à la "flexibilité" excessive du format ELF.
Une libc POSIX pour Motorola 68000 qui tient en 70 KO??? Avec le noyeau real time en plus? Je n'arrive pas à te croire ceci...
Je ne suis pas le seul critique des librairies dynamiques!
du _nostub) que apres ils comprennent plus rien alors que si ils font l'effort de comprendre des le debut c mieux