Как стать автором
Обновить

Комментарии 74

Вот интересно — вот это полностью самостоятельный, самобытный дистрибутив? Или он основан на каких-то других популярных диатрибах (будь-то зарубежные или отечественные)? И что с поддержкой х86 и арм платформ? То, что она может быть заявлено — одно, интересно, что по факту

Если я не ошибаюсь, то когда-то представители МЦСТ заявляли, что это не ОС для конечного пользователя, а пример того, как вообще писать системное ПО под Эльбрусы.
Поэтому поддержка всего, кроме e2k, там на уровне «Скомпилировалось — и слава богу!».
Дистрибутив то точно самостоятельный. Навряд ли кто-то из-за границы будет собирать дистрибутив под e2k. Как минимум будут трудности с покупкой железа для компиляции/тестирования/отладки входящего ПО. Хорошо, что МЦСТ оставили совместимость на уровне формата пакетов с дебианом.

Про наличие сборки для х86 прямо в заметке сказано, как для sparc и e2k (естественно :). А вот для ARM как-то ни разу не слышал, что даже планировали портировать. Это наверное Байкалу интереснее будет.

Тут больше вопрос зачем тратиться на собственный дистрибутив, если как минимум есть Альт Линукс и Астра Линукс, которые имеют сборки под архитектуру Эльбрусов.
Тут больше вопрос зачем тратиться на собственный дистрибутив, если как минимум есть Альт Линукс и Астра Линукс, которые имеют сборки под архитектуру Эльбрусов.
Так он же как бы референсный образец.
Понимаю, если это компилятор, средства разработки и отладки, драйвера под собственное железо, собственный загрузчик наконец. А остальное почему бы не брать у коллег?
Сколько ресурсов можно так сэкономить и пустить их, например, на компиляторы для языков типа Rust/Java/Питон, помимо имеющихся Си/С++/Фортран!
Ну, коллеги подключились позже, насколько помню.

Насколько я понимаю, портирование ядра на e2k таки тянет МЦСТ. Альт и все остальные берут уже готовое(или патчи). Так же и с остальными пакетами, хотя альтовцы часть сами делают.

Раньше это был совсем Debian, там даже можно было увидеть, какой релиз был взят за основу. Сейчас, видимо, они отошли чуть дальше, но это все еще debian-based дистрибутив, если посмотреть на списки пакетов по ссылке

Портом Debian (неофициальным) является ОС «Эльбрус-Д», упомянутая на странице «Программное обеспечение Эльбрус». А тот факт, что и поныне «Эльбрус Линукс» в ответ на lsb_release идентифицирует себя как Debian, объясняется тем, что так проще, чем переписывать кучу configure, Makefile и install.sh в сторонних программах, которые кто-нибудь пытается скомпилировать. По той же причине фирменный компилятор LCC выдаёт себя за GCC, насколько это возможно, хотя внутри не имеет с последним ничего общего.

Это всё ещё debian-based дистрибутив, если посмотреть на списки пакетов по ссылке.
Просто интересно: какие пакеты-«индикаторы» вы считаете признаком наследия Debian? Считаете ли вы, что именно набор прикладных пакетов определяет сущность дистрибутива, а не, например, система сборки этих пакетов в сочетании со сборочными инструкциями?

Самобытность Линукс дистрибутивов это уже походу из области философии. Этот скорее переборка Debian, со своими патчами. И на фоне общего числа пакетов/кода эти патчи будут занимать 1%. Альт — точно самобытный дистрибутив с богатой историей. А с другой стороны CentOS — это просто избавление от традемарков RedHat, но при этом отдельный дистрибутив.

Интересно, это полностью самостоятельный, самобытный дистрибутив? Или он основан на каких-то других популярных диатрибах? Что с поддержкой x86 и ARM?
Если действительно интересно, то почему не посмотреть на странице описания «Эльбрус Линукс», благо ссылка дана в первом же абзаце статьи?
На чём базируется дистрибутив Эльбрус Линукс
Операционная система «Эльбрус Линукс» является собственной разработкой АО «МЦСТ» — не повторяет другие дистрибутивы, хотя и включает в себя технические решения Debian.
Какие архитектуры поддерживает Эльбрус Линукс
  • Эльбрус,
  • SPARC (МЦСТ-R),
  • x86.
