Kernel ou _nostub ? - Page 3

Kernel ça suxxx, Nostub ça puuuuue, vive AMS. ^^ (cherchez l'erreur)

Moi aussi j'aime l'Application Management Services

(quoique non en fait mais bon )

Pff vous êtes nuls ! kernel sux, nostub suxxxxxxxx, flashapp powa

_nostub rox.

kernel ça me fait penser à du .NET ou du java, dans la mesure où il faut installer un (gros) truc pour faire marcher même un petit "hello world".
A la limite les concepteurs des lib kernel auraient du pousser le vice jusqu'au bout et faire un truc à virtual machine qui fait du JIT.

?

tu le sors d'où tout ça? tu te fais des interpretations délirantes et imaginaires (toi qui aimes bien ça) pour pouvoir me faire des attaques perso?

Lionel Debroux (./60) :
J'aime bien l'esprit de ce topic.

, jusqu'à ce que Martial arrive en tout cas

oué mais bon, si tu pouvais râler contre onur par email à partir de vos boites persos, au lieu de pourrir les topics humoristiques, ça le ferait bien, hein (== j't'aime bien mais t'es pénible là)

Comme si TIGCC avait tué le _nostub

Sinon, moi, j'aimais bien les jeux en kernel

Le kernel ayant déjà été aboli, si tu vas abolir le _nostub, il ne reste plus grand chose. Sauf éventuellement les FlashApps...

Martial, hier j'ai eu une vision. C'était Jésus. Il m'a dit toute la vérité concernant le kernel, il m'a dit que c'était nul. Si si! c'est vrai!!! Et puis je suis allé voir le prêtre à mon église préférée. Il m'a dit que la même chose était déjà arrivé à ses collegues.

Mais voilà toi tu vas essayer de me montrer par a+b que kernel est mieux, en niant completement et paradoxalement ce que Dieu m'a dit à travers l'image de Jésus.

Et le _nostub c'est Satan. Méfie toi Onur !!!

Oui. Mais voilà Martial va préferer me donner des raisons techniques plutôt que tenir compte de ce qui s'est réellement passé, et ce que Jésus m'a dit.

onur (./76) :
Martial, hier j'ai eu une vision. C'était Jésus. Il m'a dit toute la vérité concernant le kernel, il m'a dit que c'était nul. Si si! c'est vrai!!! Et puis je suis allé voir le prêtre à mon église préférée. Il m'a dit que la même chose était déjà arrivé à ses collegues.

Mais voilà toi tu vas essayer de me montrer par a+b que kernel est mieux, en niant completement et paradoxalement ce que Dieu m'a dit à travers l'image de Jésus.

Si tu dis que Jesus te l'a dit, alors je te crois
J'écrirais un bouquin et je le répèterais à tout le monde.

Jésus ne "dit" pas, Jésus crie. Lire à haute voix pour comprendre si vous ne connaissez pas encore ce jeu de mot...

oh!

Ton jeu de mot témoigne simplement d'un manque total de respect :-/
Si tu penses que le kernel est bien, tu as le droit de le penser. Mais ne vient pas descendre ceux qui ont eu la chance d'avoir reçu la lumière.

Une preuve que c'est mauvais est le désinteressement des codeurs depuis le monopole de TIGCC et de son nostub...

Il y a plusieurs analyses possibles des causes du désintéressement des codeurs depuis 2-3 ans, elles comportent certainement toutes une part de subjectivité.

Je pense que pour bien analyser le phénomène, il est une erreur de se focaliser uniquement sur des choses qui se passent dans la communauté TI-68k (je veux dire: sur le plan technique, sur le plan des communications entre personnes, sur le plan des disponibilités des personnes). Il faut regarder un peu plus largement, dans la vie réelle.

Oui, le nostub_ est bien trop dans la vie réelle, et c'est la faute de la TIGCC. Je suis d'accord

Je pense qu'on peut trouver un peu mieux comme explication

Déjà, il n'est pas très juste de taper sur TIGCC. Au cas où certains feraient semblant de l'oublier, TIGCC, avec son linker depuis TIGCC 0.95, introduit des capacités (optimisation) que les vieux outils traditionnellement utilisés pour le kernel-based n'ont pas - et qui peuvent aussi profiter au kernel-based. Certains de la poignée de programmeurs kernel-based restants ne l'utilisent à ma connaissance pas, ils ont tort.

Mais ce linker introduit aussi certaines capacités du kernel-based qui sont mauvaises en _efficacité_: citons BSS, relocations mode kernel. Dans ces deux cas (et aussi avec les RAM_CALLs, par exemple), on se trouve avec du xxx.l relogé alors que du pc-relatif ou du an-relatif est en général largement possible, et plus efficace.
La couche d'abstraction représentée par le kernel (se traduisant notamment par kernel::exec et les RAM_CALLs) est bien pour la compatibilité antérieure. Celle qui permet toujours au vieux txtrider buggé de fonctionner (un peu) sur les machines modernes.
Mais vous savez comme moi, et ça ne s'applique pas qu'aux TI-68k, que la compatibilité antérieure se fait au détriment de l'efficacité, notamment parce que l'absence de modif/recompilation périodique ne permet pas de profiter des améliorations de la toolchain.

Euh, il n'y a pas de RAM_CALLs dans ld-tigcc (sauf ceux du mode kernel évidemment).

Bien vu, j'ai pas dû finir les modifs de mon post. Je vais corriger ça.

pourquoi ne pas choisir la voie du milieu? un truc nouveau, éloigné du _Nokerstubnel, plus efficace, et qui regroupe les avantages des deux?



et pis moi je vais militer pour que les progs TI passent au format ELF