[ON] Разработчики ядра Linux на пути к удалению поддержки процессоров i486

[rssbot]

Инго Молнар (Ingo Molnar), мэйнтейнер архитектуры x86, механизма блокировок и планировщика задач в ядре Linux, выставил на обсуждение набор патчей, удаляющих из ядра поддержку процессоров 486 (M486, M486SX, AMD ELAN) и начальных серий процессоров 586. В ядре предлагается оставить только возможность работы с процессорами x86, поддерживающими инструкцию CX8 (CMPXCHG8B) и регистр TSC (Time Stamp Counter), которые появились в CPU Pentium.


Отмечается, что для поддержки CPU 486 в ядре приходится держать код, эмулирующий операции CX8 (сравнить и обменять 8 байт) и TSC (счётчик циклов CPU, используемый в планировщике задач). Подобный код усложняет ядро, затрудняет сопровождение и временами становится источником проблем, разбор которых отнимает время у разработчиков. Прекращение поддержки 486 позволит удалить из ядра 14104 строки кода, что значительно упростит некоторые функции в ядре за счёт исключения прослоек, эмулирующих CX8 и TSC, и позволит избавиться от библиотеки math-emu, эмулирующей FPU.



За день до публикации патчей вопрос целесообразности удаления поддержки 486 поднял Линус Торвальдс при обсуждении очередной проблемы, проявляющейся при эмуляции CX8. Линус считает, что настало время отказаться от поддержки CPU 486 и не видит причин, чтобы продолжать тратить время разработчиков на решение возникающих из-за них проблем. Поддержка процессоров 386 была удалена из ядра в 2012 году. По мнению участников дискуссии, сейчас настало время для удаления поддержки CPU 486. В октябре 2022 года Линус уже публиковал подобное предложение, но оно не получило развития.



В остающихся в обиходе системах 486 актуальные ядра Linux практически не используются. Специализированные варианты процессоров 486 для встраиваемых систем, такие как Intel Quark, поддерживают CX8 и TSC, их изменение не коснётся. Старые оригинальные CPU 486, как правило, продолжают использоваться с устаревшими дистрибутивами, поставляющими старые версии ядра Linux. Современные дистрибутивы Linux давно прекратили поддержку 32-разрядных систем x86 или перешли на использование при сборке опции X86_PAE, требующей наличия поддержки CX8.



Источник: https://www.opennet.ru/opennews/art.shtml?num=63184
(opennet.ru, основная лента)

[yoricI]

Да чего там, до Пня2 (или даже 3-го) можно вычищать, всё равно работать невозможно.

[Aliech]

Да чего там, до Пня2 (или даже 3-го) можно вычищать, всё равно работать невозможно.

Невозможно кому? Невозможно работать с чем?

Так-то ядро linux не только на рабочих местах применяется и высокопроизводительных серверах. Но и на всяких там IoT-устройствах и прочей маломощной встройке. А там таки имеет распространение крайне порезанные x86-ядра. Фактически 486е на стероидах. Например семейство процессоров Intel Quark, упомянутое в новости. Ну и да, Vortex86***, как самый популярный x86 SoC в промышленных решениях. Где большая часть линейки - 486е, фактически. Вот их тоже выкинуть надо лишь потому, что десктоп на них не ахти?

[yoricI]

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

[SwapON]

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

[ormorph]

Невозможно кому? Невозможно работать с чем?

На новых дистрибутивах невозможно работать с устаревшими процессорами, так как потребляют много ресурсов, как ядро так и прочее. Сами старые компы с их памятью не потянут. Есть старые дистрибутивы со старыми ядрами, на них и поддерживать данное оборудование. Поддержка то удаляется только из новых ядер, на старых дистрибутивах то всё работать будет. Потому то и нет смысла поддерживать это в новом ядре. Новые приложения и без десктопа могут потреблять не мало памяти и будут. Ну и с ПО не должно быть проблем, если только не использовать какие то особые технологии, которые могут появиться в будущем, пока то ядрами поддерживается и systemd и т.п., а что будет дальше кто его знает.

