forum.opennet.ru - "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" (51)

"Выпуск утилиты для синхронизации файлов Rsync 3.3.0"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
Сообщение от opennews (??), 06-Апр-24, 23:10
После полутора лет разработки опубликован релиз Rsync 3.3.0, утилиты для синхронизации файлов и резервного копирования, позволяющей минимизировать трафик за счёт инкрементального копирования изменений. В качестве транспорта могут быть использованы ssh, rsh или собственный протокол rsync. Поддерживается организация работы анонимных rsync-серверов, оптимально подходящих для обеспечения синхронизации зеркал... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60941
Ответить \| Правка \| Cообщить модератору

Оглавление

20 лет feature request у, а воз и ныне там https bugzilla samba org show_bug c, Аноним (2), 23:56 , 06-Апр-24, (2) +1

unix вей не позволяет реализовать такие вещи эффективно, ls (??), 00:05 , 07-Апр-24, (3)

не звезди, при переименовании inode не меняется , Аноним (5), 00:13 , 07-Апр-24, (5)

Использовать inode 8212 не unix way , Аноним (8), 00:37 , 07-Апр-24, (8) +2
и как rsync должен знать про inode , Аноним (13), 06:52 , 07-Апр-24, (13) +2

Тут есть что-то про detect-renamed https github com RsyncProject rsync-patche, LeNiN (ok), 00:10 , 07-Апр-24, (4)
Если не использовать btrfs zfs у которых есть свои средства для снимков и синхр, n80 (?), 00:17 , 07-Апр-24, (7)

Синхронизируется каталог с кучей файлов В какой-то момент каталог переименовыва, Аноним (9), 01:12 , 07-Апр-24, (9) +3

Напомни почему ты за 20 лет не сделал форк с данным патчем хотябы для себя Може, Аноним (14), 09:03 , 07-Апр-24, (14) +4
Полагаю, что для выпускника западного универа это не та семантическая разница, к, Ю.Т. (?), 09:14 , 07-Апр-24, (17) +1

Unison вроде умеет такое обрабатывать , Аноним (20), 09:55 , 07-Апр-24, (20)

Я говорю о том, что даже если мы на 101 имеем идентичные файлы, то для западно, Ю.Т. (?), 10:30 , 07-Апр-24, (23)

Для любого, западного или восточного, реального практика в смысле не теоретика, Аноним (9), 20:16 , 07-Апр-24, (50)

Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а, Ю.Т. (?), 22:58 , 07-Апр-24, (52) +1

Сомнительная идея и антифича Для типичных применений сабжа, это могут быть разн, Аноним (25), 10:47 , 07-Апр-24, (25)
Если тебя это так тревожит, то первое что тебе следует сделать -- связаться с ав, Аноним (-), 13:20 , 07-Апр-24, (40) +1
Так это ни разу не всего-то, считать хеши всех подряд ведь мы не знаем, что и к, n80 (?), 21:17 , 07-Апр-24, (51)

Речь идет совсем не об экономии трафика Время Поясню На небольшом сервачке кажд, Аноним (9), 01:40 , 08-Апр-24, (53)

а если я не переименовывал, а создал новый каталог или два, три и скопировал т, nailts (ok), 16:31 , 18-Апр-24, (58)

Она не решается в хорошем виде в общем случае В CoW видите ли трекинг изменений, Аноним (-), 07:35 , 08-Апр-24, (56)

кстати да, ещё очивидную фичу не выходить с ненулевым error-code когда есть mis, pelmaniac (?), 18:53 , 07-Апр-24, (49)

Зачем , Аноним (10), 01:41 , 07-Апр-24, (10) +1

Чтобы хоть кто-то понимал , а што не так (?), 02:25 , 07-Апр-24, (11) +3
Ну как же, а бизапастность , Аноним (14), 09:04 , 07-Апр-24, (15) –1
Питон это Перл сегодня , Ю.Т. (?), 09:15 , 07-Апр-24, (18)

Гентушники одобряют , Аноним (45), 16:16 , 07-Апр-24, (45)

Ну, вот, есть у тебя, например, мыло, а тебе нужно шило Или, допустим, наоборот, YetAnotherOnanym (ok), 09:46 , 07-Апр-24, (19) +3

Всё правильно понял и описал, только лицо у тебя почему-то недовольное , Аноним (21), 10:24 , 07-Апр-24, (21) +1

Недовольный потому что эти навозные изза сарая хлеб ему отбирают Масло отобрал, Аноним (20), 10:27 , 07-Апр-24, (22) +1

Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе воп, YetAnotherOnanym (ok), 10:50 , 07-Апр-24, (26) +2

