Начались разговоры об удалении поддержки архитектуры процессоров i486 в ядре Linux

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

всего то 18 лет как прекратили производство!

Давеча, при Государе-Императоре кораблик построили, «Волховъ». Так он до сих пор в строю, работает. Про архитектрные сооружения я вообще молчу. И только в этом нашем ИТ всё считается устаревшим сразу после выпуска.

Втыкание твердотельного диска через переходник sata-ide волшебным образом очень сильно ускоряет старые компы. Особенно если получается еще и память до максимально поддерживаемой чипсетом добить.

Да я и сам эту идею до экстрима довёл. :) До сих пор стоит «шкаф» с СЖО и АМД Феномом начала 2000х. Пиханул туда ССД и 20Гигов ддр2 оперативы, и, в целом, он норм живёт. Да, собирать что-то из исходников - бывает напряжно. По этому, всегда отключаю LTO, и тогда хотя бы линкуются проги не 10 минут, а 10 секунд. :)

При этом, сейчас пишу не с него, а с современного ноута с хорошим процом и ссд, но всего 8Гб оперативы (и добавить нельзя). И вот это вот полный ахтунг! Всё тупит и пердит гораздо хуже, чем на 20летней давности шкафчике. Но всё-таки феном начала 2000х и 486 начала 90х - это 2 огромные разницы. Четвёрик бы уже не вытянул. Вне зависимости от памяти и ссд. Там даже мп3 декодировать было проблематично, нужно было битрейт занижать.

К примеру помещаем массив в отдельный сегмент и выход за его границу будет проверяться аппаратно.

Ну, в принципе, вы можете и guard page после массива вставить. Тот же эффект. И, в то время как сегментов может быть всего порядка 8000, пустых пейджей можно и больше наклепать.

Это было возможно под некоторыми дос-экстендерами и я лично это использовал под одним из них в начале 90х.

Сейчас проще использовать санитайзеры.

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

Уже пофиксили битиком NX.

Единственное, с чем можно согласиться - это с тем, что Интел вложился в сегментацию куда более основательно, чем в пейджинг. И по этому у сегментов сразу можно было выставить права на исполнение, а у страниц это появилось спустя 25 лет. У сегментов было 4 уровня привелегий, а у страниц - 2. Ну и вот, как выяснили, даже виртуальное адресное пространство было у сегментной модели значительно шире, чем у страничной.

Единственный недостаток всего этого - оно есть только на x86, но нет например на АРМе.

По тому, что там изначально пейджинг нормально сделан, и ничего другого не нужно.

На практике такие огромные сегменты если и нужны то крайне редко.

Мы обсуждали возможность расширить адресное пространство до 42бит и более. Для этого нужны большие сегменты.

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

Речь не обязательно про код. Можно было, к примеру, сделать аналог mmap(), только чтобы файлы он маппировал в отдельные сегменты. И тогда бы получилось намаппировать гораздо больше, чем на 32битной архитектуре можно. Так что сама по себе идея, конечно, прикольная… Только вряд ли хоть кто-то так делал.

А вот программисты как обычно не осилили использовать весь потенциал,заложенный в железо.

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

В конфиге ядра уже есть опции с поддержкой вендоров цп, почему не сделать опцию тоже, но с i486, i686, x86-64, sse4, avx?

Есть опции для компилятора, чтобы он не использовал какие-то инструкции при оптимизации. А есть возможности проца, на которые завязаны платформозависимые ассемблерные файлы. И если первые легко отключить - компилятор и так справится, то вот со вторыми возникают проблемы. Ведь программист - не компилятор. Он может сказать «без этой функциональности мне реализовать данный алгоритм слишком сложно, я не буду». А компилятор так, обычно, не говорит. По крайней мере пока. :)

Интересно кстати - насколько сложно было бы написать отдельный ядерный модуль, который бы занимался трансляцией одной разновидности драйверного API в другую и позволял грузить драйверы не от той версии ядра?

Такие попытки делались. Например, media_build для мультимедиа-драйверов: https://www.linuxtv.org/wiki/index.php/Media_build Предоставляла АПИ и систему сборки, совместимую с новыми ядрами, но позволяющую собирать для «любых» старых.

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

На архитектурах где вообще нет этого TSC,ядро как-то без него вполне обходится.

Таймер с быстрым доступом (просто счётчик тиков) есть на всех современных архитектурах. Ну на арме - точно есть. Вы же не будете предлагать ядру в PIT лазить - это не только тормозить будет дико, но ещё и вообще не получится стабильный тайминг получать, так как там нельзя узнать, были ли переполнения между последовательными чтениями.

