Спецкурс "Программное обеспечение GNU\Linux", в рамках факультетского проекта UNИX. Сайт http://uneex.ru. На сайте есть дальнейшая информация, например, о списке рассылки с небольшим трафиком и со многим всяким интересным. Что касается спецкурса этого года, то мы тут посовещались тесной компанией, и решили, что стоит запустить по новой цикл спецкурсов "от простого и начального уровня до сложного". Просто потому, что те люди, которые в прошлом году посещали спецкурсы, они в большом количестве закончили. Было изрядно пятикурсников. Вторая причина - давно не было базового курса по Linuxу. Третье - захотелось пересмотреть базовые представления о том, как надо рассказывать про Linux. Лектор - сотрудник лаборатории программного оборудования (не знает, что это такое) кафедры АСВК. Потом лет пять работал сисадмином факультета. Зовут Георгий Курячий. Основное место работы - ALTLinux, работает, не знает кем (всем по не многу).

О чем предполагается говорить базовом начальном курсе. Если замахиваться не на одноразовый курс, а на линейку, то, по всей вероятности, подход "поставьте волшебную Ubuntu, и нажмите волшебную кнопку, и вам будет хорошо" неинтересен. Рассказывать о том, как нажать кнопку "мне будет хорошо" неинтересно в плане отсутствия перспектив. Лично лектору хочется рассказать об этом самом странном LINUXе так, чтобы он оказался нестрашным, ну, или страшным, но интересным. И подходить к этому делу не столь академически, как "LINUX это ос, у ос архитектура, и т.д.". Лектору кажется, что для начала надо бы разобраться с тем зверем, который называется LINUX, который перед нами появился внутри большой или не очень коробочки.

Поговорим про.

  1. Пользовательский интерфейс. В голом виде оно бессмысленно, потому что мы им пользуемся. Без междумордий управлять компьютером сложно, они очень полезно. Но представляют ли они академический интерес - вряд ли.
  2. Особенность свободного ПО как такового, в представлении лицензионно-правовом, сообщества, бытования этого ПО в мировом информационном пространстве, и т.д. Лектор надеется показать, что концепции и свойства свободного ПО диктуют многие свойства и концепции GNU/Linux.
  3. Чтобы достаточно хорошо ориентироваться с теми самыми LINUXами, необходимо освоить не только интерфейсы, коих там много, но и немножко заглянуть в архитектуру. Причём, понятие архитектуры двуликое - архитектура ос на базе GNU/Linux (как она работает) и архитектура того, из каких компонентов она конструируется (архитектура дистрибутива, почему оно работает: дистрибутив, хранилище, пакеты). Весьма важная тема.
  4. Информационное пространство.

Немаловажная тема для того чтобы освоить и начать ориентироваться в LINUXах и свободном ПО. Есть несколько специфик, главная из них состоит в том, что, если мы имеем дело с людьми, которые нам хотят чего ни-будь впарить, они нам все уши проедят, какими программами делать себе хорошо. При этом они не будут рассказывать про все варианты, расскажут только про свои пять. Забивать гвозди резинкой, воздушным шариком или микроскопом - человек выберет микроскоп. LINUX это в первую очередь сообщество и с сообществом придётся работать.

У всех этих 4 тем есть недостаток, который хотелось бы изживать. В такой форме это история-нарратив. Как оно бывает. Не то, что бы это было само по себе неинтересно. Но, чтобы как-то шагнуть дальше, необходимо пытаться найти в каждой из этих тем управляющий принцип, инвариант. Проще всего понять на примере 100500 продуктов. Ну не 100500, а в среднем дистрибутиве 8 000 пакетов. Все их запоминать -- либо не запомним, либо сойдём с ума, либо уже сошли с ума. Поэтому, разговаривая про пакеты, надо говорить не про все, и даже не про самые важные, а про какой-то принцип, который нам позволит не изучать все кнопки на свете, а понять, как ориентироваться во всём этом. Наверно инвариант не лучший термин, можно ещё нагло назвать это "управляющим принципом".

История техники насчитывает много сотен лет. Чарльз Бэббидж придумал машину для сбрасывания трупов коров с железнодорожных путей, разработал сетку тарифов для ЖД. Он же построил первую механическую вычислительную машину, правда запнулся о невозможность достаточно качественно и много вытачивать шестерёнок.

По началу, время создания компьютера примерно равнялось времени создания ОС. Лет пять. Потом стало очевидно, что за 5 лет ОС становится ненужной, потребности будут другие, отрасль очень быстро растёт. Именно с тех пор ведёт своё начало термин операционная система. Вот есть компьютер на котором можно программировать в кодах или на фортране. А ещё им можно operate как инструментом, например не вы сами печатаете, а компьютер за вас печатает.

В начале 60-ых поняли, что так нельзя. Одним из примеров, полезных для понимания, был MULTICS, с огромными затратами ресурсов. Встал вопрос -- как только появляется компьютер общего назначения, должна появится ОС общего назначена, выглядящая примерно одинаково на разных машинах. Кен изобрёл язык C, а Денис хотел играть с Startrack, поэтому пришлось изобрести многозадачность. При этом они ещё работали. Потом пошло-поехало, за подробностями обращаю вас в Google по истории UNIX.

Они допилили UNIX, но тут пришёл великий популяризатор науки и программирования Керниган. И сказал вы пишите ОС на кодах машины, а вы напишите на языке B, который изобрели. Она будет медленной, но всем пофиг на пользовательские задачи при этом можно писать на чем хочешь, зато можно будет использовать ОС на других архитектурах, почти не переписывая.

