Как стать автором
Обновить
3700.03
Рейтинг
Маклауд
Облачные серверы на базе AMD EPYC

30 лет Линукса. Интервью с Линусом Торвальдсом. Часть 2

МаклаудНастройка LinuxРазработка под LinuxИстория ITИнтервью
Перевод
Автор оригинала: JEREMY ANDREWS


Первая часть интервью.

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


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

ЛТ: Итак, ответ на этот вопрос состоит из двух частей.


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

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

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

Таков контекст.

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

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

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

Вот у Джунио такой «хороший вкус» нашелся.

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

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

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

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

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

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

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

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

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

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

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

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

ЛТ: разумеется, в первую очередь были удовлетворены именно мои пожелания по функционалу, поэтому мне редко приходилось задумываться о каких-либо новых фичах.

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

Итак, для меня Git всегда был хорош, но со временем стал только лучше.

Значительные улучшения связаны с тем, насколько удобнее стало «обычным пользователям» работать с Git. Во многом благодаря тому, что люди разобрались, как в Git устроен поток задач, и просто привыкли к нему (он очень отличается от CVS и других аналогов, к которым люди привыкли ранее), но и сам Git стал гораздо приятнее в использовании.



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Теги:vdsvpsбыстрые vpsлинус торвальдсинтервьюlinuxядро linux
Хабы: Маклауд Настройка Linux Разработка под Linux История IT Интервью
Всего голосов 47: ↑46 и ↓1 +45
Просмотры14.5K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
macloud.ru
Численность
11–30 человек
Дата регистрации
Представитель
Mikhail

Блог на Хабре