Разумеется, в разных версиях системы была поддержка разных версий архитектур; сейчас поддерживаются только Эльбрус в. 3 и новее, SPARC V9, x86-64. На разных архитектурах могут быть немного разные наборы / версии пакетов из-за сложности портирования.

Меня не интересует «формальное» положение дел, а интересует реальное. А то я могу слона буйволом назвать и толку?

Реальное положение дел:


  1. Дистрибутив «Эльбрус Линукс» действительно строится вокруг своей системы сборки и развивается самостоятельно, без оглядки на другие дистрибутивы. Даже если какие-то технические решения (средства настройки, например) или специфические прикладные пакеты позаимствованы откуда-то ещё, это не значит, что и в других аспектах выдерживается сходство. Самобытность — это на самом деле палка о двух концах: некоторые пользователи действительно ожидают увидеть слегка модифицированный Debian и огорчаются, что на самом деле это не так, и их навыки администрирования тут не работают. (По-моему, это самая наглядная иллюстрация того, что «Эльбрус Линукс» — это не Debian.)
  2. Дистрибутив «Эльбрус-Д» — это именно Debian, фиксированной версии. Портирован, конечно, далеко не весь бесчисленный репозиторий пакетов Debian, но те, что портированы, должны быть такими же, как в Debian соответствующей версии — ни шагу в сторону. То есть, если какому-то пользователю нужен дополнительный или обновлённый пакет, которого не было в апстриме, то в «Эльбрус-Д» его тоже не добавят — это, в свою очередь, обратная сторона портирования уже существующего дистрибутива: его нельзя развивать самостоятельно, иначе получится не порт, а форк, и далее по пути пункта 1.
  3. Поддержку различных архитектур стараются делать симметричной, насколько это возможно — а это невозможно на все 100 %. Например, поскольку компилятора LCC нет для x86, то в дистрибутиве для x86 используется обычный GCC со всеми вытекающими: какие-то пакеты могут быть новее, чем в основной ветке, потому что весь мир ориентируется на самые свежие версии GCC, а совместимость с ним в LCC всегда отстаёт от оригинала; зато, имея в распоряжении только GCC, нельзя прочувствовать специфику LCC — можно лишь сделать первые шаги в портировании своих программ для «Эльбрус Линукс». Архитектура SPARC сейчас на вторых ролях: чтобы не распылять усилия, тестовые сборки выпускаются для архитектур Эльбрус и x86. Даже на Эльбрусе не всегда сборки идут гладко: например, версию 6.0 пока не получается по-нормальному собрать для Эльбрус-1С+ (даже под прототип Эльбрус-16С получается, а под серийный процессор внезапно нет) — это всё рабочие моменты, они решаются, точно так же как переползание на новую версию ядра или компилятора — вопрос не одного дня и чаще всего не одного месяца.
  4. Собственный компилятор LCC — это тоже медаль с двумя сторонами. Конечно, весь мир пишет под GCC и Clang, но с точки зрения экспертов-разработчиков компилятора для архитектуры Эльбрус не получилось бы так же хорошо реализовать в этих проектах все оптимизации (а без них на EPIC VLIW архитектурах далеко не уедешь), как это сейчас получается при использовании покупного фронтенда (такого же, как в компиляторе Intel, кстати, и во многих других, менее известных, коммерческих компиляторах). С одной стороны — хорошо: не надо тратить силы на архитектурно-независимую языковую часть, можно сконцентрироваться на аппаратной специфике. С другой стороны: обнаружился, например, некий баг год назад, мешающий сборке CMake новых версий — его передали разработчикам фронтенда, те якобы что-то исправили, но на самом деле просто замаскировали проблему, так что теперь вместо внятного сообщения о причинах сбоя выдаётся лишь безадресная internal error; можно, конечно, исправить у себя (все исходники фронтенда на руках), но тогда получится адский ад из-за необходимости поддерживать получившийся форк.

Так и живём. Дистрибутив прогрессирует, может, и не так резво, как мировые лидеры, над которыми трудятся сотни-тысячи людей, но всё равно существенно: оценить это можно по изменениям перечня пакетов и их версий, приведённым в описании на вкладке «Состав»; и это ещё туда не включены архивные ветки 2.x, про которые здесь на Хабре писали, сетуя на старые версии пакетов, — хотя всего-то 5 лет прошло.

Спасибо за столь подробный ответ! Из него узнал много интересного и он сделал мой день !

