On Saturday, Nov 29, 2003, at 15:10 US/Pacific, Saskia van der Elst wrote:
Rob said:
I would love to know of a description of the Unix /philosophy/. Once sucked in to the surrounding ideas everything seems obvious, but I know of no book that explains stuff like processes, forking, signals and so on that underly the basic ideas of Unix.
In essence it is a much more simple system than something like MS Windows, but perhaps it seems so simple to those who know that it doesn't need any explanation?
Have fun with this one:
http://research.microsoft.com/~daniel/unix-haters.html
My complements to Saskia for the well placed comedy. Anything that has 'the scream' associated with it and computing stuff is a good place to start.
But to step back for moment to Rob's question, I think he is jumping in a bit 'late' in the core cult of unix. Folks might want to look at one of the classic FAQ's about it: <http://www.faqs.org/docs/artu/ch01s06.html>
The root cause of Unix is that it is very hard to code in Machine Language, and only slightly better to code in Assembler, a point that is unpleasantly known to those who have been on the 'kernel' side of the OS, and/or have been obliged to be EXTREMELY CLEAR about what exactly the chunk of code is suppose to do.
So one of the first things out the door is that unix was hacked by folks who wanted to simplify their collective lives. What this meant was separating the 'responsibility' of who did what how, and thus we get the first break between
the kernel and user_space
allow me to illustrate with our pet favorite types of commands
open()
read()
write()
close()Most folks really do not like to have to read all of
the specifications for all of the types of devices
out there that can be fobbed off as 'file systems',
so it is nice to leave that stuff 'in the kernel' and
buy the overhead of making a kernel call. { check on
the number of scsi, ide, eide, atapi, etc, etc, devices
there are out there, then marry in some raid smack that
can between you and your 'logical filesystem' and the
actual thing that retains the persistent data.This of course will help you understand one of those witty unix mantra,
in the dark all things are just fd's ( file descriptors )
since it was not too much of a leap to notice that the same things that 'work' with regards to 'real things' like file systems, happen to be the same sorts of commands that work for less real things, like network connections, and interprocess connections. If you will step back, you notice that the four basic commands are what you will be using with things like ipc's as well as 'networking code'.
So for some the start was that Unix lifted the users off the 'file system' and the need to know all of the painful minutia about how to write some 'bunch of memory' onto a spinning disk. The gory details are things we leave to divice driver freaks. They like reading tech specs and converting it into painfully arcane device drivers.
This of course also means that distinction between just a 'regular piece of application layer programme' and 'the kernel' - a notion that would take the DOS folks a while to sort out - since it took them a while to understand that not everything can or should be run as 'privileged' - and how to actually implement the idea of having more than one thing that is queued up to access the CPU. When one does the comparison of how many 'instructions' a CPU can move, vice the number of 'blocks of data' that can be done in I/O one notices that the average CPU spends most of it's time waiting for some I/O stuff. When even the best primates average on the order of say 30 'words per minute' - or about 150 characters - that is still on 2.5 char per second. NOT what I would call a viable I/O subsystem. Nothing against Primates, some of my best friends are Primates.
So we now have a CPU on the edge of angst and ennui, and need a way to keep it amused. It is at this point in the process that 'processes' become 'useful' as a mental construct. Depending upon *nix implementation either the kernel is the first programme loaded, and hence is PID 0, or we will see it in other ways, but as a general rule of thumb 'init' will be running as PID 1, and it will 'initialize' all things that are not the kernel itself - hence why, as the process of last resort, eveything sooner or later traces it's ancestry back to PID 1.
Layer into this the idea of differenciated 'users' where there is the 'privileged user' "root", and the rest of the folks, and the basic 'process table' becomes a bit more readable - and it really is basically little more than that - a Freaking Table, and it is indexed by 'PID' - and has some other junk that gets associated with it. But unless the Kernel Crashes or Hangs, all the rest of the processes can go and choke themselves as far as the "system" is concerned.
When one does not have a system where there is this distinction, any one piece of running code can wedge it all. What many know as the imfamous 'blue screen of death'.
The shell of course is a Sop to the Primates, so that they can play with the computer, and preen about having some margin of significance. But let us be realistic, at best they are random number generators. The old school tie distinctions between ttys and ptys, is mostly lost to history, since who still actually uses a 'teletype' to make a hard wired connection??? So just as the Evil Unix Monkies stashed all the technical differences of file systems in the kernel, the same they did to the Primates and their various Forms of "terminals" as the slow speed I/O devices....
The GUI of course offered the re-assurance to the Primates that they would be able to 'interact' with computers in a more Primate Way, but let's be honest. In a traditional *nix environment, it is really, well, just a fancy way to Piss Pids into the proc table on ptys.
Ironically, while MIT's Xwindows was suppose to offer us a cross platform GUI that would lift the Primates off of needing to know how to write code to the OS specific implementation of how they do FD munching, the reality seems to be that HTTP/HTML have offered folks the other way off the OS, so that the Primates can go "poke, poke, ook, ook, see the pretty spinning coloured widgets" without having to understand the underlying OS.
So that we can suck this back into the Perl Space Properly, and especially since we just had that "Bash Moment" a bit back - one of the unpleasantries of "shell scripting" was that each of those 'awk' or 'grep' or what evers was itself a new PID in the proc table, henc a line like
VAR=`ps -aef | grep $FOO | egrep -v grep | awk '{print $1}'`
meant that on top of the currently running 'script' there would be FOUR MORE PIDS that would have to be spawned. WOW UGLY, WAY PAINFUL! and for each of them, in this case since it is a pipeline, the stdin and stdout of them have to be all nicely aligned by the Kernel as it goes pissing them out the door.... WOO Ugly...
HTH.
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
