Payloads : Hermes ou Kakaroto ?

[Newserator]

Pour beaucoup d'entre nous, les différentes versions de payloads publiés parfois en quelques jours peuvent prêter à confusion, sans compter certaines versions/mods d'Open Manager qui intègrent de nouveaux patch, qui sont retirés ensuite afin d'être intégré au Payloads.

Bref, difficile de si retrouver au milieu des versions Hermes et KaKaRoTo.

Ce dernier a décidé de s'exprimer à propos du Payload d'Hermes. Ces explications se sont tenues en deux temps avec l'avantage de comprendre un peu mieux les coulisses des payloads.

Installez-vous confortablement, prenez un café, c'est parti :

Le 15 octobre : The Payload mess...

Beaucoup de questions se posent concernant les différents Payload dont le dernier PL3 (le mien) et je remarque que peu de gens savent vraiment de quoi ils parlent.

Je vais donc essayer de clarifier le sujet.

Tout d'abord , je conseille à tout le monde d'oublier le payload v3 Hermes. Je ne soutiens pas son travail , et d'après moi, ce payload n'est pas un produit correctement développé . Il peut entrainer des crash système et n'est pas correctement écrit . Pour finir, il semble ne pas avoir compris le principe du Git et son fonctionnement.

De plus, PL3 contient déjà depuis un certain temps toute la partie de travail que je qualifierai de correct venant d'Hermes. Il prend en charge l'installation des mises à jour de jeu ou encore le lancement des backups sans BR. Le reste, présent dans le payload Hermes ne sert à rien et amène même à des plantages dans certain cas.

Certain d'entre vous ont pu voir et tester ma version , et beaucoup me demandent en quoi elle diffère des versions actuelles.

PL3 n'est pas basé, lui, sur l'appel système 36 pour diverses raisons en commençant par le fait que ce n'est pas le bon code à utiliser . Il mappe en effet (en dur) un dossier complet vers une valeur (/dev_bdvd ou /app_home ou /dev_flash ou encore toute valeur codée dans le payload). Ce qui veut dire que si nous ( j'entends par là les développeurs PSGROOVE ou PSFreedom) ne voulons pas gérer le support des backups , aucun payload actuel ne fonctionnera avec backup manager sans devoir le patcher auparavant.

J'utilise donc l'appel système 35 car plus logique . Dans ce cas , vous pouvez mapper n'importe quel nom de chemin et lui en donner un autre . Le principe de fonctionnement étant : syscall 35 (char *ancien_chemin, char *nouveau_chemin).

Il devient donc inutile dans ce payload de coder en direct le chemin /dev_bdvd , ou meme de mapper /app_home en autre chose directement dans le code. Ni même d'avoir un syscall 36 qui va modifier /dev_bdvd et /app_home et par là même bloquer les homebrews qui voudraient utiliser la fonction diskless du backup manager. Ainsi, plus la peine d'utiliser un payload patché pour le "firmware usb loader" . Ca fonctionnera tout simplement car le choix de mappage des chemins sera directement inclus dans le homebrew lui même. Ce qui veut dire que les backup managers vont directement mapper le /dev_bdvd vers le chemin de leur choix et cela fonctionnera sans soucis avec mon payload , nul besoin d'un payload patché pour ce type d'application.

En conclusion, les backups managers dépendant du syscall36 ne fonctionneront donc plus. Seule la version Gaia est aujourd'hui compatible avec PL3 mais je ne doute pas que d'autres seront modifiés pour supporter le syscall35

Il faut bien comprendre que cette fonction est amenée à devenir un standard . C'est ce que tout futur payload devrait utiliser . La solution développée pour le PSJAilbreak à base de syscall36 sera naturellement abandonnée.

