Niet vergeten dat een boek leuk is, maar de 'echte' bron van informatie gewoon bij de software en source code te vinden is. Om dat op te zoeken hoef je geen programmeur te zijn.
Er is niet 1 Linux, je hebt de Linux Kernel van kernel.org, dat is in principe de basis Linux kernel, maar daar heb je in de praktijk nauwelijks rechtstreeks wat mee te maken. Die kernel, of, de broncode daar van, wordt in 99% door bepaalde Linux-distributies gebruikt, aangepast (bijv. sommige zaken aanzetten/uitzetten) en onderhouden voor een langere termijn. Daar wordt dan nog een setje tools aan toegevoegd, vaak de GNU userland zodat je ook daadwerkelijk iets kan doen, en dan komt er met desktop-distributies ook nog een grafische interface bij met window server, desktop environment en programma's voor GUI-gebruik. Dan heb je nog een package manager die vooraf gecontroleerde, gecompileerde en geïntegreerde software beschikbaar maakt zodat je niet alles constant zelf hoeft te doen.
Kortom: weten wat een shell, console, terminal (emulator) of tty is helpt, maar is in feite niet zo belangrijk als je denkt dat het is.
Als je het boek uit hebt kan ik je aanraden in elk geval twee distributies te testen: Debian en Fedora. Daarmee dek je 90% van de ecosystemen af:
- RPM vs. DEB packages (yum/dnf vs. apt)
- sysconfig vs. normale /etc indeling
- commerciele insteek vs. community en ethische insteek
Als je nog wat andere zaken wil doen, zoals non-self-hosting systemen zou je OpenWRT in een VM kunnen gooien of op een embedded router.
Je kan het zo breed en zo diep behandelen als je maar wil, maar in de meeste gevallen ben je (vooral als beginner) het beste af door gewoon een paar grote distro's te pakken en de advanced CLI installer een paar keer doorlopen. Dan kan je in elk geval van begin tot eind + recovery zelf doen en heb je in elk geval het gevoel zelf te kunnen bepalen wat er gaat draaien. De volgende stap (voor mij in 1993 in elk geval) is misschien wat dieper in het opstartsysteem van x86 duiken, even uitzoeken wat er gebeurt als het systeem aan gaat, de CPU uit reset komt, en de PCH/CPU beginnen met firmware uitvoeren om de POST te doen, en de bootloader op te zoeken. Daar krijg je dan gratis een stukje les van GRUB en BIOS of UEFI bij, en iets over harde schijven en partitionering, partitie ID's, en hoe computers datatypes herkennen (magic numbers, headers enz. file extensions zijn eigenlijk alleen op Windows desktop echt relevant).
Het risico van enkel een boek lezen is dat je je kennis heel sterk op specifieke zaken uit dat boek vastspijkert en niet de achterliggende concepten snapt. Dat hoeft niet altijd zo te zijn, maar Linux en een groot gedeelte van het FOSS OS ecosysteem zijn haast universeel te begrijpen zodra je snapt hoe computers zo'n beetje werken, hoe je van code naar binaries naar packages gaat, en dat alles zonder zelf echt te hoeven programmeren.
Als je dit lijstje snapt kan je bijv. in elk geval Linux, BSD, en de meeste andere systemen wel snappen:
- CPU reset / platform power on
- CPU reset vector (waar de eerste code gelezen en gestart wordt, meestal firmware loader)
- Firmware (klassieke BIOS, UEFI, OpenFirmware, UBoot, Reboot enz.)
- Bootloader (GRUB, LILO, NTLDR enz.)
- Kernel + initramdisk (bootloader kopieert kernel en ramdisk naar RAM, en geeft parameters mee zodat de kernel weet waar in het geheugen er gekeken moet worden, ramdisk wordt met minimaal setje tools geladen om daarna de HDD/SSD/RAID/LVM/ZFS te vinden en de rest van het OS/services te kunnen gebruiken)
- init (eerste proces wat de kernel start, meestal een programma dat zelf ook init heet, soms systemd, soms launchd enz. je kan er ook bash van maken en dan start de kernel een shell en doet daarna niks meer voor je)
Maar ook bijv. een basisconcept van programma's laten draaien, niet dat je dat elke dag gaat doen, maar het is iets wat het verschil maakt tussen een computer waar je de controle over hebt vs. een computer waarbij je maar moet hopen dat iemand anders de software beschikbaar maakt. Leer bijv:
- tarball / git repo met code regelen
- configure en make uitvoeren
- resulterende binaries meteen gebruiken
dat kan om dat je op een self-hosted Linux systeem zelf de mogelijkheid hebt software te bouwen en te draaien en niemand kan je tegen houden. Self-hosted betekent dat een systeem zichzelf kan bouwen vanuit broncode zonder dat je daar een extra systeem voor nodig hebt. Sommige systemen, bijv. VxWorks zijn niet self-hosting, je kan VxWorks niet builden op VxWorks, dat moet op een ander systeem. Als je als gebruiker Windows installeert heb je hetzelfde. (maar dat is voornamelijk om dat de code geheim is en de tooling en methode om te bouwen niet echt portable of geschikt is om zomaar te kunnen gebruiken)
Zodra je door hebt hoe je van een computer die uit staat naar een computer die opgestart is komt, en hoe je van code naar werkende software komt kan je eigenlijk zo'n beetje alles, en zal de rest van de dingen die je wil leren vooral over specifieke zaken gaan.
Dat is zo ongeveer hoe ik er ooit mee begon, en ik pluk er nog steeds de vruchten van. Maakt niet uit hoe veel 'nieuwe' zaken er bij komen, de meeste processen en achterliggende patronen van hardware tot software veranderen weinig. Zo is de BIOS misschien vervangen, maar de PEI van UEFI is echt niet heel veel anders. En een CPU wordt op een x86 moederbord nog steeds gewoon in RESET gehouden totdat soft power-on gebeurt en de PCH er klaar voor is. En je hebt nog steeds dat je firmware wat dingen doet om je hardware zo ver te krijgen, en daarna control geeft aan de bootloader die daarna verder gaat. De details over hoe veel er gedaan wordt, en hoe efficient de code is, en hoeveel invloed componenten naast de CPU, firmware en bootloader hebben, dat verandert een beetje, maar de globale principes zijn onveranderd. Dat is ook nog steeds zo met met software voor Linux bouwen (die in C of C++ geschreven is en met autotools geconfigureerd wordt). Dat is nog steeds een kwestie van zorgen dat je een werkende makefile hebt, make doen, en gaan met de software. Ja, er zijn meer container smaken bij gekomen (maar dat is dus ook niet nieuw en bestaat al 10 jaar voor dat Docker als bullshitbingo uit de bus kwam), maar jails en chroots bestaan al erg lang. Je kan nu wat meer met control groups en kernel CAPs, maar deze concepten en de generieke manier van gebruik is onveranderd.
Kijk ook hier om wat informatie te verzamelen:
-
https://wiki.osdev.org/System_Initialization_(x86)
-
Wikipedia: Reset vector
-
https://www.centos.org/do...nit-shutdown-process.html
-
https://wiki.debian.org/BootProcess
-
https://wiki.debian.org/Shell
-
https://askubuntu.com/que...6/what-does-tty-stand-for
-
Wikipedia: Disk partitioning
-
http://allendowney.blogsp...am-is-getting-harder.html (nee, niet alleen programmeurs, ook het globale probleem dat techniek 'verstopt' wordt achter ondoorzichtige processen en GUIs waardoor je als computergebruiker wel makkelijk even wat kan doen, maar dus niet meer weet wat er gebeurt en als je een keer wel wat wil weten, dan kan dat dus niet zomaar)
[
Voor 17% gewijzigd door
johnkeates op 18-02-2018 16:11
]
:strip_icc():strip_exif()/u/50899/av-8.jpg?f=community)
/u/34186/crop62e07d174532d_cropped.png?f=community)
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
/u/125506/link-8bit.png?f=community)
:strip_icc():strip_exif()/u/75828/sid.jpg?f=community)
). Ik verdenk je ervan met een antiek handboek aan de slag te zijn, als je over X Windows praat. Dat is al járen vervangen door een opvolger, en voor die opvolger zijn ook al vervangers in aantocht :strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Weet nu helemaal niet meer waar ik moet beginnen. 
/u/127857/avatar_36_1322279746.png?f=community){kind=avatar}
:strip_exif()/u/2087/osiris_ani.gif?f=community)
/u/361397/crop58b5e363f2f5f_cropped.png?f=community)