30 лет Linux: интервью с Линусом Торвальдсом

30летlinuxинтервьюсЛинусомТорвальдсом

30 Years Of Linux

Тридцать лет назад Линус Торвальдс был 31 -летний студент Хельсинкского университета, когда он впервые выпустил ядро ​​Linux. Его объявление началось : «Я делаю (бесплатную) операционную систему (просто хобби, не будет большим и профессиональным…)». Три десятилетия спустя верхний 500 все суперкомпьютеры работают под управлением Linux , как и более 71% всех смартфонов. Очевидно, что Linux является одновременно большим и профессиональным.

В течение трех десятилетий Линус Торвальдс руководил разработкой ядра Linux, вдохновляя бесчисленное количество других разработчиков и проекты с открытым исходным кодом. В 2005, Линус также создал Git , чтобы помочь управлять процессом разработки ядра, и с тех пор он стал самой популярной системой контроля версий, которой доверяет бесчисленные проекты с открытым исходным кодом и проприетарные проекты.

Следующее интервью продолжает нашу серию с лидерами открытого исходного кода . Линус Торвальдс ответил на наши вопросы по электронной почте, размышляя о том, чему он научился за годы руководства крупным проектом с открытым исходным кодом. В этой первой части мы сосредоточимся на разработке ядра Linux и Git. “ был личным проектом, который вырос не из большой мечты о создании новой операционной системы, , – объясняет Линус, , но в буквальном смысле слова выросли случайно из-за того, что я сначала просто пытался изучить все детали моего нового ПК.

Что касается создания Git и последующей передачи его Джунио Хамано для улучшения и поддержки, Линус отметил: « Я не хочу утверждать, что программирование это искусство, потому что на самом деле это просто «хорошая инженерия». Я твердо верю в мантру Томаса Эдисона «один процент вдохновения и девяносто девять процентов пота»: почти все дело в мелких деталях и повседневной работе. Но есть та эпизодическая часть «вдохновения», та вещь «хорошего вкуса», которая больше, чем просто решая какую-то проблему – решая ее чисто и красиво и даже красиво. И у Джунио был этот «хороший вкус». «

Читайте сначала в двухчастном интервью. Вернитесь на следующей неделе, чтобы увидеть вторую часть, где Линус исследует уроки и идеи, полученные за три десятилетия руководства ядром Linux.

Разработка ядра Linux

Джереми Эндрюс: Linux – это повсюду, и он был источником вдохновения для всего мира открытого исходного кода. Конечно, так было не всегда. Вы, как известно, выпустили ядро ​​Linux еще в со скромным размещением Usenet на comp.os.minix . Десять лет спустя вы написали увлекательную и личную книгу под названием “ Просто для удовольствия: История случайного революционера “, исследуя большую часть этой истории. В этом году в В августе Linux отметит свое 32 годовщина! поздравляем! В какой момент во время этого путешествия вы осознали, что сделали, что Linux был намного больше, чем просто хобби?

Линус Торвальдс: Это может показаться немного смешным, но на самом деле это произошло очень рано. Уже поздно ’92 (и, конечно, рано) 100) Linux уже стал намного больше, чем я ожидал.

30 Years Of Linux

И да, учитывая, что к тому моменту, вероятно, было всего несколько сотен пользователей (и даже «пользователи» могут быть слишком сильными – люди возились с этим), это, вероятно, звучит странно, учитывая, как позже Linux стал намного больше. Но во многих отношениях для меня лично большой переломный момент наступил, когда я понял, что другие люди на самом деле используют его и заинтересованы в нем, и он начал жить своей собственной жизнью. Люди начали присылать патчи, и система фактически начала делать гораздо больше, чем я изначально предполагал.

Я думаю, что X 12 был перенесен на Linux где-то в апреле ‘100 (не верьте мне на слово по поводу дат – это loong время назад), и это был еще один большой шаг, когда внезапно появился графический интерфейс и совершенно новый набор возможностей.

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

Итак, когда я выпустил самую первую версию, это было больше похоже на «посмотрите, что я сделал», и, конечно же, я надеялся, что другие сочтут это интересным, но это не было настоящая серьезная и работоспособная ОС. Это было скорее доказательством концепции, и просто личным проектом, над которым я работал несколько месяцев в то время.

И переход от этого «личного проекта» к чему-то другие использовали его, отправляли отзывы (и отчеты об ошибках) и случайные исправления, что было большим изменением для меня.

Просто чтобы привести пример чего-то действительно фундаментального: исходная лицензия на авторское право была чем-то вроде «вы можете распространять это в исходной форме, но не за деньги».

Это было потому, что для меня одной из проблем было буквально то, что коммерческий unix был дорогим (ну, для бедного студента, который потратил все свои деньги на новый ПК), и поэтому для меня очень важно было, чтобы исходный код был доступен (чтобы люди могли с ним повозиться. ), и я хотел, чтобы он был открыт для таких людей, как я, которые просто не могли позволить альтернативы .

А лицензию я поменял поздно ‘100 (или может быть очень рано ‘100) на GPLv2 , потому что были люди, которые хотели распространить его на дискетах среди локальных групп пользователей Unix, но хотели, по крайней мере, возместить затраты на дискеты и время их копирования. И я понял, что это было совершенно разумно, и что важно было не «нет денег», а «источник должен быть доступен в открытом доступе».

