Ядро linux для андроид

Android – это Linux. Или нет?

Константин Иванов

Android – это Linux? Казалось бы, это тот вопрос, на который должен существовать прямой ответ – да или нет. Но вместо этого сообщества пользователей Android и Linux годами обсуждают, как обстоят дела на самом деле, и не могут прийти к согласию.

Есть два фактора, которые делают особенно сложным поиск четкого ответа на вопрос, являются ли Android и Linux одним и тем же.

1. Люди часто используют слово Linux для обозначения определенного числа связанных между собой, но однозначно разных вещей.
2. Нет четкого, однозначного и повсеместно принятого определения, что позволяет считать то или иное ПО Linux.

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

Так что же такое Linux?

Когда кто-то говорит «Linux», это может относиться к следующим вещам:

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

В свою очередь, вокруг термина Android нет такой путаницы. Есть, тем не менее, два вида ОС Android.

Первый – это Android Open Source Project (AOSP), проект, в рамках которого Google предоставляет доступ к исходному коду Android. Этот код можно использовать для того, чтобы создать рабочую операционную систему, которую можно установить на смартфон или планшет, но в итоге ей будет не хватать функциональности, которую большая часть пользователей ожидают получить от своего опыта взаимодействия с Android, наиболее характерный пример – это мобильные сервисы Google. Это набор приложений и API от Google, которые для большого числа пользователей являются основной частью опыта работы с Android, аналогично тому, как iTunes и App Store являются основной частью опыта на macOS. AOSP имеет открытый исходный код, но не обеспечивает тех возможностей, которых ожидает типичный конечный пользователь устройства, работающего на ОС Android.

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

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

Почему Android – Linux?

Существует всего лишь один реальный аргумент в пользу того, чтобы расценивать Android как Linux, но это серьезный аргумент. Каждый смартфон или планшет на Android содержит ядро Linux. Вы даже можете увидеть, какая версия ядра установлена на вашем устройстве. Для этого надо зайти в Настройки – Об устройстве – Версия ядра.

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

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

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

Почему Android – не Linux?

Он не использует стандартное ядро Linux

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

Поскольку основной аргумент в пользу того, чтобы расценивать Android как дистрибутив Linux, базируется на том факте, что Android использует ядро Linux, может показаться, что тут и всяким спорам конец, все и так вполне очевидно. Однако для дистрибутива Linux не является обычным делом внесение изменений в ядро.

Ядро Linux подпадает под действие Универсальной общественной лицензии GNU, каждый волен как хочет изменять его исходный код, что и делается во многих дистрибутивах Linux. Если говорить о том, насколько значительным изменениям подвергла команда разработчиков Android ядро Linux, в Embedded Linux wiki приходят к заключению, что количество изменений, внесенных командой Android, «не особенно велико и не выходит за рамки того, что обычно делают с ядром Linux разработчики ОС на его базе».

Android не включает в себя ПО GNU и библиотеки

Если вы согласны с тем, что наличие ПО GNU является определяющей характеристикой для дистрибутива Linux вплоть до того, что мы должны расценивать дистрибутивы Linux как GNU/Linux, тогда Android ни в коем случае не может быть дистрибутивом Linux. Android включает в себя лишь некоторые системные библиотеки GNU. Из самого заметного – команда разработчиков Android разработала кастомизированную C-библиотеку под названием Bionic вместо того, чтобы использовать C-библиотеку GNU.

И даже если вы не согласны с тем, что дистрибутив Linux должен включать в себя ПО GNU, трудно отрицать, что отсутствие GNU делает Android очень отличным от большей части представителей сообщества дистрибутивов Linux.

Вы не можете запускать приложения Linux на Android – и наоборот

Если вы возьмете несколько выбранных случайным образом дистрибутивов Linux, есть шанс, что единственным общим программным компонентом у них у всех будет ядро Linux. В реальности у Android так мало общего ПО с другими дистрибутивами Linux, что запускать обычные приложения Linux на Android невозможно.

Верно и обратное утверждение. Приложения для Android требуют специальных библиотек Android, среды выполнения и ряда других программ, которые есть только в ОС Android, так что по умолчанию вы не можете запускать приложения для Android на какой-то другой платформе, кроме Android.