Ну и да, Vortex86***, как самый популярный x86 SoC в промышленных решениях. Где большая часть линейки - 486е, фактически. Вот их тоже выкинуть надо лишь потому, что десктоп на них не ахти?

А как удаление поддержки из ядра повлияет на ПО, которое будет использоваться данным процессором? Хотя есть ПО, которое изначально разрабатывалось только под 64 бит. Тут вопрос не в том, почему удаляют это из ядра, а то, как будет поддерживаться ПО под старые ядра далее. Самих то технологий не так то и много под старые процессоры по сравнению с новыми, что бы потребовалось использовать новое ядро.

[Aliech]

Я думаю yoricI имел ввиду архитектуру под морально устаревшее железо, которое в лучшем случае должно находиться уже в музее.

Да, только прямые потомки классического 486го - не только лишь устаревшее железо, но и актуальные SoC, имеющие широкое распространение в составе промышленных средств автоматизации. Такие дела... Они, кстати, немного совершенней, чем классический 486, так что их не коснётся изменение из оригинальной новости. Но вот предложение удалить всё до условного 686 (как предложил yoricI, но он, надо отдать должное ему, всё понял) уже их коснётся. Но зачем так делать, если удалять надо не что-то, что кажется кому-то морально устаревшим, а лишь то, что увеличивает накладные расходы на сопровождение, само оставаясь не востребованным настолько, чтобы это окупилось? Вот как содержание доп. кода для эмуляции пары инструкций на классическом 486ом.

Ну а если существует необходимость поддержки маломощного железа, к примеру маршрутизаторов, то для этого есть MIPS, ARM и т.д.

А маломощное железо, на ваш взгляд, ограничивается только коммуникационными процессорами с ядрами mips/arm и парой-тройкой встроенных интерфейсов сетевых (ну и ущербным хабом на одном из них)? Нет. В промышленной автоматике применяются потомки 486го, они укомплектованы широким набором i/o и имеют допуск работать много где. Вот как семейство Vortex86, которое я выше упомянул. От того, что вы о них не знаете, их востребованность не сильно падает. И это актуальные решения, не то, чему место в музее, или на помойке. Так зачем выкидывать их поддержку, пока она не накладывает доп. расходы на разработку ядра?

А как удаление поддержки из ядра повлияет на ПО, которое будет использоваться данным процессором?

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

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

Да, но ядро linux применяется даже на контролерах с ARMv5! И это речь совсем не про дистрибутивы. Вот так же и с 486ми, о которых я пишу. Не забывайте, что ядро у нас с одной кодовой базы "разливается".

[ormorph]

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

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

Но вот предложение удалить всё до условного 686 (как предложил yoricI, но он, надо отдать должное ему, всё понял) уже их коснётся.

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

Да, но ядро linux применяется даже на контролерах с ARMv5! И это речь совсем не про дистрибутивы. Вот так же и с 486ми, о которых я пишу. Не забывайте, что ядро у нас с одной кодовой базы "разливается".

Это уже другое, там используется уже своя прошивка от производителя, как правило какая-нибудь система на busybox. Но про удаление поддержки этих контроллеров речи не шло. Ну и то что работало так же работать будет на своих прошивках и ядрах. Сами сказали это не про дистрибутивы, а значит там и нет привязки к последнему ядру. Как правило одни избавляются от сопровождения, а другие берутся. Тут ни чего нового. Некоторые до сих пор работают на ядре 3.x.

[Aliech]

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

Вот и резать надо лишь тогда, когда действительно появляются дополнительные расходы на поддержку. И только если они не покрываются пользой от старого кода. О чём я писал выше.

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

Вы всё за юзерленд переживаете! Ещё разок, я писал о другом - о том, что существует актуальное 32х битное железо. Вот новое. Не старьё из чулана.

