In this channel you will mainly find videos related to the UNIX/BSD/Linux world. I am a UNIX user & lover since 1995 and I intend to spread the love for the most amazing Operating System ever conceived through this media.
I really enjoy doing those videos and would truly love them to provide enough revenue to free me some time and work on them in a more regular basis, so if you want to help, here's my Patreon page www.patreon.com/imil
Commencé Linux avec MiniLinux sur 4 dskt avec XFree récupéré sur un BBS nordiste (1992). Après c'est Yggdrasyl sur CD en 94. Jeune à l'époque je suis de 64 !
A cette époque, j'avais un 486, un disque dur de 120 Mo et 8Mo de ram, 1 lecteur de cd, 2 lecteurs 3"1/2. Bref que du bonheur. 😂 Le seul poinr noir, je ne savais pas que linux existait 😭😭😭😭😭😭😭😭😭😭😭😭😭😭
L halgortyme a le rhume encore une fois . Comme une fois elle ma fait une suggestion d'une partie de baseball korenne de 1991 ...je vais liker et m abonner non obstant of course😂
hello ! je decouvre ta chaine ! je suis aussi posseceur de smb orangepi 5 plus en 16G de ram. j'ai aussi une eMMC, par contre impossible de booter dessus !!! as tu un tuto de comment tu as fait ? merci.
@emileimilheitor3456 il faut que l'on cause de l'architecture CPU bug.littke d'ARM qui permet de mélanger les cœurs basse consommation 'A55 et haute performance : A76. Intel a copié le principe. Pour l'augmentation des prix chez AliExpress, c'est impressionnant depuis 15 jours. Je n'ai pas non plus la raison de cette explosion des prix. Le NanoKVM se mange presque 20€ d'augmentation.
Merci pour tes vidéos, la série est passionnante. Petite question, pour compiler une kernel 1.2.13 on ne peut pas se servir du /live de l'iso slackware vu qu'il faut passer à qemu le -kernel ? Comment tu avais fait pour le compiler du coup ? J'ai rebalayé les autres épisodes j'ai pas retrouvé l'explication.
Merci pour le com' ! Alors la série date un peu mais si je me souviens bien j'avais installé une slack complète dans une vm, et je crois me souvenir que j'avais fait ça de façon peu orthodoxe et l'avoir expliqué dans un des eps... mais lequel la comme ça je sais plus ^^" De mémoire j'avais untar les archives comme un gros sale dans le disque virtuel mounté sur le host.
Émile, tu es investi d'une mission, et tu l'accomplis putaraillassement bien! Merci mil et mil fois! Je kiffe grave (comme on dit aujourd'hui) toutes ces vidéos, j'écris ma RAM en binaire pour vérifier que je pige bien chaque morceau (each bit, héhé...). Comme dit le dicton: «Émile, il en vaut mille!»
Je suis pris d'un grand trouble... Afin de piger ce qui se passe, je me suis "amusé" à écrire tous les 1 et 0 de la RAM, sur autant de bits qu'en comporte la plage [esp; ebp] durant l'exécution de main(). Je me suis gourré une première fois, car j'avais écrit les bits dans l'ordre "naturel"; or je compile sur une architecture AMD 64, donc en petit-boutiste. Je me suis rendu compte de ma gourrance. J'ai recommencé, ça allait mieux, c'était lors des vidéos précédentes. Mais là, il me semble que gef montre les valeurs en gros-boutiste, je suis un peu paumé... Dans le dernier exemple, après avoir fait la transcription du mensonge int i = 10; , à savoir: mov DWORD PTR [ebp-0x8], 0xa , je m'attends à trouver à l'adresse ebp-0x8 la valeur, en petit-boutiste (en insérant une espace tous les 8 caractères représentant les bits): 00001010 00000000 00000000 00000000 Or c'est ceci que je vois dans le débogueur: gef➤ x/t $ebp-8 0xffffd0e0: 00000000000000000000000000001010 Et là, je me sens un peu perdu...
J'aime tes vidéos. Tu vas vraiment dans les détails. Si tu les republiais au format long tutoriel sans le chat mais en répondant aux questions sur une plateforme comme Udemy ou autre, je les achèterais sûrement !
Allons lance Mistral Gagnant ! ... et un petit coup de Llama 3 gradient ... et tu te prends une volée de mots ... a te faire retourner ton cerveau ! Mistral Gagnant ... {note de piano}
Merci mil et mil fois, iMil, pour tant de pédagogie, tant de patience. Je n'ai pas tenu 1h53, très loin s'en faut. J'ai tenu beaucoup plus... Cela m'a pris de 2024_05_01__12_02_23 à 2024_05_06__12_45_34, soit 5 jours, mais pas sans interruption (tout de même)! Pour aller plus vite, j'écoute en 1,5x ou 1,75x, mais comme j'arrête pas de revenir en arrière, et de pauser pour jongler avec mon lldb et mon vim, eh bé voilà, ça prend du temps... Au final, j'arrive à ça comme image de la RAM, avec le basepointer tout à droite: 11111111111111111101000100111100011001100110111101110101000000000000000000000100000000000000000000000000000000000000000000000000 C'est bon, je me suis pas trop gourré? Oui, oui, je me suis fait ch!er, mais j'ai adoré, au moins j'ai tout pigé (enfin, je crois) aux mensonges! Je regrette de n'avoir pas fait plus d'assembleur, du temps où j'avais taquiné ça, sur mon ZX81...
Hello, Toujours content de mater le replay des sessions "hard system". Si tu vires tout l'output intermédiaire tu dois pouvoir faire baisser la durée de boot encore.
Elle est très bien cette émission. Ici, on n'est pas dans le déroulement d'un tuto que l'on défile de manière 'abrutissante' sans chercher à comprendre ce que l'on fait et qui pourrait nous donner de fausses ambitions, celles d'être des cadors de Linux From Scratch' ou de Gentoo, par exemple. Le principe de la décomposition des choses en les explicitant est tres fécond car on apprend à comprendre au travers de vos explications très pédagogiques. Par conséquent, un grand merci pour cette manière de faire, qui va au cœur des choses, et qui porte des fruits.
XEN, que de souvenir avec sa paravirtualisation et le bordel des noyaux Linux spécifique. Avoir une Debian en Dom0 et un guest (DomU) RedHat devant tourner avec un kernel plus proche du monde Debian que RedHat. Pour la partie visualisation hardware dans les CPU Intel : VMX ou Intel VT-x AMD : SVM ou AMD-V Après, on a eu d'autres ajouts permettant des accès directs du matériel par les VM géré par le Dom0. Le fameux passthrough. XEN a bien changé depuis 10 ans. AWS a basculé sur qemu/kvm depuis 2019 mais il reste encore pas mal de XEN Pour XEN, le mode PVHVM est vraiment une tuerie en perf face au PV. Il y a un article de Xen Orchestra sur le sujet, mais je ne peux pas mettre le lien, RU-vid interdit les liens dans les commentaires.
Ces explications sur la virtualisation en font - avis très personnel - le meilleur épisode de cette excellente série qui nous fait découvrir NetBSD, (d'une faço inhabituelle : à partir du code du noyau, pour lui faire d'abord un régime minceur).
C'est très intéressant tout ça, et après avoir vu les 2 premières vidéos de la série, je suis sûr d'aller au bout. BSD me rappelle mes années d'étudiants sur machines Sun encore sous BSD (SunOS 3 & 4, + X11R3, X11R4 et X11R5, + TWM très personnalisé), à une époque où l'offre commerciale de Sun venait de basculer sur le récent Unix SVR4 d'AT&T, sous le nom de Solaris 2/SunOS 5, que j'ai aussi utilisé pendant 2 mois à l'époque. Il y a le seul défaut classique des BSDistes dans cette vidéo : l'incapacité d'admettre que les *BSD exigent des compétences d'informaticien pour être utilisé. Il est impossible que ma petite sœur - infirmière diplômée - ne parvienne jamais à utiliser ce truc, elle qui a déjà galéré quand elle a dû apprendre à 42 ans à utiliser Windows et PowerPoint pour préparer une sélection professionnelle... Tous les jours, elle utilisait pourtant un truc à base de noyau BSD, mais c'était son iPhone où Apple a noyé ce morceau de BSD dans un environnement que même ma mère qui n'a pas son certificat d'études arrivait à utiliser. Je suis désolé, mais il faut arrêter de s'aveugler : NetBSD, OpenBSD, FreeBSD, Dragonfly BSD, et tous les forks ou dérivés qui s'en revendiquent, et la plupart des distributions Linux, ne sont accessibles qu'à des gens comme nous, qui s'y connaissent au moins un peu en shell Unix et en compilation de code C. Donc uniquement à des informaticiens - et pas tous encore ! J'en connais qui après des décennies de développement sur mainframes ont toujours besoin en 2023 d'assistance sous Windows... qu'ils l'utilisent pourtant depuis 25 ans (quand on a remplacé leurs vieux terminaux passifs par des émulateurs et qu'on leur a installé un vrai logiciel de messagerie). Inutile de vous dire comme ils sont déconcertés devant Ubuntu. Les distributions Linux tiennent effectivement plus de bazars (Eric S. Raymond a même théorisé que c'était là toute la force du logiciel libre). Mais ça a toujours été un peu le cas d'Unix. La "cohérence" trouve ses limites dès la ligne de commande : on ne peut pas ne pas remarquer que les options des commandes de bases en sont dépourvues (les sens de "-r", "-i", "-l", "-f", "-e", "-x", "-o"... dépendent des commandes - la faute à vouloir exprimer du sens avec des "mots" significatifs d'une seule lettre...). Unix en général est un truc conçu par des informaticiens pour eux-mêmes, sans aucune considération de facilité d'utilisation, même pour eux-mêmes, sans parler des utilisateurs finaux... J'ai connu des systèmes d'exploitation de mainframes autrement plus conviviaux (malheureusement toujours propriétaire) - et d'ailleurs aussi mieux construits qu'Unix (car mieux inspirés de Multics). Les BSDistes ne cessent de vanter la qualité de leur code et de leur doc, mais conservent pourtant eux aussi les incohérences d'Unix dans l'expérience utilisateur, pour ne pas changer les habitudes - exactement pour la même raison qu'on continue à utiliser, selon les pays, des claviers QWERTY, AZERTY, QWERTZ etc., dont l'aménagement des touches date d'un temps où il fallait limiter la vitesse de frappe pour que les marteaux des machines à écrire mécaniques ne se coincent pas (ce qui ne tient plus la route depuis plus de 33 ans).
Hello, je veux reproduire ce que tu nous montres dans cette vidéo mais impossible de mettre la main sur le kernel sur les miroirs slackware. Merci pour cette vidéo où j’ai compris pas mal de choses qui pour l’instant n’étaient pas très clair.merci pour tes videos
Hello @Farfad! il me semble que dans les épisodes suivants je donne les liens vers une iso, mais le voici archive.org/download/Slackware_Linux_3.0_Walnut_Creek_October_1995
00:00 Intro part 1 13:10 la relique 17:50 Intro part 2 18:40 L'origine du sujet 21:25 Ce qui a été fait 22:20 Objectif général 25:30 Le problème de Docker 29:20 Sujet de la soirée 32:20 Plus d'info sur le challenge 33:40 Step 1. : écriture d'une image disque vide 43:00 Step 2. : Création du filesystem 46:58 Step 3. : Mount de l'image en loopback 50:50 Step 4. : lost&found 54:00 Introduction busybox 55:00 Explications de busybox 57:40 Folder /rescue: kesaco ? 59:00 crunchgen: kesaco ? 1:08:30 NetBSD init function 1:13:26 Step 5. : rc file 1:15:48 Step 6. : fstab 1:19:50 Step 7. : mknode 1:25:42 Step 8. : le kernel 1:32:38 Step 9. : confkerndev 1:34:12 Step 10. : 3, 2, 1, intro part 336 et boot ! 1:38:56 Step 11. : Houston, on a un problème 1:42:40 indice de fin Les liens: - la PR en Python: gitlab.com/iMil/mksmolnb/-/merge_requests/5 - confkerndev: gitlab.com/0xDRRB/confkerndev.git - cdn.netbsd.org/pub/NetBSD/NetBSD-9.3/i336/binary/sets/rescue.tgz - gruik en rust : gitlab.com/GaLinux/gruik-rs
Wow... Mais les révélations épisodes après épisodes... Donc en gros, un tableau, c'est même pas des valeurs qui se suivent dans la mémoire ? Ce ne sont que des adresses qui elles se suivent toutes en mémoire tous les 4 octets (sur du 32 bits), et qui pointent vers des valeurs mises un peu à la zob dans la mémoire ? =0 Franchement, merci pour tes lives de qualitay !
C'est ça, les adresses se suivent, et pour un entier sur machine 32 bits, une "case" tous les 4 bytes, dans lesquelles on met une valeur :) ça fait plaisir de lire ta progression !!
Ok... Je pense que je commence à voir ce qui est difficile à saisir en ce qui me concerne sur cette série. Pour faire simple, je trouve ça difficile de savoir quand est-ce qu'une adresse a comme valeur une autre adresse, et quand est-ce que cette adresse a comme valeur le contenu de notre variable. Dans ton exemple, tu nous donnes : int i = 10; Dans gef, on peut voir qu'avant d'avoir le return i, 10 est bien déclaré dans la stack, mais après le return i, on retrouve notre 10 dans eax, donc dans le registre CPU ET dans la stack (toujours à la même adresse). Et c'est ça que j'ai du mal à saisir perso. Est-ce que ça veut dire que 10 est stocké uniquement dans le registre du CPU après le return i ? A quel niveau est-ce qu'on nous ment ici ? Est-ce que notre 10 se trouve dans la stack ET dans le registre ? Ou est-ce que la valeur de la stack n'est qu'une adresse vers le registre ?
Avant de répondre, je dois te dire que tu es *exactement* dans le bon spirit, c'est tout à fait le genre de questionnement qui va te mener à une compréhension précise et concrète, continue ! Il y a un concept très simple à comprendre : la vie d'une stack frame (les données d'une fonction présentes dans la stack) est éphémère, lorsque la fonction est terminée, ces données ne sont plus valides, c'est pour ça qu'on parle de variables locales, or, il faut pouvoir "retourner" une valeur, par exemple le résultat d'un calcul, à la fonction appelante. C'est le rôle du registre eax (rax en 64 bits), le standard -sur un CPU Intel- c'est de placer le résultat d'une valeur de retour dans le registre eax, d'ailleurs, et je pense qu'on le fait plus tard dans la série, tu peux écrire un petit bout d'assembleur qui bouge une valeur dans eax et tu verras que tu retrouveras cette valeur en retour de la fonction.
Toujours le même plaisir à regarder tes vidéos ! Par contre, truc tout con qui me fume en répétant au calme les trucs chez moi... Dans ton code tu déclares 1 - Ta variable i 2 - Ta variable c Maintenant, quand on regarde les adresses, on a par exemple i à 0xffffa104, et c à 0xffffa100... Donc en gros la variable c est plus "haute" en mémoire alors qu'elle a été déclarée après dans le code... Et on observe la même chose dans ton live... Alors probablement que tu as du l'expliquer dans tes Linux From Scratch, mais j'avoue que les arcanes de cette logique me laissent un peu con.
Hello ! Merci beaucoup pour ton commentaire :) je pense que tu vas comprendre la localisation des variables un peu plus loin quand on va rentrer plus profondément dans le fonctionnement de la stack, ce qu'il faut savoir c'est que cette zone mémoire "augmente vers le bas" ^^", c'est à dire que du point de vue de la stack, 0xffffa100 est superieur à 0xffffa104. Oui c'est particulier... Note que ce n'est pas une vérité absolue et que le compilateur peut décider d'un ordre différent fonction de comment il souhaite optimiser le code généré !
Rooooh, super et merci beaucoup@@emileimilheitor3456 pour ta réponse, t'es vraiment le GOAT ! Et merci pour ta pédagogie et ton approche (qui manque beaucoup trop en info) ! J'espère que tu pourras encore nous régaler avec pleins de lives et de vidéos comme celles-ci !!!
