Зацените сборку. Запускается на Macbook Air M1 с помощью ALARM (Arch Linux для ARM) на Asahi.
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
✍27❤5🎉4💔2👍1
Представлена бета-версия Fedora Linux 44, финальный релиз ожидается 14 апреля
Воспроизводимые сборки доведены до 99% пакетов. Это значит, что пользователи теперь могут лично убедиться, что бинарники в репозитории собраны именно из того исходного кода, который заявлен, и не содержат скрытых изменений.
В редакциях с KDE произошли серьёзные перемены: SDDM заменён на новый Plasma Login Manager от KDE, а для начальной настройки после установки задействован Plasma Setup. GNOME обновлён до версии 50 (прощай, X11), Budgie переехал на 10.10 с Wayland. Fedora Games Lab переработали с учётом современных технологий (Wayland, PipeWire).
В ядре по умолчанию активировали модуль ntsync - это символьное устройство для синхронизации NT-примитивов, которое должно серьёзно ускорить Windows-игры под Wine за счёт ухода от накладных RPC-вызовов.
Из нового софта: GCC 16.1, LLVM 22, Ruby 4.0, Go 1.26, glibc 2.43, MariaDB 11.8, uutils-coreutils 0.5 (Rust-версия), nushell 0.109.2. В репозиторий добавили пакетный менеджер NIX, которым теперь можно ставить пакеты из nixpkgs прямо в Fedora.
Параллельно в сообществе обсуждают инициативу по созданию песочницы для экспериментов, чтобы новые технологии можно было обкатывать, не ломая стабильность основного дистрибутива.
Linux / Линукс🥸
Воспроизводимые сборки доведены до 99% пакетов. Это значит, что пользователи теперь могут лично убедиться, что бинарники в репозитории собраны именно из того исходного кода, который заявлен, и не содержат скрытых изменений.
В редакциях с KDE произошли серьёзные перемены: SDDM заменён на новый Plasma Login Manager от KDE, а для начальной настройки после установки задействован Plasma Setup. GNOME обновлён до версии 50 (прощай, X11), Budgie переехал на 10.10 с Wayland. Fedora Games Lab переработали с учётом современных технологий (Wayland, PipeWire).
В ядре по умолчанию активировали модуль ntsync - это символьное устройство для синхронизации NT-примитивов, которое должно серьёзно ускорить Windows-игры под Wine за счёт ухода от накладных RPC-вызовов.
Из нового софта: GCC 16.1, LLVM 22, Ruby 4.0, Go 1.26, glibc 2.43, MariaDB 11.8, uutils-coreutils 0.5 (Rust-версия), nushell 0.109.2. В репозиторий добавили пакетный менеджер NIX, которым теперь можно ставить пакеты из nixpkgs прямо в Fedora.
Параллельно в сообществе обсуждают инициативу по созданию песочницы для экспериментов, чтобы новые технологии можно было обкатывать, не ломая стабильность основного дистрибутива.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣85💔6🔥2😁2✍1
Инженер из SUSE предложил патчи для ядра Linux 7.1, которые убирают возможность собирать стек IPv6 как модуль ядра
Останется только два варианта: либо IPv6 встроен в ядро намертво (CONFIG_IPV6=y), либо выключен полностью (CONFIG_IPV6=n). Промежуточный вариант с модулем (CONFIG_IPV6=m) существовал по чисто историческим причинам, и в реальности им никто не пользуется. Современные дистрибутивы давно либо вкомпиливают IPv6 в ядро, либо отрубают его целиком.
Причина в том, что когда IPv6 собран модулем, то куча подсистем (сетевой стек, BPF, Netfilter, отдельные драйверы) вынуждены тащить на себе обработчики выгрузки этого модуля. Код, который никто не вызывает, но который нужно поддерживать, тестировать и не ломать при каждом обновлении. Классическая ситуация, когда легаси-опция, написанная когда-то на всякий случай, годами усложняет жизнь мейнтейнерам ради нуля пользователей.
Никто не пострадает, зато кодовая база станет чище. Хотя наверняка где-нибудь найдётся человек, который собирал IPv6 модулем на своём самосборном NAS из 2009 года, и для него это будет личная трагедия...
Linux / Линукс🥸
Останется только два варианта: либо IPv6 встроен в ядро намертво (CONFIG_IPV6=y), либо выключен полностью (CONFIG_IPV6=n). Промежуточный вариант с модулем (CONFIG_IPV6=m) существовал по чисто историческим причинам, и в реальности им никто не пользуется. Современные дистрибутивы давно либо вкомпиливают IPv6 в ядро, либо отрубают его целиком.
Причина в том, что когда IPv6 собран модулем, то куча подсистем (сетевой стек, BPF, Netfilter, отдельные драйверы) вынуждены тащить на себе обработчики выгрузки этого модуля. Код, который никто не вызывает, но который нужно поддерживать, тестировать и не ломать при каждом обновлении. Классическая ситуация, когда легаси-опция, написанная когда-то на всякий случай, годами усложняет жизнь мейнтейнерам ради нуля пользователей.
Никто не пострадает, зато кодовая база станет чище. Хотя наверняка где-нибудь найдётся человек, который собирал IPv6 модулем на своём самосборном NAS из 2009 года, и для него это будет личная трагедия...
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
👍30🌚2
Современные методы подбора персонала ни к чему не приводят. Практическая оценка, подобная этой, звучит лучше. Что вы думаете?
Linux / Линукс🥸
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23😁9💯6🫡3
Google включила AutoFDO в ядре Android и ускорила системные вызовы на 20%
Компания подвела итоги внедрения оптимизации AutoFDO (профильная оптимизация на основе сэмплов) при сборке ядра Linux для Android. Технология использует данные профилирования, собранные при запуске 100 популярных приложений, чтобы компилятор эффективнее расставлял горячие участки кода.
Раньше AutoFDO применяли только для userspace-компонентов (библиотеки, исполняемые файлы), где оно дало +4% к скорости запуска и -1% времени загрузки. Но 40% процессорного времени в Android тратится на ядро, поэтому там и решили попробовать.
Результаты оказались таковы: время загрузки сократилось на 2.1%, первый запуск приложений ускорился на 4.3%, системные вызовы стали быстрее на 9.3%, а Binder-транзакции на 12-22% в зависимости от типа. Оптимизация уже включена в ядро 6.12 для Android 16 и 6.6 для Android 15, в 6.18 для Android 17 тоже будет.
Linux / Линукс🥸
Компания подвела итоги внедрения оптимизации AutoFDO (профильная оптимизация на основе сэмплов) при сборке ядра Linux для Android. Технология использует данные профилирования, собранные при запуске 100 популярных приложений, чтобы компилятор эффективнее расставлял горячие участки кода.
Раньше AutoFDO применяли только для userspace-компонентов (библиотеки, исполняемые файлы), где оно дало +4% к скорости запуска и -1% времени загрузки. Но 40% процессорного времени в Android тратится на ядро, поэтому там и решили попробовать.
Результаты оказались таковы: время загрузки сократилось на 2.1%, первый запуск приложений ускорился на 4.3%, системные вызовы стали быстрее на 9.3%, а Binder-транзакции на 12-22% в зависимости от типа. Оптимизация уже включена в ядро 6.12 для Android 16 и 6.6 для Android 15, в 6.18 для Android 17 тоже будет.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍4🎄3
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12😎7🔥2😈2
Debian не смог договориться, как относиться к коду от ИИ, в итоге голосование отменили
В феврале в Debian попытались принять общую резолюцию, регулирующую приём вкладов, созданных с помощью ИИ. Инициатор Лукас Нуссбаум предлагал разрешить AI-генерируемый код при условии явной маркировки, полного понимания материала автором и запрета на загрузку чувствительных данных проекта в публичные модели.
Однако дискуссия быстро увязла в терминологии: одни требовали чётко разделять LLM, RL и «собственно AI», другие настаивали на этической оценке (воровство контента, экология, фейковые отчёты). Подняли и вопрос адаптации новичков: если новичок просто пересылает сгенерированный код, он не учится, а проект тратит время на ревью.
Противники жёстких запретов указывали, что под раздачу могут попасть ядро Linux, Python, LLVM, если следовать логике «AI-код вне основного архива». В итоге консенсус не сложился, и резолюцию решили не выносить на голосование.
Debian присоединился к длинному списку проектов, которые пока не знают, что делать с AI-вкладами. В отличие от Fedora (разрешили с человеческим контролем) или GNOME Shell (запретили дополнения от AI), Debian оставил вопрос открытым.
Linux / Линукс🥸
В феврале в Debian попытались принять общую резолюцию, регулирующую приём вкладов, созданных с помощью ИИ. Инициатор Лукас Нуссбаум предлагал разрешить AI-генерируемый код при условии явной маркировки, полного понимания материала автором и запрета на загрузку чувствительных данных проекта в публичные модели.
Однако дискуссия быстро увязла в терминологии: одни требовали чётко разделять LLM, RL и «собственно AI», другие настаивали на этической оценке (воровство контента, экология, фейковые отчёты). Подняли и вопрос адаптации новичков: если новичок просто пересылает сгенерированный код, он не учится, а проект тратит время на ревью.
Противники жёстких запретов указывали, что под раздачу могут попасть ядро Linux, Python, LLVM, если следовать логике «AI-код вне основного архива». В итоге консенсус не сложился, и резолюцию решили не выносить на голосование.
Debian присоединился к длинному списку проектов, которые пока не знают, что делать с AI-вкладами. В отличие от Fedora (разрешили с человеческим контролем) или GNOME Shell (запретили дополнения от AI), Debian оставил вопрос открытым.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣23🤔7😢2
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣30💯3😎3🤔2
TrueNAS убрал публичную систему сборки с GitHub, и сообщество забеспокоилось о прозрачности
Разработчики TrueNAS перенесли инфраструктуру сборки во внутренние системы и заархивировали соответствующий репозиторий на GitHub. Формальная причина в требованиях безопасности, включая поддержку Secure Boot и контроль над подписью образов. Позже упоминание Secure Boot из описания убрали, но репозиторий остался в режиме read-only.
В сообществе возникли вопросы: если многие дистрибутивы умудряются держать открытые сборочные инструменты, сохраняя закрытой только подпись, почему TrueNAS пошёл другим путём? Пользователи опасаются, что без публичного конвейера сложнее проверить, соответствуют ли бинарные релизы исходному коду.
Сотрудник iXsystems объяснил, что поддержка двух параллельных систем сборки (публичной и внутренней) - это двойная работа, а 99% комментаторов всё равно никогда не собирали TrueNAS из исходников. Самые активные пользователи публичной сборки, по его словам, - зарубежные форки, которые не вносят ничего обратно в проект.
Исходный код самого TrueNAS (Debian, OpenZFS и пр.) остаётся открытым под GPL3, так что формально требования лицензии соблюдены. Но для энтузиастов, привыкших к полной прозрачности, это тревожный сигнал.
Linux / Линукс🥸
Разработчики TrueNAS перенесли инфраструктуру сборки во внутренние системы и заархивировали соответствующий репозиторий на GitHub. Формальная причина в требованиях безопасности, включая поддержку Secure Boot и контроль над подписью образов. Позже упоминание Secure Boot из описания убрали, но репозиторий остался в режиме read-only.
В сообществе возникли вопросы: если многие дистрибутивы умудряются держать открытые сборочные инструменты, сохраняя закрытой только подпись, почему TrueNAS пошёл другим путём? Пользователи опасаются, что без публичного конвейера сложнее проверить, соответствуют ли бинарные релизы исходному коду.
Сотрудник iXsystems объяснил, что поддержка двух параллельных систем сборки (публичной и внутренней) - это двойная работа, а 99% комментаторов всё равно никогда не собирали TrueNAS из исходников. Самые активные пользователи публичной сборки, по его словам, - зарубежные форки, которые не вносят ничего обратно в проект.
Исходный код самого TrueNAS (Debian, OpenZFS и пр.) остаётся открытым под GPL3, так что формально требования лицензии соблюдены. Но для энтузиастов, привыкших к полной прозрачности, это тревожный сигнал.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔20👍3