Подписки: linux.debian.user.russian - новые сообщения (19) в темах 4

linux.debian.user.russian
http://groups.google.com/group/linux.debian.user.russian?hl=ru

linux.debian.user.russian@googlegroups.com

Темы дня:

* dd - сообщений: 11, авторов: 5
http://groups.google.com/group/linux.debian.user.russian/t/1c40d49e503dacaa?hl=ru
* Не работает GLX Debian Squeeze/Wheezy, черный экран при обращении к Open GL -
сообщений: 4, авторов: 3
http://groups.google.com/group/linux.debian.user.russian/t/abc0b5ccd7cfbf7f?hl=ru
* Файловая система для множественного монтирования - сообщений: 2, авторов: 2
http://groups.google.com/group/linux.debian.user.russian/t/15e7feff508e56c6?hl=ru
* про exim -f - сообщений: 2, авторов: 2
http://groups.google.com/group/linux.debian.user.russian/t/69ab0e2d7b929a71?hl=ru

==============================================================================
ТЕМА: dd
http://groups.google.com/group/linux.debian.user.russian/t/1c40d49e503dacaa?hl=ru
==============================================================================

== 1 с 11 ==
Дата: Чт. 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

== 2 с 11 ==
Дата: Чт. 1 сен 2011 04:20
От: Иван Лох

On Thu, Sep 01, 2011 at 09:51:18AM +0400, Artem Chuprina wrote:
> cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко
> оказывается лучше, чем rsync -a. И в половине случаев при этом на самом деле
> нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о
> нижепроцитированном sendfile(2), которая в этом последнем случае немедленно
> начинает проигрывать cp в разы по скорости и квадратично по месту на диске.

Вопрос же не в том cp или rsync, а в том open/write или специальным ядерным вызовом.
Понятно, что чем изощреннее становятся оба планировщика, чем сложнее дисковые драйверы
и сами диски, тем больше будет разрыв в производительности между двумя подходами.

Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и широкого
прорастания этого Non Stable API в userspace. Его козырем всегда был и будет +1% к
производительности. А он и есть IMHO за счет Non Stable API.

> вообще. Потому что нигде больше не применяемый и оттого не стандартизованный
> sendfile(2) вдруг взял и разучился копировать между файлами.

Fall back to read/write все делают.

--
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/20110901111416.GA12097@nano.ioffe.rssi.ru

== 3 с 11 ==
Дата: Чт. 1 сен 2011 06:50
От: Artem Chuprina

> > Я понимаю, что рассылка тематическая, но у меня есть, гм,
> > предубеждение, что линукс-специфичное решение, как правило, хуже
> > общеюниксового там, где их сложность сравнима, а
> > дистрибутив-специфичное решение там, где есть хотя бы общее
> > линукс-специфичное, обычно вообще невменяемо.
>
> У меня тоже есть такое предубеждение, но я его ещё и обосновываю :) Если
> некая линуксовая бранзулетка так уж хороша, почему её не стырили хотя бы
> окружающие фрюниксы? Впрочем, этот аргумент работает только на длинных
> интервалах времени, или на фичах с простой реализацией (когда самое
> трудное было додуматься до идеи). Да и то есть исключение, имхо: futexes
> не расхватали просто потому, что тупыыыые.

Ну и помимо фрюниксов, которых, собственно, одна FreeBSD, есть еще и другие
юниксы. В части из которых этого не сделали, потому что они не фрюниксы, а в
части - по другим соображениям, например, безопасности (меньше кода - легче
аудит).

> >> Кстати, я вспомнил ещё один подход: писал когда-то простенькую
> >> хреновину на си, содержательная часть которой состояла в вызове
> >> sendfile(2) (оно тогда умело между файлами копировать; сейчас это
> >> splice(2), если не ошибаюсь).
> >
> > Вот, кстати, да. Яркий пример. Выигрыш в производительности в
> > полтора раза ценой того, что в какой-то момент хреновина ВНЕЗАПНО
> > перестает работать вообще. Потому что нигде больше не применяемый и
> > оттого не стандартизованный sendfile(2) вдруг взял и разучился
> > копировать между файлами.
>
> Ну какое там внезапно -- даже специально не отслеживая, я прочитал о
> том, что так будет, сильно раньше чем ядром 2.6 стало можно
> пользоваться (к тому же, когда с переходом 2.4->2.6 что-то перестаёт
> работать, это /по построению/ ни хрена не ВНЕЗАПНО).

