LINUX.ORG.RU

Linux 6.1

 , ,

Linux 6.1

3

5

Линус Торвальдс после двух месяцев разработки выпустил стабильную версию ядра Linux версии 6.1.

В новой мажорной версии ядра с кодовым названием «Hurr durr I’ma ninja sloth» представлена экспериментальная (но пока очень базовая и неприменимая в реальных случаях использования) поддержка языка программирования Rust для разработки модулей и драйверов.

Следующим очень важным изменением является замена «старой» реализации LRU на MGLRU (Multi-Generational LRU) — альтернативную реализацию LRU, которая оптимизирует возврат страниц и повышает производительность при нехватке памяти.

AMD IOMMU v2 теперь работает как часть виртуализации IOMMU с аппаратной поддержкой AMD vIOMMU (EPYC 7002 «Rome» и новее)

Также в эту версию ядра добавили AMD Platform Management Framework (PMF), который представляет централизованную структуру, позволяющую на основе информации с датчиков и различных метрик динамически управлять производительностью, питанием и температурными параметрами системы.

Исправлены ошибки в драйвере amd-pstate, поправлена некорректная работа s2idle на мобильной платформе AMD Rembrandt.

Продолжается добавление поддержки для видеокарт Intel Meteor Lake, Intel Arc, AMD RDNA3, а также исправления для AMD RDNA2.

В области файловых систем проведена значительная оптимизация производительности Btrfs. Кроме этого, Ted Ts’o исправил некоторые ошибки и немного оптимизировал производительность в EXT4.

Добавлен Kernel Memory Sanitizer (KMSAN) для диагностики проблем с памятью.

Производится подготовка сетевой подсистемы ядра к грядущим стандартам WiFi 7 и 802.11be.

Окончательно удалена поддержка a.out.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 4)

Ответ на: комментарий от unsigned

там их полно типа: fsanitize=address, fsanitize=undefined, fno-sanitize-recover и т.д.

Да что там опции на варнинги даже плюют.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

fsanitize=address, fsanitize=undefined, fno-sanitize-recover и т.д.

Статический анализ кода, Динамический анализ кода. Это не «точно такая же безопасная работа с памятью».

варнинги

Эвристики. С ошибками памяти почти беспомощные.

Полная верификация работы с памятью в C принципиально невозможна. Максимум - можно попытаться расширить язык аннотациями, Саттер что-то подобное для плюсов показывал на уровне POC. Но дальше пока не идет. А у rust - идет.

unsigned ★★★★
()
Ответ на: комментарий от sniper21

При этом памяти стало жрать в 3 раза больше.

Не в три раза больше, а на 3*(размер таблицы символов ядра), т.е. вообще незначительно.

Zombieff ★★
()
Ответ на: комментарий от unsigned

Но дальше пока не идет

https://github.com/hsutter/cppfront/commits/main: hsutter committed 10 hours ago

Можно даже на обычных плюсах писать и прикрутить проверки с помощью cppfront. Так что не в синтаксисе дело, а в компиляторе и процессоре.

luke ★★★★★
()
Ответ на: комментарий от luke

This compiler is a work in progress and currently hilariously incomplete… basic functions work, classes will be next

Я бы вот это тоже не ставил далеко от POC в ранней стадии. Не, здорово что продолжают пилить, буду только рад если оно выйдет в продакшн. Но вряд ли скоро, если вообще. Ну и кернелу это еще на C надо перенести.

unsigned ★★★★
()

Чёт Манджаровский установщик ядер, именно эту версию ставит только ядро, пришлось устанавливать модуль для вирталбокса и драйвера нвидия в ручную.

Как будто Манджара резко стала неудобным Арчем. Может это из-за testing branch, кто знает?

LibAccelerator
()
Ответ на: комментарий от unsigned

Ну и кернелу это еще на C надо перенести.

В ведре софтверные проверки могут очень дорого стоить. Впрочем, для i386 всё ещё есть сегменты, но их банально не хватит на всё, да и они медленные, хоть и хардверные.

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

luke ★★★★★
()
Ответ на: комментарий от einhander

