Linux? - Page 52

Pen^2 (./1524) :

squalyl (./1522) :
donc chaque programme nostub est obligé d'embarqué son propre code de calcul des relogements?

Ben non, il me semble qu'il y a une fonction d'AMS qui s'occupe de ça. C'est le mal, certes, mais faut pas exagérer

Ben si en fait tu vois, faut exagérer

Bof, le _nostub suxe assez d'origine sans avoir besoin d'en rajouter
(Il ne faut pas se moquer, il est né comme ça, le pauvre )

Rah arrête, tu me mets la larme à l'œil...

Tiens, un mouchoir ! (et c'est pour les larmes des yeux, hein, cochonne !)

Bon, sur ces bonnes paroles, je rentre à ma maison

²

Oooohhhh, le Pen^2 qui nous fait un kernel::exit \o/

Et si on pouvait revenir au sujet (GNU/Linux)?

GNU/Linux est génial : il a un kernel, il a tout compris \o/

Non, le sujet c'est « Qu'est-ce que Linux ? ».

C'est un kernel !!!!!!!!!!

Mais alors pourquoi Kevin idolâtre Linux ?

C'est une question sur laquelle les philosophes réfléchissent depuis des millénaires.

C'est un noyau de système d'exploitation, pas un TSR totalement inutile qui se pose par dessus du système d'exploitation, consomme de la RAM en permanence sans que ça apporte quoi que ce soit pour l'utilisateur et se fait appeler "kernel" sans en être un.

Kevin Kofler (./1543) :
totalement inutile

Kevin Kofler (./1543) :
sans que ça apporte quoi que ce soit pour l'utilisateur

Kevin Kofler (./1543) :
et se fait appeler "kernel" sans en être un

Kernel extender à la base, kernel c'est plus court. C'est si grave que ça ?

Que je précise un peu quand même :
- le kernel fournit une détection matérielle, que chaque programme nostub réinvente
- le kernel fournit une détection de AMS, que chaque programme nostub réinvente
- le kernel fournit un linker dynamique avec les librairies, que chaque programme nostub réinvente
- le kernel fournit un support des bss, que chaque programme nostub réinvente
- le kernel fournit une détection de VTI, que chaque programme nostub réinvente
- le kernel fournit l'adresse de ROM_BASE, que chaque programme nostub réinvente
- le kernel fournit un support des valeurs de retour, que chaque programme nostub réinvente
- le kernel fournit un support pour exécuter d'autres programmes, que chaque programme nostub réinvente
- le kernel fournit le support de exit et atexit, que chaque programme nostub réinvente
- le kernel fournit un support du fline moderne, que chaque programme nostub réinvente

- le kernel fournit un anticrash, pas le nostub
- le kernel fournit d'autres choses encore, comme la gestion des pack archive, pas le nostub
- le kernel fournit une API stable, pas AMS que les programmes nostub prennent en pleine poire

- le nostub consomme 4 kb de RAM pour sauver l'écran, pas les programmes kernel
- le nostub est dépendant des protections mises en place par TI, pas les programmes kernel
- le nostub tourne de manière absolument débile sous PedroM, sur lequel les programmes kernel peuvent tourner de manière terriblement efficace (libc intégrée, exécution en archive et plus encore).

J'arrête là. Toute façon tu as décidé du haut de ton trône divin, tu ne changeras pas

putain j'avais pas réalisé. tout ça?

Peut-être, mais le _nostub suxe par contre, et pas le kernel !!

Folco (./1545) :
- le kernel fournit une détection matérielle, que chaque programme nostub réinvente

La version matérielle est mise à disposition par le système d'exploitation, la fonction de TIGCCLIB se contente d'aller vérifier le bon octet du système d'exploitation. (Il y a un hack spécial pour VTI, mais vu l'obsolescence de VTI, on pourrait l'enlever désormais.) Le RAM_CALL kernel n'est qu'une autre méthode, redondante, d'accéder à cette information.

- le kernel fournit une détection de AMS, que chaque programme nostub réinvente

Le système d'exploitation propose 2 valeurs: le nombre de ROM_CALLs et, sous les versions récentes, la version exacte. TIGCCLIB se contente d'aller vérifier ces 2 valeurs (en général, la première suffit, elle est accessible en moins d'octets qu'un RAM_CALL). Le RAM_CALL kernel n'est qu'une autre méthode, redondante, d'accéder à cette information.

- le kernel fournit un linker dynamique avec les librairies, que chaque programme nostub réinvente

Les programmes _nostub n'inventent aucun linker dynamique, ils utilisent le linkage statique.

- le kernel fournit un support des bss, que chaque programme nostub réinvente

Les BSS sont souvent inefficaces à cause des relogements, il y a souvent des solutions meilleures, et dans les cas où c'est utile, ça coûte une allocation et une désallocation de mémoire, on n'a pas besoin d'un kernel pour ça.

- le kernel fournit une détection de VTI, que chaque programme nostub réinvente

VTI est obsolète, donc cette détection peut être supprimée.

- le kernel fournit l'adresse de ROM_BASE, que chaque programme nostub réinvente

ROM_BASE peut être calculée avec un simple & logique. Le RAM_CALL kernel n'est qu'une autre méthode, redondante, d'accéder à cette information.

- le kernel fournit un support des valeurs de retour, que chaque programme nostub réinvente

L'astuce de RETURN_VALUE ne prend presque pas de place dans le code.

- le kernel fournit un support pour exécuter d'autres programmes, que chaque programme nostub réinvente

Le programme moyen n'a pas du tout besoin d'exécuter d'autres programmes.

- le kernel fournit le support de exit et atexit, que chaque programme nostub réinvente

Le programme moyen n'a pas du tout besoin de exit ni atexit, AMHA avoir besoin de ces fonctions est un indicateur de code sale ou du moins peu adapté au support visé.

- le kernel fournit un support du fline moderne, que chaque programme nostub réinvente

AMS gère la FLine depuis la version 2.04.

- le kernel fournit un anticrash, pas le nostub

L'anticrash met en général la calculatrice en un état instable, donc autant faire un reset (c'est de toute façon conseillé même après anticrash). La mémoire archive est gardée.

