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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 02 Jan 2008 13:39:21 -0500
From: Valdis.Kletnieks@...edu
To: reepex <reepex@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Professional IT Security Providers -
	Exposed] QuietMove ( D - )

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.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/