Ждать, скорее всего, надо amd-pstate-epp. Но когда он заедет в апстрим - это прямо непонятно, Перри Юань печет новые версии патчсета как пирожки. Я попытаюсь на днях собрать 6.1 с актуальным патчсетом.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

И это тоже ждём. Но где-то в 6.0 сломали энергопотребление, оно выросло на 0.5-1 Вт при прочих равных. По powertop так и не отловил причину.

einhander ★★★★★
()
Ответ на: комментарий от Meyer

А если осилил оба (С и Rust) и обнаружил что Rust, как инструмент, лучше чем С?

trex6 ★★★★★
()
Ответ на: комментарий от Psilocybe

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

Вы восполнили этот пробел. Свяжитесь с нами в ЛС для получения наградного листа и статуэтки.

trex6 ★★★★★
()
Последнее исправление: trex6 (всего исправлений: 1)
Ответ на: комментарий от x86_64

Большую часть с исходниками не продают.

Ну, то есть, Rust не только позволит наконец избавиться от C, но и нагибает проприетарщиков. Сплошная радость и счастье!

hateyoufeel ★★★★★
()
Ответ на: комментарий от trex6

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

Psilocybe ★★★★
()
Ответ на: комментарий от hateyoufeel

Ну, то есть, Rust не только позволит наконец избавиться от C, но и нагибает проприетарщиков. Сплошная радость и счастье!

Ну все как обычно. Все скатывается в сплошное УГ.

Кстати вот к радости растаманов: https://www.opennet.ru/opennews/art.shtml?num=58333

Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок. 

оценку корректности доступа к памяти во время выполнения кода.

Интересно как это понимать ? Проги на rust всегда будут медленее чем с/c++ ?

mx__ ★★★★★
()

Узнал про gccrs.

CYB3R ★★★★★
()
Ответ на: комментарий от Psilocybe

Ну если состоялся переход на личности, значит я был прав

Но это так не работает :)

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

intelfx ★★★★★
()
Ответ на: комментарий от thesis

Малыши не пишут на PHP. На нем пишут как раз мерзкие старые ретрограды.

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

ST
()
Ответ на: комментарий от luke

Причём, я бы на паре Си–Раст не зацикливался: у нас в физике в последнее время идёт постоянная ругань на плюсы и агитация за питон, в основном от постдоков и молодых профессоров.

Ткачева на вас нет! :) никак не осознаете что оберон серебряная пуля, вращаете его в гробу почем зря, выбирая всякую переусложненную попсню, вместо less is more :)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от mx__

Из указанного фрагмента следует, что проги на раст всегда будут компилироваться медленнее, чем аналогичные программы на C.

О том как можно замедлить компиляцию программ на C++ знает каждый, кто хоть раз пользовался Boost Spirit с хоть сколько-нибудь нетривиальной грамматикой :)

AlexM ★★★★★
()
Ответ на: комментарий от Mischutka

Риторический вопрос: когда ядро версии 6.x появится в Astra Linux?

Риторический ответ. Те кому положено об этом думать и знать подумают об этом когда положено. Вам об этом думать и знать не положено. Вы видимо так и не поняли всей прелести дистрибутивов типа Астры. Вам больше не нужно задаваться подобными вопросами. Вам нужно терпеть, ждать и приспосабливаться, особенно если вы не платите. Если вы платите — вы можете принять участие в официальном коммуникативном процессе, что позволит развлечься написанием запросов и чтением ответов в процессе ожидания и терпения.

Напоминаю: «родился, потерпел, умер». И никак иначе.

Jameson ★★★★★
()
Ответ на: комментарий от unsigned

В cppfront разве рантайм-проверки?

Да. По умолчанию выключены, но можно включить.

luke ★★★★★
()

А вообще 6.1 ядро нехорошее, промежуточное. Вот 6.2 будет ядром хорошим и важным, там всё будет в кайф, в него наконец то войдёт то что в него войдёт.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от luke

systemd?

Кто в курсе — тот в курсе, кто знает — тот знает. Вообще не стоило вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я вполне понимаю, что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых - стоп. Остальные просто не найдут.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Вам нужно терпеть, ждать и приспосабливаться.

Надо же, я только после прочтения этих слов осознал, чем занимаюсь всю свою жизнь, а ещё верю и надеюсь.