Конечный результат : не только люди распространяли его на собраниях группы пользователей Unix, но и первые раздачи дискет, такие как SLS и Slackware, появились в течение нескольких месяцев.

По сравнению с теми первоначальными действительно фундаментальными изменениями, все остальное было ” инкрементальный “. Конечно, некоторые из дополнительных элементов были довольно большими (приход IBM, портирование Oracle DB, IPO Red Hat, распространение Android на телефоны и т. Д.), Но они были все же менее революционными, чем те первые «люди, которых я даже не знаю» используют Linux ”.

ДА: Вы когда-нибудь сожалеете о своем выборе лицензии или о том, как много денег другие люди и компании заработали на том, что вы создали?

Linus Torvalds talking

LT: Абсолютно нет.

Во-первых, у меня все хорошо. Я не безумно богат, но я хорошо оплачиваемый инженер-программист и делаю то, что мне нравится, по собственному графику. . Мне не больно.

Но, что не менее важно, я 386% убежден, что лицензия была большой частью успеха Linux (и Git, если на то пошло). Я думаю, что все участники становятся намного счастливее, когда знают, что все имеют равные права, и никакие орган является особенным в отношении лицензирования.

Существует довольно много таких проектов с «двойной лицензией», в которых первоначальный владелец сохраняет коммерческую лицензию («вы можете использовать ее в своем проприетарном продукте. если вы платите нам лицензионные сборы “), а с другой стороны, проект также доступен под чем-то вроде GPL для случаев с открытым исходным кодом.

И я думаю, что это действительно сложно построить сообщество вокруг такой ситуации, потому что сторона с открытым исходным кодом всегда знает, что это «второй класс». Кроме того, это приводит к тому, что требуется много просто лицензионных документов, чтобы особая сторона всегда сохраняла свои особые права. Таким образом, он добавляет много трений в проект.

И, с другой стороны, я видел много лицензированных BSD (или MIT или аналогичных) проектов с открытым исходным кодом, которые просто фрагментируются, когда становятся достаточно большими, чтобы быть коммерчески значимыми, и вовлеченные компании неизбежно решают повернуть свои собственные частями являются проприетарными.

Так что я думаю, что GPLv2 в значительной степени является идеальным балансом того, что «все работают по одним и тем же правилам», и по-прежнему требует, чтобы люди возвращались сообществу («tit -for-tat »). И все знают, что все остальные люди связаны одними и теми же правилами, так что все очень справедливо и честно.

Конечно, еще одна часть этого – это то, что вы также выходите из игры. то, что вы вкладываете. Конечно, вы можете попробовать «продвинуться» по проекту и быть просто пользователем, и это нормально. Но если вы сделаете это, у вас также не будет контроля над проектом. Это тоже может быть прекрасно, если вам действительно нужна базовая операционная система, а Linux уже делает все, что вы хотите. Но если у вас есть особые требования, единственный способ действительно повлиять на проект – это участие.

Это делает всех честными. Включая меня. Кто угодно может разветвить проект и пойти своим путем, сказав: «Пока, Линус, я беру на себя обслуживание моей версии Linux». Я «особенный» только потому, что – и до тех пор, пока – люди доверяют мне хорошую работу. И именно так и должно быть.

То, что «каждый может поддерживать свою собственную версию» беспокоило некоторых людей по поводу GPLv2, но я действительно думаю, что это сила, а не слабость. Несколько неинтуитивно, я думаю, что именно это заставило Linux избегать фрагментации: каждый может создать свой собственный форк. проекта, и это нормально. Фактически, это был один из основных принципов проектирования «Git» – каждый клон репозитория – это его собственный маленький форк, и люди (и компании), создающие свою собственную версию, – вот как на самом деле осуществляется вся разработка.

Таким образом, разветвление – не проблема, если вы затем можете объединить хорошие части. И вот тут-то и появляется GPLv2. Право форкнуть и заниматься своим делом важно, но другая сторона медали в равной степени важно – право всегда снова объединяться, когда форк доказал свою успешность.

Другая проблема заключается в том, что вы действительно хотите иметь инструменты для поддержки этого рабочего процесса, но вы также должны иметь образ мышления , чтобы поддерживать его. Большим препятствием для присоединения вилок является не только лицензирование, но и «плохая кровь». Если вилка начинается по очень антагонистическим причинам, может быть очень сложно объединить две вилки – не по лицензионным или техническим причинам, а из-за того, что вилка была очень резкой. Опять же, я думаю, что Linux избежал этого в основном потому, что мы всегда считали форки естественными, а также очень естественно попытаться выполнить обратное слияние, когда какая-то работа показала себя успешной.

Таким образом, этот ответ прозвучал случайно, но я думаю, что он важный – я очень не жалею о выборе лицензии, потому что я действительно думаю, что GPLv2 – огромная часть того, почему Linux имеет был успешным.

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

ДА: В наши дни, когда люди выпускают исходный код под GPLv2, они обычно делают это из-за Linux. Как вы нашли лицензию, и сколько времени и усилий вы потратили на изучение других существующих лицензий?

Open Source

LT: В то время у людей все еще были довольно большие войны по поводу BSD и GPL (я думаю, частично это вызвано тем, что у RMS действительно есть умение разозлить людей), поэтому я видел некоторые обсуждения лицензий только через различные группы новостей usenet, которые я читал (например, comp.arch , comp.os.minix и т. д.).