Это уже другое, там используется уже своя прошивка от производителя, как правило какая-нибудь система на busybox. Но про удаление поддержки этих контроллеров речи не шло. Ну и то что работало так же работать будет на своих прошивках и ядрах. Сами сказали это не про дистрибутивы, а значит там и нет привязки к последнему ядру. Как правило одни избавляются от сопровождения, а другие берутся. Тут ни чего нового. Некоторые до сих пор работают на ядре 3.x.

Что такое это ваше "другое"? Там кроме busybox ядро есть? Ну так вот, - есть. Почему я, как разработчик, когда захочу делать СВЕЖУЮ прошивку, для НОВОГО устройства, на базе АКТУАЛЬНОГО железа не могу взять АКТУАЛЬНОЕ ядро, в котором исправлены все программные ошибки, найденные со времён предыдущих ядер? Чтобы потом лет на десять о нём забыть, чтобы специалистам подрядчика не объяснять (возможно тупым представителям), что им не стоит беспокоится об той горе CVE'шек, которая была найдена со времён 3.x линейки?

Некоторые до сих пор работают на ядре 3.x.

Примеры? Ну вот чтобы, как я выше указал, НОВОЕ устройство, на базе АКТУАЛЬНОГО железа, без ограничений на существующий софт, но по-прежнему с 3.x ядром? Удивите меня, прошу вас!

[ormorph]

Примеры?

Вроде как ОС эльбрус не так давно видел была всё ещё на 3.x. Сейчас может и перешли на более новое, но что то сомневаюсь. Само собою там было ограничение на существующий софт, но кому нынче легко.

Почему я, как разработчик, когда захочу делать СВЕЖУЮ прошивку, для НОВОГО устройства, на базе АКТУАЛЬНОГО железа не могу взять АКТУАЛЬНОЕ ядро, в котором исправлены все программные ошибки, найденные со времён предыдущих ядер? Чтобы потом лет на десять о нём забыть, чтобы специалистам подрядчика не объяснять (возможно тупым представителям), что им не стоит беспокоится об той горе CVE'шек, которая была найдена со времён 3.x линейки?

Этот вопрос не ко мне. Но это уже не раз происходило и ни чего нового тут нет. Хотите что то актуальное занимайтесь поддержкой, либо спонсируйте, почему это должен делать кто то за вас.

[Aliech]

Вроде как ОС эльбрус не так давно видел была всё ещё на 3.x. Сейчас может и перешли на более новое, но что то сомневаюсь. Само собою там было ограничение на существующий софт, но кому нынче легко.

Это точно АКТУАЛЬНОЕ для АКТУАЛЬНОГО железа? Но вы привели заведомое, что называется, ЛЕГАСИ. Не надо так. А устаревшее оно по ряду причин: во-первых оно должно быть сертифицировано, а бабла жалко на сертификацию, так что там будет обновляться только то, дыры чего известны сертификатору, и без закрытия которых он отказывается продлевать сертификат.

А ещё патчи для поддержки e2k легко могут сдерживать переход на свежее ядро. Потому что писали их ногой. И переписывать их некому.

Но, барабанная дробь, свежее ядро для e2k бывает (ну уж точно моложе 3.x)! А если вы видели ОС Эльбрус для их sparc-процессоров, то это пример устаревшего ПО строго для устаревшего железа, который вы можете встретить лишь в составе устаревших комплексов, доживающих свой век.

А я писал о другом: об том что существуют свежие 32х-разрядные контроллеры на архитектуре x86. И они дальше набора инструкций 486+ обычно не продвигаются. До 686 добираются лишь те, кому SMP нужно. А так 486 + доп инструкции = отличный результат.

Хотите что то актуальное занимайтесь поддержкой, либо спонсируйте, почему это должен делать кто то за вас.

