Вся история 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). Этот шаг стал началом активного движения за открытое ПО.
Несколько лет спустя профессор Амстердамского свободного университета Эндрю Таненбаум (Andrew S. Tanenbaum) в качестве учебного пособия разработал Unix-подобную систему Minix. Он хотел сделать ее максимально доступной для студентов. Издатель его книги, к которой прилагалась ОС, настаивал хотя бы на номинальной плате за работу с системой. Эндрю и издатель пришли к компромиссу по цене лицензии в $69. В начале 90-х Minix завоевала популярность среди разработчиков. И ей было суждено стать основой для разработки Linux.
/ Flickr / Christopher Michel / CC BY
Рождение Linux и первых дистрибутивов
В 1991 году молодой программист из Хельсинкского университета Линус Торвальдс осваивал Minix. Его эксперименты с ОС переросли в работу над совершенно новым ядром. 25 августа Линус устроил открытый опрос группы пользователей Minix о том, что их не устраивает в этой ОС, и анонсировал разработку новой операционной системы. В августовском письме есть несколько важных тезисов о будущей ОС:
- система будет бесплатной;
- система будет похожа на Minix, но исходный код будет абсолютно другим;
- система не будет «большой и профессиональной, как GNU».
25 августа принято считать днем рождения Linux. Сам Линус ведет отсчет от другой даты — 17 сентября. Именно в этот день он загрузил первый релиз Linux (0.01) на FTP-сервер и отправил электронное письмо людям, проявившим интерес к его анонсу и опросу. В исходном коде первого релиза сохранилось слово «Freaks». Так Торвальдс планировал назвать свое ядро (комбинация слов «free», «freak» и Unix). Администратору FTP-сервера не понравилось название, и он переименовал проект в Linux.
Далее последовала череда обновлений. В октябре того же года была выпущена версия ядра 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, о которой мы поговорим в следующей статье.
Источник
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 используется в качестве резервного варианта, если для заданного вопроса не находится более узконаправленная рассылка). Таким образом, когда к дискуссии подключается новичок, он может посмотреть историю и контекст проблемы, просто изучив рассылку, посвященную разработке ядра.
Таким образом, я привык, что подписан на эту рассылку, но вся почта из 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 тысячами участников). Но сама модель разработки остается весьма ровной и стабильной.
Так, конечно, было не всегда. Первые двадцать лет в истории разработки ядра были полны поистине болезненных перемен в модели разработки. Последнее десятилетие получилось гораздо более предсказуемым в плане выхода релизов.
Дж.А.: На настоящий момент последний релиз — 5.12-rc5. Как стандартизирован процесс релизов? Например, изменения какого рода попадают в -rc1, по сравнению с -rc2 и так далее? И в какой момент вы решаете, что очередной релиз готов к официальному выходу? Что происходит, если вы ошиблись, и после финального релиза приходится серьезно отойти назад, и как часто это случается? Как этот процесс развивался с годами?
ЛТ: Выше я на это уже указывал: сам процесс в самом деле хорошо стандартизирован, и остается таким на протяжении последнего десятилетия. Перед этим произошло несколько серьезных потрясений, но с 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% скидку на первый месяц аренды сервера любой конфигурации!
Источник
