Seriously, this type of explanation and presentation is the type of education we all need for Linux. There is so much to learn (If you want to program C against the kernel or system).
I've had some super insightful moments regarding linux kernel development while reading "Hands-On System Programming with C++" by Rian Quinn. Might be worth a look
There is PLENTY of information out there. Also, the lower level you got, the less info you're going to get naturally as fewer people know and care about these stuff, hence less will teach and be able to help with them.
No, you don't need this kind of explanation and presentation. Well, unless you are realistically mentally challenged. This was really not much information.
0:30 While there is a family of POSIX C functions, only execve is (also) a syscall. The rest are convenience functions that can look up a full path name for a program name using the PATH variable (those with a "p" in their name), accept program parameters as function arguments rather than an array of strings (those with an "l" rather than "v" as in vector), or inherit the environment variables of the calling process (those lacking the "e" at the end).
@@lawrencedoliveiro9104 It is in the kernel, but execveat is a much later addition to the kernel (3.19+) than the other -at functions, and is usually only used in special cases where you want to execute relative to a fixed directory or from a special O_PATH file descriptor. The latter is also not used by fexecve(3), which is documented to use the special /proc path representing that file descriptor on Linux, but *is* a syscall on other systems.
@@D0Samp Here’s a note from the fexecve man page: On Linux with glibc versions 2.26 and earlier, fexecve() is implemented using the proc(5) filesys‐ tem, so /proc needs to be mounted and available at the time of the call. Since glibc 2.27, if the underlying kernel supports the execveat(2) system call, then fexecve() is implemented using that system call, with the benefit that /proc does not need to be mounted.
@@lawrencedoliveiro9104 You're right. It makes sense to use more efficient syscalls after all. Also doesn't change functionality, for example the inability to execute shell scripts from a close-on-exec file descriptor, because it will be closed before the shell can read it (then again, this seems entirely impossible e.g. with fexecve(2) on FreeBSD).
@@gregorymorse8423 If you want to know how this stuff works at the assembly level, you are free to go look at the actual source code, download it, play with it, even make your own video about it.
Excellent video. Subbed. I’ve been hacking on Linux since the ‘90s, and this is the clearest low-level explanation of Linux executables I’ve ever seen. A follow-up video would be amazing! Keep up the great content. It’s _very_ much appreciated!
Hey, this video naturally got my interest, im currently rewriting my elf loader that is used in one of my projects, and this video is overall pretty correct, the only thing that i think it would've been interesting to include is the resulting memory layout, that would be the mappings of the shared libraries and the main executable, with some real examples, like the command "cat /proc/self/maps", that shows the mappings of the program "cat" being executed, it shows the actual main executable mappings, the heap, libc.so.6, the linker ld-linux-x86-64.so.2, the stack, etc...
Great video. There’s actually one more step the Linux kernel takes before loading the elf file. It opens the file and checks if it contains the shebang character (#!) at the start. if so, it interprets the file rather than executing it using the program specified in the shebang (e.g. #! /bin/bash)
5:53 Those segments _are_ the content of the executable. ELF has the concepts of “sections” versus “segments”; the “sections” are the divisions of the file content, while the “segments” define the in-memory layout.
I never usually comment but I think this right is where it is an obligation. Please please please do more in depths like this. With the clarity and succinctness that you have explained and shown us how this system works is insanely good. I will watch every single video you pump out that explains about how Linux really works.
I swear it feels like over the past few months there havee just been so many insanely good videos from small channels. Have this videos always been here and youtube is just now recommending them, or is there just a surge of new high quality content for some reason?
I got inundated with small channels (like three figure subs small) relatively recently, so I do think yt rolled out an algorithm tweak that gives newer creators a bit of a boost.
This is actually really cool. I'd love to see the very complex version of the same : ) It takes a lot of understanding and patience to actually come up with such beautiful explanation. Thanks !
Thank you for such a thorough explanation. I would love to see more videos about systems programming in Linux done in your concise and accessible style!
Really loved this explanation! I understood how to get an executable and how code execution works at an assembly level, but never thought to wonder the in-between steps. I'm looking forward to more videos like this! Keep up the great work :)
I wish I was learning this in class right now, I'd love to see the more complex explanation too! The moderate explanation makes enough sense and provides enough detail for it to poke the computer science bug in my brain and get it to say "I want more"
Fantastic explanation, I'll be forwarding that to some buddies. I have recently started using NixOS again, and figured this was surprisingly relevant, got to the end excited for you to talk about the interpreter and dynamically linking, and then got cliff hung. I'm subscribing, eagerly awaiting a follow up.
The UA-cam algorithm is doing it's thing, and it's great :) While the complexity of the explanation is kept low, I think the visuals and the fact that you picked the subject well and stripped it out of the more complex ideas makes it more digest. Properly mentioning what you're NOT talking about and making it easy for the viewer to differentiate between what's the subject and what isn't is a big part of actually explaining something and not just circle jerking an idea :P It's easier to expand on ideas (E.G, looking at another video or docs with the knowledge acquired) than it is to suddenly digest a dump of code and ideas. Also, the format could be a little bit longer but not too much, because being short enough to remember the beginning of the video by the end is very useful for such concepts. Otherwise, it just feels like consuming content and taking nothing out of it :) Liked the video a lot !
@@atlantic_love it recommended me a random video from an unknown channel about Linux low level exec calls. I have never watched a video on Linux systems nor have I cared about that kind of content before. So yeah, it did it's thing by recommending a good, fast growing video that is only loosely related to the content I usually watch. Go be negative somewhere else.
@@Dekharen It's completely random recommendations, and if you like something out of those random things, than it will recommend more of those things. What this video is about has nothing to do with the conversation. It's pretty simple, actually. No real "algorithm" in the sense of it catoring to you specifically. Someone telling you that you don't know what you're talking about isn't them "being negative". Go victimize somewhere else.
Really happy to see this explanation video of yours gain much more attentions, like your quote in early video, it demonstrate non-zero day motto and the quote "success story comes after a long way". Some system call explaination and system-C library usage and their interfaces to more user-friendly language like python and lua would be interesting
Oh for the days when an executable file only needed to have a header with an entry point followed by a series of blocks of data, each with a header of the address in memory the data is to be placed and a byte for the length of the block. Of course, that was before shared libraries and link on load loaders. Thank you for the clarity of your presentation. Do consider a follow up video. I am sure the animation was a lot of work but, trust me, it was worth it.
Very interesting video! For those interested in learning a bit more, there's a series of articles by LWN titled "How programs get run" that go over the exec family of syscalls, and its follow-up "How programs get run: ELF binaries".
This is a fantastic introduction to the concept of simply loading some Linux code into memory. I'd love to see what the interpreter does within this context. I'd also be interested in the kernel side of this for how that side of it is managed in a sane manner, so that the kernel can run the code without the machine falling over. Thanks for this video. I'm now subbed too.
Oh this was interesting! I am studying CS and we went through the basic workings of a computer and it was interesting, but since it was just general ideas found on computers in general, the idea was left floating in abstract space. Would love to see explained in video form how these things go about in real concrete linux system! More of this please! :D
I have been Studying Computer science. There are two 6LP Modules about what you talk about in this one vid (sure Modules are a bit more about general cases and what a Programm or a thread is) - you explained to me what I couldn't understand after failing one of the courses twice now. Incredible way to represent infomration. You might want to add as anotations what is a program header entry is
2:17 What? This is strange to me. Why is file showing you this? When I run it on the executables on _my_ system, they're identified as "pie executable", not "shared object". And in fact, if I compile a program this way and try to run it, it just segfaults. (Not too surprising. The initialization may be too different for that to work normally.) But maybe your distro has things set up differently? Or was this an error?
I've got a little anecdote about this: I was trying to make a from-scratch, super minimal Docker image for a Python program, using pyinstaller if I remember correctly, but I kept getting a "file not found" error. But the file obviously existed. I copied it into the image, and when I exported a container running that images to a .tar file, it still existed. It turned out that my from-scratch image was missing the interpreter (p_type/PT_INTERP). That took me hours to figure out, even with the help of 2 other people. P.S. great video! I'd love to see a sequel that goes more in-depth.
I like the video: the content, the structure and the way you tell it very satisfying. Also, I can see you just on the beginning of your UA-cam fame journey, so I need to say some critic: Your baritone voice needs a better microphone or its tuning. :) Maybe it will be fine just to add some simple music at the background. Thanks!
@@robertsimplerino Exacty! That kills the video for me. I barely managed to get through it with 2x speed. Unfortunately it's a cultural thing so I don't think there is much that can be done to fix it for old farts who can't stand it, like myself.
I'm a Windows guy, with a bit of reverse engineering knowledge, trying to get into Linux and this is exactly the kind of content and I want - thank you
Great video! My only suggestion would be to make the code / technical parts in a mono space font. Nitpicky because everything else was great. Keep it up!
I remember once I had fun writing an elf loader to load a linux .so binary into windows as DLL and use it. It was some sort of blob that didn't do any actual syscall, it was merely for cryptography, it only used CPU instructions, so I was able to load it and run the code on Windows. I did have to provide basics of the interpreter to patch up code as it was not PIC. But well, that was the fun part.
Another kind of executables is "shell script", and there're two ways to run it at least. The simplest way, the shell calls into kernel, then kernel call the "shebang" of the script to interpret the script, usually seen in small system like busybox. The second way is a little complicated, the shell do the interpreting job by its own way first, then it might call system call later, this depends on which shell is running to run the executable.
awesome explanation. what if the entrypoint is outside of the executable? does it mean the assembly is packed? i had that on windows on a pe file i try to reverse engineer
Awesome video and I just subscribed! (Some feedback is that the transitions where letters scattered or rearranged was annoying. It works when expanding an acronym but otherwise it looks like dyslexia)
you've earned a sub in 37 seconds! I am in 2nd year of Computer Science I was having a lot of fun with Arch over summer break. -Also sorry to point this out but your voice is quite cracky, like you have a very dry throat, I never watched any videos if there are, so I have to stress this so you will have this in mind (if it is something you can fix).- Also i can hear that mic audio is starting low then to higher volume, seems like a mic issue or you dont speak to the mic at the semi-constant distance 1:20-1:38
Fun Fact: You can disable running of scripts (Specifically starting with #! on line 1) in "make menuconfig" menu of Linux when your trying to compile the kernel.
2:25 i’ve been wondering what the “version 1 (SYSV)” means? i have seen some executables that says something about gnu instead at the same location. what is the difference?
God I want to switch back to Linux so bad, but I bought an ROG Flow Z13 and I didn't realize certain systems don't run well with Linux. I tried installing Fedora but it was super laggy. I probably just need to edit some settings...
Amazing content! But if I were to give some constructive criticism to make it even better, I'd suggest to try and reduce your vocal fry during recording. I watched it till the end and loved the content, but the vocal fry kinda put me off 😅
I really liked your explanation and I think you did an excellent job! however please just stop lowering your voice into a fry at the end of every sentence pls
@@sellicott Some parts I do manually and that just takes some time, but occasionally I've found I can just copy straight from VSCode and the highlighting is preserved.
Wish this video was out when I was trying to make my own implementations of the clear command for different architecturea in a hex editor, would have saved me a lot of time early on in understanding what I was doing.
There’s no way ELF doesn’t mean there are tiny little elves in the computer making these things work with magic.
Seriously, this type of explanation and presentation is the type of education we all need for Linux. There is so much to learn (If you want to program C against the kernel or system).
I've had some super insightful moments regarding linux kernel development while reading "Hands-On System Programming with C++" by Rian Quinn. Might be worth a look
There is PLENTY of information out there. Also, the lower level you got, the less info you're going to get naturally as fewer people know and care about these stuff, hence less will teach and be able to help with them.
No, you don't need this kind of explanation and presentation. Well, unless you are realistically mentally challenged. This was really not much information.
Pot kettle black @@yaroslavpanych2067
0:30 While there is a family of POSIX C functions, only execve is (also) a syscall. The rest are convenience functions that can look up a full path name for a program name using the PATH variable (those with a "p" in their name), accept program parameters as function arguments rather than an array of strings (those with an "l" rather than "v" as in vector), or inherit the environment variables of the calling process (those lacking the "e" at the end).
I think execve(2) is just a special case of execveat(2).
@@lawrencedoliveiro9104 It is in the kernel, but execveat is a much later addition to the kernel (3.19+) than the other -at functions, and is usually only used in special cases where you want to execute relative to a fixed directory or from a special O_PATH file descriptor. The latter is also not used by fexecve(3), which is documented to use the special /proc path representing that file descriptor on Linux, but *is* a syscall on other systems.
@@D0Samp Here’s a note from the fexecve man page:
On Linux with glibc versions 2.26 and earlier, fexecve() is implemented using the proc(5) filesys‐ tem, so /proc needs to be mounted and available at the time of the call. Since glibc 2.27, if the underlying kernel supports the execveat(2) system call, then fexecve() is implemented using that system call, with the benefit that /proc does not need to be mounted.
@@lawrencedoliveiro9104 You're right. It makes sense to use more efficient syscalls after all. Also doesn't change functionality, for example the inability to execute shell scripts from a close-on-exec file descriptor, because it will be closed before the shell can read it (then again, this seems entirely impossible e.g. with fexecve(2) on FreeBSD).
@@gregorymorse8423 If you want to know how this stuff works at the assembly level, you are free to go look at the actual source code, download it, play with it, even make your own video about it.
Excellent video. Subbed. I’ve been hacking on Linux since the ‘90s, and this is the clearest low-level explanation of Linux executables I’ve ever seen. A follow-up video would be amazing! Keep up the great content. It’s _very_ much appreciated!
Thank you! Appreciate the feedback from a long term linux hacker!
Hacking you said?
Liar
@@rian0xFFF you got me. I should have said GNU/Linux _and_ the *BSD’s.
@@rayforever yes
Hey, this video naturally got my interest, im currently rewriting my elf loader that is used in one of my projects, and this video is overall pretty correct, the only thing that i think it would've been interesting to include is the resulting memory layout, that would be the mappings of the shared libraries and the main executable, with some real examples, like the command "cat /proc/self/maps", that shows the mappings of the program "cat" being executed, it shows the actual main executable mappings, the heap, libc.so.6, the linker ld-linux-x86-64.so.2, the stack, etc...
As an aspiring Linux Kernel Developer, I really appreciated this video :)
Glad you liked it!
Great video. There’s actually one more step the Linux kernel takes before loading the elf file. It opens the file and checks if it contains the shebang character (#!) at the start. if so, it interprets the file rather than executing it using the program specified in the shebang (e.g. #! /bin/bash)
Linux also supports other interpreters for specific file types now, which is how e.g. WINE and userspace QEMU work!
This is such a good explanation of what goes down at different levels of complexity. Loved the animations and presentation. You get sub sir :)
This editing is satisfying to watch
It looks like Powerpoint with the morph transitions. Incredibly powerful stuff
Anyone know how they are done? Is it like the guy that writes his videos in rust?
@@en7998the rust guy uses obsidian paired with a slides extension
Who's the rust guy?
@@en7998 It looks like Manim to me - the python library that 3Blue1Brown made for their videos. But I could be wrong.
5:53 Those segments _are_ the content of the executable. ELF has the concepts of “sections” versus “segments”; the “sections” are the divisions of the file content, while the “segments” define the in-memory layout.
I really like your presentation and animation, if you do make more videos related to this topic id love to watch them.
I never usually comment but I think this right is where it is an obligation. Please please please do more in depths like this. With the clarity and succinctness that you have explained and shown us how this system works is insanely good. I will watch every single video you pump out that explains about how Linux really works.
So you sometimes comment?
635th subscriber, subscribed afterjust 30 seconds, great channel, it will blow up
I’d love another video about the topic! It’s very interesting
Very interesting video and also great work with all the animations. All of them were quite smooth and pleasant.
Interesting, I have been super interested in how computers work for a while and this taught me a little about Linux executables.
Glad to hear it, if you want more detail on the ELF format I left the spec in the description 👍🏻
I swear it feels like over the past few months there havee just been so many insanely good videos from small channels. Have this videos always been here and youtube is just now recommending them, or is there just a surge of new high quality content for some reason?
I got inundated with small channels (like three figure subs small) relatively recently, so I do think yt rolled out an algorithm tweak that gives newer creators a bit of a boost.
Lol another bot 😅
This is so good! I'm looking forward to a video talking about dynamic linking since that's always been a mystery (basically magic) to me
This is actually really cool. I'd love to see the very complex version of the same : ) It takes a lot of understanding and patience to actually come up with such beautiful explanation. Thanks !
Thank you for such a thorough explanation. I would love to see more videos about systems programming in Linux done in your concise and accessible style!
Really loved this explanation! I understood how to get an executable and how code execution works at an assembly level, but never thought to wonder the in-between steps. I'm looking forward to more videos like this! Keep up the great work :)
Very cool. I kind of had a sense of how this worked before, but seeing this really connected a lot of dots. Super clear and informative video.
with this level of quality i thought you at least had 1M subs - keep up the good work!
I wish I was learning this in class right now, I'd love to see the more complex explanation too! The moderate explanation makes enough sense and provides enough detail for it to poke the computer science bug in my brain and get it to say "I want more"
Thanks for giving me a refresher on this subject! One of my uni courses had a very fun segment on this topic!
Great video: editing, visualization and so on. Once in lifetime youtube recommended something really good
Fantastic explanation, I'll be forwarding that to some buddies. I have recently started using NixOS again, and figured this was surprisingly relevant, got to the end excited for you to talk about the interpreter and dynamically linking, and then got cliff hung. I'm subscribing, eagerly awaiting a follow up.
The UA-cam algorithm is doing it's thing, and it's great :)
While the complexity of the explanation is kept low, I think the visuals and the fact that you picked the subject well and stripped it out of the more complex ideas makes it more digest. Properly mentioning what you're NOT talking about and making it easy for the viewer to differentiate between what's the subject and what isn't is a big part of actually explaining something and not just circle jerking an idea :P
It's easier to expand on ideas (E.G, looking at another video or docs with the knowledge acquired) than it is to suddenly digest a dump of code and ideas.
Also, the format could be a little bit longer but not too much, because being short enough to remember the beginning of the video by the end is very useful for such concepts. Otherwise, it just feels like consuming content and taking nothing out of it :)
Liked the video a lot !
I don't think you know what the algorithm actually is.
@@atlantic_love it recommended me a random video from an unknown channel about Linux low level exec calls. I have never watched a video on Linux systems nor have I cared about that kind of content before. So yeah, it did it's thing by recommending a good, fast growing video that is only loosely related to the content I usually watch. Go be negative somewhere else.
@@Dekharen It's completely random recommendations, and if you like something out of those random things, than it will recommend more of those things. What this video is about has nothing to do with the conversation. It's pretty simple, actually. No real "algorithm" in the sense of it catoring to you specifically. Someone telling you that you don't know what you're talking about isn't them "being negative". Go victimize somewhere else.
this was really clear, it made more sense than the other tutorials id read
Really happy to see this explanation video of yours gain much more attentions, like your quote in early video, it demonstrate non-zero day motto and the quote "success story comes after a long way". Some system call explaination and system-C library usage and their interfaces to more user-friendly language like python and lua would be interesting
Dropped a sub! Clean content. You were in my recommended so hopefully the algorithm likes ya :D
I just got this recommended to me, and it's really well done. Thanks for making it
I've thinking about that exact thing and for me the thumbnail is just a very, very simple and fully self-explanatory overview, in theory.
Just to mention, some late 20th century mathematics as well, but at best very partially.
Oh for the days when an executable file only needed to have a header with an entry point followed by a series of blocks of data, each with a header of the address in memory the data is to be placed and a byte for the length of the block. Of course, that was before shared libraries and link on load loaders. Thank you for the clarity of your presentation. Do consider a follow up video. I am sure the animation was a lot of work but, trust me, it was worth it.
Very interesting video! For those interested in learning a bit more, there's a series of articles by LWN titled "How programs get run" that go over the exec family of syscalls, and its follow-up "How programs get run: ELF binaries".
This is a fantastic introduction to the concept of simply loading some Linux code into memory. I'd love to see what the interpreter does within this context. I'd also be interested in the kernel side of this for how that side of it is managed in a sane manner, so that the kernel can run the code without the machine falling over.
Thanks for this video. I'm now subbed too.
This video is super well made, subbing for more Linux content like this :) I can't believe you only have 3k subs with this kind of quality
Oh this was interesting! I am studying CS and we went through the basic workings of a computer and it was interesting, but since it was just general ideas found on computers in general, the idea was left floating in abstract space. Would love to see explained in video form how these things go about in real concrete linux system! More of this please! :D
“ive been thinking about executables a lot recently” is so strangely relatable
I like your animation style a lot. I'm looking forward to seeing more videos from ya.
I have been Studying Computer science. There are two 6LP Modules about what you talk about in this one vid (sure Modules are a bit more about general cases and what a Programm or a thread is) - you explained to me what I couldn't understand after failing one of the courses twice now. Incredible way to represent infomration.
You might want to add as anotations what is a program header entry is
Bro, great video and great channel!! Just randomly found you, but your content is amazing!
2:17 What? This is strange to me. Why is file showing you this? When I run it on the executables on _my_ system, they're identified as "pie executable", not "shared object". And in fact, if I compile a program this way and try to run it, it just segfaults. (Not too surprising. The initialization may be too different for that to work normally.) But maybe your distro has things set up differently? Or was this an error?
THIS is quality content, keep it up! Hugs from Brazil here. 🇧🇷 :D
I've got a little anecdote about this:
I was trying to make a from-scratch, super minimal Docker image for a Python program, using pyinstaller if I remember correctly, but I kept getting a "file not found" error. But the file obviously existed. I copied it into the image, and when I exported a container running that images to a .tar file, it still existed.
It turned out that my from-scratch image was missing the interpreter (p_type/PT_INTERP). That took me hours to figure out, even with the help of 2 other people.
P.S. great video! I'd love to see a sequel that goes more in-depth.
I like the video: the content, the structure and the way you tell it very satisfying.
Also, I can see you just on the beginning of your UA-cam fame journey, so I need to say some critic:
Your baritone voice needs a better microphone or its tuning. :)
Maybe it will be fine just to add some simple music at the background.
Thanks!
Hey really appreciate the feedback! I'm looking into solutions to fix it, do you have any microphone suggestions that you like?
it's not baritone voice, it's vocal fry
@@robertsimplerino Exacty! That kills the video for me. I barely managed to get through it with 2x speed. Unfortunately it's a cultural thing so I don't think there is much that can be done to fix it for old farts who can't stand it, like myself.
I'm a Windows guy, with a bit of reverse engineering knowledge, trying to get into Linux and this is exactly the kind of content and I want - thank you
Good job algorithm. Banger video, well done Mr Pradels.
Great video! My only suggestion would be to make the code / technical parts in a mono space font. Nitpicky because everything else was great. Keep it up!
I remember once I had fun writing an elf loader to load a linux .so binary into windows as DLL and use it.
It was some sort of blob that didn't do any actual syscall, it was merely for cryptography, it only used CPU instructions, so I was able to load it and run the code on Windows.
I did have to provide basics of the interpreter to patch up code as it was not PIC. But well, that was the fun part.
I'm down for a part 2.
Yes, this guy thought it was interesting and subscribed for loading the interpreter. I'd also like to see other common use cases of ELF explained
I thought I'd be bored but I want you to explain forever
Please give us more of that quality Linux content!
Another kind of executables is "shell script", and there're two ways to run it at least. The simplest way, the shell calls into kernel, then kernel call the "shebang" of the script to interpret the script, usually seen in small system like busybox. The second way is a little complicated, the shell do the interpreting job by its own way first, then it might call system call later, this depends on which shell is running to run the executable.
Excellent job! You clearly have educational talent!
Nice clear and wisely parted. 🤯
awesome explanation. what if the entrypoint is outside of the executable? does it mean the assembly is packed? i had that on windows on a pe file i try to reverse engineer
This is great! Please explain the linker. Your presebtation style ie nice and approachable and I would love more!
As an electrical and computer engineering student, this video was extremely useful
Thanks for for the great material presentation. Very concise and understandable explanation of quite complex stuff.
Thank you for this clear explanation.
P.S. Your voice is amazing.
Thank you for your kind words :)
Awesome video and I just subscribed!
(Some feedback is that the transitions where letters scattered or rearranged was annoying. It works when expanding an acronym but otherwise it looks like dyslexia)
Subs are amazing. CIS calls made my day 😂
it's a lot harder than i thought. great video!
as a devops with about 9 YOE it was very good video. I was always curious how its work. Subbed
great video, i love your animation style
you've earned a sub in 37 seconds! I am in 2nd year of Computer Science I was having a lot of fun with Arch over summer break.
-Also sorry to point this out but your voice is quite cracky, like you have a very dry throat, I never watched any videos if there are, so I have to stress this so you will have this in mind (if it is something you can fix).-
Also i can hear that mic audio is starting low then to higher volume, seems like a mic issue or you dont speak to the mic at the semi-constant distance 1:20-1:38
Thank you! Working on the mic issues
This is fantastic!! People complaining about your voice need to relax.
This was great! This was more than worth my sub.
Fantastic video, but please try to smooth the volcal fry a bit in the future. It's going to be easier for some people to grasp words.
Excellent video. It would be great if you could make a video series with things like this, I'd love to share them with my students.
@ncurses.h what's wrong with having an anime pfp?
Tiny correction to an otherwise awesome video: For a dynamic library the elf type would be ET_DYN not ET_EXEC.
Good catch, thanks!
Bro you're the best 🫶 This is the best video by far that I could find to understand about executables.
I'm a simple man. Once I find any channel using manim, I subscribe ❤
Make a follow up for what the interpreter does!
Fun Fact: You can disable running of scripts (Specifically starting with #! on line 1) in "make menuconfig" menu of Linux when your trying to compile the kernel.
Very cool. I would watch one where you went into more detail.
2:25 i’ve been wondering what the “version 1 (SYSV)” means? i have seen some executables that says something about gnu instead at the same location. what is the difference?
Excellent Video. This Channel deserves more subscirbers
Awesome video, can't wait for the interpereter.
God I want to switch back to Linux so bad, but I bought an ROG Flow Z13 and I didn't realize certain systems don't run well with Linux. I tried installing Fedora but it was super laggy. I probably just need to edit some settings...
Good video
I'd consider adding more about what is exec and what's happening there (fork syscall and its consequences)
This is 3b1b tier editing an explanation. Awesome stuff 💯💯💯
Amazing content! But if I were to give some constructive criticism to make it even better, I'd suggest to try and reduce your vocal fry during recording. I watched it till the end and loved the content, but the vocal fry kinda put me off 😅
Noted! Working to improve that
And glad to hear you enjoyed aside from that!
Great video. Please do make a video on the dynamically linking interpreter!
I subscribed. Hope to see more of this type of content
Linux really be like "damn that file is looking executable and linkable today"
Keep this videos up and you will become something. Doesn't matter about your upload schedule or anything else, you will become something.
I really liked your explanation and I think you did an excellent job! however please just stop lowering your voice into a fry at the end of every sentence pls
Very interesting and well presented. If I may ask, what software are you using to generate the animations?
Powerpoint, shh don't tell anyone its a secret 😉
@@jacobpradels Impressive. How are you doing the code formatting? I've always had a hard time with that in Word and Powerpoint.
@@sellicott Some parts I do manually and that just takes some time, but occasionally I've found I can just copy straight from VSCode and the highlighting is preserved.
0:49 argv and evnp are not a null-terminated character arrays, they are arrays of null-terminated character arrays, aka string arrays
I don't think anyone would be mad if you said "elf" instead of E.L.F.
"I've been thinking a lot about executables lately"
-The entire french population
Very nice video, keep up the great work!
Wish this video was out when I was trying to make my own implementations of the clear command for different architecturea in a hex editor, would have saved me a lot of time early on in understanding what I was doing.
Great video, I'd love to see more!
It'd be great to see a follow up video.
xv6 is a simple unix-like operating system built for demonstrations and explanations like this. Linux has added a lot of complexity over the decades.
Videos like this are the sort of content that (in hindsight) I am stunned my university never explained.
Sir please, start producing these videos non stop for the next 5 years thank you!