А что спонсировать? Это жеж обычный x86ой! Там нет вообще ничего специфичного. Vortex86 (начиная с DX, т.е. 2010 год) и Intel Quark вообще никак не страдают от ожидаемого изменения. Но вот от предложения "порезать вплоть до P3" - они пострадали бы. От предложения, профит от которого не понятен. О чём я писал изначально. Но вы вступили в дискуссию, теперь же я жду, когда вы объясните мне, так в чём же профит от обрезания по самый P3?

Добавлено:
Возможно по-прежнему кому-то не понятно, что речь в статье идёт о коде, который скрыт за CONFIG_M486SX, CONFIG_M486 и CONFIG_M586. Почему удаляют: потому что приходится эмулировать программно функции, таскать дополнительный код для этого, который ещё и мешает писать свежий код. Но "обрезать по P3" - это удалить поддержку огромного числа CPU, поддержка которых не сопряжена с необходимостью поддержки кода математических функций. То есть стоит приблизительно ничего. Внимание вопрос: а нафига тогда?

[ormorph]

А что спонсировать? Это жеж обычный x86ой! Там нет вообще ничего специфичного. Vortex86 (начиная с DX, т.е. 2010 год) и Intel Quark вообще никак не страдают от ожидаемого изменения. Но вот от предложения "порезать вплоть до P3" - они пострадали бы. От предложения, профит от которого не понятен. О чём я писал изначально. Но вы вступили в дискуссию, теперь же я жду, когда вы объясните мне, так в чём же профит от обрезания по самый P3?

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

А ещё патчи для поддержки e2k легко могут сдерживать переход на свежее ядро. Потому что писали их ногой. И переписывать их некому.

Там более простая причина, они используют свой компилятор, не gcc для сборки. А потому кто будет поддерживать весь зоопарк ПО, для сборки которого уже нужны довольно современные компиляторы, каким нибудь gcc-2.95 уже не соберёшь. Всё очень далеко ушло.

[Aliech]

Там более простая причина, они используют свой компилятор, не gcc для сборки. А потому кто будет поддерживать весь зоопарк ПО, для сборки которого уже нужны довольно современные компиляторы, каким нибудь gcc-2.95 уже не соберёшь. Всё очень далеко ушло.

Нет. Свежее ПО там не появляется главным образом из-за сертификации. Нормально icc всё собирает, когда надо. А патчи к gcc свежему тоже существуют. Кстати, у Эльбрус ОС есть и более свежие "разливы".

Эти процессоры как раз не поддерживают CX8.

Обращаю ваше внимание, что изначально вы вступили в дискуссию со мной, где я не был против удаления процессоров БЕЗ CX8, но был против предложения yoricI об возможности удаления процессоров, даже поддерживающих CX8, просто потому что они более старые, чем Pentium 3. Вы уж определитесь, вы таки за удаление "по самый Pentium 3", или только за удаление эмуляции CX8 (а значит всех 486, не поддерживающих CX8, и всех багнутых Pentium I, у которых CX8 работает некорректно). Если таки только последнее - то вы значит плохо прочли мой текст, с которым решили поспорить. И вся простыня выше была зря...

[ormorph]

Обращаю ваше внимание, что изначально вы вступили в дискуссию со мной, где я не был против удаления процессоров БЕЗ CX8, но был против предложения yoricI об возможности удаления процессоров, даже поддерживающих CX8, просто потому что они более старые, чем Pentium 3. Вы уж определитесь, вы таки за удаление "по самый Pentium 3", или только за удаление эмуляции CX8 (а значит всех 486, не поддерживающих CX8, и всех багнутых Pentium I, у которых CX8 работает некорректно). Если таки только последнее - то вы значит плохо прочли мой текст, с которым решили поспорить. И вся простыня выше была зря...

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

Нет. Свежее ПО там не появляется главным образом из-за сертификации. Нормально icc всё собирает, когда надо. А патчи к gcc свежему тоже существуют. Кстати, у Эльбрус ОС есть и более свежие "разливы".

