subject:"Re\: xserver\-xorg и hal"

On Mon, May 04, 2009 at 07:30:42PM +0400, Alexey Pechnikov wrote:
 Hello!
 
 On Monday 04 May 2009 19:02:01 Artem Chuprina wrote:
  Я верю в осмысленность разделяемой памяти для баз данных.  Для беготни
  по индексам в условиях, когда mmap() работает на запись неоптимально.  А
  так как-то сходу больше и не приведу примеров...
 
 Разработчики Оракла тоже верили. Вот только почему-то действительно
 большие БД ( 10 Тб) с оракла зачастую перетаскивают на Терадата, хотя это 
 сопряжено с большими трудностями и затратами. Уж не потому ли, что 
 разработчики Терадата не используют разделяемую память и их СУБД 
 масштабируется линейно?..

 В Терадата нет индексов? Вай-вай, how can I resist you... ;)
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 DamirX написал(a):

 Господа! Ну что вы в самом деле? Это - рассылка. Сюда пишут для
 _самовыражения_, в первую очередь, для обмена опытом - во вторую, ни и
 тд.
 ЗЫЖ в более других рассылках (freebsd, с) вообще, дедовщина и мордобой
 получается, по вашим меркам.

Да я уже понял, что зря трачу время :) Но вроде хотелось культурно, 
по-вежливому поговорить

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 05:33:05 Anton Anikin wrote:
В сообщении от 5 мая 2009 Alexey Pechnikov написал(a):

Вы преувеличиваете. Аргументы от Anton Anikin вида плохо, хорошо и
глупо весьма способствуют улыбке. Что касается домашнего задания, то
это словосочетание используют многие преподаватели и учителя, в том числе в
неформальной обстановке - выходит, вы их всех готовы в хамы записать? А
если я вас неправильно понял, то и вы могли неправильно понять. Давайте
будем следить за собой, а не другими.

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

Вы перешли к прямым оскорблениям (сноб) и клевете (обилию у вас ...
аргументов вида...).
Укажите в нашей дискуссии мое сообщение со словами надо всем яйца оторвать
или
признайте, что вы троллите.

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

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 05:44:28 Anton Anikin wrote:
1. Лукавите, однако. То у вас большой объем данных, то вдруг он заведомо
помещается в ОЗУ.

Эти данные можно загружать кусками - это новость для вас ?

Ты пишешь про работу с shared memory и матричные операции. Про загружать
кусками
слова не было. Более того, не так просто разделить матрицу так, чтобы по
результатам
матричной операции с полученными частями можно было собрать итоговую матрицу.
А если это сделать и оперировать разделенной матрицей, то общая память
совершенно
не нужна, т.к. каждый поток вычислений работает со своими данными.

2. Распределенной обработкой у вас и не пахнет. Для распределенной
обработки матрицы разделяют (используя блочное или ленточное по строкам или
столбцам разделение) и полученные части матрицы обрабатывают независимо.
То, что делаете вы, на паре ядер может дать выигрыш, но не масштабируется в
принципе.

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

Тебе объяснили, что твой пример с матрицей не подходит, если других аргументов
нет, имей честность признать это. А насчет ерунды - повежливее надо быть, даже
если сказать нечего. Разделение матриц вовсю использовалось еще на одноядерных
компах,
поскольку дает возможность обсчитывать огромные матрицы при ограниченном ОЗУ и
времени (при сбое потеряется только результат текущей итерации). И при наличии
нескольких ядер/процессоров/компов запускается соответствующее число экземпляров
программы. У нас на кафедре так делали как минимум еще в 90-х.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Alexey Pechnikov написал(a):

Вы перешли к прямым оскорблениям (сноб) и клевете (обилию у вас ...
аргументов вида...). Укажите в нашей дискуссии мое сообщение со словами
надо всем яйца оторвать или признайте, что вы троллите.

Про сноба я погорячился, признаю. Про яйца - тоже, перепутал вас с
Victor Wagner. Прошу прощения за невнимательность (почти ночь у нас была уже).
К троллению мои сообщения никакого отношения не имеют.

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

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

Ну что же вы оскорбились ? Вашу фразу Аргументы от Anton Anikin
вида плохо, хорошо и глупо весьма способствуют улыбке. я как,
по-вашему, должен воспринимать ? Вы выразили свое мнение о моих словах, я - о
ваших.

И предлагаю закрыть тему. Ничего хорошего никто друг другу уже не скажет.

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 10:46:29 Eugene Berdnikov wrote:
Разработчики Оракла тоже верили. Вот только почему-то действительно
большие БД ( 10 Тб) с оракла зачастую перетаскивают на Терадата, хотя это
сопряжено с большими трудностями и затратами. Уж не потому ли, что
разработчики Терадата не используют разделяемую память и их СУБД
масштабируется линейно?..

В Терадата нет индексов? Вай-вай, how can I resist you... ;)

А при чем тут индексы? В эскулайте, к примеру, есть режимы работы с shared cache
и без него, и в обоих режимах доступны все возможности СУБД (ну, если быть
точным, в режиме с общим кэшем виртуальные таблицы, которые предоставляют
интерфейс к внешним источникам данных, не работают). PostgreSQL использует
shared memory и, пока обрабатываемые запросом данные в ней помещаются,
работает, но обсчет выборки, намного превосходящей объем ОЗУ (обычно
значительная часть ОЗУ отдается под общую память для постгреса) становится
проблемой. А вот СУБД без общей памяти, как правило, умеют работать с данными
на диске, а не пихают все данные в ОЗУ.

Что касается Терадаты, то это представитель класса параллельных СУБД:

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

(См.
Распределенные и параллельные системы баз данных
М. Тамер Оззу, Патрик Валдуриз
Источник: журнал Системы Управления Базами Данных # 4/1996, издательский дом
«Открытые системы»
Новая редакция: Сергей Кузнецов, 2009 г.
Оригинал: M. Tamer Ozsu, Patrick Valduriez. Distributed and parallel database
systems.)

Вероятно, на узлах shared memory может использоваться и в Teradata, однако узлы
между собой не имеют общих ресурсов.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Alexey Pechnikov написал(a):

Ты пишешь про работу с shared memory и матричные операции. Про загружать
кусками слова не было. Более того, не так просто разделить матрицу так,
чтобы по результатам матричной операции с полученными частями можно было
собрать итоговую матрицу. А если это сделать и оперировать разделенной
матрицей, то общая память совершенно не нужна, т.к. каждый поток вычислений
работает со своими данными.

Это был всего лишь пример. Вот есть у нас алгоритм, он что-то обрабатывает (ту
же матрицу, будь она неладна). Алгоритм этот работает в один поток и не
критичен по скорочти в том смысле, что будет быстрее - хорошо, нет - ну и фиг
с ним. Чем плох вариант с использованием openMP (пара-тройка срок в коде) и
задействованием всех ядер в системе (благо их больше чем одно сейчас, как
правило) ? Про большие объемы сейчас речь не идет, просто хочется, чтоб
побыстрее, если можно (желательно с минимальными изменениями в коде).

Тебе объяснили, что твой пример с матрицей не подходит, если других
аргументов нет, имей честность признать это. А насчет ерунды - повежливее
надо быть, даже если сказать нечего. Разделение матриц вовсю использовалось
еще на одноядерных компах, поскольку дает возможность обсчитывать огромные
матрицы при ограниченном ОЗУ и времени (при сбое потеряется только
результат текущей итерации). И при наличии нескольких
ядер/процессоров/компов запускается соответствующее число экземпляров
программы. У нас на кафедре так делали как минимум еще в 90-х.

