Если для тебя «ноль копирований вместо двух» — не аргумент, и ты ещё хочешь каких-то бенчмарков... то я рад, что ты не участвуешь в разработке ядра.

В самом деле. Бинарная совместимость *настолько* важна, что я не хочу иметь дела с разработчиками ядра, которые не понимают этой важности.

...

Чёрт возьми, я продолжаю удивляться *идиотам* вокруг, которые не понимают, что бинарная совместимость — один из главных приоритетов.

...

© Торвальдс.

Прекращай путать прямую и обратную совместимость.

взаимосвязанные вещи.

тем же временем у ядра linux свой, ни с чем не совместимый abi, и набор сисколов, аналогов которых нет в других *nix. Линус тот ещё врунишка

4.2, это противоположные вещи.

хорошо что ты не участвуешь в разработке coreutils.

Вне зависимости от того, участвую ли я в разработке coreutils или нет, прямая совместимость и обратная — разные вещи.

• прямая: то, что совместимо с новой версией [ядра], должно быть совместимо и со старыми
• обратная: то, что совместимо со старой версией [ядра], должно оставаться совместимым и с новыми

Линус говорит про обратную совместимость. Ты — про прямую.

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

Он говорит о другой совместимости. Понимаешь, о другой. Впрочем, нет. Ты не способен понимать. Жаль.

зато ты способен понять простую вещь:

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

2. если новая функция обеспечивает явные (практически, а не теоретически) преимущества, то необходимо добавить функционал. Добавить, понимаешь? На новых ядрах с новой функцией, на старых - с совместимой.

у тебя рач гойловного мозга и системде в последней стадии, если для тебя эти вещи не естественны.

Напиши сам. Исходники cp/mv есть в coreutils. Просто к примеру добавь опцию, включающую цветной прогрессбар и прописывай её альясом. Но только в coreutils обратно не коммить, лучше оставь всё на локалхосте, нам не нужны новые поеттеринги.

напиши сам

Ставь double comander короче. У тебя debian, проблем с компиляцией не будет т.к можешь просто поставить deb.
Пока ничего более подходящего для таких целей не знаю.
Если есть что-то получше для работы с файлами с (псевдо)графическим интерфейсом, просветите. Исполюзую только mc т.к ненавистник и неосилятор паскалей.

Но только в coreutils обратно не коммить, лучше оставь всё на локалхосте, нам не нужны новые поеттеринги.

Линуксоиды на острие прогресса!

Но только в coreutils обратно не коммить, лучше оставь всё на локалхосте, нам не нужны новые поеттеринги.

Линуксоиды на острие прогресса!

Коммить-коммить, предыдущий оратор - дурачок.

Леннарт не коммитит, а велосипедит. Вот этого делать не надо.

с форматом 7z

и кстати, я тут налажал, потому что согласно ману: DO NOT USE the 7-zip format. 7-zip does not store the owner/group of the file. Не могу это рекомендовать.

плохой, плохой пинг

ping -O

# ping -O 127.1
ping: invalid option — 'O'
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
[-M mtu discovery hint] [-S sndbuf]
[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination

DO NOT USE the 7-zip format. 7-zip does not store the owner/group of the file.

Спасибо за уточнение. Если нужно сохранить права файлов (например, при резервном копировании системы или конфигов) — я использую tar+gzip т.к. они есть практически везде.

pv уже советовали?

У меня и про gzip есть что сказать :)

The gzip format represents the input size modulo 2^32, so the --list option reports incorrect uncompressed sizes and compression ratios for uncompressed files 4 GB and larger.

мне это попортило нервов с терабайтными .gz образами.

Багу десятки лет, междупрочим. Там тупо фундаментальная проблема в формате gzip, без потери совместимости его не пофиксить. Поэтому, надейюсь, скоро gzip уйдет в небытие :)

ping: invalid option — 'O'

mv, cp, dd etc с прогресс-баром (комментарий)
mv, cp, dd etc с прогресс-баром (комментарий)
Ты всё ещё не обновил пинг до самой свежей преальфы? Товарищ выше утверждает что люди, пользующиеся версией старше 2012 года — безрукое ленивое быдло.

kioclient

слоупоки.жопеге

Багу десятки лет, междупрочим. Там тупо фундаментальная проблема в формате gzip, без потери совместимости его не пофиксить.

Жесть. А почему не сделали какой-нибудь отдельный fxgzip с фиксом? Можно было бы поставлять его вместе со старым gzip для совместимости, при этом старый использовать для распаковки старых архивов, а при создании новых по умолчанию жать только в fxgzip. Со временем проблема отпала бы сама собой.