- le kernel fournit d'autres choses encore, comme la gestion des pack archive, pas le nostub

Fonctionnalités exotiques et inutiles, et surtout sans aucun intérêt pour l'utilisateur final.

- le kernel fournit une API stable, pas AMS que les programmes nostub prennent en pleine poire

AMS fournit une API stable: les ROM_CALLs.

- le nostub consomme 4 kb de RAM pour sauver l'écran, pas les programmes kernel

Tu es libre d'utiliser la restauration de l'écran… Et puis la sauvegarde est plus simple, plus rapide et plus compatible, et la place est prise sur la pile où on n'a normalement pas besoin de ces 3840 octets.

- le nostub est dépendant des protections mises en place par TI, pas les programmes kernel

Le kernel ne pourrait même pas exister sans contourner ces protections. Les programmes _nostub font attention à ces protections exprès, pour pouvoir tourner sur n'importe quelle machine dès l'usine.

- le nostub tourne de manière absolument débile sous PedroM, sur lequel les programmes kernel peuvent tourner de manière terriblement efficace (libc intégrée, exécution en archive et plus encore).

Le _nostub est le format natif de AMS, donc forcément, ça utilise les fonctionnalités de AMS, pas celles de PedroM. Mais ça tourne très bien sous PedroM aussi si PedroM implémente les ROM_CALLs nécessaires. Je trouve dommage que PpHd n'accorde pas plus d'importance à la compatibilité AMS (implémenter les ROM_CALLs manquants, changer quelques détails internes pour un fonctionnement plus proche à celui de AMS (genre: boucle événementielle, pile d'expressions, implémentation interne des handles compatible AMS) pour être compatible avec des programmes qui dépendent de ces détails etc. plutôt que d'implémenter des fonctionnalités qui dupliquent celles de TIGCCLIB).

(Kevin, t'es lourd )

Et surtout: tout ce que liste Folco sont des détails techniques qui peuvent au maximum simplifier la vie au programmeur et qui dans la plupart des cas sont totalement invisibles même pour celui-ci grâce à TIGCC. Qu'est-ce que ça apporte à l'utilisateur final? Tout ce qu'il voit, lui, c'est un logiciel qu'il doit installer parce que sinon le programme qui l'intéresse vraiment ne tourne pas, logiciel qui doit être réinstallé à chaque reset et qui consomme de la place en RAM en permanence.

Flanker (./1549) :
(Kevin, t'es lourd )

C'est Folco qui est lourd en faisant sans arrêt sa pub pour PreOs dans un topic dédié à GNU/Linux! Et évidemment Kochise qui a lancé le tout avec sa question totalement hors sujet dans ce topic.

Qui aurait pu croire que le troll _krenostbunel fonctionne encore aussi bien

Quelle belle machine!

Kevin Kofler (./1548) :
Les programmes _nostub n'inventent aucun linker dynamique, ils utilisent le linkage statique.

Même pour les vraies fausses dll ? C'est fort alors, si c'est pas du linking dynamique c'est catastrophique en perf (lecture d'une table et calcul de l'adresse à chaque saut ?).

Kevin Kofler (./1548) :
Les BSS sont souvent inefficaces à cause des relogements

Alors pourquoi TIGCC produit des BSS pour les vars globales, pourquoi pas des variables initialisées dans le segment de code ? C'est débile comme comportement.

Pour le reste, je laisse pisser, j'en ai rien à battre. Et j'utilise encore VTI. Et je savais que tu répondrais à tout point par point.

Folco (./1553) :

Kevin Kofler (./1548) :
Les programmes _nostub n'inventent aucun linker dynamique, ils utilisent le linkage statique.

Même pour les vraies fausses dll ?

Presque personne n'utilise cette fonctionnalité, et elle ne sert pas à la même chose (le seul intérêt est de contourner la limite de 65518 octets), donc je n'en ai pas du tout parlé. Mais effectivement il n'y a pas de linker dynamique à vrai dire même pour ça, mais un fonctionnement de type dlopen (mais avec des IDs numériques plutôt que des noms de symbole, pour des raisons de taille et de vitesse).

C'est fort alors, si c'est pas du linking dynamique c'est catastrophique en perf (lecture d'une table et calcul de l'adresse à chaque saut ?).

Bah, ça fonctionne pratiquement de la même manière que les libs conditionnelles de PreOs.

Kevin Kofler (./1548) :
Les BSS sont souvent inefficaces à cause des relogements

Alors pourquoi TIGCC produit des BSS pour les vars globales, pourquoi pas des variables initialisées dans le segment de code ? C'est débile comme comportement.

C'est configurable. Les options par défaut ne sont pas forcément les plus efficaces. Sur certains programmes (quand il y a d'énormes tableaux globaux), les sections BSS rendent bien (elles économisent des kilo-octets d'octets nuls), sur d'autres non (j'utilise en général -mno-bss pour mes logiciels, ça désactive complètement les BSS, directement au niveau du compilateur). On peut aussi contrôler directement dans le code l'emplacement d'une variable globale (si on ne met pas d'initialisateur, elle sera par défaut mise dans une section BSS, si on en met un, même si c'est 0 ou {}, elle sera mise directement dans le programme) et aucune section BSS ne sera créée si on n'a aucune variable BSS.

Et j'utilise encore VTI.

Un émulateur qui n'a plus été mis à jour depuis 9 années?
Et en plus il n'y a aucune version GNU/Linux! Le fais-tu tourner avec WINE? Pourquoi pas utiliser un émulateur natif?

Kevin Kofler (./1551) :
Et évidemment Kochise qui a lancé le tout avec sa question totalement hors sujet dans ce topic.

Mouerf, venant de ta part, ça me va droit au coeur Nan mais c'était pour éclairer ma techno-lanterne, pas que t'en rajoute ensuite 40 posts pour défendre ton Graal-nostub...

Kochise

nostub vs kernel, lol, j'ai l'impression d'être de retour en 2001-2002 quand j'ai eu ma TI89 ^^

L'histoire n'est qu'une longue série de répétitions !

Kevin Kofler (./1554) :
Bah, ça fonctionne pratiquement de la même manière que les libs conditionnelles de PreOs.

Sauf que quand on programme efficacement, un saut vers une fonction de lib conditionnelle avec PreOS se résume à un jsr fonction.l si on accepte le smc, ou à un jsr x(an)/jmp (fonction) si on fait du pic. Même la version pic est pratiquement égale à la version la plus optimale, rien à voir avec le monstre de tigcc.

Kevin Kofler (./1554) :
Et en plus il n'y a aucune version GNU/Linux! Le fais-tu tourner avec WINE? Pourquoi pas utiliser un émulateur natif?

Oui, et il tourne impeccable, et je me passe la très grande majorité du temps de ce qui n'est pas/qui est mal émulé. Et souvent je le préfère à TiEmu pour une raison unique : son dock 57,26 fois plus petit permet de suivre, en always-on-top, à la fois le débogueur et le source.

Arvi89 (./1556) :
nostub vs kernel, lol, j'ai l'impression d'être de retour en 2001-2002 quand j'ai eu ma TI89 ^^

(gossip girl ... !! hahahaha #trihuhuhu#)

MDR ^^
(même pas pu voir j'ai envoyé mon PC au SAV là ^^)