Ладно, если вы считаете, что этот пример плох - оставим его. Я прекрасно
осознаю, что практически всё, что считают сейчас - считалось и 30 лет назад.
Тем не менее, я не считаю существование нитей и openMP - бесполезным. И
городить огород с процессами, передачей параметров этим процессам, запуском
их в нужном количестве вручную (т.е. код для этого писать надо, да он еще и
платформозависимый будет, т.к. банальное определение числа процессоров в
системе зависит от ОС и т.д.) там, где можно обойтись 2-3 (10) строками для
включения нитей через openMP - лично мне влом. Если результат будет один и
тот же - то зачем ? Еще раз повторю - все это ИМХО и применимо не для всех
задач. Если я и буду делать это через процессы - то только с использованием
MPI(MPICH) - там все это выглядит естественным и не надо заморачиваться
с ручным запуском всего этого хозяйства.

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Alexey Pechnikov написал(a):
Мда, shared memory уже стала чем-то вроде tmpfs, та же файлопомойка, только
в ОЗУ. И вы этим еще и гордитесь... Кстати, если система не нуждается в
масштабировании, ваши ухищрения тем более не понятны.

Где я чем-то горжусь ? Если использование нескольких процессоров на
SMP-системе - это не масштабируемость, то что же это тогда ? Слово
масштабируемость - достаточно скользкое, но тем не менее. К тому же она
бывает разного масштаба (такой вот каламбур получился). На фоне мощных
вычислительных систем (как MPP, так и NUMA) с тысячами или десятками тысяч
процессоров, это конечно, смешно. Но на фоне 1 процессора - вполне себе.

Еще как агитируете, и притом вы не представили ни одной области, где и в
самом деле были бы нужны нити. Самое интересное, что такие области есть,
только вы о них не знаете. Отсюда следует вывод, что нити вам вообще ни
разу не нужны. А вот, к примеру, разработчики ejabberd понимали, что им
нужно, и использовали erlang. Ага, они еще и знали, что такое событийное
программирование.

Покажите, пожалуйста, где я агитирую ? То, что я не согласен с вами в
некоторых вопросах - не означает мое тотальное неприятие вашей точки зрения и
начало агитации за нити.

P.S. Посмотрите архитектуру PostgreSQL, который заточен на использование
многих гигабайт shared memory. Это как раз то, к чему вы призываете. Может,
дойдет...

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

Re: xserver-xorg и hal

On Tue, May 05, 2009 at 02:09:26PM +0400, Alexey Pechnikov wrote:
Hello!

On Tuesday 05 May 2009 10:46:29 Eugene Berdnikov wrote:
Разработчики Оракла тоже верили. Вот только почему-то действительно
большие БД ( 10 Тб) с оракла зачастую перетаскивают на Терадата, хотя
это
сопряжено с большими трудностями и затратами. Уж не потому ли, что
разработчики Терадата не используют разделяемую память и их СУБД
масштабируется линейно?..

В Терадата нет индексов? Вай-вай, how can I resist you... ;)

А при чем тут индексы?

Индексы были в том, во что якобы Разработчики Оракла тоже верили.
Убийственный аргумент. Табличку 10Тб индексировать совсем не нужно?

В эскулайте, к примеру, есть режимы работы с shared cache
и без него, и в обоих режимах доступны все возможности СУБД (ну, если быть
точным, в режиме с общим кэшем виртуальные таблицы, которые предоставляют
интерфейс к внешним источникам данных, не работают). PostgreSQL использует
shared memory и, пока обрабатываемые запросом данные в ней помещаются,
работает, но обсчет выборки, намного превосходящей объем ОЗУ (обычно
значительная часть ОЗУ отдается под общую память для постгреса) становится
проблемой.

Постгресс не умеет использовать столько памяти, сколько ему сказали?
Не верю! :) Оракл точно умеет. Причём весьма гранулярно: сегмент для
базы, сегмент для пользовательских сессий, и т.д. А что не лезет, то
крутится через диск.

А вот СУБД без общей памяти, как правило, умеют работать
с данными на диске, а не пихают все данные в ОЗУ.

Чтобы работать в 1000 раз медленнее оракла и постгресса на том же железе?
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 14:49:51 Eugene Berdnikov wrote:
А при чем тут индексы?

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

Умеет. Только столько памяти нет, чтобы все данные с диска в нее засунуть.
К примеру, на сервере с 1 Гб ОЗУ была у меня проблема с постгресом при обсчете
выборки в 10 Гб (данные за полгода - ровно такая отчетность требуется
заказчику) .
Обработка запроса занимала от 1-го до 2-х часов. Если в это время поступал еще
запрос, Сервер уходил в своп навсегда. Теперь там работает эскулайт, обсчитывая
ту же выборку в 60 раз быстрее (от 1-й до 2-х минут) - он прямо с диска данные
берет, а не засовывает их предварительно в shared memory. Могу еще отметить,
что в эскулайте данные хранятся компактнее, чем в постгресе, что тоже вносит
свой вклад в быстродействие.

А вот СУБД без общей памяти, как правило, умеют работать
с данными на диске, а не пихают все данные в ОЗУ.

Чтобы работать в 1000 раз медленнее оракла и постгресса на том же железе?

Любите гадать на кофейной гуще? :-) Выше я привел вам пример, что происходит
с постгресом на выборках объемом много более доступной shared memory. Если же
говорить о тестах, то на целероне с полгигом памяти 15 миллионов записей в
таблице постгрес обработать не смог, а эскулайт без проблем работал со 100
миллионами (на диске у меня тогда было 100 гиг доступно, а то бы и с большим
числом попробовал). Да, прошло лет 5, железо теперь другое, но качественно
ничего не изменилось. Более того, интел обещает 1000-ядерные процессоры -
эскулайт на них будет масштабироваться _линейно_, в отличие от СУБД с
разделяемыми ресурсами.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On Tue, May 05, 2009 at 03:32:03PM +0400, Alexey Pechnikov wrote:
Постгресс не умеет использовать столько памяти, сколько ему сказали?
Не верю! :) Оракл точно умеет. Причём весьма гранулярно: сегмент для
базы, сегмент для пользовательских сессий, и т.д. А что не лезет, то
крутится через диск.

Умеет. Только столько памяти нет, чтобы все данные с диска в нее засунуть.
К примеру, на сервере с 1 Гб ОЗУ была у меня проблема с постгресом при обсчете
выборки в 10 Гб (данные за полгода - ровно такая отчетность требуется
заказчику) .
Обработка запроса занимала от 1-го до 2-х часов. Если в это время поступал
еще
запрос, Сервер уходил в своп навсегда. Теперь там работает эскулайт,
обсчитывая
ту же выборку в 60 раз быстрее (от 1-й до 2-х минут) - он прямо с диска
данные
берет, а не засовывает их предварительно в shared memory.

Sqlite -- с диска? Вы в этом уверены? :) А я вот сильно сомневаюсь, что
sqlite открывает файл так, чтобы его содержимое не попадало в буферный кэш.
Потому что умею протрассировать его и посмотреть флаги open(). :-)

