Опубликован первый выпуск проекта elfshaker, развивающего систему управления версий для двоичных файлов, оптимизированную для отслеживания изменений в исполняемых файлах в формате ELF. Система хранит бинарные патчи между файлами, позволяет извлекать нужную версию по ключу, что значительно ускоряет выполнение операции "git bisect" и сильно сокращает размер используемого дискового пространства. Код проекта распространяется под лицензией Apache-2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56234
Отличный проект, жаль только написан на расте. Ждем аналога на православном C/C++.
заминусовали, наверное, обладатели терабайт оперативки, которые могут себе позволить запускать исполинские бинарники раста
Даже не пытайся, рациональные аргументы растоманам не интересны. Это же сектанты.
А минусовали-то как раз "жаль" без аргументов, аргументы после появились.
Рациональный аргумент: Исполинские бинарники
Рациональный аргумент: Терабайт оперативкиГосподи иисусе, когда же ты спустишься с небес и высушишь всех анонимов опеннета.
> Рациональный аргумент: Исполинские бинарникиНе угадал. От 2МБ до и от 110КБ после стрипа. И это с учётом ВСЕГО растаманского рантайма, прилинкованного к бинарю. Гоповские бинари у меня тоже были от 2.2МБ(1.1 после стрипа). Статический С-бинарь - около полутора.
> Рациональный аргумент: Терабайт оперативкиГде-то столько же, сколько и для соответствующей сишной проги. Если у тебя занимает терабайт ОЗУ, то лечи руки и голову, проблема где-то там.
> Господи иисусе, когда же ты спустишься с небес и высушишь всех анонимов опеннета.
Религиозный рационализм?
Ну я не буду создавать коней в ваккуме и возьму пример из практики что сейчас у меня на машине с +/- похожим функционалом (не одинаковый).
Rust'овский ripgrep (других нормальных программ на расте не существует) и обычный grep. Разница в 26 раз (совсем не 2МБ vs 1,5МБ).
$ stat -c "%s %n" /usr/bin/rg
5234448 /usr/bin/rg
$ stat -c "%s %n" /bin/grep
199136 /bin/grepЗависимости тоже не в пользу раста в 1.37 раза
$ ldd /usr/bin/rg | awk '{print $3}' | xargs readlink -f | xargs stat -c "%s %n" | awk '{ SUM += $1 } END {print SUM}'
3679600
$ ldd /bin/grep | awk '{print $3}' | xargs readlink -f | xargs stat -c "%s %n" | awk '{ SUM += $1 } END {print SUM}'
2670272
$ ldd /usr/bin/rg | awk '{print $3}' | xargs readlink -f | xargs stat -c "%s %n"
18816 /lib/x86_64-linux-gnu/libdl-2.31.so
157224 /lib/x86_64-linux-gnu/libpthread-2.31.so
104984 /lib/x86_64-linux-gnu/libgcc_s.so.1
2029224 /lib/x86_64-linux-gnu/libc-2.31.so
1369352 /lib/x86_64-linux-gnu/libm-2.31.so
$ ldd /bin/grep | awk '{print $3}' | xargs readlink -f | xargs stat -c "%s %n"
465008 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
18816 /lib/x86_64-linux-gnu/libdl-2.31.so
2029224 /lib/x86_64-linux-gnu/libc-2.31.so
157224 /lib/x86_64-linux-gnu/libpthread-2.31.soВыбор за вами, но на мой взгляд, учитывая увеличение бинарей в 26 раз, что раст медленнее, хуже читается, несвободный, целиком зависит от rust foundation (фактически прикрытие для микрософт, гугл, амазон, фейсбук), и ооочень спорный касательно безопаснсти, rust нужно всеми силами избегать, а его адептов закидывать гнилыми помидорами.
Не совсем корректно сравнивать ripgrep с grep, ripgrep нужно сравнивать с the silver searcher (ag) и подобными
Он как минимум намного быстрее и фичастее:https://blog.burntsushi.net/ripgrep/
https://beyondgrep.com/feature-comparison/
Дальше видимо должно идти выбор более подходящего греп клона, уравнение опций, параметров компилятора, версий либ, кейсов для тестирования, патчей для схожести алгоритмов и прочие действия которые для меня сделают сравнение ещё менее практичным.
Т.е сравнивать поисковые программы по их размеру на диске - практично?
Иногда — да. Я переписал dirname потому что мне не нравилось то, как она сделана (и описана в POSIX) в libgen.h, придав ей вид realpath. Заодно решил собрать в бинарь, повторяющий функционал POSIX и так же жрущий кучу аргументов подряд, как GNU версия. В итоге мой бинарь весит 16 кб просто с флагами -Ofast, а GNU версия аж 40 кб, и по скорости получилось одинаково.
А, и вся функция dirname из зависимостей имеет только memcpy, ни одной другой функции не использовал.
А по стабильности и безопасности как получилось у Неуловимого Джо? Сколько времени занимает сопровождение форка? (Намек, что подходит для индивида, не обязательно подходит для сообщества.)
Нет, не практично, но не я затеял эту сравнение. Это лишь лишний раз подчеркивает что к одному, далеко не главному, аргументу анонима касательно небольшого веса программ на расте следует относится с долей сомнения.
> Нет, не практично, но не я затеял эту сравнение. Это лишь лишний
> раз подчеркивает что к одному, далеко не главному, аргументу анонима касательно
> небольшого веса программ на расте следует относится с долей сомнения.Ну допустим возьмём чот более сравнимое, есть язык шаблонизации - jsonnet
Под него есть 4 известных реализации (Рассматриваю статически слинкованные x86_64 бинари):
C++ (10.7мб после распаковки): https://github.com/google/jsonnet/releases/tag/v0.17.0
Scala (8.8мб, но тут ещё нужно jvm считать): https://github.com/databricks/sjsonnet/releases/tag/0.4.1
Go (4.6мб после распаковки): https://github.com/google/go-jsonnet/releases/tag/v0.17.0
Rust (1.7мб): https://github.com/CertainLach/jrsonnet/releases/tag/v0.5.0-...Как же так получилось что Rust самый компактный?
Могу сказать только что это хороший пример.
for the record, 12:% uname -op ; ldd `which grep` | awk '{print $3}' | xargs readlink -f | xargs stat -f "%z %N"
FreeBSD amd64
1897288 /lib/libc.so.7и всё.
Да, параметр формата stat отличается.
for the record
тогда уж актуальный гнутый греп:
/usr/local/bin/grep -V
grep (GNU grep) 3.6uname -op ; ldd /usr/local/bin/grep | awk '{print $3}' | xargs readlink -f | xargs stat -f "%z %N"
FreeBSD amd64
59832 /usr/local/lib/libintl.so.8.2.0
653480 /usr/local/lib/libpcre.so.1.2.13
1880856 /lib/libc.so.7
126464 /lib/libthr.so.3uname -op ; ldd /usr/local/bin/grep | awk '{print $3}' | xargs readlink -f | xargs stat -f "%z %N"|awk '{ SUM += $1 } END {print SUM}'
FreeBSD amd64
2720632uname -op ; ldd /usr/local/bin/rg | awk '{print $3}' | xargs readlink -f | xargs stat -f "%z %N"|awk '{ SUM += $1 } END {print SUM}'
FreeBSD amd64
2838152
Оргументы про 2мб вообще непонятны, более гигабайта непонятнозачемстолько исходников которые делают неизвестное. Я понимаю что дело в вере, но несектантов напрягает.
Вот нафига мне скрипта, которую надо компилить на суперкомпе с тоннами памяти ? На выбор куча намного легковеснее и приятнее на синтаксис альтернатив.
Насильное заражение старых проектов "этим" сильно портит имидж которого и так нет. Напрочь отбитые фанатики и отсутствие документации (тот сайт не работающий без жабаскрипта - не документация).
Генерация нового синтаксиса идет в минус любому езыку, посчитай сколько минусов набрал хруст.
> Религиозный рационализм?w> Почему именно наша компания ?
i> Было написано про адекватное руководство.w> Ну ладно, что не так в этом куске кода ?
i> Он написан на rust.w> Когда вы сможете выйти на работу ?
i> Когда уволите того кто написал эту гадость.w> Пойдем, покажу твой кабинет.
Я тут как бы стебусь с дурачковатых расто-хейтеров, которые "исполинский бинарник" считают рациональным аргументом...Что ж, дурачки есть как среди расто-хейтеров, так и расто-филов
https://ru.wikipedia.org/wiki/Гипербола_(риторика)
Если вы гиперболизируете, то не претендуйте на рациональность.
"риторика" -- читай "демагогия".
"Ordu" - читай "durO"
Не, он их всех размножаемым хлебом ещё накормит.
Кормит непереставая. "Размножаемый хлеб" наших дней - это свободное копирование - то, с чем борются копирасты.
Этот проект в сущности тонкая обертка над стандартными C библиотеками. Не очень понятно, зачем тут вообще понадобился раст.$ ldd /bin/elfshaker
linux-vdso.so.1 (0x00007ffe18ea6000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f94a466f000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f94a464e000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f94a450a000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f94a4503000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f94a4337000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f94a4946000)
> Этот проект в сущности тонкая обертка над стандартными C библиотеками.Все гораздо хуже:
ldd /usr/bin/perl
linux_vdso.so.1 => (0x00007ffffffff000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000000801800000)
libm.so.6 => /lib64/libm.so.6 (0x0000000801c00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000000802000000)
libc.so.6 => /lib64/libc.so.6 (0x0000000802400000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000000802800000)
/lib64/ld-linux-x86-64.so.2 (0x0000000001021000)
libfreebl3.so => /lib64/libfreebl3.so (0x0000000802c00000)
Однозначно - заговор неосиляторов Великого Си!
> Не очень понятно, зачем тут вообще понадобился раст.
> $ ldd /bin/elfshaker
> linux-vdso.so.1 (0x00007ffe18ea6000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f94a466f000)
> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f94a464e000)
> libm.so.6 => /usr/lib/libm.so.6 (0x00007f94a450a000)
> libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f94a4503000)
> libc.so.6 => /usr/lib/libc.so.6 (0x00007f94a4337000)
> /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f94a4946000)Действительно, зачем использовать системное API и библиотеки, когда можно притащить кучу своих?
Действительно хуже, если язык якобы системного программирования приходится сравнивать со скриптовым языком для обработки текстов.
>> Этот проект в сущности тонкая обертка над стандартными C библиотеками.
>> в качестве "подтверждения" приводятся якобы зависимости, при этом скромно игнорируется вариант с полностью стат. сборкой
> Действительно хуже, если язык якобы системного программирования приходится сравнивать со скриптовым языком для обработки текстов.Хуже очередного опеннетного Ыксперта, переобувающегося в прыжке? Вряд ли.
Действительно, судя по ldd любой сишной программы, язык якобы системного программирования С ничем не отличается от скриптового языка обработки текстов Perl.
Хехе, вот возьми и перепиши! А то только на опеньке языком трепать можешь...
Рассматриваю и такой вариант.
Забавно видеть, как растохейтеры в комментариях к другим новостям уверяли, что на расте нет ни одного полезного проекта, а значит раст плохой и не нужен. Здесь же пишут, что проект хороший, но плохо, что на расте. Circular reasoning, не иначе.
Да по большому счету всем же наверняка пофигу что за ЯП - вызывает раздражение только мания все переписать также как есть, но только на другом ЯП...
И ладно бы переписывали прототип на что-то по серьезнее, а то с одного нормального на другой нормальный...
> вызывает раздражение только мания все переписать также как естьЭто уже сто лет с нами - BSDшники (особенно OpenBSD) очень любят все переписывать, попутно урезая функциональность (якобы "ради безопасности", по факту "лень пилить, мне еще 100500 проектов переписать надо").
Они не лезут в чужие проекты с предложениями переписать все на другоя языке. Берут и сами делают то что им нужно.
И чем это делает их лучше?
Как минимум тем что не лезут ко всем со своим навязыванием. Не лезут с рекламой что они лутше всего и всех и хосподь жги.
> Не лезут с рекламой что они лутше всего и всех и хосподь жги.Наверное, вы живёте в альтернативной вселенной, где нет Тео де Раадта и Ко, задолбавших всех своим самопиаром "у вас проги дырявые, а у нас БЕЗОПАСНОСТЬ!".
Всем.
Или всё-таки ничем?
>> вызывает раздражение только мания все переписать также как есть
> Это уже сто лет с нами - BSDшники (особенно OpenBSD) очень любят все переписыватьУгу-угу, переписали исконно-перепончатое sudo в doas и до кучи весь корутильс ...
> попутно урезая функциональность (якобы "ради безопасности", по факту
> "лень пилить, мне еще 100500 проектов переписать надо").И то ли дело "приближение прогресса и светлого будущего" а ля
HAL => DeviceKit => disks => udisks => udisks2 => storaged => udisks2,
doass
> doassВаганович, ты?
> исконно-перепончатое sudoты уверен? загугли, что ли, неуч, кто начинал его писать...
>> исконно-перепончатое sudo
> ты уверен? загугли, что ли, неуч, кто начинал его писать...Загугли "сарказм" и "читать предложения целиком", уч ты очередной анонимный.
Или ты опустил "и до кучи весь корутильс ..." потому что считаешь, что утилиты там - "изобрели" пингвинята-гнутики?
А потом пришёл Тео и изобрёл их сам, лично. Раньше гнутиков, конечно. Но уже потом.
> А потом пришёл Тео и изобрёл их сам, лично. Раньше гнутиков, конечно.
> Но уже потом.Казалось бы, причем тут Тео?
https://github.com/dank101/4.2BSD/blob/master/bin/dd.c
> static char *sccsid = "@(#)dd.c 4.3 (Berkeley) 4/29/83";
> Забавно видеть, как растохейтеры в комментариях к другим новостям уверяли, что на расте нет ни одного полезного проекта, а значит раст плохой и не нужен.Ну, почти все полезные проекты на сях ведут свою историю из дремучих годов.
В последние лет 10 _новых_ полезных проектов на сях действительно мало.
Полезность раста хорошо демонстрируется тем фактом, что в качестве примера для сжатия бинарника выбран gcc.
Точнее clang, суть не меняет.
А ещё точнее — LLVM. Действительно, причём тут rust?
>LLVM is written in C++Не пугай так больше, а то решил было что его уже переписали на расте.
>LLVM is written in C++
> на растеSort of.
> Точнее clang, суть не меняет.Не меняет, но уровень очередного "эксперта" тем не менее - палит.
И не говори, сам в ужасе от своей безграмотности.
> Полезность раста хорошо демонстрируется тем фактом, что в качестве примера для сжатия бинарника выбран gcc.Сам что-то придумал, сам что-то оспорил, сам гордо надул щечки - настоящий опеннетный Анти-Расто-Воен!
Пока ты вымучивал свой пафосный комментарий, выше пояснили, что Раст написан на C++. Nuf said.
> Пока ты вымучивал свой пафосный комментарий, выше пояснили, что Раст написан на C++. Nuf said.
> Раст написан на C++.Действительно, nuff said.
Разве Rust можно собрать чисто из исходников без С++ зависимостей?
Растаманам сначала нужно самим переписать свой язык на Rust, прежде чем требовать этого от других.
> Разве Rust можно собрать чисто из исходников без С++ зависимостей?Можно, разрешаю!
https://github.com/rust-lang/rust
> Rust 97.9% Python 0.4% JavaScript 0.3%--
> Растаманам сначала нужно самим переписать свой язык на Rust, прежде чем требовать этого от других."Сам что-то придумал, сам что-то оспорил, сам гордо надул щечки - настоящий опеннетный Анти-Расто-Воен!" (c)
Про внешние зависимости ты конечно же забыл. llvm на расте уже переписал, Анти-Анти-Расто-Воен, или ты силен только в навыке спамить проекты issues "Rewrite in Rust"?
> Про внешние зависимости ты конечно же забыл. llvm на расте уже переписал,Эксперды опеннета в своей естесвенной среде обитания ...
https://rustc-dev-guide.rust-lang.org/backend/codegen.html
> rustc uses LLVM for code generation; there is also support for Cranelifthttps://github.com/bjorn3/rustc_codegen_cranelift
> features = ["std", "read_core", "write", "coff", "elf", "macho", "pe"]
> Rust 95.8% Shell 4.2%
> или ты силен только в навыке спамить проекты issues "Rewrite in Rust"?И опять
"Сам что-то придумал, сам что-то оспорил, сам гордо надул щечки - настоящий опеннетный Анти-Расто-Воен!" (c)
Впрочем, ничего иного от местных "Экспердов" и не ожидалось.
Мда, точно сам что-то придумал, сам что-то оспорил, сам гордо надул щечки - настоящий опеннетный Расто-Воен!
Видел ранее в трендах гитхаба, но не придал этому проекту значения, думал очередная мало кому нужная поделка на расте, но оказывается полезная тулза. Добавил в закладки.🤥
пиши мемуары, с удовольствием прочитаем
держи в курсе
Шокер для эльфов?
Шейкер. Чтобы лучше засыпали.
Шейкером эльфа не пронять. Только хороший разряд!
Эльфотряс
Вот же будет весело и не скучно однажды поддерживать rust-legacy код.
Znext поколение будет переписывать его на том новом, модном для них, ЯП.
> Вот же будет весело и не скучно однажды поддерживать rust-legacy код.Вряд ли это будет чем-то хуже, чем legacy c++.
Синтаксис у них одинаково марсианский.
> В частности, результаты двух тысяч пересборок компилятора Clang (каждая пересборка отражает изменение после каждого коммита) могут быть сохранены в одном pack-файле, размером 100 МБ, что в 4000 раз меньше, чем потребовалось бы при раздельном хранении.Для Gentoo будет круто
Интересно, зачем тебе доступ к пре-предыдущим emerge'ам? Ну к предыдущему ещё можно понять, чтоб откатить систему, если обновление сломало.
Это больше для разработки полезно. Тебе баг-репорт влетает, ты пишешь тест на баг, и тебе надо найти коммит, который этот баг привнёс, и тут ты запускаешь git bisect, и оставляешь его работать на часы или даже сутки. Но, внезапно у тебя появляется сия тулза, и bisect выполняется на порядки быстрее.В дженте не очень понятно как это использовать. Ядро не умеет запускать из такого формата, ему подавай именно elf. Значит, чтобы запустить нужную версию компилятора, её надо будет извлечь сначала и распаковать в реальный файл. И всё это ради пары-тройки версий бинаря? Причём существенно отличающихся версий, потому что они отличаются второй, а может даже и первой цифрой версии, а значит и не сильно упаковывающихся. Проще чутка пожертвовать жёстким диском, и хранить в распакованном виде, дополнительные сложности просто не стоят того.
были б в ELF-файлах хотя бы подобные MZ-записям...
"This program cannot be run in DOS mode"?
зачёт )
Но я больше про версии, ресурсы, подписи, манифесты.
В общем, всё, что пришлось запихивать в бинарники из-за отсутствия в винде FHS и пакетных менеджеров.
Зачем миру open source контроль версий бинарников? Исходники рулят.
А, ну да, растаманы сами себе в помощь делают. А то же Rust нцать часов собирается.
> Зачем миру open source контроль версий бинарников? Исходники рулят.Местным теоретикам-WSL-щикам и домохозякам с бубунтой - наверное действительно незачем.
Я не WеSеLщик, я практически собираю из исходников.
WeSelьчак-У :)
Основная идея вполне внятно описана в новости. Чтобы быстро через bisect найти версию софта, в которой появился баг. В приличной разработке, где каждый коммит идёт через CI и, собственно, единственная проблема - хранение промежуточных бинарей, это будет адски полезной и почти ничего не стоящей фиче.Второе - это собственно прои разработке скачки между версиями без необходимости всё пересобирать.
Но, конечно, язык разработки и лицензия не радуют совершенно
Оно только для хранения пригодно? А в рантайме нельзя использовать? Ну типа для мультиплатформенных или мультиверсионных бинарей? Например x86 и x64 варианты в один файл упихать.
https://www.opennet.me/opennews/art.shtml?num=23948
упаковать, навреное, получится, но смысла нет - сжатия, считай, не будет, так как код совершенно разный
Для других бинарных форматов и вообще генерик бинарников (через xdelta там) было бы неплохо что-то подобное
что только не придумают, чтобы svn не использовать
А кстати анонче прав. Эта гадость переваривала любые помойки.
Расходимся посоны. Растаманы нас жестоко на#бали, впрочем как обычно. Эта хрень заточена под один узкоспециальный кейс, представленный их единственным примером применения manyclangs.Бинарный патчи? Ха! Якобы бинарник clang хранится в pack-файле в виде множества .o-файлов и дедупликация происходит на уровне отдельных .o-файлов путем сортировки по размеру файла! После извлечения из архива множества объектных файлов бинарник еще нужно слинковать. И за 2-4 секунды этого не сделаешь, речь идет только об извлечении файлов из архива, и то на хорошем железе.
Компилировать проект в объектники для этой утилиты нужно со специальным, не меняющимся набором флагов, чтобы было как можно меньше меняющихся между сборками файлов. Без этого весь этот рекорд сжатия идет прахом. Кстати, pack-файл за последний месяц имеет размер не 100 Мб, а 205 Мб.
Для произвольно взятого множеста бинарных релизов эта хреновина практически бесполезна. Вместо нее можно взять обычный архиватор с хорошим сжатием.
Аналог данного проект можно написать на баше. Для измененных файлов использовать xdelta, а остальное сжать обычным zstd, который она к слову и использует. Или поискать готовую утилиту дедупликации мелких файлов. Или вообще использовать обычную VCS с поддержкой сжатия бинарников, с несравнимо большими возможностями!
Вердикт: не нужно. Только если вы тестер clang или нужно версионировать папку с множеством редко меняющихся файлов, да и то можно сделать это другими, более привычными способами.