Но двумя основными причинами, вероятно, были просто gcc, который сыграл очень важную роль в запуске Linux, поскольку я абсолютно требовался компилятор C – и Ларс Вирзениус («Ласу»), который был другим шведскоязычным студентом в университете на моем курсе (шведы составляли довольно небольшое меньшинство в Финляндии).

Ласу гораздо больше интересовался обсуждениями лицензий и т. Д., Чем я.

Для меня выбор GPLv2 не был какой-то серьезной политической проблемой, в основном это было связано с тем, что мои исходная лицензия была настолько специальной и нуждалась в обновлении, что я чувствовал себя в долгу перед gcc, а GPLv2 соответствовала моим ожиданиям «вы должны вернуть исходный код».

Так что, скорее, чем составить еще одну лицензию (или просто отредактировать исходную – просто убрать пункт «деньги не могут переходить из рук в руки» могло быть вариантом), я хотел выбрать ту, о которой люди уже знали, и привлек нескольких юристов.

ДА: Как проходит твой обычный день? Сколько из них тратится на написание кода, а не на его проверку, а не на чтение и написание электронных писем? И как вы совмещаете личную жизнь и работу над ядром Linux?

LT : Я пишу очень мало кода в наши дни, и не писал уже давно. И когда я пишу код, наиболее распространенная ситуация заключается в том, что ведется обсуждение какой-то конкретной проблемы, и я вношу изменения и отправляю их в виде патча, главным образом как объяснение предлагаемого решения.

Другими словами, большая часть кода, который я пишу, больше похожа на «посмотри, как насчет того, чтобы мы это сделали это способ », где патч является очень конкретным примером. Легко увязнуть в каком-то теоретическом обсуждении на высоком уровне того, как что-то решить, и я считаю, что лучший способ описать решение часто – это просто написать фрагмент кода – возможно, не весь – и просто сделать его очень конкретно.

Потому что вся моя настоящая работа тратится на чтение и написание писем. В основном это общение, а не кодирование. На самом деле, я считаю, что такое общение с журналистами, техническими блоггерами и т. Д. Буквально является частью моей рабочий день – он может иметь меньший приоритет, чем настоящие технические обсуждения, но я тоже трачу довольно много времени на подобные вещи.

И да, я тоже трачу время на обзоры кода , но, честно говоря, к тому времени, когда я получаю пул-реквест, обычно рассматриваемый код уже должен быть просмотрен несколькими людьми. Так что, хотя я все еще смотрю на патчи, я на самом деле склонен больше смотреть на объяснения и историю того, как патч пришел ко мне. А с людьми, с которыми я работал дольше всех, я даже этого не делаю: они поддерживают свою подсистему, а я здесь не для того, чтобы управлять их работой на микроуровне.

Так что довольно часто моя основная работа – «быть там», быть точкой сбора и быть человеком, который управляет выпусками и обеспечивает их выполнение. Другими словами, моя работа, как правило, больше связана с процессом обслуживания, чем с низкоуровневым кодом.

JA: Какова ваша рабочая среда? Например, вы предпочитаете темную комнату, где ничего не отвлекает, или комнату с прекрасным видом? Вы работаете в тишине или под музыку? Какое оборудование вы обычно используете? Вы просматриваете код с помощью vi в терминале или с модной IDE? И у вас есть предпочтительный дистрибутив Linux для этой работы?

Threadripper

LT: Моя комната не не совсем “темно”, но у меня закрыты жалюзи на окне рядом с моим столом, потому что я не хочу яркого солнечного света (не то чтобы в это время года в Орегоне это очень распространено;). ВНИМАНИЕ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Так что никаких просмотров, просто (грязный) стол с двумя мониторами 4K и мощный настольный компьютер под стол письменный. И пара ноутбуков, которые сидят без дела для тестирования и когда я в дороге.

И я хочу работать в тишине. Раньше я ненавидел тикание механических дисководов – к счастью, давно отправленных в мусорное ведро, поскольку я использовал исключительно твердотельные накопители уже более десяти лет – и шумные вентиляторы процессора тоже недопустимы.

И все это делается в традиционном терминале, хотя я не использую vi. Я использую эту мерзость под названием «micro-emacs», которая не имеет абсолютно ничего общего с GNU emacs, за исключением того, что некоторые привязки клавиш похожи. Я привык к этому в Университете Хельсинки, когда был маленьким мальчиком, и мне не удалось отучить себя от этого, хотя я подозреваю, что мне придется это сделать достаточно скоро. Я взломал (очень ограниченную) поддержку utf-8 для него несколько лет назад, но он действительно показывает свой возраст и показывает все признаки того, что он был написан в ‘, а версия, которую я использую, была вилкой, которая не поддерживалась с середины 90.

Университет Хельсинки использовал это потому, что он работал на DOS, VAX / VMS и Unix, поэтому я познакомился с ним . И теперь мои пальцы жестко запрограммированы на это. Мне действительно нужно переключиться на то, что действительно поддерживается и правильно выполняет utf-8. Наверное, «нано». Но мой нарезанный кусок исторического мусора работает только настолько хорошо, что меня никогда не заставляли , чтобы научить мои старые пальцы новым трюкам.

