Facebook представил новую сборочную систему Buck2, ориентированную на организацию сборки проектов из очень крупных репозиториев, включающих код на разных языках программирования. Ключевыми отличиями новой реализации от ранее применявшейся в Facebook системы Buck является использование языка Rust вместо Java и существенное увеличение эффективности и производительности сборочного процесса (во внутренних тестах в той же инфраструктуре Buck2 выполняет сборочные задания быстрее Buck в два раза). Код распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58933
>> Ключевыми отличиями ... является использование языка Rust*сердитое лицо*
>> вместо JavaНу ладно... :-|
Ох, я уже знаю человека у которого зачешется это применить...
Этим человеком был InuYasha?
Ипоня чтоли? Его порвет на куски еще при освоении гугловского базяля. В общем мегакорпорации за господство рубятся а у хипстеров лбы трещат.
Я бы попробовал, потому что на расте.Хотя, для сборочной системы это не критично.
Пусть она хоть на каждый чих в панику сваливается
>использование языка Rust вместо JavaЖабогадюкинг в действии.
>Для правил используется язык Starlark
К жабе и гадюке присоединяется бычий цепень. Говорю как человек, который патчил этот самый Starlark, чтобы он хотя бы не крашился на openbsd по-умолчанию.
Самое забавное что этот самый фейсбук проводит массовые сокращения, но при это занимает оставшихся людей откровенной фигнёй.
Какой фигней?
Откровенной же.
> который патчил этот самый Starlarkа какую из его реализаций ?
google/starlark-goТам проблема была, как обычно, в оверкоммите. Настоящий язык программирования, естественно, первым делом должен при старте выделить 2^32 памяти, иначе что это за язык какой-то жалкий и смешной.
У ФБ своя реализация на Rust: https://github.com/facebookexperimental/starlark-rust
Какая разница, где именно nih синдром?
А в плюсах? Firefox: куча процессов по 2+ GB VIRT, несколько по 20 GB, есть ещё даже 48 GB! И это при всего лишь 4 GB реальной оперативки.
Не в плюсах же, а в Firefox. Никто не запрещает стрелять себе в ногу. И даже так, Firefox работает под openbsd без моего (анонимного) участия.
Я вообще не понимаю, нафига какой-то starlark с несуществующей экосистемой, если есть python с существующей? Особо тяжёлая форма NIH-синдрома видимо.
еще и потхон тащить в зависимостях со всеми его кактусами-модулями.Жрите сами.
Тока сегодня собирал на маке redis-json. Официальная версия требует не просто потхон, но и brew и 10 раз проверит чо он там есть... Хотя если закомметировать то все работает и так <3 facepalm here>
Но ведь жабу в проект они тащили )На днях хотел побаловаться с webrtc - вот там говнища целая куча тянется вплоть до хромиума со всеми пожитками как одна из зависимостей
В общем где-то на 15 Гб
А в итоге - вылет с ошибкой, ведь сборка для андройда возможна только из под линукса
Там не совсем тривиально собирать, но в репе jabber-клиента Conversations есть интрукция по сборке .aar файла. Но да, нужно примерно 20 гигабайт хз-чего. Но существует ещё реализация WebRTC в gstreamer. Хотя тоже сорта коричневой субстанции, но там, вроде, и сам протокол непростой. Audio, dtls, stun+turn, ICE. Там немало трюков.
> Но да, нужно примерно 20 гигабайт хз-чего.Мне счас мозг вынесло... (x_x) 20 гигов скачать для сборки проги в 10МБ под андроид?
С Yocto не менее весело - 40 гигов и сутки сборки-скачивания ради образа линукса в 30 Мб
Чему там выноситься, дружище? Ты про Google Stadia слышал? Это 300 мегабайт в минуту потребления трафика только. 20 гигов -- это жалкий час игры, хотя геймеры шпилят сутками зачастую.Для гугла 20 гигабайт это даже не достойно внимания. 200 секунд качать на гигабитном канале.
Не слышал, но уже стрёмно, спасибо...
В том и дело что это самому и вручную реализовывать вообще не вариант - это не какой-нибудь MJPEG запилить
Поэтому начал копаться в уже реализованном. Хотя бы пытатьсяПомимо кучи постепенно введённых ограничений проблема в том, что практически все реализации WebRTC под капотом тянут весь функционал работы с камерой. И он крайне убогий.
Т.е обычно нет возможности удалённо сфокусироваться на какой-то конкретный объект, произвести промежуточную обработку кадра перед отправкой, а то и по ходу стрима сделать полноценную фотку в полном разрешении ( у трансляции качество гуляет в зависимости от сети и мелкие объекты обычно сильно мажутся. А фотка - по сути будет снимком экрана на котором отображён стрим, т.е ещё и размерами экрана будет ограничено ).
Хотя такие библиотеки и есть, но они не стримят( руки чешутся стрим прикрутить как раз вебртк-шный из-за чего всё и началось )Но больше всего что удивило - почти полное отсутствие качественной документации по нативным библиотекам WebRTC.
Они, как подобает, почти наверняка написаны на плюсах, а значит даже просто в андройде будет работать посредством NDK и потребует обёрток на жабе без возможности по человечески редактировать базовые исходники и нормально пересобирать.Практически никаких графиков, что куда и как идёт, жирнющих описаний с разжёвыванием и описанием структур данных чего сейчас обычно требуют даже на самый ерундовый проект, делаемый под заказ - просто высранная куча кода с горой папок, часть из которых ещё и докачивается по ходу дела( т.е внешний сервак отвалится и вообще хрен соберёшь )
Ещё и с костылями для андройда вроде флага "не прерывать сборку при ошибке" ( abortOnError false ).
Т.е даже не ворнинги - ошибки сыпятся и "это норма".Похоже, придётся брать уже предварительно собранную библиотеку и как-то это ковырять.
Но, почему-то, каждый раз как начинаю копать что-то серьёзное и опенсорсное - всплывает такая куча гомна, убогая архитектура и подход, что вообще удивляюсь как архитекторов и программистов за это палками до смерти не побили, а ведь им за это ещё и платили нехило, ещё наверняка и именуют "крутыми разработчиками"
Я чувствую твою боль, бро. С 2006 по 2021 использовал Linux From Scratch в качестве десктопа, и после 2010 года пошёл тренд делать монстров, которых из исходников можно собрать, только если компилировать руками, а не компилятором. У авторов оно, по-видимому, собирается только на машине разработчика, и в прод отправляется получившийся бинарь, вместо сборки релиза на отдельном сервере. Пропади машина и не найдись бэкапов - проект застопорится на пару лет из-за необходимости заново подобрать окружение, на котором оно соберётся, а то и вовсе помрёт.Справедливости ради, проприетарь не лучше. А если ещё и поддержки нет, то приходится вообще методом тыка и гуглинга на стеке решать, и то не всегда удаётся.
> StarlarkМне кажется попытка слепить из Python "безопасный" кастрированный вариант изначально обречена на провал. Уже сколько раз пытались использовать Python как встроенный язык, и каждый раз это оборачивалось провалом. Python не приручаем, он не для того создан.
>кастрированный вариант изначально обречена на провал.А вы знаете что игра Х3 (космический шутер) использует подмножество питона для внутренней механики? Правда продолжение вышло из за этого тормознутым,там в х4 можно было строить промышленные кластера,симулятия которых оказалась на пределе общета тогдашних компьютеров .Так что не все одназначно.
Можешь примерно рассказать, почему нельзя было использовать язык получше, кроме очевидного синдрома утёнка разрабов?
> Можешь примерно рассказать, почему нельзя было использовать язык получше, кроме очевидного
> синдрома утёнка разрабов?Да я откуда знаю что у разработчиков в голове творилось.Но полагаю что Яву из за жора памяти отвергли,а встроенное подмножесттво (пико и нано) стоило слишком дорого.NET задолбала на тот момент неопределенностью - новая версия и что нибудь поломано и народ по полгода ждет когда починят,неопределенность на тот момент с графическим движком (за 5 лет 3 библиотеки выпустили).Полагаю что с питоном знакомо много людей и из за этого и решили использовать встроенное подмножество,благо что графику решили без наворотов реализовывать.
Lua же?
Или Squirell, у него синтаксис привычнее. Хотя ничуть не умаляю достоинства Луа.
> использование языка Rust вместо Java
> Жабогадюкинг в действии.И всё равно любой из этих гадов в тысячу раз лучше простыней на shell script/Makefile.
Потому что ты не выучил ни мейк, ни шелл, но зато глубоко познакомился и с жабой, и с гадюкой?
Баш по скорости ещё хуже Питона, предлагать питон заменить на баш - надо быть совсем чокнутым.
Пила плохо приспособлена, чтобы ей строгать, ага.
Ну хоть какая-то польза от Фейкбука. Но лучше бы выделили проект в отдельный бизнес или фонд.
>Но лучше бы выделили проект в отдельный бизнес или фонд.Тогда сразу было бы понятно по сливу фонда, что проект никому не нужен.
Среди опеннетных "экспертов" - допускаю.
Эта штука может сделать ненужными cmake, cargo и т.д. или это надстройка, которая их использует?
Cargo же не только про сборку, а еще и пакетный менеджер. А так да, можно заменить Cmake, а можно встроить его как еще один язык.
> а еще и пакетный менеджерНемного не догоняю: каково может быть назначение пакетного менеджера конкретного языка в большом проекте на множестве разных языков?
Если эта система сборки такая же кривая и тормозная, как интерфейс ФБ, то спасибо, не надо...
Такое ощущение, что тебе кто-то навязывает эту систему.
Что только ни делают, лишь бы не использовать Nix.
Nix делает всё что бы не делать платную поддержку.
Когда сделают nix без убого nix, сразу перейду)
Nix самая лучьшая часть nix.
Особенно его дебажить, прям наслаждаешься
Уже сделали. GUIX называется вроде.
Ладно, поправка: нормальный императивный nix
((lisp ((любят ) только))) ((фанатики ) lisp))
И ещё любители скобочек.
(у тебя операторы попутаны)
> из коробки поддерживает сборку проектов, написанных на языках C++, Python, Rust, Kotlin, Erlang, Swift, Objective-C, Haskell и OCaml, используемых в FacebookА где JavaScript, TypeScript ? Они, можно подумать, не используются ни в запрещённом Facebook, нигде.
Фронтенд - это отдельная история, там всё не как у людей. Там не столько компиляторы в привычном понимании слова, сколько транспайлеры и бандлеры.
Надо учить Rust. Не зря говорят: не можешь победить - возглавь.
Лучше учи Си.
>>Лучше учи Си.+
++
>>Лучше учи Си.Си Цзиньпин
Калашников
Это вас поучат в воспитательных лагерях 9600 бод любить.С уважением, Пух.
Согласен
Ох как же любо рвёт икспердов от рессентимента. Это ж самая настоящая ревность =)
>Action - An individual, cacheable, ideally hermetic command that's run during the build. It takes artifacts as inputs and produces other artifacts as outputs. An example command could be gcc -o main main.c, which takes the artifact main.c (a source file) and produces the artifact called main (the compiled binary).Сразу нафиг. Ещё одни неудачники повторяют ошибки всех невзлетевших систем сборок. Компиляция не должна вообще касаться gcc и его флагов вообще каким-либо образом. Ибо я могу компилировать не с помощью gcc, а с помощью clang, или Visual Studio, и могуу не под хостовую систему, и могу вообще заюзать модуль, активирующий дополнительные фичи компилятора, такие как модули. И система сборки должна меня изолировать от всего этого маразма с кучей совершенно необходимых флагов для зоопарка версий компиляторов и прописанных в командной строке путей к зависимостям. CMake - взлетевшая адекватная система сборки. С отвратительным встроенным ЯП (который надо менять на питон, оставив всё остальное), но по крайней мере в Kitware не анцефалы работают (а те. благодаря чьей деятельности можно диагностировать анцефалию).
А вот перечисленный в примерах говнокод можно и на питоне вручную наговнокодить, и никакой системы сборки на расте для этого не нужно, только уже установленный в системе питон, библиотека sh для удобного запуска консольных утилит и библиотека click для удобного парсинга аргументов.
Предлагаю вам тут найти запуск gcc:cxx_binary(
name = "main",
srcs = ["main.cpp"],
link_style = "static",
)
У фейсбука не то что все прибито к конкретному компилятору, у них вообще свои компиляторы патченые.Смысл этой штуки в максимальной параллелизации сборки кучи бинарей из большой монорепы, с построением графа зависимостей и пересборкой только необходимого. Большинству людей это просто не надо. Выложили в опенсорс и выложили, молодцы, чо
> максимальной параллелизации сборки кучи бинарей из большой монорепыгде-то я уже подобное видел. и не один раз.
называется "вместо оптимизации размазать нагрузку".
например:
1) если веб-сайт не справляется с нагрузкой - поставить два или три сайта за реверс прокси с раунд робином.
2) если браузер типа хром не справляется с нагрузкой - породить кучу процессов, чтобы заняли все ядра CPU, а там пусть планировщик ОС разбирается кого куда.
3) ... многие вспомнят еще примерывнимание вопрос: можно ли такой подход считать антипаттерном ?
> 2) если браузер типа хром не справляется с нагрузкой - породить кучу
> процессов, чтобы заняли все ядра CPU, а там пусть планировщик ОСЭто сделано для изоляции адресных пространств.
CVE-2021-21194 - очень помогла та изоляция, не правда ли ?
а сколько еще таких CVE не найдено (не исправлено, не опубликовано) ?поэтому - отказать, это сделано для "динамичного веб-серфинга по современным сайтам",
как тут писал один молодой но резкий девляпс.
> CVE-2021-21194 - очень помогла та изоляция, не правда ли ?Даже не собираюсь смотреть, что там. Попробуйте как-то тоньше подменять тезис.
> а сколько еще таких CVE не найдено (не исправлено, не опубликовано) ?
И что?
> Даже не собираюсь смотреть, что тампотому что настоящий религиозник не должен читать
еретические тексты, а тем более их обсуждать.> Попробуйте как-то тоньше подменять тезис.
тезисы все те же:
1) ``изоляция адресных пространств'' - пздж архитекторов хрома,
т.к. против реалных дыр не помогает.2) следовательно, настоящая цель у них была другая.
3) какия именно другая ? см выше по треду.
>> Даже не собираюсь смотреть, что там
> потому что настоящий религиозник не должен читатьЧитать кого? Вы вообще кто? Есть свои наработки по теме, или только "читаете"?
> еретические тексты, а тем более их обсуждать.
Обсуждайте:
1. изоляция адресных пространств не перекрывает все возможные вектора атаки;
2. любая реализация на императивном языке априории содержит дефекты.>> Попробуйте как-то тоньше подменять тезис.
> тезисы все те же:
> 1) ``изоляция адресных пространств'' - пздж архитекторов хрома,Это тезис архитектора операционной системы Windows.
В Windows процессы не исполняются.
Исполняются потоки.> т.к. против реалных дыр не помогает.
> 2) следовательно, настоящая цель у них была другая.
> 3) какия именно другая ? см выше по треду.Что бы "заняли все ядра CPU, а там пусть планировщик ОС разбирается кого куда" необходимо и достаточно наплодить кучу потоков.
Так есть же какая-то новая хрень на питоне для сборки. Не помню названия - мне недавно только показывали. Она то-ли проекты генерит, то-ли над симейком рулит... забыл уже.
Не meson случаем?
≥ использование языка Rust вместо Java и существенное увеличение эффективности и производительности сборочного процесса (во внутренних тестах в той же инфраструктуре Buck2 выполняет сборочные задания быстрее Buck в два раза).
Всего лишь в два?
Хвалят его, хвалят.. а в итоге....
Зато безопастно
Протекающий, ненадёжный не верефицируемый ржавый это безопасно?Посмотри на SPARK как пример безопасного языка.
Раст — небезопасный язык. Все это знают уже давно.
Но это тайна !!!
Не рассказывай никому !
Зачем оно нужно, если придумали xtask, идеи которого можно использовать в любом языке
https://github.com/matklad/cargo-xtask
> В сборочном окружении применяется концепция "гермитичности" - собираемый код отрезан от внешнего мира, в процессе сборки извне ничего не загружается, а повторные выполнения работ на разных системах приводят к одному и тому же результатуЭтим стоит похвастатся.
Как человек добавивший воспроизводимость зборок в Gentoo утверждаю, что воспроизводимость в практичном применении снижает безопасность. Речь о рандомизации многих структур во время сборки для безопасности.
В принципе, одно другому не мешает. Вряд ли у вас там рандомизация основана на естественном источнике энтропии, скорее всего, какой-нибудь PRNG. А значит, воспроизводимости можно добиться, используя тот же seed.
Аноним взял и отменил всю прикладную криптографию современности. Сам, видимо, имеет доступ (и не делится) к неограниченному квантовому источнику случайности.
>имеет доступКурейт продает ведь :)
> В принципе, одно другому не мешает.Еще раз, воспроизводимость сборок снижает безопасность сборки так как требует отключения рандомизации во время сборки.
Но воспроизводимость, для сборочных систем нужна, как опция, для все той же безопасности.
> Вряд ли у вас там рандомизация основана на естественном источнике энтропии, скорее всего, какой-нибудь PRNG. А значит, воспроизводимости можно добиться, используя тот же seed.
В большинстве случаев можно прямо сам рандом указать. И разные системы собирать с одним и темже указаным рандомом.
Но в некоторых случаях разрабы не предусмотрено разработчиками подстановка рандома. Сборка таких пакетов не воспроизводима без патчей исходников.
/dev/*random в привельных дистрах невопроизводим.
> /dev/*random в привельных дистрах невопроизводим.Учись, джун!
rm -f /dev/*random
echo '1234567890abcdef' > /dev/urandom
ln /dev/urandom /dev/randomглавное - так после себя и оставить.
>практичном применении снижает безопасность.Эта ваша рандомизация - обскюрити!
Осталось ещё только понять, кто из людей, проживающих за пределами Сан-Диего, пользуется пейсбуком в 2023 году.
дружище, не хотел бы тебя огорчать, но число мест где не забанен фейсбук существенно шире твоего Сан-Диего.А что там на болотах - в общем-то уже всем давно все равно.
Там скоро вообще очереди к перфораторам будут... хотя не, не будут, перфоратор поди гдрский был, не мог Союз сам сложную механику выпускать.
в последнее время Facebook какой-то щедрый
это называется утилизация отходов.Мы еще от прошлой их щедрости не отошли, когда они собирались всех удивить своим хрустоаналогом меркуриал, но удивили чем-то что даже не компилируется - и не может в принципе.
Ручная сборка непосредственно на компьютере единственного разработчика - так у них принято.
Ну вот теперь они зарелизили систему сборки и патченный Меркуриал получится собрать.
ну как получится - пришли открытку. А пока предположу что ты не соберешь этой системой сборки даже саму систему сборки.
Досадно, что в двадцать первом веке люди все еще изобретают сборочные системы. Видимо, задача, действительно, неимоверно сложная. Также удивительно, но я все еще с интересом и надеждой читаю подобные сообщения.
задача заставить фуллщмякдевелопера выучить что-то помимо жабоскрипта (или хруста, или на чем единственном-неповторимом он фулдей шмякает) - действительно нерешаемая.а мэйк или тем более основанные на нем системы - это очень много букв а у него спринт не может ждать.
Поэтому рожается очередной урод на том единственном что он собственно умеет.
Досадно будет, когда люди прекратят изобретать велосипеды, потому что к этому можно придти только одним путём: люди разучатся изобретать велосипеды. Такое уже бывало, математика Древнего Египта и Древнего Вавилона существовала в виде россыпи методов, которые старшие поколения вдалбливали в головы младшим. Потребовалось вмешательство древних греков, чтобы начать классифицировать методы оттуда и отсюда, заметить расхождения, и изобрести методы создания методов. Но до этого тысячелетиями развитие мёртво стояло на месте, и сохранение знаний целиком полагалось на передачу этих знаний. Если что-нибудь оказалось бы утерянным, то оно было бы утерянным навсегда, потому что никто не знал как можно знание генерировать.С велосипедом та же история: до тех пор, пока их изобретают, можно быть уверенными что навыки необходимые для изобретения велосипеда ещё не утеряны. Когда их прекратят изобретать, вот тогда уже поздно будет пить Боржоми.
>>Ситуация отсутствия зависимости воспринимается в Buck2 как ошибка.От чего нужно быть зависимым, чтобы на этом собирать?
Ну и зоопарк
Система сборки которая требует наличия rust чтобы самой собратся - не нужна.
Даже CMake сливает Meson потому что у CMake зависимостей больше и среди них Meson.Что до типа быстроты - фигня.
99,9% времени сборочная система ждёт когда компиляторы отработают.
Считать граф сборки в огромной монорепе, сравнивать два графа в разных ветках и принимать решения, что за чем собирать, нет ли циклов, какие ресурсы задействовать и что брать из кэша - вполне себе нагрузочка. Это занимает время.
Проблема в вашей монорепе. Странная, дурацкая идея.
Gradle умеет это из коробки и можно писать билдскрипты на котлине и груви со всеми плюшками от использования IDE, зачем было городить новый скриптовый язык не понятно.
Очередная либа со своим очередным dsl с плохой поддержкой IDE.
Rust только недавно стали хорошо поддерживать, вот его бы и использовали, ну или использовали gradle. Так может он ещё лучше бы стал, чем сейчас.
Например часть его кода переписали бы на Rust, если уж им так этого хотелось.
ide не нужна
Отказались от собора в пользу базара? Получайте вавилонскую башню!
Так это и есть апофеоз собора, собор городит чудище на питоне, жс и расте, получая очередного сизифа, а базар просто использует мейк.
Компилируемый язык в два раза быстрее интепретируемого. Вот это новость.
Можно было тогда компилятор гнумейка запилить и AOT в Guile и дело с концом.
Гениальное решение:* требует 20GB диска для сборки - пробовал на железке собрать с 2Гб ну там все перегрелось и отключилось - непригодно;
* требует ночного диалекта "nightly-2023-01-24" и в случае обновления версий зависимостей сборка выдает несовместимость (если забросят сейчас, то проекту кранты)
* язык выдуман из пальца и не совместим ни с CMake ни с meson (очередная трата корпоративного время других компаний)В целом польза в инвестиции в инструменты разработки конечно полезное дело, но полученный результат пока напоминает какое-то развлечение.
Теперь про пример "Hello, world!" берем создаем файл BUCK кажется этого достаточно в аналогичном meson, но оказалось нужен ".buckconfig", а потом еще оказалось нужно описать в "toolchains" используемые инструменты и это не конец...При отсутствии этих файлов операция сборки кстати проходит успешно (BUILD SUCCESS), но не создает никаких результатов работы, но не очень понятно как это интегрировать с CI/CD системы.
Почитай про базел и старларк, в каких компаниях они используются, и сразу раздуплишь, из какого пальца они сосут
То, что выпилили Java конечно плюс. Но Bazel, в отличие от Buck, уже набрал кое-какую популярность и интеграцию в официальные репозитории популярных библиотек. Так что без совместимости с ним не нужно.
От плюсов стоит отказаться хотя бы ради того, чтобы не тащить зоопарк билд-систем. Специальные cкриптовые языки придумывают, которые нужны исключительно чтобы программу собрать! Наверно еще чуть-чуть и начнут в эти языки завозить статическую типизацию, сделают их компилируемыми и создадут еще один скриптовой язык для их сборки.
> От плюсов стоит отказаться хотя бы ради того, чтобы не тащить зоопарк билд-системОт жизни на земле стоит отказаться, так как существует много видов животных и растений.
> Специальные cкриптовые языки придумывают, которые нужны исключительно чтобы программу собрать
Верно. Это называется DSL. Ничего страшного в этом нет. Полным полно различных DSL.
Даже сев за руль и получив в свое распоряжение две пидали ты считай получил некоторый
DSL. Под конкретную задачу выдают инструменты.> Наверно еще чуть-чуть и начнут в эти языки завозить статическую типизацию,
> сделают их компилируемыми и создадут еще один скриптовой язык для их сборки.В целом всем на$рать на то как они там внутри организуют свою "кухню" вопрос сейчас
в том на сколько это быстро, удобно и практично.Что касется Buck2 это откровенная трата времени, возможно какой-то момент и удобен,
но дойти до него не получается, практический нужен еще один специаист (DevOps) для
разарботки этого самого Buck2 скриптинга и конфигов для него. Разработчикам проще
использовать по аналогии сейчас Meson или CMake.
Какая-то смесь несвязанных фактов и фантазий.