4 ms·

my grossly over-simplified understanding of Linux (for the average end-user) if I had to "teach it" to somebody really quickly --- processor + RAM in motherbo

my grossly over-simplified understanding of Linux (for the average end-user) if I had to "teach it" to somebody really quickly --- processor + RAM in motherboard with hard disk and some kind of integrated graphics solution/external graphic card for video output, plus keyboard + mouse for input (hardware) hit the power button, motherboard inits procoess and runs BIOS which jumps to hard disk MBR (typically, ignores CD/USB/net boot) MBR jumps into bootloader on first sector on hard drive (GRUB or syslinux/extlinux) (this is my pre-EFI understanding) bootloader loads kernel (with optional initrd) from hard disk into memory kernel performs its own init, mounts root device (hard drive formatted in Linux-friendly file system like ext4 usually), sets up all hardware given bundled drivers/modules, calls /sbin/init or comparable /sbin/init spawns TTYs, does network configuration, then starts X server + a display manager (typically gdm if i remember correctly for GNOME?) X has input drivers for keyboard + mouse, output driver to get graphics onto monitor(s) (not sure if Wayland finally killed X yet, gonna guess no) from there, you can load /usr/local/bin/Chromium while will create a window on DISPLAY=:0 and go on Hacker News (granted you have it installed with all of its wonderful dependencies. probably 300mb+ of executables and resources and dynamic libraries) the fact that there's 20 different ways to do a lot of the steps I just described is... interesting. the magic (to me at least) happens after /sbin/init. What all gets started? Why? I feel the latest Ubuntu probably spawns... 40-60 processes? systemd and this/that/the other.

porknubbins 6y ago
I kind of conceptualize Linux as an OS (as compared to say a microprocessor directly executing a single program) like this- in the kernel there is a big infinite loop, just like a videogame loop that "updates" everything. In this loop the OS iterates over a linked list of task structs (AKA processes in userspace) and either gives each process its fair share of CPU time according to some scheduler or skips over it if it is sleeping (which the majority are).
- MuffinFlavored 6y ago
  I agree with you but I feel like that isn't specific to Linux as an OS. Windows and Mac both have a kernel responsible for keeping processes ticking in an infinite loop (scheduling executing across threads) as well. I think the original comment I was responding to was about the complications of Linux. To me... the complications of Linux aren't really in the 20+ years of "tech debt" that is "just make it boot and work for x86_64 like it used to work for i386", but moreso the 20-30 different configuration files and formats that happen after boot.
- ksaj 6y ago
  That's part of it. Now consider the CPU probably has multiple cores, so the "loop" as you have it, isn't a single thread. It's quite fuzzy. Add in the many tricks CPUs employ, like branch prediction, re-ordering, et al. Things don't happen in sequential order anymore, and multiple chunks of that code are being operated on at the same time. Even Assembler is pretty much a high level language nowadays, because once its loaded in memory, lots of unseen permutations will happen to it at execution time. It's a language of macros after all.
  - atoav 6y ago
    A question of scope. Do you want people to understand every intricate of the system? Do you want them to grasp the basic concept? Or do you want people to be able to use it on a day to day basis? These are very different courses
    - porknubbins 6y ago
      For my part I just want to answer basic questions that will help me understand the Linux kernel workings. The assembly and hardware details are a different, lower level issue.
  - saagarjha 6y ago
    CPUs are very constrained on the kinds of reordering they are allowed to visibly exhibit.

porknubbins 6y ago

I kind of conceptualize Linux as an OS (as compared to say a microprocessor directly executing a single program) like this- in the kernel there is a big infinite loop, just like a videogame loop that "updates" everything. In this loop the OS iterates over a linked list of task structs (AKA processes in userspace) and either gives each process its fair share of CPU time according to some scheduler or skips over it if it is sleeping (which the majority are).

MuffinFlavored 6y ago
I agree with you but I feel like that isn't specific to Linux as an OS. Windows and Mac both have a kernel responsible for keeping processes ticking in an infinite loop (scheduling executing across threads) as well. I think the original comment I was responding to was about the complications of Linux. To me... the complications of Linux aren't really in the 20+ years of "tech debt" that is "just make it boot and work for x86_64 like it used to work for i386", but moreso the 20-30 different configuration files and formats that happen after boot.
ksaj 6y ago
That's part of it. Now consider the CPU probably has multiple cores, so the "loop" as you have it, isn't a single thread. It's quite fuzzy. Add in the many tricks CPUs employ, like branch prediction, re-ordering, et al. Things don't happen in sequential order anymore, and multiple chunks of that code are being operated on at the same time. Even Assembler is pretty much a high level language nowadays, because once its loaded in memory, lots of unseen permutations will happen to it at execution time. It's a language of macros after all.
- atoav 6y ago
  A question of scope. Do you want people to understand every intricate of the system? Do you want them to grasp the basic concept? Or do you want people to be able to use it on a day to day basis? These are very different courses
  - porknubbins 6y ago
    For my part I just want to answer basic questions that will help me understand the Linux kernel workings. The assembly and hardware details are a different, lower level issue.
- saagarjha 6y ago
  CPUs are very constrained on the kinds of reordering they are allowed to visibly exhibit.