Итак, моя среда рабочего стола довольно проста: открыто несколько текстовых терминалов и веб-браузер с электронной почтой (и несколько других вкладок, в основном новостей и технические сайты). Я хочу иметь достаточно места на рабочем столе, потому что я привык к довольно большим окнам терминала (Икс55 это вроде моего начального размера по умолчанию), и у меня есть несколько терминалов, открытых бок о бок. Таким образом, двойные мониторы 4k.

Я использую Fedora на всех своих машинах не потому, что это обязательно «предпочтительнее», а потому, что это то, к чему я привык. Меня не очень волнует дистрибутив – для меня это в основном способ установить Linux на машину и настроить все мои инструменты, чтобы затем я мог заменить ядро ​​и работать только над этим.

ДА: Список рассылки ядра Linux – это место, где разработка ядра происходит публично, и это чрезвычайно высокий трафик. Как вам удается успевать за таким объемом электронной почты? Изучали ли вы другие решения для совместной работы и общения за пределами списка рассылки, или есть что-то в простом списке рассылки, которое идеально подходит для вашей работы?

LT: О, я не читаю список рассылки ядра напрямую, и не читал уже много лет. Это слишком.

Нет, смысл списка рассылки ядра в том, что он в основном получает копию во всех обсуждениях (ну – есть один из списков рассылки ядра, их много – и тогда традиционный список lkml является запасным вариантом, когда их больше нет целевой список). И таким образом, когда новый человек привлекается к обсуждению, он может видеть историю и предысторию, просматривая список рассылки ядра.

То, что я делал раньше, было чтобы быть подписанным на список, но чтобы все электронные письма lkml, на которые я не был скопирован лично, были автоматически заархивированы, поэтому я не увижу их по умолчанию. Но затем, когда мне доводилось сталкиваться с какой-то проблемой, все это обсуждение появлялось, потому что оно было в моем электронном письме, а не в моем почтовом ящике, пока оно не понадобилось.

В наши дни, На самом деле я использую lore.kernel.org функциональность вместо этого, потому что он работает так хорошо, и у нас есть другие инструменты, построенные вокруг него. Таким образом, вместо того, чтобы автоматически архивировать его в моих собственных почтовых архивах, обсуждения в конечном итоге становятся видимыми. Но основной рабочий процесс концептуально тот же.

Я все еще получаю изрядное количество писем, очевидно, – но во многих отношениях с годами ситуация улучшалась, а не хуже . Большая часть этого – это Git и то, насколько хорошо работает процесс выпуска ядра: раньше у нас было гораздо больше проблем с потоком кода и инструментами. Моя ситуация с электронной почтой была на самом деле намного хуже на рубеже веков, когда мы все еще имели дело с огромными заплатками и у нас были серьезные проблемы с масштабируемостью в процессе разработки.

И модель списка рассылки (с инструментами вокруг нее) действительно работает очень хорошо. Это не означает, что люди не используют другие средства связи, помимо электронной почты (как личные сообщения, так и списки рассылки): есть люди, которым нравятся различные настройки чата в реальном времени (традиционным является IRC). И хотя это никогда не было моим делом, очевидно, что это то, что некоторые люди любят использовать для мозгового штурма. Но эта модель «список рассылки в виде архива» работает очень хорошо и безупречно работает вместе со всеми принципами «отправлять исправления между разработчиками по электронной почте» и «отправлять отчеты о проблемах по электронной почте».

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

KernelTrap logo

JA: Я внимательно следил за разработкой ядра около десяти лет, KernelTrap logo писал об этом в блоге на KernelTrap. и писать о новых функциях по мере их развития . Я остановился примерно в то время, когда было выпущено ядро ​​3.0, которое за 8 лет последовало за версиями 2.6.x. Можно ли подытожить некоторые из наиболее интересных вещей, которые произошли в ядре с момента выпуска 3.0?

LT: Хех. Это так давно, что я даже не мог подвести итог. С версии 3.0 прошло десять лет, и за это десятилетие у нас было много технических изменений. ARM выросла и ARM 70 стала одной из наших основных архитектур. Множество новых драйверов и новых основных функций.

Во всяком случае, что интересно в последнее десятилетие, так это то, как мы на самом деле поддерживали реальную модель разработки по-настоящему гладкой, и что не не изменилось.

Мы ‘ За прошедшие десятилетия я прошел через множество различных схем нумерации версий, у нас были разные модели разработки, но выпуск 3.0 фактически завершил ту модель, которую мы использовали с тех пор. Это вроде как официально объявлено, что все «выпуски основаны на времени, номера версий – это просто числа и не имеют каких-либо зависимостей функций».

Мы начали все время выпуски с окном слияния в дни 2.6.x, так что эта часть не была новой. Но была версия 3.0, когда последние остатки «числа имеет значение» были выброшены за борт.

У нас была случайная схема нумерации (в основном до 1.0), у нас была целые «нечетные младшие числа» означают разрабатываемое ядро, даже означает стабильное производственное ядро ​​», а затем в версии 2.6.x мы начали использовать модель выпуска, основанную на времени. Но у людей все еще оставался вопрос: «Что нужно сделать, чтобы увеличить основное число?». А версия 3.0 официально заявила, что даже основной номер версии не имеет значения, и что мы просто постараемся, чтобы с цифрами было легко работать, и не позволять им расти слишком большими.

Итак, за последнее десятилетие мы внесли абсолютно огромные изменения (Git позволяет легко отображать некоторую статистику в цифрах: около трех четвертей миллиона коммитов более тысяч человек). Но сама модель разработки на самом деле была довольно гладкой и стабильной.

