Как зовут создателя операционной системы linux
Вся история Linux. Часть I: с чего все началось
В этом году ядру Linux исполняется 27 лет. ОС на его базе используют многие корпорации, государственные, исследовательские учреждения и дата-центры по всему миру.
За более чем четверть века вышло немало статей (в том числе и на Хабре), рассказывающих о разных отрезках истории Linux. В этой серии материалов мы решили выделить наиболее значимые и интересные факты, связанные с этой операционной системой.
Начнем с разработок, которые предшествовали Linux, и истории появления первой версии ядра.
Эпоха «свободного рынка»
Появление Linux считается одним из важнейших событий в истории открытого ПО. Рождение этой операционной системы во многом обязано идеям и инструментам, которые формировались и «зрели» десятилетиями в среде разработчиков. Поэтому для начала обратимся к истокам «опенсорсного движения».
На заре 50-х большая часть программного обеспечения в США создавалась сотрудниками университетов и лабораторий и распространялась без каких-либо ограничений. Это делалось с целью упрощения обмена знаниями в научной среде. Первым опенсорсным решением того периода считается система A-2, написанная для ЭВМ UNIVAC Remington Rand в 1953 году.
В те же годы сформировалась первая группа разработчиков свободного ПО — SHARE. Они работали по модели «совместного однорангового производства». Результатом труда этой группы ближе к концу 50-х стала одноименная ОС.
Эта система (и другие продукты SHARE) пользовалась популярностью у производителей компьютерного оборудования. Благодаря политике открытости они могли предложить клиентам не только аппаратное, но и программное обеспечение без дополнительных затрат.
Приход коммерции и рождение Unix
В 1959 году компания Applied Data Research (ADR) получила заказ от организации RCA — написать программу для автозаполнения блок-схем. Разработчики выполнили работу, но не сошлись с RCA в цене. Чтобы не «выбрасывать» готовый продукт, в ADR переделали решение для платформы IBM 1401 и начали самостоятельно его реализовывать. Однако продажи шли не очень хорошо, так как многие пользователи ждали бесплатную альтернативу решению ADR, которую планировали в IBM.
В ADR не могли допустить выпуск бесплатного продукта с аналогичной функциональностью. Поэтому разработчик Мартин Гетц (Martin Goetz) из ADR подал патент на программу и в 1968 году первым в истории США получил его. С этого момента принято отсчитывать эпоху коммерциализации в индустрии разработки — из «бонуса» к оборудованию ПО превратилось в самостоятельный продукт.
Приблизительно в то же время небольшая команда программистов из Bell Labs начала работу над операционной системой для мини-компьютера PDP-7 — Unix. Unix создавали в качестве альтернативы другой ОС — Multics.
Последняя была слишком сложной и работала только на платформах GE-600 и Honeywell 6000. Переписанная на языке СИ Unix должна была стать портативной и более простой в использовании (во многом благодаря иерархической файловой системе с единым корневым каталогом).
В 50-х холдинг AT&T, в состав которого на тот момент входила Bell Labs, подписал соглашение с правительством США, запрещающее корпорации продавать программное обеспечение. По этой причине первые пользователи Unix — научные организации — получали исходный код ОС бесплатно.
AT&T отдалилась от концепции свободного распространения ПО в начале 80-х. В результате вынужденного разделения корпорации на несколько компаний запрет на продажу ПО перестал действовать, и холдинг прекратил бесплатное распространение Unix. Разработчикам грозили исками за несанкционированный обмен исходным кодом. Угрозы не были беспочвенными — с 1980 года компьютерные программы стали объектом авторского права в США.
Не всех разработчиков устраивали условия, которые диктовали в AT&T. Поисками альтернативного решения занялась группа энтузиастов из Калифорнийского университета в Беркли. В 70-х учебное заведение получило лицензию от AT&T, и энтузиасты начали создавать на его основе новый дистрибутив, который впоследствии стал Unix Berkeley Software Distribution, или BSD.
Открытая Unix-подобная система возымела успех, на что сразу обратили внимание в AT&T. Компания подала в суд, и авторам BSD пришлось удалить и заменить весь задействованный исходный код Unix. Это немного замедлило распространение Berkeley Software Distribution в те годы. Последняя версия системы вышла в 1994 году, но сам факт появления свободной и открытой ОС стал важной вехой в истории опенсорсных проектов.
/ Flickr / Christopher Michel / CC BY / Фото обрезано
Назад — к истокам свободного ПО
В конце 70-х сотрудники Массачусетского технологического института написали драйвер для принтера, установленного в одной из аудиторий. Когда бумага застревала и создавалась очередь из заданий на печать, пользователи получали уведомление с просьбой устранить проблему. Позже в отделе появился новый принтер, для которого сотрудники захотели добавить такую функцию. Но для этого нужен был исходный код первого драйвера. Штатный программист Ричард Мэттью Столлман (Richard M. Stallman) запросил его у коллег, но получил отказ — выяснилось, что это конфиденциальная информация.
Этот незначительный эпизод, возможно, стал одним из судьбоносных в истории свободного ПО. Столлман негодовал из-за сложившегося положения вещей. Его не устраивали ограничения, накладываемые на обмен исходным кодом в ИТ-среде. Поэтому Столлман решил создать открытую операционную систему и позволить энтузиастам свободно вносить в нее изменения.
В сентябре 1983 года он объявил о создании проекта GNU — GNU’s Not UNIX («GNU не Unix»). В его основе лежал манифест, который послужил и базисом для лицензии на свободное программное обеспечение — GNU General Public License (GPL). Этот шаг стал началом активного движения за открытое ПО.
/ Flickr / Christopher Michel / CC BY
Рождение Linux и первых дистрибутивов
В 1991 году молодой программист из Хельсинкского университета Линус Торвальдс осваивал Minix. Его эксперименты с ОС переросли в работу над совершенно новым ядром. 25 августа Линус устроил открытый опрос группы пользователей Minix о том, что их не устраивает в этой ОС, и анонсировал разработку новой операционной системы. В августовском письме есть несколько важных тезисов о будущей ОС:
Далее последовала череда обновлений. В октябре того же года была выпущена версия ядра 0.02, а в декабре — 0.11. Изначально Linux распространялся без лицензии GPL. Это означало, что разработчики могли пользоваться ядром, модифицировать его, но не имели права перепродавать результаты своих трудов. Начиная с февраля 1992 года, все коммерческие ограничения были сняты — с релизом версии 0.12 Торвальдс изменил лицензию на GNU GPL v2. Этот шаг Линус позже назвал одним из определяющих факторов успеха Linux.
Популярность Linux в среде разработчиков Minix росла. Некоторое время обсуждения велись в фиде comp.os.minix сети Usenet. В начале 92-го создатель Minix Эндрю Таненбаум запустил в сообществе спор об архитектуре ядер, заявив, что «Linux устарел». Причина, по его мнению, заключалась в монолитном ядре ОС, которое по ряду параметров уступает микроядру Minix. Еще одна претензия Таненбаума касалась «привязки» Linux к линейке процессоров x86, которая, по прогнозам профессора, должна была кануть в небытие в ближайшее время. В полемику вступил сам Линус и пользователи обеих ОС. В результате спора сообщество разделилось на два лагеря, а у приверженцев Linux появился свой фид — comp.os.linux.
Сообщество занималось расширением функциональности базовой версии — разрабатывались первые драйверы, файловая система. Самые ранние версии Linux умещались на двух дискетах и состояли из загрузочного диска с ядром и корневого диска, который устанавливал файловую систему и несколько базовых программ из инструментария GNU.
Постепенно сообщество начало разрабатывать первые дистрибутивы на базе Linux. Большинство ранних версий создавались энтузиастами, а не компаниями.
Первый дистрибутив — MCC Interim Linux — был создан на основе версии 0.12 в феврале 1992 года. Его автор — программист из Компьютерного центра университета Манчестера — назвал разработку «экспериментом» с целью устранить некоторые недостатки в процедуре установки ядра и добавить ряд функций.
Вскоре после этого число пользовательских дистрибутивов значительно возросло. Многие из них остались локальными проектами, «прожившими» не более пяти лет, например, Softlanding Linux System (SLS). Однако были и дистрибутивы, которым удалось не только «закрепиться» на рынке, но и во многом повлиять на дальнейшее развитие опенсорсных проектов. В 1993 году состоялся релиз двух дистрибутивов — Slackware и Debian, — которые дали старт серьезным переменам в индустрии свободного ПО.
Debian создал Иан Мердок (Ian Murdock) при поддержке Free Software Foundation Столлмана. Он задумывался как «изящная» альтернатива SLS. Debian поддерживается по сей день и является одной из самых популярных разработок на базе Linux. На его основе, в свою очередь, был создан ряд других важных для истории ядра дистрибутивов — например, Ubuntu.
Что касается Slackware, это — еще один ранний и успешный проект на базе Linux. Его первая версия вышла в 1993 году. По некоторым оценкам, через два года на долю Slackware приходилось уже около 80% установок Linux. И десятилетия спустя дистрибутив оставался популярным среди разработчиков.
В 1992-м в Германии была основана компания SUSE (аббревиатура от Software- und System-Entwicklung — разработка программного обеспечения и систем). Она первой начала выпускать продукты на базе Linux для бизнес-клиентов. Первым дистрибутивом, с которым стали работать SUSE, как раз был Slackware, адаптированный для немецкоязычных пользователей.
Именно с этого момента начинается эпоха коммерциализации в истории Linux, о которой мы поговорим в следующей статье.
История Linux. Вкратце о главном
Корни Linux прослеживаются ещё с годов века. Точкой отсчёта можно считать появление операционной системы Unix в году в США в фирме Bell Laboratories, дочернем подразделении компании AT&T. Unix стала основной для большого количества операционных систем промышленного класса. Самые основные из них отображены на этой временной шкале:
Linux же больше всего обязан своей жизнью двум проектам — GNU и Minix.
История проекта GNU началась в сентябре года. Основоположник проекта GNU, Ричард Столлман (Richard M. Stallman) работал в это время в лаборатории искусственного интеллекта Массачусетского технологического института (Massachusetts Institute of Technology, MIT, Cambridge, Massachusetts). Столлмана называют одним из самых выдающихся программистов нашего времени.
В той среде, к которой принадлежал Столлман, было принято свободно обмениваться программами и их исходными кодами. Лицензия же на Unix от AT&T, к примеру, стоила 40 000 долларов. Позволить себе купить её могли только достаточно крупные фирмы. А без обладания лицензией, программист не имел права использовать исходные коды системы в своих разработках. Это препятствовало обмену идеями в сфере программирования и сильно тормозило процесс создания программ, поскольку вместо того, чтобы позаимствовать готовый кусок кода для решения той или иной задачи, разработчик программы был вынужден писать эту часть кода заново, что сродни изобретению колеса.
Столлман решил изменить это положение вещей в программировании. В году он объявил о начале разработки проекта GNU, целью которого было создание полностью открытой операционной системы:
После Дня Благодарения я начинаю писать Unix-совместимую программную систему GNU (Gnu’s Not Unix), которую буду предоставлять свободно(!) всем, кто может её использовать. Нужна помощь в виде времени, денег, программ и оборудования.
GNU будет содержать ядро плюс все утилиты, необходимые для того, чтобы писать и запускать программы на Cи: редактор, оболочку, компилятор Cи, линкер, ассемблер и ещё несколько вещей. После этого будут добавлены программа форматирования текста, YACC, игра Empire, электронная таблица и сотни других вещей. Мы надеемся включить всё, что обычно поставляется с Unix-системами, и всё, что ещё может оказаться полезным, в том числе онлайновую и печатную документацию.
GNU будет способна запускать программы Unix, но не будет идентична Unix. Мы будем вносить в систему улучшения, основываясь на нашем опыте работы с другими операционными системами.
Аббревиатура GNU расшифровывается как «GNU — это не Unix» (GNU is Not Unix). Unix всегда была несвободным ПО, то есть она лишает своих пользователей свободы сотрудничества, а также контроля над своими компьютерами (как Windows в наши дни). Чуть позже Столлман написал свой знаменитый Манифест GNU, который стал основой для лицензии GPL (GNU General Public License). Роль этой лицензии нельзя переоценить, она изменила всю компьютерную индустрию.
К году в рамках проекта GNU было создано большинство компонент, необходимых для функционирования свободной операционной системы. Помимо текстового редактора Emacs, Столлман создал компилятор gcc (GNU C Compiler) и отладчик gdb. Будучи выдающимся программистом, Ричард Столлман в одиночку сумел создать эффективный и надёжный компилятор, который превосходит по своим качествам продукты коммерческих поставщиков, создаваемые целыми группами программистов. Поскольку изначально при его создании ставилась задача обеспечения переносимости, сегодня существуют версии этого компилятора практически для всех операционных систем. Позже были созданы компиляторы и для других языков программирования, включая C++, Pascal и Fortran. Поэтому сейчас аббревиатура GCC расшифровывается как GNU Compiler Collection.
Как пишет Ричард Столлман: «К году система GNU была практически закончена, не хватало только одного из базовых компонентов — ядра.» Ожидалось, что ядро (оно получило название Hurd) будет реализовано как набор серверных процессов, работающих на Mach — микроядре, создаваемом в Университете Карнеги-Меллона, а затем в Университете штата Юта. Начало разработки откладывалось в ожидании выпуска Mach, которое, как было обещано, будет выпущено в виде свободно распространяемого программного обеспечения. Но его появление всё откладывалось, и тут появилось ядро, разработанное финским студентом Линусом Торвальдсом, получившее название Linux. Линус создал его в попытках усовершенствовать свою домашнюю операционную систему Minix, о которой стоит упомянуть отдельно.
Minix
В течение годов персональные компьютеры на основе микропроцессора Intel, оснащённые операционными системами от Microsoft, заняли господствующее положение на рынке настольных систем и захватили также существенную долю рынка серверов — традиционной сферы применения Unix-систем. Компьютеры на основе Intel и Intel-совместимых процессоров достигли вычислительной мощности, сравнимой с мощностью рабочих станций с Unix. Но большинство коммерческих Unix-систем не имели версий, способных работать на оборудовании Intel. Производители Unix обычно тесно сотрудничали с производителями конкретных процессоров или даже имели долю собственности в компаниях, производивших эти процессоры, а поэтому были заинтересованы в использовании своих собственных разработок. Примерами могут служить линейки процессоров SGI и MIPS. 
Поскольку аппаратные возможности персоналок стремительно возрастали, естественно, что рано или поздно должны были появиться варианты Unix для компьютеров на основе Intel-совместимых процессоров. Один из таких вариантов Unix-подобной операционной системы, который сыграл особую роль в истории Linux, был разработан в январе года Эндрю Таненбаумом (Andrew S. Tanenbaum), профессором Университета Врие, Амстердам, Нидерланды. Таненбаум был одним из ведущих специалистов в области разработки операционных систем. Свою операционную систему Minix (Миникс) он разработал как учебное пособие, на примере которого показывал студентам внутреннее устройство реальной операционной системы.
Конечно, как операционная система, Minix не была верхом совершенства. Она была ориентирована на микропроцессор Intel 80286, который в то время господствовал на рынке. Но у неё было одно очень важное качество — открытые исходные коды. Каждый, кто имел книгу Таненбаума «Операционные системы», мог изучить и проанализировать 12 000 строк кода, написанного на языке Си и на ассемблере. Это был тот редкий случай, когда исходные коды не были заперты под семью печатями в сейфах разработчика. Великолепный автор, Таненбаум сумел вовлечь самые выдающиеся умы компьютерной науки в обсуждение искусства создания операционных систем. Minix можно было приобрести и отдельно от книги, она могла быть реально установлена на персональный компьютер. Студенты компьютерных факультетов по всему миру корпели над книгой Таненбаума, вчитываясь в коды с целью понять, как работает та самая система, которая управляет их компьютером. И одним из таких студентов был Линус Торвальдс.
Linux
В году, Линус Торвальдс, финский студент, чрезвычайно увлёкся идеей написать совместимое с Unix ядро операционной системы для своего персонального компьютера с процессором Intel. Прототипом для будущего ядра стала операционная система Minix: совместимая с Unix операционная система для персональных компьютеров, которая загружалась с дискет и умещалась в очень ограниченной в те времена памяти персонального компьютера.
августа года Линус Торвальдс направил первое сообщение о своей разработке в группу новостей comp.os.minix:
From: torvaldsSklaava.Helsinki.Fi (Linus Benedict Torvalds)
To: Newsgroups: comp.os.inix
Subject: Чего вам больше всего не хватает в minix?
Summary: небольшой опрос для моей операционной системы Message-ID:
Date: 25 августа 1991 г., 20:57:08 GMT
Organization: University of Helsinki
Привет всем пользователям minix!
Я пишу (бесплатную) операционную систему (это просто хобби, ничего большого и профессионального вроде gnu) для AT 386(486). Я вожусь с этим с апреля, и она, похоже, скоро будет готова. Напишите мне, кому что нравится/не нравится в minix, поскольку моя ОС на неё похожа (кроме всего прочего, у неё — по практическим соображениям — то же физическое размещение файловой системы).
Пока что я перенёс в неё bash (1.08) и gсс (1.40), и всё вроде работает. Значит, в ближайшие месяцы у меня получится уже что-то работающее, и мне бы хотелось знать, какие функции нужны большинству. Все заявки принимаются, но выполнение не гарантируется 🙂
PS. Она свободна от кода minix и включает мультизадачную файловую систему. Она НЕ переносима (используется переключение задач 386 и пр.) и, возможно, никогда не будет поддерживать ничего, кроме АТ-винчестеров, потому что у меня больше ничего нет 🙁
Название «Linux» новая система получила следующим образом. Самого Торвальдса несколько смущало созвучие этого названия с его именем, поэтому он пытался назвать свою разработку Freax. Это название можно обнаружить в файле kernl/Makefile версии 0.11, и в исходных кодах других программ. Но Ари Лемке, который предоставил место для выкладывания системы на FTP сайте, назвал каталог pub/OS/Linux. И это название закрепилось за новой ОС.
Тот факт, что Линус выложил код своей ОС в интернет, был решающим в дальнейшей судьбе Linux. Хотя в году интернет ещё не был так широко распространён, как в наши дни, зато пользовались им в основном люди, имеющие достаточную техническую подготовку. И уже с самого начала Торвальдс получил несколько заинтересованных откликов.
Примерно в феврале года Линус высказал просьбу ко всем, кто уже пользовался или тестировал Linux, прислать ему открытку. Таких открыток было получено несколько сотен со всех концов света — из Новой Зеландии, Японии, Нидерландов, США. Это говорило о том, что Linux начала приобретать некоторую известность.
Вначале к разработке присоединились сотни, потом тысячи, потом сотни тысяч добровольных помощников. Система уже не была просто игрушкой для хакеров. Дополненная массой программ, разработанных в рамках проекта GNU, ОС Linux стала пригодна для практического использования. А то, что ядро системы распространялось под лицензией GNU General Public License, гарантировало, что исходные коды системы останутся свободными, то есть смогут копироваться, изучаться и модифицироваться без опасения нарваться на какое-либо преследование со стороны разработчика или какой-то коммерческой фирмы. Этот факт привлекал в ряды пользователей и сторонников Linux всё новых последователей, в первую очередь из числа студентов и программистов.
К этому времени сформировалась отдельная конференция в интернете, посвящённая Linux, — comp.os.linux. Энтузиасты образовали множество групп пользователей и в начале года вышел первый номер журнала «Linux Journal». Linux привлекла внимание промышленных фирм и несколько небольших компаний начали разрабатывать и продавать собственные версии Linux.
Первоначально Линус Торвальдс не хотел продавать свою разработку. И не хотел, чтобы её продавал кто-то другой. Это было чётко прописано в уведомлении об авторских правах, помещённом в файл COPYING самой первой версии — 0.01. Причём требование Линуса налагало значительно более жёсткие ограничения на распространение Linux, чем те, которые провозглашались в лицензии GNU: не разрешалось взимать никаких денег за передачу или использование Linux. Но уже в феврале года к нему стали обращаться за разрешением брать плату за распространение дискет с Linux, чтобы покрыть временные затраты и стоимость дискет. Кроме того, необходимо было считаться и с тем, что при создании Linux использовалось множество свободно распространяемых по интернету инструментов, самым важным из которых был компилятор GCC. Авторские права на него оговорены в общественной лицензии GPL, которую изобрёл Ричард Столлман. Торвальдсу пришлось пересмотреть свое заявление об авторских правах, и, начиная с версии 0.12, он тоже перешёл на использование лицензии GPL.
С технической точки зрения, Linux представляет собой только ядро Unix-подобной операционной системы, отвечающее за взаимодействие с аппаратной частью компьютера и выполнение таких задач, как распределение памяти, выделение процессорного времени различным программам и так далее. Кроме ядра, операционная система включает в себя множество различных утилит, которые служат для организации взаимодействия пользователя с системой. Успех Linux как операционной системы во многом обусловлен тем, что к году в рамках проекта GNU уже было разработано множество утилит, свободно распространяемых в интернете. Проекту GNU не хватало ядра, а ядро, скорее всего, осталось бы невостребованным, если бы отсутствовали необходимые для работы утилиты. Линус Торвальдс оказался со своей разработкой в нужном месте в нужное время. И Ричард Столлман прав, когда настаивает на том, что операционную систему следует называть не Linux, а GNU/Linux. Но название Linux исторически закрепилось за этой ОС, поэтому мы тоже будем называть её просто Linux (не забывая о заслугах Столлмана и его сподвижников).
P.S. Я честно пролистал на Хабре все 36 страниц поисковой выдачи по запросу «история linux» и не нашёл ничего целостного по теме, что показалось мне довольно странным, учитывая популярность системы среди хабровчан. Информация по крупицам собиралась мной со всего интернета, отделены зёрна от плевел и, надеюсь, будет вам интересна.
UPD: Мне было сделано верное замечание по поводу временной шкалы. Я её переработал, заодно ещё раз проверил все даты. Думаю, что стало лучше и очевиднее.
30 лет Линукса. Интервью с Линусом Торвальдсом. Часть 1
Тридцать лет назад Линусу Торвальдсу был 21 год, он был студентом Хельсинского университета. Именно тогда он впервые выпустил ядро Linux. Анонс этого события начинался так: «Я делаю (свободную) операционную систему (просто в качестве хобби, большой и профессиональной она не будет…)». Три десятилетия спустя все топ-500 суперкомпьютеров в мире работают под Linux, равно как и более 70% всех смартфонов. Linux явно стал и большим, и профессиональным.
В течение тридцати лет Линус Торвальдс руководил разработкой ядра Linux, вдохновив бесчисленное множество других разработчиков и опенсорсных проектов. В 2005 году Линус также создал Git, чтобы было проще управлять процессом разработки ядра, с тех пор Git превратился в популярную систему контроля версий, которой доверяют бесчисленные опенсорсные и проприетарные проекты.
Следующее интервью – одна из серии бесед с лидерами опенсорса. Линус Торвальдс ответил на вопросы по электронной почте, поразмышляв о том, что он узнал за годы руководства большим опенсорсным проектом. В первой части акцент сделан на разработке ядра Linux и Git. «[Linux] был личным проектом, который вырос не из какой-нибудь большой мечты создать новую операционную систему,« — объясняет Линус, — «а в буквальном смысле несколько спонтанно, ведь я изначально просто сам хотел разобраться во входах и выходах моего нового железа для ПК.«
Что касается создания Git и его последующей передачи Джунио Хамано для дальнейшей доработки и поддержки, Линус отметил: «Не собираюсь утверждать, что программирование – это искусство, поскольку на самом деле это большей частью просто хорошая «инженерия». Я горячо верю в мантру Томаса Эдисона об «одном проценте таланта и девяноста девяти процентах упорного труда»: почти все зависит от мелких деталей и ежедневной рутинной работы. Но есть и эта эпизодическая составляющая, называемая «талант», этот «хороший вкус», который сводится не только к решению какой-либо задачи, но и к стремлению решить ее чисто, аккуратно и да, даже красиво. У Джунио есть как раз такой «хороший вкус».
Итак, читайте первую часть этого интервью (есть и вторая). В оригинале она выходит через неделю после первой, и во второй части Линус исследует те уроки и озарения, которые приобрел за три десятилетия во главе разработки ядра Linux.
Разработка ядра Linux
Джереми Эндрюс: Linux повсюду, он вдохновил целый мир опенсорса. Разумеется, так было не всегда. Вы прославились тем, что выпустили ядро Linux еще в 1991 году, скромно сообщив об этом в Usenet в разделе comp.os.minix. Десять лет спустя вы написали увлекательную и глубоко личную книгу под названием «Ради удовольствия: Рассказ нечаянного революционера«, где разобрали большую часть этой истории. В августе этого года Linux празднует тридцатилетие! Это захватывающе, поздравляем! В какой момент на вашем пути вы осознали, что Linux – это уже гораздо больше, чем «просто хобби»?
Линус Торвальдс: возможно, прозвучит слегка потешно, но, на самом деле, это произошло очень рано. Уже к концу девяносто первого (и определенно к началу девяносто второго) Linux вырос значительно сильнее, чем я ожидал.
Да, на тот момент у Linux было, пожалуй, всего несколько сотен пользователей (и даже «пользователей» слишком громко сказано – люди просто возились с ним), и это, возможно, звучит странно, учитывая, насколько Linux вырос впоследствии. Но во многих отношениях, для меня лично, большой поворотный момент наступил, когда я осознал, что другие люди в самом деле пользуются Linux, заинтересованы им, и операционная система начала жить своей жизнью. Люди начали присылать патчи, и система начала делать гораздо больше, чем я изначально мог представить.
Думаю, X11 была портирована на Linux где-то в апреле девяносто второго (не верьте мне на слово, когда я припоминаю даты – слиииишком давно дело было), а еще один серьезный шаг свершился, когда у системы вдруг появился GUI и целый новый набор возможностей.
Чтобы дать широкий контекст – скажу, что в самом деле не начинал с наполеоновских планов или больших ожиданий. Это был личный проект, который вырос не из какой-нибудь большой мечты создать новую операционную систему, а в буквальном смысле несколько спонтанно, ведь я изначально просто сам хотел разобраться во входах и выходах моего нового железа для ПК.
Поэтому, когда я выпустил ту самую первую версию, посыл в самом деле был «смотрите, что у меня получилось» и, разумеется, я надеялся, что другие найдут мою работу интересной, но это не была по-настоящему серьезная, практически-ориентированная ОС. Это была скорее «проверка концепции» и просто личный проект, который я к тому моменту разрабатывал уже несколько месяцев.
Причем, переход от этого «личного проекта» к продукту, который оказался по-настоящему востребован у других, по которому мне стала приходить обратная связь (и багрепорты), а также кое-какие патчи – все это стало для меня большой переменой.
Просто пример одного по-настоящему фундаментального аспекта: исходная лицензия на копирайт формулировалась примерно так: «допускается распространение в виде исходников, но не за деньги».
Дело в том, что для меня одна из проблем заключалась в реальной дороговизне коммерческого Unix (да, для бедного студента, потратившего все деньги на новый ПК, так и было), поэтому для меня было серьезно и важно обеспечить доступность исходного кода (так, чтобы люди могли с ним пошаманить), и я хотел, чтобы проект оставался открытым для людей вроде меня, которые просто не могли позволить себе альтернатив.
И я изменил лицензию в конце девяносто первого (или, может быть, в самом начале девяносто второго), поскольку нашлись те, кто хотел распространять систему на дискетах в локальных группах пользователей Unix, но при этом хотя бы отбить расходы на дискеты и компенсировать себе время, потраченное на копирование. Причем, я понял, что это, очевидно, совершенно оправданно, и что важнее всего было обеспечить не «полную бесплатность», а «свободную доступность исходников».
К чему это привело: мало того, что люди стали распространять Linux на собраниях в группах пользователей Unix, но и в считанные месяцы появились первые дистрибутивы для дискет, например, SLS и Slackware.
По сравнению с теми первыми, по-настоящему фундаментальными изменениями, все дальнейшие можно считать «пошаговыми». Разумеется, некоторые из этих шагов были весьма велики (систему взяла на вооружение IBM, под мою систему портировали Oracle DB, состоялись первичные коммерческие предложения Red Hat, Android расцвел на смартфонах, т.д.), но лично мне эти события все равно казались не столь революционными, как «люди, которых я даже не знаю, уже используют Linux».
Дж. А.: Вы когда-нибудь сожалели, что выбрали именно такую лицензию, либо завидовали тому, какие деньги сделали другие люди и компании на вашем детище?
Во-первых, мне вполне хватает. Я не баснословно богат, но я – хорошо оплачиваемый программист, занимаюсь любимым делом, сам составляю себе расписание. Не бедствую.
Но не менее важно, что я на 100% уверен: именно такая лицензия во многом определила успех Linux (и Git, если уж на то пошло). Думаю, всем причастным гораздо приятнее знать, что все в равных правах, и никого такая лицензия не выделяет.
Существует немало таких проектов с «двойной лицензией», где за исходным владельцем остается коммерческая лицензия (»можете использовать это в вашем проприетарном продукте при условии, что будете отчислять нам роялти»), но, с другой стороны, продукт также доступен по GPL-подобной лицензии для использования в опенсорсных проектах.
Думаю, в такой ситуации действительно сложно выстроить сообщество, так как те, кто занимается опенсорсом, всегда будут сознавать, что они «второй сорт». Плюс такая ситуация порождает массу лицензионной бумажной волокиты, чтобы избранные всегда сохраняли свои особые права. Таким образом, в проекте возникает серьезная пробуксовка.
С другой стороны, я видел много лицензированных опенсорсных проектов от BSD (или MIT, или т.п.), которые просто фрагментируются, как только становятся достаточно крупными и приобретают коммерческую важность, а компании, причастные к таким проектам, неизбежно решают запатентовать принадлежащие им фрагменты.
Итак, я считаю, что GPLv2 дает практически идеальный баланс «все работают, и правила для всех одинаковы», но при этом все равно требует от людей отдачи сообществу (»долг платежом красен»). Причем, каждый знает, что все остальные люди, вовлеченные в проект, подчиняются одним и тем же правилам, поэтому весь процесс очень равноправный и честный.
Разумеется, обратный эффект заключается в том, что и вы получаете что-то от проекта, в который вложили силы. Разумеется, можно попытаться «запрыгнуть на хвост» проекту и оставаться обычным пользователем, почему нет. Но, избрав такой путь, вы нисколько не будете контролировать проект. Это также может быть вполне нормально, если вам нужна всего лишь непритязательная операционная система, а Linux уже делает все, что вам надо. Но, если у вас есть особые требования, то единственный реальный способ влиять на проект – это участвовать в нем.
При таком подходе все честны. Включая меня. Каждый может сделать форк проекта и пойти своим путем, сказать: «пока, Линус, у меня есть своя версия Linux, и ее поддержку я беру на себя». Я «особенный» только потому что и только до тех пор, пока люди доверяют мне за хорошо сделанную работу. Именно так и должно быть.
То, что «каждый может поддерживать собственную версию» вызывало у некоторых беспокойство по поводу версии GPLv2, но я вижу в этом достоинство, а не недостаток этой лицензии. Несколько парадоксально, но я считаю, что именно это и уберегло Linux от фрагментации: ведь каждый может сделать собственный форк проекта, и это нормально. На самом деле, именно в этом заключается один из ключевых принципов, на основе которых спроектирован «Git» – каждый клон репозитория — это самостоятельный маленький форк, и люди (а также компании) ответвляют собственные версии, именно так и совершается весь процесс разработки.
Итак, форки – не проблема, если потом при слиянии вы добавите в основную ветку только то, что получилось хорошо. Именно здесь вступает в дело GPLv2. Право сделать форк и развивать собственный проект очень важное, но в равной степени важна и другая сторона медали – право впоследствии снова объединиться, если форк показал себя успешным.
Другая проблема в том, что вам по-настоящему нужны только инструменты для поддержания интересующего вас потока задач, но при этом вам также нужен подходящий менталитет для поддержки этого проекта. Серьезным препятствием для возвращения форков в общий проект являются не только вопросы лицензирования, но и «дурная кровь». Если форк создается из чувства глубокого противоречия родительской ветке, то объединить две ветки обратно может быть очень сложно, причем, дело не в лицензировании и не в технических причинах, а в том, что форк был столь несочетаем с исходной версией. Опять же, думаю, что в Linux такого удалось в основном избежать, поскольку мы всегда относились к созданию форков как к делу совершенно естественному. Поэтому естественно воспринимается и обратное слияние, если какая-то работа успешно прошла проверку практикой.
Итак, отвечая на вопрос, я немного ушел в сторону, но считаю, что это важное отступление. Я решительно не жалею о том, какую лицензию выбрал, поскольку действительно считаю, что в GPLv2 заключается огромная часть успешности Linux.
На самом деле, деньги – не столь серьезный мотиватор. Они не сплачивают людей. Думаю, что, если работаешь над общим проектом и чувствуешь, что реально можешь быть полноправным партнером в рамках этого проекта, то именно это и мотивирует людей.
Дж.А.: В наши дни, если кто-то выпускает исходный код по лицензии GPLv2, то делает это в основном ради работы с Linux. Как вы нашли лицензию, и сколько времени и сил у вас ушло на изучение других существующих лицензий?
ЛТ: В те времена в сообществе еще бушевали серьезные флеймы по поводу BSD и GPL (думаю, отчасти они разжигались из-за того, что у rms настоящий талант бесить людей), так что я встречал разные дискуссии на тему лицензирования только в разных новостных группах usenet, которые я читал (такие источники, как comp.arch, comp.os.minix и т.д.).
Но двумя основными поводами были, пожалуй, банальный gcc – который очень и очень поспособствовал тому, чтобы Linux набрал ход, поскольку мне был абсолютно необходим компилятор для C — и Ларс Виржениус (»Ласу»), другой шведскоязычный студент с факультета компьютерных наук, с которым мы учились в университете на одном курсе (шведскоязычное меньшинство в Финляндии очень невелико).
Ласу гораздо активнее участвовал в дискуссиях по лицензированию и т.п., чем я.
Для меня выбор GPLv2 не был огромной дипломатической проблемой, а был обусловлен в основном тем фактом, что моя изначальная лицензия была столь импровизированной, и ее требовалось обновить, а еще я чувствовал себя в долгу перед gcc, и GPLv2 соответствовала моим ожиданиям «исходники нужно отдавать».
Итак, вместо того, чтобы сделать другую лицензию (или просто отредактировать оригинальную, убрав формулировку «запрещаются денежные операции» — такой вариант тоже рассматривался), я хотел выбрать такую, которая была бы уже известна людям, и я хотел привлечь к ее разработке юристов.
Дж. А.: Каков ваш обычный день? Сколько времени вы тратите на написание кода, по сравнению с ревью кода и чтением/написанием электронной почты? Как вы находите баланс между личной жизнью и разработкой ядра Linux?
ЛТ: Сейчас я пишу очень мало кода, долго не писал. А когда я все-таки пишу код, чаще всего я оказываюсь в ситуации, когда разворачивается дискуссия о какой-либо конкретной проблеме, я вношу изменения и отсылаю их в виде патча, в основном в качестве пояснения предложенного решения.
Иными словами, основной объем кода, который я пишу, скорее сводится к «посмотри, а мы это делаем вот так« и в данном случае патч — очень конкретный пример. Легко увязнуть в какой-нибудь теоретической высокоуровневой дискуссии о том, как решить какую-нибудь задачу, и, на мой взгляд, что наилучший способ описать решение — просто привести фрагмент кода, может быть, не весь код – и максимально выпятить его именно таким образом.
Вот почему вся моя реальная работа сводится к чтению и написанию электронной почты. Это в основном коммуникация, а не написание кода. На самом деле, я считаю именно такую коммуникацию с журналистами и техническими блогерами, т.д., самой настоящей частью моего рабочего дня. Возможно, приоритет у этой работы ниже, чем у технических дискуссий как таковых, но я трачу немало времени и на решение таких вопросов.
Да, я уделяю время и ревью кода, но, честно говоря, к тому времени, как я получаю пул-реквест, код, вызвавший вопросы, уже успевает просмотреть множество других людей. Поэтому, хотя я и просматриваю патчи, больше внимания я уделяю объяснениям и истории патча, как он пришел ко мне. Причем, с людьми, с которыми мы работаем достаточно давно, я обхожусь даже без этого: все они занимаются поддержкой тех подсистем, за которые отвечают, и микроменеджмент по контролю их работы – не мое дело.
Итак, весьма часто моя работа заключается в том, чтобы «просто присутствовать», играть роль концентратора, того человека, который управляет релизами и следит за соблюдением правил. Иными словами, моя работа в большей степени связана с процессом поддержки, а не с низкоуровневым кодом.
Дж.А.: Какова ваша рабочая обстановка? Например, комфортнее ли вам работать в затемненной комнате, где ничего не отвлекает, либо в комнате с видовым окном? Вы склонны работать в тишине или под музыку? Какое аппаратное обеспечение вы обычно используете? Выполняете ревью кода в vi, в окне терминала или в навороченной IDE? И есть ли такой дистрибутив Linux, который вы предпочитаете для данной работы?
ЛТ: не могу сказать, что у меня в комнате «темно», но я действительно прикрываю шторами окно у рабочего места, поскольку яркий солнечный свет мне не нравится (правда, в этот сезон в Орегоне его и так не слишком много;). Так что никаких панорам, только (заваленный) стол с двумя 4k мониторами и мощным ПК под столом. И еще пара ноутбуков под рукой, для тестирования и на случай, если какая-то работа прилетит мне в дороге.
И я хочу работать в тишине. Возненавидел щелканье механических винчестеров, к счастью, они давно отправлены в утиль, поскольку я давно переключился на работу исключительно с SSD, вот уже более десяти лет как. Шумные процессорные вентиляторы для меня также неприемлемы.
Вся работа делается в традиционном терминале, хотя, я и не пользуюсь ‘vi’. Я работаю с этим убогим «micro-emacs», который не имеет ничего общего с emacs от GNU, с той оговоркой, что некоторые привязки клавиш у них похожи. Я привык работать с этим редактором еще в Хельсинском университете, будучи юнцом, и так и не смог от него отучиться, хотя, подозреваю, вскоре мне придется это сделать. Несколько лет назад я сварганил для него (очень ограниченную) поддержку utf-8, но редактор уже старый, и во всех его аспектах сквозит, что написан он был в 1980-е, а та версия, которой пользуюсь я – это форк, не поддерживаемый с середины 90-х.
В Хельсинском университете этот редактор использовался, поскольку он работал под DOS, VAX/VMS и Unix, почему и мне довелось с ним познакомиться. А теперь он просто вшит мне в пальцы. На самом деле, давно пора переключиться на какую-то альтернативу, которая исправно поддерживается и как следует воспринимает utf-8. Пожалуй, попробую ‘nano’. Мой же наспех слепленный антикварный мусор работает на том уровне «вполне приемлемо», что у меня не возникало острой нужды переучивать мои старые пальцы на новые фокусы.
Итак, моя настольная рабочая среда весьма безыскусна: открыто несколько текстовых терминалов, еще браузер с почтой (плюс еще несколько вкладок, в основном с техническими и новостными сайтами). Я хочу, чтобы значительная часть рабочего стола была свободна, поскольку привык работать с достаточно большими окнами терминалов (100×40 – можно сказать, таков у меня исходный размер окна по умолчанию), и у меня бок о бок открыто несколько окон терминала. Поэтому работаю с двумя мониторами по 4k.
На всех моих машинах я использую Fedora, не потому, что этот дистрибутив для меня однозначно «предпочтителен», а потому, что я к нему привык. Меня не особо волнует выбор дистрибутива, я расцениваю дистрибутив в основном как вариант установки Linux на машине, как среду, в которой настроены все мои инструменты, так, чтобы я мог просто заменить ядро и сосредоточиться на работе с ним.
Дж. А.: Публичное обсуждение разработки ядра происходит в почтовой рассылке по ядру Linux, и трафик там запредельный. Как вы успеваете разгребать столько почты? Вы исследовали другие решения для совместной работы и коммуникации вне почтовой рассылки, либо простая почтовая рассылка чем-то идеально подходит для той работы, которую вы делаете?
ЛТ: О, я не читаю саму рассылку, посвященную разработке ядра, годами не читал. Там слишком много всего.
Таким образом, я привык, что подписан на эту рассылку, но вся почта из lkml, где я не указан в копии, у меня автоматически попадает в авто-архивацию, так что по умолчанию я ее не вижу. Но, когда какую-то проблему доводят до меня, я могу развернуть всю дискуссию по ней, поскольку она лежала у меня в электронной почте, а не просто во «входящих», и ждала своего часа.
В настоящее время я предпочитаю использовать функционал lore.kernel.org, так как работает он очень хорошо, и вокруг него уже выстроены некоторые другие инструменты. Поэтому дискуссии можно не автоматически упаковывать в мои собственные почтовые архивы, а сохранять вот таким образом – тогда они видны. Но общий поток задач концептуально остается прежним.
Действительно, я до сих пор получаю изрядное количество электронной почты, это очевидно, но за долгие годы ситуация во многих отношениях изменилась скорее к лучшему, чем к худшему. Во многом это благодаря Git и тому, как хорошо налажен процесс релизов ядра: раньше у нас было гораздо больше проблем с потоком кода и инструментальным оснащением. Ситуация с электронной почтой на рубеже веков у нас была гораздо, гораздо хуже, когда еще приходилось иметь дело с гигантскими связками патчей, и у нас были серьезные проблемы с масштабируемостью потока разработки.
Причем, модель с почтовой рассылкой (и сопровождающими ее инструментами) в самом деле работает очень хорошо. Я не о том, что люди не пользуются иными средствами коммуникации кроме электронной почты (имею в виду и личные переговоры, и участие в почтовых рассылках): многим очень нравятся различные чаты в режиме реального времени (традиционный вариант — IRC). Причем, хотя это и никогда не было моим коньком, очевидно, что многим нравится метод мозгового штурма. Но модель с «списком рассылки, используемым в качестве архива» работает очень хорошо, и бесшовно сшивается как с «рассылкой патчей от разработчика к разработчику в электронных сообщениях», так и с «отправкой отчетов по проблемам в виде электронной почты».
Итак, электронная почта остается основным каналом связи, по ней удобно обсуждать технические проблемы, поскольку патчи встраиваются в ту же среду, что и письма. Причем, почта работает сразу во всех часовых поясах, а это очень важно, когда сообщество так сильно рассредоточено географически.
Дж.А.: Я пристально следил за разработкой ядра на протяжении примерно десяти лет, вел на эту тему блог в KernelTrap и писал о новых возможностях по мере их развития. Бросил заниматься этим примерно к моменту выхода версии ядра 3.0, выпущенной спустя 8 лет, когда выходили версии с номерами 2.6.x. Можете ли резюмировать, какие наиболее интересные события произошли с ядром после релиза версии 3.0?
ЛТ: Эх. Это было так давно, что я даже не знаю, с чего начать резюмировать. Прошло уже десять лет с момента выхода версии 3.0, и за это десятилетие мы успели внести много технических изменений. Архитектура ARM выросла, и ARM64 стала одной из наших основных архитектур. Много-много новых драйверов и новая базовая функциональность.
В любом случае, что самое интересное за последнее десятилетие – как нам удалось удержать действующую модель разработки по-настоящему ровной, и что в ней не изменилось.
За десятилетия мы попробовали много разных схем версионирования, у нас были разные модели разработки, но релиз 3.0 фактически оказался именно тем, в котором окончательно оформилась модель, используемая нами с тех пор по сей день. В этой версии мы, так сказать, официально заявили, что «релизы выпускаются по времени, номера версий – это просто номера, и в них нет никаких зависимостей компонентов».
Мы затеяли всю историю с привязкой релизов ко времени и с окном по сведению патчей (merge window) во времена 2.6.x, поэтому сама эта инициатива не нова. Но именно в 3.0 последние реликты «у номера есть значение» были выброшены на свалку.
У нас была и случайная схема нумерации (в основном до версии 1.0), у нас была целая модель «нечетные минорные номера соответствует версии ядра, которая находится в разработке, четные означают стабильное ядро, готовое к продакшену», после чего в версиях 2.6.x мы перешли к модели с привязкой релизов по времени. Но у людей по-прежнему оставался вопрос «Что должно произойти, чтобы увеличился мажорный номер». И в версии 3.0 было официально объявлено, что четный мажорный номер версии не несет никакой семантики, и что мы всего лишь стараемся придерживаться простой нумерации, с которой было бы удобно обращаться, и которая бы чрезмерно не разрасталась.
Итак, за последние десятилетия мы внесли совершенно колоссальные изменения (в Git легко посмотреть некоторую статистику в числовом выражении: примерно три четверти миллиона коммитов, сделанных 17 тысячами участников). Но сама модель разработки остается весьма ровной и стабильной.
Так, конечно, было не всегда. Первые двадцать лет в истории разработки ядра были полны поистине болезненных перемен в модели разработки. Последнее десятилетие получилось гораздо более предсказуемым в плане выхода релизов.
ЛТ: Выше я на это уже указывал: сам процесс в самом деле хорошо стандартизирован, и остается таким на протяжении последнего десятилетия. Перед этим произошло несколько серьезных потрясений, но с 3.0 он работает практически как часы (на самом деле, это началось еще на несколько лет ранее – во многих отношениях переход на Git положил начало современным процессам, и потребовалось время, прежде, чем все к этому привыкли).
Поэтому у нас была такая каденция с «двухнедельным окном по сведению патчей», за которым следует примерно 6-8 недель, затрачиваемых на изучение кандидатов для релиза; думаю, такие циклы поддерживаются уже на протяжении примерно 15 лет.
Правила тоже всегда были одни и те же, хотя, их не всегда требовалось соблюдать со всей строгостью: окно по сведению патчей предназначено для нового кода, который предположительно «протестирован и готов», а затем в течение примерно двух последующих месяцев вносятся правки, и мы убеждаемся, что все проблемы действительно утрясены. Да, это происходит не всегда, и бывает, что предположительно «готовый» код приходится отключать или вообще выбрасывать прямо перед релизом.
Затем цикл повторяется – поэтому релизы у нас происходят примерно с десятинедельным интервалом.
А критерии для релиза для меня заключаются в ощущении достаточной уверенности, которая, очевидно, в свою очередь основана на том, какие сообщения о проблемах по-прежнему продолжают приходить. Если в какой-нибудь области проблемы продолжают сохраняться на поздних этапах релизного цикла, то я весьма настойчиво требую все откатить и говорю «займемся этим в одном из следующих релизов, когда как следует разберемся, что к чему», но в целом прибегать к таким мерам требуется достаточно редко.
Всегда ли такой процесс дает нужный результат? Нет. Как только релиз ядра состоялся, и особенно, когда релиз подхвачен ядром – у вас появляются новые пользователи, люди, не тестировавшие релиз на этапе разработки, и они находят какие-то вещи, которые не работают, или которые мы не отловили в ходе подготовки релиза. Это во многом неизбежно. Отчасти именно поэтому мы держим целые деревья «стабильных ядер», в которые после релиза продолжаем вносить правки. Причем, срок поддержки у одних стабильных ядер дольше, чем у других, такие долгоживущие ядра обозначаются аббревиатурой LTS (»долгосрочная поддержка»).
Все эти аспекты на протяжении последних десяти лет практически не менялись, хотя, мы действительно значительно шире стали применять автоматизацию. Автоматизация тестирования ядра – дело вообще сложное, отчасти потому, что значительная часть ядра приходится на драйверы, которые, очевидно, зависят от доступности аппаратного обеспечения. Но у нас есть несколько «ферм», тестирующих как загрузку, так и производительность, а еще мы выполняем различные варианты рандомизированного нагрузочного тестирования. Все это за годы работы улучшилось.
Дж.А.: В прошлом ноябре, по вашим словам, вас впечатлили новые чипсеты ARM64 от Apple, поставленные в некоторых из их новых компьютеров. Вы следите за этими разработками, чтобы поддерживать их под Linux? Вижу, work была добавлена в for-next. Вероятно ли, что Linux будет грузиться на оборудовании Apple MacBook уже с появлением готовящегося ядра 5.13? Станете ли вы одним из ранних пользователей? Насколько велика для вас важность ARM64?
ЛТ: я очень эпизодически проверяю, как с этим дела, но пока там все на очень раннем этапе. Как вы правильно отметили, самый ранний вариант поддержки, вероятно, будет добавлен в ядро 5.13, но учитывайте пожалуйста, что мы в самом начале пути, и аппаратное обеспечение Apple пока еще не годится для полезной работы под Linux.
Основную проблему представляет не сама arm64, а драйверы для аппаратного обеспечения, сопутствующего этой архитектуре (в особенности это касается SSD и GPU). На данном раннем этапе работы мы успели привести в работоспособный вид некоторые весьма низкоуровневые штуки, которые пока не приносят никакой реальной пользы кроме первичного запуска оборудования. Пройдет еще какое-то время, прежде, чем эти разработки станут реальным вариантом, который можно попробовать.
Но улучшилось не только аппаратное обеспечение Apple – сама инфраструктура для arm64 значительно выросла, и ядра процессора изменились от «ни о чем» до вполне конкурентоспособной альтернативы для серверного пространства. Еще не так давно серверное пространство arm64 представляло собой весьма унылое зрелище, но процессоры Graviton2 от Amazon и Altra от Ampere – оба основаны на значительно улучшенной версии ARM Neoverse IP – гораздо лучше альтернатив, имевшихся на рынке несколько лет назад.
Я уже более десяти лет дожидался, пока появится удобная машина с ARM, и ее до сих пор нет, но сейчас до нее гораздо ближе, чем было когда-то.
На самом деле могу сказать, что хотел машину с ARM гораздо дольше, еще в подростковые годы, причем, по-настоящему желанна была Acorn Archimedes, но из соображений цены и доступности пришлось удовлетвориться Sinclair QL (процессор M68008), а затем, конечно же, через несколько лет я сменил ее на i386 PC.
Несколько десятилетий казалось, что такая машина уже не за горами, но в широкой доступности ее по-прежнему не было, а также я не мог предпочесть ее другим компьютерам по соображениям производительности/цены. Когда-нибудь она появится. Надеюсь, не в столь отдаленном будущем.
Дж.А.: есть ли в ядре какие-то аспекты, которые сделаны не лучшим образом, но, чтобы поправить их как следует, пришлось бы полностью переписывать код? Иными словами, ядру 30 лет, и за эти 30 лет значительно изменились наши знания, языки программирования аппаратное обеспечение. Если бы сейчас вы переписывали ядро с нуля, то что бы вы в нем изменили?
ЛТ: на самом деле, нам весьма хорошо удавалось даже целиком переписывать некоторые вещи, если была такая необходимость, поэтому все детали, которые казались необезвреженными бомбами, давным-давно переписаны.
Естественно, у нас есть изрядное количество слоев, которые оставлены для обеспечения «совместимости», но обычно там не «ужас-ужас». Причем, неясно, а исчезнут ли эти слои для совместимости, если переписать все с нуля – ведь они нужны для обратной совместимости со старыми бинарными файлами (а зачастую и для обратной совместимости со старыми архитектурами, например, для запуска 32-битных приложений для x86 на x86-64). Поскольку я считаю обратную совместимость очень важной, я хотел бы сохранить их даже в переписанной версии.
Итак, очевидно, что у нас много вещей, которые реализованы «не оптимально», в том смысле, что улучшить можно что угодно, но, учитывая, как вы сформулировали вопрос, я отвечу на него отрицательно – в ядре нет ничего, чем я бы гнушался. Есть унаследованные драйверы, которыми никогда никто не озаботится хотя бы настолько, чтобы их подчистить, есть и другие уродливые вещи, но ключевой момент в том, что они «никого особо не волнуют». Это все не проблемы, а если они превратятся в проблемы, то мы активно избавляемся от поддержки по-настоящему старого унаследованного кода, до тех пор, пока ситуация вновь не начинает всех устраивать. Так, с годами мы избавились от множества драйверов, и мы откажемся от поддержки целой архитектуры, если ее поддержка утратит какой-либо смысл.
Нет, единственная серьезная причина для «переписывания» могла бы возникнуть лишь в случае, если бы обнаружился некоторый практический кейс, в котором вся структура действительно не имеет смысла. Наиболее вероятным примером такого рода в реальности могла бы оказаться какая-нибудь маленькая встраиваемая система, которой не нужно ничего, что сегодня может предложить Linux, а на уровне аппаратного обеспечения ее отпечаток столь мал, что этой системе попросту нужно нечто помельче и попроще, чем операционная система, какой за годы развития стал Linux.
Ведь Linux значительно вырос. Даже на небольших устройствах (вспомним мобильные телефоны, например) он сегодня гораздо мощнее, чем исходный Linux, который разрабатывался для машин своего времени.
Дж.А.: Как насчет хотя бы частично переписать ядро на Rust, языке, который разрабатывался именно с прицелом на производительность и безопасность? Есть ли пространство для улучшения в таком ключе? Как вы считаете, возможно ли, чтобы другой язык, например, Rust, заменил C в ядре?
ЛТ: Увидим. Не думаю, что Rust закрепится в самой основе ядра, но писать на нем отдельные драйверы (или, может быть, целые подсистемы драйверов) – не скажу, что это совершенно невероятно. Может быть, он и для файловых систем подойдет. Поэтому, скорее не «заменить C», а «дополнить наш код на C там, где это целесообразно «.
Разумеется, на драйверы как таковые приходится примерно половина кода ядра, поэтому места для таких разработок много, но я не думаю, что кто-то в самом деле рассчитывает, что уже существующие драйверы будут переписаны на Rust целиком. Может быть, «есть люди, желающие писать новые драйверы на Rust, а некоторые драйверы мы на нем действительно можем переписать, если это будет целесообразно».
Но прямо сейчас ситуация дошла только до «люди пробуют его, играют с ним», не более. Легко подчеркивать преимущества, но здесь определенно есть и сложности. Поэтому я очень склонен подождать и понаблюдать, действительно ли обещанные сильные стороны Rust себя оправдают.
Дж.А.: Есть ли в ядре какие-либо конкретные элементы, которыми вы лично особенно гордитесь?
ЛТ: выдающиеся части, которые мне хочется лишний раз подчеркнуть – это уровень VFS (»виртуальная файловая система») (и поиск имени пути в частности) и наш код виртуальной машины. Первое – просто потому, что в Linux некоторые из этих фундаментальных вещей (поиск имени файла – по-настоящему базовая функциональность в операционной системе) выполнимы намного лучше, чем во многих других ОС. А второе – в основном потому, что мы поддерживаем более 20 архитектур, и по-прежнему делаем это при помощи в основном унифицированного уровня виртуальной машины, что, на мой взгляд, весьма впечатляет.
Но, в то же время, все это во многом проистекает из «какая из частей ядра вам наиболее интересна». Ядро достаточно велико, чтобы разные разработчики (и разные пользователи) просто придерживались разных мнений по поводу того, что в нем наиболее важно. Некоторым кажется, что планирование задач – наиболее захватывающая функция ядра. Другим нравится вникать в тонкости драйверов устройств (а у нас таких много). Лично я сильнее вовлечен в работу над VM и VFS, поэтому, естественно, указываю на них.
Дж.А.: Я нашел вот такое описание поиска имени пути, и он сложнее, чем я ожидал. Почему реализация этой функции в Linux настолько лучше, чем в любых других операционных системах? И что для вас означает «лучше»?
ЛТ: Поиск имени пути – это поистине настолько обычная и фундаментальная вещь, что почти никто вне круга разработчиков ядра не считает, что это проблема. Они просто открывают файлы и принимают это как должное.
Но на самом деле очень сложно добиться, чтобы это работало как следует. Именно потому, что поиск имени пути все время происходит буквально везде, и поэтому данная задача критически сказывается на производительности; кроме того, это именно та область, в которой требуется хорошо масштабироваться при работе в средах SMP, блокировки при выполнении таких задач сопряжены с немалой сложностью. А вы хотите свести к минимуму какие-либо операции ввода/вывода, поэтому кэширование – это очень важно. На самом деле, поиск имени пути настолько важен, что его нельзя выполнять на низком уровне файловой системы, ведь у нас более 20 различных файловых систем, и реализация в каждой из них собственных механизмов кэширования и блокировок стала бы подлинной катастрофой.
Итак, одна из основных задач, решаемых на уровне VFS – это обработка всего кэширования и всех блокировок, связанных с компонентами имени пути, а также с обработкой всех операций, касающихся сериализации и обхода точек монтирования, причем, все это делается в основном при помощи неблокирующих алгоритмов (RCU), а также с применением весьма умных сущностей, напоминающих блокировки (блокировка «lockref», предусмотренная в Linux – это очень особенная «спин-блокировка с подсчетом ссылок», буквально предназначенная для кэширования dcache, и, в принципе, это специализированный механизм подсчета ссылок, учитывающий блокировки, который в определенных типичных ситуациях может выполнять исключение блокировок).
В итоге: низкоуровневые файловые системы все равно должны искать вещи, которые не кэшированы, но на их уровне не приходится беспокоиться о кэшировании и соблюдении правил согласованности и атомарности, которые должны соблюдаться при поиске имени пути. Уровень VFS все это обрабатывает за них.
Причем, в этом Linux успешнее, чем какая-либо другая операционная система, и это не мешает ему хорошо масштабироваться даже на машинах с тысячами CPU. Даже когда этим машинам приходится обращаться к одним и тем же каталогам (скажем, к корневому каталогу или домашнему каталогу проекта приходится одновременно обращаться даже в приложениях с сильно развитой многопоточностью, а такое по-поточное поведение не поддается какому-либо распределению).
Поэтому, здесь в Linux все не просто «лучше», но даже «Лучше» с большой буквы «Л». Ни одна другая система в этом и близко не сравнится с Linux. Механизм dcache просто единственный в своем роде.
Дж.А.: Прошлый год тяжело дался всему миру. Как пандемия COVID-19 повлияла на процесс разработки ядра Linux?
ЛТ: на самом деле, минимально, поскольку мы привыкли к такому режиму работы. Все-таки, электронная почта – чудесный инструмент, позволяющий обходиться без оффлайновых совещаний.
Да, в начале года ситуация повлияла на саммит по разработке ядра (и в этом году он пока также остается в подвешенном состоянии), а большинство конференций было отменено или переведено в виртуальный режим. Люди, работавшие в офисе, в основном стали работать из дома (но многие из тех, кто занимается поддержкой ядра, и раньше работали в таком режиме). Поэтому многие вещи изменились, но в основе своей процесс разработки ядра остался таким как прежде.
Причем, все это очевидно повлияло на нашу жизнь в другой плоскости, в том, что касается социальных связей. Но вообще, будучи разработчиками ядра, которые общаются с коллегами почти исключительно по электронной почте, мы, вероятно, оказались наименее затронуты пандемией.
Облачные серверы от Маклауд быстрые и безопасные.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!