Так что этот пример показывает, что линуксное ядро из коробки умеет само
подстроить размер буферной памяти, причём лучше, чем доморощенный DBA.

А вот СУБД без общей памяти, как правило, умеют работать
с данными на диске, а не пихают все данные в ОЗУ.

Чтобы работать в 1000 раз медленнее оракла и постгресса на том же железе?

Любите гадать на кофейной гуще? :-) Выше я привел вам пример, что происходит
с постгресом на выборках объемом много более доступной shared memory.

Это пример того, как DBA не справился с настройкой базы, загнав сервер
в своппинг. Нормально настроенная база не должна свопиться, независимо
от того, сколько у неё сессий и сколько данных ей приходится качать
через диск.

ничего не изменилось. Более того, интел обещает 1000-ядерные процессоры -
эскулайт на них будет масштабироваться _линейно_, в отличие от СУБД с
разделяемыми ресурсами.

Блажен кто верует... :)
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 15:52:50 Eugene Berdnikov wrote:
Sqlite -- с диска? Вы в этом уверены? :) А я вот сильно сомневаюсь, что
sqlite открывает файл так, чтобы его содержимое не попадало в буферный кэш.
Потому что умею протрассировать его и посмотреть флаги open(). :-)

А про двойную буферизацию постгреса знаете? Мало того, что кэш ФС попадает,
так еще и своя shared memory, да еще система из нескольких уровней для
синхронизации с persistent storage... Нет, отключить двойную буферизацию СУБД
с shared memory не удастся. Оракл обходит эту проблему, используя raw devices,
т.е.
прямой доступ к неформатированному дисковому носителю, но это вообще не
UNIX-way и, более того, полностью привязывает пользователя к вендору СУБД.

Назовите настройки постгреса, которые позволят 10 Гб данных засунуть в ОЗУ
размером 1 Гб :-) При выполнении запросов с группировкой постгрес _сначала
сортирует данные в памяти_, и на этом для больших dataset все уже заканчивается.
Что значит нормальная база не должна свопиться - вы случаем не из тех, кто для
базы в 10 гиг ставит на сервак 64 Гиг ОЗУ? Хотя может быть, вы просто
идеалист...

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On Tue, May 05, 2009 at 04:12:23PM +0400, Alexey Pechnikov wrote:
On Tuesday 05 May 2009 15:52:50 Eugene Berdnikov wrote:
Так что этот пример показывает, что линуксное ядро из коробки умеет само
подстроить размер буферной памяти, причём лучше, чем доморощенный DBA.

Оракл объявил методику raw devices как deprecated год или два назад.
Наверное, ему надоело проблему обходить и он её переехал как танк. :)

прямой доступ к неформатированному дисковому носителю, но это вообще не
UNIX-way и, более того, полностью привязывает пользователя к вендору СУБД.

Правильные флаги open(2) это не юникс-вэй? Хм. Не знал.

Назовите настройки постгреса, которые позволят 10 Гб данных засунуть в ОЗУ
размером 1 Гб :-)

Видите ли, я в техподдержке постгресса не работаю... :) Не знаю.

Что значит нормальная база не должна свопиться - вы случаем не из тех,
кто для базы в 10 гиг ставит на сервак 64 Гиг ОЗУ?

Я из тех, кто полагает, что если программа имеет ручку для ограничения
размера памяти, эта ручка обязана у неё работать. Иначе программа
не имеет права называться нормальной, либо у её рулевого надо отобрать
микроскоп и вручить банан. Выберите your way.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 17:12:30 Eugene Berdnikov wrote:
Оракл объявил методику raw devices как deprecated год или два назад.
Наверное, ему надоело проблему обходить и он её переехал как танк. :)

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

Правильные флаги open(2) это не юникс-вэй? Хм. Не знал.

Программа должна работать _с любой ФС_, какую только пожелает пользователь.
От ФС требуется лишь POSIX-совместимость.

В теории между теорией и практикой нет разницы... Но правда в ваших словах
есть. Потому я и использую теперь SQLite.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On Tue, May 05, 2009 at 05:33:38PM +0400, Alexey Pechnikov wrote:
On Tuesday 05 May 2009 17:12:30 Eugene Berdnikov wrote:
прямой доступ к неформатированному дисковому носителю, но это вообще не
UNIX-way и, более того, полностью привязывает пользователя к вендору СУБД.

Правильные флаги open(2) это не юникс-вэй? Хм. Не знал.

Вы ещё не посмотрели man 2 open? Сюрприз: флаги O_SYNC, O_DSYNC и O_RSYNC
специфицированы в POSIX. Подозреваю, ораклоиды в курсе.

Поздравляю, это правильный выбор! :)
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Hello!

On Tuesday 05 May 2009 18:20:48 Eugene Berdnikov wrote:
 On Tue, May 05, 2009 at 05:33:38PM +0400, Alexey Pechnikov wrote:
  On Tuesday 05 May 2009 17:12:30 Eugene Berdnikov wrote:
прямой доступ к неформатированному дисковому носителю, но это вообще не
UNIX-way и, более того, полностью привязывает пользователя к вендору 
СУБД.
   
Правильные флаги open(2) это не юникс-вэй? Хм. Не знал.
  
  Программа должна работать _с любой ФС_, какую только пожелает пользователь.
  От ФС требуется лишь POSIX-совместимость.
 
  Вы ещё не посмотрели man 2 open? Сюрприз: флаги O_SYNC, O_DSYNC и O_RSYNC
  специфицированы в POSIX. Подозреваю, ораклоиды в курсе.

Ясно же написал - _с любой ФС_. Оракл в режиме доступа raw device работает 
_с блочным устройством_ напрямую.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On Tue, May 05, 2009 at 06:30:59PM +0400, Alexey Pechnikov wrote:
On Tuesday 05 May 2009 18:20:48 Eugene Berdnikov wrote:
On Tue, May 05, 2009 at 05:33:38PM +0400, Alexey Pechnikov wrote:
On Tuesday 05 May 2009 17:12:30 Eugene Berdnikov wrote:
прямой доступ к неформатированному дисковому носителю, но это вообще
не
UNIX-way и, более того, полностью привязывает пользователя к вендору
СУБД.

Правильные флаги open(2) это не юникс-вэй? Хм. Не знал.

Программа должна работать _с любой ФС_, какую только пожелает
пользователь.
От ФС требуется лишь POSIX-совместимость.

Вы ещё не посмотрели man 2 open? Сюрприз: флаги O_SYNC, O_DSYNC и O_RSYNC
специфицированы в POSIX. Подозреваю, ораклоиды в курсе.

Ясно же написал - _с любой ФС_. Оракл в режиме доступа raw device работает
_с блочным устройством_ напрямую.

Вам нужно отдохнуть.

На raw device никакой fs нет, потому и raw.
А вот open() обращается к чему-то, что лежит на fs.
И именно open() есть абстракция, скрывающая от юзера детали fs.
Позволяющая флагами O_*SYNC отменить кэширование.
--
Eugene Berdnikov

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

2009-05-04 Пенетрантность Alex Grigorovich

Hello!

On Tuesday 05 May 2009 18:51:46 Eugene Berdnikov wrote:
  Ясно же написал - _с любой ФС_. Оракл в режиме доступа raw device работает 
  _с блочным устройством_ напрямую.
 
  Вам нужно отдохнуть.
 
  На raw device никакой fs нет, потому и raw.
  А вот open() обращается к чему-то, что лежит на fs.
  И именно open() есть абстракция, скрывающая от юзера детали fs.

