Это правда, что с каждой новой версией ядра увеличивается расход памяти и падает быстродействие?

В смысле «была»? А она разве куда-то делась?

Ну вон, говорят, что кончилась. Я не пользовался после OS/2.

Это правда, что с каждой новой версией ядра увеличивается расход памяти и падает быстродействие?

Ныне «кто выще бье, тот краще грает».
В далёкие 80-е и 32KB на раздел (СМ-1, СМ-2М, ...) вполне хватало для решения многих задач.

Поддержка есть в ядре, так что теоретически можно даже на неё ОС поставить.

640 кб хватит всем !! :)
в современном компе настолько дохрена ресурсов, что современные погромисты пилют не «эффективный и быстрый» код а «простой и быстронаписываемый», обмазывая его прокладками hal виртуалками и прочим…
потому современные програмы никак не быстрые.
компиляторы, которые должны преобразовывать высокоуровневые абстракционные писанину в качественные код тож никто не рвется улучшать и прорабатывать - «работает и ладно».

«погромист должен творить!!!» а не разбираться в распределении регистров для быстрой работы.

Быстродействие не в регистрах.

щас бы подразумевать что говнокодеры заморачиваются с алгоритмами

потому современные програмы никак не быстрые

не знаю, на моём десктопе всё летает

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

С каждой версией ядра добавляется новый код. Сам то как думаешь?

да, новая ветка кода под simd инструкции конечно всё так замедляет

Раньше Linux запускался на 486 с 8Mb, а сейчас?

Debian 12

Минимальной рекомендуемой конфигурацией для настольной системы является машина с процессором Pentium 4, 1 ГГц.

Говорят, новая убунта быстрее старой.

на компьютерах из Топ500, наверное

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

для высокоэффективного кода необходимо познание «железной» работы процессора и соответствующий опыт

для высокоэффективного кода нужно понимание алгоритмов и достаточное количество времени

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

man Закон Вирта

Нет, не нормально.

знатоки алгоритмов написали электрон. ибо так проще писать алгоритмы :)

ядро << браузер. быстродействие… смотря как собрано, частота и прочая муть. для быстродействия сети опять же, я предпочитаю вествуд при вайфаи (пацаны расказывали, что так быстрее). Объём ведра тоже смотря, какие галочки/звездочки поставлены ))))

💡️Мертвизна линукса пропорцианально отмиранию твоего мозга)))☝️

Прочитай ядрённую физику для домохозяек, устарело конечно, но суть верна.

Проверь и напиши результат

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

Нет. Разница будет несущественна.

Это довольно размазанное утверждение, которое скорее всего не правда. Новые устройства, файловые системы и протоколы не поедают ресурсы просто так, их нужно использовать, включить опцию в ядре, подключить эти самые устройства. Со временем само ядро рефачат, удаляют поддержку совсем старья, совершенствуются компиляторы, в железе появляются дополнительные возможности ускорить ядро (но иногда вот приходится и баги в железе закрывать с ухудшением производительности), поэтому в долгосроке оно должно становиться быстрее. Что касается памяти, ядро её использует как дисковый кэш, расходуя все 100%, потому как нет смысла держать её в бездействии, само собой, если вдруг память понадобится приложениям, то размер этого кэша уменьшается.

Зато сетевой стек, шедулеры, драйверы fs... Сравни размер модулей ext2/3 и ext4!

24.04 быстрее чем 16.04. Памяти 24.04 есть меньше чем 22.04.

Размер растёт, это факт. К счастью не опережающими темпами а вполне сносно.

А вот с быстродействием всё сложно, но обычно на ~90% конфигураций новое ядро не медленней, а где то даже быстрее. Факапы с тормозами случаются, но не слишком то смассовые.

Да, вопрос бессмысленный и скорее ради холивара. Модераторы недавно кого то за это банили.

Строго говоря та же ехт4 со всеми плюшками в большинстве сценариев не превосходит ехт2 времён ядра 2.6, хотя бы просто потому что в обоих случаях всё упирается в диск и там просто нечего оптимизировать. А можно даже найти сценарий, когда операции над журналом опустят производительность ехт4 ниже ехт2.

Надо выбирать самое новое ядро, в котором всё железо хорошо работает. Сначала подержку железа улучшают, а через 5-10 лет а него забивают и работа начинает ухудшаться. Где то есть оптимальный пик.

А где то есть требования, что вот для этого софта нужен вот тот софт, а он только на ядрах не ниже х.х.х, так что возможно придётся ставить неоптимальное ядро и мириться с ним.

