http://groups.google.com/group/linux.debian.user.russian?hl=ru
linux.debian.user.russian@googlegroups.com
Темы дня:
* dd - сообщений: 5, авторов: 4
http://groups.google.com/group/linux.debian.user.russian/t/1c40d49e503dacaa?hl=ru
* IV Международная конференция разработчиков и пользователей свободного
программного обеспечения FOSS Sea 2011 - сообщений: 1, 1 автор
http://groups.google.com/group/linux.debian.user.russian/t/69eea6639eea7159?hl=ru
==============================================================================
ТЕМА: dd
http://groups.google.com/group/linux.debian.user.russian/t/1c40d49e503dacaa?hl=ru
==============================================================================
== 1 с 5 ==
Дата: Ср. 31 авг 2011 00:50
От: alexander barakin
On Wed, Aug 31, 2011 at 03:29:51AM +0600, Murat D. Kadirov wrote:
> On Tue, Aug 30, 2011 at 11:32:30PM +0400, alexander barakin wrote:
> > On Tue, Aug 30, 2011 at 09:57:02PM +0400, sergio wrote:
> > > On 08/30/2011 09:54 PM, Anton Kovalenko wrote:
> > >
> > > > -o loop
> > > Это больше не обязательно.
> >
> > хм· и давно настало это <<больше>>?
> > $ sudo mount test.image /media
> > mount: test.image is not a block device (maybe try `-o loop'?)
> > $ lsb_release -rdc
> > Description: Debian GNU/Linux 6.0.2 (squeeze)
> > Release: 6.0.2
> > Codename: squeeze
> >
> > p.s. а вот использовать dd -- действительно, необходимости нет·
> > /bin/cp прекрасно справляется·
>
> Александр, я честно говоря не понимаю, чем вас так не устраивает
> использование утилиты dd. Всякое упоминание dd в рассылке обязательно
> вызывает у вас подобный комментарий о неуместности использования dd,
> когда есть cp.
играю роль <<разрушителя мифов>>·
--
wbr, alexander barakin aka sash-kan.
--
To UNSUBSCRIBE, email to debian-russian-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20110831073934.GB27511@teta.mezon.local
== 2 с 5 ==
Дата: Ср. 31 авг 2011 12:10
От: Stanislav Maslovski
On Wed, Aug 31, 2011 at 09:58:38AM +0600, Sergej Kochnev wrote:
> On Wed, 31 Aug 2011 03:29:51 +0600 "Murat D. Kadirov" <banderols@gmail.com> wrote:
> >Александр, я честно говоря не понимаю, чем вас так не устраивает
> >использование утилиты dd. Всякое упоминание dd в рассылке обязательно
> >вызывает у вас подобный комментарий о неуместности использования dd,
> >когда есть cp.
> >
>
> dd практически всегда нуждается в указании bs для оптимального
> быстродействия, чем не страдают cat/pv.
... в которых размер буфера наверняка забит руками раз и навсегда,
что тоже не есть хорошо.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russian-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20110831190134.GA6022@kaiba.homelan
== 3 с 5 ==
Дата: Ср. 31 авг 2011 12:30
От: Anton Kovalenko
Stanislav Maslovski <stanislav.maslovski@gmail.com> writes:
>> dd практически всегда нуждается в указании bs для оптимального
>> быстродействия, чем не страдают cat/pv.
>
> ... в которых размер буфера наверняка забит руками раз и навсегда,
> что тоже не есть хорошо.
... но там запросто может быть забито руками что-то поумнее
умолчательного bs=512.
По-моему, никому не помешает периодическое напоминание о том, что cp и
cat тоже справляются (особенно если оно не утверждает великую кошерность
cp и халяльность cat на фоне скоромности dd).
Кстати, я вспомнил ещё один подход: писал когда-то простенькую хреновину
на си, содержательная часть которой состояла в вызове sendfile(2) (оно
тогда умело между файлами копировать; сейчас это splice(2), если не
ошибаюсь). Использовал её для разделов и для больших файлов (типа
образов CD), где копирование тормозило; разница по времени с cp
иногда была раза в полтора (ну, точно не помню, но десятки процентов).
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
== 4 с 5 ==
Дата: Ср. 31 авг 2011 23:00
От: Artem Chuprina
> >> dd практически всегда нуждается в указании bs для оптимального
> >> быстродействия, чем не страдают cat/pv.
> >
> > ... в которых размер буфера наверняка забит руками раз и навсегда,
> > что тоже не есть хорошо.
>
> ... но там запросто может быть забито руками что-то поумнее
> умолчательного bs=512.
>
> По-моему, никому не помешает периодическое напоминание о том, что cp и
> cat тоже справляются (особенно если оно не утверждает великую кошерность
> cp и халяльность cat на фоне скоромности dd).
Тогда только надо не забывать упоминать, в каких именно ОС они справляются.
Я понимаю, что рассылка тематическая, но у меня есть, гм, предубеждение, что
линукс-специфичное решение, как правило, хуже общеюниксового там, где их
сложность сравнима, а дистрибутив-специфичное решение там, где есть хотя бы
общее линукс-специфичное, обычно вообще невменяемо.
cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко
оказывается лучше, чем rsync -a. И в половине случаев при этом на самом деле
нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о
нижепроцитированном sendfile(2), которая в этом последнем случае немедленно
начинает проигрывать cp в разы по скорости и квадратично по месту на диске.
> Кстати, я вспомнил ещё один подход: писал когда-то простенькую хреновину
> на си, содержательная часть которой состояла в вызове sendfile(2) (оно
> тогда умело между файлами копировать; сейчас это splice(2), если не
> ошибаюсь).
Вот, кстати, да. Яркий пример. Выигрыш в производительности в полтора раза
ценой того, что в какой-то момент хреновина ВНЕЗАПНО перестает работать
вообще. Потому что нигде больше не применяемый и оттого не стандартизованный
sendfile(2) вдруг взял и разучился копировать между файлами.
> Использовал её для разделов и для больших файлов (типа
> образов CD), где копирование тормозило; разница по времени с cp
> иногда была раза в полтора (ну, точно не помню, но десятки процентов).
--
Весь юникс для того и был придуман, чтобы PS в принтер выплевывать.
Alex Korchmar в <a63nn3$ef7$1@alx.private>
--
To UNSUBSCRIBE, email to debian-russian-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87k49sq089.wl%ran@ran.pp.ru
== 5 с 5 ==
Дата: Чт. 1 сен 2011 00:20
От: Anton Kovalenko
Artem Chuprina <ran@ran.pp.ru> writes:
> Я понимаю, что рассылка тематическая, но у меня есть, гм,
> предубеждение, что линукс-специфичное решение, как правило, хуже
> общеюниксового там, где их сложность сравнима, а
> дистрибутив-специфичное решение там, где есть хотя бы общее
> линукс-специфичное, обычно вообще невменяемо.
У меня тоже есть такое предубеждение, но я его ещё и обосновываю :) Если
некая линуксовая бранзулетка так уж хороша, почему её не стырили хотя бы
окружающие фрюниксы? Впрочем, этот аргумент работает только на длинных
интервалах времени, или на фичах с простой реализацией (когда самое
трудное было додуматься до идеи). Да и то есть исключение, имхо: futexes
не расхватали просто потому, что тупыыыые.
[...]
>> Кстати, я вспомнил ещё один подход: писал когда-то простенькую
>> хреновину на си, содержательная часть которой состояла в вызове
>> sendfile(2) (оно тогда умело между файлами копировать; сейчас это
>> splice(2), если не ошибаюсь).
>
> Вот, кстати, да. Яркий пример. Выигрыш в производительности в
> полтора раза ценой того, что в какой-то момент хреновина ВНЕЗАПНО
> перестает работать вообще. Потому что нигде больше не применяемый и
> оттого не стандартизованный sendfile(2) вдруг взял и разучился
> копировать между файлами.
Ну какое там внезапно -- даже специально не отслеживая, я прочитал о
том, что так будет, сильно раньше чем ядром 2.6 стало можно
пользоваться (к тому же, когда с переходом 2.4->2.6 что-то перестаёт
работать, это /по построению/ ни хрена не ВНЕЗАПНО).
Насчёт <<больше нигде не применяемый>>: ну да, накрылась именно та /часть/
функциональности, которая была линукс-специфична. А для сокетов sendfile
есть чуть ли не вообще везде; способ с ним обращаться отличается, но
смысл тот же (и на винде есть, только TransmitFile называется).
Если вспомнить, как модно было пузомерствовать в области раздачи статики
через http -- оно и неудивительно.
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
==============================================================================
ТЕМА: IV Международная конференция разработчиков и пользователей свободного
программного обеспечения FOSS Sea 2011
http://groups.google.com/group/linux.debian.user.russian/t/69eea6639eea7159?hl=ru
==============================================================================
== 1 с 1 ==
Дата: Ср. 31 авг 2011 10:50
От: Sohin Vyacheslav
29.08.2011 21:14, Dmitry Spodarets пишет:
> Центр суперкомпьютерных вычислений и свободного программного обеспечения
> ИИ ОНУ им. И.И. Мечникова совместно с компанией RootUA Media снова
> собирает всех, для кого важны открытые и свободные IT-технологии, на IV
> Международной конференции разработчиков и пользователей свободного
> программного обеспечения FOSS Sea 2011.
да уж, звучит пафосно, чуть ли не межгалактический Центр
перекомпьютерных вычислений...
--
Best wishez,
Сохин Вячеслав
--
To UNSUBSCRIBE, email to debian-russian-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4E5E71AB.5050909@yandex.ua
==============================================================================
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком Группы Google: "linux.debian.user.russian"
группа.
Чтобы отправить в эту группу сообщение, посетите страницу: http://groups.google.com/group/linux.debian.user.russian?hl=ru
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: linux.debian.user.russian+unsubscribe@googlegroups.com
Чтобы изменить способ получения электронной почты из этой группы, посетите:
http://groups.google.com/group/linux.debian.user.russian/subscribe?hl=ru
Чтобы сообщить о ненадлежащем использовании, отправьте электронное сообщение
с описанием проблемы на адрес abuse@googlegroups.com
==============================================================================
Группы Google: http://groups.google.com/?hl=ru
Комментариев нет:
Отправить комментарий