А не могли бы статью написать по этой теме?
По какой именно теме и какого рода (формата) статью? Предлагайте, у кого какие идеи есть.

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

По теме данного дистрибутива и его пакетов.

«Кто бы нам самим такую статью|документацию|… написал» — популярная в МЦСТ шутка. Серьёзно, многие вещи ещё только предстоит формализовать: например, описание жизненного цикла дистрибутива впервые появилось лишь сейчас, и оно не отвечает на такой вопрос как, скажем, почему тестовые сборки — от самых ранний альфа-версий до более-менее годных беток — уже гордо именуются релиз-кандидатами, при этом продолжая существенно меняться, иногда даже без смены номера.


Например, нынешняя 6.0-rc2 — это действительно уже что-то удобоваримое, способное плавно превратиться в релиз. Но! Во-первых, это уже третья сборка с таким обозначением; первая была с двумя багами, из-за которых половина GUI-программ не работала (в 6.0-rc1 такого не было). Разумеется, такие непротестирвоанные или забракованные сборки никто наружу не выдаёт, но внутри организации они расходятся, и возникает некоторая неоднозначность. Во-вторых, стадия RC в привычном понимании подразумевает фиксацию функциональности (feature freeze) как минимум до выпуска релиза, однако у нас это скорее snapshot / milestone — обновление прикладных и системных пакетов идёт почти без ограничений, порой и уже в стабильной версии. В-третьих, как следствие двух предыдущих обстоятельств, релизом становится не последняя беспроблемная RC-сборка, а очередная (с изменениями), сразу выпущенная как релиз — если при внутреннем тестировании обнаруживаются баги, делается пересборка, и так далее до победного конца.


Вот когда этому процессу удастся найти логическое объяснение, тогда и можно будет статью написать.



В описании написано что пакеты монолитные. То есть они собраны так, что либы в бинарник входят, или как? И нет ли мыслей прикладное ПО отделить вообще от дистрибутива, если оно всё с собой несёт?

Нет, они монолитны вовсе не в том смысле, что все исполняемые файлы скомпонованы статически. И тем более не в том новомодном «контейнерном» смысле, что каждый пакет полностью автономен, так как таскает за собой все зависимости. Тогда бы дистрибутив занимал не 2–3 неполных DVD, а скорее 20–30 под завязку.


Пакеты монолитны в том смысле, что один source-проект, за редким исключением, на выходе превращается в один установочный пакет — нет разделения на части bin, data, doc, devel, lib и т. д., искусственно создающие видимость изобилия в репозитории. Пока что у нас практически нет таких пакетов, где бы архитектурно-независимая часть составляла основную долю — больше всего занимает машинный код, который для VLIW очень размашистый, особенно на высоких уровнях оптимизации, поэтому всё равно для каждого процессора выпускается своя сборка дистрибутива, и нет необходимости делить пакет на части. Ещё исторически не принято рассматривать обновление системы в продакшне как норму — основным сценарием видится установка с нуля, поэтому и насчёт «облегчения» обновляемой части пакета заботиться как бы нет смысла, тем более что бинарники всё равно зачастую пересобираются даже когда не было обновления исходников.


Замечание про монолитность сделано для того, чтобы пояснить, что ≈2000 пакетов Эльбрус Линукс — это реально даже больше, наверное, чем ≈8500 пакетов Эльбрус-Д, где сделана разбивка на части, как в Debian. Ну, и в сравнении с другими дистрибутивами тоже чтобы мало не казалось, хотя, бесспорно, даже у коллег в e2k-системах пакетов больше — потому что им не приходится тратить силы на фундаментальные компоненты, и они менее консервативны в плане добавления новых пакетов и обновления версий (особенно если они уже поддерживают этот пакет для других архитектур).


Какое слово вместо «монолитные» предлагаете использовать, чтобы всем было понятно, что на самом деле имеется в виду?

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

очень самобытный подход, однако…

Очень популярный подход среди целевой аудитории:


  1. Работает — не трогай.
  2. Сертифицированная система даёт +100 к ощущению неуязвимости. А процесс сертификации занимает от полугода до полутора.

Первый подход не специфичен для какой-либо архитектуры или платформы, как и второй, впрочем. Просто Эльбрусы чаще всего применяются в таких проектах, где вероятность встретить хотя бы один из этих подходов близка к единице.


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

