Pas mal ... J'ai fini Beginner et Intermediate.

Hamlet ? Trop facile

Moi je teste ma virilité sur ça

http://regexcrossword.com/playerpuzzles/638abba5-5cfa-430c-b26a-33d1f4f42dab

Bouh un codec non-libre.

http://www.openbsd.org/songs/song57.ogg *

Pourquoi avoir un IDE quand on peut avoir des cartes percées ?

Touché . Tu utilises un IDE ?

http://x86asm.net/articles/uefi-programming-first-steps/index.html#UEFI-Programming-with-FASM
http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/index.html

A quand un bon rootkit efficace dans l'UEFI ? /

Kernel bientot je souhaiterais me mettre à l'assembleur, pourrait tu m'aiguiller j'ai quelque questions à poser

Ah cool, comment puis-je t'aider ?

L'assembleur c'est bien le langage du microprocesseur ?
Et c'est quoi le rôle du microprocesseur pour le processeur ?

Quel assembleur apprendre, lequel est le plus compatible avec le plus d'architecture ?
L'assembleur manipule directement la pile ?
Dans des architectures différente de procésseur, quesqui change, quelles est la différence entre les architectures ?
L'organisation de la pile d'éxécution d'un programme change ?

Processeur / microprocesseur c'pareil.
Oui l'assembleur c'est le nom d'un langage qui manipule des instructions du jeu d'instruction (ISA) d'un processeur. (Le mot "assembleur" fait aussi référence au programme qui assemble le code)

A chaque fois que t'as un jeu d'instructions différent t'as un asm différent, si tu veux coder sur PC apprends l'assembleur x86 (qui est l'architecture intel 32 bit) pour commencer, la plupart des pc actuels utiliseront cette archi (ou amd64 pour les CPU 64bits, mais ton code x86 devrait tourner sur cette archi aussi)

Oui, tu peux manipuler les registres du CPU qui contrôlent la pile (esp, ebp.. par exemple sur x86).

Ce qui change d'une archi à l'autre, bah théoriquement tout peut changer, oui t'as la gestion de la pile par exemple, le lien avec la mémoire est aussi différent (RISC / CISC, dans le premier tu manipules les registres et tu fais les opérations sur la mémoire avec des load/store, dans le second tu peux faire des opérations directement sur la mémoire, les archis intel sont CISC, ARM par exemple c'est du RISC -> l'archi est beaucoup plus simple au final) après bah l'archi en elle-même est différente, y a différentes fonctionnalités techniques qui seront pas les mêmes, comme le pipeline, le cache, le parallèlisme..
Par exemple sur les GPU de nVidia, tu remarques qu'une d'une archi à l'autre y a des caches qui sont unifiés (entre autres modifications) en réorganisant d'autre partie de la mémoire en conséquence..

Si tu te mets à apprendre l'assembleur ça te permettra de comprendre un peu mieux le fonctionnement d'un cpu, et comment on gère la mémoire. Un autre moyen très efficace de rentrer un peu dans le domaine c'est décrire un émulateur pour un vieux processeur 8-bit.

Les archis de cpu aujourd'hui sont hyper compliquées, y a des manuels qui les détaillent un peu disponibles sur les sites d'Intel et Amd, pour apprendre l'archi des cpu en général bah tu peux essayer de trouver des bouquins généraux sur ça.

Le 01 mai 2015 à 15:05:12 kernel[] a écrit :
http://x86asm.net/articles/uefi-programming-first-steps/index.html#UEFI-Programming-with-FASM
http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/index.html

A quand un bon rootkit efficace dans l'UEFI ? /

J'ai tellement hâte, t'imagines pas

Hmm la dernière fois que j'ai fait ça il me semble que dd marchait, en mettant un MBR Windows sur la clé à l'aide de ms-sys après le dd.

La chanson de la nouvelle release d'OpenBSD

C'est possible de développer une bibliothèque 3d entièrement en assembleur facilement ( jdéconne )

Mais quand tu fais de l'assembleur, tu manipule constamment la pile pour faire des opérations non ?
Si c'est ça j'apprend l'assembleur easy, je manipulais la pile de certain processus en C++ et tout comme un grand
Je vais juste devoir bosser sur l'architecture du proco amd64, et sur les registres car je sais même pas c'est quoi un registre

Bref merci de ton aide kernel, je t'inviterais peut-être à manger un morceau de gateau au chocolat un jour

Ouais, bah basiquement disons que t'as pas vraiment de fonctions au sens habituel de la programmation, mais tu peux controler le flot d'instructions via des instructions (call / jmp) et pour passer des arguments tu utilises la pile (tu push les arguments sur la pile, tu sautes au code de la fontion, et tu pop la pile pour recevoir les arguments passés)
T'as qu'à essayer de prendre un programme très simple en C et de regarder la sortie assembleur de gcc (en désactivant l'opti sinon c'est incompréhensible) pour voir ce qu'il se passe.

Tu peux manipuler la pile de ton processus en C/C++ via des commandes asm, mais il vaut mieux pas faire n'importe quoi. (Olol je fais de l'assembleur et j'oublie que je suis dans une fonction C et que le compilo va rajouter du code autour du mien..)
Et t'es pas censé pouvoir accéder à la mémoire d'un processus distant car l'os protège la mémoire de chaque processus. (Sauf si bien-sûr par un moyen ou un autre tu pouvais utiliser certaines fonctions pour rendre de la mémoire exécutable à distance, injecter du code et l'exécuter, mais chut. )

Yoshey Oui c'est possible.

Gnome 3 vient avec le serveur de son PulseAudio qui permet de faire ça.

Il faut passer par le logiciel pavucontrol pour pouvoir contrôler les volumes audio comme tu le souhaites.

Bon à part ça PA c'est quand même une grosse bouse. Y a néanmoins moyen de faire ça avec ALSA, mais c'est plus compliqué.

Ya des jours où je regrette qu'on n'ait pas un équivalent bénéfique de Lennart Poettering dans la commu GNU/Linux. Un mec qui prendrait les vrais problèmes à part un par un et nous pondrait une jolie solution qui respecte la philosophie, sans tourner au bloatware complètement.

Alors OK, c'est exactement ce que Lennart prétend faire. Sauf que soyons honnêtes, les trois quarts des problèmes il les invente, et ses solutions sortent complètment du scope.
J'ai jamais demandé à Avahi de raconter la vie de ma machine à tout le réseau.
J'ai jamais demandé à PulseAudio de faire du "streaming audio réseau [...]" (je veux dire, c'est pas comme si des solutions existaient déjà pour ça avant, et fonctionnaient à merveille).
J'ai jamais demandé à systemd de gérer le firewall, réchauffer les restes de la veille ni repasser mon linge (mais je voudrais bien un outil standalone pour chaque tâche).

Le 02 mai 2015 à 02:00:34 Google_Bot a écrit :
Ya des jours où je regrette qu'on n'ait pas un équivalent bénéfique de Lennart Poettering dans la commu GNU/Linux. Un mec qui prendrait les vrais problèmes à part un par un et nous pondrait une jolie solution qui respecte la philosophie, sans tourner au bloatware complètement.

Alors OK, c'est exactement ce que Lennart prétend faire. Sauf que soyons honnêtes, les trois quarts des problèmes il les invente, et ses solutions sortent complètment du scope.
J'ai jamais demandé à Avahi de raconter la vie de ma machine à tout le réseau.
J'ai jamais demandé à PulseAudio de faire du "streaming audio réseau [...]" (je veux dire, c'est pas comme si des solutions existaient déjà pour ça avant, et fonctionnaient à merveille).
J'ai jamais demandé à systemd de gérer le firewall, réchauffer les restes de la veille ni repasser mon linge (mais je voudrais bien un outil standalone pour chaque tâche).

Il n'y a que les incapables qui ont un esprit sain. C'est toujours les malades qui font le boulot

Bah, non. Je veux dire quand Linus a débarqué dans le paysage des SCM, c'était pas la joie... et Git a répondu à pas mal de problématiques. Pareil pour les mecs d'OpenBSD avec leurs outils "phares", etc.
Non, Lennart c'est un cas à part, le problème c'est qu'il espère être considéré comme un héros au même titre que ceux qui font des choses vraiment utiles.