Это для программиста, который следит за ядром (и знает, что у него в программе
есть сисколлы, по-разному работающие в разных юниксах), оно не внезапно. А
для сисадмина, который сапгрейдил дистрибутив на сервере и у него отвалилась
софтина, написанная тем программистом - внезапно. А мы тут обсуждаем скорее
сисадминскую, чем программистскую деятельность - пользование системой, а не
написание под нее программ.

> Насчёт «больше нигде не применяемый»: ну да, накрылась именно та /часть/
> функциональности, которая была линукс-специфична. А для сокетов sendfile
> есть чуть ли не вообще везде; способ с ним обращаться отличается, но
> смысл тот же (и на винде есть, только TransmitFile называется).
> Если вспомнить, как модно было пузомерствовать в области раздачи статики
> через http -- оно и неудивительно.

Поправка насчет больше нигде не применяемой /части функциональности/
sendfile(2) принята :-)

--
Юзер обожает терпеть мелкие неудобства
Victor Wagner

== 4 с 11 ==
Дата: Чт. 1 сен 2011 07:00
От: Artem Chuprina

> > cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко
> > оказывается лучше, чем rsync -a. И в половине случаев при этом на самом
> > деле нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о
> > нижепроцитированном sendfile(2), которая в этом последнем случае
> > немедленно начинает проигрывать cp в разы по скорости и квадратично по
> > месту на диске.
>
> Вопрос же не в том cp или rsync, а в том open/write или специальным ядерным
> вызовом. Понятно, что чем изощреннее становятся оба планировщика, чем
> сложнее дисковые драйверы и сами диски, тем больше будет разрыв в
> производительности между двумя подходами.

Видишь ли, cp -al - это не open/write и не sendfile(2). Это link(2).

> Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и
> широкого прорастания этого Non Stable API в userspace. Его козырем всегда
> был и будет +1% к производительности. А он и есть IMHO за счет Non Stable
> API.

Я же не говорю, что линукс-специфичное решение _всегда_ хуже. Там, где тебе
действительно нужен +1% - не вопрос, оптимизируй.

Когда у тебя прорва файлов и ты точно знаешь, что тебе их надо скопировать из
одной директории в другую не глядя, надо сделать это один раз и на линуксе, cp
-a в норме будет быстрее, чем rsync -a, не вопрос. Потому что не будет читать
даже целевое дерево, не говоря уже о файлах (интересно, у rsync есть
противоестественный интеллект на тему "если копирование локальное, не считать
контрольные суммы и дельты, а гнать файл не глядя"? и если он есть, то хорошо
ли это для копирования на флешки?)

> > вообще. Потому что нигде больше не применяемый и оттого не
> > стандартизованный sendfile(2) вдруг взял и разучился копировать между
> > файлами.
>
> Fall back to read/write все делают.

Если нет жестких требований к производительности, то дешевле сразу написать
read/write, чем писать sendfile и fallback на тот же самый read/write. А если
есть, то какой нафиг fallback?

Нет, я понимаю, есть узкий класс задач, где это имеет смысл.

--
Unix-like -- для кинестетиков, Emacs -- для аудиалов, Mac -- для визуалов,
Windows -- для чайников
-- RockMover in <RM279891167063140rmover@golovolomka.net>

== 5 с 11 ==
Дата: Чт. 1 сен 2011 07:10
От: Иван Лох

On Thu, Sep 01, 2011 at 05:53:31PM +0400, Artem Chuprina wrote:
> > > немедленно начинает проигрывать cp в разы по скорости и квадратично по
> > > месту на диске.
> >
> Видишь ли, cp -al - это не open/write и не sendfile(2). Это link(2).

Я в курсе. Именно поэтому мне трудно понять какое отношение к ней имеет sendfile.

> > Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и
> >
> > Fall back to read/write все делают.
>
> Если нет жестких требований к производительности, то дешевле сразу написать
> read/write, чем писать sendfile и fallback на тот же самый read/write. А если
> есть, то какой нафиг fallback?
>
> Нет, я понимаю, есть узкий класс задач, где это имеет смысл.

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

== 6 с 11 ==
Дата: Чт. 1 сен 2011 07:50
От: Anton Kovalenko

Artem Chuprina <ran@ran.pp.ru> writes:

> (интересно, у rsync есть противоестественный интеллект на тему "если
> копирование локальное, не считать контрольные суммы и дельты, а гнать
> файл не глядя"?

Rsync мог и «поумнеть» (чему я нифига не обрадуюсь), но традиционно у
него даже идея сделать всё в рамках одного процесса не возникает. На том
месте, где обычно происходит запуск удаленной копии rsync, он форкается
-- вот и весь интеллект (да и тот при указании --rsync-path пропадает).

> и если он есть, то хорошо ли это для копирования на флешки?)

Если бы он был (или если он ВНЕЗАПНО есть), это ни для чего
нехорошо. Единственная детерминированная софтина осталась -- пожалели бы
редкую зверушку.

--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia

== 7 с 11 ==
Дата: Чт. 1 сен 2011 08:20
От: Artem Chuprina

> > > > немедленно начинает проигрывать cp в разы по скорости и квадратично по
> > > > месту на диске.
> > >
> > Видишь ли, cp -al - это не open/write и не sendfile(2). Это link(2).
>
> Я в курсе. Именно поэтому мне трудно понять какое отношение к ней имеет
> sendfile.

Речь шла о кастомной программе с использованием sendfile, которая выигрывала
десятки процентов у cp. Я говорю о том, что да, у cp -a она выиграет десятки
процентов. А cp -al, если оная вдруг применима, проиграет в разы. К вопросу
об использовании более или менее стандартных решений.

> > > Ну и потом linux не добился бы никакого успеха без "Stable API
> > > Nonsense", и
> > >
> > > Fall back to read/write все делают.
> >
> > Если нет жестких требований к производительности, то дешевле сразу
> > написать read/write, чем писать sendfile и fallback на тот же самый
> > read/write. А если есть, то какой нафиг fallback?
> >
> > Нет, я понимаю, есть узкий класс задач, где это имеет смысл.
>
> IMHO жесткие требования на высокую производительность при копировании файлов,
> есть почти всегда. read/write имеет смысл сразу делать только для небольших файлов.

Повторюсь: а если требования жесткие, то какой нафиг fallback? Жесткие - это
значит, что read/write не тянут. Если они не тянут, то делать на них fallback
нельзя.

--
The effort of using machines to mimic the human mind has always struck
me as rather silly. I would rather use them to mimic something better
-- Edsger Dijkstra

== 8 с 11 ==
Дата: Чт. 1 сен 2011 08:40
От: Andrey Rahmatullin

On Thu, Sep 01, 2011 at 05:53:31PM +0400, Artem Chuprina wrote:
> (интересно, у rsync есть противоестественный интеллект на тему "если
> копирование локальное, не считать контрольные суммы и дельты, а гнать
> файл не глядя"? и если он есть, то хорошо ли это для копирования на
> флешки?)
А зачем тогда rsync?
Я ещё понимаю, если посчитать чексумму N байт дешевле, чем эти N байт
переписать ими же самими, тут rsync со стандартным алгоритмом полезен даже
локально.

--
WBR, wRAR

== 9 с 11 ==
Дата: Чт. 1 сен 2011 09:30
От: Anton Kovalenko

Artem Chuprina <ran@ran.pp.ru> writes:

> (интересно, у rsync есть противоестественный интеллект на тему "если
> копирование локальное, не считать контрольные суммы и дельты, а гнать
> файл не глядя"? и если он есть, то хорошо ли это для копирования на
> флешки?)

Если подумать, то не с той стороны вы ждёте интеллекта :) Флешка,
которая снаружи видна как нечто хардообразное (usd-storage, ide, cf...),
наверняка много размышляет о том, как бы блоки раскидать, и контрольные
суммы тоже считает; на этом фоне было бы очень странно, если перезапись
блока его же содержимым приводила бы к реальному стиранию.

"Голая" флешка (без usb-storage и прочего интеллекта) имеет ещё одно
полезное свойство: хотя стирается она только блоками, никто не
заставляет на неё блоками записывать (для программиста это выглядит
примерно так: по команде стирания в блоке все биты "объединичиваются", а
вот "обнулять" их обратно можно в каком угодно порядке -- не то что
блоков никаких нет, даже и байты значения не имеют). Если "обвязка",
предоставляющая usb-storage, будет по-умному это свойство использовать,
можно ожидать, что и запись блока данных поверх блока нулей не приведёт
к лишнему циклу стирания по сравнению с записью данных /сразу/.