Тут рассуждать, как вилами по воде, знаю только то, что почему то в ALT Linux с сертификацией под Эльбрус всё норм. А вот для ОС Эльбрус почему то нет. На счёт свежих разливов не знаю, смотрел как то то, что они выложили в гит, и нового там особо не видел. Основное сейчас это то, что собирает ALT LInux, то более новое.

[Aliech]

Тут рассуждать, как вилами по воде, знаю только то, что почему то в ALT Linux с сертификацией под Эльбрус всё норм. А вот для ОС Эльбрус почему то нет. На счёт свежих разливов не знаю, смотрел как то то, что они выложили в гит, и нового там особо не видел. Основное сейчас это то, что собирает ALT LInux, то более новое.

Вы понимаете, какое дело... Есть в моей биографии грешок - работа в ВПК. Я что-то об предмете обсуждения знаю даже... Из первых рук, что называется. Актуальное на состояние конца 2021года/начала 2022ого. Но вы меня пытаетесь убедить в чём-то другом. Это очень нахраписто, прям вы молодец!

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

Вы включились в обсуждения с ответа на мою реплику, где я указывал yoricI на неверность позиции "да пусть режут по самый pentium 3". Конечно я воспринимаю это как защиту позиции "да пусть режут по самый pentium 3". Иначе что вы ещё пытались мне донести? А если вы другое имели ввиду, то, пожалуйста, ещё разок повторите. Так чтобы вас понятно было.

[ormorph]

Иначе что вы ещё пытались мне донести?

Нефиг смотреть на всякий подтекст. Я имел в виду, что особо нового тут не увидишь, раз взялись за дело то рано или поздно удалят. Вы же хотели бы получать последние актуальные исправления ядра. Тут всего лишь факты что решили удалить и всё тут. Так же было когда переходили на systemd, тоже много кто возмущался, но тем не менее всё равно оно теперь почти везде. Само собою что это неприятный факт, но тут особо нечего не сделаешь. Мне ещё в технические особенности этого включаться не хватало. Тут так же можно сказать почему micropython не собирается под esp32 последним компилятором gcc, а только с использованием старого esp-open-sdk. Я говорю что если нужно решить проблему, то нужно пользоваться подходящим инструментом. В данном случае если нормальной поддержки для Vortex86 в ядре не будет, то нужно решать проблему по дургому. Если для вас это современный процессор, то для кого то это уже вчерашний век.

Я понимаю что хочется доказать свою правоту, но мне как то это всё равно, я полно похожих примеров видел, когда кому то что то не нравится, то предлагают использовать подходящий инструмент. Это так же как я вам про последнее ПО, а вы мне с сертификацией.

[Aliech]

Это так же как я вам про последнее ПО, а вы мне с сертификацией.

А тут что не так? Наоборот, я просил вас привести примеры, когда в состав нового программного комплекса, который должен крутится на актуальном (активно производимом, поставляемом и потребляемом) железе, зачем-то включают ядро ОС заведомо десятилетней давности. Вы же мне давай за Эльбрус ОС сообщать, притом за какую-то ей древнюю версию. А на моё возражение про то, что древность компонентов Эльбрус ОС связана, в основном, со стоимостью, которую, фактически, приходится башлять сертификатору при каждом изменении состава ОС, вы давай что-то про компиляторы...

Так примеры то будут, акромя Эльбрус ОС?

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

У меня для вас плохие новости: это отличный процессор для промышленного оборудования. И его поддержку не выкидывают. Но если будут выкидывать, то, конечно, хотелось бы веские причины видеть, а не чьи-то современно/не современно. Это относится вообще к любому оборудованию. Не только к CPU или только к Vortex86. Потому что неприятно, когда привычный инструмент берёт и не заводится. Но! Одно дело, когда поддержку выкинули, потому что она стоила человекочасов, но не была востребована/оплачена. Другое дело, когда кто-то там что-то за современность порешал.

[ormorph]