Это ломает всю историю с patch management. Я, конечно, обеими руками за infrastructure as a code и immutable infrastructure, но переходить в радикализм не хочется. Дополнительно отмечу, что защищённая система — это не та, которая сертифицированная и не меняется. А для которой существуют вполне определенные процессы аудита, контроля и изменения. И для нас это важнее, чем некая бумажка от ФСБ

Нет, они монолитны вовсе не в том смысле, что все исполняемые файлы скомпонованы статически.

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


А там кроcскомпилятор в дистре есть или опять не положили?


Какое слово вместо «монолитные» предлагаете использовать, чтобы всем было понятно, что на самом деле имеется в виду?

Перестать оправдываться перед всеми и начать жить. Не предложение а просто совет мимокрока.

Я думал, на Эльбрусе так (компоновать программы статически) гораздо быстрей.

Вы, наверное, понимаете, что VLIW в смысле размера машинного кода — явление, прямо противоположное ARM Thumb. Но до конца не представляете, насколько противоположное, хотя бы даже в сравнении со всем привычным x86. Например, основные модули LibreOffice Writer и Calc (libswlo.so и libsclo.so) версии 6 для Debian x86-64 имеют размер порядка 17–20 Мбайт, для Эльбрус Линукс E8C — порядка 57–58 Мбайт, и это оно ещё, возможно, не на самом высоком уровне оптимизации собрано. А так, если переусердствовать с оптимизацией и/или отказом от подгружаемых библиотек, то легко можно получить 100-мегабайтный экзешник даже на таких простых, казалось бы, вещах как Git или CMake.



Кроcскомпилятор в дистре есть, или опять не положили?
Кросс-система традиционно поставляется отдельно, так как, вообще говоря, существует в стольких же вариантах, сколько есть и целей сборки — 6 версий архитектуры Эльбрус с 2 подвидами в некоторых версиях и 2 версии SPARC. Сейчас из этого поддерживается 6 вариантов; за вычетом будущих процессоров — 4 варианта, что тоже немало. Потому что помимо собственно компилятора кросс-система состоит ещё и из архива файлов установленной целевой системы — а это некислый такой архив даже в минималистичном варианте установки (вот тут, конечно, не помешало бы деление пакетов на devel и lib, потому что всё остальное для кросс-компилятора не нужно). Так что вкладывать это всё в универсальный установочный образ для x86 как минимум не гуманно по отношению к многочисленным желающим просто попробовать в режиме пользователя.

Перестать оправдываться перед всеми и начать жить.

Во-первых, тут у нас просто со своим же продуктом конкуренция получается: люди смотрят на количество пакетов в Эльбрус-Д (и производных от него) и думают, что это более перспективная система, хотя именно Эльбрус Линукс богаче на программы и развивается в первую очередь.


Во-вторых, ну да, часто приходится оправдываться именно из-за своей самостийности. Например, в недавней статье „Импортозамещение на практике. Часть 5. Восхождение на «Эльбрус»“, среди прочих выводов, к которым автор пришёл, не посчитав нужным поинтересоваться в первоисточнике, было:

Для «Эльбрус» был портирован дистрибутив Linux. После этого ядро ОС было отдано в РусБИТех и БазАльт… Имеем четыре ОС, которые можно установить на «Эльбрус». И у всех этих ОС, кроме Альт 9, одна версия ядра – 4.9.0. У Альт 9 же версия ядра 4.9.170, что говорит нам о том, что люди работают, развивают свою платформу.

При всём уважении к героическим усилиям Михаила Шигорина из «Базальта», который чуть ли не в одиночку тянет весь e2k-порт Альт Линукса, партнёры всё же получают фундаментальные компоненты (linux, libc, firefox, …) от МЦСТ, а не портируют и не обновляют их самостоятельно. Просто в Эльбрус Линукс такая самостийная нумерация используется — 4.9.0-x.x; в Астра Линукс — 4.9.0-x. При этом номер версии апстрима присутствует в первых строках /proc/config.gz и в информации о версии пакета (как в имени deb-файла, так и внутри базы данных пакетного менеджера): например, из ветки 4.9 последней является 4.9.0-5.4, которая, как и вся подветка -5.x, основана на апстримной версии 4.9.224. Аналогично, сейчас ядро 5.4.0-1.6 основано на апстримной версии 5.4.58.

