НАЧАЛО КОНСПЕКТИКОВ ПО ОСЯМ
---
Первая лекция
---
[Полезный линк](https://studfiles.net/preview/1910846/)
Самое базовое определение операционных систем звучит так:
Операционная система - базовое системное програмное обеспечение, управляющее работой вычислительного узла и реализующее интерфейс между аппаратным обеспечением, программным обеспечением и пользователем.
Этапы развития операционных систем:
1. Программные диспетчеры.
Программные диспетчеры - это системные программы, управляющие порядком ввода программ. Диспетчер осуществлял запуск заданий по очереди, по принципу FIFO (если ты не расшифровал, "кыш" от Скакова).
2. Добавление прерываний.
Прерывание - сигнал, поступающий от внешнего устройства в центральный процессор, сообщающий о некотором событии, приостанавливая текущий поток команд и передающий управление обработчику прерываний.
3. SPOOL, Однопрограммная пакетная обработка
SPOOL - Simultaneous Peripheral Output On Line — одновременный вывод информации
Однопрограммная пакетная обработка - ???
Системный вызов - обращение прикладной программы к операционной системе с требованием предоставить дополнительный ресурс или выполнить привелегированную операцию
4. В 1963 году был создан MCP
---
Вторая лекция
---
4. (Продолжение)
На момент середины 50-60 гг, операционнные системы начали быть актуальны. Период поиска. Было создано много компьютеров, и под каждый нужно было создать операционную систему. Код написанный под одну операционную систему, не работал на другом. Задача - создать операционную систему, которая поддерживает язык высокого уровня. Bell (Белла) - подразделение AT & T. Они взялись за решение проблемы разработки универсальной операционной системы. В конце 60-ых гг, три разработчика пытаются создать язык программирования (впоследствии С), и операционную систему (впоследствии Unics). В конце 69 года, unics Edition One. Запуск происходит 1 января 1970 года (начало отсчета операционных систем). В 72 году они переписывают это все на B, получают unics edition Two. В начале 73 года появляется появляется Edition 3, с уже встроенным языком С. В 75 году появляется 5 версия на полном С. Как раз последняя версия переименнована из Unics -> Unix. 78 год - создание 7 версии с Bash. Университет Беркли надавил на правительство в тяжелое время и отбил патент на Unix. Теперь у них есть своя ветвь BSD (знаменита Free BSD, Open BSD, Net BSD). Стенфордский университет. SUN - Stenford University Network, компания, созданная университетом. Создается SUNOS. Тем временем AT & T создает SystemV (five). Новая фича - многопоточное программирование. В это время Стенфорд договаривается с AT & T, и выбивает себе часть кода Систем файв. Пишет новую систему под названием SUNSolaris (теперь есть его детище Open Solaris). Так же от Систем файв отходит три ветви - IRIX, AIX, HP-UX. 70-80-начала 90 появляется новая волна борьбы за свободу (теперь FreeSoftware). Ричард Столман (4 свободы программного обеспечения). CopyRight "(c)". Он создает CopyLeft. Он создает GNU (Gnu is Not Unix). Они создают так же и gcc c лицензией GPL (мега лицензия, ее сложно обойти). Спор Линуса и Танебаума:
<начало эпической байки>Жил был Таненбаум и решил он выступить однажды в 1992 году, что микроядра вытесняют монолитные ядра, а один малоизвестный аспирант решил опровергнуть это (этим аспирантом был ~~Альберт Эйнштейн~~ Линус Торвальдс). Свои размышления они вылили в великий холивар в своих ньюсчатиках. Линус проигрывал и решил доказать свою точку зрения практикой <конец эпичной байки>
И Ричард "помогает" Линусу, и теперь есть GNU/Linux. Байки про холивар о создании ядра для ОС. Затем вышли две ветки rpm и debian.
Возратимся в 1985 год. Стив Джобс покидает Apple (его выгняли из Совета Директоров) и создает компанию Next и создает ОС NexTSTep. В 96 году он вернулся в Apple, и происходит цепочка NexTSTep -> Darvin -> MacOS.
Поговорим про Microsoft. "создать операционную систему, которая будет простая в эксплуатации". Создается DoS. Затем создается Windows (убогий интефейс, убогие возможности были). Windows 98 - первая успешная реализация операционная система. Windows NT4 - успешная операционная система для серверов.
---
Третья лекция
---
Архитектура операционных систем.
5 уровней архитектур.
1. Функциональная архитектура - как сгруппировать операции
2. Информационная архитектура -
3. Системная архитектура - что будет реализованно и как. Программный компоненты, и как они будут взаимодействовать.
4. Архитектура данных - структуры данных. Архитектура данных.
5. Программная архитектура -
Все это архитектура операционной системы. Обеспечение надежности, производительности и безопасности, и исполнение пользовательского ПО. Операционная система вовлечена в задачу хранения данных. Доступ к телекоммуникационным ресурсам. Организовать диалог с пользователем. Организация интерфейса между приложениями и аппаратным обеспечением. Обеспечение доступа к устройствам воода/вывода. Контролируемый доступ к файлам. Обнаружение ошибок и их обработка. Учет использования ресурсов. Генерация эффективного распределение ресурсов.
Свертка - !k = alpha * k1 + beta * k2 + ...
Цикл Деминга. Средство исправления ошибок и файлов
Обработка времени. Исправления в коде ядра и латания дыр
---
Четвертая лекция
---
В данный момент разработка операционной системы затруднена из-за денежных проблем. Сумма 180 млрд долларов - примерная стоимость разработки операционной системы (Linux Fedora был примером). РВС - атрибуты процессора.
Первый блок -
Второй блок - информация о ассоциированных ресурсах.
Третий блок - история этого процесса
Концепция - Shorter Job First. Сейчас работает подобная система.
Механизм планирования - механизм планирования очередей к ресурсам.
Подсистема управления ресурсами.
Подсистема управления памятью. Подраздел - подсистема управления виртуальной памяти. Подраздел - механизм защиты памяти.
Подсистема управления файлами. Механизм преобразования имен в символьные пути файлов. Механизм управления каталогами.
Подсистема управления внешними устройствами. Универсальный механизм ввода/вывода. Механизм (драйверов - Windows, модули ядра - Linux). Система Plug&Play (позднее Plug&Pray). Подсистема защиты данных и администрирования. Log in - locical income. Механизм аудита (пассивный и активный). Подсистема пользовательского интерфейса.
---
Пятая лекция
---
В детстве мы замечали, что порой мы используем код по нескольку раз. Так зачем мы переписываем их по нескольку раз? Давайте разберем основы проектирования программой архитектуры. Принцип модульной организации. Принцип функциональной избыточности - мы должны обеспечить большими ограничениями наши подпрограммы. Для чего это делается? Заметим, что с ходом лет мы обретаем новые возможности в сфере компьтеров. И, вероятно, нам нужно, что бы теперь новые программы поддерживали новые изменения. Принцип параметрической организации. Код ядра. Первое свойство - защита, его нельзя изменить. Второе - мы размещаем этот код в операционке. Монолитная архитектура ядра. Ядро имеет целостное пространство. Одна программы видит другую. Самая базовая модель - трехслойная. Слой утилит, слой сервисов, слой главной программы.
---
Шестая лекция
---
Процесс - совокупность наборов исполняющихся команд, ассоциированных с ними ресурсов, и контекстов исполнения, находящихся под управлением операционной системы. Системный вызов - обращение к ядру. Кольца защиты в основном используют 0 и 3 уровень (второй и первый уровень уже почти не используются). Теперь все обратились к ПОТОКАМ. Процесс содержит несколько потоков (тредов (threads)). Нам кажется, что мы занимаемся каким-то порядком, но на самом деле нет, мы работаем с потоком. Операционная система не просто читает потоками, а управляет ими. Но она видит их, но не знает, что в них. Но тред это не базис, базис это ВОЛОКНО (fiber). Однако этого тоже недостаточно, и над process появилось (Job - Windows, CGroup - Linux).
Управление процессами
1. Самая первая функция для управления процессами - это создание процесса. В любой операционной системе процесс создается другим процессом ("рождение процесса").
Linux. Init - pid=1. Бывают процессы зомби - они уже мертвы, адресное пространство уже забрали и все, его уже нет, но он живой. Это некоторый бич Linux.
Windows. Там все по другому. Есть некоторый диспетчер процессов, который отвечает за все. Теперь зомби нет, но есть другие проблемы. Можно создать процесс, который обладает большими правами, чем диспетчер. Там же только один диспетчер отвечает за все.
2. Обеспечение потоков процессов ресурсами. Достаточно просто.
3. Изоляция процессов.
4. Планирование процессов и потоков.
5. Организация межпроцессного взаимодействия.
6. Синхронизация процессов и потоков
7. Завершение процесса. Это тоже процесс.

---
НЕОЖИДАННЫЙ ПЕРЕХОД
---
Девятая лекция
---
Два основных ресурса - время и память. В чем же сложность выделять память? Есть две точки зрения (два критерия). Они противоречат друг другу.
| Название | Регистры | Кеш 1 уровня (L1) | Кеш 2 уровня (L2) | RAM | HDD |
| -------- | -------- | ----------------- | ----------------- | ---- | ----- |
| Время доступа | 0.1нс | 1нс | 5нс | 50нс | 5мс |
| Размер | ~байт | ~Кбайт | ~Мбайт | ~Гбайт | ~Тбайт |
Так как же мы все таки преобразуем адреса? У нас есть символьные адреса --(транслятор)-> виртуальная адресация --(перемещающий загрузчик/динамическое преобразование)-> физические адреса
Методы разделения памяти
1) С использованием внешней памяти
1.1) Страничный обмен. В каждой странице хранится несколько флагов.
2) Без использования внешеней памяти
2.1) Фиксированная память - просто выделяем куски памяти и распределяем процессы. Проблема - мы неравномерно распределяем процессы на равномерные куски.
2.2) Динамическая память - процессы сами запрашивают память и радуются на своем куске. Проблема - память разрежена, и мы можешь забить память отрезками по 1 через 99 и процесс с памятью 100 не сможет сьесть ничего и будет голодным.
2.3) Перемещаемая память - мы перемещаем отрезки динамической памяти. Проблема - нужно приостанавливать программу, и переместить, и сожрать немного времени.
---
Десятая лекция
---
**"напомню, что мы находимся в курсе про операционные системы"** (ц) рандомные фразочки
Тема: управление постоянной памятью
Google file system (не входит в курс, но интересно)
Наверняка, вы удивлены тем, что вы однажды сохранили файл на компьютере, перезаписали его на диск, затем снова на другой компьютер. Удивительно, но файл всегда хранится по разному, но вы все равно можете открыть его. Удивлены? Разберем это.
VLS - Линейно адресуемое пространство


