Материалы по тегу: legacy

15.01.2021 [20:25], Андрей Галадей

В Debian 12 могут отказаться от поддержки i386

Дата релиза Debian 11 (Bullseye) пока не сообщается разработчиками. Однако они уже готовятся к началу работы над Debian 12. И, судя по первым сведениям, в этой сборке могут сократить поддержку процессоров i386. Для версии 11 мягкая заморозка кодовой базы стартует 12 февраля, а полная — месяцем позже. Для Debian 11 будут поддерживаться архитектуры AMD64, ARM64, ARMEL, ARMHF, i386, MIPS64EL, MIPSEL, PPC64EL и s390x. Таким образом, сейчас отказались только от базовой версии MIPS.

theregister.com

theregister.com

Между тем, в Debian 12 (Bookworm) число «отказников» может вырасти. В последнее время ведутся дискуссии о состоянии поддержки архитектуры i386 и о том, как с этим справиться в будущем. Пока что основном мнением является продолжение поддержки 32-битных процессоров. Однако окончательное решение пока не принято.

Отметим, что Debian 11 «Bullseye» должен быть выпущен в этом году, тогда как Debian 12 «Bookworm» появится не раньше 2023 года. Потому не исключено, что к тому времени вопрос поддержки означает будет не слишком актуален. Также отметим, что уже известно кодовое наименование дистрибутива Debian 13 — «Trixie». Его релиз ожидается примерно в 2025 году.

Постоянный URL: http://servernews.ru/1030183
13.01.2021 [23:29], Андрей Галадей

Разработчики ядра Linux обсуждают отказ от ряда старых процессоров

Ядро Linux 5.10 стало очередным релизом с долгосрочной поддержкой (LTS), который будет поддерживаться как минимум в течение следующих пяти лет. И потому в сообществе началось обсуждение отказа от поддержки ряда устаревших процессоров и архитектур. В числе аргументов сторонники удаления отмечали, что многие платформы не получали обновлений и коммитов уже много лет.

Разработчик Арнд Бергманн (Arnd Bergmann) предложил список из 30 с лишним платформ Arm, которые можно было бы безболезненно убрать. Большая часть из них, попав в основную ветку ядра, получала обновления в течение 1-3 лет, после чего была заброшена. Другая часть относится к «доисторическим», то есть к таким, которые уже давным-давно не производятся.

hackster.io

hackster.io

Наконец, есть перечень платформ, которые давно «мертвы» и не поддерживаются разработчиками порядка 10 лет:

  • H8300
  • C6X
  • SPARC/Sun4M
  • PowerPC: CELL (не считая PS3), CHRP, AmigaOne, Maple
  • M68K: Apollo, HP300, Sun3, Q40
  • MIPS JAZZ и Cobalt

Кроме того, есть и архитектуры, которые тоже можно рассмотреть в качестве кандидатов на исключения из ядра Linux:

  • 80486SX/DX — поддержка 80386 прекратилась в 2012 году, нет смысла поддерживать и 80486.
  • Alpha 2106x — системами на базе любых Alpha вряд ли кто-то пользуется.
  • IA64 Merced — первое поколение Itanium, на смену которым через год пришли Itanium II.
  • MIPS R3000/TX39xx: 32-бит чипы MIPS-II (не путать с более современной MIPS32), которые с 1991 года вытеснены 64-бит MIPS-III.
  • SuperH SH-2 — популярная в середине 90-х архитектура для встраиваемых систем.
  • 68328 (DragonBall) — поддержка похожих микроконтроллеров 68360 удалена в 2016 году. Поддержка более новых 68020+ и Coldfire MCF5xxx сохранится.

Вопрос об удалении старых архитектур возник не на пустом месте. Арнд Бергманн изучал текущее состояние 32-бит платформ и потенциальную возможность отказа от них, так как полный переход на поддержку только 64-бит архитектур значительно облегчил бы жизнь разработчиков во многих аспектах. Ранее он предположил, что через десять лет среди массовых архитектур останутся только x86-64, ARM и RISC-V.