Внутренний мир разработки)
Или как оно на 16С.
Просто комментарии у вас большие и интересные, а прочитают их на хабре — единицы, потому что тема уже старая и сюда заходит намного меньше людей, чем в новую статью и комменты под ней.
Интересно, а когда они перестанут нарушать GPL и опубликуют исходные коды дистрибутивов?
GPL же не требует обязательно публиковать исходные коды. Лишь предоставлять их пользователю по его требованию. Предоставлять их можно в разном виде, хоть на физическом носителе.

Если у вас есть соответствующее железо, вы можете затребовать исходные коды и уже затем опубликовать их.
И я как пользователь запросил исходники полтора года назад habr.com/ru/post/447010. Исходников нет и по сей день.
Пишите в FSF и OSI, вроде они занимаются вопросом соблюдения GPL.

Ну, и какова будет их реакция? Попадут в суд на МЦСТ? Наложат очередные санкции на РФ? Да и пофиг — в общем-то, никаких рычагов у них нет реальных

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

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

А у МЦСТ в США есть какой-либо бизнес/представитель?
Кстати, оговорка «Если у вас есть соответствующее железо, вы можете затребовать исходные коды и уже затем опубликовать их.» — ничтожна. В GPL нет никакого упоминания про какое-то «железо».
Речь идет только о программном обеспечении.
И так как дистрибутив уже опубликован, то отказ от предоставления исходников является прямым нарушением лицензии.
А что, кто-то имеет право требовать исходный код продукта, не являясь его пользователем?
Пользователь становится по факту владения, а не реального использования.
Можно купить (скачать), но не пользоваться, и все равно являться законным владельцем.
С чего бы?
Вы можете официально скачать только x86 версию.
Можно купить
ну так купите
(скачать)
а скачать вроде как только если через железо.
Кстати, оговорка «Если у вас есть соответствующее железо, вы можете затребовать исходные коды и уже затем опубликовать их.» — ничтожна. В GPL нет никакого упоминания про какое-то «железо».
А эту ОС разве можно запустить без наличия «Эльбруса»? Если нет, то отсутствие железа равносильно невозможности быть пользователем. Вот если бы был эмулятор аппаратной части… но его ведь не существует.
МЦСТ опубликовал дистрибутив и для х86 процессора, и для него исходников тоже не предоставил.
Ссылка в тексте заметки на исходник дистрибутива — это списки файлов в него входящих. Исходники входящего ПО публикуются авторами этого ПО. Не путайте дистрибутив (составное произведение — название файлов и их версии, скрипты сборки) и само ПО.
Исхордники ПО, это не список файлов, а исходный тест этих файлов.
Конечно, но мы обсуждаем именно дистрибутив, а не ПО.
Мы обсуждаем выполнение требований GPL лицензии, а не различные оправдания в её нарушении.

Я с вами тут абсолютно согласен. На мой взгляд МЦСТ нарушает GPL. И есть тысяча способов её обойти, но они не используют эти варианты. Но мне пришёл интересный вариант в голову. Я скачал исходники программы под GPL, исправил что-то, скомпилировал, удалил исходники. Выложил бинарник в сети. Теперь физически невозможно получить исходники. Как быть?

Удалить бинарник с ресурсов, доступ к которым имеете (то есть являетесь распространителем). А кто уж там скачал и сам дальше распространяет — его проблемы. Если кто обратится за исходниками — так и ответить, сорян, исходники утеряны, потому прошу удалить бинарник и им не пользоваться.

Странный посыл. Дистрибутив — это список ПО и скрипты для сборки. Вижу, что ссылка на список пакетов прямо в этой заметке указана. Плюс портирование входящего в дистрибутив ПО на целевые платформы. Исходный код этого ПО не меняется, за исключением исправления явных ошибок компиляции.
В чём может быть нарушение GPL?

Как минимум в ядре изменений будет явно побольше чем «исправления явных ошибок компиляции», а насколько я понял пост rsashka, исходников ядра вроде тоже не дают

Коли Альт и Астра делают правку и сборки под e2k и отправляют эти изменения в основную международную ветку, то надо полагать ядро уже давно пропачено и опубликовано. Могу ошибаться, но по крайней мере, посыл именно такой — МЦСТ все правки отправляет российским партнёрам по линуксу, а они по своей линии дальше. Видел много тикетов со стороны Альтов и Астры на этот счёт.