Вы, собственно, о чем?.. Вы считаете, что БД на raw device есть UNIX-way? Не 
вижу
аргументов. На ФС свои проблемы есть, в частности, с производительностью, но
это другой вопрос.

  Позволяющая флагами O_*SYNC отменить кэширование.

Опять же - какой отношение это имеет к оракловским raw device? 

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On Sat, May 02, 2009 at 03:42:05PM +0400, Иван Лох wrote:
 P.S. Я правильно понимаю, что Chrome это демонстративный отказ от нитей?

Нет, неправильно. Нитей там есть, см. 
http://dev.chromium.org/developers/design-documents/threading

-- 
Alex Grigorovich


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

On 2009.05.03 at 13:31:02 +0700, mitrohin a.s. wrote:

On Thu, Apr 30, 2009 at 11:40:13PM +0900, Anton Anikin wrote:
В сообщении от 29 апреля 2009 Victor Wagner написал(a):
Общественность думает, не пора ли сносить Debian и заменять его на
OpenSolaris.

Вперед :) Вы только не забудьте потом нам подробно описать процесс
установки и
настройки на более-менее современном железе :) Отмазки типа Wi-Fi,
Bluetooth,
аппаратное ускорение OpenGL и т.д. не завелись, но оно мне и нафиг не надо,
т.к. я РАБОТАЮ ...

Ну для работы gcc и vi/emacs вещи типа opengl, bluetooth не сильно то важные.

Кому как. Bluetooth это как раз крайне важная вещь для работы - это
интерфейс с сетью там, где больше ничего нету, это интерфейс с
GPRS-приемником, интерфейс с диагностическим разъемом автомобиля и много
чего еще.

Собственно то, что в Linux сейчас bluetooth без D-Bus не работает, это
как раз одна из основных претензий к новомодным веяниям. X-сервер у меня
пока старый, без hal обходится. А вот bluetooth уже в etch без D-Bus
никак.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

On 2009.04.30 at 23:27:59 +0900, Anton Anikin wrote:

В сообщении от 30 апреля 2009 Victor Wagner написал(a):

За использование нитей надо судить. Большим жюри. Иногда оправдывать.
Потому что ситуации, когда они нужны - бывают. И даже бывают
разработчики, которые в этих ситуациях ухитряются с ними грамотно
справляться. В остальных случаях - либо расстреливать, либо на
принудительные работы по писанию примитивов синхронизации на ассемблере.

Вы хоть раз сами эти вещи (с использованием нитей) писали ? Или может
предложите что другое, при этом переносимое ? Про fork не надо песни петь,

Опишите задачу для которой нужно предложить архитектуру.

Мое категоричное утверждение было о том, что БЫВАЮТ задачи для которых
нити действительно полезны и БЫВАЮТ программисты, которые способны с
ними в этой ситуации справиться. Но в 90% задач существуют более
надежные решения. И более простые, которые можно уложить в голове у
нормального программиста, а не супергения.

На мой взгляд, сейчас есть ряд весьма популярных технологий (нити -
не единственная, есть еще OOP), написание надежных программ на которых
требует очень высокой квалификации, очень грамотного дизайна, но при
этом эти технологии создают ОБМАНЧИВОЕ впечатление простоты.

Поэтому в качестве rule of thumb использования этих технологий следует
избегать елико возможно. И использовать только тогда, когда были
перепробованы все остальные варианты, и стало очевидно, что они не
годятся. (кстати, сам факт перепробования остальных вариантов очень
способствует правильному дизайну).

его много где нет. Тот же openMP (который как раз через нити работает),

OpenMP - узконишевой продукт. Причем в такой нише, где надежность, как
правило, не является категорическим императивом. Потому что типичная
счетная задача девять раз из десяти завершается неудачей вовсе не потому
что наступили на грабли с нитями, а потому что не углядели какой-то
особенности в модели. Поэтому если она будет завершаться неудачно не 9
раз из 10, а 19 из 20, но эти 20 прогонов будут завершены быстрее, чем
те 10 - на это можно пойти.

А вот задачи с которыми пользователь имеет дело каждый день - браузер,
X-сервер, текстовый редактор etc просто НЕ ИМЕЮТ права падать. Даже в
случае заведомо неправильных действий пользователя.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

On 2009.05.04 at 18:59:24 +0900, Anton Anikin wrote:

Ситуации бываю разные. И методы их решения тоже. Предложите варианты
(переносимые) для эффективной масштабируемости на SMP-системах. Я уже писал
об этом выше.

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

Отказ от ООП как такового вовсе не гарантирует вам хорошего качества продукта
на выходе. Зачастую такого понапишут, что черт ногу сломит. Для ООП это тоже
актуально, поэтому, как мне кажется, всё зависит от квалификации
разработчика. Если она недостаточна, то ни ООП, ни процедурный стиль, ни
функциональный не дадут вам удовлетворительный результат.

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

следует избегать елико возможно - это вы сами придумали ? Или есть
рекомендации в серьезных источниках ?

Какие источники вы считаете серьезными?

Маркетинговый бред банды четырех?

Т.е. из этой фразы можно сделать вывод, что нити - потенциально ведут к
падениям ПО, написанного с их использованием ? Странно как-то это звучит.

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

Т.е. если мы все напишем через FSM или fork, то программа сразу будет
являться образцом стабильности и надежности? Ну-ну.

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

Кстати не FSM или fork, а, как правило, FSM и fork. Только в очень
редких случаях при реализации многопроцессной модели удается обойтись
без процесса-менеджера, который распределяет доступ к общим ресурсам.
Этот процесс должен обрабатывать поток запросов от нескольких других
процессов, поэтому должен иметь FSM.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

2009-05-04 Пенетрантность Иван Лох

On Mon, May 04, 2009 at 06:59:24PM +0900, Anton Anikin wrote:

 Т.е. если мы все напишем через FSM или fork, то программа сразу будет 
 являться образцом стабильности  и надежности? Ну-ну.

Сразу не будет. А после отладки, вполне возможно. Вот упала программа.
Чужая. Опенсорс. С нитями. Вы будете ее ковырять? А без нитей?

Параллельные вычисления, вообще, трудно отлаживать. Но с процессами
еще туда-сюда, научились как-то, а с нитями пока IMHO вообще труба.
Дернул за ухо -- *** отвалился...


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Victor Wagner написал(a):

следует избегать елико возможно - это вы сами придумали ? Или есть
рекомендации в серьезных источниках ?

openMP пригоден не только для счетных задач (моделирование, о котором вы
упомянули), тем более для них есть более подходящие средства. У учетом того,
что он есть во всех современных компиляторах, сфера его применения может быть
весьма широкой. Естественно, при АДЕКВАТНОМ применении. При неадекватном
любая технология может выдать монстра.

Т.е. из этой фразы можно сделать вывод, что нити - потенциально ведут к
падениям ПО, написанного с их использованием ? Странно как-то это звучит.
Т.е. если мы все напишем через FSM или fork, то программа сразу будет
являться образцом стабильности и надежности? Ну-ну.

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 14:54:20 Victor Wagner wrote:
 Нити подразумевают что несколько потоков выполнения одновременно
 обращаются к общей памяти. Причем, как правило, в этой памяти еще и
 указатели бывают. Отсюда один шаг до сегфолта в случае ошибки
 синхронизации.