Il est temps que les payloads soient développés selon un nouveau standard , découvrir une centaine de payloads différents sur le net est une aberration. J'ai toujours cru en un payload unique qui fonctionnerait pour tous, et c'est pourquoi j'ai développé le PL3. C'est la raison pour laquelle celui ci est totalement indépendant du PSfreedom , (le PSGroove ayant été porté il y a peu pour s'appuyer sur PL3) et à mon avis , c'est dans ce sens que tous les futurs développements devraient se diriger. De plus , grâce au PL3 vous accédez directement au support des firmwares antérieurs (3.01, 3.10, 3.15 et 3.41).

Un nouveau Payload vient de faire son apparition , celui , créé par Rancid , qui fusionne "le meilleur des 3 solutions existantes" (Hermes, Waninkoko et Mathieulh) et je ne peux comprendre comment tant de gens peuvent s'en féliciter. Ces personnes ne comprennent pas que ce type de payload est totalement inutile . le PL3 contient déjà depuis un moment toutes ces fonctionnalités . Alors pourquoi perdre du temps à refaire ce qui existe déjà ?

Si je réagis aujourd'hui, c'est pour faire comprendre à tout le monde qu'il ne sert plus à rien aujourd'hui d'attendre de nouveaux payloads et que vous pouvez dès à présent vous baser sur PL3 car il contient déjà toutes les fonctions utiles.

C'est après avoir reçu un P3Hub et testé dessus PSGroove que j'ai modifié le code (basé sur la version jevinskie) et que je l'ai depuis optimisé pour PL3.

Ce qui veut dire que PL3 est aujourd'hui totalement fonctionnel pour tous ceux qui veulent utiliser aussi bien PSFreedom que PSGroove.

Vous n'avez donc plus aucune excuse pour continuer à utiliser des produits obsolètes ou mal codés tels que les premiers payloads disponibles jusqu'à présent.

Je n'ai pas parlé du "peek&poke". Laissez moi vous donner mon point de vue là dessus.

Au niveau du PL3, cette fonctionnalité est désactivée tout simplement car totalement inutile et obsolète !!!!

J'ai jeté un oeil sur le code de différents backup managers et il semblerait que tous ont recours au "poke" pour modifier "quelque chose" en mémoire parce que les développeurs pensent que c'est son rôle de faire cela . Il n'en est rien .

Pour faire simple ... si vous développez un homebrew , ne lui laissez faire que ce qu'il est sensé faire et laissez le soin au payload de patcher le kernel. De la même façon que le rôle du PL3 n'est pas de mapper /dev_bdvd vers /dev_usb000/Mon_jeu et de l'inscrire en dur.

Patcher un kernel par ce moyen n'est pas la bonne solution car l'offset utilisé dans ce cas est dépendant du firmware , et donc diffèrent pour chacun d'eux.

Cette fonction est donc totalement inutile et d'ailleurs absente des versions linux sur pc .. pourquoi voudriez vous l'inclure dans un payload ?

Les seules personnes susceptible d'utiliser cette fonction sont les vrais développeurs qui souhaiteraient analyser et modifier un kernel à la volée , voir de créer un driver pour un kernel précis.

PS : J'ai mis à disposition un script capable de créer le .hex de tout matériel compatible PSGROOVE pour tout firmware (

Ces fichiers viennent d'être mis à jour suite à quelques retours de plantage au lancement de certains backups.

Le 16 octobre : Pourquoi je n'aime pas le Payload Hermes :

Avant toute chose, le titre dit « pourquoi je n'aime pas le Payload d'Hermès ». Cela n'a donc rien à voir avec Hermès lui même. Je ne le connais pas, je ne lui ai jamais parlé, je ne sais pas quel genre de personne il est, et donc je n'ai aucune opinion sur ça personnalité.

Maintenant je voudrais clarifier quelques points. J'ai vu beaucoup de personnes m'attaquer pour avoir tapé sur Hermès, et bon nombre semble penser que je dis être meilleur que lui, ou quelque chose du genre. On dirait donc que j'ai créé une certaine confusion avec mes commentaires, dans mon ancien posr de blog. Je veux donc m'excuser, et être sûr qu'il n'y aura plus aucune confusion.

Quand je dis que le payload d'Hermes est « dangereux », les gens ne me comprennent pas. Non ce n'est pas dangereux pour votre PS3, pas de risque de brick ou autre. Le seul « danger » étant (dans certains cas) le crash...et donc le besoin de redémarrer la console...c'est tout. N'ayez donc pas peur que son travail puisse abimer (votre console) ou autre parce que, de ce que j'en sais, c'est faux.

Plusieurs personnes m'ont aussi dit « respecte ce qui a été fait », et je veux le faire. J'ai toujours respecté les gens, à chaque fois que j'ai terminé un travail, j'ai remercié ceux qui m'ont aidé à y arriver. Je ne recherche pas la notoriété ici (sinon j'aurais annoncé la release de PL3 il y a 3 semaines, quand je l'ai commencé). Je prend simplement du plaisir à faire ça dans mon temps libre. Hermes a contribué à de très belles choses et j'apprécie ce qu'il a fait, principalement quand il a réussi à régler le problème des contrôleurs avec certains jeux. C'était quelque chose de très difficile à corriger et j'ai été surpris de la rapidité avec laquelle il a trouvé une solution intelligente que je peux qualifier de « bon travail ». le reste de son travail sur le Payload, je n'apprécie pas trop et c'est ce que je veux développer dans ce message.

Pour ceux qui ne veulent pas connaître les détails techniques, laissez moi conclure en disant que si le Payload Hermes fonctionne pour vous, alors utilisez le. Je ne dis pas aux gens d'arrêter son utilisation. Je ne dis pas non plus que le PL3 fonctionne mieux. Peut être le fait il dans certaines situations, peut être pas. Le choix de l'utilisateur devrait toujours être « ce qui fonctionne pour vous ».

Le but du PL3 est de fournir un standard, et d'avoir une base de code commune pour tous ceux qui travaillent sur des payloads. De ce fait, PL3 devrait évoluer plus vite et avoir plus d'options...ou pas. Notez que c'est mieux pour les développeurs de payloads de baser ler travail sur le PL3. Mais encore une fois, cela n'a pas de sens pour les utilisateurs, si ce n'est clarifier la confusion autour de tous ces lanceurs, personne ne sachant lequel utiliser.

Je parle donc du PL3 comme un tronc commun pour les contributeurs. Les gens semble l'avoir baptisé « le payload de kakaroto », mais je n'ai jamais dit que c'était mon payload. PL3 est PL3, ce n'est pas uniquement mon travail et si vous regardez les logs, vous verrez que je ne suis pas l'unique contributeur. Le PL3 lui même intègre des patchs de Hermes, Wanikoko, Mathieulh. J'en ai amélioré quelques uns pour être sur que cela fonctionnerait mieux avec des firmwares différents du 3.41, mais il s'agit toujours de leur travail. PL3 n'est pas mon payload. PL3 est un payload partagé avec tous. De plus, PL3 en tant que projet contient de nombreux payloads (par défaut, pour développeurs, diump LV2, dump elfs, etc...)

PL3 n'est pas parfait, rien dans ce monde n'est parfait, donc il y aura des bugs. Cela ne fonctionnera pas pour certaines personnes. Qui sait ce qui arrivera. Mais je n'ai jamais dit que c'était parfait, les gens devraient arrêter de penser que j'ai dit ça. C'est écrit plus proprement, c'est une meilleure infrastructure, mais c'est la seul chose que je peut affirmer.

Pour ceux qui se plaignent du bouton de donation que j'ai ajouté au blog, je ne trouve pas cela recevable. Je ne mendie pas de l'argent (je n'ai rien reçu en 3 semaines pour ceux que ça intéresse). Si vous ne voulez pas donner, il n'y a aucune raison d'insulter à ce sujet. J'ai mis ce bouton pour que ceux qui apprécient le travail et veulent donner quelque chose puisse le faire. J'ai demandé des dons avant car j'avais besoin d'une PS3 de développement. J'ai déjà réuni assez d'argent pour l'acheter, je n'ai donc plus besoin de donations supplémentaires. Je ne demande donc plus d'argent, c'est aussi simple que ça.

Quand bien même, voici les explications techniques détaillées importantes des raisons pour lesquelles je n'aime pas son payload.

D'abord, le code n'est pas propre. On ne peut le maintenir. Le fait est qu'il donne son code source en fichier .rar plutôt qu'un format propre est certainement le défaut principal que je lui trouve. Oui cela ne change rien pour l'utilisateur, cela ne compte que pour le développeur. Le problème avec cette méthode de partage, est que vous n'avez aucun moyen de savoir sur quoi est basé le code. Il est donc difficile de savoir ce qui a changé. Et si vous y arrivez, à trouver cette base, et faite un écart, vous obtenez un écart gigantesque qui vous oblige à faire un reverse engineering pour comprendre ce qu'il a modifié. C'est compliqué et gênant pour les développeurs!

Pour ceux qui suivent mon twitter, vous pouvez voir combien de commentaires je poste. J'ai toujours préféré avoir de courts commentaires car chaque commentaire devient indépendant, s'explique de lui même, et facile à retrouver. Cela permet aussi de mieux intégrer, s'il ne vous faut qu'une section spécifique, vous ne prenez que ce qu'il vous faut, au lieu de copier coller tout le code et de l'éditer pour enlever le clutter. L'autre raison pour laquelle j'aime git c'est que s'il l'avait utilisé et que j'y aurais apporté une amélioration, le code lui serait encore crédité dans le log. Ca me permet d'avoir le code sans lui prendre ses droits d'auteur. Cela à permet à tous d'être crédité pour ce qui a été fait et je pense que c'est la meilleur solution pour un projet open source et communautaire.

La raison pour laquelle j'ai dit que son code pouvait crasher, c'est que son payload est devenu trop gros, et ne loge plus dans la mémoire du kernel, (1296 bytes). Il a donc décidé de déplacer le code à une position aléatoire (0x7fff000 je pense). Cela veut dire que son Payload ne fonctionnera que tant qu'aucune application, jeu ou kernel, n'utilisera de placement aléatoire, qui pourrait atterrir dans cette zone. Si cela arrive, alors le Payload sera écrasé et le kernel crashera. La bonne manière de faire (PL3 le fait), c'est d'allouer la mémoire durant l'initialisation du payload, de copier les fonctions voulues dans cette mémoire que nous avons et de faire en sorte que ces fonctions aient une position indépendante. De ce fait elles fonctionneront où qu'elles soient placées dans la RAM.

Une autre raison est la façon dont son syscall8 fonctionne. J'ai essayé de lire un assemblage et de faire un reverse engineering, et j'étais complètement perdu sans comprendre ce qui se passait. Il n'y a pas de commentaire (vous remarquerez que mon payload a un commentaire pour chaque instruction)...je vous demande comment je peux intégrer son syscall si je ne sais même pas ce qu'il fait. Si finalement il avait été sur git, j'aurais pu voir les commentaires et comprendre ce que chaque partie du code faisait...mais il n'a pas utilisé git alors...

La façon dont il a réparé le problème du contrôleur n'était pas non plus si bonne. Il a patché deux offset pour passez à une fonction qui décide à partir d'une certaine énumération quelle réponse donner. Et vous auriez contrôlé ça avec son propre sys call 8....pourquoi faire une telle chose? Cela rend le fix dépendant des personnes qui utilisent ce nouveau syscall et c'est inutile quand vous pouvez patcher directement la bonne valeur.

Je n'ai pas non plus aimé le fait que son code devienne un bordel indépendant du 3.41, et qu'il faudrait un boulot monstre pour essayer de le faire fonctionner sur le 3.15. J'ai déjà passé beaucoup de temps à nettoyer le payloads et les faire fonctionner avec d'autres anciens firmware, alors pourquoi s'écarter et écrire du code qui n'intègre pas cela, ça rend la collaboration plus difficile.

Il y a aussi tout le problème du syscall 35 ou 36, mais cela n'a rien à voir avec son payload puisque j'ai ajouté le sc35 après qu'il ait sorti son payload. Ce n'est pas que son payload soit mauvais parce qu'il ne le supporte pas mais le PL3 a un meilleur (si je puis dire) système call. Qu'est ce que cela veut dire pour les utilisateurs pour le moment? Rien pour le moment, peut être que ce sera utilisé pour développer de jolies choses plus tard, peut être pourrez vous placer un jeu sur un bluray et un autre jeu dans /app_home, ce qui peut être utile pour les utilisateurs. Pour le moment, c'est simplement plus flexible et plus propre.

Il y a de nombreuses autres petites choses que je n'aime pas, mais ce ne sont que des broutilles comparé à « le code ne peut être conservé » et « il n'utilise pas git ». Comme je l'ai dit si cela vous importe peu,alors je ne vois aucune raison pour que vous n'utilisez pas ce payload. Cela ne veut dire non plus qu'il n'est pas efficace, mais simplement qu'il manque d'intérêt pour le partage de code et l'open source. Mais ça n'enlève pas de valeur à son travail.

J'espère que cela clarifie un peu les choses. J'ai critiqué son travail, dit ce que j'en pensais et les gens ont trop réagi. Je voulais être sur que les gens me comprennent, et ne pensent pas que je ne respecte pas Hermes pour ce qu'il a déjà fait. Tout le reste n'est que de la dramatisation et des gens qui essaient de se faire voir.

Si ce post entraine d'autres problèmes, et bien tant pis, je ne pense pas avoir autre chose à dire. J'ai dit ce que je pensais, c'est à prendre ou à laisser. D'ailleurs je ne tolère pas les gens insultant sans raison. Alors s'il vous plait, critiquez moi tant que vous voulez, mais restez respectueux.

Merci. KaKaRoTo

  Site officiel : http://kakaroto.homelinux.net

Grand merci à Morris, Oliveroidubocal et Starlightelise pour le travail de traduction.

Lien vers article original : http://ps3.gx-mod.com/modules/news/article.php?storyid=2109

[mick711]

Enfin ce n'était pas trop tot

J'ai eu peur avec des news comme il en pleuvait que les Dev ne se battent avec toutes les méprises qu'il y a eu de la par des newseur

Perso en lisant il était pourtant simple de comprendre ce que KaraRoto pensait Hermes mathieulh etc. Mais il y a des petits malin qui voulaient comme d'ailleurs ce qui vien d'arriver avec le départ d'hermes de faire partir tous les Dev .... eux Sony est ou dans tout cela ?

Merci de ces précisions pour les mauvaises langues qui ce font le plaisirs de pourrir le dev sur PS3 ou comme cela c'est fait sur PSP et nous avons vu le résultat plus aucun CF sur PSP

Par contre comment est il possible de joindre KaraRoto car perso j'ai des problemes de reconnaissance de périphérique dans certain jeux comme Grd et NFS Shift et aucune solution d'ailleurs pour ces jeux le dongle est en cause car même avec les originaux en mode Jailbreak le G25 ne fonctionnent pas .

[tikilou]

Pour ma part, je pense que le raisonnement de Kakaroto tient la route, il semble objectif et reconnait le travail des autres, et j'estime également que son approche concernant le kernel, les patchs, l'allocation mémoire, les peeks&pooks, et le mode de fonctionnement des backups managers, est pleine de bon sens.

De toute façon, Hermes a décidé de quitter la scène PS3, donc il n'y aura plus rien après sa version 4.

Modifié 18 octobre 2010 par tikilou

[abb]

Je vais parler au niveau pratique de mon coté (je vais peut être dire une bêtise). j'utilise un téléphone (Diamond) pour lancé le code Hermes parce qu'il est en .bin. Je suis pas sur que je puisse faire pareil avec un .Hex.

Dans ce cas la, rendre son format universel m'empêchera de suivre l'évolution des ces fabuleux payload.

On a pas tous un flasher dédié et la Hermes répond à un besoin.

[Pagurus]

Pour ma part, je pense que le raisonnement de Kakaroto tient la route, il semble objectif et reconnait le travail des autres, et j'estime également que son approche concernant le kernel, les patchs, l'allocation mémoire, les peeks&pooks, et le mode de fonctionnement des backups managers, est pleine de bon sens.

De toute façon, Hermes a décidé de quitter la scène PS3, donc il n'y aura plus rien après sa version 4.

+1, chapeau bas Mr KaKaRoTo , voilà des explications claires & qui sont tout à fait dans l'esprit de l'open source -qu'aucun ne critique plus à ce jour, tellement linux est utilisé sous différentes formes commerciales aujourd'hui

dommage par contre qu'Hermes quitte la scène, s'ils avaient pu s'entendre ces deux là auraient probablement permis encore de grandes choses, comme par ex. la création et le maintien d'un cfw (open source) digne de ce nom

[Tetsumaki]

J'ai eu du mal à tout lire mais ça en valait la peine.

Merci pour la traduction.

[djeid]

Ce que veut dire KaKaRoTo en gros c'est: "merci a Hermes et consorts pour ce que vous apportez a la communauté mais vous codez avec vos pieds "

[lecareur]

Merci pour la news et la traduction, je suis 100% d'accord avec Kakaroto, d'ailleurs j'utilise son payload en toute confiance depuis le début, c'est pas un rigolo, il sait de quoi il parles...

[psychomantis59]

Ben moi le pl3 fonctionne pas sur ma ti84+ sa fais planter ma ps3 donc retour en hermes v4 hihi

Modifié 19 octobre 2010 par psychomantis59

[jabberwock]

choisit bien tes mots, si ta console etait réelement briquée (et non crashée), la V4 d'hermes ne pourrait rien pour toi...