Постоянный URL: http://servernews.ru/1029884
29.12.2020 [20:40], Андрей Галадей

Bootlin «научит» старые NAS с 32-бит ARM-процессорами работать с хранилищем ёмкостью более 17 Тбайт

Современные объёмы жёстких дисков и технологии RAID уже давно позволяют собирать системы на десятки Тбайт данных. Однако не всегда есть возможность задействовать такие объёмы из-за ограничения аппаратной и программной частей. В строю до сих пор есть масса устаревших NAS на базе 32-битных процессоров ARM и не самых свежих ядер Linux.

Однако в такой конфигурации есть проблема, связанная с тем, что по умолчанию используются 4-КиБ (кибибайт) физические страницы, а это накладывает ограничение на максимальный размер адресуемой памяти в 16 ТиБ (~17,59 Тбайт) для хранилища, причём это практически не зависит от файловой системы. Проще говоря, современные накопители, которые уже достигли 20-Тбайт объёма, подобный NAS попросту не «осилит».

kobol.io

kobol.io

Одно из решений проблемы — использование страниц памяти большего размера. Точнее говоря, их эмуляция, так как есть некоторые нюансы в организации работы с памятью внутри ядра и собственно аппаратной реализацией в 32-бит ARM. Другим подходом является использование 64-битных (pgoff_t) смещений для адресации файловых систем, и некоторые производители уже используют его.

Подробнее обо всём этом компания Bootlin рассказывает в своем блоге. Именно она по заказу неназванного производителя NAS подготовила серию патчей для решения этой проблемы. Причём её реализация поддерживает страницы размером 4, 8, 16, 32 и 64 КиБ. То есть это даёт возможность работы с 256-ТиБ пространством в случае 64-КиБ страницы.

Патчи были выпущены довольно давно, но до сих пор не добавлены в основную ветку ядра Linux. И вряд ли будут. Одной из причин этого является тот факт, что поддержка больших страниц для 32-битной ARM-системы увеличивает расход памяти. Так что компромиссным вариантом пока является использование 8-КиБ страницы, которые дают поддержку до 32 ТиБ при минимально возможном перерасходе памяти.

Постоянный URL: http://servernews.ru/1028953
02.09.2020 [22:58], Илья Коваль

Компиляторы могут остаться без поддержки Intel MMX

Набор SIMD-инструкций Intel MMX, представленный в 1997 году, является откровенно устаревшим и уже давно вытеснен различными версиями SSE и AVX. Тем не менее, в средствах разработки они всё ещё формально поддерживаются. Правда, в силу редкости использования, их имплементация страдает от багов. Поэтому неудивительно, что их в очередной раз предложили выкинуть из популярного набора компиляторов LLVM.

В обсуждении, начатом в листах рассылки, предлагается переписать и заменить интринсики для MMX на новые, использующие уже имеющиеся для SSE или, лучше, SSE2. Текущие требуют некоторый внимательности от разработчика, так как при некорректном использовании программа будет не падать, а выдавать некорректные результаты. В дальнейшем предлагается исключить MMX из представления LLVM IR.

Единственный способ использования этих инструкций и сопутствующих регистров, если это по какой-то причине действительно нужно — использование ассемблерных вставок непосредственно в коде. Любопытно, что, судя по всему, даже физически отдельных регистров для x87/MMX в современных процессорах уже нет — они делят «кремний» с регистрами для маскирования AVX-512, так как вероятность высокой нагрузки со стороны обоих типов инструкций одновременно крайне маловероятна.

Отказ от MMX, естественно, повысит минимальные требования LLVM. Однако сейчас трудно найти работающую x86-систему, в которой нет поддержки SSE2 или хотя бы SSE. Это перекликается с активизировавшимися призывами отказаться от поддержки старых CPU вообще, 32-битных и без современных инструкций. В частности, Fedora и RHEL уже движутся в этом направлении.

Постоянный URL: http://servernews.ru/1019749
Система Orphus