Re: xserver-xorg-video-vesa
Dmitrii Kashin free...@gmail.com writes: Ivan Shmakov oneing...@gmail.com writes: […] mplayer с vesa работает, BTW. Равно как и Iceweasel. VESA хватает для всего, кроме комфортного просмотра видео. Вот у меня сейчас P4 и Radeon 9600. На VESA-драйвере P4 не справляется с автоматическим разворотом видео на весь экран. На днях проверяли Radeon HD 6450 + xserver-xorg-video-radeon — тоже были проблемы, как с видео, так и с glxgears(1) — в «протокол» идет порядка 60 FPS, в действительности — не более порядка 6. Debian Wheezy. Впрочем, видеоадаптер взят главным образом для OpenCL. Для всего остального — работает на 5+. Иногда вместо -zoom удается использовать xrandr(1). В общем же, особого интереса к видео высокого разрешения у меня действительно нет. -- FSF associate member #7257 http://sf-day.org/ -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86ehocw70b@gray.siamics.net
Re: xserver-xorg-video-vesa
Ivan Shmakov oneing...@gmail.com writes: Andrey Rahmatullin w...@wrar.name writes: On Tue, Jul 10, 2012 at 01:56:25PM +0400, Victor Wagner wrote: Впрочем, я считаю что ни в коем случае нельзя использовать проприетарные драйвера NVidia. Последние лет десять я совершенно уверен, что ни в коем случае нельзя использовать сами видеоадаптеры Nvidia. На домашней машине — на той из них, на которой есть X-сервер — у меня драйвер vesa, BTW. На моих задачах проблем пока не было. У vesa помнится, есть некоторые проблемы с просмотром видео. В смысле, авторы всяких программ для просмотра видео слишком закладываются на возможности видеооверлея, предоставляемые продвинутыми видеоадаптерами. В xterm, xclock, xeyes просмотр видео не входит. С одной стороны, xclock не нужна, поскольку есть date в xterm. С другой стороны, существенная часть материалов на http://coursera.org/ — именно видео. (А то, что не видео, — требует ECMAScript и в xterm тоже, к сожалению, не умещается.) mplayer с vesa работает, BTW. Равно как и Iceweasel. VESA хватает для всего, кроме комфортного просмотра видео. Вот у меня сейчас P4 и Radeon 9600. На VESA-драйвере P4 не справляется с автоматическим разворотом видео на весь экран. Для всего остального - работает на 5+. -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obnjybyd@ws00.freehck.ru
Re: xserver-xorg-video-vesa
On Fri, Jul 13, 2012 at 06:26:02PM +0400, Dmitrii Kashin wrote: VESA хватает для всего, кроме комфортного просмотра видео. Вот у меня сейчас P4 и Radeon 9600. На VESA-драйвере P4 не справляется с автоматическим разворотом видео на весь экран. Для всего остального - работает на 5+. И разрешения 16:10/16:9 выставляются? И несколько видеовыходов одновременно? -- WBR, Dmitry signature.asc Description: Digital signature
Re: xserver-xorg-video-vesa
Dmitry Nezhevenko d...@inhex.net writes: On Fri, Jul 13, 2012 at 06:26:02PM +0400, Dmitrii Kashin wrote: VESA хватает для всего, кроме комфортного просмотра видео. Вот у меня сейчас P4 и Radeon 9600. На VESA-драйвере P4 не справляется с автоматическим разворотом видео на весь экран. Для всего остального - работает на 5+. И разрешения 16:10/16:9 выставляются? И несколько видеовыходов одновременно? Увы, мне таковое без надобности. -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9z3yaqd@ws00.freehck.ru
xserver-xorg-video-vesa
Andrey Rahmatullin w...@wrar.name writes: On Tue, Jul 10, 2012 at 01:56:25PM +0400, Victor Wagner wrote: Впрочем, я считаю что ни в коем случае нельзя использовать проприетарные драйвера NVidia. Последние лет десять я совершенно уверен, что ни в коем случае нельзя использовать сами видеоадаптеры Nvidia. На домашней машине — на той из них, на которой есть X-сервер — у меня драйвер vesa, BTW. На моих задачах проблем пока не было. У vesa помнится, есть некоторые проблемы с просмотром видео. В смысле, авторы всяких программ для просмотра видео слишком закладываются на возможности видеооверлея, предоставляемые продвинутыми видеоадаптерами. В xterm, xclock, xeyes просмотр видео не входит. С одной стороны, xclock не нужна, поскольку есть date в xterm. С другой стороны, существенная часть материалов на http://coursera.org/ — именно видео. (А то, что не видео, — требует ECMAScript и в xterm тоже, к сожалению, не умещается.) mplayer с vesa работает, BTW. Равно как и Iceweasel. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86wr2b3m71.fsf...@gray.siamics.net
Re: xserver crash
Timothy Silent tara...@mail.ru writes: Если сказать startx а затем открыть офис, то в консоль падает: X:../../include/privates.h:116: dixGetPrivateAddr: Assertion `key-initialized' failed. xinit: connection to X server lost Как побороть? Коротко о себе: sid nvidia проприетарные дистрибутивные. wm awesome. Попробуйте: Меню-Сервис-Параметры-LibreOffice-Вид; Снять опцию включить аппаратное ускорение. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: xserver crash
On Tue, 20 Sep 2011 17:03:38 +0400 Anton Kovalenko wrote: Попробуйте: Меню-Сервис-Параметры-LibreOffice-Вид; Снять опцию включить аппаратное ускорение. не помогло. лечил так: 1. запуск офиса без документов - всё накрылось уже при попытке зайти в меню. 2. изменение настройки на соседнем компе и выкачивание .libreoffice - то же самое. попробовал как включённое так и выключенное. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920162909.11e30b82@ibem
Fwd: xserver crash
Есть та же проблема, если кто поможет - буду очень благодарен. Есть еще момент: после последнего недельного обновления на сид - не поставились дрова нвидии с сайта (блобы), орут не знаем мы этих иксов, обновлений дров еще не было. А репозиторные валятся постоянно. 20 сентября 2011 г. 13:29 пользователь Grey Fenrir grey.fen...@gmail.comнаписал: On Tue, 20 Sep 2011 17:03:38 +0400 Anton Kovalenko wrote: Попробуйте: Меню-Сервис-Параметры-LibreOffice-Вид; Снять опцию включить аппаратное ускорение. не помогло. лечил так: 1. запуск офиса без документов - всё накрылось уже при попытке зайти в меню. 2. изменение настройки на соседнем компе и выкачивание .libreoffice - то же самое. попробовал как включённое так и выключенное. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920162909.11e30b82@ibem
Драйвер fglrx, xserver-xorg и перегрев процессора
Добрый день! Последний год сидел на sid'е и все было прекрасно. Даже fglrx встал при установке без проблем. Все работало как часы до середины уходящей недели. Но вот бновился fglrx до версии 11.1 и xserver-xorg до 7.6 и после очередного ребута отказался грузить модель fglrx с формулировкой [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM и [drm:r600_startup] *ERROR* Failed to load firmware! Но эта проблема не такая уж и проблема - можно ведь и vesa использовать. Но при загрузке с vesa вместо нормальных для моего процессора 50 градусов нагрева он постоянно висел в диапазоне 80-88 градусов. Убил некоторое время чтобы поставить fglrx из пакетов, собранных из установщика с оф сайта. Но безрезультатно - перегрев оставался Тогда откатил fglrx, xserver-xorg до версий из стабильной ветки и все вернулось на круги своя. Гугление ничего не дало и решил спросить у уважаемого сообщества - Каким образом драйвер fglrx влияет на нагрев процессора? Машина - HP Pavilion dm3. Linux hp-debian 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux -- Utkin Gennadiy -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d572155.6080...@mail.ru
Re: Драйвер fglrx, xserver-xorg и перегрев процессора
On Sun, Feb 13, 2011 at 10:09:57AM +1000, Utkin Gennadiy wrote: Добрый день! Последний год сидел на sid'е и все было прекрасно. Даже fglrx встал при установке без проблем. Все работало как часы до середины уходящей недели. Но вот бновился fglrx до версии 11.1 и xserver-xorg до 7.6 и после очередного ребута отказался грузить модель fglrx с формулировкой [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM и [drm:r600_startup] *ERROR* Failed to load firmware! aptitude install load firmware-linux-nonfree Только скорее всего это ругань не fglrx Гугление ничего не дало и решил спросить у уважаемого сообщества - Каким образом драйвер fglrx влияет на нагрев процессора? Это, блядь, 5+! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213003920.gc16...@nano.ioffe.rssi.ru
Re: Драйвер fglrx, xserver-xorg и перегрев процессора
On Sun, Feb 13, 2011 at 03:39:20AM +0300, Иван Лох wrote: Гугление ничего не дало и решил спросить у уважаемого сообщества - Каким образом драйвер fglrx влияет на нагрев процессора? На vesa работает софтверный рендеринг и естественно греется процессор. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213004551.gd16...@nano.ioffe.rssi.ru
Re: Драйвер fglrx, xserver-xorg и перегрев процессора
13.02.2011 10:45, Иван Лох пишет: On Sun, Feb 13, 2011 at 03:39:20AM +0300, Иван Лох wrote: Гугление ничего не дало и решил спросить у уважаемого сообщества - Каким образом драйвер fglrx влияет на нагрев процессора? На vesa работает софтверный рендеринг и естественно греется процессор Но разве настолько должно греться? И после установки vesa стоял пару дней - не было нагрева даже до 60. Про Это, блядь, 5+! я Вас не понял. Что, прям так тупо вопрос задал? -- Utkin Gennadiy -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d572be2.5030...@yandex.ru
Re: Драйвер fglrx, xserver-xorg и перегрев процессора
On Sun, Feb 13, 2011 at 10:54:58AM +1000, Utkin Gennadiy wrote: 13.02.2011 10:45, Иван Лох пишет: On Sun, Feb 13, 2011 at 03:39:20AM +0300, Иван Лох wrote: Гугление ничего не дало и решил спросить у уважаемого сообщества - Каким образом драйвер fglrx влияет на нагрев процессора? На vesa работает софтверный рендеринг и естественно греется процессор Но разве настолько должно греться? И еще тормозить. И после установки vesa стоял пару дней - не было нагрева даже до 60. Про Это, блядь, 5+! я Вас не понял. Что, прям так тупо вопрос задал? У Вас ошибка Failed to load firmware! Ну так apt-cache search firmware radeon Или здесь спросите. Проще простого. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213012322.ge16...@nano.ioffe.rssi.ru
Re: Драйвер fglrx, xserver-xorg и перегрев процессора
13.02.2011 11:23, Иван Лох пишет: On Sun, Feb 13, 2011 at 10:54:58AM +1000, Utkin Gennadiy wrote: 13.02.2011 10:45, Иван Лох пишет: On Sun, Feb 13, 2011 at 03:39:20AM +0300, Иван Лох wrote: Гугление ничего не дало и решил спросить у уважаемого сообщества - Каким образом драйвер fglrx влияет на нагрев процессора? На vesa работает софтверный рендеринг и естественно греется процессор Но разве настолько должно греться? И еще тормозить. И после установки vesa стоял пару дней - не было нагрева даже до 60. Про Это, блядь, 5+! я Вас не понял. Что, прям так тупо вопрос задал? У Вас ошибка Failed to load firmware! Ну так apt-cache search firmware radeon Или здесь спросите. Проще простого. То что не грузит прошивку я и сам видел, потому и вставил это в письмо. Вопрос был почему _так_ греется? Ну и версия из стабильной ветки таких ошибок не выдает. Собственно вопрос был решен откатом драйвера как я писал в первом письме. Спасибо за ответы. -- Utkin Gennadiy -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d573466.5080...@yandex.ru
Re: xserver bug
Andrey Rahmatullin wrote: и X server останавливается. В баге, как видно, не останавливается. Да и баг про совсем другое. Да, искал по единственным еррорам, был невнимателен. Показывайте полный лог. Вот он: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-686 i686 Debian Current Operating System: Linux ibem 2.6.32-5-vserver-686 #1 SMP Thu Sep 30 06:24:27 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-vserver-686 root=UUID=26c1b09c-bc8d-4ef2-b9c5-78e0c779c224 ro quiet Build Date: 20 September 2010 03:40:46PM xorg-server 2:1.7.7-7 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Oct 9 18:19:27 2010 (==) Using config file: /etc/X11/xorg.conf (==) Using system config directory /usr/share/X11/xorg.conf.d (==) ServerLayout Layout0 (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Device0 (**) |--Input Device Keyboard0 (**) |--Input Device Mouse0 (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Keyboard0 (WW) Disabling Mouse0 (II) Loader magic: 0x81ea020 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (--) PCI:*(0:1:0:0) 10de:0429:17aa:20d8 nVidia Corporation G84M [Quadro NVS 140M] rev 161, Mem @ 0xd600/16777216, 0xe000/268435456, 0xd400/33554432, I/O @ 0x2000/128 (II) Open ACPI successful (/var/run/acpid.socket) (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded by default. (II) dri will be loaded by default. (II) dri2 will be loaded by default. (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: glx (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor=NVIDIA Corporation compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 195.36.31 Tue Jun 1 23:22:44 PDT 2010 (II) Loading extension GLX (II) LoadModule: record (II) Loading /usr/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: dri (II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: dri2 (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: nvidia (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so (II) Module
xserver bug
Доброго времени суток. После очередного обновления встретился с http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583346 тот же вывод про (EE) AlpsPS/2 ALPS DualPoint TouchPad Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device AlpsPS/2 ALPS DualPoint TouchPad и X server останавливается. Подскажите, пожалуйста, как побороть. debian sid xorg 1.7.7 kernel 2.6.32-5 nvidia 195.36.31-4 -- bi0shop -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1p4iay-ng-00.bi0shop-mail...@f242.mail.ru
Re: xserver bug
On Fri, Oct 08, 2010 at 10:59:50PM +0400, bi shop wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583346 xserver-xorg-input-synaptics: TapButton1 configuration option not respected in xorg.conf тот же вывод про (EE) AlpsPS/2 ALPS DualPoint TouchPad Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device AlpsPS/2 ALPS DualPoint TouchPad и X server останавливается. В баге, как видно, не останавливается. Да и баг про совсем другое. Подскажите, пожалуйста, как побороть. Показывайте полный лог. -- WBR, wRAR Powered by the ALT Linux fortune(6): mgr_ а что делать, когда zsh не дружит с русскими буквами? wRAR ставить альт * mgr_ теперь известен как gns wRAR а wRAR ставить новый альт gns повторяю вопрос :) gns у меня redhat9 wRAR я так и подумал wRAR почему-то gns гг wRAR zsh с поддержкой utf8 вышел спустя года три soul_r wRAR: ты всегда сначала отвечаешь, а потом читаешь вопрос? soul_r я к тому, что можно не утруждать себя написанием вопросов, ты и так неплохо отвечаешь wRAR гг wRAR нене, я серьёзно хотел выдать фразу про то, что рх9 говно, а надо ставить новый альт gns wRAR: О! ты наконец-то вернулся из отпуска? signature.asc Description: Digital signature
Re: Прокрутка-скроллин г на сенсорной панели но утбука сломалась после п опытки обновить xserver-xorg-video-intel
On Thu, 8 Apr 2010 19:06:32 +1100 XSS Vulnerable mental.a...@gmail.com wrote: On Thu, 08 Apr 2010 10:52:21 +0300 Игорь Чумак i.chu...@generali.garant.ua wrote: XSS Vulnerable пишет: Привет. Установлена Lenny 5.0. попытался обновить xserver-xorg-video-intel из репозитория sid... Ну обновил с зависимостями... перезагрузился и X.org не смог запуститься. Пришлось очистить кэш apt'a и установить старые пакеты. Все, вход в систему удался. Но только одно не работает сейчас - прокрутка окон, с помощью сенсорной панели ноутбука. Вожу пальчиками по панели, а она не работает. :( Как восстановить работоспособность прокрутки? xserver-xorg-input-synaptics - Synaptics TouchPad driver for X.Org/XFree86 server gsynaptics - configuration tool for Synaptics touchpad driver of X server tpconfig - configure touchpad devices Оно? да. оно. ;) спс. прокрутка заработала Необходимо было переустановить дебьян. :( После этого все эти пакеты установил, но тачпад работал без полос прокрутки. Используя утилиты tpconfig, gsynaptics... они сообщали что не могут получить доступ к share memory. Примерно еще такое сообщение You must to set up SHMConfig to On in /etc/X11/xorg.conf Посмотрел бывший xorg.conf который был у меня до этого, там никакого SHMConfig не было указано, но полосы прокрутки в тачпаде работали :(( Это явно какой то баг в дебьяне. Воспользовавшись случаем сообщу о еще одном баге в дебьяне ленни - это смещение экрана приветствия (логин скрин) в непонятно какую сторону. Недоработка драйверов для графических чиспетов Intel. :( Как все таки сделать полосы прокрутки на синаптике рабочими. :( -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414211204.27417...@zont
Re: Прокрутка-скроллинг на сенсорной пан ели ноутбука сломалась после попытки обновить xserver-xorg-video-intel
On Wed, Apr 14 2010, XSS Vulnerable wrote: SHMConfig to On in /etc/X11/xorg.conf Посмотрел бывший xorg.conf который был у меня до этого, там никакого SHMConfig не было указано, но полосы прокрутки в тачпаде работали :(( Это явно какой то баг в дебьяне. Воспользовавшись случаем сообщу о еще одном баге в дебьяне ленни - это смещение экрана приветствия (логин скрин) в непонятно какую сторону. Недоработка драйверов для графических чиспетов Intel. :( Как все таки сделать полосы прокрутки на синаптике рабочими. :( Если нужна замена gsynaptics, попробуйте gpointing-device-settings (из sid). Команднострочный synclient в sid входит в комплект x-x-i-synaptics; synclient -l должен отобразить список доступных настроек, если драйвер synaptics встал нормально. Среди них будет много всякого разного; прокрутка может не работать из-за BottomEdge, RightEdge, на самом деле из-за кучи всего другого тоже. В общем, сначала давайте с драйвером разберёмся, а потом вывод synclient -l запостите, и посмотрим на него. SHMConfig выпилили в пользу xinput, как я понял (на самом-то деле и synclient никакой сейчас не нужен: сделать xinput list, узнать номер тачпэда, сделать xinput --list-props номер, и все те же настройки, хоть под более длинными названиями, как на ладони). У меня на eee 900 при обновлении драйвера пришлось дописывать в .xsessionrc следующее: synclient FastTaps=1 TapButton1=1 TapButton2=2 TapButton3=3. (как минимум, TapButton раньше работали сразу). Но вот с прокруткой (на eee и текущем драйвере из sid) проблем как раз нет; правда, я пользуюсь two-finger scroll, а не краевым. О, кстати, ещё вопрос: может, драйвер вдруг осознал, что ваш тачпэд умеет мультитач, и решил скроллить по друм пальцам? Стоит проверить. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Прокрутка-скроллин г на сенсорной панели ноутбука сломалась посл е попытки обновить xserver-xorg-video-intel
On Wed, Apr 14, 2010 at 02:50:08PM +0400, Anton Kovalenko wrote: У меня на eee 900 при обновлении драйвера пришлось дописывать в .xsessionrc следующее: synclient FastTaps=1 TapButton1=1 TapButton2=2 TapButton3=3. Это всё пишется (в squeeze) в /lib/udev/rules.d/66-xorg-synaptic.rules -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(6): Ну gcc3 на J20 я не протащу. он наверняка за собой потянет обновленный до gcc3.4 Junior 2.0 называется сизиф и обитает в соседней рассылке $) -- genix in community@ signature.asc Description: Digital signature
Re: Прокрутка-скроллинг на сенсорной пан ели ноутбука сломалась после попытки обновить xserver-xorg-video-intel
On Wed, Apr 14 2010, Andrey Rahmatullin wrote: У меня на eee 900 при обновлении драйвера пришлось дописывать в .xsessionrc следующее: synclient FastTaps=1 TapButton1=1 TapButton2=2 TapButton3=3. Это всё пишется (в squeeze) в /lib/udev/rules.d/66-xorg-synaptic.rules Простите, сэр, но на фига? Живи оно сейчас в /etc (и будь оно conffiles) -- я бы согласился, что ваш вариант приемлем (мне-то всё равно нужны разные настройки для юзеров, а ваши - это «счастье всем, даром», и всем одинаковое). А так эти настройки просто снесут при апгрейде, и всё. Если уж в /lib/udev что-то класть, то только отдельным файлом (67-our-xorg-synaptics.rules, к примеру). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Прокрутка-скроллин г на сенсорной панели ноутбука сломалась посл е попытки обновить xserver-xorg-video-intel
On Wed, Apr 14, 2010 at 03:04:58PM +0400, Anton Kovalenko wrote: On Wed, Apr 14 2010, Andrey Rahmatullin wrote: У меня на eee 900 при обновлении драйвера пришлось дописывать в .xsessionrc следующее: synclient FastTaps=1 TapButton1=1 TapButton2=2 TapButton3=3. Это всё пишется (в squeeze) в /lib/udev/rules.d/66-xorg-synaptic.rules Простите, сэр, но на фига? Живи оно сейчас в /etc (и будь оно conffiles) -- я бы согласился, что Скопируй просто в /etc/udev/rules.d/ и исправь. Он позже читается -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414112933.ga3...@nano.ioffe.rssi.ru
Re: Прокрутка-скроллинг на сенсорной пан ели ноутбука сломалась после попытки обновить xserver-xorg-video-intel
On Wed, Apr 14 2010, Иван Лох wrote: Это всё пишется (в squeeze) в /lib/udev/rules.d/66-xorg-synaptic.rules Простите, сэр, но на фига? Живи оно сейчас в /etc (и будь оно conffiles) -- я бы согласился, что Скопируй просто в /etc/udev/rules.d/ и исправь. Он позже читается Благодарю, но мне не надо :) Я традиционно чихать хотел на системные настройки, пока они позволяют набрать логин и пароль. А уж если речь идёт об устройстве, которое никто не собирается вынимать и втыкать… Но вообще информация полезная. А вот, раз уж разговор зашёл -- не знаете ли какой-нибудь штуки, которая отслеживает событие «подключили клавиатуру» (через XInput2 это делается), и применяет пользовательский setxkbmap, когда это происходит? А то если нету, надо бы написать (правда, кое-чего я здесь не понимаю: Вроде бы раскладка setxkbmap применяется к core keyboard, т.е. к виртуальному устройству, которое есть всегда; тем не менее, если отключить и включить десктопную клавиатуру, последствия setxkbmap теряются; интересно, какая логика за этим стоит?). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Прокрутка-скроллин г на сенсорной панели ноутбука сломалась посл е попытки обновить xserver-xorg-video-intel
On Wed, Apr 14, 2010 at 03:46:41PM +0400, Anton Kovalenko wrote: Вроде бы раскладка setxkbmap применяется к core keyboard, т.е. к виртуальному устройству, которое есть всегда; тем не менее, если отключить и включить десктопную клавиатуру, последствия setxkbmap теряются; интересно, какая логика за этим стоит?). Клавиатуры разные бывают. А настройку их я только через hal умею делать... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414125802.gb3...@nano.ioffe.rssi.ru
Re: Прокрутка-скроллинг на сенсорной пан ели ноутбука сломалась после попытки обновить xserver-xorg-video-intel
On Wed, Apr 14 2010, Иван Лох wrote: Вроде бы раскладка setxkbmap применяется к core keyboard, т.е. к виртуальному устройству, которое есть всегда; тем не менее, если отключить и включить десктопную клавиатуру, последствия setxkbmap теряются; интересно, какая логика за этим стоит?). Клавиатуры разные бывают. А настройку их я только через hal умею делать... Я понимаю, что они разные бывают, но core keyboard (виртуальная) ведь одна? Полагаю, при уходе с hal логика не изменилась - ну, другим способом оповещение об устройстве получается, но xinput2 и xkb это затрагивать не должно. Вам приходилось на двух клавиатурах ставить разные раскладки, хотя бы через hal? И как оно при одновременном подключении -- действительно для каждой клавиатуры умеет свои настройки? А то боюсь я, что по втыканию перенастраивается (согласно данным из hal/udev) опять же core keyboard, одна на всех (тогда раскладка для последней подключённой клавиатуры будет применена и к остальным; если такого эффекта не видно, то я неправ). В общем, надо поэкспериментировать. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Прокрутка-скроллин г на сенсорной панели но утбука сломалась после п опытки обновить xserver-xorg-video-intel
On Wed, 14 Apr 2010 14:50:08 +0400 Anton Kovalenko an...@sw4me.com wrote: On Wed, Apr 14 2010, XSS Vulnerable wrote: SHMConfig to On in /etc/X11/xorg.conf Посмотрел бывший xorg.conf который был у меня до этого, там никакого SHMConfig не было указано, но полосы прокрутки в тачпаде работали :(( Это явно какой то баг в дебьяне. Воспользовавшись случаем сообщу о еще одном баге в дебьяне ленни - это смещение экрана приветствия (логин скрин) в непонятно какую сторону. Недоработка драйверов для графических чиспетов Intel. :( Как все таки сделать полосы прокрутки на синаптике рабочими. :( Если нужна замена gsynaptics, попробуйте gpointing-device-settings (из sid). Команднострочный synclient в sid входит в комплект x-x-i-synaptics; synclient -l должен отобразить список доступных настроек, если драйвер synaptics встал нормально. Среди них будет много всякого разного; прокрутка может не работать из-за BottomEdge, RightEdge, на самом деле из-за кучи всего другого тоже. В общем, сначала давайте с драйвером разберёмся, а потом вывод synclient -l запостите, и посмотрим на него. SHMConfig выпилили в пользу xinput, как я понял (на самом-то деле и synclient никакой сейчас не нужен: сделать xinput list, узнать номер тачпэда, сделать xinput --list-props номер, и все те же настройки, хоть под более длинными названиями, как на ладони). У меня на eee 900 при обновлении драйвера пришлось дописывать в .xsessionrc следующее: synclient FastTaps=1 TapButton1=1 TapButton2=2 TapButton3=3. (как минимум, TapButton раньше работали сразу). Но вот с прокруткой (на eee и текущем драйвере из sid) проблем как раз нет; правда, я пользуюсь two-finger scroll, а не краевым. О, кстати, ещё вопрос: может, драйвер вдруг осознал, что ваш тачпэд умеет мультитач, и решил скроллить по друм пальцам? Стоит проверить. странно :B а сейчас заработала прокрутка.. после перезагрузки. вроде ниче особенного не делал. Вот вывод команд: m:/home/alexander# synclient -l Can't access shared memory area. SHMConfig disabled? m:/home/alexander# tpconfig Found Synaptics Touchpad. Firmware: 8.96 (multiple-byte mode). m:/home/alexander# tpconfig -i Found Synaptics Touchpad. Firmware: 8.96 (multiple-byte mode). Sensor type: unknown (0). Geometry: rectangular/landscape/up. Packets: absolute, 80 packets per second. Corner taps disabled; no tap gestures. Edge motion: none. Z threshold: 6 of 7. 2 button mode; corner tap is right button click. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100415002750.196bf...@zont
Re: Прокрутка-скроллин г на сенсорной панели ноутбука сломалась посл е попытки обновить xserver-xorg-video-intel
On Wed, Apr 14, 2010 at 05:15:52PM +0400, Anton Kovalenko wrote: On Wed, Apr 14 2010, Иван Лох wrote: Вроде бы раскладка setxkbmap применяется к core keyboard, т.е. к виртуальному устройству, которое есть всегда; тем не менее, если отключить и включить десктопную клавиатуру, последствия setxkbmap теряются; интересно, какая логика за этим стоит?). Клавиатуры разные бывают. А настройку их я только через hal умею делать... Я понимаю, что они разные бывают, но core keyboard (виртуальная) ведь одна? Полагаю, при уходе с hal логика не изменилась - ну, другим способом оповещение об устройстве получается, но xinput2 и xkb это затрагивать не должно. Вам приходилось на двух клавиатурах ставить разные раскладки, хотя бы через hal? И как оно при одновременном подключении -- действительно для каждой клавиатуры умеет свои настройки? Каждая физическая клавиатура это Slave device и она настраивается через hal или udev. Core keyboard (XKeyboard) -- Master device -- динамически связана с одной из них. Остальные -- XExtensionKeyboard. setxkbmap имеет ключ -device (по-умолчанию, core keyboard) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414135845.gc3...@nano.ioffe.rssi.ru
Re: Прокрутка-скроллинг на сенсорной пан ели ноутбука сломалась после попытки обновить xserver-xorg-video-intel
On Wed, Apr 14 2010, XSS Vulnerable wrote: странно :B а сейчас заработала прокрутка.. после перезагрузки. вроде ниче особенного не делал. Вот вывод команд: m:/home/alexander# synclient -l Can't access shared memory area. SHMConfig disabled? Я всё-таки не понял, у вас x-x-i-synaptics из lenny или из squeeze? Вроде как то, что перезагрузка помогла -- к дождю^W свойствам udev'а, что говорит о squeeze. (можно было бы вместо неё дать от рута udevadm trigger --subsystem-match=input и udev бы пересообразил параметры устройств). Но если squeeze, откуда там synclient, требующий SHMConfig?.. (если это lenny, то надо бы его включить, наверное. Но, боюсь, _тогда_ это через hal, а не через xorg.conf). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Прокрутка-скроллинг на сенсорной пан ели ноутбука сломалась после попытки обновить xserver-xorg-video-intel
On Wed, Apr 14 2010, Иван Лох wrote: Каждая физическая клавиатура это Slave device и она настраивается через hal или udev. Core keyboard (XKeyboard) -- Master device -- динамически связана с одной из них. Остальные -- XExtensionKeyboard. Ага, вот теперь всё встало на свои места, спасибо. То есть setxkbmap без параметров конфигурирует одну из Slave клавиатур (если повезёт, то настоящую, а если она не успела обнаружиться, то XTEST, к примеру :) Я почему-то заглючил в сторону того, что у Virtual Core Keyboard есть _отдельная_ настройка xkb. Теперь разглючил. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
Re: Прокрутка-скроллин г на сенсорной панели но утбука сломалась после п опытки обновить xserver-xorg-video-intel
On Wed, 14 Apr 2010 18:36:33 +0400 Anton Kovalenko an...@sw4me.com wrote: On Wed, Apr 14 2010, XSS Vulnerable wrote: странно :B а сейчас заработала прокрутка.. после перезагрузки. вроде ниче особенного не делал. Вот вывод команд: m:/home/alexander# synclient -l Can't access shared memory area. SHMConfig disabled? Я всё-таки не понял, у вас x-x-i-synaptics из lenny или из squeeze? Вроде как то, что перезагрузка помогла -- к дождю^W свойствам udev'а, что говорит о squeeze. (можно было бы вместо неё дать от рута udevadm trigger --subsystem-match=input и udev бы пересообразил параметры устройств). Но если squeeze, откуда там synclient, требующий SHMConfig?.. (если это lenny, то надо бы его включить, наверное. Но, боюсь, _тогда_ это через hal, а не через xorg.conf). у меня lenny stable. Ладно, будем изучать hal ж) Но это в следующий раз, когда опять прокрутка сломается. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100415015000.31a8a...@zont
Re: Прокрутка-скроллин г на сенсорной панели ноутбука сломалась посл е попытки обновить xserver-xorg-video-intel
On Wed, Apr 14, 2010 at 02:50:08PM +0400, Anton Kovalenko wrote: synclient FastTaps=1 TapButton1=1 TapButton2=2 TapButton3=3. (как минимум, TapButton раньше работали сразу). Но вот с прокруткой (на eee и текущем драйвере из sid) проблем как раз нет; правда, я пользуюсь two-finger scroll, а не краевым. Я только сейчас обратил внимание, что у меня VertEdgeScroll вписан. Правда это потому что мультитач, а он выключает боковую прокрутку IIRC. О, кстати, ещё вопрос: может, драйвер вдруг осознал, что ваш тачпэд умеет мультитач, и решил скроллить по друм пальцам? Стоит проверить. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(6): henker Utvuk: что-то ip flush cache Utvuk henker: блин, боязно, я как ip r flush сделал, так мне пришлось наверьхь бежать service network restart делать - он table main почистил :) henker Utvuk: хехе Utvuk henker: те смешно, а от серверной далековато нахожусь - на другом этаже. пока добежишь все двери откроешь телефон раскалиться успеет henker Utvuk: хе. а мне тогда пришлось звонить и расказывать как нетворк рестарт henker Utvuk: а еще было сидишь по ссх, хотел рестарт, на наверняка лучше стоп/старт. и тока потом понимаешь.. :) Utvuk henker: у меня было другое - за 2000 км мне на сотовый позволнили, сказали, что к серверу подключиться не могут. а я в поезде был - вот по телефону пришлось говорить, как проверить - dns запись оказывается забыл сделать, и как nslookup'ом е доабвить :) dottedmag henker: screen рулит henker dottedmag: ну да, network stop, и уже ничего не рулит signature.asc Description: Digital signature
Прокрутка-скроллинг на сенсорной панели ноут бука сломалась после поп ытки обновить xserver-xorg-video-intel
Привет. Установлена Lenny 5.0. попытался обновить xserver-xorg-video-intel из репозитория sid... Ну обновил с зависимостями... перезагрузился и X.org не смог запуститься. Пришлось очистить кэш apt'a и установить старые пакеты. Все, вход в систему удался. Но только одно не работает сейчас - прокрутка окон, с помощью сенсорной панели ноутбука. Вожу пальчиками по панели, а она не работает. :( Как восстановить работоспособность прокрутки? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408184837.00857...@zont
Re: Прокрутка-скрол линг на сенсорной п анели ноутбука слом алась после попытки обновить xserver-xorg-video-intel
XSS Vulnerable пишет: Привет. Установлена Lenny 5.0. попытался обновить xserver-xorg-video-intel из репозитория sid... Ну обновил с зависимостями... перезагрузился и X.org не смог запуститься. Пришлось очистить кэш apt'a и установить старые пакеты. Все, вход в систему удался. Но только одно не работает сейчас - прокрутка окон, с помощью сенсорной панели ноутбука. Вожу пальчиками по панели, а она не работает. :( Как восстановить работоспособность прокрутки? xserver-xorg-input-synaptics - Synaptics TouchPad driver for X.Org/XFree86 server gsynaptics - configuration tool for Synaptics touchpad driver of X server tpconfig - configure touchpad devices Оно? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bbd8b35.6070...@generali.garant.ua
Re: Прокрутка-скроллин г на сенсорной панели но утбука сломалась после п опытки обновить xserver-xorg-video-intel
On Thu, 08 Apr 2010 10:52:21 +0300 Игорь Чумак i.chu...@generali.garant.ua wrote: XSS Vulnerable пишет: Привет. Установлена Lenny 5.0. попытался обновить xserver-xorg-video-intel из репозитория sid... Ну обновил с зависимостями... перезагрузился и X.org не смог запуститься. Пришлось очистить кэш apt'a и установить старые пакеты. Все, вход в систему удался. Но только одно не работает сейчас - прокрутка окон, с помощью сенсорной панели ноутбука. Вожу пальчиками по панели, а она не работает. :( Как восстановить работоспособность прокрутки? xserver-xorg-input-synaptics - Synaptics TouchPad driver for X.Org/XFree86 server gsynaptics - configuration tool for Synaptics touchpad driver of X server tpconfig - configure touchpad devices Оно? да. оно. ;) спс. прокрутка заработала -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408190632.16fe2...@zont
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: А при чем тут индексы? Индексы были в том, во что якобы Разработчики Оракла тоже верили. Убийственный аргумент. Табличку 10Тб индексировать совсем не нужно? Еще раз - при чем тут индексы? Разговор был про общую память. Постгресс не умеет использовать столько памяти, сколько ему сказали? Не верю! :) Оракл точно умеет. Причём весьма гранулярно: сегмент для базы, сегмент для пользовательских сессий, и т.д. А что не лезет, то крутится через диск. Умеет. Только столько памяти нет, чтобы все данные с диска в нее засунуть. К примеру, на сервере с 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(). :-) Так что этот пример показывает, что линуксное ядро из коробки умеет само подстроить размер буферной памяти, причём лучше, чем доморощенный DBA. А про двойную буферизацию постгреса знаете? Мало того, что кэш ФС попадает, так еще и своя shared memory, да еще система из нескольких уровней для синхронизации с persistent storage... Нет, отключить двойную буферизацию СУБД с shared memory не удастся. Оракл обходит эту проблему, используя raw devices, т.е. прямой доступ к неформатированному дисковому носителю, но это вообще не UNIX-way и, более того, полностью привязывает пользователя к вендору СУБД. Это пример того, как DBA не справился с настройкой базы, загнав сервер в своппинг. Нормально настроенная база не должна свопиться, независимо от того, сколько у неё сессий и сколько данных ей приходится качать через диск. Назовите настройки постгреса, которые позволят 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. А про двойную буферизацию постгреса знаете? Мало того, что кэш ФС попадает, так еще и своя shared memory, да еще система из нескольких уровней для синхронизации с persistent storage... Нет, отключить двойную буферизацию СУБД с shared memory не удастся. Оракл обходит эту проблему, используя raw devices, т.е. Оракл объявил методику raw devices как deprecated год или два назад. Наверное, ему надоело проблему обходить и он её переехал как танк. :) прямой доступ к неформатированному дисковому носителю, но это вообще не UNIX-way и, более того, полностью привязывает пользователя к вендору СУБД. Правильные флаги open(2) это не юникс-вэй? Хм. Не знал. Это пример того, как DBA не справился с настройкой базы, загнав сервер в своппинг. Нормально настроенная база не должна свопиться, независимо от того, сколько у неё сессий и сколько данных ей приходится качать через диск. Назовите настройки постгреса, которые позволят 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), а теперь они техническую информацию маркетинговой заменяют, читать стало бесполезно. А жаль. прямой доступ к неформатированному дисковому носителю, но это вообще не UNIX-way и, более того, полностью привязывает пользователя к вендору СУБД. Правильные флаги open(2) это не юникс-вэй? Хм. Не знал. Программа должна работать _с любой ФС_, какую только пожелает пользователь. От ФС требуется лишь POSIX-совместимость. Я из тех, кто полагает, что если программа имеет ручку для ограничения размера памяти, эта ручка обязана у неё работать. Иначе программа не имеет права называться нормальной, либо у её рулевого надо отобрать микроскоп и вручить банан. Выберите your way. В теории между теорией и практикой нет разницы... Но правда в ваших словах есть. Потому я и использую теперь 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) это не юникс-вэй? Хм. Не знал. Программа должна работать _с любой ФС_, какую только пожелает пользователь. От ФС требуется лишь POSIX-совместимость. Вы ещё не посмотрели man 2 open? Сюрприз: флаги O_SYNC, O_DSYNC и O_RSYNC специфицированы в POSIX. Подозреваю, ораклоиды в курсе. Я из тех, кто полагает, что если программа имеет ручку для ограничения размера памяти, эта ручка обязана у неё работать. Иначе программа не имеет права называться нормальной, либо у её рулевого надо отобрать микроскоп и вручить банан. Выберите your way. В теории между теорией и практикой нет разницы... Но правда в ваших словах есть. Потому я и использую теперь SQLite. Поздравляю, это правильный выбор! :) -- 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
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: Мое категоричное утверждение было о том, что БЫВАЮТ задачи для которых нити действительно полезны и БЫВАЮТ программисты, которые способны с ними в этой ситуации справиться. Но в 90% задач существуют более надежные решения. И более простые, которые можно уложить в голове у нормального программиста, а не супергения. Ситуации бываю разные. И методы их решения тоже. Предложите варианты (переносимые) для эффективной масштабируемости на SMP-системах. Я уже писал об этом выше. Варианты чего? Сервера, обслуживающего многочисленных клиентов? Вот он прекрасно масштабируется fork-ом. И переносимость его на платформы, не умеющие fork - неинтересна. Для этих платформ аналогичный продукт надо писать с нуля с принципиально иными архитектурными решениями. Отказ от ООП как такового вовсе не гарантирует вам хорошего качества продукта на выходе. Зачастую такого понапишут, что черт ногу сломит. Для ООП это тоже актуально, поэтому, как мне кажется, всё зависит от квалификации разработчика. Если она недостаточна, то ни ООП, ни процедурный стиль, ни функциональный не дадут вам удовлетворительный результат. Вопрос в том, какая именно квалификация достаточна. Для архитектуры без ООП и без нитей достаточна намного меньшая квалификация, чем для грамотного использования того или другого. следует избегать елико возможно - это вы сами придумали ? Или есть рекомендации в серьезных источниках ? Какие источники вы считаете серьезными? Маркетинговый бред банды четырех? А вот задачи с которыми пользователь имеет дело каждый день - браузер, X-сервер, текстовый редактор etc просто НЕ ИМЕЮТ права падать. Даже в случае заведомо неправильных действий пользователя. Т.е. из этой фразы можно сделать вывод, что нити - потенциально ведут к падениям ПО, написанного с их использованием ? Странно как-то это звучит. Нити подразумевают что несколько потоков выполнения одновременно обращаются к общей памяти. Причем, как правило, в этой памяти еще и указатели бывают. Отсюда один шаг до сегфолта в случае ошибки синхронизации. Т.е. если мы все напишем через 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
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): Мое категоричное утверждение было о том, что БЫВАЮТ задачи для которых нити действительно полезны и БЫВАЮТ программисты, которые способны с ними в этой ситуации справиться. Но в 90% задач существуют более надежные решения. И более простые, которые можно уложить в голове у нормального программиста, а не супергения. Ситуации бываю разные. И методы их решения тоже. Предложите варианты (переносимые) для эффективной масштабируемости на SMP-системах. Я уже писал об этом выше. На мой взгляд, сейчас есть ряд весьма популярных технологий (нити - не единственная, есть еще OOP), написание надежных программ на которых требует очень высокой квалификации, очень грамотного дизайна, но при этом эти технологии создают ОБМАНЧИВОЕ впечатление простоты. Отказ от ООП как такового вовсе не гарантирует вам хорошего качества продукта на выходе. Зачастую такого понапишут, что черт ногу сломит. Для ООП это тоже актуально, поэтому, как мне кажется, всё зависит от квалификации разработчика. Если она недостаточна, то ни ООП, ни процедурный стиль, ни функциональный не дадут вам удовлетворительный результат. Поэтому в качестве rule of thumb использования этих технологий следует избегать елико возможно. И использовать только тогда, когда были перепробованы все остальные варианты, и стало очевидно, что они не годятся. (кстати, сам факт перепробования остальных вариантов очень способствует правильному дизайну). следует избегать елико возможно - это вы сами придумали ? Или есть рекомендации в серьезных источниках ? OpenMP - узконишевой продукт. Причем в такой нише, где надежность, как правило, не является категорическим императивом. Потому что типичная счетная задача девять раз из десяти завершается неудачей вовсе не потому что наступили на грабли с нитями, а потому что не углядели какой-то особенности в модели. Поэтому если она будет завершаться неудачно не 9 раз из 10, а 19 из 20, но эти 20 прогонов будут завершены быстрее, чем те 10 - на это можно пойти. openMP пригоден не только для счетных задач (моделирование, о котором вы упомянули), тем более для них есть более подходящие средства. У учетом того, что он есть во всех современных компиляторах, сфера его применения может быть весьма широкой. Естественно, при АДЕКВАТНОМ применении. При неадекватном любая технология может выдать монстра. А вот задачи с которыми пользователь имеет дело каждый день - браузер, X-сервер, текстовый редактор etc просто НЕ ИМЕЮТ права падать. Даже в случае заведомо неправильных действий пользователя. Т.е. из этой фразы можно сделать вывод, что нити - потенциально ведут к падениям ПО, написанного с их использованием ? Странно как-то это звучит. Т.е. если мы все напишем через 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 и т.д. ? При правильной реализации алгоритма все это легко и просто ЛИчно я бы оторвал яйца тому, кто стал бы это делать на 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 Хорошо, озвучьте тогда этот класс, если вас не затруднит. Я верю в осмысленность разделяемой памяти для баз данных. Для беготни по индексам в условиях, когда mmap() работает на запись неоптимально. А так как-то сходу больше и не приведу примеров... AA И чем приведенный пример плох ? Насколько мне известно, многие AA архиваторы поддерживающих smp - сделаны на потоках, и вполне себе AA работают. Я могу это объяснить, например, тем, что основная целевая платформа либо платформа разработки их - Windows. Где _традиционно_ для распараллеливания используются нити. И... надо сказать, осмысленность таких архиваторов, похоже, весьма ограничена как таковая. Ну, то есть в отсутствие маркетингового буллшита они как-то не используются... Разработчики Photoshop - довольно известный пример неадекватности. Ну, то есть алгоритмисты у них хорошие, а вот с программистами не сложилось. Странно, что Вы этого не знаете... AA Я не говорю, что они гении, но и не считать их неадекватными. Что AA же именно там у них не так ? Я не знаю, насколько их подход был адекватен для MacOS, но та MacOS уже не существует, а фотошоп все еще развлекается с собственным свопом (по слухам - так, что ставит раком всю систему) и пишет в Program Files. Больше 10 лет существует Photoshop под Windows, а его программисты так и не осознали этого факта. Теперь он уже и под родную макось неадекватен... -- Современной называется технология, которую пытаются совать во все дырки независимо от того, заточена она под них или нет. Д. Белявский -- 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 видеокодеков и т.д. вы тоже будете ставить под сомнение ? Разработчики Photoshop - довольно известный пример неадекватности. Ну, то есть алгоритмисты у них хорошие, а вот с программистами не сложилось. Странно, что Вы этого не знаете... -- В теории нет различия между теорией и практикой. На практике - есть. -- 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): Вот так винда устроена. Вроде работает, простые вещи делаются просто, а сложные - никак не делаются. Причем понятия простое/сложное - ни разу не юзерские... Ну не все так плохо, как мне кажется. Линукс за последние годы, конечно, несколько отошел от своего первоначального пути. Но это плата за некоторую популярность, как мне кажется - простым юзерам хочется чтоб было попроще и покрасивше.
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
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
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): Вы преувеличиваете. Аргументы от Anton Anikin вида плохо, хорошо и глупо весьма способствуют улыбке. Что касается домашнего задания, то это словосочетание используют многие преподаватели и учителя, в том числе в неформальной обстановке - выходит, вы их всех готовы в хамы записать? А если я вас неправильно понял, то и вы могли неправильно понять. Давайте будем следить за собой, а не другими. Еще один сноб. Если вас так радуют слова в моих сообщениях - так вы читайте их почаще, может настроение улучшится. А то судя по обилию у вас очень формальных и серьезных аргументов вида надо всем яйца оторвать можно подумать, что у вас имеются какие-то личные проблемы с рассматриваемой областью. Насчет дом. задания - не надо тут выкручиваться. Рассылка не только немодеруруемая, но и вроде как равноправна для всех ее участников. Если вы (или Артем) считаете, что можете относится к другим снисходительно - это ваши личные проблемы, а точнее проблемы вашего воспитания. Лично мне неприятно общаться с вами в таком ключе.
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
В сообщении от 5 мая 2009 Eugene V. Lyubimkin написал(a): Алексей, вы не правы. Давайте закончим эти глупые, уже давно нетехнические препирательства. Никакие нити с FSM'ами не стоят человеческих отношений. Лично я поддерживаю. Никто никого уже ни в чем не убедит, да и смысле в этом нет.
Re: xserver-xorg и hal
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 не сильно то важные. А вот когда баловство (hal/d-bus) ломает/раздувает инструмент для нормальной работы (xserver) - плохо. Пока есть возможность отключения этой попсы - половина беды, когда это станет неотъемлемой частью и вас лишат выбора - дистрибутивом будет сложно что-то решить. /swp -- 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
В сообщении от 2 мая 2009 Иван Лох написал(a): А на чем рассчитывать-то будем? На кластере небось? Для кластеров есть другие средства (MPI и им подобные) и там свои проблемы и уже отработанные методы их решения. Я имел в виду обычные SMP-системы, благо многоядерные процессоры - уже мейнстрим. И очень часто правильное применение банального #pragma omp for (и им подобных директив openMP) позволяет практически линейно масштабировать производительность при росте количества ядер. Это, конечно, далеко не всегда так красиво получается, но тем не менее (естественно, при понимании программистом как оно вообще работает и куда нужно, а куда не стоит это пихать).
Re: xserver-xorg и hal
On Sat, May 02, 2009 at 06:30:16PM +0900, Anton Anikin wrote: В сообщении от 2 мая 2009 Иван Лох написал(a): А на чем рассчитывать-то будем? На кластере небось? Для кластеров есть другие средства (MPI и им подобные) и там свои проблемы и уже отработанные методы их решения. Я имел в виду обычные SMP-системы, благо многоядерные процессоры - уже мейнстрим. И очень часто правильное применение банального #pragma omp for (и им подобных директив openMP) позволяет Когда Вы пишете счетный код Вы, как правило, еще не знаете на чем его придется запускать. Если Вы используете только MPI, то Вы можете перенести свой код на кластер, а если, OpenMP, то Вам придется делать гибрид. То есть менять все прагмы и заново отлаживаться. К тому же MPICH быстрее и лучше управляется. P.S. Я правильно понимаю, что Chrome это демонстративный отказ от нитей? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
