четверг, 1 сентября 2011 г.

linux.debian.user.russian - новые сообщения (6) в темах 2 - обзор

linux.debian.user.russian
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

Комментариев нет:

Отправить комментарий