Вы же мне давай за Эльбрус ОС сообщать, притом за какую-то ей древнюю версию. А на моё возражение про то, что древность компонентов Эльбрус ОС связана, в основном, со стоимостью, которую, фактически, приходится башлять сертификатору при каждом изменении состава ОС, вы давай что-то про компиляторы...

Вот когда они выложат в свободный доступ исходник своего компилятора тогда и поговорим, что с чем собирается. Мне как то до этого уже нет дела. Лично я сомневаюсь что там все последние стандарты реализованы, это про само ПО, которое должно ещё работать с ядром, само ядро тут пол беды. Как буд то сами ни когда не собирали и не знаете что то что написано под новые стандарты под старым компилятором собираться не будет(C, C++). Я тут исхожу из их заявлений, что код собранный именно их компилятором показывает наибольшую производительность. Просто знаю что сколько разработчиков в gcc, МЦСТ такого не найти. Я уже сказал, что это всё равно что современный софт попробовать собрать с помощью gcc-2.95, точнее намекал. То что собирают ALT, это порт gcc под эту архитектуру, и это уже на много легче.

Так примеры то будут, акромя Эльбрус ОС?

Зачем вам примеры, вы и сами скоро увидите то же самое с Vortex86, ах да тогда оно уже не будет относиться с современному железу.

[Aliech]

Вот когда они выложат в свободный доступ исходник своего компилятора тогда и поговорим, что с чем собирается. Мне как то до этого уже нет дела.

Вы сначала обоснуйте тезис, что комплектация устаревшими компонентами вызвана именно невозможностью сборки. А то ведь есть шанс того, что вы видели просто очень старую версию Эльбрус ОС (скорее всего так и было). Со старым GCC в комплекте. Патчи на GCC, кстати, разрабатывались ещё в МЦСТ. Так что свежий GCC, которым собирает Базальт, он тоже из МЦСТ родом. Ну так вот. Обоснуйте, пожалуйста.

Зачем вам примеры, вы и сами скоро увидите то же самое с Vortex86, ах да тогда оно уже не будет относиться с современному железу.

Я не понял, пояснитесь пожалуйста...

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

Так вот, когда убирают функционал из софта - это всегда неприятно. И одно дело, когда убирают функционал, мешающий движению вперёд. Другое дело - когда убирают функционал лишь потому, что кто-то решил, что что-то там устарело, а он (функционал) не мешал и не баговал. Фактически весь код, начиная с 486го, снаряженного функцией CMPXCHG8B, - есть один и тот же код, к которому добавляется функционал, что называется, "с боку", типа разных наборов MMX, SSE и т.д. Только необходимость эмуляции CMPXCHG8B УВЕЛИЧИВАЕТ размер кода. Поэтому сейчас, когда речь идёт об том, чтобы избавится от кода, усложняющего ядро, - всё ОК.

Но если кто-то возьмёт и выкинет из ядра поддержку процессоров, условно, до Pentium 3, лишь потому, что "всё равно на них десктоп неудобно", то это, мягко говоря, будет сомнительным шагом. Ибо зачем трогать код, который "кушать не просит"? Особенно если этот код работает на процессорах, выпускаемых в данный момент времени, которые лишь отсутствием SSE (который весьма опционален) не дотягивали до того Pentium3?

[ormorph]

Вы сначала обоснуйте тезис, что комплектация устаревшими компонентами вызвана именно невозможностью сборки. А то ведь есть шанс того, что вы видели просто очень старую версию Эльбрус ОС (скорее всего так и было). Со старым GCC в комплекте. Патчи на GCC, кстати, разрабатывались ещё в МЦСТ. Так что свежий GCC, которым собирает Базальт, он тоже из МЦСТ родом. Ну так вот. Обоснуйте, пожалуйста.

