Компания Google развивает новую сборочную систему Soong, призванную заменить собой старые сценарии сборки платформы Android, основанные на использовании утилиты make. Soong предлагает использовать простые декларативные описания правил сборки модулей, задаваемые в файлах с расширением ".bp" (blueprints). Формат файлов близок к JSON и по возможности повторяет синтаксис и семантику сборочных файлов Bazel. Код написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51769
> призванную заменить собой старые сценарии сборки платформы Android, основанные на использовании утилиты makeОни же, вроде бы, уже заменяли make на cmake?
Речь о сборке OS.Известную сцену из Зелёного Слоника с CMake они разыгрывают для обычных разработчиков.
Как-то пофиг на Goolag, давно перестал пользоваться его шпиoнскими сервисами. Благо, есть достойные свободные альтернативы: Duckduckgo, Nextcloud, Protonmail, Mobilizon и т.п.
Protonmail вычеркните из списка - там крайне мутные хозяева.
Швейцария? Мутная? За "немутной" я так понимаю полетишь на Марс? :)Или ты очередной мамкин какиръ, свято верующий в непогрешимость и "непробиваемость" VPS?
> Protonmail вычеркните из списка - там крайне мутные хозяева.а где немутные и, главное - откуда они такие должны вот браться?
Ты вкладываешь непонятно где взятое бабло в супер-защищенный (от внезапного маскишоу в том числе!) datacenter, супер-защищенные сервера с наплатным нереверсимым шифрованием, разработку софта, ежедневно платишь за каналы и электричество самосвалы бак...франков... Кормишь адвокатов, потому что к тебе приходят, с запросами.
И где профит? Ну хоть в десятилетней перспективе? Опеннетовский анонимчик, понятно, заплатит хрен да нихрена. А кто заплатит - босс мафии? А ему надо так палиться? Он скорее как раз выберет самый незаметный, самый бесплатный из всех бесплатных акаунтов. Добрые дяди-меценаты? Держи карман шире!
Где деньги, я вас спрашиваю?
Протон - очевиднейший honeypot. Тем более что благословенная швейцария состоит в интересных организациях по защите мира от интерн...терроризма.
И в чём новость? Этот сунг у них с Android 6, если мне память не изменяет.В 7 точно-точно используется.
в том что GO всех сделает за пару лет
В гуголе
В том, что система полезна не только для сборки андроида, но и других программ. При этом она малоизвестна - в гугле всего 18 страниц находится по релевантным запросам, причём большинство ссылок - либо мусор вроде дорвеев, либо на китайском языке. Релевантные же англоязычные ссылки же содержат только обзорную информацию. У меня не получилось эту штуку собрать, ибо собирается она самим собой. blueprint забутстрапился шелл-скриптами с горем пополам, а сунг - нет. А выглядит очень вкусно (декларативная модульная сборочная система, без джавы и питона, модули пишутся на goвно-ЯП с кучей модулей в стандартной библиотеке, при этом всё компилируется в небольшие нативные бинари, не требующие goвна), безусловно надо попробовать заменить им CMake.
Ой как вы достали уже с очередной говносистесьоркой. Выучите уже make cmake ну или meson или premake. Но неееет мыж смузи мамкины хацкеры, нам вот тока еще одной не хватает как scons или waf. Че гугл базеля не хватило рынок зохавать?
Коварная система сьехать с Андроида на Фуксию. Все к этому и идет, помяните мое слово, когда придет.
Ну съедут, ну и хрен с ними. Можно подумать что Линуксу сильно помогло что он является базой для Андроида.
Ещё как. Правда, для embedded Linux.
Разверни мыслю! Интересно, куда оно там помогло.
Главное понять на какой градус разворачивать и какой стороной...
Читал мнение одного embedded Linux-разраба, который сказал что лучше бы Linux'а там и не было, так как поддерживать низкокачественный код для поддержки зоопарка SoC тот ещё подвиг.
значит такой прораб )))))В целом ничуть не сложней чем для WS - пример centos7 для arm7 - тому подтверждение.
Создал DT для своего SoC - получается обычная система.
Быстрее на линуксы на смартфонах съедем
Э-х-х... Мечты. Я как-то сталкивался с Meego (его тогда уже Интел курировал), это было просто супер. Мне тогда поставили задачу портировать наш софт под эту систему. Самый обычный Линукс. Без какой-либо тивоизации и прочего ДРМ-шлака. Но не взлетело.
Что не "не взлетело", ваш софт или вообще про Meego?
Они все вместе не взлетели. Кэп.
Обе штуки. Нам тогда Интел выдал оборудование с 945 видеокартой (это не драйвер, а индекс видеокарты, а мы писали 3D-штуку) и всё было плохо. На тот момент карточка уже устарела без шансов. Поэтому и портирование заглохло.
А почему Мигоу заглох я не знаю. Выглядело отлично. Андроид со своей Ява-привязкой и рядом не валялся.
Нет софта, нет разработчиков, на чём писать игры под MeeGo непонятно и самое главное, intel видимо в отличии от гугла недостаточно хорошо рекламировал широкие возможности шпионажа за пользователями на своей платформе.
> Нет софта, нет разработчиков, на чём писать игры под MeeGo непонятноПод Линукс нет софта и разработчиков?
Сорта гoвна... Лучше съехать на LineageOS.
на Replicant же.
Фукция имеет какие-то преимущества? Зачем вообще они ее пилят?
Чтобы заблокировать использование, кроме как для своего бизнеса.Чтобы не зависеть. От Линукса, например.
Да, там есть пару классных фич, ради которых можно без оглядки забросить линукс.
Если рассматривать архитектуру ядра, то там она микроядерная — мечта здешних опеннэтчиков. Микроядро имеет множество плюсов, в основном связанных с безопасностью и надежностью.
Традиционно, в том числе и Торвальдс, критикуют микроядра за эдакую "академичность" и уступающую производительность. Дело в том, что ключевой элемент в микроядре — IPC-механизм, который обходится ОС существенно дороже нежели прямые syscall-вызовы (с одной оговоркой). Спор давний, аргументированный, но... теряет свою актуальность:
- сначала оговорка: микроядро уступают по производительности монолиту в *нынешней* архитектуре компьютеров, которая не меняется уже более полувека. В этом-то и суть и невероятная новость (в основном спекулятивная): гугло готовит новинку SoC, новый архитектурный дизайн машины для микроядра, в котором оно раскрывается во всей красе на аппаратном уровне;
- исследователи публиковали данные, что уже сейчас производительность системы на микроядре на традиционных машинах уступает всего на 5% ядру Линукса;
Практически весь юзерспейс линукса используют IPC, который в парадигме монолитных ядер является скорее тормозящим, ухудшающим фактором. Напомню, сами разработчики ядра линукса во главе с Greg Kroah-Hartman уже давно пришли к идее развернуть DBUS в ядре, что позволит ввести многочисленные техники оптимизации. Однако их многообещающий проект kdbus так и не выстрелил, ибо IPC в монолитном ядре — это противоречие в самой архитектуре ядра, ведущее к многочисленным проблемам и уязвимостям. А dbus в пространстве пользователя — это неэффективный велосипед. В микроядрах, в свою очередь, IPC — есть ключевой элемент и изначально достоинство системы;IO ядра Fuchsia (Zircon) асинхронные. Это оригинальная новинка по достоинству будет оценена разработчиками будущей ОС. IO линукса синхронные: они исполняются на том же cpu-ядре, на котором был осуществлен вызов. В Zircon обработка io-запроса может быть на другом cpu-ядре. Это же касается и конвеерной обработки инструкций.
Если Fuchsia сравнивать, то ядро линукса монструозное - более 15 млн строк кода. Вопросы поддержки ни раз поднимались сообществом по этому поводу. Ядро Fuchsia очень маленькое.
В графическом стэке Fuchsia не предусмотрена прослойка всяким композиторам, вэйландам, прослойкам и т.п. Тут я не специалист, но вэйланды здесь рядом не стоят. В сорцах Fuschia читайте Magma Overview \ Design. Да, лет 5 назад у меня были оптимистичные надежды, что с приходом вэйланда в графическом стэке линукса все улучшится. Но нет. Нет, и этого не будет никогда. Подсистемы линукса в идеале работают только те, над которыми работают крупные компании только для их специфичных нужд.
Fuchsia необремененна long term требованиями с поддержкой технологий 20-30-40 летней давности. Она открыта для инноваций с оглядкой на современность.
Fuchsia модульна. Fuchsia создается с идеей в голове, что она будет внедрена от IoT до облаков (как гипервизор, насколько я слышал она уже используется).
Да, гугл может впилить свою телеметрию, свои зонды, но проект Open Source — 100% будут сборки энтузиастов, ungoogled zircon и т.п.
> Если Fuchsia сравнивать, то ядро линукса монструозное - более 15 млн строк
> кода. Вопросы поддержки ни раз поднимались сообществом по этому поводу. Ядро
> Fuchsia очень маленькое.драйвера то в этой Fuchsia будут? и строки вы б привели для линукса без дров, для сравнения то
> Да, гугл может впилить свою телеметрию, свои зонды, но проект Open Source
> — 100% будут сборки энтузиастов, ungoogled zircon и т.п.лицензия какая? бсд "опенсорс" не очень то помогает
Не содержит условных операторов... Ха. А это что:```
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
```
Определение двух параметров, которые потом будут обработаны программой на Go.
Это... Програмисты "там" информатику не изучают как таковую, поэтому терминология очень хромает. Оператор выбора отдельно, условный отдельно... Потому что так проще запомнить.
Русские программисты самые лучшие на свете, а пиндосы ну тупые.Термин "оператор" осилишь сам изучить?
> Не содержит условных операторов... Ха. А это что:А это декларативное описание проекта. Для того, чтобы говорить об условном операторе тебе нужен императивный стиль программирования. Ты, я предположу на основании того, что вижу, всегда мыслишь о программировании в императивном нарративе и иначе не умеешь. Тебе стоит попробовать расширить сознание чутка. Сложно дать совет как это сделать -- у нас нынче грозят чуть ли не уголовным наказанием за пропаганду веществ, но попробуй haskell в качесте легальной замены. "Попробуй", это в смысле нырнуть туда на полгода, отказаться от C, bash, python, R и всего остального, что ты используешь, и пользоваться только haskell'ом. У твоих мозгов просто выбора иного не будет, кроме как выйти за пределы доступного им и начать осваивать новые горизонты. За полгода ты вполне можешь освоить язык и попытаться написать что-нибудь _эдакое_, что потребует изучения всяких специальных техник программирования на языке, и соответственно изучения чужого кода, и попыток проникнуть пониманием в то, как думают другие ("каким местом надо думать, чтобы придумать такую хрень?"), и вот тут при любом iq выше 85 просветление неизбежно. Всё что тебе нужно, найти то самое место, которым некоторые иногда думают, и тоже научится им пользоваться для того, чтобы думать. Истинно просветлённый должен уметь думать любым местом, в том числе и теми, которые эволюционно не приспособлены для этого.
как же достали корпорации типо гугла. очередной ботнет.
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}это же один в один qbs, почему бы им тогда его не взять?
Свой велосипед роднее
Нет, это один-в-один их же собственный gn. Развитием которого сабж, скорее всего, и является.
Где-то в Гугле: итак, у нас есть 15 несовместимых друг с другом сборочных систем..
"А давайте сделаем еще одну!"
Но ведь когда-нибудь мы все-таки сделаем самую лучшую! ;)
Причем все 15 написаны гуглом.
Так очень много разработчиков и мало толковых менеджеров понимающих куда двигать компанию вот и пишут свои "вертолеты".
хобби?)
кто-нибудь еще понял референс к доктору сунгу, сборщику андроидов из Star Trek: TNG?
В гробу мы видали декларативность на JSON, если честно.
Лучше декларативность на json, чем декларативность на bash.На деле, я не знаю форматов которые были бы существенно лучше чем json для подобных вещей. Есть всякие там toml и вариации, они лучше json тем, что меньше скобочек надо, но это детали и нюансы.
Скажем, если сравнить с лиспом, то предпочтение json'у такой записи:
(cc_library
...
:srcs ("generic.cpp")
:arch (
:arm (:srcs ("arm.cpp"))
:x86 (:srcs ("x86.cpp"))))можно объяснить только личными предпочтениями.
> На деле, я не знаю форматов которые были бы существенно лучше чем json для подобных вещей.А я знаю - yaml.
> А я знаю - yaml.Для пользователя он хорош, но его спека очень сложная и я был удивлен, узнав, как мало софта поддерживает yaml в полной мере.
Но если выделить некий сабсет yaml (возможно какую-то из ранних версий) чисто для замены json, то будет очень даже ничего.
Все тебе плохо, а что хорошо ты и сам не знаешь!
Что-то маловато сборочных систем. Хочу, каждая программа собиралась своей системой сборки. И чтобы у каждой системы сборки была своя система сборки. И...
> Что-то маловато сборочных систем. Хочу, каждая программа собиралась своей системой сборки.Двумя!
> И чтобы у каждой системы сборки была своя система сборки. И...
Бутсрап (не путать со страпоном) через 18 штук. https://lists.gnu.org/archive/html/guix-devel/2019-10/msg006...
> Бутсрап (не путать со страпоном) через 18 штук.С 2006 года использовал в качестве десктопной системы LFS.
До 2012 года радовался, всё было просто и удобно.
В 2018 необходимость собрать новый firefox с его растом и попытки собрать раст из исходников, а не скачать блоб-доверьтесь-нам, стала последней каплей, перешёл на бинарный дистр.Спасибо тебе Мозилла за опенсорс, который на практике только невменяемый будет ставить не из блобов.
Хм. А gcc откуда бутсрапится? При инсталляции собирается цепочка компиляторов с восемьдесят забытых годов? Или таки бутстрапится с бинарного блоба?
> Хм. А gcc откуда бутсрапится? При инсталляции собирается цепочка компиляторов с восемьдесят
> забытых годов? Или таки бутстрапится с бинарного блоба?Маньяки https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-b.../
собирают Mes-ом gcc-N-кактой-то, им собирают gcc-M-какой-надо...
> Маньяки https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-b.../
> собирают Mes-ом[пропустил, не проверил] ... подрихтованный tcc, этим tcc собирают ...
> gcc-N-кактой-то, им собирают gcc-M-какой-надо...
> А gcc откуда бутсрапится?Вы глупый и правда не понимаете сути проблемы?
Ну так объясните. Бутстрап gcc без бинарных блобов пока не реализован. Бутстрап rustc без бинарных блобов пока не реализован. В чём суть проблемы?
Так в LFS gcc как раз таки не из блоба. Там он собирается в несколько проходов. А усложнил все Мозилла со своим Фаерфоксом.
> ну так объясните.Хорошо, постараюсь.
> Бутстрап gcc без бинарных блобов пока не реализован.
C почти полвека, C++ больше 35 лет, расту лет 5 от силы.
C/C++ имеют кучу реализаций (и если одна из них помрёт, можно будет пользоваться остальными), у раста же реализация - единственная (причём контролируемая компанией, которая сама на ладан дышит).
C/C++ есть на куче платформ/систем, и если я хочу собрать LFS, то ситуацию "на моей системе нет C/C++ компилятора" представить очень трудно. Ситуацию "на моей системе нет раста" представить трудно лишь пока вы сидите на amd64, и даже в этом случае это вполне вероятно.
Для C существует куча стандартов (C89, C99, C2001), для C++ стандарты и вообще каждые три года выходят. Для раста стандарта нет ВООБЩЕ, разработчики лишь добавляют то, что хотят, а остальные бегут за паровоз^Wпрогресс^W"прогрессом".
Что было написано на C 20 лет назад, будет собираться и сегодня (с поправкой на нестандартные библиотеки). Что было написано на расте 2 года назад сегодня вполне может не собраться. Будет ли раст существовать через 20 лет - вопрос риторический.
C/C++ является основным языком разработки года минимум с 85. На расте до сих пор написаны лишь ripgrep, librsvg и кусок файрфокса.Собрать gcc можно не имея блоба самого gcc (возможно, путём небольших правок исходников gcc), воспользовавшись другой реализацией C-компилятора. Собрать раст, не имея блоба самого раста, невозможно.
> Бутстрап rustc без бинарных блобов пока не реализован.
Не "пока", а "уже". Он изначально был написан на окамле, который собирался сишным компилятором.
Разработчики раста убрали эту возможность в последующих релизах. Зачем? Если такие умные, писали бы раст СРАЗУ на расте, и успокаивали себя этими сказочками про невозможность бутстрапа без блобов.Итого в общем:
1. C/C++ есть на любой системе. Бутстрап gcc без бинарных блобов просто не нужен, так как C/C++ компилятор есть всегда.
2. Раст есть только на системах, которые захочет поддерживать небольшая но очень гордая коммерческая компания. И бутстрап раста приходится начинать со скачивания блоба.Что касается LFS (с этого ведь началось):
1. LFS собирается в две стадии. Даже если предположить, что раст есть на хост-системе (а его запросто может и не быть, и что делать тогда? кстати, gcc есть всегда.), то в его необходимо собирать в /tools на временной стадии, увеличивая размер /tools. При этом избавиться от gcc не получится, так весь софт использует именно его.
2. rust сам по себе требует clang, и, как следует из описания выше, каких-то магических пассов вплоть до 18-кратного бутстрапинга, чтобы его можно было использовать для сборки того же файрфокса. За это время можно собраться весь LFS плюс иксы плюс какой-нибудь i3 и уже начать пользоваться компьютером.
3. Вслед за rust придут другие. Куча недоязыков типа раста, которые мнят из себя нормальный язык, и каждый пакет будет требовать своего языка. /tools, предназначенный для сборки минимальной ВРЕМЕННОЙ системы, будет разрастаться до полноценного дистрибутива только из-за того, что кто-то не может сделать нормальную сборку без бутстраппинга.
Спасибо за развёрнутый ответ.То есть те же проблемы, что были у С в начале существования: необходимость как-то портировать компилятор на новые платформы и наличие на платформе единственной реализации компилятора.
> 1. C/C++ есть на любой системе [...] gcc есть всегда.
Ну, почти. На некоторые платформы компилятор просто не влезет. Кросскомпиляторы есть почти для всего - да.
> 1. C/C++ есть на любой системе
Но что это значит конкретно? Это значит, что на инсталляционном образе лежит блоб с бинарником компилятора.
> 3. Вслед за rust придут другие
Раз в 50 лет - нормально. Не повезло жить в эпоху перемен. Бывает.
> То есть те же проблемы, что были у С в начале существованияНе совсем. У любой системы есть основной sdk. В существующих *nix это C/C++. В Android это Java или C. В Windows это C для низкоуровневых компонент и C# для высокоуровневых. В любом случае, для разработки всегда доступен C.
Для всех современных систем раст является инородным, а C если не основным, то по крайней мере активно поддерживаемым. Поэтому для человека в здравом уме реализовать раст на языке C для существующих платформ - было бы нормой.
Если Redox взлетит и будет используема мной, то я точно так же буду ныть, что в redox C-компилятор требует скачивать левый блоб с какого-то сайта вместо сборки уже имеющимся раст-компилятором.
Моя основная претензия не техническая (у меня нет проблем с тем, чтобы запустить блоб, или 90 часов собирать файрфокс), а логическая. Есть основной sdk. Мозилла, вместо того, чтобы органично интегрироваться с ним, создаёт нечто инородное в своём традиционном стиле (вспомним поддержку гтк-тем файрфоксом), не особо заботясь об экосистеме, в которую внедряется.
Если что, есть такая штука как trusting trust attack. Достаточно одного бинарного блоба, чтобы компрометировать все компиляторы, собранные с его использованием.
И в завистмостях сборки чтоб руби, две - три версии питона, го и братефак!
Брейнфак, вестимо
Не, это слишком просто. Братефак - это новый язык, который нужно будет собирать отдельно.
Ну, кому моск, а кто и братюню предпочитает...
Лучше баш скриптов наверну чем юзать это поделие.
В бизнесе просто: оно даёт денег? Если да, то и 18 и 135 сборочных систем будет написано.Т.к. это даёт доход.
А искусство красивых вещей редко кому надо.P.S. Гляньте в Го Лэнге формат для строки с датой и временем. Халтура. Жаль, что взлетло. Но бизнес оказался в прибыли.
Башскрипт это довольно адовый язычок в плане синтаксиса...
У вас смузи расплескался от недовольства. Баш в плане синтаксиса золотой стандарт. Он может все.
Например чем?
ох, вы бы видели powershell. на bash бы после молились..
>Формат файлов близок к JSON и по возможности повторяет синтаксис и >семантику сборочных файлов Bazel. Код написан на языке Go
>и распространяется под лицензией Apache 2.0.
>сборочную систему
>призванную заменить собой СТАРЫЕ сценарии сборки
>основанные на использовании утилиты makeПеревожу на человеческий:
Времена меняются, опытные старички профессионалы не вечны, и они уходят, на место приходят новые "специалисты", стильные-модные-молодёжные, они неосиливают этот ваш ретроградный make и СТАРЫЕ непонятные сценарии, от них они нервничают, пролевают смузи на свитшоты, и фсячески фрустрируют, нужно чтобы во имя инклюзивности им тоже было хорошо, а ещё во имя моды и борьбы с ретроградством, во имя развития, всё что можно переписать на JSONы и прочее модно-молодёжное, на Go, а потом, в будещем, и гладишь окончательно победим старпёрство и всё на электроне будет, так победим!
всё на электроне будет -- а электрон как известно, так же неисчерпаем, как и атом. ;)
Надеюсь скоро электрон зaкопaют, вместе с его создателями!
>Надеюсь скоро электрон зaкопaют, вместе с его создателями!Нет, брат, Анон, тенденции говорят о том, что наши надежды не оправдаются и в конце концов будет SystemD_OS написанное на электроне и управление всё через вэбморду, и чтобы это всё работало надо будет каких-то несколько десятков Гб ОЗУ!
Надеюсь в экосистему линукс эти электроны никогда не пролезут.
ГНУ... А нет подождите... Лично Столман... Хотя... Кто-нибудь нас спасёт, не переживайте.
> ГНУ... А нет подождите... Лично Столман... Хотя... Кто-нибудь нас спасёт, не переживайте.Экосистему "Линукс" спасают Джим Землин и Микрософт. Помощь рядом! </>
Компьютеры превратятся в терминалы с электроном. А все вычисления будут происходить на серверах.
ошибочка. в чем профит бизнеса? если нет больших объемов продаж электроники и чипов, то профита нет. следовательно будут все дальше уходить от компилируемых языков в пользу скриптовых, которые жрут поболее. следовательно требуются машинки многократно мощнее с каждым выходом новой оси. вот он профит. а ты о терминалах с серверами. как говорится "кому выгодно". раньше вообще был си/с++, баш,питон, ява и парочка других и то умудрялись все так загаживать производительность с каждым выпуском. а сейчас эти электроны только массовее будут. во первых проще набрать индусо-клепателей, во вторых нагрузка на мощное железо тоже. итог комп в 10 раз мощнее, а производительность таже, но зато ребята хотите шустрее быстрее на апгрейд.
Видишь ли, бизнес он разный. Что пойдет на пользу одному виду, то может оказаться во вред другому.
На производителях железа свет клином не сошелся.
верно, но основной контингент будет стремиться продать железо. а без него все ПО это только оболочка. даже гугол будет в тисках не имея подходящего оборудования. он может тролить всех только из за засилия андроидоподелия и хрома, которые работают на железе. и его должно быть много, чтоб он был монополистом.))
а твои данные они через свой анонимайзер облачный снимут. как фоксовцы или гуглята))
ILC на них нет…
>опытные старички профессионалыКакие они на хрен профессионалы, если не умеют в архитектуру. Их гοвнoскриптами я не смогу собрать их поделие - у меня другая система, другие компиляторы и другие их флаги. А их скрипты завязаны на конкретный компилятор. Если я вижу такое, я обычно первым делом переписываю всё на CMake. Вторым выкидываю все бандлованные зависимости и приделываю либо autodiscovery, либо загрузку из гита свежайших версий. Третьим делом я приделываю самописный скрипт, который по максимуму включает все функции безопасности, которые найдёт в компиляторе. И только после этого этим хоть как-то можно пользоваться.
А что ты умеешь, кроме критики с дивана? Какая от тебя польза?
>Код написан на языке Go и распространяется под лицензией Apache 2.0.Косяк, надо чтобы был на GPL v.3+
>>Код написан на языке Go и распространяется под лицензией Apache 2.0.
> Косяк, надо чтобы был на GPL v.3+Отлично! Купи Гугль и перепиши их лай-сенс гадлдайны.
Не отказывай себе в удовольствии.
больше жырных фреймворках на жырных фреймворках
Пзц опеннет в гшугле забанили.
Развивает это уже примерно 4 года как.У меня для опеннет лучше новсть есть: гугл развивает новый язык ява для разработки под андроид.