Android – это продукт Google

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

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

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

«Открытый» статус Android под вопросом

Несмотря на рекомендацию Фонда свободного программного обеспечения, предписывающую разработчикам убрать все проприетарное программное обеспечение из их дистрибутивов Linux, нет строгого правила, которое бы запрещало дистрибутивам Linux содержать проприетарное ПО. В реальности многие дистрибутивы включают в себя скомпилированные бинарные драйверы, известные также как блобы. Поэтому на самом деле вопрос стоит так: насколько открыт Android в сравнении с вашим типичным дистрибутивом Linux?

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

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

Это не обязательно означает, что Android невозможно расценивать как дистрибутив Linux, но нельзя не отметить, что большая часть кода, который пользователи могут видеть и с которым могут взаимодействовать, является проприетарной, таковы мобильные сервисы Google и модификации производителя, как, например, TouchWiz от Samsung.

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

Вы не можете кастомизировать ОС Android – по умолчанию

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

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

Заключение

Итак, возвращаемся к исходному вопросу: является ли Android дистрибутивом Linux? В целом, все сводится к тому, что вы подразумеваете под дистрибутивом Linux. Если вы согласны с тем, что мы должны относить к дистрибутивам Linux GNU/Linux, а не Linux, тогда ответ отрицательный, поскольку Android включает в себя очень малую часть ПО GNU.

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

Однако если вы определяете дистрибутив Linux как операционную систему, которая основана на ядре Linux, тогда Android является дистрибутивом Linux. Возможно, это необычный, высокоспециализированный дистрибутив, но это такой же дистрибутив, как Ubuntu, Fedora, Debian и любая другая операционная система, основанная на ядре Linux.

А каково ваше мнение? Является ли Android дистрибутивом Linux просто по причине наличия в нем ядра Linux? Или операционная система должна соответствовать ряду дополнительных критериев, чтобы можно было считать ее дистрибутивом Linux?

Источник

Как обновить ядро ​​Android до последней стабильной версии Linux —

Мы рассмотрели руководства по ядрам Android, такие как «Как создать собственное ядро» и «Лучшие кастомные ядра для Android», но сегодня мы собираемся показать вам, как использовать ядро ​​против последней стабильной версии Linux.

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

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

Что такое ядро ​​Linux-Stable?

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

1. Линус Торвальдс получит несколько патчей от своих сопровождающих в течение двух недель.
2. После этих двух недель он выпускает ядро ​​rc1 (например, 4.14-rc1).
3. На каждую неделю в течение следующих 6-8 недель он выпускает другое ядро ​​RC (например, 4.14-rc2, 4.14-rc3 и т. Д.), Которое содержит ТОЛЬКО исправления ошибок и регрессии.
4. Как только он будет считаться стабильным, он будет выпущен в виде архива для загрузки в org (например, 4.14).

Что такое ядра LTS?

Каждый год Грег выбирает одно ядро ​​и поддерживает его в течение двух лет (LTS) или шести лет (расширенный LTS). Они предназначены для продуктов, которым требуется стабильность (например, телефоны Android или другие устройства IOT). Процесс такой же, как и выше, просто это происходит дольше. В настоящее время существует шесть ядер LTS (которые всегда можно посмотреть на странице релизов kernel.org):

• 4.14 (LTS), поддерживается Грег Кроа-Хартман
• 4.9 (LTS), поддерживается Грег Кроа-Хартман
• 4.4 (eLTS), поддерживается Грег Кроа-Хартман
• 4.1 (LTS), поддерживается Сашей Левиным
• 3.16 (LTS), поддерживается Беном Хатчингсом
• 3.2 (LTS), поддерживается Беном Хатчингсом

Каковы преимущества перехода моего ядра Android на Linux Stable?

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

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

Да и нет, в зависимости от того, как вы определяете «в основном». Ядро Linux может содержать много кода, который не используется в системе Android, но это не гарантирует, что при слиянии новых версий не будет конфликтов с этими файлами! Поймите, что практически никто не собирает каждую часть ядра, даже самые распространенные дистрибутивы Linux, такие как Ubuntu или Mint. Это не значит, что вы не должны принимать эти исправления, потому что ЯВЛЯЮТСЯ исправления для водителей вы ДЕЛАТЬ запустить. Возьмем, например, arm / arm64 и ext4, которые являются наиболее распространенной архитектурой Android и файловой системой соответственно. В 4.4 с 4.4.78 (версия последнего тега Oreo CAF) до 4.4.121 (последний восходящий тег) это следующие цифры для коммитов этих систем:

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

