On Mon, 13 Apr 2015 20:21:49 +0300 Reco <recovery...@gmail.com> wrote:
> On Tue, Apr 14, 2015 at 12:36:28AM +0800, Bret Busby wrote: > > The question is, what is the nature of the understanding that you > > want of Linux? Is it the interaction between the layers, for > > example, the HAL and the higher layers; is it the multitasking; is > > it understanding administration (such as, do not do one of the > > whoopsies - using "chmod .", as one (other) student did, when I was > > learning UNIX), is it scripting and shell processing, or, is it the > > "design and implementation" of the operating system, and, in that, > > does what you want, include comparative design and implementation > > of operating systems? > > Let's see as I didn't have OS design in mind. Something like: > > Exit codes and their value in real life. > Strings handling, memory allocation. > Process control and daemonisation (sp?). > Signal handling. > Inter-process communication (sockets, pipes). > IP protocol use and abuse. > Shared memory. > Threads. > Libraries and their usage. Just to pipe in here, these are among the things that I want an understanding of - especially numbers 3, 4, 5, 6 and 9. With extra focus on 9 and 6b :) Also things like communication between processes and devices, file systems, etc. I want to learn how to find out why things work the way they do, if that makes sense. > Bonus points are granted if code can be compiled on more than one > processor architecture. Extra bonus points for doing it in more than > one POSIX-compatible OS. > > Of course, those are basics. There's nothing in those that cannot > be implemented in any programming language. > > But then - you encounter a mis-behaving program. You use strace(1) or > ltrace(1) and, hey, suddenly you understand what's going on without This! I know how to use strace to get an idea of what goes wrong, but I understand that without a basic understanding of C you can't really make optimal use of such tools. > even looking at the source. You can use gdb to pull out tricks deemed > impossible by others. You can use valgrind to point out memory leaks > or use-after-free. All that possible by the fact you've learned C, and > you can't get more closely to OS than using C. > > That does not invalidate the fact that learning C as a first > programming language can be pretty hardcore (I was taught BASIC first, > then Pascal), and for the complex program you'll probably want > something else as by today's standards C has poor result/effort ratio. I can't recall saying that C would be my first programming language. I started writing short programs in BASIC when I was 5 or 6, and learnt Pascal, Smalltalk and a little 6502 + 68K assembler at school. Through the years I've also picked up a little Perl and a bit of shell by sheer necessity. > And please think of the children :) Teaching young ones something as > volatile and ever-changing as Python (or, $DEITY forbid, Ruby) can be > considered cruel and abusive :) "Won't _somebody_ think of the _children?!" :) My cat is walking on my keyboard now, demanding attention. Best not to ignore him any longer. :) Petter -- "I'm ionized" "Are you sure?" "I'm positive."
pgpm5Nz7PNdP9.pgp
Description: OpenPGP digital signature