Я бы добавил, что самые масштабируемые системы как-раз таки используют 
архитектуру
shared nothing. И масштабируются почти линейно. Но, конечно, нити и т.п. это ж 
куда как 
круче звучит, чем fork(), так что вряд ли вам удастся в чем-то убедить 
оппонента.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On 2009.05.04 at 15:08:17 +0400, Alexey Pechnikov wrote:

Hello!

On Monday 04 May 2009 13:59:24 Anton Anikin wrote:
Ситуации бываю разные. И методы их решения тоже. Предложите варианты
(переносимые) для эффективной масштабируемости на SMP-системах. Я уже писал
об этом выше.

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

На самом деле надо еще задаться вопросом а что такое масштабируемость,
и так ли она нам в данном случае нужна. А то масштабируемость это
теперь тоже маркетинговое заклинание такое, так же как нити и ООП.

Ну вот например, какой прок в масштабируемости движка корпоративного
веб-сайта?
Cтоит он себе на коллокейшн и стоит, и не выбьешь ты из финдиректора
денег на дополнительные процессоры или, упаси боже, кластер.
Потому что нормальная посещаемость этого сайта - десять человек в час.

А потом вдруг ссылка на этот сайт попадает на первую страницу, ну
скажем, газеты.вру и сразу в течение минуты прибегает миллион леммингов.

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 13:59:24 Anton Anikin wrote:
 Ситуации бываю разные. И методы их решения тоже. Предложите варианты 
 (переносимые) для эффективной масштабируемости на SMP-системах. Я уже писал 
 об этом выше.
 

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 15:25:14 Victor Wagner wrote:
 На самом деле надо еще задаться вопросом а что такое масштабируемость,
 и так ли она нам в данном случае нужна. А то масштабируемость это
 теперь тоже маркетинговое заклинание такое, так же как нити и ООП.

Тему уж очень удобная для спекуляций - поскольку мало кто сталкивается 
с необходимостью в масштабировании, можно убеждать, что оно всем нужно.
Хотя если подумать, то один средний сервак легко обрабатывает 200 гиг 
динамического трафика в месяц (примерно миллион запросов в сутки). 
Значит, мощности всего лишь одного современного компа хватит на довольно 
крупный по масштабам рунета проект. 
Из смешного - недавно у меня реверс-прокси Pound под нагрузкой захлебнулся, 
притом, что база бэкенда - PostgreSQL, который я и полагал основным якорем :-)
Наверное, лучше не упоминать, что там и SQLite используется ;-) Ведь для многих
Оракл даже при нагрузке в сотню раз меньше выглядит куда как солиднее.

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

Да в общем-то достаточно на кэширующем прокси политику кэширования настроить.
И на реверс-прокси добавить хидер для кэширования на всех последующих прокси. 
Сам сайт можно вовсе не трогать.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

On 2009.05.04 at 16:08:22 +0400, Alexey Pechnikov wrote:

 Hello!
 
 On Monday 04 May 2009 15:25:14 Victor Wagner wrote:
  На самом деле надо еще задаться вопросом а что такое масштабируемость,
  и так ли она нам в данном случае нужна. А то масштабируемость это
  теперь тоже маркетинговое заклинание такое, так же как нити и ООП.
 
 Тему уж очень удобная для спекуляций - поскольку мало кто сталкивается 
 с необходимостью в масштабировании, можно убеждать, что оно всем нужно.

Интересно устроена массовая психология. Никто не сталкивался с
необходимостью, соответственно должен автоматически возникать вопрос
а на фига?. Так нет же...



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Victor Wagner написал(a):
On 2009.05.04 at 22:45:37 +0900, Anton Anikin wrote:
В сообщении от 4 мая 2009 Victor Wagner написал(a):
Собственно то, что в Linux сейчас bluetooth без D-Bus не работает, это
как раз одна из основных претензий к новомодным веяниям. X-сервер у
меня пока старый, без hal обходится. А вот bluetooth уже в etch без
D-Bus никак.

Без обид, но лично вам как мешает установленный в системе D-Bus ?

Он должен быть не установленный в системе, а запущенный и работающий.
С этим у меня как-то доходило до того, что система просто меня не
пускала - вводишь логин и пароль, а она подумает-подумает, и выкинит
обратно окошко дисплей-менеджера. Потому что не смогла инициализировать
session bus. (правда, при очередном апгрейде dbus пофиксилось).

А с bluetooth все еще хуже. Раньше можно было в
/etc/bluetooth/hcid.conf написать что данный адаптер должен быть всегда
discoverable. Теперь - нельзя. Надо это дело через dbus api hcid
включать. И со спариванием устройств то же самое - нужно passkey-agent,
который умеет работать через D-Bus API.

А в комплекте bluez ВООБЩЕ НЕТ нормальных командно-строчных утилит.
sdptool например, не умеет выдавать ненулевой код завершения, если не
нашел того, что просили. Про формат выдачи я уж вообще молчу.

Тот passkey-agent.c, который кладется в /usr/share/doc/examples, и
который до недавнего времени практически без изменений использовался
kbluetooth, написан так, что при его завершении libdbus ругается
на недопустимую операцию.

Пришлось переписывать нафиг. Ну и утилиту которая переключает режимы
видимости адаптера пришлось самому писать.

Понятно :) Просто bluetooth использую только через kde, вроде работает, вот и
не парился ни с hal, ни с dbus.

Re: xserver-xorg и hal

On 2009.05.04 at 23:08:02 +0900, Anton Anikin wrote:

В сообщении от 4 мая 2009 Alexey Pechnikov написал(a):

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

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

ЛИчно я бы оторвал яйца тому, кто стал бы это делать на shared memory.
Потоки и только потоки. Причем так, чтобы обработчик (или много
одинаковых обработчиков) можно было запустить отдельно из командной
строки. И только после того, как он таким образом отлажен, пытаться
вызывать его из графической оболочки.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org  @ Mon, 4 May 2009 23:10:00 
+0900:

  Я бы добавил, что самые масштабируемые системы как-раз таки
  используют архитектуру shared nothing. И масштабируются почти
  линейно. Но, конечно, нити и т.п. это ж куда как круче звучит, чем
  fork(), так что вряд ли вам удастся в чем-то убедить оппонента.

 AA Если вы внимательно читали ветку, то должны были заметить,

Золотые слова...  Витус нигде не выдавал _категорических_ высказываний.
В отличие от эмоциональных, да.  Если вы внимательно читали ветку, то
должны были заметить это.

