Unix 101: Introduction to UNIX (I.E. Unix for Windows Users)

Unix 101: Introduction to UNIX (I.E. Unix for Windows Users)

Unix 101: Introduction to UNIX (i.e. Unix for Windows Users) Mark Kegel September 7, 2005 1 Introduction to UNIX (i.e. · solid and basic understanding of unix Unix for Windows Users) ¥ not enough time in the regular school year to teach you this and teach you everything • The cold hard truth else you need to know ¥ and also because the CS department · this course is NOT sponsored by the CS doesn’t have the resources, or want to of- dept. fer this course on its own - maybe they will · you will not receive any credit at all in the future ¥ we needed something to do with our sum- • introduce ourselves to the students mer vacation · Should introduce myself and Marshall ¥ the goodness of our hearts, etc. ¥ are seniors in CS and CS/Math • To make this perfectly clear... • And what do we think we’re doing... · will not teach you to program · will not teach you emacs tricks; will provide · here to teach you fundamentals of Unix a reference sheet · to teach you the student to teach yourself ¥ not about learning to use a single applica- about unix tion · to give you the necessary basics to go out ¥ will not solve world hunger, peace, or to be and teach yourself whatever you might need a better person to know to get work done on unix · catch a fish for a man vs teach a man to 2 Computers on Campus fish · trying to follow Mudd philosophy - teach • Available computing resources you to teach yourself · graphics lab • who this course is targeted at · terminal room - printer · AC and LAC labs - printer and scanner · those students who have never worked with unix before and would to get some experi- · Engineering lab - to be avoided ence doing • Servers · those students who have had some experi- · odin, thuban, banshee ence but would like to learn more · knuth, knuth, wilkes, muddcs, arc, cortana · someone who is lost, confused, and looking ¥ knuth is the one you care about for spiritual enlightenment ¥ main server everyone will be working on - ¥ mashall has a great religion for you to join give specs. - we sin so jesus didn’t die in vain • People to know ¥ ask around, see who has what experience · Tim Buchheim and Roger Wiechman • Some reasons to learn about Unix ¥ Bring them milk, cookies and be nice to · linux and OS X them, they make things work 1 3 Philosophy and History of ¥ about as different as mango, peach, kiwi, straw- UNIX berry ice-cream and peach, strawberry, kiwi, mango ice-cream with bits of vanilla • Origin of Unix ¥ especially that way in linux, its all just annoying ¥ computers were mainframes that people ¥ it doesn’t matter what you run, what we are worked at, much like knuth going to teach you here will apply across most ¥ teletypes - basically a typewriter plugged unixes though not all into a computer • What is Unix? · Ken Thomson implemented the first UNIX environment ¥ unix in some sense is not an operating sys- tem but rather a programming language ¥ had been working at Bell Labs on a project (C)/philosophy/interface (POSIX) called Multics (Multiplexed ...) ¥ the development of C (and the internet) are ¥ Unix was kind of a castrated Multics - much all connected smaller because invented on an underpow- ered system - PDP-7 ¥ unix is (kind of) C, the Standard C Li- brary, and POSIX (Portable Operating Sys- ¥ became popular mainly because it was dis- tem Standard) which is the API that pro- tributed to Universities grammers use to interact with the system ¥ will want to display Unix timeline kernel • Unix Today ¥ the design and implementation of unix also follows a certain philosophy about how ¥ programmers environment - because of this an OS should be designed, how programs is extremely powerful should be written, etc. · still very much a tinkerer’s environment ¥ everything else is just historical baggage · unix encourages and support ”hacking” the ¥ makes unix extremely flexible - can start system from scratch with a new implementation but still same ”design” · Fundamentally multi-user and multitasking ¥ designed in the days of mainframe environ- ¥ what would be some good philosophical ideas to ments when many people would all work on follow when building an OS? one computer system ¥ what are some good rules of thumb? what trade- ¥ we still use the same model in many ways offs do you want to make? with knuth • Unix philosophy ¥ clean, simple interface · programs should be designed to operate to- ¥ Chalkboard exercise gether ¥ unix is also multi-layered in design, mean- · output of one could be used as the in- ing that functionality separated into levels put to another going from the hardware to the user, stuff ¥ text streams -> universal input is also abstracted aways at each layer · Programs are viewed as simple tools that ¥ user | (shell, other programs) | OS(kernel) combined will do complex tasks | hardware · each program should do one thing ex- ¥ at top user at bottom hardware, what’s in- tremely well between? ¥ LEGO blocks - simple tools but can create ¥ scales very well - from supercomputers to very complex systems microwaves (embedded systems) ¥ another analogy - hammer, wrench, saw ¥ two different flavors of unix - BSD (FreeBSD, ¥ Avoid the ginormous programs that do ev- OSX) and System V (Solaris, Linux) erything 2 ¥ Windows has this problem (think of Of- make commands and programs interact fice) with each other, not just from treating ¥ Windows programs also don’t integrate each as a fixed black box. very nicely - no pipeline · Richness of utilities (over 400 standard · want to keep everything as simple as possi- ones) often overwhelms novices. Doc- ble umentation is short on examples and tutorials to help you figure out how to · KISS - keep it simple stupid use the many tools provided to accom- ¥ this applies everywhere - both in OS plish various kinds of tasks.” interaction (system calls and library ¥ ”Unix *is* user-friendly. It’s just picky calls) and in program creation about its friends.” · separate mechanism from policy ¥ very true - have to be able to understand ¥ Unix (and programs that run on Unix) the system at some intuitive level to be able provide a mechanism to do something to work with it but do not lock you down to one policy ¥ also if you don’t like something you can fix ¥ policy - how a program should look and it, maybe not easily, but you can fix it behave ¥ users have to decide on policy ¥ What makes a system secure? What needs to be ¥ games and GUIs are generally a good protected? examples - mods and skins ¥ What is a good way of protecting things, like ¥ walk up to some one and try to scare them property? Ownership · principle of least surprise • Unix security · applications will generally produce no output if successful · concept of ownership - everything on the · applications that fail will make it evi- system is owned by someone dent (sirens if necessary) ¥ ownership implies responsibility - so who- · programs should do the least surprising ever owns these files is in the end responsi- thing ble for them ¥ do not try to feed emacs a stray cat · protect users from one another and from · there is no ”one true way” - unix is not doing dangerous things perfect! · protect privacy -> data ¥ unix has things wrong with it, and · protect work -> programs things that unless you understand will · protect programs and files from users - or cause you a great deal of pain rather allow only certain users to do certain ¥ The Unix Hater’s Handbook - written things to expose the flaws in unix ¥ security: not perfect, can break, and will · from a stanford site: cause you to scream a few months down the http://pangea.stanford.edu/computerinfo/ line unix/overview/advantages.html · ”The traditional command line shell in- terface is user hostile 4 Types of users · designed for the programmer, not the casual user. ¥ what powers is each user going to have? · Commands often have cryptic names ¥ do you need to have a class of users that manage and give very little response to tell the the system? user what they are doing. Much use of special keyboard characters - little ty- ¥ what kinds of users are there going to be? pos have unexpected results. • administrative users · To use Unix well, you need to under- stand some of the main design features. · root - is the best known account of this type Its power comes from knowing how to - aka The SuperUser 3 · complete control over everything on the sys- ¥ for security reasons do not want to have a tem web server running as root · can do anything that they want (mostly) - ¥ what if someone owned your web daemon - has to respect file perms. would own your system...is bad · can become any user on the system ¥ unless you’re setting up your own system ¥ loaded gun with the safety off, easy to shoot don’t have to worry about this yourself in the foot ¥ and even then still don’t really have to · is a standard account on every worry about this since most of these users UNIX/Linux/BSD machine will have been created by default - rarely have to create a new system user · used for system administra- tion/maintenance ¥ now that we have users, how do we manage · what this is will cover later them? ¥ any other user however can be granted ad- ¥ should all users be lumped in to one category? min privileges, so root isn’t strictly neces- sary to run a system • groups ¥ why would you want? what if you tried to ¥ are the unix solution to separating respon- delete all the files on the system? shouldn’t sibilty amoung users be able to do · every user on the system belongs to one or more groups ¥ should there be different types of normal users? is there a better way to organize responsibility? · these are

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    36 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us