4/3/2017 Introduction to Operating Systems Instructor 1A. Administrative introduction to course • Background (non-academic) 1B. Why is OS a required course? – professional engineer w/over 40 years in OS • commercial Unix/Linux, SMP and distributed 1C. What is an Operating System? • development, leadership, staff and executive roles 1D. Operating Systems Principles – I am here because I love teaching and I love OS 1E. A (very) Brief History of Operating Systems • Getting in touch with me (in order) – email: mark.kampe@gmail.com – GoogleTalk: mark.kampe@gmail.com – office: BH 4531M, TR 1-1:50, 4-4:50 Course Introduction 1 Course Introduction 2 This Course Learning Objectives • This is a revised curriculum with new goals: • We started with a list of learning objectives – understanding and exploiting OS services – over 300 concepts, issues, approaches and skills – foundation concepts and principles • All activities in this course are based on them – common problems that have been solved in OS – the reading has been chosen introduce them – evolving directions in system architecture – the lectures are designed to reinforce them • This is not a course in how to build an OS – the projects have been chosen to exercise them – you will not read or write any kernel-mode code – the exams will test your mastery of them – you will not study or build any parts of a toy OS • Study this list to understand the course goals • Use this list to guide your pre-exam review Course Introduction 3 Course Introduction 4 Course Web Site(s) Reading and Quizzes http://web.cs.ucla.edu/classes/spring17/cs111 • Reading • course syllabus – Remzi Arpaci-Dusseau OS in Three Easy Pieces • reading, lecture and exam schedule – numerous monographs to fill in gaps • copies of lecture slides – average 40pp/day, but there is one 84 page day • supplementary reading and study materials • Quizzes https://ccle.ucla.edu/course/view/17S-COMSCI111-1 – 4-8 short questions on the assigned reading • announcements – online (CCLE), due before start of each lecture • (per lecture) on-line quizzes – purpose: to ensure that you do the reading • projects descriptions and submission • discussion forum (and lecture topic requests) Course Introduction 5 Course Introduction 6 1
4/3/2017 Lectures Projects • Format: • Lectures will not – individual programming projects w/questions – re-teach material well-covered by the reading – written in C to be run on Linux systems • Lectures will be used to – one will require you to buy an Intel Edison kit – clarify and elaborate on the reading • Goals: – explore implications and applications – Develop ability to exploit OS features – discuss material not covered by the reading – Reinforce principles from reading and lectures – Develop programming/problem solving ability – discuss questions raised by students – Practice software project skills • All lecture slides will be posted on-line – to aid you in your note-taking and review Course Introduction 7 Course Introduction 8 Projects Instructor/TA Responsibilities • Subjects • Instructor: lectures, readings, and tests P0 – a warm-up to confirm your readiness P1 – processes, I/O and IPC (2 parts) – ask me about issues related to these P2 – synchronization (2 parts) – TA’s do not follow the reading and lectures P3 – file systems (2 parts) • TA’s: projects P4 – Embedded Systems/Internet of Things (3 parts) – they will do all assistance and grading • broken into ~weekly deliverables – all questions on projects should go to them – start each project as soon as you finish previous – be ready to discuss problems on Friday – finish the project over the weekend Course Introduction 9 Course Introduction 10 Course Grading Late Assignments & Make-ups • Quizzes • Basis for grading: – no late quizzes accepted, no make-ups – quizzes 10% – but I usually drop the lowest score – projects 45% (P0 5%, all others 10%) • Labs – midterm 15% – each student gets FIVE slip days (usable on any project) – final exam part-1 15% – after that score drops by 10% per late day – final exam part-2 15% • Exams • I do not grade on a curve – alternate times or make-ups may be schedulable (with – I do look at score distribution to set break points advanced notice) Course Introduction 11 Course Introduction 12 2
4/3/2017 Academic Honesty Course Load • Reputation: THE hardest undergrad CS class • Acceptable: – Fast pace through much non-trivial material – study and discuss problems/approaches w/friends • Expectations you should have – independent research on problems/approaches – lectures 4-6 hours/week • Unacceptable: – reading 3-6 hours/week – submitting work you did not independently create – projects 3-20 hours/week (or failing to cite your sources) – exam study 5-15 hours (twice) – sharing code or answers with class-mates • Keeping up (week by week) is critical – using reference materials in closed-book exams – Catching up is extremely difficult • Detailed rules are in the course syllabus Course Introduction 13 Course Introduction 14 Academic Honesty – Projects Why is OS a required course? • Do your own projects • Most CS discussions involve OS concepts – If you need additional help, ask the instructor • Many hard problems have been solved in OS • You must design and write all your own code – synchronization, security, scalability, distributed computing, dynamic resource management, … – Do not ask others how they solved the problem – the same solutions apply in other areas – Do not copy solutions from the web, files or listings • Few will ever build an OS, but most of us will: – Cite any research sources you use – set-up, configure, and manage computer systems • Protect yourself – write programs that exploit OS features – Do not show other people your solutions – work w/complex distributed/parallel software – Be careful with old listings – build abstracted services and resources – troubleshoot problems in complex systems Course Introduction 15 Course Introduction 16 Relation to Other Courses Why do I build Operating Systems? • They (and their problems) are extremely complex • Build on concepts and skills from other courses • They are held to high pragmatic standards: – data structures, algorithms, computer architecture – programming languages, assembly language programming – performance, correctness, robustness, scalability, availability, maintainability, extensibility • Provide you with valuable foundation concepts – they demand meticulous attention to detail – processes, threads, virtual address space, files • They must also meet high aesthetic standards – capabilities, synchronization, leases, deadlock, granularity – general, powerful, and elegant (these characteristics • Prepare you to work with more advanced subjects make the complexity manageable) – data bases, file systems, and distributed computing • The requirements are ever changing – security, fault-tolerance, high availability – exploit the capabilities of ever-evolving hardware – computer system modelling, queuing theory, ... – enable new classes of systems and applications • Worthy adversaries attract interesting people Course Introduction 17 Course Introduction 18 3
Recommend
More recommend