-- 
Презерватив - это защита от копирования дурака.
 -- (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Artem Chuprina написал(a):
 Бывают.  Но это очень специфический класс задач.  И нет, нижеприведенные
 примеры к таковым не относятся.

Хорошо, озвучьте тогда этот класс, если вас не затруднит. И чем приведенный 
пример плох ? Насколько мне известно, многие архиваторы поддерживающих smp - 
сделаны на потоках, и вполне себе работают.

 Разработчики Photoshop - довольно известный пример неадекватности.  Ну,
 то есть алгоритмисты у них хорошие, а вот с программистами не
 сложилось.  Странно, что Вы этого не знаете...

Я не говорю, что они гении, но и не считать их неадекватными. Что же именно 
там у них не так ?

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Artem Chuprina написал(a):

 Хорошая отмазка.  Так можно все свалить на категоричность, Вам не
 кажется?

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

P.S. Человек тем и отличается от животных, что имеет возможность 
контролировать свои эмоции (пусть и не всегда) и оценивать их впоследствии. И 
если под воздействием этих эмоций сказал что-то не совсем корректное - 
признать это.

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 18:08:02 Anton Anikin wrote:
Не спорю. Но бывают не настолько требовательные по масштабируемости процессы,
но нужна быстрая разделяемая память. И иметь геморрой (пусть и маленький) с
этим пулом не всегда хочется.

Мда, shared memory уже стала чем-то вроде tmpfs, та же файлопомойка, только в
ОЗУ.
И вы этим еще и гордитесь... Кстати, если система не нуждается в
масштабировании,
ваши ухищрения тем более не понятны.

Еще раз повторю, что никого не агитирую использовать нити. Просто для них
есть
свои сферы, а вы малость лукавите, пытаясь представить ситуацию так, что сфер
таких нет. Вы призываете не использовать нити в неподходящих для них
ситуациях. Я - использовать в подходящих.

Еще как агитируете, и притом вы не представили ни одной области, где и в самом
деле
были бы нужны нити. Самое интересное, что такие области есть, только вы о них
не знаете.
Отсюда следует вывод, что нити вам вообще ни разу не нужны. А вот, к примеру,
разработчики ejabberd понимали, что им нужно, и использовали erlang. Ага, они
еще и
знали, что такое событийное программирование.

P.S. Посмотрите архитектуру PostgreSQL, который заточен на использование
многих гигабайт
shared memory. Это как раз то, к чему вы призываете. Может, дойдет...

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Artem Chuprina написал(a):

 Золотые слова...  Витус нигде не выдавал _категорических_ высказываний.
 В отличие от эмоциональных, да.  Если вы внимательно читали ветку, то
 должны были заметить это.

Хорошая отмазка. Так все можно свалить на эмоции, Вам не кажется ?

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Anton Anikin написал(a):

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

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Artem Chuprina написал(a):
Anton Anikin - debian-russian@lists.debian.org @ Mon, 4 May 2009 23:46:35
+0900:
Бывают. Но это очень специфический класс задач. И нет,
нижеприведенные примеры к таковым не относятся.

AA Хорошо, озвучьте тогда этот класс, если вас не затруднит.

Я верю в осмысленность разделяемой памяти для баз данных. Для беготни
по индексам в условиях, когда mmap() работает на запись неоптимально. А
так как-то сходу больше и не приведу примеров...

Разработкой БД не занимался, но вот для быстрой распределенной (в рамках SMP)
обработки большого объема данных (когда обработка одной части не влияет на
другую - как тупейший пример - возведение элементов матрицы в квадрат) -
вполне применима. Или вместо последовательного запуска независимого фрагмента
кода N раз (итерации в какой-нибудь счетном алгоритме как пример) в несколько
потоков - тоже нормально. Лично я 2-мя строками с помощью openMP добавил в
один из своих расчетных алгоритмов возможность использования всех доступных
ядер без побочных эффектов и сегфолтов - это разве плохо? И я уверен, что мой
код корректно отработает везде, где есть нитки и компилятор тянет openMP.

Я могу это объяснить, например, тем, что основная целевая платформа либо
платформа разработки их - Windows. Где _традиционно_ для
распараллеливания используются нити. И... надо сказать, осмысленность
таких архиваторов, похоже, весьма ограничена как таковая. Ну, то есть в
отсутствие маркетингового буллшита они как-то не используются...

Не знаю как насчет рекламного *шита, но лично меня устраивает, что архиватор
(7z - он вообще к коммерции не имеет отношения, если что) оптимально
использует мое железо. Если вам это не нужно - не говорите за всех.

Я не знаю, насколько их подход был адекватен для MacOS, но та MacOS уже
не существует, а фотошоп все еще развлекается с собственным свопом (по
слухам - так, что ставит раком всю систему) и пишет в Program Files.
Больше 10 лет существует Photoshop под Windows, а его программисты так и
не осознали этого факта. Теперь он уже и под родную макось
неадекватен...

Про это ничего не скажу, поскольку мало с ним работал (и то давно). Но тут
скорее всего просто сказывается слишком большой объем унаследованного кода.
Думаю, что рано или поздно разгребут. Примером подобной
унаследованной помойки может служить и открытые Mozilla Firefox +
OpenOffice.org - нынешние разработчики, похоже сами не всегда знают, что
имеют в том коде, которым занимаются.

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 19:02:01 Artem Chuprina wrote:
 Я верю в осмысленность разделяемой памяти для баз данных.  Для беготни
 по индексам в условиях, когда mmap() работает на запись неоптимально.  А
 так как-то сходу больше и не приведу примеров...

Разработчики Оракла тоже верили. Вот только почему-то действительно
большие БД ( 10 Тб) с оракла зачастую перетаскивают на Терадата, хотя это 
сопряжено с большими трудностями и затратами. Уж не потому ли, что 
разработчики Терадата не используют разделяемую память и их СУБД 
масштабируется линейно?..

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Artem Chuprina написал(a):
 Ряд подписчиков этой рассылки, насколько мне известно, полагают, что
 _такая_ популярность Free Software вообще и линуксу в частности вредна.
 Поэтому тот факт, что она еще и не бесплатна, является отягчающим
 обстоятельством.

Я не говорю, что это хорошо. Но и однозначно плохим не считаю. А держаться до 
упора за то, что было 20-30 лет - иногда глупо. 

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

И не надо снисходительности, Вы мне, вроде, не старший брат. Домашние задания 
оставляйте, пожалуйста, своим детям (ученикам).

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org  @ Tue, 5 May 2009 00:11:07 
+0900:

  Хорошая отмазка.  Так можно все свалить на категоричность, Вам не
  кажется?

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

 AA P.S. Человек тем и отличается от животных, что имеет возможность
 AA контролировать свои эмоции (пусть и не всегда) и оценивать их
 AA впоследствии. И если под воздействием этих эмоций сказал что-то не
 AA совсем корректное - признать это.

Это совершенно другой вопрос.  Но если Вы не отличаете эмоционального
высказывания от категоричного, то разговора тоже не получится.  Потому
что собеседники под разными словами будут понимать разное.  Что и
наблюдается.

-- 
Я не люблю делать что бы то ни было для целевой аудитории Microsoft
(С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

On 2009.05.04 at 23:46:35 +0900, Anton Anikin wrote:

Разработчики Photoshop - довольно известный пример неадекватности. Ну,
то есть алгоритмисты у них хорошие, а вот с программистами не
сложилось. Странно, что Вы этого не знаете...

Я не говорю, что они гении, но и не считать их неадекватными. Что же именно
там у них не так ?

Помнится, когда я в конце прошлого века осваивал сканирование
фотографий, я это делал с помощью GIMP. Не помню, 1.0 он тогда
назывался, или 0.9, но не суть важно.

Машина была слабенькая (помню специально ради убыстрения работы со
сканированными изображениями память с 32 до 64Мб расширял). Сканер тоже
не шибко шустрый - на узком SCSI висел.

Так вот, штатный режим работы у меня был такой - пока по одной-двум
картинкам despeckle гоняется, следующая сканируется.

То есть в GIMP никаких проблем с запуском нескольких процессов-фильтров
не было. Та самая модель на fork-ах, которую здесь так ругали.

Потом мне как-то понадобилось БОЛЬШУЮ картинку отсканировать и я пошел к
знакомым на сканер A2. К которому была подключена виндовая машина с
фотошопом. И там обнаружил, что оказывается в этом самом фотошопе пока
картинка сканируется, НЕВОЗМОЖНО работать с уже отсканированными. Окошко
Acquire Image - МОДАЛЬНОЕ. Возможно, правда, это не неадекватность
программистов Adobe, а общая неадекватность интерфейсов винды.

А может - наследие MacOS Classic, где с многозадчностью воообще плохо
было.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org  @ Mon, 4 May 2009 23:05:46 
+0900:

 AA Понятно :) Просто bluetooth использую только через kde, вроде
 AA работает, вот и не парился ни с hal, ни с dbus.

Вот так винда устроена.  Вроде работает, простые вещи делаются просто, а
сложные - никак не делаются.  Причем понятия простое/сложное - ни разу
не юзерские...

-- 
Functional programming is like describing your problem to a
mathematician.  Imperative programming is like giving instructions to
an idiot.
 -- arcus, #scheme on Freenode


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org @ Mon, 4 May 2009 23:36:31
+0900:

Вот так винда устроена. Вроде работает, простые вещи делаются
просто, а сложные - никак не делаются. Причем понятия
простое/сложное - ни разу не юзерские...

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

Ряд подписчиков этой рассылки, насколько мне известно, полагают, что
_такая_ популярность Free Software вообще и линуксу в частности вредна.
Поэтому тот факт, что она еще и не бесплатна, является отягчающим
обстоятельством.

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

--
Чем отличается свобода от независимости?
Независимость - это когда за тебя не платят.
А свобода - когда за тебя не думают.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 19:28:17 Anton Anikin wrote:
Разработкой БД не занимался, но вот для быстрой распределенной (в рамках SMP)
обработки большого объема данных (когда обработка одной части не влияет на
другую - как тупейший пример - возведение элементов матрицы в квадрат) -
вполне применима. Или вместо последовательного запуска независимого фрагмента
кода N раз (итерации в какой-нибудь счетном алгоритме как пример) в несколько
потоков - тоже нормально. Лично я 2-мя строками с помощью openMP добавил в
один из своих расчетных алгоритмов возможность использования всех доступных
ядер без побочных эффектов и сегфолтов - это разве плохо? И я уверен, что мой
код корректно отработает везде, где есть нитки и компилятор тянет openMP.

Жжете, иначе не скажешь.

1. Лукавите, однако. То у вас большой объем данных, то вдруг он заведомо
помещается
в ОЗУ.

2. Распределенной обработкой у вас и не пахнет. Для распределенной обработки
матрицы разделяют (используя блочное или ленточное по строкам или столбцам
разделение) и полученные части матрицы обрабатывают независимо. То, что делаете
вы,
на паре ядер может дать выигрыш, но не масштабируется в принципе.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org @ Mon, 4 May 2009 23:46:35
+0900:

Бывают. Но это очень специфический класс задач. И нет,
нижеприведенные примеры к таковым не относятся.

AA Хорошо, озвучьте тогда этот класс, если вас не затруднит.

AA И чем приведенный пример плох ? Насколько мне известно, многие
AA архиваторы поддерживающих smp - сделаны на потоках, и вполне себе
AA работают.

AA Я не говорю, что они гении, но и не считать их неадекватными. Что
AA же именно там у них не так ?

--
Современной называется технология, которую пытаются совать во все дырки
независимо от того, заточена она под них или нет.
Д. Белявский

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org @ Tue, 5 May 2009 00:28:17
+0900:

Бывают. Но это очень специфический класс задач. И нет,
нижеприведенные примеры к таковым не относятся.

AA Хорошо, озвучьте тогда этот класс, если вас не затруднит.

Я верю в осмысленность разделяемой памяти для баз данных. Для
беготни по индексам в условиях, когда mmap() работает на запись
неоптимально. А так как-то сходу больше и не приведу примеров...

AA Разработкой БД не занимался, но вот для быстрой распределенной (в
AA рамках SMP) обработки большого объема данных (когда обработка одной
AA части не влияет на другую - как тупейший пример - возведение
AA элементов матрицы в квадрат) - вполне применима.

... если эта матрица вообще в память лезет целиком (ибо если нет - то на
кой там shared memory? а нитки, кстати, при этом можно использовать, они
на этой задаче при правильном подходе от процессов практически не
отличаются). Но если матрица такая маленькая, что в память лезет
целиком, то от масштабирования на этой задаче проку немного...

AA Или вместо последовательного запуска независимого фрагмента кода N
AA раз (итерации в какой-нибудь счетном алгоритме как пример) в
AA несколько потоков - тоже нормально. Лично я 2-мя строками с помощью
AA openMP добавил в один из своих расчетных алгоритмов возможность
AA использования всех доступных ядер без побочных эффектов и сегфолтов
AA - это разве плохо? И я уверен, что мой код корректно отработает
AA везде, где есть нитки и компилятор тянет openMP.

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

--
Think of C++ as an object-oriented assembly language.
-- Bruce Hoult (br...@hoult.actrix.gen.nz)

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org  @ Tue, 5 May 2009 00:32:18 
+0900:

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

 AA И не надо снисходительности, Вы мне, вроде, не старший
 AA брат. Домашние задания оставляйте, пожалуйста, своим детям
 AA (ученикам).

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

-- 
В какой тебя среде сформировало?..
 -- http://www.psy.msu.ru/people/leontiev_da.html


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Victor Wagner написал(a):

 Собственно то, что в Linux сейчас bluetooth без D-Bus не работает, это
 как раз одна из основных претензий к новомодным веяниям. X-сервер у меня
 пока старый, без hal обходится. А вот bluetooth уже в etch без D-Bus
 никак.


Без обид, но лично вам как мешает установленный в системе D-Bus ?

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Victor Wagner написал(a):

 ЛИчно я бы оторвал яйца тому, кто стал бы это делать на shared memory.
 Потоки и только потоки. Причем так, чтобы обработчик (или много
 одинаковых обработчиков) можно было запустить отдельно из командной
 строки. И только после того, как он таким образом отлажен, пытаться
 вызывать его из графической оболочки.

Ну идите и оторвите яйца разработчикам openMP :). Я же написал при правильной 
реализации алгоритма - т.е. если алгоритм можно заточить под openMP (#pragma 
omp for как пример), то проблем не будет. Естественно, что такая ситуация 
возможна далеко не всегда.

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Alexey Pechnikov написал(a):

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

