Re: [Professional IT Security Providers - Exposed] QuietMove ( D - )

[reepex <reepex () gmail com>]

if you noticed he was reading tanebaum's book about minix. If you would look
at the book you would see he relies heavily on source code and actually has
the code in the back of the book so that he can refer to it constantly. In
other books i agree you do not have to know C, but for this book, if you do
not know C, you will end up understanding at a very very high level what
message passing is and thats about it.

On Jan 2, 2008 12:39 PM, <Valdis.Kletnieks () vt edu> wrote:

> On Tue, 01 Jan 2008 12:33:36 CST, reepex said:
>
> > Is this list up to date?  It makes it seem as if you are learning basic
> > linux commands, sed, and basic perl. Also why are you reading operating
> > system design and implementation when you do not know C?
>
> C is not a prerequisite for understanding operating systems design. It's
> only
> needed if the particular operating system you're working with implements
> its
> internals in C.
>
> What is more important is understanding the *concepts* - things like
> locking,
> and race conditions, and how fine-grained locking you need/want for a
> filesystem. Having one big lock is a lot easier, but causes contention -
> having
> a lot of little locks can cause deadlocks, especially in error handlers.
>  What
> does the filesystem code do if (for example) it gets 2/3 of the way
> through the
> rename of a file, and encounters an I/O error while writing out the
> removal of
> the old name of the file?  What are the trade-offs required for an
> operating
> system to support jitter-free multimedia applications (the first thing to
> learn
> is that throughput, latency, and jitter are intertwined, and it's very
> difficult to do all 3 well at the same time)?
>
> It's also important to understand that there are approaches other than
> Windows
> and Unix/Linux - IBM's VM and MVS systems have been around for a long
> time, and
> have a lot to tell us about other choices that can be made.  There's still
> a
> lot of VMS running out there in scattered corners as well - and that
> system had
> a lot of concepts that one should understand, at least well enough to know
> why
> "my favorite system didn't do it that way because..." (Hint - consider how
> and
> why SYS$FOO variables worked in VMS, and why they're so hard to get
> working
> correctly under Linux - they're *not* exactly the same as Unix/Linux
> environment variables, and as such provide both problems and solutions
> that
> environment variables don't).
>
> Bonus points for knowing that VMS was mostly written in Bliss/32 or some
> such,
> and VM and MVS were a mixture of assembler and (later on) PL/S.  No C
> knowledge
> needed for those critters...
>
> Even when the system *is* written in C, you don't need to be a C guru to
> understand what's going on. Maurice Bach's "The Design of the Unix
> Operating
> System" is probably one of the classic texts - but you don't need to know
> C any
> better than "read C code snippet as pseudocode" to follow it.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/