Comments 74
Это конечно прекрасно, а где взять сам Эльбрус?
Зачем, интересно, сделали платной для рабочих станций? 5к рублей. Зачем ставить пейволл? Там продаж этих будет минимум, нет бы десктопную версию сделать опенсорсной и собрать сообщество с обратной связью. Можно было бы развернуть, потыкать, но ради интереса платить 5к — желание сразу пропадает.
http://mcst.ru/elbrus_linux
Еще и через запрос через сейлзов.
"раскрытие кода — это желание компании подробно рассказать об архитектуре «Эльбруса» как можно более широкому кругу людей, а также сформировать международное коммьюнити разработчиков."
говорят одно, а делают другое.
Тот же вопрос, стоил бы он в рамках 300-500$ то я бы из спортивного интереса взял бы себе домой под всякие простые задачки типа шары/веб сервера.
под такие простые задачки, может, и получится нарыть где-ть 2С+ в эти деньги, только на него придётся старенькую OSL4 ставить; а так -- взял себе из спортивного и меркантильного интереса 16С (немножко дороже, правда), пишу вот с него, рядом повод для ещё одной статьи крутится :-)
сейчас эльбрус -- это по факту limited edition для тех, кто понимает, за что именно переплачивает; не стоит набегать без приличного опыта в линуксе и ясного понимания хотя бы по ssh (но на самом деле гораздо лучше щупать живьём -- скажем, в московском яндекс-музее на Фрунзе или в новосибирском музее вычтехники Дмитрия Бачило).
для обычного пользователя(tm) местами тоже годится, но как и на x86 -- система должна быть приготовлена и сопровождаться специалистом.
Он как раз в таких пределах и стоит, мы по крайней мере покупаем по такой цене. По какой его продает Максим Горшенин не знаю, но врядли сильно дороже.
Я правильно понимаю, что новость про то что они сделали то, что согласно GPL обязаны были сделать ещё давным давно? Или тут ещё что-то?
GPL не обязывает выкладывать исходники в прямо публичный доступ, особенно для тех, кто не является клиентом. Они в том числе могут распространяться хоть на пачке дискет, с предварительной оплатой пересылки тем, кто их запрашивает (без иных способов распространения)
То есть они уже были публичны (через другие механизмы, но раскрыты и доступны) и заголовок статьи про "раскрыла" несколько не точен, новость только про портал?
То есть они уже были публичны (через другие механизмы, но раскрыты и доступны)
Не совсем. Они были доступны честным приобретателям по запросу (причём только благоприобретенной версии). Приобретатель мог раскрывать их публично, а мог и не раскрывать. Поэтому заголовок про "раскрыли" и "публичный доступ" вполне точен. Явная официально-публичная, поддерживаемая, относительно свежая версия - это довольно сильно не то же самое, что вероятностно доступная по лицензии неизвестной давности. На мой взгляд, новость вполне достойная публикации (хотя лично я ко всей этой эльбрусовозне оочень скептично настроен).
особенно для тех, кто не является клиентом
Тут нет. В лицензии нет ни слова про "клиент". Более того, GPL явно разрешает передавать полученные бинарники (GPLые) с передачей права на запрос исходников. Поэтому строго говоря у компании вообще нет возможности отличить клиента от не-клиента и они любому кто пришел к ним с запросом "исходники на бочку" обязаны ответить с момента как случилось первое распространение.
Они в том числе могут распространяться хоть на пачке дискет, с предварительной оплатой пересылки тем, кто их запрашивает (без иных способов распространения)
GPL обязывает давать исходники схожим способом, как распространялись (пункт 5 лицензии - там явно говорится что способ распространения должен быть схожим - то есть если клиент скачал по HTTP то надо через сеть интернет ему исходники передать) бинарники любому владельцу бинарников (с момента как случилось первое распространение).
И есть лимит на стоимость - должна быть по цене носителя.
Как раз включено чтобы не было "да, пожалуйста, мы вам дадим исходники разбитые на дискеты по 1 байту на дискету, с вас 100500 млн за пять грузовиков дискет".
Обязанности выкладывать их в публичный доступ конечно нет, компании это напрямую выгодно так как снижает затраты на обработку запросов от страждующих.
По-моему в контексте RedHat эта проблема обсуждалась. Мол контракт расторгается или что-то типа того. Иные утверждали про лазейку в GPL: отношение между разработчиком и пользователем меняется на разраб-тестировщик, что не попадает под лицензию.
Это так набросал, для дальнейших поисков. Больше всего инфы по прениям лицензионным должно быть на английском.
Мол контракт расторгается или что-то типа того.
За передачу бинарников можно расторгнуть контракт на поддержку. Это вам никто не запретит.
отношение между разработчиком и пользователем меняется на разраб-тестировщик
Не получится. Факт передачи есть, у тестировщиков полный набор прав на GPL код. Об этом в FAQ к GPLv2/v3 простым языком рассказано.
Так в этом одна из проблем GPL для проприетарного кода - его юридически нельзя закрыть за всякими NDA, а с момента первой передачи законы о коммерческой тайне его также перестают защищать.
Не получится. Факт передачи есть, у тестировщиков полный набор прав на GPL код. Об этом в FAQ к GPLv2/v3 простым языком рассказано.
Вот только бред не пишите и не вводите людей в заблуждение. Вам уже несколько раз приводили ссылки, что это не так. Права на GPL есть только у законного пользователя, но не у наемного работника или вора компакт диска с ОС.
что это не так.
Вы сами читали то, на что сослались-то? Конкретно кусок:
The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right.
Я специально жирным выделил релевантный кусочек.
Права на GPL есть только у законного пользователя, но не у наемного работника или вора компакт диска с ОС.
Вы уже в нужном месте были, почитайте FAQ чуточку дальше (Stolen CD прям в FAQ есть). Плюс я запрос повторю уже в третий раз: покажите кусок в лицензии где сказано "у законного пользователя". Вы почему-то этот запрос упорно игнорируете, так что даете мне все основания считать что вы лицензию не читали и не понимаете.
Вы похоже не понимаете самих базовых юридических принципов действия лицензий.
Лицензия это прежде всего договор и перед тем, как у кого либо возникнут по нему обязательства (в том числе по передаче исходников, как в GPL), требуется его заключение между сторонами. т.е. выполнение определенных "конклюдентных действий".
В случае договора присоединения, которым является GPL, это может быть скачивание дистрибутива с сайта, заключение договора между юридическими лицами и т.д., но ни воровство компакт диска с дистрибутивом, ни исполнение своих должностных обязанностей тестировщиком (т.е. наемным работником), заключениями договора присоединения не являются.
Поэтому прежде чем ссылаться на какие либо собственные толкования GPL, вам нужно стать стороной этого договора, т.е. либо разработчиком проекта (закоммитить туда свой код), либо стать пользователем, выполнив конкретные "конклюдентных действий", определенные второй стороной договора.
Если у вас есть конкретная информация, опровергающее все выше написанное (а вы кажется писали, что уже озвучивали в судах свою позицию), скиньте пожалуйста ссылку на решение суда.
Я не увидел в вашем ответе указания на то, где в лицензии сказано "законный пользователь". Так что попрошу вас не распространять больше интерпретации, которые явно противоречат лицензии и FAQ на нее.
Если у вас есть конкретная информация, опровергающее все выше написанное (а вы кажется писали, что уже озвучивали в судах свою позицию), скиньте пожалуйста ссылку на решение суда.
Тут вы придумываете. Я говорил что я убедил несколько компаний согласиться с тем что написано в тексте лицензии и отдать исходники, в том числе убедить их что в суде их идея с "законный пользователь" не выстоит. Все досудебно. Так что про суды - ваши выдумки. Учитесь внимательно читать что вам пишут, впрочем такой подход к спору объясняет почему вы спорите с текстом лицензии.
То есть выходит, что у вас нет никакой реальной правоприменительной практики на основе ГК РФ, о которой вы писали, кроме как собственный интерпретаций FAQ на сайте интернете?
Тогда счастливо вам оставаться с верой в собственные заблуждения.
Тогда счастливо вам оставаться с верой в собственные заблуждения.
Как я уже вам выше сказал - вы умудряетесь выдавать ссылки, опровергающие вашу позицию за подтверждение (я про faq и NDA) и спорить с лицензией без каких либо фактов с вашей стороны. Вы уверены, что вера тут не с вашей стороны?
Вопрос риторический, можете не отвечать. И в дальнейшем, если вы будете вместо разбора лицензии и указания на конкретные пункты и формулировки, подтверждающие вашу позицию, снова делать магические пасы руками, я попросту ваши ответы будут игнорировать. Учитесь опровергать по существу.
Я говорил что я убедил несколько компаний согласиться с тем что написано в тексте лицензии и отдать исходники, в том числе убедить их что в суде их идея с "законный пользователь" не выстоит. Все досудебно.
После правки комментария, вы уже в явном виде написали, что у вас было только общение с другой компанией насчет выполнения требований GPL, но это не судебная правоприменительная практика, а только ваша интерпретация.
И я вам уже писал ранее, что в данном конкретном случае вы совершенно правы!!! Так как компания распространяла свои устройства в свободной продаже и прошивки у себя на сайте. В этому случае законным пользователем (с точки зрения заключения договора присоединения) является любой человек в силу наличия публичного договора оферты и что либо доказывать или покупать устройства (быть пользователем) действительно не требуется.
Что же касается темы статьи, то МЦСТ в такой ситуации оказался только с 2019 года, после публикации дистрибутива ОС на сайте. Но до этого времени (до публичного договора оферты на сайте), требования о раскрытии исходников GPL мог выдвигать только законный пользователь (не уверен насчет корректности данного юридического термина), но до этого времени ситуация была как с МСВС.
И выложили притом не все. Зажали binutils (GPL), uclibc (LGPL) и компилятора lfortran (использует GPL код - они тупо втащили кусок от gcc, кажется версии 5.4, в свое время и с тех пор технически должны свой lfortran фронтэнд выложить и свой бэкэнд целиком).
Меня больше смутило то, что это не git репозиторий в который планируются регулярные коммиты и прочие PR, а просто срез. Типа просили - на-те получите. Это конечно большое достижение, но не то, что требуется современным разработчикам.
Знаете, git репозиторий дело десятое. А вот полный набор исходников, которые обязаны по лицензии выложить - первоочередная задача.
И документация на ISA туда же, и описание модели памяти и публичный errata а не хедер в ядре с кусочками - это все первоочередная задача для МЦСТ, если они хотят привлекать разработчиков.
А git репозиторий можно пока и самостоятельно организовать сбоку.
Ну по мне так наличие живого репозитория с регулярными коммитами куда более важней чем неуклонное следование требованиям лицензий. У МЦСТ всегда к этому вопросу было пофигистское отношение и ожидать что они в корне его пересмотрят просто наивно. Но если они задумали подтянуть комьюнити, то следовало бы организовать это дело поприличней - репозитории, сайт с доками и wiki, форум/mail-list для общения разработчиков (а не закрытый телеграмм канал).
Не как образец для подражания, но хотя бы так:
https://github.com/MikronMIK32/
https://wiki.mik32.ru/Заглавная_страница
PS: Кое-какую документацию по E2K МЦСТ выкладывал в 2020 году.
Отлично!
Ну, тогда и https://www.opennet.ru/opennews/art.shtml?num=57658 стоит упомянуть. Там как раз binutils.
Только старенький. Кстати, можно еще попробовать спросить товарища @shigorin о истории появления. А то слухи ходят, что он напрямую в этом виноват.
Он правда меня обычно игнорирует, но можете у него сами спросить, вдруг таки расскажет.
Ну по мне так наличие живого репозитория с регулярными коммитами куда более важней чем неуклонное следование требованиям лицензий.
Тут я полностью не согласен. Неуклонное следование требованиям лицензии И доступный нормальный SDK И нормальная документация - это самое важное. Вики, форумы, чаты - комьюнити самостоятельно организует (смотрите на пример risc-v и loongson'ов тех же), и комьюнити может продолжить работать над проектом даже когда производитель от него откажется, было бы достаточно информации о нем.
PS: Кое-какую документацию по E2K МЦСТ выкладывал в 2020 году.
Что далеко от нормальной документации на ISA и не содержит ровным счетом ничего о модели памяти и нету errata - без этого платформа вообще говоря обречена на забвение, даже если была бы хорошей (а с этим у Эльбрусов все тоже очень плохо).
Не знаю чем вы слушали но Трушкин как раз это и сказал что сделали публичный репозиторий куда можно слать патчи git.openelbrus.ru
А где я должен был его слушать ? Я читал статью здесь и на сайте ТАСС. В статьях упоминается некий сайт https://dev.mcst.ru/ , на нем присутствуют ссылки для скачивания трех тарболлов с исходниками. Больше я там ничего не нашел. Уже здесь в комментариях начали скидывать полезные ссылки на репозитории, в том числе на https://git.openelbrus.ru/mcst.
Стартап не выстрелил?
Однако вода камень точит. В огромной части это заслуга непосредственно Трушкина - долгая и методичная работа с главным заказчиком. Осталось избавиться от бессмысленных NDA для разработчиков.
Будете щупать "Эльбрус", хотя бы удалённо?
Зачем удаленно, у меня в соседней комнате стоит, правда старенький и слабенький - Э-1С+ и уже защупанный. Если еще что-то щупать, то скорее всего Э-2С3 - это более-менее современный СнК со встроенной GPU. Год назад была идея сделать на нём процессорный модуль и одноплатную ПЭВМ, но по финансам пока не срослось.
Процессорный модуль МП21 на Эльбрус-2С3
https://www.sm1820.ru/2024/01/16/mp21/
Да, я в курсе.
Не вам одному пришла такая идея.
Как известно, "пусто место святым не бывает". :)
Может быть и к лучшему, что не ввязались в эту тему. Конкурировать с гос конторами бессмысленно.
Так процессоры ж не производится, есть ли разница?
Трушкин утверждает что они есть в наличии и их много, до 2030 года достаточно. А там уже свой литограф и массовое производство. ;-)))
Трушкин утверждает что они есть в наличии и их много
Много это сколько? Я смутно помню что всего Эльбрусов всех поколений меньше 100 тысяч было выпущено даже теоретически.
до 2030 года достаточно
Только при условии, что они никому не нужны.
А там уже свой литограф и массовое производство. ;-)))
А это вообще говоря очень оптимистичное заявление. Мало того что совершенно не факт что свой литограф к тому моменту вообще будет (вы, кажется, слабо представляете себе проблему и скорее всего невнимательно слушали доклады где уже сейчас заботливо раскладывают места, на которые будут вину за провал проекта списывать).
Ну и потом, если 100 тысяч процессоров всех поколений хватает для удовлетворения спроса на 6 лет, то, как думаете, процессор он как вино - с годами только лучше? Или все таки процессор скорее устаревает и становится ненужным, даже если был хорошим?
Только при условии, что они никому не нужны.
Подозреваю, есть области, где не нужно ничего, кроме процессора производства РФ.
Подозреваю, есть области, где не нужно ничего, кроме процессора производства РФ.
И какое отношение это имеет к произведенным на TSMC Эльбрусам?
Важно не фактическое место производства, а соответствующие документы и разрешения, где это произведенное разрешается использовать.
Была на Хабре статья, где человек жаловался на то, что даже резисторы, бывает, произведены в Китае, но по документам они - российские, и стоят на порядок дороже. И такие можно использовать при производстве некоторых устройств (по госзаказу), а иностранные (опять-таки, по документам) нельзя.
А про gcc забыли?
А GCC когда-то был под E2K ? ЕМНИП, долгое время был доступен только проприетарный ICC, и совсем недавно портировали LLVM.
Основной сыр-бор относительно VLIW архитектур как раз происходит вокруг оптимизирующего компилятора, которого толком и не было создано.
А GCC когда-то был под E2K ?
Они "golang" портировали через сборку gccgo (и gcc соответственно) старой версии, например. И как минимум в эльбрус-линуксе 7.2 у них был как побочный результат gcc 9.3.0.
Во-вторых - в lfortran используются куски gcc напрямую, поэтому они должны весь компилятор свой выложить под GPL.
долгое время был доступен только проприетарный ICC
ICC это Intel C/C++ Compiler, у МЦСТ компилятор называется LCC. Общее у них то, что они используют EDG-фронтенд. Часто баги компилятора общие, потому что общий фронтенд. Интел уже отказался от ICC и перешел на LLVM, теперь это называется ICX.
и совсем недавно портировали LLVM
Если корректно, то LLVM не портируют, в него добавляют бэкэнд для архитектуры. Это было сделано уже давно, но версия отстаёт от актульной, и обновляется скачками через несколько версий.
Исходники "порта" они выложили, но кодогенератора в исходниках нет, промежуточное представление передаётся в отдельную программу, исходники которой закрыты. То есть бэкэнд вынесен в закрытое приложение.
Так потому что нет там никакого LLVM:
Решение ожидаемое, так как архитектура LLVM плохо напяливается на VLIW, но итоговый код оно генерирует все равно отличный от оригинального lcc, причем очень сильно в худшую сторону. Нужна ли такая разработка которая генерирует заведомо паршивый код, может проще фронтенды для llvm пропатчить что бы они выдавали AST языка, или что им там надо для полноценного компиляния.
Или вообще поддержать GIMPLE он вроде похож на этот их EIR.
так как архитектура LLVM плохо напяливается на VLIW
А этому есть какое нибудь обоснованное доказательство? Потому что в LLVM есть поддержка VLIW архитектур, например DPU от Kalray, Hexagon DSP от Qualcomm и TeraScale (ака r600, архитектура что была до GCN и RDNA в GPU) от AMD.
То есть, как будто, практика показывает что заявление не соответствует действительности.
Есть вот такое обсуждение https://youtu.be/LgxD-Kcasy8?t=1206
Тут даже не про эльбрус, а про специализированные vliw cpu, коих много, и у всех свои проприетарные патчи для планировщика инструкций, там дальше где то разговор про предикаты, что он почему то предполагается только один.
(Отсебятина) LLVM и его IR это, как я понимаю стековая машина и байткод, выбрана такая архитектура либо просто для естественной безопасности, либо предполагалось что это будет универсальный компилятор для vm+jit в том числе.
Поддержка vliw хоть и изначально заявлялась, но еще опыт AMD показал что у разработчиков представление о vliw ограничивалось укладыванием инструкций в бандл.
Есть вот такое обсуждение https://youtu.be/LgxD-Kcasy8?t=1206
Послушал примерно 10 минут от данного вами тайм-стэмпа (пока обсуждали вопрос), там спикеры говорят что в общем разницы нет и с LLVM все можно нормально сделать.
Так что простите, но я пока не увидел никакой адекватной аргументации против LLVM.
и у всех свои проприетарные патчи для планировщика инструкций
Не у всех. В LLVM есть таргеты на LLVM чипы :)
(Отсебятина)
У вас в отсебятине отсутсвует аргументация. То есть вы на "опыт AMD" ссылаетесь как на факт, который на самом деле не факт. Поэтому не вижу смысла её разбирать подробно и предлагаю все таки без отсебятины обойтись и показать конкретные факты в поддержку вашего заявления.
Я не утверждал что нельзя сделать. Можно, преодолев при этом кучу ограничений и накидав в бакенд кучу специфичных анализов https://youtu.be/LgxD-Kcasy8?t=2543
Но если итог будет заведомо хуже кода который генерирует родной компилятор, то заниматься этим нет никакого смысла.
А не будет он потому что LLVM уже на верхнем уровне делает какие то общие оптимизации, которые в основном заточены на risc и совершенно не учитывают vliw архитектуры. Бакенду попадет в руки уже пережеванный код без прагм и рестриктов что уже даже пример компиляции через lccrt-IR демонстрирует - обычный lcc если ему хорошенько подсказок накидать он даже сложные вложенные циклы начинает по своему раскручивать/наматывать, подрубать apb, если чтения из кучи линейные, а вот с LLVM-IR раскрутки и apb врубаются только для элементарных циклов где и без подсказок понятно что можно применить.
Я не утверждал что нельзя сделать.
Вы утверждали "так как архитектура LLVM плохо напяливается на VLIW".
Я вам в ответ сказал, что LLVM используется фактически в основе компиляторов под большинство популярных VLIWов и это уже делает ваше заявление сомнительным.
Вы в ответ привели ссылку (дважды) где говорится о том, что все можно и все нормально в LLVM.
Но если итог будет заведомо хуже кода который генерирует родной компилятор, то заниматься этим нет никакого смысла.
А это тоже необоснованное утверждение, которое вам бы стоит доказать.
А не будет он потому что LLVM уже на верхнем уровне делает какие то общие оптимизации, которые в основном заточены на risc и совершенно не учитывают vliw архитектуры.
Вы сами привели видео (дважды) где люди это опровергают.
Бакенду попадет в руки уже пережеванный код без прагм и рестриктов что уже даже пример компиляции через lccrt-IR демонстрирует
Это демонстрирует, что lcc IR сильно отличается от LLVM IR, но никак не показывает что нормальный бэкэнд под LLVM будет хуже чем lcc.
а вот с LLVM-IR раскрутки и apb врубаются только для элементарных циклов где и без подсказок понятно что можно применить
Это все то же самое - отличие в IRе и скорее всего отсутствие опыта работы с LLVM у МЦСТ, а не фундаментальные проблемы компилятора.
LLVM и его IR это, как я понимаю стековая машина и байткод
SSA же - т.е. неограниченное количество временных регистров, а не стек.
Да, вы правы, совсем не стековая, но все таки сорт оф dataflow
А GCC они, вроде, собираются открыть позже.
Но "обещать" не значит "жениться"
Выглядит отчаянной попыткой. Нужно было лет 5 назад это сделать. А сейчас господдержка risk v и усилия программистов туда направлены.
Будем посмотреть, как теперь все эти действия повлияют на общую работу. Конечно это всё хорошо.
«МЦСТ» раскрыла исходные коды компонентов Linux, системных библиотек и ПО для платформы «Эльбрус»