Еще раз приведу пример - сжатие (архивация) данных, обработка видео (аудио).
Лично вы бы стали городить огород с процессами, пулом, выделением shared
memory и т.д. ? При правильной реализации алгоритма все это легко и просто
делается через нити. Использование того же openMP даже часть проблем с
синхронизацией снимает. Адекватность разработчиков PhotoShop, многопоточных
видеокодеков и т.д. вы тоже будете ставить под сомнение ?

Еще раз повторю, что никого не агитирую использовать нити. Просто для них есть
свои сферы, а вы малость лукавите, пытаясь представить ситуацию так, что сфер
таких нет. Вы призываете не использовать нити в неподходящих для них
ситуациях. Я - использовать в подходящих.

Re: xserver-xorg и hal

В сообщении от 4 мая 2009 Alexey Pechnikov написал(a):

Я бы добавил, что самые масштабируемые системы как-раз таки используют
архитектуру shared nothing. И масштабируются почти линейно. Но, конечно,
нити и т.п. это ж куда как круче звучит, чем fork(), так что вряд ли вам
удастся в чем-то убедить оппонента.

Если вы внимательно читали ветку, то должны были заметить, что я нигде не
выпячиваю ни нити, ни что-либо другое. Я считаю, что каждой вещи - свое место
при правильном ее применении. Просто я против КАТЕГОРИЧЕСКИХ высказываний -
это отдает нездоровым максимализмом, вот и всё.

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