Там вроде как был не gcc, а компилятор их собственной разработки lcc. Если сейчас собирают что то более новое, то это уже не lcc а gcc. По крайней мере то что ОС собиралась именно lcc а не gcc. C gcc вполне могли они собрать уже что то более новое. А так сами попробуйте собрать то что писалось для C++-17 под C++-11( а там были фишки и под СИ), о каком современном ПО тут может идти речь. Если что то определённое можно портировать, то большой объём ПО уже нет просто не хватит ресурсов.

Я не понял, пояснитесь пожалуйста...

Удалят поддержку из ядра, что сами делать будете? Выкините на свалку?

[Aliech]

Удалят поддержку из ядра, что сами делать будете? Выкините на свалку?

см. выше

Там вроде как был не gcc, а компилятор их собственной разработки lcc.

Там бэкенд компилятора был их, в lcc если. Плюс они патчи к gcc передапи в Базальт и Русбитех. "Имел честь" поднять на совещании вопрос о том, что МЦСТ дали патчи к GCC Базальту и Русбитеху, но не передали их Институту системного программирования РАН, который, собственно, назначили ответственным за ведение кодовой базы gcc и linux'а. Как их представители на троих морозится стали! Такой вот бизнес, знаете ли. Жаль не под камеру! Это у нас осень 21го года была.

[ormorph]

Там бэкенд компилятора был их, в lcc если. Плюс они патчи к gcc передапи в Базальт и Русбитех. "Имел честь" поднять на совещании вопрос о том, что МЦСТ дали патчи к GCC Базальту и Русбитеху, но не передали их Институту системного программирования РАН, который, собственно, назначили ответственным за ведение кодовой базы gcc и linux'а. Такой вот бизнес, знаете ли. Это у нас осень 21го года была.

Слышал я эту историю, они gcc портировали совместно с ALT, и там много проблем было с координацией между собою по документации, точнее на сколько я понял патчи были для старого компилятора, а им нужно было переписать на новый, либо я не так понял. Там больше совместная работа на сколько я понял была. Но lcc как раз чисто продукт МЦСТ, и на нём по их заявлению код работал с наибольшей производительностью. Как там дела обстоят с gcc в этом плане сейчас я не знаю, может он просто генерирует код который может запускаться, но не использует все фишки процессора. На сколько я понял они часть собирали на lcc, а часть что связана с графикой на gcc. Но если поритровать на новые пакеты то возникнут вполне не маленькие расходы. Как бы всё равно опять же идёт отсыл к компилятору. В случае использования gcc расходы уменьшаются кратно, так как можно брать готовые наработки из ALT Linux, у них же всё равно идёт кооперация.

см. выше

Где? То что оно будет работать только максимум с 4 гигами памяти(-PAE), оно уже не будет современным и полной поддержки уже не будет.

[Aliech]

Слышал я эту историю, они gcc портировали совместно с ALT, и там много проблем было с координацией между собою по документации, точнее на сколько я понял патчи были для старого компилятора, а им нужно было переписать на новый, либо я не так понял.

Я не знаю этой истории. Я знаю, что патчи для GCC были выданы МЦСТ Русбитеху и Базальту. Перерабатывал ли Базальт патчсет или нет - дело десятое. В любом случае, свежий кмпилятор у них, как сами видите, был. И да, каждый раз, когда вы видите сертифицированную ОС и старые версии софта в ней, помните, что это про бабло. Обновление версий компонентов = занести бабла сертификатору. Это касается и сертифицированного Альта. И Астры.

Где?

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

Так вот, когда убирают функционал из софта - это всегда неприятно. И одно дело, когда убирают функционал, мешающий движению вперёд. Другое дело - когда убирают функционал лишь потому, что кто-то решил, что что-то там устарело, а он (функционал) не мешал и не баговал. Фактически весь код, начиная с 486го, снаряженного функцией CMPXCHG8B, - есть один и тот же код, к которому добавляется функционал, что называется, "с боку", типа разных наборов MMX, SSE и т.д. Только необходимость эмуляции CMPXCHG8B УВЕЛИЧИВАЕТ размер кода. Поэтому сейчас, когда речь идёт об том, чтобы избавится от кода, усложняющего ядро, - всё ОК.