(Впрочем, если недодумать, журналированная ФС может подключить /свой/
интеллект, и тогда есть вероятность, что стирание всё-таки произойдёт, и
не одно).

--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia

== 10 с 11 ==
Дата: Чт. 1 сен 2011 13:10
От: Artem Chuprina

> > (интересно, у rsync есть противоестественный интеллект на тему "если
> > копирование локальное, не считать контрольные суммы и дельты, а гнать
> > файл не глядя"? и если он есть, то хорошо ли это для копирования на
> > флешки?)
> А зачем тогда rsync?

Затем, что он одинаково работает и на линуксе, и на солярке. В отличие от
cp. И одинаково успешно работает локально и удаленно. Опять же в отличие от
cp.

--
Все гениальное просто.
Но со вкусом.
Кнышев.

== 11 с 11 ==
Дата: Чт. 1 сен 2011 21:30
От: Ivan Shmakov

>>>>> "AC" == Artem Chuprina <ran@ran.pp.ru> writes:

[…]

AC> Когда у тебя прорва файлов и ты точно знаешь, что тебе их надо
AC> скопировать из одной директории в другую не глядя, надо сделать это
AC> один раз и на линуксе, cp -a в норме будет быстрее, чем rsync -a,
AC> не вопрос. Потому что не будет читать даже целевое дерево, не
AC> говоря уже о файлах (интересно, у rsync есть противоестественный
AC> интеллект на тему "если копирование локальное, не считать
AC> контрольные суммы и дельты, а гнать файл не глядя"?

Похоже, что есть.

--cut: rsync(1) --
-W, --whole-file
With this option rsync's delta-transfer algorithm is not used
and the whole file is sent as-is instead. The transfer may be
faster if this option is used when the bandwidth between the
source and destination machines is higher than the bandwidth to
disk (especially when the "disk" is actually a networked
filesystem). This is the default when both the source and des‐
tination are specified as local paths, but only if no batch-
writing option is in effect.
--cut: rsync(1) --

AC> и если он есть, то хорошо ли это для копирования на флешки?)

Перед копированием, rsync(1), в отличие от cp(1), может сравнить
m-time и длину файлов, и не копировать в случае совпадения. Для
cp(1), IIRC, есть только --update.

[…]

--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)

==============================================================================
ТЕМА: Не работает GLX Debian Squeeze/Wheezy, черный экран при обращении к
Open GL
http://groups.google.com/group/linux.debian.user.russian/t/abc0b5ccd7cfbf7f?hl=ru
==============================================================================

== 1 с 4 ==
Дата: Чт. 1 сен 2011 06:10
От: basilio

Всем спасибо.
Т.е., насколько я понял, чтобы без глобальных потрясений (я скорее юзер,
чем админ, комп реально используется для работы) это или ждать, или в
сторону предыдущих версий / других дистрибутивов смотреть?
Хотя, другой дистриб - это тоже глобальное потрясение, так что не подходит.

== 2 с 4 ==
Дата: Чт. 1 сен 2011 06:10
От: basilio

Sid не помог мне, увы. То же черное окошко. Что можно еще попробовать?
Спасибо заранее.

30.08.2011 04:00, Сергей Кондурян пишет:
> 30.08.2011 00:01, basilio пишет:
>> Суть проблемы: в Debian Squeeze/Wheezy после одного из обновлений отпал
>> OpenGL. При обращении к его функциям получаем черное окно (экран).
>> Ситуация, судя по симптомам, похожа на описанную здесь blog.mraw.org и
>> возникла примерно в то же время (вторая половиня июня). Поэтому
>> подумалось, что все рассосется само собой, Тем более, что репозитории
>> тестируемой версии подключены. Но уже август заканчивается, а проблема
>> осталась до сих пор.
>> Установлены (из оф. репозиториев):
>> Xorg 1:7.6+8
>> xserver-xorg-video-radeon 1:6.14.2-1
>> libgl1-mesa-dri 7.11~0-2
>> Железо:ноут Acer; видео ATI Mobility Radeon HD 4250.
>>
>> glxinfo ошибок не выдает. glxgears показывает черное окошко.
>>
>> Может у кого был уже аналогичный случай. Спасибо заранее.
>>
>>
> Может попробовать с сида поставить?
>
>

== 3 с 4 ==
Дата: Пт. 2 сен 2011 00:00
От: Peter Evdokimov

On Thu, 01 Sep 2011 15:54:24 +0300
basilio wrote:

