В Pingora нашли критические дыры, позволяющие воровать чужие запросы
Cloudflare закрыла три уязвимости в своём фреймворке Pingora (на Rust), две из которых получили критический статус (9.3/10). Проблемы позволяли проводить атаки HTTP Request Smuggling — вклиниваться в трафик других пользователей и подменять содержимое страниц.
Первая уязвимость (CVE-2026-2835) возникала из-за кривой обработки заголовка Transfer-Encoding с несколькими значениями. Pingora игнорировал его и считал телом запроса всё подряд до закрытия соединения. Атакующий мог отправить один запрос, а бэкенд (например, Node.js) видел два — второй воровал данные из чужой сессии.
Вторая проблема (CVE-2026-2833) касалась заголовка Upgrade. Pingora сразу отправлял данные вслед за ним на бэкенд, не дожидаясь ответа 101 Switching Protocols. Это ломало синхронизацию — бэкенд воспринимал остаток данных как отдельный запрос и возвращал результат другому пользователю.
Третья уязвимость (CVE-2026-2836, 8.4) позволяла отравить кэш: ключ кэширования строился только по пути URI, игнорируя Host. Из-за этого для разных хостов с одинаковым путём выдавался один и тот же кэшированный ответ.
В CDN Cloudflare проблемы не эксплуатировались из-за особенностей конфигурации, но в других инсталляциях они были опасны. Все дыры закрыли в выпуске Pingora 0.8.0.
Linux / Линукс🥸
Cloudflare закрыла три уязвимости в своём фреймворке Pingora (на Rust), две из которых получили критический статус (9.3/10). Проблемы позволяли проводить атаки HTTP Request Smuggling — вклиниваться в трафик других пользователей и подменять содержимое страниц.
Первая уязвимость (CVE-2026-2835) возникала из-за кривой обработки заголовка Transfer-Encoding с несколькими значениями. Pingora игнорировал его и считал телом запроса всё подряд до закрытия соединения. Атакующий мог отправить один запрос, а бэкенд (например, Node.js) видел два — второй воровал данные из чужой сессии.
Вторая проблема (CVE-2026-2833) касалась заголовка Upgrade. Pingora сразу отправлял данные вслед за ним на бэкенд, не дожидаясь ответа 101 Switching Protocols. Это ломало синхронизацию — бэкенд воспринимал остаток данных как отдельный запрос и возвращал результат другому пользователю.
Третья уязвимость (CVE-2026-2836, 8.4) позволяла отравить кэш: ключ кэширования строился только по пути URI, игнорируя Host. Из-за этого для разных хостов с одинаковым путём выдавался один и тот же кэшированный ответ.
В CDN Cloudflare проблемы не эксплуатировались из-за особенностей конфигурации, но в других инсталляциях они были опасны. Все дыры закрыли в выпуске Pingora 0.8.0.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
😁12❤2👍2
nginx 1.29.6 научился привязывать клиентов к серверам через куки и анализ ответов
Вышла новая основная ветка nginx 1.29.6, которая в будущем превратится в стабильную 1.30. Главное новшество — поддержка привязки (sticky) сеансов клиентов к конкретным серверам в upstream-группе.
Добавили три метода: cookie (данные о сервере передаются через куку), route (сервер сам назначает маршрут при первом запросе) и learn (nginx анализирует ответы от бэкендов и запоминает, какой сервер обслуживал сеанс). Для настройки в блоке upstream появилась директива sticky, а у server добавили параметры route и drain.
Остальные изменения традиционно мелкие — закрыли несколько багов и улучшили совместимость.
Linux / Линукс🥸
Вышла новая основная ветка nginx 1.29.6, которая в будущем превратится в стабильную 1.30. Главное новшество — поддержка привязки (sticky) сеансов клиентов к конкретным серверам в upstream-группе.
Добавили три метода: cookie (данные о сервере передаются через куку), route (сервер сам назначает маршрут при первом запросе) и learn (nginx анализирует ответы от бэкендов и запоминает, какой сервер обслуживал сеанс). Для настройки в блоке upstream появилась директива sticky, а у server добавили параметры route и drain.
Остальные изменения традиционно мелкие — закрыли несколько багов и улучшили совместимость.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
Release release-1.29.6 · nginx/nginx
release-1.29.6 tag
👍11🔥3❤2🤔2
📘 На Stepik вышел курс — «DevSecOps»
ИИ-инструменты, облака, автоматизация — всё это стало стандартом. И ровно поэтому защита инфраструктуры стала не опцией, а необходимостью. DevSecOps — навык, который всё чаще требуют от инженеров любого профиля. Глубоких знаний в ИБ не требуется — всё нужное объясняется прямо в процессе.
• Docker, Kubernetes — безопасная сборка, политики доступа, аудит образов
• SAST, DAST, SCA — анализ кода и сканирование зависимостей на CVE в пайплайне
• CI/CD с security-gates — проверки безопасности на каждом этапе деплоя
• SIEM, ELK — мониторинг, корреляция событий, реагирование на инциденты
• Управление секретами, IaC, защита API и фаерволы
• Финальный проект: end-to-end DevSecOps-инфраструктура с документацией — в портфолио или как база для продакшена
🎓 Сертификат по завершении — добавьте в резюме или LinkedIn
🚀 Скидка 25% — действует 48 часов
👉 Пройти курс на Stepik
ИИ-инструменты, облака, автоматизация — всё это стало стандартом. И ровно поэтому защита инфраструктуры стала не опцией, а необходимостью. DevSecOps — навык, который всё чаще требуют от инженеров любого профиля. Глубоких знаний в ИБ не требуется — всё нужное объясняется прямо в процессе.
• Docker, Kubernetes — безопасная сборка, политики доступа, аудит образов
• SAST, DAST, SCA — анализ кода и сканирование зависимостей на CVE в пайплайне
• CI/CD с security-gates — проверки безопасности на каждом этапе деплоя
• SIEM, ELK — мониторинг, корреляция событий, реагирование на инциденты
• Управление секретами, IaC, защита API и фаерволы
• Финальный проект: end-to-end DevSecOps-инфраструктура с документацией — в портфолио или как база для продакшена
🎓 Сертификат по завершении — добавьте в резюме или LinkedIn
🚀 Скидка 25% — действует 48 часов
👉 Пройти курс на Stepik
👍4❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
🌚20😁8💯5
Please open Telegram to view this post
VIEW IN TELEGRAM
💯48🌚9😁4
SUSE снова готовят к продаже
Инвестиционная корпорация EQT, владеющая SUSE с 2018 года, начала переговоры о продаже компании. Пока это ранняя стадия, и сделка может не состояться, а ожидаемая сумма от 4 до 6 миллиардов долларов.
Текущая выручка SUSE около 800 миллионов в год, прибыль до вычета налогов - 250 миллионов. Несмотря на общую нервозность IT-рынка из-за ИИ-бума, покупка SUSE выглядит привлекательно: инфраструктурное ПО нужно всегда, особенно на фоне роста ИИ-нагрузок.
История продаж SUSE богата: в 2003 её купила Novell за $210 млн, потом Attachmate Group ($2.2 млрд), затем Micro Focus, а в 2018 EQT выкупила бизнес за $2.5 млрд. В 2021 компания выходила на биржу, но в 2023 EQT снова сделала её частной, оценив в $2.96 млрд. Теперь ценник вырос минимум вдвое.
Linux / Линукс🥸
Инвестиционная корпорация EQT, владеющая SUSE с 2018 года, начала переговоры о продаже компании. Пока это ранняя стадия, и сделка может не состояться, а ожидаемая сумма от 4 до 6 миллиардов долларов.
Текущая выручка SUSE около 800 миллионов в год, прибыль до вычета налогов - 250 миллионов. Несмотря на общую нервозность IT-рынка из-за ИИ-бума, покупка SUSE выглядит привлекательно: инфраструктурное ПО нужно всегда, особенно на фоне роста ИИ-нагрузок.
История продаж SUSE богата: в 2003 её купила Novell за $210 млн, потом Attachmate Group ($2.2 млрд), затем Micro Focus, а в 2018 EQT выкупила бизнес за $2.5 млрд. В 2021 компания выходила на биржу, но в 2023 EQT снова сделала её частной, оценив в $2.96 млрд. Теперь ценник вырос минимум вдвое.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
🫡15🌚3🤣3😢2
PostgreSQL и секционирование: «разделяй и властвуй!». Бесплатный урок курса «PostgreSQL для администраторов баз данных и разработчиков»
Большие таблицы в PostgreSQL сначала «просто растут», а потом внезапно начинают убивать всё вокруг: запросы тормозят, вакуум длится вечность, обслуживание превращается в боль, а любой релиз страшно трогать. Секционирование — один из немногих инструментов, который реально помогает вернуть управляемость и скорость, если применять его правильно.
📅 На открытом уроке 16 марта (пн) в 20:00:
— Разберём, зачем вообще нужно секционирование и какие проблемы больших таблиц оно решает.
— Пройдёмся по основным видам секционирования в PostgreSQL: по списку значений, по диапазону и по хэшу.
— Отдельно разберём декларативный подход, как современный способ секционирования: синтаксис, создание и обслуживание секций, добавление и удаление, а также сравнение со старым методом через наследование.
— В конце — лучшие практики и частые ошибки, из-за которых секционирование «не взлетает».
👉 Записаться: https://otus.ru/lessons/postgresql-dba
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
Большие таблицы в PostgreSQL сначала «просто растут», а потом внезапно начинают убивать всё вокруг: запросы тормозят, вакуум длится вечность, обслуживание превращается в боль, а любой релиз страшно трогать. Секционирование — один из немногих инструментов, который реально помогает вернуть управляемость и скорость, если применять его правильно.
📅 На открытом уроке 16 марта (пн) в 20:00:
— Разберём, зачем вообще нужно секционирование и какие проблемы больших таблиц оно решает.
— Пройдёмся по основным видам секционирования в PostgreSQL: по списку значений, по диапазону и по хэшу.
— Отдельно разберём декларативный подход, как современный способ секционирования: синтаксис, создание и обслуживание секций, добавление и удаление, а также сравнение со старым методом через наследование.
— В конце — лучшие практики и частые ошибки, из-за которых секционирование «не взлетает».
Урок не для тех, кто ищет одну универсальную схему «на все случаи», хочет «ускорить всё одним движением» и не готов менять модель данных и запросы под реальную нагрузку.
👉 Записаться: https://otus.ru/lessons/postgresql-dba
Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576
❤3
Oracle выпустила бесплатный Solaris 11.4.90 CBE с непрерывными обновлениями
Компания представила третий выпуск своей редакции Solaris CBE (Common Build Environment), предназначенной для разработчиков и персонального использования. В отличие от обычных сборок Solaris 11.4, которые можно бесплатно применять для тестирования и личных проектов, CBE использует непрерывную модель публикации обновлений (rolling) и включает самые свежие версии программ и исправлений на момент выпуска.
Для получения доступа достаточно подключить репозиторий pkg.oracle.com/solaris/release и выполнить pkg update. Также доступен отдельный ISO-образ для чистой установки. Код открытых компонентов Solaris лежит на GitHub, отдельные пакеты можно скачать с pkg.oracle.com.
Общая поддержка Oracle Solaris обещана до 2037 года.
Linux / Линукс🥸
Компания представила третий выпуск своей редакции Solaris CBE (Common Build Environment), предназначенной для разработчиков и персонального использования. В отличие от обычных сборок Solaris 11.4, которые можно бесплатно применять для тестирования и личных проектов, CBE использует непрерывную модель публикации обновлений (rolling) и включает самые свежие версии программ и исправлений на момент выпуска.
Для получения доступа достаточно подключить репозиторий pkg.oracle.com/solaris/release и выполнить pkg update. Также доступен отдельный ISO-образ для чистой установки. Код открытых компонентов Solaris лежит на GitHub, отдельные пакеты можно скачать с pkg.oracle.com.
Общая поддержка Oracle Solaris обещана до 2037 года.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
Oracle
Announcing a New Version of our Oracle Solaris Environment for Developers
Announcing a new Oracle Solaris Common Build Environment (CBE) release
👍8❤5
Зацените сборку. Запускается на 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😎8🔥2😈1
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😢1
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣25💯3🤔2😎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
🤔18👍3