Как объединить стабильное ядро ​​Linux в ядро ​​Android

Для начала вам необходимо выяснить, какая версия ядра работает на вашем Android-устройстве.

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

Он вернет вам ту версию, на которой вы находитесь. Первые два числа будут использоваться для определения нужной вам ветки (например, linux-4.4.y для любого ядра 4.4), а последнее число будет использоваться для определения, какую версию вам нужно начать со слияния (например, если вы используете 4.4 .21, вы объедините 4.4.22 дальше).

Получить последний исходный код ядра от kernel.org

В kernel.org содержится последний исходный код ядра в репозитории linux-stable. Внизу этой страницы будет три ссылки для получения. По моему опыту, зеркало Google имеет тенденцию быть самым быстрым, но ваши результаты могут отличаться. Запустите следующие команды:

Решите, хотите ли вы объединить все ядро ​​или выберите коммиты

Далее вам нужно будет выбрать, хотите ли вы объединить коммиты или вишню. Вот плюсы и минусы каждого и когда вы можете сделать это.

НОТА: Если исходный код вашего ядра имеет форму tarball, вам, скорее всего, понадобится cherry-pick, иначе вы получите тысячи файловых конфликтов, потому что git заполняет историю, основываясь исключительно на восходящем потоке, а не на том, что изменили OEM или CAF. Просто перейдите к шагу 4.

Вишневый Сбор урожая:

• Проще разрешать конфликты, поскольку вы точно знаете, какой конфликт вызывает проблему.
• Проще перебазировать, так как каждый коммит сам по себе.
• Проще разделить пополам, если возникнут проблемы

• Это занимает больше времени, так как каждый коммит должен быть выбран индивидуально.
• Немного сложнее сказать, является ли коммит восходящим с первого взгляда

сливаться

Pros:

• Это быстрее, так как вам не нужно ждать объединения всех чистых исправлений.
• Когда коммит поступает из апстрима, легче увидеть, поскольку вы не будете коммиттером, а сопровождающим.

Минусы:

• Разрешить конфликты может быть немного сложнее, так как вам нужно будет посмотреть, какой коммит вызывает конфликт, используя git log / git blame, он не скажет вам напрямую.
• Перебазировать сложно, так как вы не можете перебазировать слияние, оно предложит выбрать все коммиты по отдельности. Однако вам не следует часто делать ребазинг, вместо этого используйте git revert и git merge, где это возможно.

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

Добавьте коммиты в ваш источник, по одной версии за раз

Самая важная часть этого процесса — одна версия за раз. В вашей вышестоящей серии МОЖЕТ быть проблемный патч, который может вызвать проблемы с загрузкой или сломать что-то вроде звука или зарядки (объяснено в разделе советов и рекомендаций). По этой причине важно вносить постепенные изменения в версию: легче найти проблему в 50 коммитах, чем в 2000 версий для некоторых версий. Я бы порекомендовал сделать полное слияние только после того, как вы знаете все фиксации проблемы и разрешения конфликтов.

Вишневый Сбор урожая

git cherry-pick v3.10.73..v3.10.74

сливаться

Git Merge v3.10.74

Я рекомендую отслеживать конфликты в коммитах слияния, удаляя маркеры #.

Как разрешить конфликты

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

Если вы объединяетесь, выясните, какой коммит вызывает конфликт. Вы можете сделать это одним из двух способов:

1. git log -p v $ (make kernelversion) .. чтобы получить изменения между вашей текущей версией и последней версией. Флаг -p даст вам изменения, сделанные каждым коммитом, чтобы вы могли видеть.
2. Запустите git blame для файла, чтобы получить хэши каждого коммита в этой области. Затем вы можете запустить git show –format = fuller, чтобы увидеть, был ли коммиттер из mainline / stable, Google или CodeAurora.