Но это только для библиотек и прикладного ПО, патчи для ядра они не публиковали в открытом доступе, и уж тем более не отправляли в апстрим

Я в эту тему тоже глубоко не копал, но как минимум в https://github.com/torvalds/linux упоминания e2k или elbrus не находятся поиском, что есть подозрительно. (Возможно, на packages.altlinux.org где-нибудь код ядра лежит, но сайт настолько неудобный и медленный, что я не осилил)

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

Вот что навскидку попадается: Портирование Sisyphus на платформу e2k (Эльбрус 2000)
GPL не нарушается потому-что опубликована только х86 версия которая является просто сборкой ванильных пакетов. Насколько я знаю патчей для e2k там нет. Эти патчи поставляются отдельно уже собственно пользователям кода с этими патчами.
Это проверяется очень просто, сборкой из выложенных исходников. Остается только их дождаться.

Откуда мне знать, из чего там собрано? Выложены только бинари.


Если это просто ванильные пакеты, тем более не вижу никаких проблем с публикацией их исходников, это вообще нарушение gpl на пустом месте получается.

Интересно, а когда они перестанут нарушать GPL и опубликуют исходные коды дистрибутивов?
Если действительно интересно, то можно чуть внимательнее прочитать текст новости, где прямо сказано: «Комплект исходных текстов с необходимыми корректурами, инструментами и сценариями сборки доступен в виде Набора разработчика платформы», и даже ссылка на этот PDK дана. Статью не читай @ сразу комментируй?

Да, туда не входят исходники ядра, но это пока: не всё же сразу удаётся оформить в виде готового к потреблению devkit'а. А тем разработчикам операционных систем, которые сами с усами (Альт, Астра), все необходимые исходники передавались задолго до формирования PDK как продукта.
Да, туда не входят исходники ядра
@ сразу комментируй?
Не всё сразу.

— Вот когда портируете ядро, тогда и поговорим.
— Вот когда создадите дистрибутив, тогда и поговорим.
— Вот когда опубликуете дистрибутив, тогда и поговорим.
— Вот когда опубликуете исходники системы сборки пакетов, тогда и поговорим.
— Вот когда опубликуете исходники прикладных пакетов, тогда и поговорим.

=== Вы находитесь здесь ===

— Вот когда опубликуете исходники ядра, тогда и поговорим.

Если хотите всё сразу, то приходите работать в МЦСТ — возможно, высвободите чьи-то руки, чтобы ускорить этот процесс. А пока что не за вами ведь придёт товарищ майор, если в опубликованных исходниках обнаружатся фрагменты, которые не подлежат публикации: образно говоря, они были написаны на деньги товарища майора, и только он имеет право их запрашивать, а вы за них не платили, поэтому требовать их не можете. Ибо не достаточно только лишь автоматически прогнать исходный код через unifdef и т. п. — надо потом вручную перепроверять результаты.
Вы опять пытаетесь объяснить не выполнение условий GPL лицензии внешними обстоятельствами.
Но ведь это именно вы не платили за использование кода, когда отчитывались им за деньги, полученные от товарища майора. И это вы почему-то забыли, что заимствованный вами код можно было взять только на условиях лицензии. А когда у вас попросили эти условия выполнить, вы начинаете юлить.
Вы неправильно представляете себе ситуацию. Изначально именно товарищ майор оплатил разработку, и только он имеет право на исходные тексты — в строгом соответствии с лицензией GPL, как вам уже объясняли (а на самом деле в соответствии с госконтрактом). Потом у товарища майора спросили: «Можно дать попользоваться такому-то госпредприятию?». «Пожалуй, можно, но только чур в упрощённом виде», — ответил великодушный товарищ майор. Потом его спрашивали ещё и ещё, пока он наконец не сказал: «Короче, давайте кому хотите, но только не за границу и без исходников; а исходники — только с моего персонального разрешения». Так и повелось, и именно такую картину вы наблюдаете сейчас, не понимая, что [почти] свободное распространение бинарного дистрибутива — это акт доброй воли изначального спонсора, который решил поделиться с вами частичкой разработанного для него продукта. Иначе бы вообще никакого дистрибутива не было в свободном обращении.

