À vrai dire ils utilisent des fonctions non standard comme funopen, donc non, ils ne supportent pas tout ce qui supporte POSIX proprement. Ils supportent OpenBSD et rien d'autre.
Et non, ça n'est pas si facile de supporter Visual Studio, ou OpenVMS, ou autre OS non POSIX. OpenSSL le faisait pourtant, et c'est certainement une des raisons pour laquelle presque tout est basé sur OpenSSL. Mais j'imagine que c'est plus facile pour les développeurs d'OpenBSD de chier publiquement sur les couches de compatibilité d'OpenSSL (voire même de se moquer de certaines features comme le support d'OpenVMS) que d'essayer d'implémenter la même chose proprement.
Tu vois le monde en noir et blanc, en ignorant les nuances entre les deux. Si tu penses que les gens qui font en sorte de pouvoir développer sur du matériel que tu as acheté sont aussi "noir" que les gens qui permettent de télécharger illégalement et sans rémunération de l'auteur des logiciels normalement vendus pour un prix, je pense que je n'ai rien de plus à te dire.
Oh, et pour ton information : la Wii n'a pas d'EULA à accepter avant utilisation de la console, sauf pour les services en ligne. Je n'ai jamais accepté un seul EULA sur ma console.
C'est déjà faisable sans accès à l'OTP et sans autoriser la lecture de DVDs arbitraires non chiffrés sur la console : il suffit d'utiliser les fonctions de lecture de disque proposées par l'OS de Nintendo qui tourne sur la Wii.
Et très honnêtement, le nombre de gens qui dumpent vraiment leurs jeux depuis leurs DVDs au lieu de les télécharger est infime. Sans statistique exacte, je dirais moins de 2 ou 3% des utilisateurs d'émulateurs.
PS: Je suis un des core developers de l'émulateur Dolphin, dont parle le journal que tu cites.
Il y a deux raisons pour lesquelles les gens ont arrêté de release leurs exploits. La première, c'est de rendre plus difficile la correction des failles sur lesquelles les exploits se basent : plus l'exploit est "camouflé", le plus longtemps il sera valide et utilisable. La deuxième, c'est de rendre plus difficile l'utilisation des informations sur le fonctionnement interne des consoles par les gens qui développent des outils de warez.
Je m'étonne que tu relèves la non liberté de l'outil qui fournit le fichier "corrompu" causant l'exploit sans relever la non liberté du Hackmii Installer, qui est après tout le payload de l'exploit, et qui lui fait tout le travail intéressant pour installer le Homebrew Channel sur ta console. En plus de ne pas être libre, il est protégé par de nombreuses couches d'obfuscation afin de masquer la faille qui a été utilisée. C'est pour les mêmes raisons.
Cette deuxième raison, cacher des informations sur le fonctionnement de la console, est malheureusement due à des développements assez récents sur cette génération de console. Au début du hacking de la Wii, la diffusion d'informations était très peu contrôlée. La Team Twiizers (qui fait maintenant partie de fail0verflow) documentait tout, y compris des informations très bas niveau qui au final ne sont que très peu utiles pour un développeur de Homebrew (on peut dire ce qu'on veut, mais je ne vois pas pourquoi quelqu'un développant un jeu sur Wii aurait besoin de comprendre comment lire l'OTP de la console pour récupérer les clés, ou désactiver la protection du lecteur DVD pour faire lire des jeux commerciaux sans chiffrement). Des gens en ont profité pour sortir des tonnes d'utilitaires dont le but est uniquement de pouvoir pirater des jeux et y jouer sans avoir acheté l'oeuvre originale : USB Loader GX, Sneek, Dios Mios, et j'en passe. À cause de ça, les hackers passent pour des pirates, et les pirates passent pour des gens intelligents qui codent "ce que les hackers ont pas réussi à faire" (alors que c'était en fait par choix). Voir par exemple cet article de marcan (hacker Wii/PS3/WiiU) qui explique à quel point coder un de ces outils de warez est trivial, avec beaucoup de rage :)
Je prend l'exemple de la Wii parce que c'est ce que je connais le mieux (et ce qui est évoqué dans ce journal), mais c'est pareil partout : iPhone, PS3, Xbox 360, etc.
Récemment la WiiU est sortie, et je pense que cette fois ci les gens qui travaillent dessus ne font pas la même erreur : il n'y a actuellement pratiquement aucune information sur le fonctionnement interne de la console qui filtre hors du/des groupe(s) de hackers qui travaillent dessus, et j'ai de bonnes raisons de penser que cette fois-ci tout ce qui sera released pour l'utilisateur final sera encore obfusqué et ne permettra pas d'avoir accès au couches les plus basses de la console. Merci à la nature humaine pour toujours tout gâcher.
La carte graphique de la Gamecube ou de la Wii est limitée à une résolution de rendu très faible, de l'ordre de 640x480 pixels. Cependant, il est tout à fait possible d'utiliser les mêmes textures, modèles 3D, etc. et d'effectuer le rendu à une résolution plus élevée : là où on aurait normalement 20 ou 30 pixels qui représenteraient un objet, on pourra par exemple en avoir 100 ou 200.
En pratique, un exemple dans un jeu de Wii récent (Xenoblade Chronicles) :
En plus de cette amélioration, Dolphin supporte entre autre l'anti-aliasing, le filtrage anisotrope, ainsi que le chargement de textures personnalisées installées par l'utilisateur (des artistes travaillent sur des packs de textures haute résolution pour certains jeux, utilisables avec Dolphin).
On a encore un moment avant d'avoir des CPUs ARM assez puissants pour émuler un PPC à 800MHz :) Les A15 qui commencent à être disponibles sont encore environ 1.5x trop lents (en théorie) pour faire tourner les jeux les plus lights de la Gamecube (qui ne tourne qu'à 400MHz).
Un développeur travaille sur le support des devices ARM, et en plus des CPUs lents les GPUs intégrés aux SoC ne sont juste pas assez bons pour faire tourner les shaders que Dolphin utilise. On attend les premiers GPUs qui supporteront GLES3…
Si par recompilation tu entends recompilation statique, non. Concrétement, la recompilation statique ça fonctionne quand tu sais exactement faire la différence entre code et data, et que tu n'as pas de code auto-modifiant. Si tu as l'un de ces deux facteurs, faire de la recompilation statique devient pratiquement impossible.
Sur la Gamecube/Wii (ainsi que la plupart des plateformes, d'ailleurs), on a les deux : les jeux peuvent charger du code depuis le CD en mémoire, parfois en le décompressant/déchiffrant avant (donc en statique c'est mort) et on a en plus de ça du code auto-modifiant (par exemple, les jeux EA utilisent un outil propriétaire appelé ELFpacker qui décompresse l'exécutable du jeu à la volée).
Le JIT expérimental (JitIL) était effectivement une tentative de rendre le code recompilé plus rapide en passant par une layer intermédiare : au lieu de faire PPC -> X86 directement, on fait PPC -> IL -> X86, avec potentiellement des passes d'optimisation sur l'IL. Le problème c'est que la plupart des passes d'optimisation à faire sur l'IL ne sont pas triviales du tout à réaliser en gardant un comportement identique au code PPC original (à l'exception de quelques trucs basiques comme les peephole opts qui sont de toute façon déjà implémentée dans JIT64, le JIT par défaut). Du coup, JitIL n'a jamais vraiment été plus rapide que JIT64 - en x86 parfois il est un peu plus rapide car l'allocateur de registres est un peu plus intelligent (en x86_64 plus de registres sont dispos donc ça se voit moins).
Je pense que c'est une approche intéressante, mais sans réutiliser un backend d'optimisation commun à la LLVM ça risque de ne jamais vraiment aboutir. Le problème de LLVM pour un JIT dynamique comme celui là c'est que LLVM gère très mal l'invalidation de code JITé (en gros, on doit invalider tout le module et recompiler toutes les fonctions qui ont des branches statiques vers une fonction invalidée) comparé à ce qu'on peut faire à la main (juste remplacer comme un bourrin le code de l'ancienne fonction par la nouvelle). Si quelqu'un cherche un sujet de recherche intéressant, un backend "à la LLVM" de JIT pour l'émulation ça me semble être une idée à explorer.
Pas vraiment la même architecture non. On passe à un CPU multicore (3 coeurs, dont un qui a plus de privilèges que les autres), et à une carte graphique beaucoup plus complexe (pipeline programmable, comparé au pipeline fixe de la Wii).
Dolphin ne supportera certainement jamais la WiiU dans la même codebase. Après, il est probable que si un émulateur WiiU sorte des bouts de Dolphin seront réutilisés (exemple récent : le projet PPSSPP, émulateur PSP, réutilise une grosse partie des libs internes de Dolphin pour la génération de code x86 et la portabilité). C'est l'avantage du libre :)
C'est à peu près ça. Certains lecteurs LG permettent de les lire en hackant un peu car leur controlleur supporte des commandes de debug qui récupèrent les données optiques brutes du disque. Cet article parle en détail de comment c'est "sécurisé".
Parce qu'il ne se passe rien de très intéressant en ce moment hors des branches de développement, et que je ne vais pas faire un journal à chaque fois qu'on expérimente avec des idées. On a une release "mineure" dans le pipeline dans pas très longtemps, qui aurait éventuellement été plus propice à une dépêche.
Niveau Triforce, ça sera amélioré quand on aura des patches de gens qui savent comment ça marche. C'est le genre de matos qu'on n'a pas tous chez soi, donc c'est dur de tester correctement comment le hardware spécifique à cette borne d'arcade se comporte. L'intérêt est aussi assez faible IMHO, étant donné que le seul jeu original pour Triforce est a priori MKGP2 (le F-Zero pour Triforce est un port de GX sur Gamecube), du coup c'est assez peu prioritaire pour moi par rapport à d'autres trucs.
Par ailleurs, si des gens ont des questions sur Dolphin (utilisation ou fonctionnement interne), étant un des développeurs du projet (depuis environ 1 an et demi) je me ferais un plaisir d'y répondre :)
Ils peuvent supprimer le mot KISS du WIKI d'ArchLinux.
KISS != facile d'utilisation. La nouvelle procédure d'installation est bien plus simple que la précédente, au sens où il n'y a plus de magie masquée par les menus. Tout se fait encore en une dizaine de commandes, mais il faut savoir un minimum comment ça fonctionne derrière (ou avoir le wiki sous les yeux).
L'apparition de Store se rapproche aussi du concept de Apple, à savoir contrôler les applications disponibles au profit de la sécurité et au détriment de la liberté de choix, heureusement que les installations traditionnelles persistent.
Ah, un peu comme le package manager des distributions Linux ?
Et c'est le même Stefan Esser qui a dévoilé la faille critique dans PHP 5.3.9. Il a d'ailleurs posté récemment sur la liste php-internals pour donner encore une fois son avis sur la version PHP "upstream" : http://news.php.net/php.internals/57655
And that my dear readers is exactly what would happen to the code of Suhosin if it gets merged into PHP. It would be patched by people that do not know exactly what they are doing. And it would be broken.
Que dire des "haut-faits" qui suggèrent "battre un ennemi de " ? Faut-il à ce point assister le joueur dans son plaisir ? Ça me fait furieusement penser à des rires enregistrés.
Généralement la description des achievements de ce type est masquée et tu n'as donc pas moyen de savoir si tu ne vas pas regarder une liste/une soluce sur le net.
Par curiosité (même si ça une réponse positive ne justifierait pas le choix, pour les raisons ci-dessus), est-ce que le matos dont tu parles coûte plus cher au total que tes frais d'inscription globaux (sur toutes les années que tu y passes) pour cette école ?
Non, certainement pas quand même. Peut-être en y incluant le prix des locaux où je passe quand même pas mal de temps, mais ça serait tricher. Mais je vois pas ce que je ferais avec plus de matos que ça à vrai dire, là j'ai déjà de quoi m'occuper pour mes dernières années d'études :)
Je n'ai pas dit que le prix était justifié (ça me fait mal aux fesses aussi de payer aussi cher), juste qu'il n'y a aucune alternative qui me plaisait autant dans le public et que contrairement à ce que tu penses tout le monde ne regrette pas ce choix d'aller dans le privé et de payer plus cher.
Parce que les bons sont faits pour aller dans le public et c'est forcément une erreur de faire le choix d'aller dans une école privée ? C'est pas un préjugé ça ?
Il y a des avantages qu'ont les écoles privées que les écoles publiques n'ont simplement pas. Je n'avais pas envie de faire une prépa généraliste parce que ça ne m'intéressait pas de perdre deux ans à faire des maths/de la physique à longueur de journée, ni de faire une fac parce que les possibilités pour faire des trucs cools me semblaient plus limitées.
Là ma rentrée est dans deux semaines, je vais passer ma nuit (c'est à dire jusque demain 8h) avec des amis dans les locaux de l'école à bosser sur du matériel marrant qui a été financé par EPITA (une board SMP ARM pour faire du kernel dev, une board avec un Spartan 6 pour faire joujou avec du Verilog). Tout ça sur une machine convenable (i.e. core 2 quad, carte graphique, grands écrans, au pluriel) avec des gens avec qui je n'aurais certainement pas eu l'occasion de travailler si je n'étais pas dans cette école. Donc oui, effectivement, je paie mon année assez cher par rapport à des frais d'inscription en fac, mais je ne pense pas que ça soit totalement gâché.
Tu sais qu'EPITECH a 2 ou 3x plus de piscines qu'EPITA, et qu'elles commencent dès la première année d'études contrairement à EPITA qui délaie jusqu'à BAC+3 ?
Dans toutes les écoles tu peux citer une minorité de bons et une très grosse majorité de mauvais. Je connais aussi des gens qui sont sortis d'EPITECH il y a 2 ans et qui sont maintenant chez Google ou VMware.
Un jour les gens en France arrêteront de juger du niveau des gens selon l'école d'où ils sortent. En informatique, ça veut rarement dire quoi que ce soit.
[^] # Re: et ca compile ?
Posté par Pierre Bourdon . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 6.
À vrai dire ils utilisent des fonctions non standard comme funopen, donc non, ils ne supportent pas tout ce qui supporte POSIX proprement. Ils supportent OpenBSD et rien d'autre.
Et non, ça n'est pas si facile de supporter Visual Studio, ou OpenVMS, ou autre OS non POSIX. OpenSSL le faisait pourtant, et c'est certainement une des raisons pour laquelle presque tout est basé sur OpenSSL. Mais j'imagine que c'est plus facile pour les développeurs d'OpenBSD de chier publiquement sur les couches de compatibilité d'OpenSSL (voire même de se moquer de certaines features comme le support d'OpenVMS) que d'essayer d'implémenter la même chose proprement.
[^] # Re: Opinion d'un développeur d'exploit pour Wii
Posté par Pierre Bourdon . En réponse au journal Nintendo, hackers and sourcecode. Évalué à 10.
Tu vois le monde en noir et blanc, en ignorant les nuances entre les deux. Si tu penses que les gens qui font en sorte de pouvoir développer sur du matériel que tu as acheté sont aussi "noir" que les gens qui permettent de télécharger illégalement et sans rémunération de l'auteur des logiciels normalement vendus pour un prix, je pense que je n'ai rien de plus à te dire.
Oh, et pour ton information : la Wii n'a pas d'EULA à accepter avant utilisation de la console, sauf pour les services en ligne. Je n'ai jamais accepté un seul EULA sur ma console.
[^] # Re: mode parano
Posté par Pierre Bourdon . En réponse au journal Nintendo, hackers and sourcecode. Évalué à 1.
C'est une attaque utilisable uniquement avec accès hardware à la console (il faut insérer une carte SD).
[^] # Re: Désactivation des protections
Posté par Pierre Bourdon . En réponse au journal Nintendo, hackers and sourcecode. Évalué à 8.
C'est déjà faisable sans accès à l'OTP et sans autoriser la lecture de DVDs arbitraires non chiffrés sur la console : il suffit d'utiliser les fonctions de lecture de disque proposées par l'OS de Nintendo qui tourne sur la Wii.
Et très honnêtement, le nombre de gens qui dumpent vraiment leurs jeux depuis leurs DVDs au lieu de les télécharger est infime. Sans statistique exacte, je dirais moins de 2 ou 3% des utilisateurs d'émulateurs.
PS: Je suis un des core developers de l'émulateur Dolphin, dont parle le journal que tu cites.
# Opinion d'un développeur d'exploit pour Wii
Posté par Pierre Bourdon . En réponse au journal Nintendo, hackers and sourcecode. Évalué à 10.
Il y a deux raisons pour lesquelles les gens ont arrêté de release leurs exploits. La première, c'est de rendre plus difficile la correction des failles sur lesquelles les exploits se basent : plus l'exploit est "camouflé", le plus longtemps il sera valide et utilisable. La deuxième, c'est de rendre plus difficile l'utilisation des informations sur le fonctionnement interne des consoles par les gens qui développent des outils de warez.
Je m'étonne que tu relèves la non liberté de l'outil qui fournit le fichier "corrompu" causant l'exploit sans relever la non liberté du Hackmii Installer, qui est après tout le payload de l'exploit, et qui lui fait tout le travail intéressant pour installer le Homebrew Channel sur ta console. En plus de ne pas être libre, il est protégé par de nombreuses couches d'obfuscation afin de masquer la faille qui a été utilisée. C'est pour les mêmes raisons.
Cette deuxième raison, cacher des informations sur le fonctionnement de la console, est malheureusement due à des développements assez récents sur cette génération de console. Au début du hacking de la Wii, la diffusion d'informations était très peu contrôlée. La Team Twiizers (qui fait maintenant partie de fail0verflow) documentait tout, y compris des informations très bas niveau qui au final ne sont que très peu utiles pour un développeur de Homebrew (on peut dire ce qu'on veut, mais je ne vois pas pourquoi quelqu'un développant un jeu sur Wii aurait besoin de comprendre comment lire l'OTP de la console pour récupérer les clés, ou désactiver la protection du lecteur DVD pour faire lire des jeux commerciaux sans chiffrement). Des gens en ont profité pour sortir des tonnes d'utilitaires dont le but est uniquement de pouvoir pirater des jeux et y jouer sans avoir acheté l'oeuvre originale : USB Loader GX, Sneek, Dios Mios, et j'en passe. À cause de ça, les hackers passent pour des pirates, et les pirates passent pour des gens intelligents qui codent "ce que les hackers ont pas réussi à faire" (alors que c'était en fait par choix). Voir par exemple cet article de marcan (hacker Wii/PS3/WiiU) qui explique à quel point coder un de ces outils de warez est trivial, avec beaucoup de rage :)
Je prend l'exemple de la Wii parce que c'est ce que je connais le mieux (et ce qui est évoqué dans ce journal), mais c'est pareil partout : iPhone, PS3, Xbox 360, etc.
Récemment la WiiU est sortie, et je pense que cette fois ci les gens qui travaillent dessus ne font pas la même erreur : il n'y a actuellement pratiquement aucune information sur le fonctionnement interne de la console qui filtre hors du/des groupe(s) de hackers qui travaillent dessus, et j'ai de bonnes raisons de penser que cette fois-ci tout ce qui sera released pour l'utilisateur final sera encore obfusqué et ne permettra pas d'avoir accès au couches les plus basses de la console. Merci à la nature humaine pour toujours tout gâcher.
[^] # Re: Amélioration vidéo
Posté par Pierre Bourdon . En réponse à la dépêche L'émulateur Dolphin sort en version 3.5. Évalué à 10.
La carte graphique de la Gamecube ou de la Wii est limitée à une résolution de rendu très faible, de l'ordre de 640x480 pixels. Cependant, il est tout à fait possible d'utiliser les mêmes textures, modèles 3D, etc. et d'effectuer le rendu à une résolution plus élevée : là où on aurait normalement 20 ou 30 pixels qui représenteraient un objet, on pourra par exemple en avoir 100 ou 200.
En pratique, un exemple dans un jeu de Wii récent (Xenoblade Chronicles) :
En plus de cette amélioration, Dolphin supporte entre autre l'anti-aliasing, le filtrage anisotrope, ainsi que le chargement de textures personnalisées installées par l'utilisateur (des artistes travaillent sur des packs de textures haute résolution pour certains jeux, utilisables avec Dolphin).
[^] # Re: Dolphin, etc.
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 2.
On a encore un moment avant d'avoir des CPUs ARM assez puissants pour émuler un PPC à 800MHz :) Les A15 qui commencent à être disponibles sont encore environ 1.5x trop lents (en théorie) pour faire tourner les jeux les plus lights de la Gamecube (qui ne tourne qu'à 400MHz).
Un développeur travaille sur le support des devices ARM, et en plus des CPUs lents les GPUs intégrés aux SoC ne sont juste pas assez bons pour faire tourner les shaders que Dolphin utilise. On attend les premiers GPUs qui supporteront GLES3…
[^] # Re: Dolphin, etc.
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 6.
Si par recompilation tu entends recompilation statique, non. Concrétement, la recompilation statique ça fonctionne quand tu sais exactement faire la différence entre code et data, et que tu n'as pas de code auto-modifiant. Si tu as l'un de ces deux facteurs, faire de la recompilation statique devient pratiquement impossible.
Sur la Gamecube/Wii (ainsi que la plupart des plateformes, d'ailleurs), on a les deux : les jeux peuvent charger du code depuis le CD en mémoire, parfois en le décompressant/déchiffrant avant (donc en statique c'est mort) et on a en plus de ça du code auto-modifiant (par exemple, les jeux EA utilisent un outil propriétaire appelé ELFpacker qui décompresse l'exécutable du jeu à la volée).
[^] # Re: Dolphin, etc.
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 4.
Le JIT expérimental (JitIL) était effectivement une tentative de rendre le code recompilé plus rapide en passant par une layer intermédiare : au lieu de faire PPC -> X86 directement, on fait PPC -> IL -> X86, avec potentiellement des passes d'optimisation sur l'IL. Le problème c'est que la plupart des passes d'optimisation à faire sur l'IL ne sont pas triviales du tout à réaliser en gardant un comportement identique au code PPC original (à l'exception de quelques trucs basiques comme les peephole opts qui sont de toute façon déjà implémentée dans JIT64, le JIT par défaut). Du coup, JitIL n'a jamais vraiment été plus rapide que JIT64 - en x86 parfois il est un peu plus rapide car l'allocateur de registres est un peu plus intelligent (en x86_64 plus de registres sont dispos donc ça se voit moins).
Je pense que c'est une approche intéressante, mais sans réutiliser un backend d'optimisation commun à la LLVM ça risque de ne jamais vraiment aboutir. Le problème de LLVM pour un JIT dynamique comme celui là c'est que LLVM gère très mal l'invalidation de code JITé (en gros, on doit invalider tout le module et recompiler toutes les fonctions qui ont des branches statiques vers une fonction invalidée) comparé à ce qu'on peut faire à la main (juste remplacer comme un bourrin le code de l'ancienne fonction par la nouvelle). Si quelqu'un cherche un sujet de recherche intéressant, un backend "à la LLVM" de JIT pour l'émulation ça me semble être une idée à explorer.
[^] # Re: dolphins
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 6.
Pas vraiment la même architecture non. On passe à un CPU multicore (3 coeurs, dont un qui a plus de privilèges que les autres), et à une carte graphique beaucoup plus complexe (pipeline programmable, comparé au pipeline fixe de la Wii).
Dolphin ne supportera certainement jamais la WiiU dans la même codebase. Après, il est probable que si un émulateur WiiU sorte des bouts de Dolphin seront réutilisés (exemple récent : le projet PPSSPP, émulateur PSP, réutilise une grosse partie des libs internes de Dolphin pour la génération de code x86 et la portabilité). C'est l'avantage du libre :)
[^] # Re: Quid des jeux ?
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 3.
C'est à peu près ça. Certains lecteurs LG permettent de les lire en hackant un peu car leur controlleur supporte des commandes de debug qui récupèrent les données optiques brutes du disque. Cet article parle en détail de comment c'est "sécurisé".
[^] # Re: Dolphin, etc.
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 2.
Parce qu'il ne se passe rien de très intéressant en ce moment hors des branches de développement, et que je ne vais pas faire un journal à chaque fois qu'on expérimente avec des idées. On a une release "mineure" dans le pipeline dans pas très longtemps, qui aurait éventuellement été plus propice à une dépêche.
Niveau Triforce, ça sera amélioré quand on aura des patches de gens qui savent comment ça marche. C'est le genre de matos qu'on n'a pas tous chez soi, donc c'est dur de tester correctement comment le hardware spécifique à cette borne d'arcade se comporte. L'intérêt est aussi assez faible IMHO, étant donné que le seul jeu original pour Triforce est a priori MKGP2 (le F-Zero pour Triforce est un port de GX sur Gamecube), du coup c'est assez peu prioritaire pour moi par rapport à d'autres trucs.
# Dolphin, etc.
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 9.
Par ailleurs, si des gens ont des questions sur Dolphin (utilisation ou fonctionnement interne), étant un des développeurs du projet (depuis environ 1 an et demi) je me ferais un plaisir d'y répondre :)
[^] # Re: dolphins
Posté par Pierre Bourdon . En réponse au journal Les jeux de BigN sous Linux. Évalué à 4.
Ce Dolphin là date de 2003, soit bien avant celui de KDE. Le nom est en fait le nom de code original de la Gamecube.
[^] # Re: AIF abandonné ?
Posté par Pierre Bourdon . En réponse à la dépêche Une nouvelle image d'installation pour Archlinux (2012.07.15) est disponible. Évalué à 6.
KISS != facile d'utilisation. La nouvelle procédure d'installation est bien plus simple que la précédente, au sens où il n'y a plus de magie masquée par les menus. Tout se fait encore en une dizaine de commandes, mais il faut savoir un minimum comment ça fonctionne derrière (ou avoir le wiki sous les yeux).
# Package manager
Posté par Pierre Bourdon . En réponse au journal Commentaires sur Windows 8 béta. Évalué à 10.
Ah, un peu comme le package manager des distributions Linux ?
[^] # Re: Mouarf
Posté par Pierre Bourdon . En réponse au journal Michael Simms se barre de LGP et se fait remplacer par Clive Crous. Évalué à 3.
Pour les vieux jeux pas cher*
[^] # Re: Encore et toujours...
Posté par Pierre Bourdon . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 9.
Et c'est le même Stefan Esser qui a dévoilé la faille critique dans PHP 5.3.9. Il a d'ailleurs posté récemment sur la liste php-internals pour donner encore une fois son avis sur la version PHP "upstream" : http://news.php.net/php.internals/57655
[^] # Re: "Achievements"
Posté par Pierre Bourdon . En réponse au journal Microsoft Visual Studio Achievements. Évalué à 1.
Généralement la description des achievements de ce type est masquée et tu n'as donc pas moyen de savoir si tu ne vas pas regarder une liste/une soluce sur le net.
[^] # Re: Ah, ce bon viel intra !
Posté par Pierre Bourdon . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 2.
Non, certainement pas quand même. Peut-être en y incluant le prix des locaux où je passe quand même pas mal de temps, mais ça serait tricher. Mais je vois pas ce que je ferais avec plus de matos que ça à vrai dire, là j'ai déjà de quoi m'occuper pour mes dernières années d'études :)
Je n'ai pas dit que le prix était justifié (ça me fait mal aux fesses aussi de payer aussi cher), juste qu'il n'y a aucune alternative qui me plaisait autant dans le public et que contrairement à ce que tu penses tout le monde ne regrette pas ce choix d'aller dans le privé et de payer plus cher.
[^] # Re: Ah, ce bon viel intra !
Posté par Pierre Bourdon . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 1.
Parce que les bons sont faits pour aller dans le public et c'est forcément une erreur de faire le choix d'aller dans une école privée ? C'est pas un préjugé ça ?
Il y a des avantages qu'ont les écoles privées que les écoles publiques n'ont simplement pas. Je n'avais pas envie de faire une prépa généraliste parce que ça ne m'intéressait pas de perdre deux ans à faire des maths/de la physique à longueur de journée, ni de faire une fac parce que les possibilités pour faire des trucs cools me semblaient plus limitées.
Là ma rentrée est dans deux semaines, je vais passer ma nuit (c'est à dire jusque demain 8h) avec des amis dans les locaux de l'école à bosser sur du matériel marrant qui a été financé par EPITA (une board SMP ARM pour faire du kernel dev, une board avec un Spartan 6 pour faire joujou avec du Verilog). Tout ça sur une machine convenable (i.e. core 2 quad, carte graphique, grands écrans, au pluriel) avec des gens avec qui je n'aurais certainement pas eu l'occasion de travailler si je n'étais pas dans cette école. Donc oui, effectivement, je paie mon année assez cher par rapport à des frais d'inscription en fac, mais je ne pense pas que ça soit totalement gâché.
[^] # Re: trolldi est arrivé
Posté par Pierre Bourdon . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 0.
Tu sais qu'EPITECH a 2 ou 3x plus de piscines qu'EPITA, et qu'elles commencent dès la première année d'études contrairement à EPITA qui délaie jusqu'à BAC+3 ?
[^] # Re: Ah, ce bon viel intra !
Posté par Pierre Bourdon . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 5.
En quoi la formation d'un EPITECH le rend moins apte à s'adapter aux nouvelles technologies que quelqu'un qui sort d'une autre école ?
[^] # Re: Ah, ce bon viel intra !
Posté par Pierre Bourdon . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 10.
Dans toutes les écoles tu peux citer une minorité de bons et une très grosse majorité de mauvais. Je connais aussi des gens qui sont sortis d'EPITECH il y a 2 ans et qui sont maintenant chez Google ou VMware.
Un jour les gens en France arrêteront de juger du niveau des gens selon l'école d'où ils sortent. En informatique, ça veut rarement dire quoi que ce soit.
[^] # Re: Le pire
Posté par Pierre Bourdon . En réponse au journal 82 millions d'euros pour 200 caméras.... Évalué à 1.
Pas de baisse de la criminalité associée ? Ça me paraîtrait logique qu'il y ait une certaine dissuasion.