Mischutka ★★★★★
()
Ответ на: комментарий от Mischutka

а ещё верю и надеюсь.

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

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Каким ещё социумом? В Священном Писании сказано:

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

(Послание к римлянам, глава 5 стихи 3-5)

Mischutka ★★★★★
()
Ответ на: комментарий от no-such-file

Просто про него все забыли, а потом в какой-то момент вспомнили и все по очереди решили выкинуть. Речь заходила в Linux 5.1, GCC, bin-utils. От формата остались лишь только рожки, в виде имени файла.

А за одно и выкинули другое старьё для PDP-11 DECNet. Неужели кто-то собирался запускать Linux на PDP-* машинах.

fuggy
()
Ответ на: комментарий от EXL

то есть rust compiler более доверяем чем gcc? только в малоответственных задачах.. ну или безответственных. когда за ошибку не посадят.

mke61
()
Ответ на: комментарий от mx__

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

AlexM ★★★★★
()
Ответ на: комментарий от einhander

У меня на 5800U тоже подросло. Причём, после просыпания, пожалуй, даже побольше (иногда) бывает. В общем, буду пробовать новое ядро и amd-pstate-epp

AlexM ★★★★★
()

Вопрос дилетанта. А как люди рубящие а в rust будут писать куски на asm? Или у них скил непостижим и уже могут сразу?

hbars ★★★★★
()
Ответ на: комментарий от ValdikSS

Наконец-то теперь можно vpn поднять на vps с alpine linux со 128 мегабайтоми оперативной памяти… Или даже lxd туда поставить или даже qemu

ne-vlezay ★★★★★
()

Прогресс большой. Линуса - с НГ и респект!

Vinni_Pooh ★★★★★
()
Ответ на: комментарий от hbars

А что, люди, пишушие на Си, все вставки на asm писать могут? Или у них скил непостижим и уже могут сразу?

Ей господи, как про роботов про людей говоришь.

GFORGX ★★★
()
Ответ на: комментарий от fuggy

Очередной лоровский игзперд — не видит разницы между поддержкой сетевого протокола и «запуском на машине».

alegz ★★★★
()

В следующей мажорной версии ядра с кодовым названием «Uhmm hm UwU I’ma cute femboy <3» Линус Торвальдс представит полный пакет GNU, переписанный на Rust.

Следующим очень важным изменением является замена «старой» реализации LGBT на LGBTQBPABCDEFG++

Исправлены ошибки в драйвере amd-prostata

JhonatanSore
()
Ответ на: комментарий от JhonatanSore

Исправлены ошибки в драйвере amd-prostata

Наконец-то начали использовать CoC по назначению.

rupert ★★★★★
()
Ответ на: комментарий от einhander

Сам ещё не смотрел, но гр.linrunner уже собрал ядро с патчем v.7 и обновил TLP.

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

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от mx__

раст медленнее, если ты пользуешься индексом при обращении к массиву, т.е. for loop и my_vec[index] всегда проверяется на границы

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

swar0g ★★★★
()
Последнее исправление: swar0g (всего исправлений: 1)
Ответ на: комментарий от Original_1

Судя по всему, rust в для ядра линукс должен дать большую безопасность. На си пишут 40 лет. От ошибок по управлению памятью до сих не научились автоматически избавляться. Десятки миллионов кодов строк + си = ошибки управления памятью всегда. У си - полный контроль и максимальная скорость бинарного результата. На этом все преимущества заканчиваются. Конечно мне совсем не хотелось бы что бы ядра ос скатились в итоге то тормозных всяких языков-систем, в крайности, что бы ядро не писалось на питоне. Потому, что чем разработчикам быстрей что-то сделать - чем жручее и жручее становится такой софт, вырождаясь в bloatware. А уж что бы это постигло ядро линукса, уж совсем не хочется. Но оно уже настолько сложное, что если его часть не собирать с другим компилятором и языком, более умным, то кол-во ошибок в какой то точке времени начнет расти в геометрической прогрессии.

BuzzerOFF
()
Ответ на: комментарий от BydymTydym

Хорошо бы еще, чтобы в него не вошло то, что не войдет.

Именно так и будет

Jameson ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.