Комментарии 58
Не одобряю такого. ИМХО, в идеале вся поддержка старых чипов должна заключаться в принципе "работает - не трогай". Ведь чипы не меняются? Значит и поддерживать ничего не надо.
А тот факт что поддерживать все-же надо из-за изменений в самом ядре и компиляторе, лишь указывает на несовершенство языка программирования, на то что язык Си не обеспечивает 100-процентную инкапсуляцию различных компонентов и их независимость друг от друга.
Так в том и дело, что НЕ работает.
Ядро постоянно развивается, включая API, которые используются легаси кодом. Изменения API могут поломать код поддержки старых архитектур.
Поэтому кто-то должен постоянно их проверять с новыми ядрами. А кто будет их проверять, если никто ими не пользуется?
Получается, что в ядре находится код с непонятным статусом, но который надо поддерживать, на который надо ориентироваться при совершении изменений. Хотите, чтобы не удаляли - поддерживайте и проверяйте сами. Только так.
Более того, даже с новым ядром далеко не факт, что ПО поверх ядра запустится т.к. в старых процессорах могут отсутствовать инструкции, необходимые новым программам - SIMD и пр.
Поэтому скорее всего на такой старой системе проще и удобнее будет работать со старым ядром и старым ПО.
А почему эти чипы всё ещё в ядре, а не в модулях?
А разве собранное ядро вообще несёт какой-то бинарный код, который принципиально не может исполняться здесь и сейчас? Как я понял, речь идёт о сырцах, которые подключаются под тот или иной таргет (целевую архитектуру компиляции).
Так что с точки зрения структуры сырцов они уже «в модулях» :) просто если оно слишком распухает, начинается постоянное «ойнесобирается», ну а при необходимости можно что-то в более-менее частном порядке обратно втащить, я думаю… но, правда, придётся продраться через все «ойнесобирается», которые накопились :)
А бинарные модули по понятной причине в тех же машкодах, что и ядро, так что эти (буквальные) модули нам не помогут %)
А какая разница? Если их никто не поддерживает, они не будут работать ни в ядре, ни out-of-tree
Тем более, что это поддержка целевой архитектуры, как её модулем собрать, и главное - зачем? У вас ядро для архитектуры Х будет в таком случае собрано без поддержки архитектуры Х
С точки зрения разработчиков ядра все что не находится в официальном гит репозитории ядра не существует. Перенос в out of tree модуль для них это тоже самое что и удаление. В ядре нет - значит не поддерживается.
Не вопрос. Работает - не трогай. Просто не обновляй ядро на дышащем на ладан железе.
Дело не только в возрасте, но в том что новом коде начинает требоваться поддержка новых инструкций, а также люди обновляют железо и количество людей использующие устаревшее оборудование стремится к 0, в таком случае если никто не использует оборудование на старой архитектуре, то ее поддержку нужно убрать, чтобы не тянуть дальше мертвую архитектуру.
"работает - не трогай"
Неизвестно, работает ли. Для многих чипов не производится тестирование из-за отсутствия у мейнтейнера соответствующего железа.
А что-то вообще заведомо сломано, потому что в других подсистемах ядра произошли существенные изменения, а код, отвечающий за поддержку этих чипов, никто не взялся адаптировать. Заставить кого-то это сделать принудительно вы не можете.
Покуда чистка не затрагивает историю в гите -- давно пора.
Хлам - долой. Для специализированных случаев есть специализированные редакции и возможность вносить правки. Не верите/не согласны? А ну тогда небыло бы у нас ни Андроида, ни RaspberryPi и проч. Сейчас всё с исключительным уровнем специфичности можно залить в отдельный модуль и расшарить. Только пожалуйста, упаси вас бог превращать это в Виндоус, заплывшей жиром, с огромным полумертвым легаси в каждом дистрибутиве без реального разграничения функционала версий и попытками в новую инфраструктуру на костях старой... Это живёт только на правах монополиста с пренебрежением ущерба репутации. Линукс же изначально был... ну вы и сами знаете
Заслуженно поставил диз. Много усилий тратится на поддержку SoC мейнлайном - и теперь все выбросить в отдельную ветку? Ну уж нет.
Приведите пример откровенного легаси в винде, не вынесенное в отдельный компонент
Да хоть десять дизов. Андроид, он на базе чего? На скольких миллионах устройств работает и что происходит с устройством, когда производитель «прекращает поддержку»?
Сколько производители и энтузиасты перепиливают вдоль и поперёк, пересобирая, адаптируя? Им кто-то что-то запрещает что-ли? В отличие от...
А что касается винды, то:
В системых библиотеках тонны кода для работы с устаревшими компонентами. Даже просто залезть в WinAPI, чтобы почитать, там... Что-то там про старые порты ввода... Эмулировать тоже не будем, пусть люди сами пишут драйвера. Совместимость, спустя три десятилетия, в самой передовой версии? Когда новейшие обновления ломают новейшую же систему? Нет, это всё надо тащить! А вдруг кому-то пригодится. Только истории по типу TPM 2.0 мы будем исполнять, потому железо выкидывайте, а вот софт ни-ни. Что-то там про разные версии систем для разных поколений железа? Серверная? О чём это вы(сарказм)?. Аэропорты, вокзалы, до сих пор работают в некоторых странах на 3.1 или 95? А спросите их, почему не обновляются, там же обратная совместимость? Сбой вот недавно дал кое-какие ответы...
Призванная когда-то совершить революцию, .NET-платформа, повисла сверху, тихо став частью. Вы хоть примерно представляете, сколько в процессе прогресса версий файлов сборок выблевалось на жесткий диск? Сколько пользователей заставляли устанавливать и работать вторую с третьей и четвертной и... и это с их промежуточными версиями, сборки которых никуда не девались после обновления программ! Одна только .NET-платформа сама себя превратила в свалку легаси!
Сколько вы готовы выделить на диске, для дубликатов файлов для безопасности, которые будет хранить винда? Да, это не легаси, но это входит в тему жирноты! Не переживайте, когда придёт время, большинству пользователей они не помогут, эти фалы. Итак, в своё время 80Гб системная папка свежей установленной системы на 120Гб винте, эт ж норма, чё... Да, не у всех, но чем рядовой обыватель виноват, купив лицензию? Почему вообще эта проблема существовала
Предыдущий пункт, но syswow64, 32х битки vs 64x и это тоже надо дублировать и куда-то девать.
Даже на абсолютно чистой системе люди жалуются, открыв журнал ошибок... почему вообще такая проблема должна существовать и почему они не решают это уже много версий подряд.
Две панели управления в 11й, два меню по правому клику... а вот для защитников легаси, некоторые ставшие привычными вещи, надо убирать, потом добавлять, потом снова убирать... Это же так должно работать? Это может бесить, может не нравится, но жаловаться MS бесполезно, решать самому - вмешиваться в работу системы, весомых альтернатив, для варианта «не нравится - чемодан, вокзал», просто нет.
Есть ещё пункты, но мы раздуем полемику, а мне реально лень
Сколько стоит загрузить GDI библиотеку (не GDI+)? Сколько программ её реально сейчас используют? Что слышно с mswinsck.ocx, dx8vb.dll, технология OLE и все-все-все? Каждый день поключаются устройства USB 1.0. Там Xamarin устарел кстати. Что там с поддержкой APK? Куда девается это всё на домашнем ПК? Винда на ARM переехала кстати.
Прогресс не стоит на месте, это понятно и очевидно. MS пытается откусывать то тут, то там. Но экономит даже на тестерах! И всё болото оседает мёртвым илом.
Ну не надо мне заливать, что та версия винды, которая ставится на мой ПК, максимально прилизанная от прошлой и адаптируется под железо и ставящийся софт на лету
Лол, я просил привести core-элемент винды, вы накатали простыню текста о её компонентах. Но ок, давайте по порядку:
Да хоть десять дизов. Андроид, он на базе чего? На скольких миллионах устройств работает и что происходит с устройством, когда производитель «прекращает поддержку»?
Сколько производители и энтузиасты перепиливают вдоль и поперёк, пересобирая, адаптируя? Им кто-то что-то запрещает что-ли? В отличие от...
Причём тут вообще Android? Что там творится в юзерспейсе ведра - дело гугла и они хорошо, к слову, держат совместимость между версиями - софт для 1.0 вполне запустится на 12.
Кастомы это замечательно, согласен. Но они здесь вообще не причем, поскольку обычно не трогают ни вендорские драйвера, ни как-то глобально ядро в целом (в основном, меняются планировщики, конфигурация кэшей и т.п.) и я в целом говорил о том, что вложено много усилий принести многие SoC в мейнлайн (например, совсем недавно добавили более чем актуальный AllWinner F1C100S/F1C200S и V3S, которые под капотом ARMv5 - а вот их уже хотят выбросить, хотя чипсет вышел несколько лет назад и используется в куче одноплатников и разных устройств).
Даже просто залезть в WinAPI, чтобы почитать, там... Что-то там про старые порты ввода...
А, ну тоесть если вы не разбираетесь, значит они не нужны?) Ничего что код для работы, например, с COM-портами успешно абстрагирует не только COM-контроллер в IBM-PC, но и UART-контроллеры в ARM-машинах, а также USB CDC устройства как минимум? Ок, LPT древний? Давно уже нет таких принтеров и сканеров? Давайте вспомним, что LPT - это почти полноценная гребенка GPIO и параллельная шина, чем пользовались в embedded оборудовании и пользуются скорее всего и сейчас, хотя в винде и есть нормальный интерфейс для GPIO!
Идём дальше: такие древние и ненужные шины PCI, AGP... а потом внезапно узнаем, что в софтовой части PCI, AGP и PCI-E очень похожи и реализация поддержки PCI-E тянет автоматически поддержку PCI и AGP. Ой как неудобно! Ну а ISA думаю уже давно убрали, там действительно интерфейс иной был с дерганьем отдельных аппаратных прерываний.
Эмулировать тоже не будем, пусть люди сами пишут драйвера
Эмулировать что? Над портами есть абстракции - в юзерспейсе любой последовательный интерфейс, хоть CDC, хоть UART выглядит как COM-порт и управляется как COM-порт. Это - правильно решение, в Linux точно также, как и в Darwin. Давайте вы сначала напишите хоть один драйвер используя DDK (он не идеален, но не настолько говно как кажется), потом уже будете говорить что там плохо, а что нет?)
Совместимость, спустя три десятилетия, в самой передовой версии
Не вижу проблемы. В винде она реализована правильно - например я писал недавно демку на D3D6 (GAPI вышедшее в 1998), винда попросила установить компонент D3D6 отдельно с какого-то своего репозитория и все - это не часть самой системы.
Когда новейшие обновления ломают новейшую же систему
Это единичные случаи. За всеми машинами не уследишь. И сейчас не времена XP с ASR, винда вполне может в автоматическом режиме отключить загрузку "кривых" драйверов. Раньше краш видеоподсистемы вешал ОС, сейчас крашит WDM и все D3D приложения (OpenGL сами восстанавливали стейт) и все работает норм.
Вы хоть примерно представляете, сколько в процессе прогресса версий файлов сборок выблевалось на жесткий диск? Сколько пользователей заставляли устанавливать и работать вторую с третьей и четвертной и... и это с их промежуточными версиями, сборки которых никуда не девались после обновления программ! Одна только .NET-платформа сама себя превратила в свалку легаси!
У дотнета есть пару причин для такого деления на разные модули:
Во первых, поведение некоторых методов менялось от версии к версии. Это лучше чем if(target == "2.0") else. Во вторых, в дотнете значительно менялся механизм проверки подписей у сборок и вообще концепции безопасной среды - это ближе к дотнету на серверсайде, я об этом мало могу рассказать, но когда пилил интероп на WP8 и ПК - столкнулся с этим.
Ну и дотнет это сторонний компонент как минимум.
Сколько вы готовы выделить на диске, для дубликатов файлов для безопасности
Я вам про одно, вы мне про другое)
Предыдущий пункт, но syswow64, 32х битки vs 64x и это тоже надо дублировать и куда-то девать.
А вот чтобы понимать зачем нужны дубли dll'ок в 64х-битном окружении - нужно иметь хоть какой-то опыт нативного программирования под x64. Просто так подгрузить x86 либу не выйдет - будет бардак и с доступом к регистрам, и организации памяти и банально с базовыми типами. Тоже самое и в Linux, где требуется ставить отдельный libc и точно такой-же слой совместимости для поддержки x86 платформ :)
В случае с ARM насколько мне известно есть возможность поставить даже ARMv5 софт с SoftVFP ABI - но тоже нужно ставить небольшой слой совместимости.
а мне реально лень
И по сути, кроме .NET - всё личные догадки человека, который наверняка не написал ни одного драйвера и не полностью понимает как работает юзерспейс слой винды под капотом. Я просил перечислить Core-функционал винды, а не её отделяемые компоненты - вы же привели в основном именно отдельные компоненты.
Сколько стоит загрузить GDI библиотеку (не GDI+)? Сколько программ её реально сейчас используют
Внезапно, сам GDI+ рисует на GDI-контекстах, но для понимания этого нужно иметь опыт работы с этими подсистемами :) Использует очень много, весь виджет тулкит винды на ней подвязан, в том числе и оконная подсистема (правда сам GDI уже давно подвязан на DXGI и D3D). Какие программы реально сейчас используют? Ну, внезапно не весь софт повально на Electron'е и Qt пилится, всё ещё в ходу VCL, WinForms, wxWidgets.
Что слышно с mswinsck.ocx, dx8vb.dll
VB6 давно неактуален, да. А ActiveX местами иногда используется. Мозилла даже утащила концепцию COM в свои проекты.
Короче пока что я от вас вижу лишь предположения и догадки как пользователя, который считает что если ему не нужен GDI или абстракция от COM-портов - значит не нужен никому (в т.ч и софту, которым он пользуется каждый день) и никаких машин (в т.ч промышленных) кроме его ПК для игр и программирования на жабоскриптике - не существует. Как будет что-то по делу - пишите, опровергну, или если напишите по факту - соглашусь.
Вставлю свои 5 копеек: некорректно просить привести примеры core-элементов гибридной системы в сравнении с монолитным ядром linux. Я считаю, что аргументы, связанные с .NET, следует засчитать. Так или иначе, без этого НЕ core-элемента винда из себя мало что представляет, а вина за разведённый зоопарк актуальных версий лежит именно на MS. То, что dotnet сторонний компонент, также некорректно. Это компонент, который в большинстве простых пользовательских сценариев обязателен к установке, и, опять же, его разработчиком является сама MS
Тогда обсуждая линукс надо в эту копилку добавлять Qt, gnome и т.п.? Ведь на них построено огромное количество софта и они обязательны к установке в большинстве сценариев. Еще питон, наверное.
Обсуждая Линукс, очень часто затрагивают тему его GUI, в том числе оболочки gnome. Но я имел ввиду другое: Майкрософт сама выпустила свой фреймворк и сама сделала его важнейшим компонентом. В то время, как qt и python - языки, на которых хоть и написаны некоторые компоненты Линукс, они не созданы Линусом Торвальдсом и не сделаны главными компонентами линукса
Голое ядро никому не нужно. Как и голая ОС. Нужны программы. Это работает и в винде, и в лине, и в ведроиде.
И в данном контексте винда выглядит целостнее, давая от производителя компилятор, язык программирования, ядро, интерфейс, гайдлайны, среду программирования, окружение и многое другое, чем слепленный из чего попало линукс, где на каждый чих начинается пинг-понг и разграничения прав и каждый пилит свое поделие.
И когда вы начинаете смотреть на систему с позиции человека которому нужно выполнять задачу, а не философствовать о том является-ли питон основной частью системы - вы поймете что если 50% софта требуют питона - он является частью системы де-факто. Как и гном/кде для пользователей. Все остальное это лирика.
Так Линукс в принципе не создан Торвальдсом. Ни один дистрибутив. Он сделал ядро и его и мейнтейнит.
А из всех дистрибутивов линукса, никто не сделал какое-то единое графическое ядро, которое используют все-все-все.
А мне кажется, что претензии к дотнет надуманы. Сейчас вообще можно с собой взять "свой" дотнет, упакованный рядом со своей программой, и это как раз неплохой путь.
Так точно знаешь, что всё будет работать. Диски очень дёшевы, а надёжность, стабильность и то, что программу можно просто скопировать, и она заработает, выгоднее, чем экономия несчастных 100-200 МБ.
Одна проблема - обновления безопасности.
Ну а ISA думаю уже давно убрали
не убрали, но обновили. сейчас она называется LPC и к ней, например, подключен мультяк. логически то же самое, конвертится друг в друга без проблем. и ио-порты все еще используются. да и прерывания все еще можно дернуть, даже из pcie.
Ну вы же сами и расписали, что все это легаси. Это неважно, как именно над системами бородатых годов наваяли абстракции. Важно, что все это тянется, дублируется, латается - но ничего не приведено в порядок в достаточной степени или переписано с нуля. И производители железа так же вынуждены использовать старые шины десятилетиями. Так или иначе, это либо пересажено на другие рельсы, чтобы работало аппаратное ускорение, но при этом сохранен и старый вариант, либо продублировано 32+64, а еще, хоть это уже вопрос жирноты, бэкапится в системную папку. И это, как выше сказали, не опенсорс система, а ещё они фактически монополисты. А ещё таскать с собой кучу библиотек и дублировать их версионированием - такая себе идея. Диски может и дешёвые, но не должен, условный, Вайбер, занимать больше, чем профессиональный пакет моделирования не самой современной редакции. Это тоже куча хлама, который совершенно не нужен. Хорошо, а интерфейс зачем новый поверх старого? Чтобы пользователями было легче привыкать? Во-первых всё-равно часто надо переключать на старый вариант, а это время, это бесит, во-вторых майкам на наше привыкать всегда было по-барабану.
Ещё раз моя основная мысль: сама по себе добрая часть винды, это легаси и костыли, которые тянутся десятилетиями, обрастая новыми решениями, которые так же раздувают размер. Нам каждый раз обещают что-то совершенно новое, а продают все так же старое
Причем тут ос и сторонний софт!? Какие старые шины!? Вы понимаете, что тот же COM и UART софтварно один и тот же протокол и ничуть не менялся за 50 лет потому что это не нужно, он уже идеален для своих задач? Тоже самое о софтовом ISA: это просто маппинг внешних устройств к инструкциям in/out и механизм обработки прерываний.
Учите матчасть, потом приходите спорить.
моя основная мысль: сама по себе добрая часть винды, это легаси и костыли, которые тянутся десятилетиями
Перефразируя Страуструпа, "есть ОС, которые ругают и ОС, которыми не пользуются". Для меня 200-300 GB на диске - разумная плата за то, что я могу запустить 3-х героев, или Half-Life с Max Payne, или программу на .NET4.5, написанную в середине нулевых.
Вам наверняка подойдёт Gentoo Linux, где вы можете вручную настроить каждый компонентик и вырезать каждый неиспользуемый байт ценой нескольких часов своего времени в неделю. Только мир пересобрался, а тут уже новые апдейты и надо снова всё обновлять и перекомпиливать.
Все это зачастую "надо тащить" если ты хочешь продаваться и работать в гос. структурах, где ты обязан соответствовать распоряжению, написанному в 8*х годах и до сих пор актуальному. Это еще с win95 повелось все эти богом забытые порты и ущербные архитектурные решения, которые микрософт с упорством вставлял в каждый новый релиз.
все эти богом забытые порты
Какие именно? COM, LPT? Я, конечно, и близко не предполагаю нижеследующее экстраполировать на всех, но я этими портами пользуюсь приблизительно ежедневно, безотносительно того, существуют они в виде аппаратных разъемов на материнской плате, в виде аппаратной эмуляции (обычно USB-COM) или в виде чисто софтовой эмуляции (виртуальные кабели), поэтому меня ваш комментарий удивил, но возможно я просто неправильно вас понял.
Вы мне прям реально предлагаете вспомнить куда я дел двутомник описания структуры Windows 95 их издательства 9* года и процетировать их аргументацию на основании чего они сохраняют в ОС совместимость с массой непонятных с первого раза стандартов (работа ОС на компьютерах в гос. структурах штатов, куда эта ОС продавалась, где вполне себе формализованные требования и к ядру ОС и много еще к чему, с чем должно работать их государственное ПО и каким формальным требованиям оно должно соответствовать, а старый код эту сертификацию скорее всего прошел и она возможно не такая и бесплатная). Я понимаю что человеку который задал вопросы эти книги уже недоступны да и желания у него разбираться в вопросе скорее всего нет, но и минусовать это уже господа за гранью логического понимания.
Совместимость, спустя три десятилетия, в самой передовой версии? Когда новейшие обновления ломают новейшую же систему? Нет, это всё надо тащить! А вдруг кому-то пригодится.
А вы думаете, мы ставим Windows, чтобы полюбоваться на его баги? Если бы мы не пользовались старыми WinAPI-программами, а только современными бесхендловыми, мы бы их и запускали из-под Линукса.
Вряд ли только всё это имеет отношение к поддержке ARM'ов в ядре Линукса.
Сколько стоит загрузить GDI библиотеку (не GDI+)? Сколько программ её реально сейчас используют? Что слышно с mswinsck.ocx, dx8vb.dll, технология OLE и все-все-все?
Это шутка?
Приведите пример откровенного легаси в винде, не вынесенное в отдельный компонент
Некорректный пример. Винда не опен-сорс система, вы не можете взять и выкинуть ненужные модули из проприетарной винды или добавить их самостоятельно, не нарушая лицензию.
А легаси в винде огромное количество.
Давно пора. История в гите есть, релизы в архивах есть. Кому надо поддержку железа времен палеолита - тот знает, где брать нужный код.
ARMv7-M — еще используется в микроконтроллерах на базе Cortex-M3/M4/M7.
Оно есть в мейнлайне? Не знал. Был вроде форк ucLinux для поддержки жирных микроконтроллеров, но о нем уже давно ничего не слышно...
Поработал с исходниками десятка Андроид-сборок для телефонов от разных поставщиков. Секретные сведения - то что у вас в кармане даже на Андроид 14, вполне может быть на ядре Linux 4.14 или 4.19, то есть на ядрах семилетней давности.
Мораль - промышленность слабо волнует что там затеяли разработчики Linux.
Ядро Linux стремительно переписывают. API меняется. Поддерживать GPU, NPU, модем и прочее очень больно. Мало кому будет дешево держать ядро в актуальном состоянии.
На самом деле практика показала, что:
1. Избавляться от старья нужно и полезно
Делается это, увы, только волевым решением.
Мы же прекрасно помним, каким был переход с 32 бит на 64? Как там всё решилось? ДА вот когда все разом рубанули, тогда и перешли. А ведь нытья столько было..
Это же касается кучи инструкций в проце и кучи древних технологий. Как решили? ДА тоже взяли и рубанули.
Вот и тут вполне себе пора. Нет, ну в смысле я всё могу понять, но i486? Реально? Ему точно нужно последнее ядро?
Это же касается кучи инструкций в проце и кучи древних технологий. Как решили? ДА тоже взяли и рубанули.
Да кто рубанул то?) Нормальный софт всегда проверяет наличие тех или иных SIMD и имеет откат на решение без векторизации.
Сложно отделить, что есть векторизация, а что - жизненная необходимость.
Сейчас все современные компиляторы генерят обычный, не векторный код работы с double/float под SSE 4.2, потому что там обычная арифметика на XMM-регистрах работает намного быстрее, чем FPU x87.
Тот же Photoshop - нормальный софт? У него нет fallback на процессоры ниже Intel Core 2.
Что говорить под линукс, где всё собирается с максимальными оптимизациями, а исходники коммерческого софта часто недоступны, сами вы собрать не сможете.
Может и не нужно, но клоны 486-го и 386-го вполне себе выпускаются до сих пор.
Когда рубанули(выпустили итаниумы) - как раз нкто не перешел, а покрутили у виска.
А вот когда AMD выкатили своё решение, которое как раз ничего не рубило, а давало возможность работать и как 64 и как 32 - тогда все потихоньку переползли.
Комментатор выше про опыт Apple, но у яблочников своя атмосфера. С открытыми системами такое не проканает
У яблочников при каждом переходе было все норм.
Переходы:
PPC->x86. Был транслятор Roseta. Работал очень достойно, я даже играл в игра на x86, которые были под ppc.
x86-32 -> x86-64. Сколько-то лет поддерживался запуск х32 приложений, хотя уже не было новых устройств не с х86-64 процессорами. Переход был очень мягкий и почти незаметный. Я столкнулся только с тем, что World of Warcraft ванильный 32 битный и его никак не запустить. Но клиенту на тот момент было больше 10 лет, новые версии были уже 64 битные.
x86 -> arm. Здесь опять сделали транслятор roseta 2. Работает он отлично, для меня переход был бесшовный. Единственный затык у меня был с докер образами, которые были собраны по х86. Тут просадка была существенна. Ну, и линукс х86, чтобы запустить нужно поднимать qemu. Скорости там ужасные.
Вполне нормально чистить код от неиспользуемого легаси, т.к. его поддержка тоже тратит время.
А для тех кому надо, старые версии ядра ни куда не делись.
Хорошее начинание - удалить хлам. Но как-то уж больно консервативно и с осторожностью к этому подходят, можно было бы жёстче это делать - удалять поддержку не только совсем уж древних процессоров, но и просто старых. А кому эта поддержка нужна - может всегда воспользоваться более старой версией ядра.
Из перечисленного слегка переживаю только за малинку первой версии. Но думаю те энтузиасты, которые до сих пор используют ее в своих проектах - давно уже выкачали нужные сборки linux, и в обновлениях не особо нуждаются.
К тому же, ядро linux - открыто. И если кому надо будет добавить поддержку старых процессоров с новыми API - покопается, разберется
Это целиком вопрос экономики. Конечно, хотелось бы иметь не только поддержку в новом ядре своей старой "ламповой" архитектуры ЦПУ, но и вообще поддержку старого ядра до бесконечности. Для успешной эволюции от рудиментов надо когда-то избавляться.
Из Linux уберут поддержку десятков ARM-чипов. Что происходит?
Что происходит?
Вы родили желтушный заголовок, вот что происходит. Это примерно как на оживлённой улице харкнуть на тротуар.
Сегодня обсудим «большую чистку» ядра Linux.
Ну и где это «обсудим»?
Вы просто перепечатали информацию из других источников, попутно привнеся свои собственные ошибки, но не привнеся новых мыслей.
То же самое они делают и в отношении устаревших x86-процессоров. В самом конце прошлого года из Linux 6.7 удалили код, отвечавший за поддержку микросхем Intel Itanium на базе архитектуры IA-64.
Itanium никогда не был x86-процессором, это совершенно иные архитектура и набор команд. Эмуляция x86 на нём была не особо быстрой и это вышло ему боком.
А что вы думаете о «большой чистке Бергмана» и ее возможных последствиях?
Думаю, что подобный стиль изложения неуместен на Хабрахабре. Пишите нормально, вы же «редактор», вам за это зряплату платят.
В случае ARMv4 Бергман считает, что на первом этапе поддержку нужно вырезать из компиляторов и только потом, через несколько лет, — из ядра Linux. Еще от одной архитектуры, ARMv7-M, планируют избавиться в 2027 году. Ее развитие прекращено в 2017-ом
Если они начнут удаление ARMv7-M с компиляторов это будет катастрофа
Это ядра одних из самых популярных контроллеров. А уж по соотношению цена/производительность они, скорее всего, вообще топовые
Не вижу в этом проблемы. Ядро развивается с прицелом на 64-битные фичи. Старые 32-битные SoC-и можно запускать на старом ядре (фиксы безопасности туда будут портировать), зачем прям самое новое, для 32-битных ядер код, который написан не под них, будет лишь тормозить. Всё равно, что пытаться натянуть Windows 11 на Pentium-4, вместо того, чтобы оставить для них WinXP.
Вероятно пора делать свой форк ядра
ARMv6K — ещё ладно, но уже на грани. ARMv7-M — это уже не гуманно, всё ещё полно чипов на этих ядрах. Лет через 20 может быть. Не думаю что они там прям какое-то чудовищное место занимают.
...подсчитывами, насколько его можно облегчить... выяснилось что на 154 тыс. строк программного кода...
Это просто смехотворно, на самом деле. Если там из-за самых древних можно какие-то костыли убрать, вот это хорошо. Но 154 тыс. строк кода это так, навскидку, мегабайт 50 всего исходников.
Из Linux уберут поддержку десятков ARM-чипов. Что происходит?