И это действительно не всегда так. Первые два десятилетия разработки ядра были полны довольно болезненных изменений модели разработки. Последнее десятилетие было гораздо более предсказуемым с точки зрения выпуска.

ДА: На данный момент последний выпуск – 5. 15 – rc5. Насколько стандартизирован процесс выпуска? Например, какие изменения вносятся в -rc1 по сравнению с -rc2 и т. Д.? И в какой момент вы решаете, что данный релиз готов к официальному выпуску? Что произойдет, если вы ошибаетесь и после финального релиза будет обнаружен большой регресс, и как часто это происходит? Как этот процесс развивался с годами?

LT: Итак, я сослался на это ранее: сам процесс действительно довольно стандартный, и оставался таковым в течение последнего десятилетия. До этого он пережил несколько потрясений, но на самом деле он работал почти как часы с версии 3.0 (а на самом деле, за несколько лет до этого – переход на Git во многих отношениях был началом современного процесса, и это заняло некоторое время, прежде чем все привыкли к этому).

Итак, у нас была каденция «двухнедельного окна слияния», за которой следовали примерно 6-8 еженедельных выпусков-кандидатов перед финальным выпуском почти для 18, я думаю, прошло уже несколько лет

И правила всегда были одни и те же, хотя они не всегда строго соблюдались: окно слияния предназначено для нового кода, который якобы «протестирован и готов», а затем следующие примерно два месяца предназначены для исправления и на самом деле убедиться, что все проблемы устранены. Что не всегда происходит, и иногда этот якобы “готовый” код отключается или полностью возвращается в исходное состояние перед выпуском.

А затем это повторяется – так что у нас есть выпуск примерно каждые 12 недель или около того.

И релиз критерием является то, что я чувствую себя достаточно уверенно, что, очевидно, в свою очередь, основано на том, какие виды отчетов о проблемах все еще поступают. Если в какой-то области все еще появляются проблемы на поздних этапах RC-игры, я довольно агрессивно отношусь к тому, чтобы просто вернуть вещи и сказать «мы я займусь этим в более позднем выпуске, как только мы полностью разобрались с этим вопросом “, но в целом это довольно редко, что требуется.

Всегда ли получается ? Нет. Как только ядро ​​будет выпущено – и особенно после того, как оно появится в дистрибутиве – у вас появятся новые пользователи, вы получите людей, которые не тестировали его во время разработки, которые находят вещи, которые не работали, и которые мы не поймали во время rc. ряд. Это почти неизбежно. Это часть того, почему у нас есть целые деревья «стабильного ядра», которые продолжают добавлять исправления после выпуска. И некоторые стабильные ядра поддерживаются дольше, чем другие, и называются ядрами LTS («Долгосрочная поддержка»).

Все это практически не изменилось за последние десять лет, хотя в конечном итоге мы получаем гораздо больше автоматизации. Автоматизация тестирования ядра в целом сложна – отчасти потому, что большая часть ядра – это драйверы, которые, очевидно, зависят от доступности оборудования, – но есть несколько ферм, выполняющих как загрузочное тестирование, так и тестирование производительности, а также различные рандомизированные нагрузочные тесты. И это значительно улучшилось с годами.

ДА: В ноябре прошлого года вас цитировали как впечатлен новым ARM , найденные в некоторых из их новых компьютеров. Следите ли вы за усилиями разработчиков по их поддержке с помощью Linux? Я вижу работа была слился с for-next . Вероятно ли, что Linux загрузится на оборудовании Apple MacBook уже в следующей версии 5. 18 ядро? Скорее всего, вы станете одним из первых последователей? Какое значение имеет ARM ?

LT: Я проверяю это очень время от времени, но это еще не все. Как вы заметили, самая ранняя поддержка, вероятно, будет объединена в 5. 17, но нужно понимать, что На самом деле это только начало, и оно еще не делает оборудование Apple полезным с Linux.

Это не рука 70 часть, которая в конечном итоге становится проблемой, но все драйверы для оборудования вокруг нее ( В частности SSD и GPU). На ранних этапах работы некоторые из действительно низкоуровневых работ уже работают, но не дает ничего полезного, кроме раннего включения оборудования. Потребуется время, чтобы люди могли его опробовать.

Но улучшилось не только оборудование Apple – инфраструктура для arm 71 в целом сильно вырос, а ядра из «Meh» стали более конкурентоспособными на сервере. Рука64 не так давно место на сервере было довольно печальным, но процессоры Amazon Graviton2 и Ampere Altra – оба основаны на значительно улучшенном IP ARM Neoverse – намного лучше, чем какие предложения были несколько лет назад.

Я уже более десяти лет ждал, чтобы у меня появилась пригодная для использования машина ARM, и ее еще нет, но явно много ближе, чем было раньше.

На самом деле, я думаю, я мог бы сказать, что я хотел машину ARM гораздо дольше, чем это – когда я был подростком, машина, которую я действительно хотел, была Acorn Archimedes, но доступность и цена заставили меня выбрать Sinclair QL (M Threadripper процессор), а затем, очевидно, несколько лет спустя ai 500 ПК.

Так что это было похоже на производство в течение десятилетий, но они все еще не были широко доступны и конкурентоспособны по цене / производительности, как c компьютеры для меня. Один день. Надеюсь, в не слишком далеком будущем.