Ты с пхп путаешь Потому что с пхп как раз таки и переходят на питон , Аноним (14), 10:54 , 07-Апр-24, (28)

Разве что не осилившие , Tron is Whistling (?), 11:19 , 07-Апр-24, (30)
Ты не в тренде Таки - на игогошку уже давно - которая питона в вебе и загасит , Аноним (34), 12:12 , 07-Апр-24, (34) +1

Ну, если использовать Питон там, где его использовать не желательно, так и будет, Прохожий (??), 11:10 , 07-Апр-24, (29)
Да, только на перловку уже ни один сумасшедший не вернётся Потому что производи, namenotfound (?), 12:16 , 07-Апр-24, (35) –1
Как будто, Перл не интерпретатор и его производительность в разы выше питонячей , Аноним (45), 16:23 , 07-Апр-24, (47)
Если бизнес таки раскрутится на питоне, то дальше может спокойно решать стоит ли, Аноним (20), 16:32 , 07-Апр-24, (48)
Еще раньше они начинают задаваться вопросом почему все разваливается и постоянн, Аноним (-), 05:56 , 08-Апр-24, (55)

не надо - он если и правда умеет, пошлет тебя подальше, со словами - работает во, нах. (?), 13:49 , 07-Апр-24, (42) +1

Если нужно что-то поправить переделать, в питоне это проще и быстрее , beck (??), 11:26 , 07-Апр-24, (31)
Это наверное затем, что бы то, что работало 20 лет и кушать не просило, теперь р, Анониссимус (?), 11:53 , 07-Апр-24, (33) +2

и чтоб никаких рсинков с немодных платформ , нах. (?), 13:50 , 07-Апр-24, (43) +1

На немодных платформах нет Питона Очень сомнительно, чтобы сегодня его не было , Аноним (45), 16:20 , 07-Апр-24, (46) –1

Синхронизация с удалённым сервером, это по сути перезапись старых и удаление нес, Аноним (-), 09:06 , 07-Апр-24, (16)

они просто останутся нетронутыми А рсинк в первую очередь не для синхронизации, , Аноним (32), 11:34 , 07-Апр-24, (32)

Слово sync в названии как-бы говорит о другом , Анониссимус (?), 12:16 , 07-Апр-24, (36) +3

на уровне bittorrent sync 1 3 109 есть чё synthning - бажная шляпа rsync не кро, Петрович 69 (?), 13:06 , 07-Апр-24, (39) –4

А нам кроме экосистемы Линукса ничего не надо , Аноним (-), 16:12 , 07-Апр-24, (44)
Пользовался когда-то сборкой для винды Работало без проблем, но медленно Тепер, Аноним (54), 02:23 , 08-Апр-24, (54)
использую синхфинг уж десяток лет - умвр мож у тебя руки не тем концом не туд, pfg21 (ok), 15:32 , 11-Апр-24, (57)
дык в чем проблема платишь за resilio sync и пользуешь в свое удовольствие b, pfg21 (ok), 09:29 , 17-Май-24, (59)

Сообщения [Сортировка по времени | RSS]

2. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Аноним (2), 06-Апр-24, 23:56

20 лет feature request'у, а воз и ныне там:
https://bugzilla.samba.org/show_bug.cgi?id=2294

Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от ls (??), 07-Апр-24, 00:05

unix вей не позволяет реализовать такие вещи эффективно

Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (5), 07-Апр-24, 00:13

не звезди, при переименовании inode не меняется.

Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +2 +/–

Сообщение от Аноним (8), 07-Апр-24, 00:37

> при переименовании inode не меняется
Использовать inode — не unix way.

Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +2 +/–

Сообщение от Аноним (13), 07-Апр-24, 06:52

и как rsync должен знать про inode?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

4. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от LeNiN (ok), 07-Апр-24, 00:10

Тут есть что-то про detect-renamed: https://github.com/RsyncProject/rsync-patches

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

7. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от n80 (?), 07-Апр-24, 00:17