P.S. И еще как пример применения нитей (который вы все так не любите) -
геймдев. Сфера специфическая, но тем не менее. И разработчики при этом вполне
успешно разруливают все эти ужасы с указателями, ведущими к сегфолтам.
Интересно ваше мнение на этот счет - что там нужно использовать вместо
ниток ?

Re: xserver-xorg и hal

Anton Anikin - debian-russian@lists.debian.org @ Mon, 4 May 2009 23:08:02
+0900:

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

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

Бывают. Но это очень специфический класс задач. И нет, нижеприведенные
примеры к таковым не относятся.

AA Еще раз приведу пример - сжатие (архивация) данных, обработка видео
AA (аудио). Лично вы бы стали городить огород с процессами, пулом,
AA выделением shared memory и т.д. ? При правильной реализации
AA алгоритма все это легко и просто делается через нити. Использование
AA того же openMP даже часть проблем с синхронизацией
AA снимает. Адекватность разработчиков PhotoShop, многопоточных
AA видеокодеков и т.д. вы тоже будете ставить под сомнение ?

--
В теории нет различия между теорией и практикой. На практике - есть.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: xserver-xorg и hal

2009-05-04 Пенетрантность Murat D. Kadirov

В сообщении от 4 мая 2009 Artem Chuprina написал(a):

 Вот так винда устроена.  Вроде работает, простые вещи делаются просто, а
 сложные - никак не делаются.  Причем понятия простое/сложное - ни разу
 не юзерские...

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

Re: xserver-xorg и hal

19:52 Mon 04 May, Artem Chuprina wrote:
 Anton Anikin - debian-russian@lists.debian.org  @ Tue, 5 May 2009 00:32:18 
 +0900:
 
   А размышление, почему она вредна, я оставлю Вам в качестве домашнего
   задания...
 
  AA И не надо снисходительности, Вы мне, вроде, не старший
  AA брат. Домашние задания оставляйте, пожалуйста, своим детям
  AA (ученикам).
 
 О, детские обидки пошли...  (Взрослый человек, по идее, в курсе, что
 домашние задания дают не с целью гнобления...)

При чём здесь детские обидки? Вас попросили не опускаться до хамства,
что, кстати, резонно, т.к. вам присуще, при чём на абсолютно ровном
месте. На проятжении всего треда, кстати отметить любопытного, вы одни
умудрились задавать домашнее задание незнакомому вам человеку.

Ничего личного.

-- 
Murat D. Kadirov


pgpfu3RbHVZFs.pgp
Description: PGP signature

Re: xserver-xorg и hal

2009-05-04 Пенетрантность Murat D. Kadirov

21:21 Mon 04 May, Alexey Pechnikov wrote:
 Hello!
 
 On Monday 04 May 2009 20:22:28 Murat D. Kadirov wrote:
  умудрились задавать домашнее задание незнакомому вам человеку.
 
 Хм, а авторов сборников задач для школьников/студентов вы предлагаете 
 сжечь на костре в силу того, что читатели незнакомы авторам?

А вы действительно не видите разницы контекста сборников задач и
профильной рассылки? Хм, очевидно же вроде..

 Проще говоря - читайте правила данной _немодерируемой_ рассылки.

Милейший, _немодерируемая_ не диктует правил диспута между
собеседниками/оппонентами с пренебрежением граничящим с хамством, хотя
разумеется допускает в рамках воспитанности оных или же до тех пор пока
стороны будут подобное терпеть. Не находите?

-- 
Murat D. Kadirov


pgp0N5QXHgusD.pgp
Description: PGP signature

Re: xserver-xorg и hal

2009-05-04 Пенетрантность Eugene V. Lyubimkin

Alexey Pechnikov wrote:
 Hello!
 
 On Monday 04 May 2009 20:22:28 Murat D. Kadirov wrote:
 умудрились задавать домашнее задание незнакомому вам человеку.
 
 Хм, а авторов сборников задач для школьников/студентов вы предлагаете 
 сжечь на костре в силу того, что читатели незнакомы авторам?

Алексей, вы не правы. Давайте закончим эти глупые, уже давно нетехнические
препирательства. Никакие нити с FSM'ами не стоят человеческих отношений.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer



signature.asc
Description: OpenPGP digital signature

Re: xserver-xorg и hal

Hello!

On Monday 04 May 2009 21:57:08 Murat D. Kadirov wrote:
 Милейший, _немодерируемая_ не диктует правил диспута между
 собеседниками/оппонентами с пренебрежением граничящим с хамством, хотя
 разумеется допускает в рамках воспитанности оных или же до тех пор пока
 стороны будут подобное терпеть. Не находите?

Вы преувеличиваете. Аргументы от Anton Anikin вида плохо, хорошо и глупо
весьма способствуют улыбке. Что касается домашнего задания, то это 
словосочетание используют многие преподаватели и учителя, в том числе в 
неформальной обстановке - выходит, вы их всех готовы в хамы записать? 
А если я вас неправильно понял, то и вы могли неправильно понять. Давайте 
будем следить за собой, а не другими.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Alexey Pechnikov написал(a):

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

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Artem Chuprina написал(a):
 Это совершенно другой вопрос.  Но если Вы не отличаете эмоционального
 высказывания от категоричного, то разговора тоже не получится.  Потому
 что собеседники под разными словами будут понимать разное.  Что и
 наблюдается.

Если человек на протяжении всей дискуссии гнет одну и ту же линию, пусть и в 
эмоциональной форме, это говорит лишь о том, что он действительно так 
считает, пусть и облекает свои слова в гротескную форму. А если он постоянно 
общается в таком стиле, то чего удивляться, что его неправильно понимают ?

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Alexey Pechnikov написал(a):

 Жжете, иначе не скажешь.

no comments

 1. Лукавите, однако. То у вас большой объем данных, то вдруг он заведомо
 помещается в ОЗУ.

Эти данные можно загружать кусками - это новость для вас ?

 2. Распределенной обработкой у вас и не пахнет. Для распределенной
 обработки матрицы разделяют (используя блочное или ленточное по строкам или
 столбцам разделение) и полученные части матрицы обрабатывают независимо.
 То, что делаете вы, на паре ядер может дать выигрыш, но не масштабируется в
 принципе.

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

 Best regards, Alexey Pechnikov.
 http://pechnikov.tel/

Re: xserver-xorg и hal

В сообщении от 5 мая 2009 Artem Chuprina написал(a):
 О, детские обидки пошли...  (Взрослый человек, по идее, в курсе, что
 домашние задания дают не с целью гнобления...)

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

P.S. Отрицательное мнение многих людей (включая мое) от Вашего обостренного 
самолюбия и завышенного самомнения, граничащего с хамством, не спасут ни Ваши 
знания, ни Ваш профессиональный опыт.

Re: xserver-xorg и hal