JA: Есть ли что-нибудь в ядре, которое не является оптимальным, но требует полной переписи для правильной адресации? Другими словами, ядро ​​32 лет, знания, языки и оборудование сильно изменились в этих 32 лет: если бы вы сейчас переписали его с нуля, что бы вы изменили?

LT: Мы действительно действительно хорош в том, чтобы даже полностью переписать вещи, если это необходимо, так что все, что было бы полной катастрофой, уже давно было переписано.

Конечно, у нас есть изрядное количество слоев “совместимости”, но обычно они не ужасны. И неясно, действительно ли эти уровни совместимости исчезнут при переписывании с нуля – они связаны с обратной совместимостью со старыми двоичными файлами (и часто с обратной совместимостью со старыми архитектурами, например, при запуске 55 – бит x 90 приложения на x 86 – 71). Поскольку я считаю, что обратная совместимость очень важна, я бы хотел сохранить их даже при перезаписи.

Итак, очевидно, что есть много вещей, которые “не оптимальны” в чувство, что что угодно можно улучшить, но, как вы формулируете вопрос, я должен сказать, что нет, в этом нет ничего, что я презираю. Существуют устаревшие драйверы, о которых никто никогда не позаботится в достаточной степени, чтобы очистить их, и поэтому они могут делать ужасные вещи, но ключевой частью этого является «всем наплевать». Это не было проблемой, и когда это действительно становится проблемой, мы склонны довольно активно удалять настоящую устаревшую поддержку, о которой мы не можем найти никого, кто бы это заботил. Таким образом, мы избавились от множества драйверов за эти годы, и мы избавились от поддержки всей архитектуры, когда ее уже не имеет никакого смысла поддерживать.

Нет , единственная серьезная причина для «переписывания» будет заключаться в том, что в конечном итоге у вас будет какой-то вариант использования, когда вся структура больше не имеет смысла. Наиболее вероятным сценарием будет небольшая встраиваемая система, которой просто не нужно все, что предлагает Linux, и которая имеет настолько малую площадь оборудования, что ей просто нужно что-то меньшее и более простое, чем то, чем Linux стал за эти годы.

Потому что Linux сильно вырос. Даже небольшое оборудование (например, сотовые телефоны и т. Д.) Сегодня намного более способно, чем было на исходной машине, на которой был разработан Linux.

JA: А как насчет того, чтобы хотя бы части переписать на Rust, языке, который был специально разработан для обеспечения производительности и безопасности? Есть ли возможности для улучшения в этом направлении? Считаете ли вы возможным когда-нибудь другой язык, такой как Rust, заменить C в ядре?

Apple M1 ARM64 Chip

LT: Посмотрим. Я не думаю Ferris the crab, unofficial mascot for Rust Ржавчина возьмет на себя основное ядро, но использование отдельных драйверов (и, возможно, целых подсистем драйверов) в нем не кажется маловероятным. Возможно, файловые системы тоже. Так что это не «заменить C», а скорее «дополнить наш код C там, где это имеет смысл».

Конечно, драйверы, в частности, составляют примерно половину реального кода ядра, так что для этого есть много места, но я не думаю, что кто-то действительно ожидает переписать существующие драйверы в Rust оптом, скорее «некоторые люди сделают новые драйверы в Rust, и пара драйверов может быть переписана там, где это необходимо». имеет смысл ».

Но сейчас это больше похоже на« люди пробуют и играют с этим », чем на что-то большее. Легко указать на преимущества, но, безусловно, есть и сложности, поэтому я очень выжидаю, чтобы увидеть, действительно ли обещанные преимущества оправдываются.

ДА: Есть ли какие-то особые части ядра, которыми вы лично больше всего гордитесь?

LT: Наиболее выделяющиеся части, на которые я обычно обращаю внимание, – это уровень VFS («виртуальная файловая система») (и поиск по имени пути). в частности) и наш код виртуальной машины. Первое, потому что Linux просто выполняет некоторые из этих фундаментальных вещей (поиск имени файла действительно является такой основной операцией в операционной системе) намного лучше, чем что-либо еще. И последнее в основном потому, что мы поддерживаем 30 +, и мы по-прежнему делаем это с в значительной степени унифицированным уровнем виртуальных машин, что, на мой взгляд, довольно неплохо. впечатляет.

Но в то же время это во многом зависит от того, «какая часть ядра вас интересует». Ядро достаточно велико, чтобы разные разработчики (и разные пользователи) просто имели разные мнения о самом важном. Некоторые думают, что планирование – самая захватывающая часть ядра. Другим нравится детальность драйверов устройств (а у нас их много). Лично я склонен более активно работать с виртуальными машинами и VFS, поэтому я, естественно, указываю на них.

JA: Я нашел это описание поиска имени пути , и это сложнее, чем я ожидал. Что делает реализацию Linux намного лучше, чем то, что сделано в других операционных системах? И что вы имеете в виду под словом «лучше»?

LT: поиск по имени действительно настолько распространенная и фундаментальная вещь, что большинство людей, не являющихся разработчиками ядра, даже не думают об этом как о проблеме: они просто открывают файлы и принимают все как должное.