Если не использовать btrfs/zfs (у которых есть свои средства для снимков и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, в моих случаях. По ссылке она упоминается.
Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт, так что идеального решения в нём не получится вообще, а приемлемые за эти годы и так плюс-минус запилили. Но можно рассказать про свой сценарий использования, конечно, коллективный разум помогает, когда действительно хочется проблему решить.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

9. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +3 +/–

Сообщение от Аноним (9), 07-Апр-24, 01:12

>можно рассказать про свой сценарий использования
Синхронизируется каталог с кучей файлов. В какой-то момент каталог переименовывается без изменения содержимого. Так вот rsync в этом случае на целевой машине создаст новый каталог и будет заново качать все его содержимое. Ни какие --fuzzy и, тем более, btrfs/zfs ситуацию не исправляют.
>надо залезать на уровень кода файловых систем
Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов (на случай если в переименованом каталоге изменились какие-то файлы) и качать только измененные.
20 лет назад описан этот кейс и даже предложен патч detect-renamed. Упрямство не имеет логического объяснения.

Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +4 +/–

Сообщение от Аноним (14), 07-Апр-24, 09:03

Напомни почему ты за 20 лет не сделал форк с данным патчем хотябы для себя? Может потому что даже у тебя данный кейс ниразу не случился за 20 лет?

Ответить | Правка | Наверх | Cообщить модератору

17. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Ю.Т. (?), 07-Апр-24, 09:14

> В какой-то момент каталог переименовывается без изменения содержимого.
> Всего-то надо проверить
Полагаю, что для выпускника западного универа это не та семантическая разница, которую можно оценить как "всего-то". Это вполне может пониматься как новая сущность, которую безопасно (и как бы даже легально) обработать именно как новую. Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

20. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (20), 07-Апр-24, 09:55

Unison вроде умеет такое обрабатывать.

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Ю.Т. (?), 07-Апр-24, 10:30

> Unison вроде умеет такое обрабатывать.
Я говорю о том, что даже если мы на 101% имеем идентичные файлы, то (для западного универсанта) из этого не следует однозначно возможность считать сущность с другим названием тождественной этой.

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (9), 07-Апр-24, 20:16

>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши
Для любого, западного или восточного, реального практика (в смысле "не теоретика") равенство хэшей sha1 означает, что файлы идентичные.
>не та семантическая разница
Сферический конь в вакууме.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

52. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Ю.Т. (?), 07-Апр-24, 22:58

>>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши
> Сферический конь в вакууме.
Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а не отмахиваются.

Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (25), 07-Апр-24, 10:47

Сомнительная идея и антифича. Для типичных применений сабжа, это могут быть разные файлы, принадлежащие разным владельцам, и они будут дописываться в нескольких местах одновременно, т.е. хардлинк тут не канает.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

40. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Аноним (-), 07-Апр-24, 13:20

> Упрямство не имеет логического объяснения.
Если тебя это так тревожит, то первое что тебе следует сделать -- связаться с авторами и узнать их объяснение. У них есть irc-канал или что-то в этом роде? Если есть, то это самое правильное место обсуждать такого рода идеи. Если нет, то значит надо выбрать из активных разработчиков кого-то, и написать ему письмо, с объяснением мотивации, метода решения, ссылкой на патчи, и прямо поставить вопрос: что не так и почему это не принимается в дерево.
Выше описан самый правильный способ искать объяснения, почему патчи не приняты, но можно поспекулировать. Этот метод, во-первых, требует выбора хеш-алгоритма. Это не самый очевидный выбор (коллизии, скорость вычисления хеша...), но при этом важный выбор, который надо делать осознанно, потому что сменить хеш-алгоритм потом может быть затруднительно из-за беквард-совместимости. Во-вторых, этот метод мне лично выглядит недоделанным костылём. Почему сравниваются директории, а не индивидуальные файлы? При чём тут mtime? По-хорошему ведь, напрашивается сравнивать (size, hash) индивидуальных файлов и если они совпадают, то скопировать mtime, права, атрибуты файла и прочее, что копируется, оставив содержимое нетронутым. А если одеть поверх ещё одну "оптимизацию" и сравнивать не только пары (size, hash), но и вектора (size, hash, mtime, user:group, ... всё остальное что заявлено для копирования), и видеть что вектора равны, то пропускать соответствующий файл.
Если уж делать, то как-то так, а не уем об косяк. Потому что если об косяк, то разработчики рискуют потом столкнуться с тем, что предложенный костыль имеет какие-то эдж-кейсы, и ещё хочется функциональность его расширить, но расширить функциональность будет означать сломать обратную совместимость с костыльной реализацией идеи, а значит надо дублировать функциональность некостыльной реализацией.
И поэтому, возвращаясь к началу, тебе надо сначала поговорить с разработчиками и понять, что они думают на этот счёт, в какой форме они готовы принять эту фичу. И когда ты поймёшь, что им надо, вот тогда сесть и написать. План действий ясен? Прекращай скулить, приступай к выполнению.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

51. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от n80 (?), 07-Апр-24, 21:17

> Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов
> (на случай если в переименованном каталоге изменились какие-то файлы) и качать только измененные.
Так это ни разу не всего-то, считать хеши всех подряд (ведь мы не знаем, что и куда было перемещено) файлов и держать даже сами хеши (всех-всех файлов в синхронизируемом каталоге и его подкаталогах) в памяти удовольствие совсем не бесплатное и экономия канала тут может вообще не оправдаться. Если какая-то редко нужная функциональность ухудшит жизнь тем кому она не нужна — нехорошо получится всё же.
Лезть на уровень ФС можно чтобы получить информацию о том что такой-то inode был отлинкован от одного каталога и прилинкован к другому (или что вообще тупо каталог был переименован), при этом данные самого файла не менялись. У rsync между запусками не хранится информация об обрабатывавшихся inode, поэтому ему неоткуда об этом узнать. Патч detect-renamed в каких-то ситуациях проблему решает, но не во всех и в комментарии к патчу прямо есть TODO с планами по доработке. В целом, он здраво выглядит, конечно, так что думаю что доделают то что в TODO (если это будет в приоритете, разработчиков-то мало) и замёржат. Но всегда можно наложить локально, если действительно так надо.
В любом случае, спасибо за информацию и пинок подробнее изучить код патчей из rsync-patches.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

53. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (9), 08-Апр-24, 01:40

>экономия канала тут может вообще не оправдаться
Речь идет совсем не об экономии трафика. Время!
Поясню:
На небольшом сервачке каждую ночь AIDE проверяет неизменность объектов ФС (файлы, линки, директории) одновременно по следующим признакам: permissions, link, user, group, size, mtime, acl, md5
Вот вчерашний лог проверки:
Number of entries:      20891
End timestamp: 2024-04-07 02:12:06 +0300 (run time: 0m 5s)
5 (пять!) секунд на 20 тысяч объектов ФС. Суммарный объем этих файлов - 2,8 Гбайт. Если качать их по 100 Мбит линку, то это займет > 280 сек. Даже на скромной виртуалке считать хэши быстрее полной повторной закачки ~ в 50 раз.

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от nailts (ok), 18-Апр-24, 16:31

а если я не переименовывал, а создал новый каталог (или два, три) и скопировал туда файлы?

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

56. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (-), 08-Апр-24, 07:35

> Если не использовать btrfs/zfs (у которых есть свои средства для снимков
> и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере,
> в моих случаях. По ссылке она упоминается.
> Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем
Она не решается в хорошем виде в общем случае. В CoW видите ли трекинг изменений часть логики работы ФС, оно делается в фоне, всегда.
В случае обычной ФС этого знания просто изначально нет. И вам придется явно угробить ресурсы на его отстраивание и трекинг. Это привносит свой уровень сложности и потребления ресурсов. При том что результат как правило все же хуже чем вон там. Да, дифференциальный btrfs send и точнее, и меньше ресурсов. Что хотите то и делайте с этим фактом. Rsync же скорее для всякой синхры зеркал годится, и даже там грабель - можно огрести от души. Ибо стандартно трекинга отличий нет, полная версия ресурсоемка что капец, а эмпирика - весьма компромиссное решение.
> (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт,
> так что идеального решения в нём не получится вообще, а приемлемые за эти годы
> и так плюс-минус запилили. Но можно рассказать про свой сценарий использования,
> конечно, коллективный разум помогает, когда действительно хочется проблему решить.
Я бы сказал что рсинк vs вон то все же довольно разные. Скажем делать зеркало скажем репов дистро путем "btrfs send" будет все же несколько странной идеей. Хоть так в принципе и можно при сильном желании.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

49. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от pelmaniac (?), 07-Апр-24, 18:53

>20 лет feature request'у, а воз и ныне там:
кстати да, ещё очивидную фичу "не выходить с ненулевым error-code когда есть missing files"  (совершенно нормальная ситуация, когда живую фс копируешь)
тоже максимально упорото отказались в апстрим взять, вынесли, типа колхозь скрипты, вася...

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

10. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Аноним (10), 07-Апр-24, 01:41

>Переписан на языке Python perl-скрипт mnt-excl
Зачем?

Ответить | Правка | Наверх | Cообщить модератору

11. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +3 +/–

Сообщение от а што не так (?), 07-Апр-24, 02:25

Чтобы хоть кто-то понимал.

Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" –1 +/–

Сообщение от Аноним (14), 07-Апр-24, 09:04

Ну как же, а бизапастность?

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

18. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Ю.Т. (?), 07-Апр-24, 09:15

Питон это Перл сегодня.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

45. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (45), 07-Апр-24, 16:16

Гентушники одобряют.

Ответить | Правка | Наверх | Cообщить модератору

19. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +3 +/–

Сообщение от YetAnotherOnanym (ok), 07-Апр-24, 09:46

Ну, вот, есть у тебя, например, мыло, а тебе нужно шило. Или, допустим, наоборот. Вот и меняешь одно на другое.
А если серьёзно, питон - это язык "лёгкий в освоении и удобный в использовании". Кодеров на питоне - как навоза за сараем. Если Служба занятости отправляет безработного филолога или искусствоведа учиться программированию, то в 99% случаев это будут курсы питона. А вот перловщики - это вымирающий вид. Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему переписывание перлового скрипта на питон.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

21. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Аноним (21), 07-Апр-24, 10:24

Всё правильно понял и описал, только лицо у тебя почему-то недовольное.

Ответить | Правка | Наверх | Cообщить модератору

22. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Аноним (20), 07-Апр-24, 10:27

Недовольный потому что эти навозные изза сарая хлеб ему отбирают. Масло  отобрали уже давно.

Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +2 +/–

Сообщение от YetAnotherOnanym (ok), 07-Апр-24, 10:50

Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг приходится отваливать?", как раз таки питонята будут постоянными поставщиками хлеба с маслом для таких, как я.

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (14), 07-Апр-24, 10:54

Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Tron is Whistling (?), 07-Апр-24, 11:19

Разве что не осилившие.

Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от Аноним (34), 07-Апр-24, 12:12

> Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.
Ты не в тренде. Таки - на игогошку уже давно - которая питона в вебе и загасит. В общем то - уже.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

29. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Прохожий (??), 07-Апр-24, 11:10

Ну, если использовать Питон там, где его использовать не желательно, так и будет, в плане замены Питона на что-то более высокопроизводительное. Но в подавляющем числе случаев (до 70-75%, где-то видел диаграмму) эта производительность особо не нужна, зато важна скорость разработки.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

35. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" –1 +/–

Сообщение от namenotfound (?), 07-Апр-24, 12:16

Да, только на перловку уже ни один сумасшедший не вернётся. Потому что производительность пхутона с читаемостью опусов Рыбаченко.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

47. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (45), 07-Апр-24, 16:23

Как будто, Перл не интерпретатор и его производительность в разы выше питонячей.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

48. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (20), 07-Апр-24, 16:32

Если бизнес таки раскрутится на питоне, то дальше может спокойно решать стоит ли переходить куда-то еще. История знает таких бизнесов препорядочно, включая мегакорпораций. А вот бизнес даже не родившийся потому что воротил нос от питона вместо того чтобы быстро запустить свою идею на нем как-то даже не жалко. Да про таких никто никогда и не узнает, мало ли что какой васян мечтал сделать но не смог запилить ибо не осилил хардкор.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

55. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от Аноним (-), 08-Апр-24, 05:56

> Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе
> вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг
> приходится отваливать?"
Еще раньше они начинают задаваться вопросом "почему все разваливается и постоянно надо переписывать и майнтайнить".

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

42. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от нах. (?), 07-Апр-24, 13:49

> Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему
> переписывание перлового скрипта на питон
не надо - он если и правда умеет, пошлет тебя подальше, со словами - работает вот и не трогай (а когда ты ему в красках опишешь какую супернужную и суперсложную фичу не можешь запилить из-за неправильного языка - еще и покажет какую одну строчку надо поправить в двух местах).
Найти надо выпускника филологического факультета с опытом быстрокурсов на пихоне. И поручить переписывать, опционально снабдив доступом к чатгопоте.
Умения - не требуются!

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

31. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +/–

Сообщение от beck (??), 07-Апр-24, 11:26

Если нужно что-то поправить/переделать,  в питоне это проще и быстрее.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

33. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +2 +/–

Сообщение от Анониссимус (?), 07-Апр-24, 11:53

Это наверное затем, что бы то, что работало 20 лет и кушать не просило, теперь радостно переписывать каждые полгода на новую версию петухона. Верной дорогой идут товарищи!

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

43. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" +1 +/–

Сообщение от нах. (?), 07-Апр-24, 13:50

и чтоб никаких рсинков с немодных платформ!

Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0" –1 +/–

Сообщение от Аноним (45), 07-Апр-24, 16:20

На немодных платформах нет Питона? Очень сомнительно, чтобы сегодня его не было где угодно. ИИ подтверждает.

Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +/–

Сообщение от Аноним (-), 07-Апр-24, 09:06

>опция "-no-overwrite", запрещающая перезапись существующих файлов в целевом каталоге.
Синхронизация с удалённым сервером, это по сути перезапись старых и удаление несуществующих файлов. Если запретить перезапись существующих файлов, как всё это получится на практике? Старые файлы будут переименованы?

Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +/–

Сообщение от Аноним (32), 07-Апр-24, 11:34

они просто останутся нетронутыми.
А рсинк в первую очередь не для синхронизации, а для копирования большого количества файлов.

Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +3 +/–

Сообщение от Анониссимус (?), 07-Апр-24, 12:16

> они просто останутся нетронутыми.
> А рсинк в первую очередь не для синхронизации, а для копирования большого
> количества файлов.
Слово "sync" в названии как-бы говорит о другом.

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." –4 +/–

Сообщение от Петрович 69 (?), 07-Апр-24, 13:06

на уровне bittorrent sync 1.3.109 есть чё?
synthning - бажная шляпа. rsync не кроссплатформенный

Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +/–

Сообщение от Аноним (-), 07-Апр-24, 16:12

>rsync не кроссплатформенный
А нам кроме экосистемы Линукса ничего не надо.

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +/–

Сообщение от Аноним (54), 08-Апр-24, 02:23

Пользовался когда-то сборкой для винды. Работало без проблем, но медленно. Теперь пользуюсь robocopy.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

57. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +/–

Сообщение от pfg21 (ok), 11-Апр-24, 15:32

использую синхфинг уж десяток лет - умвр :) мож у тебя руки не тем концом не туда вставлены ??

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

59. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Т..." +/–

Сообщение от pfg21 (ok), 17-Май-24, 09:29

> на уровне bittorrent sync 1.3.109 есть чё?
> synthning - бажная шляпа. rsync не кроссплатформенный
дык в чем проблема ?? платишь за resilio sync и пользуешь в свое удовольствие. btsync аккурат в resilio переименовали.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

2. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
Сообщение от Аноним (2), 06-Апр-24, 23:56
20 лет feature request'у, а воз и ныне там: https://bugzilla.samba.org/show_bug.cgi?id=2294
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от ls (??), 07-Апр-24, 00:05
	unix вей не позволяет реализовать такие вещи эффективно
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (5), 07-Апр-24, 00:13
	не звезди, при переименовании inode не меняется.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+2 +/–
	Сообщение от Аноним (8), 07-Апр-24, 00:37
	> при переименовании inode не меняется Использовать inode — не unix way.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+2 +/–
	Сообщение от Аноним (13), 07-Апр-24, 06:52
	и как rsync должен знать про inode?
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	4. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от LeNiN (ok), 07-Апр-24, 00:10
	Тут есть что-то про detect-renamed: https://github.com/RsyncProject/rsync-patches
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	7. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от n80 (?), 07-Апр-24, 00:17
	Если не использовать btrfs/zfs (у которых есть свои средства для снимков и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, в моих случаях. По ссылке она упоминается. Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт, так что идеального решения в нём не получится вообще, а приемлемые за эти годы и так плюс-минус запилили. Но можно рассказать про свой сценарий использования, конечно, коллективный разум помогает, когда действительно хочется проблему решить.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	9. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+3 +/–
	Сообщение от Аноним (9), 07-Апр-24, 01:12
	>можно рассказать про свой сценарий использования Синхронизируется каталог с кучей файлов. В какой-то момент каталог переименовывается без изменения содержимого. Так вот rsync в этом случае на целевой машине создаст новый каталог и будет заново качать все его содержимое. Ни какие --fuzzy и, тем более, btrfs/zfs ситуацию не исправляют. >надо залезать на уровень кода файловых систем Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов (на случай если в переименованом каталоге изменились какие-то файлы) и качать только измененные. 20 лет назад описан этот кейс и даже предложен патч detect-renamed. Упрямство не имеет логического объяснения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+4 +/–
	Сообщение от Аноним (14), 07-Апр-24, 09:03
	Напомни почему ты за 20 лет не сделал форк с данным патчем хотябы для себя? Может потому что даже у тебя данный кейс ниразу не случился за 20 лет?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
	Сообщение от Ю.Т. (?), 07-Апр-24, 09:14
	> В какой-то момент каталог переименовывается без изменения содержимого. > Всего-то надо проверить Полагаю, что для выпускника западного универа это не та семантическая разница, которую можно оценить как "всего-то". Это вполне может пониматься как новая сущность, которую безопасно (и как бы даже легально) обработать именно как новую. Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	20. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (20), 07-Апр-24, 09:55
	Unison вроде умеет такое обрабатывать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Ю.Т. (?), 07-Апр-24, 10:30
	> Unison вроде умеет такое обрабатывать. Я говорю о том, что даже если мы на 101% имеем идентичные файлы, то (для западного универсанта) из этого не следует однозначно возможность считать сущность с другим названием тождественной этой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (9), 07-Апр-24, 20:16
	>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши Для любого, западного или восточного, реального практика (в смысле "не теоретика") равенство хэшей sha1 означает, что файлы идентичные. >не та семантическая разница Сферический конь в вакууме.
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	52. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
	Сообщение от Ю.Т. (?), 07-Апр-24, 22:58
	>>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши > Сферический конь в вакууме. Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а не отмахиваются.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (25), 07-Апр-24, 10:47
	Сомнительная идея и антифича. Для типичных применений сабжа, это могут быть разные файлы, принадлежащие разным владельцам, и они будут дописываться в нескольких местах одновременно, т.е. хардлинк тут не канает.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	40. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
	Сообщение от Аноним (-), 07-Апр-24, 13:20
	> Упрямство не имеет логического объяснения. Если тебя это так тревожит, то первое что тебе следует сделать -- связаться с авторами и узнать их объяснение. У них есть irc-канал или что-то в этом роде? Если есть, то это самое правильное место обсуждать такого рода идеи. Если нет, то значит надо выбрать из активных разработчиков кого-то, и написать ему письмо, с объяснением мотивации, метода решения, ссылкой на патчи, и прямо поставить вопрос: что не так и почему это не принимается в дерево. Выше описан самый правильный способ искать объяснения, почему патчи не приняты, но можно поспекулировать. Этот метод, во-первых, требует выбора хеш-алгоритма. Это не самый очевидный выбор (коллизии, скорость вычисления хеша...), но при этом важный выбор, который надо делать осознанно, потому что сменить хеш-алгоритм потом может быть затруднительно из-за беквард-совместимости. Во-вторых, этот метод мне лично выглядит недоделанным костылём. Почему сравниваются директории, а не индивидуальные файлы? При чём тут mtime? По-хорошему ведь, напрашивается сравнивать (size, hash) индивидуальных файлов и если они совпадают, то скопировать mtime, права, атрибуты файла и прочее, что копируется, оставив содержимое нетронутым. А если одеть поверх ещё одну "оптимизацию" и сравнивать не только пары (size, hash), но и вектора (size, hash, mtime, user:group, ... всё остальное что заявлено для копирования), и видеть что вектора равны, то пропускать соответствующий файл. Если уж делать, то как-то так, а не уем об косяк. Потому что если об косяк, то разработчики рискуют потом столкнуться с тем, что предложенный костыль имеет какие-то эдж-кейсы, и ещё хочется функциональность его расширить, но расширить функциональность будет означать сломать обратную совместимость с костыльной реализацией идеи, а значит надо дублировать функциональность некостыльной реализацией. И поэтому, возвращаясь к началу, тебе надо сначала поговорить с разработчиками и понять, что они думают на этот счёт, в какой форме они готовы принять эту фичу. И когда ты поймёшь, что им надо, вот тогда сесть и написать. План действий ясен? Прекращай скулить, приступай к выполнению.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	51. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от n80 (?), 07-Апр-24, 21:17
	> Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов > (на случай если в переименованном каталоге изменились какие-то файлы) и качать только измененные. Так это ни разу не всего-то, считать хеши всех подряд (ведь мы не знаем, что и куда было перемещено) файлов и держать даже сами хеши (всех-всех файлов в синхронизируемом каталоге и его подкаталогах) в памяти удовольствие совсем не бесплатное и экономия канала тут может вообще не оправдаться. Если какая-то редко нужная функциональность ухудшит жизнь тем кому она не нужна — нехорошо получится всё же. Лезть на уровень ФС можно чтобы получить информацию о том что такой-то inode был отлинкован от одного каталога и прилинкован к другому (или что вообще тупо каталог был переименован), при этом данные самого файла не менялись. У rsync между запусками не хранится информация об обрабатывавшихся inode, поэтому ему неоткуда об этом узнать. Патч detect-renamed в каких-то ситуациях проблему решает, но не во всех и в комментарии к патчу прямо есть TODO с планами по доработке. В целом, он здраво выглядит, конечно, так что думаю что доделают то что в TODO (если это будет в приоритете, разработчиков-то мало) и замёржат. Но всегда можно наложить локально, если действительно так надо. В любом случае, спасибо за информацию и пинок подробнее изучить код патчей из rsync-patches.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	53. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (9), 08-Апр-24, 01:40
	>экономия канала тут может вообще не оправдаться Речь идет совсем не об экономии трафика. Время! Поясню: На небольшом сервачке каждую ночь AIDE проверяет неизменность объектов ФС (файлы, линки, директории) одновременно по следующим признакам: permissions, link, user, group, size, mtime, acl, md5 Вот вчерашний лог проверки: Number of entries: 20891 End timestamp: 2024-04-07 02:12:06 +0300 (run time: 0m 5s) 5 (пять!) секунд на 20 тысяч объектов ФС. Суммарный объем этих файлов - 2,8 Гбайт. Если качать их по 100 Мбит линку, то это займет > 280 сек. Даже на скромной виртуалке считать хэши быстрее полной повторной закачки ~ в 50 раз.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от nailts (ok), 18-Апр-24, 16:31
	а если я не переименовывал, а создал новый каталог (или два, три) и скопировал туда файлы?
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	56. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (-), 08-Апр-24, 07:35
	> Если не использовать btrfs/zfs (у которых есть свои средства для снимков > и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, > в моих случаях. По ссылке она упоминается. > Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем Она не решается в хорошем виде в общем случае. В CoW видите ли трекинг изменений часть логики работы ФС, оно делается в фоне, всегда. В случае обычной ФС этого знания просто изначально нет. И вам придется явно угробить ресурсы на его отстраивание и трекинг. Это привносит свой уровень сложности и потребления ресурсов. При том что результат как правило все же хуже чем вон там. Да, дифференциальный btrfs send и точнее, и меньше ресурсов. Что хотите то и делайте с этим фактом. Rsync же скорее для всякой синхры зеркал годится, и даже там грабель - можно огрести от души. Ибо стандартно трекинга отличий нет, полная версия ресурсоемка что капец, а эмпирика - весьма компромиссное решение. > (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт, > так что идеального решения в нём не получится вообще, а приемлемые за эти годы > и так плюс-минус запилили. Но можно рассказать про свой сценарий использования, > конечно, коллективный разум помогает, когда действительно хочется проблему решить. Я бы сказал что рсинк vs вон то все же довольно разные. Скажем делать зеркало скажем репов дистро путем "btrfs send" будет все же несколько странной идеей. Хоть так в принципе и можно при сильном желании.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	49. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от pelmaniac (?), 07-Апр-24, 18:53
	>20 лет feature request'у, а воз и ныне там: кстати да, ещё очивидную фичу "не выходить с ненулевым error-code когда есть missing files" (совершенно нормальная ситуация, когда живую фс копируешь) тоже максимально упорото отказались в апстрим взять, вынесли, типа колхозь скрипты, вася...
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору

10. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
Сообщение от Аноним (10), 07-Апр-24, 01:41
>Переписан на языке Python perl-скрипт mnt-excl Зачем?
Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+3 +/–
	Сообщение от а што не так (?), 07-Апр-24, 02:25
	Чтобы хоть кто-то понимал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	–1 +/–
	Сообщение от Аноним (14), 07-Апр-24, 09:04
	Ну как же, а бизапастность?
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	18. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Ю.Т. (?), 07-Апр-24, 09:15
	Питон это Перл сегодня.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	45. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
	Сообщение от Аноним (45), 07-Апр-24, 16:16
	Гентушники одобряют.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+3 +/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-24, 09:46
	Ну, вот, есть у тебя, например, мыло, а тебе нужно шило. Или, допустим, наоборот. Вот и меняешь одно на другое. А если серьёзно, питон - это язык "лёгкий в освоении и удобный в использовании". Кодеров на питоне - как навоза за сараем. Если Служба занятости отправляет безработного филолога или искусствоведа учиться программированию, то в 99% случаев это будут курсы питона. А вот перловщики - это вымирающий вид. Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему переписывание перлового скрипта на питон.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	21. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
	Сообщение от Аноним (21), 07-Апр-24, 10:24
	Всё правильно понял и описал, только лицо у тебя почему-то недовольное.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+1 +/–
	Сообщение от Аноним (20), 07-Апр-24, 10:27
	Недовольный потому что эти навозные изза сарая хлеб ему отбирают. Масло отобрали уже давно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+2 +/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-24, 10:50
	Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг приходится отваливать?", как раз таки питонята будут постоянными поставщиками хлеба с маслом для таких, как я.
	Ответить \| Правка \| Наверх \| Cообщить модератору