Ваши половые компьютерные извращения норму не определяют

Это ограничение на один сегмент. А всего может быть до 64Тб.

Но не оперативки. PAE давала 64Гб и всё.

Думаю, сегменты несовместимы с UNIX.

man modify_ldt

Всё совместимо и работает, на самом то деле. Только не нужно оказалось никому.

Нет,мы приходим к тому,что программисты не умеют писать софт. Подход «тяп-ляп и в продакшн» стал слишком популярен.

Это вопрос философский. В 80е годы любой софт мог быть написан или «дописан». А сейчас - законченного совта не бывает в принципе. Бывают только релизы. Каждый из которых, как правило, содержит кучу новых багов относительно предыдущего релиза. Если софтину перестают «развивать», то нынче она считается мёртвой, хотя раньше она бы считалась доделанной. Так что дело даже не в том, что кто-то что-то разучился делать, а в экспоненциально возросшей сложности программных проектов. И поскольку довести до финала ни 1 проект теперь нельзя, то подход «тяп-ляп и в продакшн» - это то, что хотя бы просто работает.

экспоненциально возросшей сложности программных

не нужная лесть imho

тут скорее

«>экспоненциально возросшей энтропии программных »

обусловленной 2 (по сути 1 причиной) - удешевление стоимости выч_операции&памяти(память впрочем это тоже вычислительная операция которая откладывается в будущее либо экономится извлечением из хранения а не «синтезом» из «нормализованных до мин колмогоровской длины» данных) и как следстие 2 причина - обратная отрицательная связ в части падения медианы уровня программистов ( эффект погружения широкой базы) социум в целом ради гомеостаза падает общая образованность ибо именно благодаря прогрессу в науке для сохранения прежднего уровня потребления ниши уменшается количество потребное компетентных - только компенсирующий рост потребностей сохраняет(и даже делает запрос на рост и количество и качество) компенентность

знаменитая статья Вирта о свистелках и бубенцах именно о «привнесёной» сложности обусловленной первопроходчеством - а благодаря дешивезне вычислений костыли(которые как первые решения отодвигающие горизонты замечательны) тиражируются инфляционно и эта трясина приводит к «DEVупс"у

впрочем:

https://dl.acm.org/doi/pdf/10.1145/1283920.1283936

https://habr.com/ru/articles/789550/

+

https://teletype.in/@pantheon/2024-02-15

https://habr.com/ru/articles/789550/

Призыв писать компактное ПО, версия 2024 года (с примером кода)

При чём тут вообще код? Экспоненциально возросшая сложность программных проектов, о которой я говорил, происходит из-за экспоненциального роста объёмов обрабатываемых данных, а так же растёт сложность их структурирования. У вас на веб-страничках данные уже не располагаются удобными для парсинга массивчиками. А состоят из сотен различных компонентов (картинки, скрипты, что угодно ещё). И ни 1 парсер таких компонентов вы не напишете сами: попробуйте, ради прикола, написать с нуля декодер хотя бы jpeg-картинки, не говоря уже про видео. По этому и берут миллион зависимостей. И веб-страничка - это уже далеко не предел мечтаний. Сейчас парсят уже весь интернет нейронками.

Так что все эти «пишите компактый код, и будет вам счастье» - это крик в никуда. К реальности он отношения не имеет.

есть несколько идущих процессов

«на краях» очевидно рост доступных к процессингу объёмов

«внутри» дефицит двигающихся(от ядра)[==остающихся на краю расширения возможностей] людей которым не нужны «излишки» [вычь мощи]

как результат энтропия «дешевого» по больше энтропии «дорого»

а по факту дешёвое по дешево удельно :)

отсутствие экономических препятстий блоатварит код

более того подписная модель сохраняет и стабилизирует потоки

в отличии от пришёл спец и на поколение устранил проблему

и всё таки старое платье импера(тора|тива)

о стремлении к различению сущностной сложности проблемы и привнесённой «молотком гвоздирующим реальность»

ибо время критический путь

а не факт что изделие потребляет терабайт вместо килобайта - ибо на фиатном рынке память менее дефицитна чем время

к времени как критическом пути в бизнесе ( в проекции отношений менеджерья и лопатомахателей):

https://youtu.be/ud7kNkcqZ24

Придётся прод перевозить на Pentium

Не торопился бы ты так с переводом на сырое поделие, еще и пол сотни лет не тестировавшееся…