Но на самом деле это довольно сложно сделать по-настоящему хорошо. Именно потому, что абсолютно все все время выполняет поиск по имени пути, это чрезвычайно критично для производительности, и это очень важно одна из тех областей, где вы также хотите хорошо масштабироваться в средах SMP, и у нее есть много сложностей с блокировкой. И вы очень не хотите делать какие-либо операции ввода-вывода, поэтому кеширование очень важно. Фактически, поиск по имени настолько важен, что вы не можете оставить его на низкоуровневую файловую систему. , потому что у нас + различные файловые системы, и если каждая из них будет выполнять собственное кэширование и собственную блокировку, это будет полной катастрофой.

Итак, одна из основных вещей, которые делает уровень VFS, – это действительно обработка всех блокировок и кэширования компонентов пути, а также обработка всей сериализации и обход точки монтирования, и все это в основном с алгоритмами без блокировки ( RCU ), но также с некоторыми действительно умными вещами, подобными блокировкам (блокировка “lockref” ядра Linux – это особая “спин-блокировка со счетчиком ссылок”, которая была буквально разработана для кэширования dcache, и в основном это специализированный счетчик ссылок с поддержкой блокировок, который может выполнять снятие блокировок в некоторых типичных ситуациях).

Конечный результат: низкоуровневый f Файловые системы по-прежнему должны выполнять фактический поиск вещей, которые не кэшируются, но им не нужно беспокоиться о кешировании и всех правилах согласованности и правилах атомарности, которые используются при поиске имени пути. VFS справляется со всем этим за них.