Представьте себе, что для безотлагательного выполнения всех условий GPL для поставки дистрибутива простым людям потребовалось бы ждать, пока не будет проведено окончательное разделение исходников на «Для товарища майора» и «Для простых людей» (что, возможно, и не достижимо на 100 %), — скажем, до 2021 года. Пошло бы это на пользу платформе Эльбрус, если бы были потеряны 6 лет (с 2015 года, когда началась массовая продажа компьютеров на базе Эльбрус-4С) и не было бы получено столько ценной обратной связи? Народ и дальше бы стал укрепляться во мнении, что «Эльбрусы — это миф, их не существует».

И тем не менее, кому действительно надо — тот исходники получает, это факт: сюда относятся не только разработчики собственных операционных систем, но и эксплуатанты. Большинству пользователей исходники не нужны; если где-то обнаруживается баг, то о нём сообщают, чтобы разработчик дистрибутива исправил сразу для всех пользователей. Если вы подозреваете баг и очень хотите заняться отладкой самостоятельно, то попробуйте попросить исходники того конкретного пакета, который вам нужен. Если же вы пришлёте письмо в стиле «Дайте исходники!!! Я ничего не собираюсь с ними делать — я просто борцун», то пока что вам ничем помочь не смогут, так как, формально, чтобы удовлетворить такой запрос, надо спросить разрешения у товарища майора: «Там какой-то Сашка с Хабра требует исходники вашего дистрибутива, угрожая в случае отказа натравить иностранные некоммерческие организации» — не очень мотивирующее обращение, правда?

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

В общем, не вижу смысла ломать копья. Вам объяснили, что принципиальное желание открыть исходники есть и было давно — работы ведутся не первый год. Результаты публикуются по мере готовности, чтобы можно было уже сейчас пользоваться тем, что есть, а не ждать несколько лет всего комплекта сразу. Даже нынешняя новость о выпуске дистрибутива 6.0-rc2 — из той же серии: вместо того, чтобы оттягивать анонс до конца года, о появлении более-менее годной сборки решили сообщить уже сейчас, чтобы желающие попробовали и дали фидбэк.
Текст на пол страницы и 12 вхождений словосочетания «Эльбрус Линукс».
Не надо так писать тексты.
Смотрю народ возбуждается на теме американского и российского лицензирования))
Хотелось бы получить дельные ответы на несколько животрепещущих вопросов:
— какие лицензии применяются к дистрибутивам (сборникам ПО) и наследуется ли они в форках?
— изменяются ли лицензии на ПО, которое включают в дистрибутивы (сборники ПО)?
— обязательна ли перепубликация исходников ПО включённого в состав дистрибутива или досточно ссылки на оригинал?

Вообще достаточно очевидно, что :


какие лицензии применяются к дистрибутивам (сборникам ПО) и наследуется ли они в форках?

В форках, как производных произведениях — лицензии наследуются (по умолчанию). Можно опубликовать форк под другой лицензией, но она должна быть "совместимой".


изменяются ли лицензии на ПО, которое включают в дистрибутивы (сборники ПО)?

нет


обязательна ли перепубликация исходников ПО включённого в состав дистрибутива или досточно ссылки на оригинал?

А вот это интересный вопрос. На самом деле, я думаю, что ответ "да" — исходники должны быть опубликованы целиком. По идее по аналогичной процедуре ребята взяли исходники RHEL и допилили до вида Centos (первый — платный, второй — бесплатный и свободный)

В форках, как производных произведениях — лицензии наследуются (по умолчанию).

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

Вот, например, допустим, что Debian – это форк Softlanding Linux System. В лицензии на SLS говорится, что всё что собрано в дистрибутив их скриптом — является их собственной сборкой и требует получения разрешения на распространения при изменениях. Весь входящий в дистрибутив софт при этом остаётся в правах и под лицензиями исходных разработчиков.

Какие права Debian описал на счёт своего дистрибутива я не нашел сходу. Есть только правила включения ПО — там 21 разрешённая лицензия и список запрещённых. Кто знает лицензию самого дистрибутива?
На самом деле, я думаю, что ответ «да» — исходники должны быть опубликованы целиком.

Зачем? Какой в этом смысл, если есть исходники в сети? Их даже грузить можно в момент сборки и компиляции из репозитория разработчика. В Альт Линукс так и сделано.

А в дистрибутиве передавать только исполнимый код под целевые платформы. Тем более, что для проприетарного ПО именно так и будет. Для развёртывания этого достаточно.
Какой в этом смысл, если есть исходники в сети?

