[О блоге] [наверх] [пред] [2021-01-09 23:38:09+03:00] [970f40ef3b48a98101af2db0ef7836fe83f3d4be]
Темы: [redo]

goredo 0.10.0 tarball

https://lists.cypherpunks.ru/pipermail/goredo-devel/2021-January/000000.html
Один человек изъявил желание опакетить goredo для Arch Linux. А я знаю
насколько неудобно собирать Go программы без наличия всех зависимостей
рядом. Поэтому goredo теперь стал иметь и Info/Texinfo документацию и
сайт, с моим "фирменным" стилем и tarball со всеми зависимостями. Плюс
рассылку сделал для него.

А вообще сегодня обнаружил что goredo не очень корректно высчитывал
зависимости для default.do целей который находятся не рядом и выполняют
цели в поддиректориях. И ни один из apenwarr/redo и redo.sh-tests тестов
не покрыл этот use-case. Причём всё в целом работало... просто постоянно
пересобирало что не требуется.

    [оставить комментарий]
    комментарий 0:
    From: Oskar Sharipov
    Date: 2021-01-10 02:01:32Z
    
    О, вижу на http://www.goredo.cypherpunks.ru/Install.html#Install, что
    архивы сжимаются с помощью Zstandard. Сначала хотел спросить, почему про
    него вы ничего в блоге не писали, а потом решил полистать коммиты...
    Оказалось, писали не мало, я почему-то всё пропустил.
    
    Вот для остальных читателей, если кому интересно:
    
        Быстрое сжатие: ac4f39d3d92ce51278c5baf50b560608ddb6163f
    
        Нужен ли в долгом сжатии: 738fc2e95a295879f990c1a307c792d8e91b9018
    
        NNCP использует zstd: 952451ff289323ded1f32806d494dde17b6db4f1
    
    Еще в 63d24800bdf210844289b627cf87e90da83b6e5d про OpenZFS 2.0, где
    Zstandard наконец релизнули (сколько за этим следил!). Но тут я, пока
    шифрование для FreeBSD-версии не добавят, переходить не хочу. Лучше, как
    минимум, FreeBSD 13, где он по-умолчанию будет, подожду.
    
    Очень рад, что goredo улучшается! С момента, как впервые собрал,
    пользуюсь и радуюсь. Но я до сих пор не могу сказать, радуюсь ли я
    именно идее redo или этой реализации, потому что мне так и не
    понадобилось пробовать другие. Но всё равно еще раз спасибо!
    
    --
    Oskar Sharipov
    gpg fingerprint: BAC3 F049 748A D098 A144  BA89 0DC4 EA75 714C 75B5
    
    комментарий 1:
    From: Sergey Matveev
    Date: 2021-01-10 11:01:46Z
    
    *** Oskar Sharipov [2021-01-10 04:44]:
    >Оказалось, писали не мало, я почему-то всё пропустил.
    
    Писал, писал. И заменил у себя им полностью все xz/gzip вещи. Использую
    либо просто zstd вызов, как штука отлично сжимающая (лучше gzip) и
    которая упирается почти всегда только в жёсткие диски, либо "zstdmt
    --ultra -22" как замена "xz -9". Последнее хоть вроде бы работает и
    медленнее чем xz, совсем чуть-чуть хуже сжимает (иногда всего лишь доли
    процента разницы), но скорость декомпрессии решает! Я прежде даже и не
    предполагал что декомпрессия всяких tarball-ов упиралась в CPU/RAM и что
    она может быть на глаз чуть ли не моментальной.
    
    >Еще в 63d24800bdf210844289b627cf87e90da83b6e5d про OpenZFS 2.0, где
    >Zstandard наконец релизнули (сколько за этим следил!). Но тут я, пока
    >шифрование для FreeBSD-версии не добавят, переходить не хочу. Лучше, как
    >минимум, FreeBSD 13, где он по-умолчанию будет, подожду.
    
    Я тоже жду 13 или ещё более позднего релиза чтобы всё там сразу было и
    хоть сколько-то но проверено временем (ведь OpenZFS же будет
    использоваться). zstd в ZFS интересно проверить -- ибо не уверен что там
    не упрусь в процессор.
    
    Ну а шифрование лично меня не сильно там волнует. С самого начала опыта
    с ZFS использую GELI. Что не так удобно конечно, но и не сильно где-то
    доставляет проблем. Backup-ы всё равно делаю zfs send/recv обёрнутыми в
    zstd и gpg шифрование. Ну и чисто с криптографической точки зрения в ZFS
    шифровании более утекают метаданные о том что происходит на дисках...
    хотя даже меня бы это не сильно в домашних условиях беспокоило.
    
    >Очень рад, что goredo улучшается! С момента, как впервые собрал,
    >пользуюсь и радуюсь. Но я до сих пор не могу сказать, радуюсь ли я
    >именно идее redo или этой реализации, потому что мне так и не
    >понадобилось пробовать другие. Но всё равно еще раз спасибо!
    
    Вам спасибо за отзыв! Когда я написал goredo, то временами запускал
    Python реализацию на всякий случай чтобы убедиться что всё работает
    одинаково и поведение корректно. А когда перенёс ещё и тесты в goredo,
    то другие реализации были удалены полностью.
    
    Радуетесь вы 100% именно идее redo. Ибо, грубо говоря, даже визуально
    разницы между apenwarr/redo и goredo не будет видно. Только скорость
    работы между ними разнится (Python vs Go всё же, да и вроде
    apenwarr/redo не умеет unlimited jobs). Ну и разнится в местах связанных
    с redo-stamp (который в goredo является пустышкой), но я уверен что
    меньшинство проектов используют redo-always/redo-stamp.