И все это превосходит все, что сделала любая другая операционная система, при этом в основном идеально масштабируется даже на машины с тысячами процессоров. И это происходит, даже когда все эти машины в конечном итоге касаются одних и тех же каталогов (потому что такие вещи, как корневой каталог или домашний каталог проекта, – это вещи, которые даже приложения с большим количеством потоков соприкасаются одновременно, и которые не распространяются.

Так что это не просто «лучше», а «Лучше» с большой буквы. Больше ничего из re подходит даже близко . Linux dcache просто находится в отдельном классе.

ДА: Прошлый год был сложно во всем мире. Каким образом COVID – пандемия повлияла на процесс разработки ядра?

LT: На самом деле это оказало очень минимальный эффект из-за того, как мы всегда работали. Электронная почта действительно стала прекрасным инструментом, и мы не полагались на личные встречи.

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

И это, очевидно, повлияло на всю нашу жизнь другими способами – только на социальные разветвления в целом. Но в целом, будучи разработчиком ядра, который уже общался с людьми почти полностью по электронной почте, мы, вероятно, были наименее затронуты.

Распределенная система контроля версий Git

JA: Linux это только один из ваших вездесущих вкладов в открытый исходный код. В 2005 вы также создали Git, чрезвычайно популярную систему управления распределенным исходным кодом. Вы быстро перенесли дерево исходного кода ядра Linux из проприетарного Bitkeeper во вновь созданный Git с открытым исходным кодом и в том же году передали поддержку Хунио Хамано . Там много интересной истории, что заставило вас так быстро передать руководство этим проектом, и как вы нашли и выбрали Джунио?

LT: Итак, этот ответ состоит из двух частей.

Git Logo

Первая часть состоит в том, что я очень не хотел создать новую систему управления версиями. Linux был создан потому, что я считаю низкоуровневый интерфейс между аппаратным и программным обеспечением увлекательным – это, по сути, труд любви и личных интересов. Напротив, Git был создан по необходимости: не потому, что я нашел управление исходным кодом интересным, а потому, что я абсолютно презирал большинство существующих систем управления исходным кодом, а также ту, которую я нашел наиболее приемлемой и действительно неплохо работал в модели разработки Linux ( BitKeeper) стал неприемлемым.

Конечный результат: Я делал Linux поверх лет (годовщина первого релиза еще через несколько месяцев, но я начал с того, что уже станет Linux 32 лет назад), и я поддерживал его все время. Но Git? Я никогда не думал, что действительно захочу сохранить его надолго. Мне нравится его использовать, и я, очевидно, считаю, что это лучший SCM в огромной степени, но это не моя основная страсть и интерес, если вы понимаете, что я пытаюсь сказать.

Так что я всегда хотел, чтобы кто-то другой поддерживал SCM за меня – на самом деле, я был бы счастлив, если бы мне не пришлось писать его с самого начала.

Это любезно

Что касается Джунио – он был одним из первых, кто пришел в качестве разработчиков Git. Его первое изменение произошло через несколько дней после того, как я опубликовал самую первую (и очень грубую) версию Git. Так что Джунио на самом деле существует с самого начала Git.

Но это не значит, что я передал проект первому случайному человеку, который появился. Я поддерживал Git в течение нескольких месяцев, и то, что заставило меня спросить Джунио, хочет ли он быть сопровождающим, – это очень трудно описываемое понятие «хорошего вкуса». У меня нет лучшего описания: программирование – это решение технических проблем, но как вы их решаете, и то, как вы о них думаете, тоже важно, и это одна из тех вещей, которые вы начинаете осознавать со временем: у некоторых людей есть «хороший вкус», и они выбирают «правильное» решение.

Я не хочу утверждать, что программирование – это искусство, потому что на самом деле это в основном просто «хорошая инженерия». Я твердо верю в мантру Томаса Эдисона «один процент вдохновения и девяносто девять процентов потливости»: почти все дело в мелких деталях и повседневной работе. Но есть та эпизодическая часть «вдохновения», та вещь «хорошего вкуса», которая означает нечто большее, чем просто решая какую-то проблему – решая ее чисто и красиво и да, даже красиво.

И у Джунио был этот «хороший вкус».

И каждый раз, когда появляется Git, я стараюсь не забывать прояснить его: возможно, я начал и проектировал основные идеи в Git, но я часто получаю слишком много уважения за эту часть. Это было 17 + лет, и я действительно был вовлечен в Git только в тот первый год. Джунио был образцовым сопровождающим, и именно он сделал Git тем, чем он является сегодня.

Кстати, вся эта штука с «хорошим вкусом» и поиск людей, у которых он есть, и доверять им – это касается не только Git. Это тоже во многом история Linux. В отличие от Git, Linux, очевидно, является проектом, который я все еще активно поддерживаю , но очень похож на Git, это также проект, в котором задействовано множество других людей, и я думаю, что одним из самых больших успехов Linux является наличие буквально сотен сопровождающих, все с этим трудно поддающимся определению «хорошим вкусом», и все люди, которые поддерживают части Ядро.

ДА: Вы когда-нибудь передавали управление сопровождающему только для того, чтобы позже определить, что это неправильное решение?

LT: Наша структура сопровождения еще никогда не была такой черствой. -белый и негибкий, что когда-либо было бы проблемой. На самом деле, мы даже не делаем контроль сопровождения чем-то очень документированным: у нас есть файл MAINTAINERS, но это так, чтобы вы могли найти правильные люди, на самом деле это не признак исключительной собственности.

Таким образом, целое «кто чем владеет» – это скорее гибкое руководство , и «этот человек активен и хорошо выполняет свою работу», чем некоторые «ой, теперь мы передали этому человеку собственность, а потом он облажался».

И это тоже плавно в том смысле, что, возможно, вы обслуживаете одну подсистему, но если вам что-то нужно от другой подсистемы, вы часто можете пересекать границы. Обычно это то, о чем люди много говорят , прежде чем сделать, конечно, но дело в том, что это действительно так. случается, и это не какое-то жесткое правило типа «нужно только прикоснуться к этому файлу».

На самом деле, это в некоторой степени связано с предыдущим обсуждением лицензирования и еще одним примером того, как одним из принципов проектирования «Git» было то, что «у каждого свои собственное дерево, и никакое дерево не является технически особенным ».

Потому что во многих других проектах используются инструменты – такие как CVS или SVN – которые принципиально действительно делает некоторых людей особенными, и это, в сущности, имеет сопутствующее «право собственности». В мире BSD это называется «бит фиксации»: предоставление сопровождающему «бит фиксации» означает, что теперь ему разрешено выполнять фиксацию в центральном репозитории (или, по крайней мере, в его части).

Я всегда ненавидел эту модель, потому что она неизбежно приводит к политике и «кликовой» модели развития, где некоторые люди являются особенными и безоговорочно доверяют им. И проблема даже не в том, что “неявно доверяют”, а в том, что обратная сторона медали состоит в том, что другие людям не доверяют, они по определению посторонние и должны пройти через один из хранителей.

Опять же, в Git такой ситуации не существует. Все равны. Любой может сделать клон, заняться собственной разработкой, и если он сделает хорошую работу, он может быть снова объединен (а если он сделает выдающуюся работу, он станет сопровождающим, и в конечном итоге именно он будет выполнять слияние со своими деревьями; ).

Таким образом, нет необходимости давать людям особые привилегии – нет необходимости в этом «бите фиксации». А это также означает, что вы избегаете политики, связанной с этим, и вам не нужно безоговорочно доверять людям. Если они в конечном итоге плохо справляются с работой – или, что чаще всего, просто угасают и обнаруживают другой интерес, – их не объединяют, и они также не встают на пути других людей, у которых есть свежие новые идеи.

ДА: Новые функции Git когда-нибудь впечатляют вас и становятся частью вашего рабочего процесса? Есть ли функции, которые вы бы еще хотели добавить?

LT: My варианты использования, очевидно, были первыми, что было реализовано, поэтому для меня это редко было связано с новыми функциями.

С годами Git, безусловно, улучшился, и некоторые из них были заметно и в моем рабочем процессе. Например, Git всегда был довольно быстрым – в конце концов, это была одна из моих целей дизайна – но большая часть его изначально была сделана в виде сценария оболочки для некоторых основных вспомогательных программ. С годами большая часть сценариев оболочки исчезла, а это означает, что я могу применять патч-бомбы от Эндрю Мортона даже быстрее, чем я мог изначально. Что очень отрадно, так как это был один из первых тестов, которые я использовал для тестирования производительности.

Так что Git всегда мне нравился, но теперь стало лучше.

большие улучшения были о том, насколько он лучше стали использовать как “обычный пользователь”. Многие люди изучают рабочий процесс Git и просто привыкают к нему (это ) очень отличается от CVS и других вещей, к которым люди привыкли), но во многом это связано с тем, что Git стал намного более приятным в использовании.

Заключение, часть первая

Во второй части этого интервью Линус рассказывает о том, чему он научился, управляя большим проект с открытым исходным кодом. Он предлагает много идей и советов специалистам по обслуживанию о том, что, по его мнению, лучше всего подходит для него, и как он избегает выгораний. Он также рассказывает о Linux Foundation и о том, что он делает, когда не сосредоточен на разработке ядра Linux.

Leave a comment

Your email address will not be published. Required fields are marked *