для поддержки новых устройств, при сохранении обратной совместимости с устройствами старыми, новых файловых систем, сетевых протоколов, и так далее. Что столь же неизбежно ведет к разрастанию ядра, расходу памяти и падению быстродействия

Глупости пишет человек. Если поддержка нового устройста сделана компилируется в модуль, который при отсутствии этого устройства не загружается, то на расход памяти и быстродействие тупо наличие файла на диске никак не влияет. Размер (на диске, или в строках кода) — да, пухнет. Ну и компилять дольше, если сам собираешь, но почему-то ненужные модули не отключил. А так нет, это не влияет.

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

В общем и целом, всё как минимум значительно сложнее, нежели такие странные заявления.

и как узнать какое ядро самое старое поддерживает моё железо?

Если ограничиться поддерживаемыми (я думаю что это с патчами безопасности), то вот тут можно выбрать по дате окончания поддержки.
https://kernel.org/category/releases.html
А по поддержке конкретного железа - пробовать на практике.

с каждой новой версией ядра пенсия все ближе

расход памяти не всегда означает падение быстродействия

журналом

отключается

это только если до неё доживёшь

А вот вопрос, с помощью mitigations=off, можно быть уверенным, что никакая из этих замедляющих защит не прокрадется ко мне на комп? Или надо ещё и релизы прошивок матерной платы проверять на то что они там втихаря не добавят чего для моей безопасности?

PS: Да-да, я неуловимый Джо и никто такими сложными способами мой домашний комп ломать не будет.

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

можешь пересобрать ядро, все эти защиты можно вырезать полностью

можешь пересобрать ядро, все эти защиты можно вырезать полностью

Где-то писали, что некоторые защиты в фирмварь процессорную добавлены были в линуксе, а свежая фирмварь, как я понимаю, может быть либо подгружена ядром, либо прилететь с новой прошивкой UEFI. Я вот второго варианта побаиваться начал и больше UEFI не обновляю.

...после чего ехт4 превращается в ехт2.

4.2

Словно ядро какой-то значимый процент производительности жрёт... Хорошо если 1% туда-сюда колеблется в зависимости от планировщика и оптимизаций низкоуровневого кода вроде открытия файлов на чтение/запись и т.д.. Все лаги в конечном софте и долгом старте jwm (если софт на java).

И под каким микроскопом ты предлагаешь разглядывать разницу? Особенно после того, как ехт2 примонтирована драйвером ехт4, как делают все ядра уже лет 5 или даже 10.

Алексей Федорчук

а кто это такой? Я вот как специалистов мирового уровня по юниксам и линуксу слышал про Эви Неммет (пропала в море в 2013 году на яхте, с вероятностью 99.9% утонула вместе с яхтой в шторм), ну а из живых Таненбаум Эндрю (автор minix-а, но в первую очередь преподаватель в университете и автор некоторых заумных книжек про компьютеры на почти любую тематику - от криптографии и ИБ до устройства компьютеров). Конечно, есть ещё человек 20 живых, к чьему мнению стоит прислушиваться и кому более-менее можно доверять на слово, но ни одного не англоязычного челика такого уровня я не знаю.

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

Ну чтоб обрушить это баг надо внести хороший. Так-то ядро вылизано сильно. Не сидите на dev версии ядра и проблем не будет в основном.

Ну почему, роняем таймер прерываний с 1000+ Гц до 100 и мелко фризить начинает ВСЁ. Или некорректная настройка на cgrops может сделать нечто нехорошее. Или защита от новогодних подарков. Или в 6.1 на говеноры мегапатчи накладывали, а оно оказалось иногда странно себя ведёт и реально роняет производительность на 10-20-30%. Или асиметричные цпу...

А уж pf-sorces вообще был легендарным тестом экстрасенсорных способностей.

все еще хуже: можно планомерно конвертировать фс ext2 -> ext3 -> ext4 и обратно, при этом вполне сохраняя жизнеспособность файлов на них :)
потому собственно и драйвер один на всех. каждая последующая ext* является расширением предыдущей.

разницу

Индекс директорий, чексуммы метаданных, экстенты, кластеры, упаковка данных в иноды и тд.

примонтирована драйвером ехт4

Всё равно не работает как полноценная ext4.

роняем таймер прерываний с 1000+ Гц до 100 и мелко фризить начинает ВСЁ

4.2

Введение в POSIX’ивизм (C) Алексей Федорчук, 2005

Кто о чем, а русским лишь бы про *изм..

роняем таймер прерываний с 1000+ Гц до 100 и мелко фризить начинает ВСЁ

Да вообще-то живу со 100 Гц уже лет дцать - и не фризит вообще ничего. Даже когда в фоне сфежий фокс компилируется

Всё равно не работает как полноценная ext4.

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