В 70-ых этот подход показал свою эффективность. Выяснилось, что совершенно необязательно пять лет строить машину, а потом пять лет ОС. Более того, ОС можно постоянно совершенствовать. Это сильно расширило объём кода, который входит в понятие ОС. Если у вас есть одна команда, которая пишет ОС, то невозможно ее без конца раздувать начнёт работать закон больших чисел, будут множиться ошибки, и т.д. Объём кода, который может написать одна команда можно оценить, например по FreeBSD. Размер core team там около 7 человек.

Когда компьютеры были большими, а скорости их работы маленькими, никто не задумывался о лицензировании. Разработка ПО была высоконаучной деятельностью. Кудесники в белых халатах программировали что-то, понятное ещё человек для 80 в мире. Квантовых информатиков сегодня больше, чем программистов тогда. Когда же начала появляться массовость, появилась идея продавать программные продукты. Выяснились две вещи:

  1. Бизнес на продаже ПП особенный. У него почти нет расходной части. Вы даже на СDюки можете не тратиться, продавать через Интернет. И почти нет критериев, какой приход будет с расхода. Никаких критериев, кроме анализа рынка, не существует.
  2. Если вы хотите продавать, то разработка учёными в белых халатах не помогает. Вдруг другие учёные вздумают тоже ее продавать? В два раза дешевле?

В начале 80-ых случился раскол. Разработка продолжала идти по старому. С другой стороны появилась закрытая разработка.

Свойства закрытой разработки:

  1. Отсутствие информационной открытости, закрытый исходный код. Документация существует в основном внутренняя, да и то не всегда. Следствие -- количество разработчиков весьма ограничено. Ограничено ровно теми деньгами, которые компания готова потратить на этот ПП. Из-за этого подход к разработке через индусов -- нанять много-много индусов, они напишут много-много исходного кода. В противовес этому, чем более открыта разработка, тем шире круг разработчиков. По сути дела, на сегодняшний день, не существует успешных открытых проектов, у которых команда сидит рядом в офисе. Как правило это люди из разных стран. Количество людей, открыто работающих над проектом может быть весьма большим. Коммитеров в ядро несколько тысяч.
  2. Важное понятие, которое нам понадобится-- собственность на исходный код. В открытой разработке один из бонусов при привлечении к разработке это то, что участвующий может использовать код для себя. Различие только в авторстве, а права на код у вас одинаковые. Предоставление как можно большего числа свобод в плане использования это бонус, который привлекает людей в сообщество. С точки зрения закрытой разработки есть свободное лицензирование. Важно, чтобы собственность на вот то самое, которое потом начнёт продаваться, была сосредоточена в руках корпорации. Без собственности на ПП бизнеса на продаже экземпляров сделать нельзя.

Не зря зашла речь о разделении практик разработки. Вроде бы речь идёт о бизнес-решении -- возможностью торговать ПП. Это должно было бы не относиться к производственному процессу, но уже здесь мы видим, что то, как именно будет производиться манипуляция лицензиями в конце, влияет на то, как будет производиться разработка. Это разделение всегда будет, и оно будет усиливаться. Разделение не в качестве продукта, но в внутренних потребительских свойствах, из-за различий в технологических процессах.

Это произошло в 80-ые годы. С тех пор случились две эпохальные вещи. В конце 80-ых накал страстей вокруг "принадлежит ли программисту программа, которую он только что написал"(оказывается нет), достиг апогея, и некоторые программисты стали предпринимать попытки изобрести защиту ПП от его отторжения от автора. И, совершенно закономерно, такая защита нашлась на том же самом поле, на котором действовали продавцы ПП. Продавцы получали права благодаря лицензиям. Вы покупаете особый вид лицензии на ПП, фактически, берёте его в аренду. Эпохальное событие конца 80ых -- лицензия которая не запрещала, а, наоборот, законодательно устанавливала права на использование ПП. Таких лицензий сейчас много. Оно положило конец претензиям "кто у кого чего украл". Некоторые undead компании, которые до сих пор пытаются эксплуатировать "кому принадлежат права на UNIX и нет ли кода UNIX в Linux". На сегодняшний день передовой край подобного рубила это патенты, но о них сейчас говорить не будем. Это произошло в начале 90-ых.

Другое эпохальное событие того же времени - объединение информационного пространства Интернетами. Это - возможность привлечь практически любого человека, который сидит дома и пьёт чаёк, к общему делу. Индусов только мало, у них нет свободного времени, они сидят и программируют.

Сейчас ОС в голом виде не использует почти никто. Разве что какой-нибудь маршрутизатор, да и там веб-интерфейс. Самое важно следствие объединения информационного пространства объём ОС существенно меньше, чем объём дистрибутива. Дистрибутив больше ОС на пару порядков. Почему это прорыв? Потому что сообщество научилось эксплуатировать открытую разработку так, чтобы преодолевать закон больших команд. То, что попадает на компьютеры, это не ОС, это результат установки дистрибутива, в котором полным-полно прикладного ПО, не являющегося Linux ни в коей мере.

В спецкурсе речь пойдёт, в первую очередь, о дистрибутивах, потому что это передний край самоорганизации разработчиков. Как устроен, как работает, какие возможности предоставляет пользователю, и как разрабатывается дистрибутив. Хотя. Как поставить нынче WINду? Поставить ZverCD! Правда, если к вам после такой установки придут люди в погонах, то они уйдут не одни, а с деньгами.

На что хочется обратить внимание в истории. Закрытый способ разработки теряет динамику развития. Никто не придумал, как сделать его ещё более эффективным. Открытый способ не исчерпал ещё своих возможностей. С этим связан прорыв на рынок Linux-based ОС. 5 лет назад Linux был только у гиков. Сегодня человек может использовать Ubuntu и не знать, что такое Linux.

LecturesCMC/GnuLinuxSoftware2011/00 (last edited 2013-06-27 09:46:03 by FrBrGeorge)