Но если кто-то возьмёт и выкинет из ядра поддержку процессоров, условно, до Pentium 3, лишь потому, что "всё равно на них десктоп неудобно", то это, мягко говоря, будет сомнительным шагом. Ибо зачем трогать код, который "кушать не просит"? Особенно если этот код работает на процессорах, выпускаемых в данный момент времени, которые лишь отсутствием SSE (который весьма опционален) не дотягивали до того Pentium3?

[ormorph]

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

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

[Aliech]

ormorph, кстати, я таки без systemd везде. Ходить своей дорогой привычен, но очень раздражаюсь, когда кто-то пытается назначать дорогу, исходя из представлений о какой-то там современности, но не из целесообразности.

И да, в OpenBSD X'ы пока не удаляют. А ещё некрожелезо тащат до последнего. FYI

[yoricI]

OpenBSD X'ы пока не удаляют. А ещё некрожелезо тащат до последнего. FYI

И 386 поддерживается?

[ormorph]

ormorph, кстати, я таки без systemd везде. Ходить своей дорогой привычен, но очень раздражаюсь, когда кто-то пытается назначать дорогу, исходя из представлений о какой-то там современности, но не из целесообразности.

Так я и сам на Gentoo не использую systemd. Но иногда современность больно бьёт. Везде всё равно не получится без systemd, так как кто платит тот и правит балом.

Сейчас прошёл переход в Gentoo на Python3.13, в этот раз решил не ждать до последнего, переписать свои локальные ебилды под Python3.13. Не скажу что легко прошло, но в целом получилось, где то пришлось добавить дополнительные standard-xxx, для совместимости со старым python. Но тут напрягает что теперь совместимость пакетов строго с python3.13, так как там строчка:

Shell

PYTHON_COMPAT=( python3_13 )

И обратной совместимости со старым python теперь нет, точнее есть но с другой версией ебилдов, так как тут зависимости от новых пакетов standard-xxx. Сейчас если бы не Docker, то что то портабельное создавать было бы проблемно, так как можно запустить то что собранно под старыми библиотеками типа СИ на новом, но не наоборот.

[yoricI]

Везде всё равно не получится без systemd,

Пример можно, для прикладного ПО?

[Aliech]

И 386 поддерживается?

Если вы про сам процессор intel 386, то нет. Но всё, начиная с Pentium I - да. Но они умудряются sparc тащить!)

Так я и сам на Gentoo не использую systemd. Но иногда современность больно бьёт. Везде всё равно не получится без systemd, так как кто платит тот и правит балом.

Я уже не на Генте. Отовсюду её извёл, ибо смысла совсем не стало. Настолько плох местами портаж стал, что проще мне оказалось кастомные deb-пакеты собирать. Благо выделенная машина есть для фермы и репы. Половина парка Debian/SysV (не Диван), половина - OpenBSD.

Пример можно, для прикладного ПО?

Всё, что на systemd-logind завязано, но на этот случай есть заглушки типа elogind.

Добавлено (07:54):

yoricI, а как вам такой порт https://www.openbsd.org/luna88k.html ? Вот уж много вопросов, типа зачем и нафига... Но они его тянут!)

[ormorph]

Пример можно, для прикладного ПО?

Зачем вам ПО, если нужно просто сделать демон для systemd с сервисом. Вам же как то нужно его всё равно на чём то это проверять. То что демоны от systemd и под openrc запустить я в курсе и логи так же можно получать через syslog. Но просто если есть момент когда нужно запустить проверить и запустить именно сервис systemd, то всё равно придётся использовать именно systemd. Так же когда вы идёте к работодателю устраиваться, он вам специально выделит именно sysvinit и openrc, так как вы хотите и привыкли на этом работать? Про то и говорю что везде не получится, где то да придётся использовать systemd. Если получалось раньше, не значит что так будет постоянно.