Categories of posts

Saturday, September 18, 2010

linuxNUS Hackers' Workshop series - The UNIX philosophy

The below is what I've learnt from the workshop lecture by Prof. Michael Brown, at NUS LT19 on 17/09/2010 6.30pm - 8pm.

The driving idea of UNIX

  • portable

    • Unix written in C, with some assembly code.

    • Not welded to the computer used

  • multi-tasking, multi-user

  • simple and light-weight

  • use of”flat” plain text files – user-readable code

  • large number of software tools

  • hierarchical file system


Sending messages to other processes: echo “” > dev/pts/

File/device notification:

  • files: can read and write chars or blocks of data

  • devices:

    • char devices (eg keyboard) – read chars, not seekable

      • /dev/pts10

    • block devices (eg HDD) – read blocks of data, seekable

  • pseudo devices:

    • /dev/zero: produces zeros

    • /dev/null: ignores all input, has no output

    • /dev/random: produces a stream of rand output


Unix shell

  • allows “shell scripting”

    • can write “for loop” to create 10 .txt files.

for i in 0 1 2 3 4 5 6 7 8 9

do

touch $i.txt

  • can tie processes together


Selective rules for programming:

  • rule of modularity:

    • write simple modules connected via clean interface

  • rule of clarity:

    • clarity >> cleverness

  • rule of composition:

    • design programs to be connected with other programs

  • rule of user input:

    • do not make programs WAIT for user input

  • rule of simplicity:

    • add complexity only if you must

  • rule of transparency:

    • make inspection and debugging easy – a good man page helps.

  • rule of robustness:

    • program should work well, but if it fails, make sure it fails gracefully.

    • Do input checking

  • rule of least surprise:

    • in interface design, always do the least surprising thing

    • stick with convention (+ means add)

    • avoid excessive features and novelty (max of 3 clicks to go to ANY file on iPod)

  • rule of silence:

    • when program has nothing surprising to say, it should say nothing.

  • rule of repair:

    • when you must fail, fail noisily and as soon as possible

  • rule of (late) optimisation:

    • get it working before optimising it.

No comments:

Post a Comment