> Всем спасибо.
> Т.е., насколько я понял, чтобы без глобальных потрясений (я скорее
> юзер, чем админ, комп реально используется для работы) это или ждать,
> или в сторону предыдущих версий / других дистрибутивов смотреть?
> Хотя, другой дистриб - это тоже глобальное потрясение, так что не
> подходит.

Проблема в том, что у меня sid и nvidia. Поэтому кроме того, что
откатить пакеты взад =) ничего более не присоветую.

sy,
peter

== 4 с 4 ==
Дата: Пт. 2 сен 2011 00:40
От: Konstantin Fadeyev

У меня был Radeon X1650 и Ленни. После обновления на тестинг
отвалилось 3д и вообще с видео было не всё в порядке. Чего только не
вытворял, в итоге снёс и поставил тестинг с еженедельного образа. С
видео относительно наладилось. Драйвера свободные.
Не предлагаю к повтору, просто делюсь опытом.

--
Константин Фадеев

==============================================================================
ТЕМА: Файловая система для множественного монтирования
http://groups.google.com/group/linux.debian.user.russian/t/15e7feff508e56c6?hl=ru
==============================================================================

== 1 с 2 ==
Дата: Чт. 1 сен 2011 11:50
От: Denis Zaletov

Добрый день.

Существует ли в debian поддержка файловой системы, которую можно
смонтировать на запись несколько раз? Если не ошибаюсь, этот тип файловой
системы называется параллельным. Уточню, не сетевая кластерная файловая
система, вопрос о фс только для локального диска, конкретно, необходимо
разделить фс между domu Xen'а.

Спасибо!
--
Денис.

== 2 с 2 ==
Дата: Пт. 2 сен 2011 01:20
От: alexander barakin

On Thu, Sep 01, 2011 at 10:42:36PM +0400, Denis Zaletov wrote:
> Добрый день.
>
> Существует ли в debian поддержка файловой системы, которую можно
> смонтировать на запись несколько раз? Если не ошибаюсь, этот тип файловой
> системы называется параллельным. Уточню, не сетевая кластерная файловая
> система, вопрос о фс только для локального диска, конкретно, необходимо
> разделить фс между domu Xen'а.

http://www.novell.com/support/viewContent.do?externalId=7004451&sliceId=1
читали?

p.s. google://xen+shared+disk

--
wbr, alexander barakin aka sash-kan.

==============================================================================
ТЕМА: про exim -f
http://groups.google.com/group/linux.debian.user.russian/t/69ab0e2d7b929a71?hl=ru
==============================================================================

== 1 с 2 ==
Дата: Чт. 1 сен 2011 16:20
От: sergio

Всем привет.

Есть exim с виртуальными доменами и пользователями. Не локальные письма он
принимает только от авторизованных пользователей. И только с тех адресов,
которые принадлежат пользователю.

А ещё есть локальные пользователи, от которых exim тоже принимает почту
и отправляет как от localuser@maindomain. Но для локальных пользователей
существуют виртуальные, с принадлежащими им адресами.

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

--
sergio.

== 2 с 2 ==
Дата: Пт. 2 сен 2011 01:20
От: "volk@lab127.karelia.ru"

02.09.2011 3:10, sergio пишет:
> Всем привет.
>
> Есть exim с виртуальными доменами и пользователями. Не локальные письма он
> принимает только от авторизованных пользователей. И только с тех адресов,
> которые принадлежат пользователю.
>
> А ещё есть локальные пользователи, от которых exim тоже принимает почту
> и отправляет как от localuser@maindomain. Но для локальных пользователей
> существуют виртуальные, с принадлежащими им адресами.
>
> Так вот хочется сделать так, что бы локальные пользователи могли отсылать почту
> со своих адресов, при этом не позволяя им отсылать почту с любых адресов.
http://www.lissyara.su/articles/freebsd/mail/exim+courier-imap/

--
Александр Сергеевич Волков
Ведущий программист

http://www.rfidjournal.com/article/view/8600/1 - Read the story in RFID

mob: +79215283540
e-mail: volk@lab127.karelia.ru
skype: v2003_2003@mail.ru

==============================================================================

Данное сообщение отправлено Вам, так как Вы являетесь подписчиком Группы 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

Подписки

пятница, 2 сентября 2011 г.

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

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

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

пятница, 2 сентября 2011 г.

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

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

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

пятница, 2 сентября 2011 г.