Вы же понимаете фразу "исходники должны быть опубликованы целиком"?
Подскажите — как именно?
Про поставку исходников в дистрибутиве у меня ни слова не было

Чёт вспомнилось народно-приятное)) Стащил у Igor Molchanov.
Актуализировал по имеющимся доступным фактам.

План до 2025 года и на Эльбрус-32С

— вот когда появится полноценное описание архитектуры, тогда и поговорим.
— вот когда реализуют её на чипах, тогда и поговорим.
— вот когда сделают СБИС, тогда и поговорим.
— вот когда контроллер памяти будет не на ПЛИСах, тогда и поговорим.
— вот когда появится трансляция x86, тогда и поговорим.
— вот когда южный мост будет свой, тогда и поговорим.
— вот когда запустится линукс, тогда и поговорим.
— вот когда запустится радеон, тогда и поговорим.
— вот когда начнёте продавать юрикам, а не только военным, тогда и поговорим.
— вот когда сделаете нормальную материнку с ним, тогда и поговорим.
— вот когда сделаете нормальный сервер с ним, тогда и поговорим.
— вот когда сделаете нормальный десктоп с ним, тогда и поговорим.
— вот когда чип целиком сделают в России, тогда и поговорим.
— вот когда появится трансляция x86_64, тогда и поговорим.
— вот когда преодолеете гигагерц, тогда и поговорим.
— вот когда портируют отечественные дистры (астру, альт), тогда и поговорим.
— вот когда поставите кому-нибудь хотя бы тысячу штук, тогда и поговорим.
— вот когда запустится нвидия, тогда и поговорим.
— вот когда у вас будет более-менее современное ядро, тогда и поговорим.
— вот когда южник интегрируете на одну подложку с процом, тогда и поговорим.
— вот когда южник интегрируете на один кристалл с процом, тогда и поговорим.
— вот когда в школах/универах/прочих образовательных учреждениях будут эльбрусы, тогда и поговорим.
— вот когда появится аппаратная виртуализация, тогда и поговорим.
— вот когда преодолеете два гигагерца, тогда и поговорим.

=== вы находитесь здесь ===

— вот когда откроете исходники компилятора и системы сборки, тогда и поговорим.
— вот когда сделаете чиплеты, тогда и поговорим.
— вот когда соберут gcc, LLVM и всякие нужные JITы под эльбрус, тогда и поговорим.
— вот когда откроете исходники ядра, тогда и поговорим.
— вот когда архитектура появится в апстриме ядра, тогда и поговорим.
— вот когда начнёте продавать частникам, тогда и поговорим.
— вот когда соберут дебиан, центось и убунту, не говоря уже о раче, под эльбрус, тогда и поговорим.
— вот когда поставите кому-нибудь хотя бы сто тысяч штук, тогда и поговорим.
— вот когда у каждого третьего человека в стране будет эльбрус, тогда и поговорим.
— вот когда обгоните АМД, тогда и поговорим.
— вот когда обгоните Интел, тогда и поговорим.
— вот когда каждый комп в мире будет на эльбрусе, тогда и поговорим.
А поделитесь описанием архитектуры, а? Система команд, регистры и прочая радость, чтобы портировать llvm. Ну и ещё пара строк до «здесь» вызывает некоторые сомнения.
Машкоманд не хватает для портирования.
Это вам напрямую в МЦСТ стоит обратиться.
Вообще говоря, компилятор не обязан сразу выдавать машинный код, наверное. Если названия инструкций процессора известны, то можно из компилятора выдавать текстовый asm-файл, на который потом натравливать штатный ассемблер — пусть он сам с кодировками команд разбирается. Понятное дело, что метод субоптимальный, но в отсутствие полного описания системы команд — единственный, который приходит на ум.
Уважаемые энтузиасты портирования всего и вся на Эльбрус! Ваш настрой в одиночку между делом тянуть то, что тянут целые команды на полную ставку, очень похвален. Поэтому, если вы действительно уверены в своих силах, то не ждите, что на вас обратят внимание (хотя, да, глаза есть повсюду), — сами обратитесь в МЦСТ со своим предложением. Даже если один в поле не воин, при накоплении критической массы желающих можно что-нибудь придумать. А некоторые проекты уже сейчас копают энтузиасты-одиночки.

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