[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Book questions



On Mon, 13 Apr 2015 20:21:49 +0300
Reco <recoverym4n@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."

Attachment: pgpAZeNakpe7R.pgp
Description: OpenPGP digital signature


Reply to: