Линус Торвальдс о развитии и будущем Linux

0
121
Линус Торвальдс о развитии и будущем Linux

Содержание страницы

Создатель Linux подробно рассказывает о ядре, сообществе и о том, как вычисления будут меняться в ближайшие годы

В последний раз, когда мне довелось провести собеседование с Линусом Торвальдсом, это был 2004 год, а версия 2.6 ядра Linux была недавно выпущена. Я работал над функцией под названием « Linux v2.6 масштабирует предприятие ». Вступительное предложение было «Если коммерческие вендоры Unix уже не беспокоились о Linux, они должны быть теперь». Насколько пророческими оказались эти слова.

Более 12 лет спустя — несколько жизней в вычислительном мире — Linux можно найти во всех уголках технологического мира.

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

Следующее интервью предлагает Torvalds взять на себя будущее x86, изменения в разработке ядра, контейнеры Linux, а также то, как сдвиги в вычислительных и конкурирующих моделях модернизации ОС могут повлиять на Linux вниз.

Истоки Linux были в средах с низким ресурсом, и практика кодирования была непреодолимой.

Сегодня это не так в большинстве случаев использования. Как вы думаете, что повлияло на методы разработки для ядра или операционных систем в целом?

Я думаю, что ваша предпосылка неверна: происхождение Linux было определенно не таким низким ресурсом. 386 был всего лишь самой жесткой машиной, которую вы могли купить в качестве рабочей станции в то время, и в то время как 4 МБ или 8 МБ ОЗУ звучат смехотворно сдержанно сегодня, и вы бы сказали «обязательно худой», в то время, когда это не чувствовалось так вообще.

Поэтому я чувствовал, что у меня есть память и ресурсы, которые можно сэкономить еще 25 лет назад, и вовсе не ограничены аппаратными средствами. И аппаратное обеспечение все улучшалось, так как Linux рос — и, возможно, что более важно, в качестве рабочих нагрузок, которые вы могли бы использовать для Linux для роста, мы все еще не испытывали особого ограничения со стороны аппаратных ресурсов.

С точки зрения развития, я не думаю, что все изменилось так сильно.

Во всяком случае, я думаю, что в эти дни, когда люди пытаются помещать Linux в некоторые действительно крошечные встроенные среды (IoT), у нас на самом деле есть разработчики сегодня, которые чувствуют себя более ограниченными, чем разработчики ядра, которые чувствовали себя 25 лет назад. Это звучит странно, поскольку эти устройства IoT имеют тенденцию быть более мощными, чем оригинальные 386, которые я начал, но мы выросли (много), и ожидания людей тоже выросли.

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

Тот факт, что Linux является «серьезным бизнесом», явно изменяет работу, вы имеете больше правил и должны быть более внимательными и осторожными в отношении выпусков.

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

Наша модель развития сильно изменилась за четверть века, но я не думаю, что это связано с аппаратными ограничениями.

Вы видите какие-то фундаментальные различия среди молодых хакеров ядра сегодня против 20 лет назад?

Очень сложно быть интроспективным и на самом деле все правильно. Я не думаю, что разработчики ядра обязательно все это другое; Я думаю, что масштаб и зрелость самого проекта — гораздо большая разница.

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

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

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

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

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

Рассматриваете ли вы цветущий рост языков более высокого уровня и интерпретируемых языков и связанные с ними методы кодирования, так как привлекать талантливых разработчиков от основной внутренней разработки ОС?

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

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

Как вы думаете, что будет в будущем для x86?

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

Это очевидная сюжетная линия, и это заставляет многих людей волноваться по поводу всего x86 -vs.-ARM : «ARM собирается расти и вытеснять x86».

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

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

Этот шаблон не удерживается для сравнения x86 -vs.-ARM. Фактически, это наоборот: даже если вы развиваетесь для меньшей ARM-экосистемы, вы все равно почти наверняка используете ПК (будь то Linux, MacOS или Windows) для разработки, и вы просто развертываете на ARM.

В этом очень реальном смысле, в историческом сравнении с тем, как компьютеры x86 заняли компьютерный мир, ARM на самом деле больше похожа на большое аппаратное обеспечение, которое смещено и меньше похоже на ПК, который его перемещает.

Что все это значит? Я не знаю. Я не вижу, что ARM растет, пока он недостаточно самодостаточен, и это, похоже, не происходит. Я ждал его уже десять лет, и кто знает, когда это происходит на самом деле.

Мы можем быть в ситуации, когда у вас есть отдельные архитектуры для разных ниш: ARM для бытовой электроники и встроенного оборудования и x86 для ПК / рабочей станции / сервера. Когда IBM поддерживает свои собственные архитектуры навсегда (эй, S / 390 все еще вокруг, и Power, похоже, тоже не уходит), реальность может быть менее захватывающей, чем архитектура Thunderdome («две архитектуры входят, одна архитектура уходит») ,

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

Что вы думаете о проектах, которые в настоящее время разрабатываются для разработки ядер ОС на таких языках, как Rust (рекламируются за встроенные функции безопасности, которые нет в C)?

Это совсем не новое явление. У нас были люди системы, которые использовали Modula-2 или Ada, и я должен сказать, что Rust выглядит намного лучше, чем любая из этих двух катастроф.

Я не уверен в том, что Rust для ядра ОС (тем не менее, для системного программирования гораздо больше, чем для ядра), но в то же время нет сомнений в том, что C имеет множество ограничений.

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

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

Что для вас является самым большим приоритетом для разработки ядра: поддержка новых функций аппаратного обеспечения или процессора, повышение производительности, повышение безопасности, обеспечение новых форм поведения разработчиков (таких как технология контейнеров) или что-то еще?

Я лично? На самом деле я больше всего беспокоюсь о проблемах «потока разработки», а не о проблемах с кодом.

Да, я по-прежнему участвую в нескольких областях (в основном, в слое VFS, но иногда в VM), где я забочусь о конкретных проблемах с производительностью и т. Д., Но на самом деле это скорее боковое хобби, чем моя основная работа в эти дни.

Я признаю, что все еще нахожу новые функции архитектуры процессора очень интересными — именно поэтому я начал, в первую очередь, Linux, и это все-таки то, за чем я следую и люблю видеть интересные новые вещи. Я был очень рад видеть возможности транзакционной памяти , например, даже если реклама, похоже, сильно утихла.

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

Моя основная модель [по отношению] к разработке ядра — убедиться, что мы все правильно поняли, что у нас есть правильные люди, работающие над нужными вещами, и что нет никаких ненужных вещей, стоящих на пути развития. Если процесс будет работать правильно, а люди будут заботиться о качестве, конечный результат позаботится о себе, в некотором смысле.

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

Как вы думаете, что еще нужно сделать для улучшения Linux-контейнеров?

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

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

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

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

За последние несколько лет мы видели, как Microsoft, Google и Apple выпускали новые выпуски для настольных компьютеров и мобильных ОС беспрецедентным образом. Каковы ваши взгляды на все более быстрые циклы выпуска для настольных и мобильных операционных систем?

Источник: https://www.itworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html