Мы освобождаем блоки - снова записываем - получается много свободных мест размера 1 - дефрагментация диска.
Как мы будет организовывать память?
Если в виде большого массива - проблема, которая только что была прописана.
Если в виде связного списка - проблема - если вы потеряли блок - вы очень больно проиграли. Поиск элемента - долго.
Табличное размещение файлов - File allocation table - FAT16, FAT32 (циферка в конце - кол-во битов для хранения адресов) - хранится FAT табличка со ссылками ОТДЕЛЬНО.
Метод индексных дескрипторов - ext2. Есть superblock, i-node, bitmap, data.

Для каждого файла есть свой i-node. Хранит 15 байтов помимо имени, дат и так далее. Хранит ссылки на первые 12 байт. 13 байт хранит косвенную ссылку на следующие блоки. 14 тоже. Только теперь получаем получем косвенную ссылку на комвенные ссылки на реальные данные (то есть можно хранить большие файлы). 15 так же, только теперь тройной уровень косвенных ссылок.

bitmap хранит битовую карту i-node, что бы быстро узнавать, какие блоки свободные, а какие нет.
Теперь рассмотрим ext-3. Режим журналирования. Три типа журналов - основной (главный), ...

---
Одиннадцатая лекция
---
Распределенные операционные системы
5 уровней прозрачностей. Идея в том, что сами программы не знают про распределенную ОС.
1) Прозрачность расположения. Наше приложение не может знать, чьи ресурсы использует.
2) Прозрачность миграции. Мы можем перемещать ресурсы без изменения их имен (или приложение) (оно даже не знает, что его перенесли).
3) Прозрачность разложения. У нас не может быть информации (мы не можем узнать), сколько копий есть нашего приложения.
4) Прозрачность конкуренции. Приложения не должны никак знать, что они разделяют ресурсы еще с кем то.
5) Прозрачность параллелизма. Если выполняются несколько процессов параллельно, то они не должны знать о друг друге.
Узел вычисления может знать информацией о соседних узлах, но далеко не о всех. Не должно быть неявного предположения о существованию глобальных часов. Алгоритм центрального сервера. Распределенная система устроена таким образом, что любой запрос попадает в этот сервер. Миграционный алгоритм. У меня нету никаких централизованных таблиц, а происходит такое: если запрос вызывает адрес памяти, и он не существует в адресной памяти. Трешинг. Алгоритм размножения для чтения. Я тоже так же буду опрашивать все, если найду, скопирую ее себе. Фантомное чтение. Нумерует все запросы-сообщения через сквозную нумерацию и затем отправляет ВСЕМ. Узел, получив запрос, вносит изменения. Иерархическое именование. Нужно, что бы для любой пары событий была некоторая определенность - кто был раньше.
---
Двенадцатая лекция
---
*Еее Huawei*
Project Oberon - полезная книжка
Dragon Book - компиляторы.
Очень советуют Forth (это язык программирования).
Jai - (game "the Witness") - тоже советуют.
---
Тринадцатая лекция
---