Поэтому, надейюсь, скоро gzip уйдет в небытие :)

Изначальный бажный формат в любом случае протухнет.

Там не то что кед, иксов нет.

нет

А почему не сделали какой-нибудь отдельный fxgzip с фиксом?

Это риторический вопрос, я понимаю. Потому что «не нужно» же, как обычно. Данная ветка иллюстрирует

Они убили мою систему. Теперь я даже не знаю, как wifi настроить через gui. network-manager уже не подходит, wicd жрёт батарейку, dhcpcd-ui не работает.

На самом деле, раз уж метод (формат) всеравно меняется, надо выбрать который получше. Сейчас самый рабочий вариант - это bzip2. У lzma2 (который круче!) нет реализации многопоточной декомпресии (по крайней мере, я не нашел). Автора 7z в дискуссиях на sourceforge пока не удавалось убедить в необходимости многопоточной декомпрессии чего-то, кроме bzip2. Да много еще в чем. Сейчас у меня возникает идея скинуться ему на кикстартере на это + рид-соломон + выбор алгоритма чексум + адаптация формата 7z к правам posix Как бы замутить...

Да.

% ping -O 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
no answer yet for icmp_seq=1
no answer yet for icmp_seq=2
no answer yet for icmp_seq=3
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3023ms

Отлично, спасибо. Не зря топик создали

Что у вас за говно мамонта

не localhost

Всю тему не читал, gcp предлагали?

 gcp is an advanced command line file copy system with an interface similar to
 that of cp. It features:
  - transfer progression indication
  - continuous copying on error (skip to next file)
  - copy status logging
  - name mangling to handle target filesystem limitations
  - forced copy serialization
  - transfer lists management

Ну, попробуй штоле обновлять свой нилокалхост чаще чем раз в десять лет.

я в нулевом посте имел в виду расширение функционала и повышение удобства, о котором спрашивают как минимум с 2005 года

Никогда его не будет. Этот функционал - нарушение той концепции, по которой упомянутый софт вообще появился. Тут либо писать свой софт, по своей концепции, либо воспользоваться предложенными костылями в рамках исходной.

что там у вас за ынтерпрайз такой, в котором ничего не работает. секретутские кампутеры?

я бы тебе сказал, да ты всё равно не поймёшь

скорее похоже, что нечем похвалится. ну да не расстраивайся

Никогда его не будет.

Есть заявление разработчиков?

Этот функционал - нарушение той концепции, по которой упомянутый софт вообще появился

О какой концепции идёт речь?

для dd - watch с kill -USR1 $PID

для cp - флаг -v

для mv - ничего: я либо копирую с проверкой по месту, а потом удаляю, либо rm сразу, ежели не нужно

для scp использую du -hs в $TARGET_DIR в watch или руками

И в скриптах вывод подавлять придеться.

Можно же просто добавить ключ дл прогрессбара

Если у тебя тонны мелочи и ФС, типа фрагментированной ext4 на нагруженной машине, то оверхед будет в аккурат 100%. В смысле время копирования удвоится.

Если у тебя тонны мелочи и ФС, типа фрагментированной ext4 на нагруженной машине

Это частный случай, когда можно просто сделать \mv или \cp.

А когда мне нужно скопировать с прогрессбаром не глядя на оверхед, я просто использую mc :)

Поддерживаю. Раз в год бывает индикатора не хватает, du нормально это решает.

А когда мне нужно скопировать с прогрессбаром не глядя на оверхед, я просто использую mc :)

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

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

Ну так и получается, что при наличии прогрессбара либо тебе придётся каждый раз запускать копирование с этим прогрессбаром и потом материться, что ты не отключил его, запустив копирование миллиона мелких файлов, либо по умолчанию прогресс-бар не использовать, а потом также материться, что не включил его через 10-15 минут после начала «тихого» копирования :)

Ну так и получается, что при наличии прогрессбара либо тебе придётся каждый раз запускать копирование с этим прогрессбаром и потом материться, что ты не отключил его, запустив копирование миллиона мелких файлов, либо по умолчанию прогресс-бар не использовать, а потом также материться, что не включил его через 10-15 минут после начала «тихого» копирования :)

Выбор зависит от частоты решаемых задач, суть же этого треда в отсутствии такого выбора. На практике копировать миллионы мелочи, тормозящей время, мне приходится гораздо реже чем несколько больших файлов. На нагруженных системах с фрагментированными ФС никто не заставляет использовать этот флаг, но в обычных условиях такой возможности изкоробки часто сильно не хватает, что подтверждается количеством разномастных альтернативных решений и вновь появляющимися тредами на LOR/SO/etc.