• Выясните, есть ли у вас коммит. Некоторые поставщики, такие как Google или CAF, будут пытаться искать критически важные ошибки, такие как исправление Dirty COW, и их обратные порты могут конфликтовать с вышестоящими. Вы можете запустить git log –grep = ”” и посмотреть, вернет ли он что-нибудь. Если это так, вы можете пропустить коммит (если вишня выбирается с помощью git reset –hard git cherry-pick — продолжить) или игнорировать конфликты (удалить >>>>).
• Выясните, существует ли бэкпорт, который портит разрешение. Google и CAF любят делать бэкпорт для некоторых патчей, которые не будут стабильными. Стабильному часто требуется адаптировать разрешение основной линии к отсутствию определенных исправлений, которые Google выбирает для бэкпорта. Вы можете посмотреть основной коммит, запустив git show (основной хеш будет доступен в сообщении коммита стабильного коммита). Если есть бэкпорт, портящий изменения, вы можете либо отменить изменения, либо использовать основную версию (что вам обычно и нужно сделать).
• Прочтите, что пытается сделать коммит, и посмотрите, исправлена ​​ли уже проблема. Иногда CAF может исправить ошибку независимо от апстрима, то есть вы можете либо перезаписать их исправление для апстрима, либо отменить их, как описано выше.

В противном случае это может быть просто результатом добавления CAF / Google / OEM, и в этом случае вам просто нужно перемешать некоторые вещи.

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

Пример URL: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Вы также можете сделать это через командную строку:

Решение резолюций — это все о контексте. Что вы должны делать ВСЕГДА, это убедиться, что ваш последний diff совпадает с исходным, выполнив следующие команды в двух отдельных окнах:

Включить rerere

Git имеет функцию rerere (расшифровывается как Reuse Recorded Resolution), что означает, что при обнаружении конфликта он будет записывать, как вы разрешили его, чтобы вы могли использовать его позже. Это особенно полезно как для хронических ребазеров, так и для слияния, а также для сортировки вишни, поскольку вам просто нужно запустить git add. git — продолжайте при повторной загрузке, так как конфликт будет разрешен так, как вы его разрешили ранее.

Это можно включить, выполнив следующую команду в вашем репозитории ядра:

Как сделать git bisect при запуске в компиляторе или во время выполнения

Учитывая, что вы будете добавлять значительное количество коммитов, очень возможно, что вы внесете компилятор или ошибку во время выполнения. Вместо того, чтобы просто сдаться, вы можете использовать встроенный в git инструмент bisect, чтобы выяснить причину проблемы! В идеале вы будете собирать и обновлять каждую версию ядра по мере ее добавления, чтобы разделение занимало меньше времени, если это необходимо, но вы можете разделить 5000 коммитов без проблем.

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

1. Начало деления пополам: начало мерзавца
2. Пометить текущую версию как плохую: git bisect bad
3. Пометьте ревизию как хорошую: git bisect good
4. Сборка с новой ревизией
5. На основании результата (если проблема существует или нет), скажите git: git bisect good ИЛИ git bisect bad
6. Промойте и повторите шаги 4-5, пока не будет найден проблемный коммит!
7. Вернуть или исправить проблему фиксации.

НОТА: Слияниям нужно будет временно запустить git rebase -i, чтобы применить все патчи к вашей ветке для правильного деления пополам, поскольку деление пополам с объединениями на месте часто будет проверять исходящие коммиты, что означает, что у вас нет ни одного специального коммита для Android. Я могу углубиться в это по запросу, но поверьте мне, это необходимо. После того, как вы определили проблемный коммит, вы можете отменить или повторно включить его в слияние.

НЕ давите обновления вверх по течению

Многие новые разработчики испытывают искушение сделать это, поскольку это «чище» и «проще» в управлении. Это ужасно по нескольким причинам:

• Авторство потеряно. Это несправедливо по отношению к другим разработчикам, если их кредитуют за их работу.
• Делить пополам невозможно. Если вы раздавили серию коммитов и что-то является проблемой в этой серии, невозможно сказать, какой коммит вызвал проблему в сквоше.
• Будущие черри труднее. Если вам нужно перебазировать с помощью сжатой серии, трудно / невозможно сказать, откуда возник конфликт.

Подпишитесь на рассылку Linux Kernel для своевременного обновления

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

Источник