>>3142
На идиотский вопрос даю идиотский ответ.

На IBM-совместимых персональных компьютерах используются две процессорные архитектуры — оригинальная x86 и её надстройка до 64 бит, amd64.

Исторически для x86 поддерживались все тридцатидвухбитные процессоры с поддержкой страничной виртуальной памяти, то есть 386 и более новые. Иначе говоря, как раз то, на чём юный Торвальдс начал писать свою систему. По мере того, как древние процессоры теряли актуальность, новый код мог в качестве минимальной системы подразумевать более новые (например, потому, что конкретное устройство никогда не выпускалось для старых систем, и не может на них работать даже теоретически). Кроме того, настройки компилятора и используемые низкоуровневые примитивы и инструкции могут с одним и тем же кодом ограничивать использование полученных бинарных файлов.

Кроме того, разработчики конкретных пользовательских сборок линукса могут договориться, что поддерживают только более новые системы с конкретным набором функций ради единых и привычных настроек компилятора для всех пакетов, скорости работы, проверок безопасности и так далее. В результате, например, даже консервативный Debian в качестве самого старого процессора требует Pentium Pro, потому что ядра по умолчанию используют PAE-адресацию памяти. Само собой, есть обоснованные сомнения, что хоть где-то в мире не ради прикола работает сервер на Pentium Pro со свежим Debian, да и PAE решает проблемы более современных конфигураций с гигабайтами памяти, а для более старых (и так же бесполезных на практике) систем не нужен. Другие группы могут проводить границу, к примеру, по поддержке инструкций SSE, и собирать свои системы только под более новые процессоры.

Само собой, во многих случаях версия под x86 сегодня просто отсутствует, поскольку и разработчики, и пользователи в большинстве своём давно перешли на шестидесятичетырёхбитные системы. Ядро линукса поддерживает все такие процессоры, а вот сборщики могут поднимать границу актуальности.

Celeron N4500 выпущен в 2021 году, совсем недавно. Технически он должен быть совместим с любой линуксовой сборкой, а используемая память (DDR4) подразумевает, что минимальный объём памяти для запуска в системе найдётся, если хоть какая-нибудь память там установлена (не знаю, можно ли на одноплатниках распаять меньше чипов, чем на планке памяти, но с точки зрения функциональности в 2021 году и далее получилось бы бесполезное устройство). Следовательно, ядро линукса он потянет, а про остальное ты ничего конкретного не сказал.

>>4105
Какого хера ты занимаешься бессмысленным нагревом атмосферы и чтением хуйни в интернетике вместо чтения документации и действий по существующим инструкциям?

Если тебе нужна автоматическая подмена майкрософтовских шрифтов, то она настраивается в fontconfig, а не в посте с реддита. Добрые люди, обслуживающие твой дистрибутив, могли всё уже сделать за тебя. Пиздуй читать документацию.

Если тебе надо настроить то, как растеризуются шрифты, пиздуй читать документацию и настраивай, а не тыкай во все подряд кнопки в автомате, которым не умеешь управлять.

Любой шрифт, который ты берёшь, хоть псевдорукописный с завитушками, хоть «Impact», не «плохой» и не «хороший». У всех очертания знаков задаются кривыми с произвольными координатами, которые не представимы без ошибок при помощи дискретных пикселей. Требуется как-то выбрать, какие именно ошибки допускать при их переводе в растровую картинку.

Допустим, у нас получилась линия толщиной в 1,5 пикселя. Её невозможно просто так нарисовать на мониторе. Что делать?

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

А второй вариант — чисто математически ставить прозрачность пикселей в соответствие занимаемой наложенной частью символа площади. В плюсе то, что это максимально корректная растеризация заданной формы для заданной сетки пикселей. В минусе — в большинстве случаев резких границ не будет, поскольку практически всегда штрихи оказываются «посреди» пикселей и один на границе выходит промежуточного цвета из-за полупрозрачности. Тем не менее, именно такое решение является необходимым в некоторых случаях. Например, при анимации надписей (движении, повороте, увеличении) попытки привязки к пикселям при генерации каждого кадра приведут к тому, что буквы будут перескакивать или раздуваться и сужаться своими частями вместо плавного изменения. Дальше у полученной картинки можно менять контрастность, то есть вместо линейной функции сопоставления использовать S-образную, а также сдвигать ноль, получая либо более тёмные и толстые, либо более светлые и тонкие линии.

Настройка отображения шрифтов как раз и позволяет выбрать, какие искажения тебе эстетически более приятны. Тут и уровень хинтинга, и уровень контраста.

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

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