Корпоративная культура — это не обязательно уставные правила в организации, это фактический уклад взаимоотношений. Вы, наверное, просто никогда не работали в организации с «токсичной» культурой (где человек человеку волк — что по вертикали, что по горизонтали, что по диагонали), просто потому что обходите подобные организации стороной.
В контексте синхронизации времени, например, используются такие термины:
resolution — разрешающая способность шкалы измерения (квант), например наносекунда в современных ОС;
precision — класс точности, определяемый дискретностью хода конкретных часов, например 50 наносекунд;
accuracy — собственно достигнутая точность системы, определяемая отклонением (offset) от эталонных часов с учётом всех внесённых поправок на долгосрочный уход частоты (wonder) после усреднения краткосрочного дрожания фазы (jitter), например 1 микросекунда с использованием GNSS, 15 микросекунд с PTP, 2 миллисекунды с NTP.
Не утверждаю, что то же самое применимо и для других областей науки и техники, но иметь в виду можно.
Более того, учитывая, что клавиша Initiate — серого цвета, в то время как параллельно присутствуют клавиши красного и синего цветов, скорее можно предположить, что это и есть какой-то вариант Escape: то есть «initiate» в смысле «initialize», но не то чтобы «erase» (как красная клавиша справа), а в смысле «начать диалог [заново]» или что-то типа того.
Сначала докажите, что вы действительно это сделали. (У автора доказательств не то, что не сохранилось — их в принципе не было.)
Штраф накладывается не за «виновность», а за неисполнение обязанности. По какой независящей от вас причине вы не смогли эту обязанность исполнить, даже если пытались, — никого не волнует, как я понял. Видимо, подразумевается, что вы должны заплатить штраф, а потом требовать его компенсации с того, по чьей вине, на ваш взгляд, не смогли выполнить свои обязательства — например, с оператора связи или разработчика приложения, которые, конечно же, ничего вам не должны.
Я думал, на Эльбрусе так (компоновать программы статически) гораздо быстрей.
Вы, наверное, понимаете, что 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.
Сертифицированная система даёт +100 к ощущению неуязвимости. А процесс сертификации занимает от полугода до полутора.
Первый подход не специфичен для какой-либо архитектуры или платформы, как и второй, впрочем. Просто Эльбрусы чаще всего применяются в таких проектах, где вероятность встретить хотя бы один из этих подходов близка к единице.
Ну, а когда нет достаточного спроса и обратной связи, то и мотивации тратить ресурсы на проработку невостребованной функциональности — мало.
«Кто бы нам самим такую статью|документацию|… написал» — популярная в МЦСТ шутка. Серьёзно, многие вещи ещё только предстоит формализовать: например, описание жизненного цикла дистрибутива впервые появилось лишь сейчас, и оно не отвечает на такой вопрос как, скажем, почему тестовые сборки — от самых ранний альфа-версий до более-менее годных беток — уже гордо именуются релиз-кандидатами, при этом продолжая существенно меняться, иногда даже без смены номера.
Например, нынешняя 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-системах пакетов больше — потому что им не приходится тратить силы на фундаментальные компоненты, и они менее консервативны в плане добавления новых пакетов и обновления версий (особенно если они уже поддерживают этот пакет для других архитектур).
Какое слово вместо «монолитные» предлагаете использовать, чтобы всем было понятно, что на самом деле имеется в виду?
Вы неправильно представляете себе ситуацию. Изначально именно товарищ майор оплатил разработку, и только он имеет право на исходные тексты — в строгом соответствии с лицензией GPL, как вам уже объясняли (а на самом деле в соответствии с госконтрактом). Потом у товарища майора спросили: «Можно дать попользоваться такому-то госпредприятию?». «Пожалуй, можно, но только чур в упрощённом виде», — ответил великодушный товарищ майор. Потом его спрашивали ещё и ещё, пока он наконец не сказал: «Короче, давайте кому хотите, но только не за границу и без исходников; а исходники — только с моего персонального разрешения». Так и повелось, и именно такую картину вы наблюдаете сейчас, не понимая, что [почти] свободное распространение бинарного дистрибутива — это акт доброй воли изначального спонсора, который решил поделиться с вами частичкой разработанного для него продукта. Иначе бы вообще никакого дистрибутива не было в свободном обращении.
Представьте себе, что для безотлагательного выполнения всех условий GPL для поставки дистрибутива простым людям потребовалось бы ждать, пока не будет проведено окончательное разделение исходников на «Для товарища майора» и «Для простых людей» (что, возможно, и не достижимо на 100 %), — скажем, до 2021 года. Пошло бы это на пользу платформе Эльбрус, если бы были потеряны 6 лет (с 2015 года, когда началась массовая продажа компьютеров на базе Эльбрус-4С) и не было бы получено столько ценной обратной связи? Народ и дальше бы стал укрепляться во мнении, что «Эльбрусы — это миф, их не существует».
И тем не менее, кому действительно надо — тот исходники получает, это факт: сюда относятся не только разработчики собственных операционных систем, но и эксплуатанты. Большинству пользователей исходники не нужны; если где-то обнаруживается баг, то о нём сообщают, чтобы разработчик дистрибутива исправил сразу для всех пользователей. Если вы подозреваете баг и очень хотите заняться отладкой самостоятельно, то попробуйте попросить исходники того конкретного пакета, который вам нужен. Если же вы пришлёте письмо в стиле «Дайте исходники!!! Я ничего не собираюсь с ними делать — я просто борцун», то пока что вам ничем помочь не смогут, так как, формально, чтобы удовлетворить такой запрос, надо спросить разрешения у товарища майора: «Там какой-то Сашка с Хабра требует исходники вашего дистрибутива, угрожая в случае отказа натравить иностранные некоммерческие организации» — не очень мотивирующее обращение, правда?
Ну, и с чисто прагматической точки зрения, несоблюдение GPL российскими компаниями на данный момент скорее всего не имеет никаких юридических последствий, тогда как несоблюдение требований товарища майора грозит неиллюзорными уголовными сроками. Причём договориться о публикации исходников можно, например, с майором ВС, а придёт за тобой майор ФСБ, который не является правообладателем, но чутко бдит.
В общем, не вижу смысла ломать копья. Вам объяснили, что принципиальное желание открыть исходники есть и было давно — работы ведутся не первый год. Результаты публикуются по мере готовности, чтобы можно было уже сейчас пользоваться тем, что есть, а не ждать несколько лет всего комплекта сразу. Даже нынешняя новость о выпуске дистрибутива 6.0-rc2 — из той же серии: вместо того, чтобы оттягивать анонс до конца года, о появлении более-менее годной сборки решили сообщить уже сейчас, чтобы желающие попробовали и дали фидбэк.
Вообще говоря, компилятор не обязан сразу выдавать машинный код, наверное. Если названия инструкций процессора известны, то можно из компилятора выдавать текстовый asm-файл, на который потом натравливать штатный ассемблер — пусть он сам с кодировками команд разбирается. Понятное дело, что метод субоптимальный, но в отсутствие полного описания системы команд — единственный, который приходит на ум.
Уважаемые энтузиасты портирования всего и вся на Эльбрус! Ваш настрой в одиночку между делом тянуть то, что тянут целые команды на полную ставку, очень похвален. Поэтому, если вы действительно уверены в своих силах, то не ждите, что на вас обратят внимание (хотя, да, глаза есть повсюду), — сами обратитесь в МЦСТ со своим предложением. Даже если один в поле не воин, при накоплении критической массы желающих можно что-нибудь придумать. А некоторые проекты уже сейчас копают энтузиасты-одиночки.
Чтобы вас восприняли всерьёз, сразу укажите свои навыки в предметной области: например, если речь о портировании компилятора, то опишите свой опыт коммитов в апстрим (или поддержания форка), либо опыт развития других аналогичных проектов. Если написать что-то сомнительное — типа «Хочу портировать FreeBSD, не хватает только кодировки команд процессора!» — вряд ли кто-то захочет тратить на вас время.
— Вот когда портируете ядро, тогда и поговорим.
— Вот когда создадите дистрибутив, тогда и поговорим.
— Вот когда опубликуете дистрибутив, тогда и поговорим.
— Вот когда опубликуете исходники системы сборки пакетов, тогда и поговорим.
— Вот когда опубликуете исходники прикладных пакетов, тогда и поговорим.
=== Вы находитесь здесь ===
— Вот когда опубликуете исходники ядра, тогда и поговорим.
Если хотите всё сразу, то приходите работать в МЦСТ — возможно, высвободите чьи-то руки, чтобы ускорить этот процесс. А пока что не за вами ведь придёт товарищ майор, если в опубликованных исходниках обнаружатся фрагменты, которые не подлежат публикации: образно говоря, они были написаны на деньги товарища майора, и только он имеет право их запрашивать, а вы за них не платили, поэтому требовать их не можете. Ибо не достаточно только лишь автоматически прогнать исходный код через unifdef и т. п. — надо потом вручную перепроверять результаты.
Дистрибутив «Эльбрус Линукс» действительно строится вокруг своей системы сборки и развивается самостоятельно, без оглядки на другие дистрибутивы. Даже если какие-то технические решения (средства настройки, например) или специфические прикладные пакеты позаимствованы откуда-то ещё, это не значит, что и в других аспектах выдерживается сходство. Самобытность — это на самом деле палка о двух концах: некоторые пользователи действительно ожидают увидеть слегка модифицированный Debian и огорчаются, что на самом деле это не так, и их навыки администрирования тут не работают. (По-моему, это самая наглядная иллюстрация того, что «Эльбрус Линукс» — это не Debian.)
Дистрибутив «Эльбрус-Д» — это именно Debian, фиксированной версии. Портирован, конечно, далеко не весь бесчисленный репозиторий пакетов Debian, но те, что портированы, должны быть такими же, как в Debian соответствующей версии — ни шагу в сторону. То есть, если какому-то пользователю нужен дополнительный или обновлённый пакет, которого не было в апстриме, то в «Эльбрус-Д» его тоже не добавят — это, в свою очередь, обратная сторона портирования уже существующего дистрибутива: его нельзя развивать самостоятельно, иначе получится не порт, а форк, и далее по пути пункта 1.
Поддержку различных архитектур стараются делать симметричной, насколько это возможно — а это невозможно на все 100 %. Например, поскольку компилятора LCC нет для x86, то в дистрибутиве для x86 используется обычный GCC со всеми вытекающими: какие-то пакеты могут быть новее, чем в основной ветке, потому что весь мир ориентируется на самые свежие версии GCC, а совместимость с ним в LCC всегда отстаёт от оригинала; зато, имея в распоряжении только GCC, нельзя прочувствовать специфику LCC — можно лишь сделать первые шаги в портировании своих программ для «Эльбрус Линукс». Архитектура SPARC сейчас на вторых ролях: чтобы не распылять усилия, тестовые сборки выпускаются для архитектур Эльбрус и x86. Даже на Эльбрусе не всегда сборки идут гладко: например, версию 6.0 пока не получается по-нормальному собрать для Эльбрус-1С+ (даже под прототип Эльбрус-16С получается, а под серийный процессор внезапно нет) — это всё рабочие моменты, они решаются, точно так же как переползание на новую версию ядра или компилятора — вопрос не одного дня и чаще всего не одного месяца.
Собственный компилятор LCC — это тоже медаль с двумя сторонами. Конечно, весь мир пишет под GCC и Clang, но с точки зрения экспертов-разработчиков компилятора для архитектуры Эльбрус не получилось бы так же хорошо реализовать в этих проектах все оптимизации (а без них на EPIC VLIW архитектурах далеко не уедешь), как это сейчас получается при использовании покупного фронтенда (такого же, как в компиляторе Intel, кстати, и во многих других, менее известных, коммерческих компиляторах). С одной стороны — хорошо: не надо тратить силы на архитектурно-независимую языковую часть, можно сконцентрироваться на аппаратной специфике. С другой стороны: обнаружился, например, некий баг год назад, мешающий сборке CMake новых версий — его передали разработчикам фронтенда, те якобы что-то исправили, но на самом деле просто замаскировали проблему, так что теперь вместо внятного сообщения о причинах сбоя выдаётся лишь безадресная internal error; можно, конечно, исправить у себя (все исходники фронтенда на руках), но тогда получится адский ад из-за необходимости поддерживать получившийся форк.
Так и живём. Дистрибутив прогрессирует, может, и не так резво, как мировые лидеры, над которыми трудятся сотни-тысячи людей, но всё равно существенно: оценить это можно по изменениям перечня пакетов и их версий, приведённым в описании на вкладке «Состав»; и это ещё туда не включены архивные ветки 2.x, про которые здесь на Хабре писали, сетуя на старые версии пакетов, — хотя всего-то 5 лет прошло.
Интересно, а когда они перестанут нарушать GPL и опубликуют исходные коды дистрибутивов?
Если действительно интересно, то можно чуть внимательнее прочитать текст новости, где прямо сказано: «Комплект исходных текстов с необходимыми корректурами, инструментами и сценариями сборки доступен в виде Набора разработчика платформы», и даже ссылка на этот PDK дана. Статью не читай @ сразу комментируй?
Да, туда не входят исходники ядра, но это пока: не всё же сразу удаётся оформить в виде готового к потреблению devkit'а. А тем разработчикам операционных систем, которые сами с усами (Альт, Астра), все необходимые исходники передавались задолго до формирования PDK как продукта.
Портом Debian (неофициальным) является ОС «Эльбрус-Д», упомянутая на странице «Программное обеспечение Эльбрус». А тот факт, что и поныне «Эльбрус Линукс» в ответ на lsb_release идентифицирует себя как Debian, объясняется тем, что так проще, чем переписывать кучу configure, Makefile и install.sh в сторонних программах, которые кто-нибудь пытается скомпилировать. По той же причине фирменный компилятор LCC выдаёт себя за GCC, насколько это возможно, хотя внутри не имеет с последним ничего общего.
Это всё ещё debian-based дистрибутив, если посмотреть на списки пакетов по ссылке.
Просто интересно: какие пакеты-«индикаторы» вы считаете признаком наследия Debian? Считаете ли вы, что именно набор прикладных пакетов определяет сущность дистрибутива, а не, например, система сборки этих пакетов в сочетании со сборочными инструкциями?
Ой, да ладно, Фидо уже давно по IP ходит в основном, и IP-only узлы перестали быть экзотикой.
Ещё остались кряки и кейгены, не являющиеся при этом троянами?
Это не так «хайпово», согласитесь.
Если верить Википедии:
Эльбрус-8С = 250 GFLOPS FP32, 125 GFLOPS FP64.
Cell из PS3 = 180 GFLOPS FP32, 15 GFLOPS FP64.
А если ещё учитывать GPU, ну так в компьютер Эльбрус тоже можно видеокарту вставить.
Корпоративная культура — это не обязательно уставные правила в организации, это фактический уклад взаимоотношений. Вы, наверное, просто никогда не работали в организации с «токсичной» культурой (где человек человеку волк — что по вертикали, что по горизонтали, что по диагонали), просто потому что обходите подобные организации стороной.
В контексте синхронизации времени, например, используются такие термины:
resolution — разрешающая способность шкалы измерения (квант), например наносекунда в современных ОС;
precision — класс точности, определяемый дискретностью хода конкретных часов, например 50 наносекунд;
accuracy — собственно достигнутая точность системы, определяемая отклонением (offset) от эталонных часов с учётом всех внесённых поправок на долгосрочный уход частоты (wonder) после усреднения краткосрочного дрожания фазы (jitter), например 1 микросекунда с использованием GNSS, 15 микросекунд с PTP, 2 миллисекунды с NTP.
Не утверждаю, что то же самое применимо и для других областей науки и техники, но иметь в виду можно.
Программисты часто спорят со своим (и чужим) кодом, а код — с ними. :-)
Более того, учитывая, что клавиша Initiate — серого цвета, в то время как параллельно присутствуют клавиши красного и синего цветов, скорее можно предположить, что это и есть какой-то вариант Escape: то есть «initiate» в смысле «initialize», но не то чтобы «erase» (как красная клавиша справа), а в смысле «начать диалог [заново]» или что-то типа того.
Вы, наверное, понимаете, что VLIW в смысле размера машинного кода — явление, прямо противоположное ARM Thumb. Но до конца не представляете, насколько противоположное, хотя бы даже в сравнении со всем привычным x86. Например, основные модули LibreOffice Writer и Calc (libswlo.so и libsclo.so) версии 6 для Debian x86-64 имеют размер порядка 17–20 Мбайт, для Эльбрус Линукс E8C — порядка 57–58 Мбайт, и это оно ещё, возможно, не на самом высоком уровне оптимизации собрано. А так, если переусердствовать с оптимизацией и/или отказом от подгружаемых библиотек, то легко можно получить 100-мегабайтный экзешник даже на таких простых, казалось бы, вещах как Git или CMake.
Кросс-система традиционно поставляется отдельно, так как, вообще говоря, существует в стольких же вариантах, сколько есть и целей сборки — 6 версий архитектуры Эльбрус с 2 подвидами в некоторых версиях и 2 версии SPARC. Сейчас из этого поддерживается 6 вариантов; за вычетом будущих процессоров — 4 варианта, что тоже немало. Потому что помимо собственно компилятора кросс-система состоит ещё и из архива файлов установленной целевой системы — а это некислый такой архив даже в минималистичном варианте установки (вот тут, конечно, не помешало бы деление пакетов на devel и lib, потому что всё остальное для кросс-компилятора не нужно). Так что вкладывать это всё в универсальный установочный образ для x86 как минимум не гуманно по отношению к многочисленным желающим просто попробовать в режиме пользователя.
Во-первых, тут у нас просто со своим же продуктом конкуренция получается: люди смотрят на количество пакетов в Эльбрус-Д (и производных от него) и думают, что это более перспективная система, хотя именно Эльбрус Линукс богаче на программы и развивается в первую очередь.
Во-вторых, ну да, часто приходится оправдываться именно из-за своей самостийности. Например, в недавней статье „Импортозамещение на практике. Часть 5. Восхождение на «Эльбрус»“, среди прочих выводов, к которым автор пришёл, не посчитав нужным поинтересоваться в первоисточнике, было:
При всём уважении к героическим усилиям Михаила Шигорина из «Базальта», который чуть ли не в одиночку тянет весь 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.
Очень популярный подход среди целевой аудитории:
Первый подход не специфичен для какой-либо архитектуры или платформы, как и второй, впрочем. Просто Эльбрусы чаще всего применяются в таких проектах, где вероятность встретить хотя бы один из этих подходов близка к единице.
Ну, а когда нет достаточного спроса и обратной связи, то и мотивации тратить ресурсы на проработку невостребованной функциональности — мало.
«Кто бы нам самим такую статью|документацию|… написал» — популярная в МЦСТ шутка. Серьёзно, многие вещи ещё только предстоит формализовать: например, описание жизненного цикла дистрибутива впервые появилось лишь сейчас, и оно не отвечает на такой вопрос как, скажем, почему тестовые сборки — от самых ранний альфа-версий до более-менее годных беток — уже гордо именуются релиз-кандидатами, при этом продолжая существенно меняться, иногда даже без смены номера.
Например, нынешняя 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-системах пакетов больше — потому что им не приходится тратить силы на фундаментальные компоненты, и они менее консервативны в плане добавления новых пакетов и обновления версий (особенно если они уже поддерживают этот пакет для других архитектур).
Какое слово вместо «монолитные» предлагаете использовать, чтобы всем было понятно, что на самом деле имеется в виду?
Представьте себе, что для безотлагательного выполнения всех условий GPL для поставки дистрибутива простым людям потребовалось бы ждать, пока не будет проведено окончательное разделение исходников на «Для товарища майора» и «Для простых людей» (что, возможно, и не достижимо на 100 %), — скажем, до 2021 года. Пошло бы это на пользу платформе Эльбрус, если бы были потеряны 6 лет (с 2015 года, когда началась массовая продажа компьютеров на базе Эльбрус-4С) и не было бы получено столько ценной обратной связи? Народ и дальше бы стал укрепляться во мнении, что «Эльбрусы — это миф, их не существует».
И тем не менее, кому действительно надо — тот исходники получает, это факт: сюда относятся не только разработчики собственных операционных систем, но и эксплуатанты. Большинству пользователей исходники не нужны; если где-то обнаруживается баг, то о нём сообщают, чтобы разработчик дистрибутива исправил сразу для всех пользователей. Если вы подозреваете баг и очень хотите заняться отладкой самостоятельно, то попробуйте попросить исходники того конкретного пакета, который вам нужен. Если же вы пришлёте письмо в стиле «Дайте исходники!!! Я ничего не собираюсь с ними делать — я просто борцун», то пока что вам ничем помочь не смогут, так как, формально, чтобы удовлетворить такой запрос, надо спросить разрешения у товарища майора: «Там какой-то Сашка с Хабра требует исходники вашего дистрибутива, угрожая в случае отказа натравить иностранные некоммерческие организации» — не очень мотивирующее обращение, правда?
Ну, и с чисто прагматической точки зрения, несоблюдение GPL российскими компаниями на данный момент скорее всего не имеет никаких юридических последствий, тогда как несоблюдение требований товарища майора грозит неиллюзорными уголовными сроками. Причём договориться о публикации исходников можно, например, с майором ВС, а придёт за тобой майор ФСБ, который не является правообладателем, но чутко бдит.
В общем, не вижу смысла ломать копья. Вам объяснили, что принципиальное желание открыть исходники есть и было давно — работы ведутся не первый год. Результаты публикуются по мере готовности, чтобы можно было уже сейчас пользоваться тем, что есть, а не ждать несколько лет всего комплекта сразу. Даже нынешняя новость о выпуске дистрибутива 6.0-rc2 — из той же серии: вместо того, чтобы оттягивать анонс до конца года, о появлении более-менее годной сборки решили сообщить уже сейчас, чтобы желающие попробовали и дали фидбэк.
Чтобы вас восприняли всерьёз, сразу укажите свои навыки в предметной области: например, если речь о портировании компилятора, то опишите свой опыт коммитов в апстрим (или поддержания форка), либо опыт развития других аналогичных проектов. Если написать что-то сомнительное — типа «Хочу портировать FreeBSD, не хватает только кодировки команд процессора!» — вряд ли кто-то захочет тратить на вас время.
— Вот когда портируете ядро, тогда и поговорим.
— Вот когда создадите дистрибутив, тогда и поговорим.
— Вот когда опубликуете дистрибутив, тогда и поговорим.
— Вот когда опубликуете исходники системы сборки пакетов, тогда и поговорим.
— Вот когда опубликуете исходники прикладных пакетов, тогда и поговорим.
=== Вы находитесь здесь ===
— Вот когда опубликуете исходники ядра, тогда и поговорим.
Если хотите всё сразу, то приходите работать в МЦСТ — возможно, высвободите чьи-то руки, чтобы ускорить этот процесс. А пока что не за вами ведь придёт товарищ майор, если в опубликованных исходниках обнаружатся фрагменты, которые не подлежат публикации: образно говоря, они были написаны на деньги товарища майора, и только он имеет право их запрашивать, а вы за них не платили, поэтому требовать их не можете. Ибо не достаточно только лишь автоматически прогнать исходный код через
unifdefи т. п. — надо потом вручную перепроверять результаты.Реальное положение дел:
Так и живём. Дистрибутив прогрессирует, может, и не так резво, как мировые лидеры, над которыми трудятся сотни-тысячи людей, но всё равно существенно: оценить это можно по изменениям перечня пакетов и их версий, приведённым в описании на вкладке «Состав»; и это ещё туда не включены архивные ветки 2.x, про которые здесь на Хабре писали, сетуя на старые версии пакетов, — хотя всего-то 5 лет прошло.
Да, туда не входят исходники ядра, но это пока: не всё же сразу удаётся оформить в виде готового к потреблению devkit'а. А тем разработчикам операционных систем, которые сами с усами (Альт, Астра), все необходимые исходники передавались задолго до формирования PDK как продукта.
lsb_releaseидентифицирует себя как Debian, объясняется тем, что так проще, чем переписывать кучу configure, Makefile и install.sh в сторонних программах, которые кто-нибудь пытается скомпилировать. По той же причине фирменный компилятор LCC выдаёт себя за GCC, насколько это возможно, хотя внутри не имеет с последним ничего общего.Просто интересно: какие пакеты-«индикаторы» вы считаете признаком наследия Debian? Считаете ли вы, что именно набор прикладных пакетов определяет сущность дистрибутива, а не, например, система сборки этих пакетов в сочетании со сборочными инструкциями?