from:"Покотиленко Костик"

Re: Wheezy NetworkManager VPN

2013-06-10 Пенетрантность Покотиленко Костик

В Пнд, 10/06/2013 в 11:45 +0400, Alex Dubinin пишет:
 10.06.2013 11:40, Alexander пишет: 
  может быть проблема с mtu, покурите настройки:
  tun-mtu
  fragment
  mssfix
 А где найти конфиг NM ? ну если конечно только не скрин-шоты?

Там есть кнопочка Экспорт


-- 
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/1370855048.11678.4.ca...@casper-hp.friendin.net

Re: про apt-get autoremove

2013-06-06 Пенетрантность Покотиленко Костик

В Чтв, 06/06/2013 в 07:10 +0400, Eugene Berdnikov пишет:
 On Thu, Jun 06, 2013 at 12:07:12AM +0400, Dmitrii Kashin wrote:
  Коли так, то заранее призову Вас ко здравому смыслу, потому что
  половина используемого Вами софта перестанет работать. Просто как
  пример: Evince имеет нестрогую зависимость от DBus, но без него
  откажет в возможности просмотра pdf/djvu. Только dvi.
 
  Интересно, как специалисты по здравому смыслу объясняют желание
  программы иметь dbus для просмотра pdf/djvu? Мне лично как
  марсианину кажется, что смысла здесь не больше, чем в поиске
  жизни на Земле... :)

Смысл - интеграция (тесная взаимосвязь компонент). Если Вы противник DE,
это не для Вас.


-- 
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/1370513418.27963.3.ca...@casper-hp.friendin.net

Re: nscd работает с libnss-ldapd ?

2013-06-05 Пенетрантность Покотиленко Костик

В Птн, 31/05/2013 в 17:05 +0400, Владимир Скубриев пишет:
On 31.05.2013 16:41, Покотиленко Костик wrote:

Вообще-то, для серьёзных задач должно быть несколько ldap серверов.
Выкрутиться, конечно, можно с помощью libpam-ccreds как уже говорили.
На счет двух серверов ldap согласен. Но пока хватает задач. Еще надо
поднять dns,dhcp,ftp,samba и многое многое другое. Все с помощью chef
(opscode)

Я уже почти все сделал на sssd.

Только с SUDOers не получается.

В процессе sudo su на клиенте sssd обращается к серверу. Но почему то
ни слова не спрашивает про контейнер с SUDOers.

Я так подозреваю он делает чисто аутентификацию пользователя, а
проверку sudo вообще не делает.

Это я выяснил запустив slapd -d -1

На sssd периодически смотрю, но так как LDAP используется для
стационарных потребителей, его ещё не пробовал. Была идея использовать
его для корпоративных ноутов...

Возможно с sudo он и не будет работать. Если у Вас получится,
отпишитесь, интересно.

Кстати, все запросы по твоему вопросу ведут сюда:
http://fedoraproject.org/wiki/Features/SSSDSudoIntegration

на сколько я понял это патч под sudo-ldap и sssd.

--
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/1370357311.11458.6.ca...@casper-hp.friendin.net

Re: nscd работает с libnss-ldapd ?

2013-05-31 Пенетрантность Покотиленко Костик

В Вто, 28/05/2013 в 10:51 +0400, Владимир Скубриев пишет:
On 28.05.2013 10:27, Alex Mestiashvili wrote:

On 05/28/2013 07:58 AM, Владимир Скубриев wrote:
nscd работает с libnss-ldapd ?
работает.

apt-file search /lib/libnss_ldap.so.2
libnss-ldap: /lib/libnss_ldap.so.2
libnss-ldapd: /lib/libnss_ldap.so.2

man nsswitch.conf

т.е. если использовать libnss-ldapd вместо libnss-ldap?

видимо есть какой то скрытый смысл в его в работе.
в чьей работе ?
в работе nscd

я так понимаю, что он нужен, для того, чтобы кэшировать например
passwd, group из nss

т.е. в случае если не доступен ldap server система должна видеть
пользователей и группы ldap

но у меня она видит только локальных юзеров машины из /etc/passwd если
физически выключить ldap сервер

может я что то не до настроил

но практически во всех мануалах его (nscd) просто ставят и все

у меня кстати стоит связка libnss-ldapd и nslcd

в связи с этим вопрос чем кэшировать данные passwd, group в случае не
доступности ldap server

если я отключаю ldap сервер, то команда getent passwd выводит только
как отключаете ? убираете ldap в /etc/nsswitch.conf ?

отключаю виртуальную машину с ldap сервером
локальных пользователей.

в чем скрытый смысл?
nscd - name service caching daemon.
чтобы посмотреть что делпает nscd можно запустить его с ключом -d

pkill nscd nscd -d

в соседнем терминале id, getent ...
он нормально работает кэширует

но стоит мне отключить сервер - не возможно войти в систему ldap
пользователем.

Вообще-то, для серьёзных задач должно быть несколько ldap серверов.
Выкрутиться, конечно, можно с помощью libpam-ccreds как уже говорили.

так как система его не видит, т.е. команда getent passwd вывод только
локальных пользователей.

Удачи.

Alex

спасибо

Re: DBus

2013-05-27 Пенетрантность Покотиленко Костик

В Суб, 25/05/2013 в 09:58 +0400, Konstantin Matyukhin пишет:
 On Sat, May 25, 2013 at 4:57 AM, Жанибек Нагашыбай
 njm.ja...@yandex.ru wrote:
 В Sat, 25 May 2013 00:50:41 +0400
 Dmitrii Kashin free...@gmail.com пишет:
 
  Вопрос же про dbus продолжает быть открытым.
 
 
 А чем же он Вам так не угодил?
 
 
 Вероятно, неочевидностью его преимуществ.

Преимуществ перед чем? Перед другой шиной обмена сообщениями? Какой?



-- 
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/1369648977.7864.12.ca...@casper-hp.friendin.net

Re: DBus

2013-05-27 Пенетрантность Покотиленко Костик

В Пнд, 27/05/2013 в 15:55 +0400, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 27 May 2013
13:02:57 +0300:

Вопрос же про dbus продолжает быть открытым.

А чем же он Вам так не угодил?

Вероятно, неочевидностью его преимуществ.

ПК Преимуществ перед чем? Перед другой шиной обмена сообщениями? Какой?

Unix socket, TCP socket, pipe, file, environment (да, переменные
окружения - это тоже шина обмена сообщениями, хотя и односторонняя).
Да, у каждой из них есть свои недостатки, которые часто являются
продолжением достоинств, но вот Unix socket, кажется, DBus'у не уступает
уже ни в чем. А во внятности существенно превосходит.

И как у нас там, кстати, в DBus c совмещением ожидания со, скажем,
stdin/stdout или с TCP?

DBus - это более высокого уровня шина нежели те что Вы перечислили.

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-30 Пенетрантность Покотиленко Костик

В Пнд, 29/04/2013 в 23:12 +0400, Dmitry-T пишет:
 Доброго времени суток!
 
  On Mon, Apr 29, 2013 at 06:27:12PM +0300, Покотиленко Костик wrote:
через неделю wheezy можно будет нормально пользоваться, вопрос
закрыт,
подожду
А вы не задумывались, что происходит в банке с консервами в ночь,
когда истекает срок хранения?
   
   Загадками Вы все разговариваете.
  Загадками здесь разговариваете вы.
  
   Кто сидел на тестинг - можете поделиться впечатлениями. Я когда-то
   немного сидел и мне не понравилось, но это *мне* и *когда-то*
  Повторяю вопрос: что такого случается с тестингом в момент релиза, что он
  внезапно становится юзабельным?
 
 Аналогия про консервы неточная. Для одного человека тестинг не будет
 отличаться от стабильного, а для другого будет.
 
 Перед переименованием тестируемого в стабильный начинают резко
 перетряхивать пакеты на предмет соответствия всем требованиям и если
 пакет не успевают доделать, то просто исключают. И эта неприятность, но
 уже по каким-то частным причинам, может произойти во всех ветках кроме
 стабильной. Поэтому я в своё время переодически поплевавшись использую
 по возможности стабильный Дебиан, лишь ради экономии своего времени.
 Это лишь мой подход, у меня хватает задач и я стараюсь максимально
 сокращать непредвиденные ситуации.

Поддерживаю такой подход, и сам придерживаюсь. 



-- 
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/1367308646.4823.39.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-30 Пенетрантность Покотиленко Костик

В Вто, 30/04/2013 в 01:05 +0400, Dmitrii Kashin пишет:
 At Mon, 29 Apr 2013 23:12:32 +0400,
 Dmitry-T wrote:
  
  Перед переименованием тестируемого в стабильный начинают резко
  перетряхивать пакеты на предмет соответствия всем требованиям и если
  пакет не успевают доделать, то просто исключают.
 
 Извините, но я как-то считал, что testing просто переименовывают в
 stable, когда все (или почти все) release-critical bugs устранены.
 
 Меня терзают смутные сомнения, что перед релизом все 30k+ пакетов
 начинают перетряхивать. Приведте пожалуйста ссылку.

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



-- 
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/1367308765.4823.41.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-30 Пенетрантность Покотиленко Костик

В Пнд, 29/04/2013 в 21:49 +0600, sysad...@ruta.ru пишет:
Константин, я работаю в sid. Рабочие станции пользователей также
собраны из этого релиза. Начиная с woody sid самое то. Это конечно мое
личное мнение, но сломать систему у меня получается только
подключив экспериментальную ветку. Это всё касаемо рабочих станций.
Я не против почитать чей-то негативный опыт работы в testing и sid,
так как у меня и моих знакомых такого опыта нет.

З.Ы. Стабильная версия вообще никак не подходит для пользовательских
систем. Опять же это личное мнение =)

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

Всем спасибо за отзывы.

29 апреля 2013 г., 21:27 пользователь Покотиленко Костик
cas...@meteor.dp.ua написал:
В Пнд, 29/04/2013 в 14:34 +0400, Konstantin Matyukhin пишет:
2013/4/29 Покотиленко Костик cas...@meteor.dp.ua
через неделю wheezy можно будет нормально
пользоваться, вопрос
закрыт,
подожду
А вы не задумывались, что происходит в банке с консервами в
ночь,
когда истекает срок хранения?

Загадками Вы все разговариваете.
Кто сидел на тестинг - можете поделиться впечатлениями. Я
когда-то
немного сидел и мне не понравилось, но это *мне* и *когда-то*

P.S. Обычно перехожу на следующий стейбл через пару месяцев
после релиза

--
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/1367249232.4823.20.ca...@casper-hp.friendin.net

--
Мечётный Виталий
Старший системный администратор
г. Екатеринбург
mob: +7 963 440 06 01
e-mail: sysad...@ruta.ru

Re: samba 3 или samba 4

2013-04-29 Пенетрантность Покотиленко Костик

В Срд, 24/04/2013 в 10:56 +0600, Andrey Rahmatullin пишет:
 On Wed, Apr 24, 2013 at 10:11:43AM +0600, Stanislav Vlasov wrote:
 Подскажите пожалуйста. Компьютеров 20 штук все под линуксом. Сервер
   тоже
 под линукс. Т.е. windows не пахнет.
Я Вам сейчас один умный вещь скажу, только Вы не обижайтес (с)
Если windows-ом не пахнет, то нахуа Вам samba? Хоть третья, хоть
   четвертая.
   Ну не нфсом-же шарить.
  Хм... А почему бы и не, собственно? :-)
 На мой непрофессиональный взгляд нфс ужасен.

Он неМного не для пользовательских шар.



-- 
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/1367229189.4823.3.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-29 Пенетрантность Покотиленко Костик

В Вто, 23/04/2013 в 17:11 +0600, Andrey Rahmatullin пишет:
 On Tue, Apr 23, 2013 at 03:06:39PM +0400, Mikhail A Antonov wrote:
  23.04.2013 14:57, Andrey Rahmatullin пишет:
   On Tue, Apr 23, 2013 at 01:45:06PM +0300, Покотиленко Костик wrote:
   Подождём wheezy...
   Так им нельзя нормально пользоваться.
  
  Да линуксом вообще нельзя нормально пользоваться!
 Так я потому и спросил.

через неделю wheezy можно будет нормально пользоваться, вопрос закрыт,
подожду.


-- 
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/1367229437.4823.5.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-29 Пенетрантность Покотиленко Костик

В Пнд, 29/04/2013 в 14:34 +0400, Konstantin Matyukhin пишет:
 2013/4/29 Покотиленко Костик cas...@meteor.dp.ua
 через неделю wheezy можно будет нормально пользоваться, вопрос
 закрыт,
 подожду
 А вы не задумывались, что происходит в банке с консервами в ночь,
 когда истекает срок хранения?

Загадками Вы все разговариваете.
Кто сидел на тестинг - можете поделиться впечатлениями. Я когда-то
немного сидел и мне не понравилось, но это *мне* и *когда-то*

P.S. Обычно перехожу на следующий стейбл через пару месяцев после релиза


-- 
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/1367249232.4823.20.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-23 Пенетрантность Покотиленко Костик

В Пнд, 22/04/2013 в 18:38 +0600, Andrey Rahmatullin пишет:
 On Mon, Apr 22, 2013 at 03:25:29PM +0300, Покотиленко Костик wrote:
Не подскажете как меньшей кровью получить 2D/3D ускорение на Ivy Bridge
Graphics Controller (8086:0152 Intel Core i3-3220, 3 поколение)?
   Зачем вы ставите на это сквиз?
  Что посоветуете?
 wheezy.

Им уже можно нормально пользоваться?


-- 
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/1366698837.10305.8.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-23 Пенетрантность Покотиленко Костик

В Вто, 23/04/2013 в 12:46 +0600, Andrey Rahmatullin пишет:
 On Tue, Apr 23, 2013 at 09:33:57AM +0300, Покотиленко Костик wrote:
  Не подскажете как меньшей кровью получить 2D/3D ускорение на Ivy 
  Bridge
  Graphics Controller (8086:0152 Intel Core i3-3220, 3 поколение)?
 Зачем вы ставите на это сквиз?
Что посоветуете?
   wheezy.
  Им уже можно нормально пользоваться?
 Нет, а чего вы ждали?

Я ждал подходящий драйвер в backports для squeeze, но пока не судьба.
Подождём wheezy...


-- 
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/1366713906.10305.169.ca...@casper-hp.friendin.net

Squeeze: Ivy Bridge Graphics Controller

2013-04-22 Пенетрантность Покотиленко Костик

Привет,

Не подскажете как меньшей кровью получить 2D/3D ускорение на Ivy Bridge
Graphics Controller (8086:0152 Intel Core i3-3220, 3 поколение)?

xorg 1:7.6+8~bpo60+1, xserver-xorg-video-intel 2:2.15.0-3~bpo60+2
говорят что такого не знают :(

Как вообще узнать в какой версии появилась поддержка?


-- 
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/1366621131.10305.6.ca...@casper-hp.friendin.net

Re: Squeeze: Ivy Bridge Graphics Controller

2013-04-22 Пенетрантность Покотиленко Костик

В Пнд, 22/04/2013 в 15:00 +0600, Andrey Rahmatullin пишет:
 On Mon, Apr 22, 2013 at 11:58:51AM +0300, Покотиленко Костик wrote:
  Не подскажете как меньшей кровью получить 2D/3D ускорение на Ivy Bridge
  Graphics Controller (8086:0152 Intel Core i3-3220, 3 поколение)?
 Зачем вы ставите на это сквиз?

Что посоветуете?



-- 
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/1366633529.10305.7.ca...@casper-hp.friendin.net

Re: smartmontools: виснет short-self test а вместе с ним и сервак

2012-12-09 Пенетрантность Покотиленко Костик

В Суб, 08/12/2012 в 16:24 +0600, Andrey Rahmatullin пишет:
 On Sat, Dec 08, 2012 at 09:58:18AM +0200, Покотиленко Костик wrote:
  Через сколько времени можно жаловаться на мейнтейнера?
 Кому и за что?

За то что нет никакого ответа за 2 недели. Да, дело не в жаловаться,
разобраться надо, а то проблемы реальные.

Никогда такого не было, не знаю куда рыть...


-- 
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/1355058474.6076.2.ca...@casper-hp.friendin.net

smartmontools: виснет short-self test а вместе с ним и сервак

2012-12-07 Пенетрантность Покотиленко Костик

Кто-нибудь сталкивался с проблемой когда short-test smartctl виснет на
90% и при этом винты жутко тупят? 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694315

Через сколько времени можно жаловаться на мейнтейнера?



-- 
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/1354953498.31755.4.ca...@casper-hp.friendin.net

Re: SAS DP + Lustre

2009-03-30 Пенетрантность Покотиленко Костик

В Птн, 27/03/2009 в 10:01 -0400, Nicholas пишет:
 Покотиленко Костик wrote:
  Задача: построить серверную ферму с полным дублированием 
 
 Возможно в тему:
 http://hadoop.apache.org/core/
 насколько я понял, это свободный форк Гугл фс/cpu,
 тоже интересно услышать о практическом использованиии.

Вроде не то совсем, во первых это для распределения специфических
вычислений, во вторых это Java.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: сломали libgtk2.0-0=2.14.7-4+b1?

2009-03-27 Пенетрантность Покотиленко Костик

В Птн, 27/03/2009 в 11:59 +0200, Andrey Tataranovich пишет:
 Есть предположение что в libgtk2.0-0=2.14.7-4+b1 сломали работу некоторый 
 приложений с
 png иконками. В pidgin 2.5.5-1 часть иконок отображается крестиком на белой 
 иконке. При
 этом часть иконок из темы отображается нормально. С pidgin помого откат 
 libgtk на 2.12.11-4.
 
 У остальных как?

У меня pidgin нормально, на Lenny.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Проблема с OpenVPN после смены провайдера

2009-03-24 Пенетрантность Покотиленко Костик

В Вто, 24/03/2009 в 12:01 +0300, Alexander Tiurin пишет:

24 марта 2009 г. 11:31 пользователь Artem Chuprina r...@ran.pp.ru
написал:
Alexander Tiurin - debian-russian@lists.debian.org @ Tue, 24
Mar 2009 10:39:34 +0300:

AT Пытаюсь разобраться в ситуации с целью понять: проблема
связана со сменой
AT провайдера, с особенностью tesning ветки дистрибутива или
с кривизной моих
AT рук.
AT Хотя на предыдущем провайдере (пару недель назад) все
работало без проблем.

AT Суть.
AT С помощью впн соединяюсь с офисом.
AT Поднимал впн соединение, прописывал маршрут
AT ip r a 192.168.1.0/24 dev tun0
AT Получал доступ офисным машинам.

AT Сейчас проделываю то же самое, но доступа нет. Ипы из
сетки
AT 192.168.1.0/24не пингуются.
AT Таблица маршрутов выглядит так

AT До поднятия впн

AT 10.10.9.56 via 10.16.64.1 dev eth0 src 10.16.102.219
AT 212.1.254.49 dev ppp0 proto kernel scope link src
79.111.85.14
AT 212.1.226.0/24 via 10.16.64.1 dev eth0
AT 212.1.224.0/24 via 10.16.64.1 dev eth0
AT 212.1.224.0/23 via 10.16.64.1 dev eth0
AT 10.16.64.0/18 dev eth0 proto kernel scope link src
10.16.102.219
AT 192.168.0.0/16 via 10.16.64.1 dev eth0
AT 10.0.0.0/8 via 10.16.64.1 dev eth0
AT default dev ppp0 scope link
AT Эти маршруты получаю от провайдера.

AT После поднятия впн, я удаляю маршрут 192.168.0.0/16 via
10.16.64.1 dev
AT eth0 и добавляю ip r a 192.168.1.0/24 dev tun0.
AT Таблица маршрутов получается
AT 10.10.9.56 via 10.16.64.1 dev eth0 src 10.16.102.219
AT 172.30.30.13 dev tun0 proto kernel scope link src
172.30.30.14
AT 212.1.254.49 dev ppp0 proto kernel scope link src
79.111.85.14
AT 172.30.30.1 via 172.30.30.13 dev tun0

AT 192.168.1.0/24 dev tun0 scope link

Этим ты пишешь, что 192.168.1.0/24 находится в прямой досягаемости по
tun0 БЕЗ маршрутизации. Я бы понял если бы это был tap0 или доступ нужен
был бы только до адреса противоположной стороны. Вот он наверно и шлёт
arp а в ответ тишина.

ip route add 192.168.1.0/24 via адрес той стороны dev tun0

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Скорость чтения с диска последовательно одним процессом VS параллельно несколькими

2009-03-24 Пенетрантность Покотиленко Костик

В Вто, 24/03/2009 в 11:04 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Monday 23 March 2009 21:12:32 Покотиленко Костик wrote:
  Для меня остаётся 2 загадки, почему при использовании 2х ядер такой
  маленький прирост 22.3% скорости, почему при 4х потоках на 2х ядрах
  скорость всё ещё увеличивается.
 
 Судя по приведенным цифрам, вы файлы только считываете и результат никуда не 
 передаете. Стоит хотя бы в stdout из дочерних потоков выводить, а из 
 родительского забирать. Ситуация с чтением без обработки и вывода данных 
 весьма неестественна.

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

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Скорость чтения с диска последовательно одним процессом VS параллельно несколькими

2009-03-23 Пенетрантность Покотиленко Костик

В Суб, 21/03/2009 в 17:04 +0300, Alexey Pechnikov пишет:
Hello!

On Friday 20 March 2009 13:02:27 Покотиленко Костик wrote:
О тесте: программа рекурсивно сканирует указанный каталог и составляет
список обычных файлов, затем делит этот список на N частей. Далее
программа создаёт N клонов с помощью fork(), каждый из которых читает
файлы из своей части списка. По окончанию работы каждого клона выводится
его статистика.

Необходимо оценить средний размер файла. Пусть это будет 8 кБ согласно
паттерну работы с БД. Примечание: если реальные файлы больше, но запросов
много, то с диска они все равно будут читаться блоками, кратно 4 кБ (по
дефолту для ext3).

1. Необходимо обращаться к рандомному файлу. Каждый поток должен работать с
полным списком, случайным образом выбирая файл для чтения. Примечание: если
вы
посмотрите паттерны доступа от интел, то увидите, что для моделирования
работы
с БД и файлсервера предполагается именно 100% рандомный доступ (в первом
приближении стоит начинать именно с этого варианта). Учет этого фактора
незначительно ускорит многопоточное чтение.

2. Необходимо учесть популярность файлов - большинство обращений происходит
к одним и тем же файлам. Используйте гауссово распределение. Учет этого
фактора значительно оптимизирует работу файлового кэша и многократно ускорит
многопоточное чтение (в зависимости от параметров распределения). Это будет
второе приближение.

В случаях, когда кэш эффективен нет разницы параллельно читать или
последовательно.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Скорость чтения с диска последовате льно одним процессом VS параллельно несколькими

2009-03-23 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 12:02 +0200, Покотиленко Костик пишет:
 Штатных утилит делающих подобное не нашёл, ткните, наверняка проглядел.
 Не поленился написать данный тест. Первая версия и результат её работы
 на моей системе выложены, ссылки внизу.
 
 О тесте: программа рекурсивно сканирует указанный каталог и составляет
 список обычных файлов, затем делит этот список на N частей. Далее
 программа создаёт N клонов с помощью fork(), каждый из которых читает
 файлы из своей части списка. По окончанию работы каждого клона выводится
 его статистика. 
 
 Кому интересно можете провести тест на свой страх и риск на своём
 железе, результат сравним.
 
 1. По результату: при моих параметрах тестирования чтение
 последовательно одним процессом быстрее, но не намного.
 
 2. Параметры тестирования:
 - каталог:   /usr/src
 - ФС:ext3 (Всего: 9,2G; Занято: 6,8G)
 - файлов в списке:   254794
 - подкаталогов:  23003
 - максимальные уровень вложенности:  12 (maxrec)
 - проц:  C2D ~2GHz
 - память:1Гб (около 300Мб свободно/кэш)
 - контроллер:Intel® ICH10
 - винт:  WDC WD5000AAKS-00YGA0
 http://www.xard.ru/post/11716/default.asp
 
 Беглое гугление показало, не факт что NCQ включён и работает:
 http://blog.kovyrin.net/2006/08/11/turn-on-ncq-on-ich-linux/lang/ru/
 Кто-нибудь в курсе статуса NCQ в Debian?
 
 # hdparm -Tt /dev/sda
 
 /dev/sda:
  Timing cached reads:   5886 MB in  2.00 seconds = 2945.75 MB/sec
  Timing buffered disk reads:  238 MB in  3.04 seconds =  78.40 MB/sec
 
 #uname -a 
 Linux casper 2.6.24-etchnhalf.1-686 #1 SMP Fri Dec 26 04:10:16 UTC 2008
 i686 GNU/Linux
 
 остальное в pdf.
 
 3. Точность:
 - программа тупо делит список на равное количество записей, размеры
 файлов не учитываются, поэтому одним клонам достаётся больше чем другим,
 они работают дольше и остаток времени работают с меньшим числом
 конкурентов, что на мой взгляд увеличивает общую скорость. Во вложенных
 результатах в тесте с 4-мя потоками 4-му досталась половина всего
 объёма. Это особенности распределения файлов по моему /usr/src.
 - для каждого числа потоков было проведено 3 эксперимента, учитывались
 средние значения.
 - в программе учитывается только время на чтение файлов по списку, и не
 учитывается время на его создание и другие операции.
 - не понятно работал ли NCQ.
 - перед тестами я не сбрасывал кэш ФС, на объёме ~1.3 Гб он не
 эффективен, это видно из тестов.
 - на мой взгляд данный тест производит нагрузку похожую на ту, что
 создаёт apache2 при соизмеримых количествах клиентов (потоков) и
 запросов.
 
 
 http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz
 http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods
 http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf

По ходу дела хочу отметить тот факт, что в этой рассылке процветает
демагогия, а когда дело доходит до дела...

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-23 Пенетрантность Покотиленко Костик

В Пнд, 23/03/2009 в 18:26 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
13:50:42 +:

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Если не увлекаться вызовом malloc() inline, а каждый объект
ПК делать набор функций create, destroy и т.д. то это не много и
ПК оправдано. Кстати, разделяя функционал от интерфейса и выделив
ПК библиотеку, так даже проще.

Любая попытка выделить память может закончиться неудачей. И
называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

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

ПК Что значит успело выделиться? Само оно не выделяется, по крайней
ПК мере в Си.

На примере gtk.

Как ты создаешь композитный виджет? Создаешь внутренние, и делаешь им
add. По очереди. Если у тебя обломалость по недостатку памяти создание
второго внутреннего виджета, ты перед возвратом должен только прибить
внешний. А вот если обломался его add, то удаления внешнего для
освобождения памяти внутреннего недостаточно - он же не добавился. Надо
его destroy вручную. И так с каждым.

Вопрос интересный:
void gtk_container_add(...);
void gtk_box_pack_start (...);
void gtk_table_attach(...);

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

С другой стороны, даже если добавление обломается, ты об этом узнаешь
через вывод GTK-WARNING:... что при тестировании вылазит сразу.

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

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

А, ты предпочитаешь просто забить на утечки памяти?

Ни в коем случае.

ПК Мне, например, не нравится как такие ситуации отработал
ПК spamassassin написанный на perl. Смотри тред OOM-Killer. С
ПК perl'ом даже OOM-Killer не справился.

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

ПК Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК делать.

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

Это вопрос логики, просто на perl'е проверки вообще суть не популярная,
если они там хотя бы есть в достаточном количестве.

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том, что
C из своей ниши вылазит...

ПК Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК клиентские, десктопные приложения, и т.д.

То-то у меня ipw2200 не работает больше полутора суток, firefox через
неделю работы приходится прибивать kill -9, потому что на штатное
завершение ему получаса не хватает, а у тебя snmpd жрет 10% CPU...

Молодец, перечислил все 3 корявые программы на Си :)

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

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

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

ПК А это как?

command
if [[ $? == ... ]]; then
...
fi

И т.п. Это если как писать. Если когда оправдано - вместо пайпов
использовать временные файлы, потому что классический sh умеет вернуть
код только последней команды в пайпе, успех завершения остальных
проверить невозможно. В bash или zsh можно, но тоже очень
небесплатно... (На самом деле сейчас придет Чеусов и скажет, что на
классическом sh тоже можно - но ты попроси его тогда этот код показать,
он у него, кажется, есть...)

ПК Иногда приходится и так писать. Спорить не буду, на perl' было бы легче.

На перле

Re: Функционал и интерфейс

2009-03-23 Пенетрантность Покотиленко Костик

В Пнд, 23/03/2009 в 18:56 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
15:53:25 +0200:

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

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

Кстати, хинт: если твоя сишная программа работает в линуксе из-под
непривелигированного юзера, управление памятью от тебя уже не
зависит...

ПК Мы что про разные управления памятью говорим?

Нет. Я просто смотрю на шаг дальше. Когда зависит от управления
памятью - речь идет об управлении _физической_ памятью.
Непривелигированный процесс к управлению физической памятью в линуксе
никто не допустит. Так что от его автора в управлении _интересной_
памятью ничего не зависит. Ну, почти ничего...

ПК Не понимаю, можно подробнее? Что такое _интересная_ и _физическая_
ПК память и как ими можно управлять из-под root'а?

Если не понимаешь, то лучше возьми назад свои вышепроцитированные слова,
и давай лучше на этом закончим... Интересная - это та, от эффективности
управления которой что-то зависит. Физическая - это, натурально, RAM, в
противовес виртуальной, которая в линуксе в лучшем случае RAM+swap, в
промежуточном - virtual RAM :-) + virtual swap, а в худшем вообще не
существует (т.е. malloc(2) завершится успешно, а при попытке туда
написать тебе пришлют sig11). У рута на хост-системе есть возможность
запросить именно физическую память, а у обычного пользователя или у
процесса в виртуалке - нету... А от эффективности управления
виртуальной памятью в твоем процессе, извини, не зависит почти ничего.

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

Я говорил о удобстве в Си управлять сложно связанными структурами.

Не, немножко зависит. За что _знающие_ люди perl и недолюбливают.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Скорость чтения с диска последовательно одним процессом VS параллельно несколькими

2009-03-23 Пенетрантность Покотиленко Костик

Проверяем чтение с использованием кэша (прокэшировано ~100%) на моем
каталоге /lib/modules:

# du -sh /lib/modules
365M/lib/modules

Погонял несколько предварительный тестов пока прокэшировалось и скорость стало 
показывать стабильно.

Проверяем для одного потока:
 ./simreadtest /lib/modules -n 1
...
CHILD00: printing results:
files: 12890
bytes: 340750735
speed: 1893669821 bytes/sec
time usecs: 179942
...

Получаем скорость: 1806Мб/с, время: 0.179942с


Проверяем для двух потоков:
 ./simreadtest /lib/modules -n 2
...
CHILD01: printing results:
files: 6445
bytes: 163305639
speed: 1485055735 bytes/sec
time usecs: 109966
...
CHILD00: printing results:
files: 6445
bytes: 177445096
speed: 1206182295 bytes/sec
time usecs: 147113
...

Получаем суммарную скорость: 2209Мб/с, время: 0.147113с

Итого: на моей машине 2 ядра, при использовании 2х потоков общая скорость 
увеличилась на (2209-1806)/1806=22.3%, скорость на ядро уменьшилась на 
(1806-2209/2)/1806=38.8%


Проверяем для четырёх потоков:
 ./simreadtest /lib/modules -n 4
...
CHILD04: printing results:
files: 2
bytes: 1460
speed: 42941176 bytes/sec
time usecs: 34
...
CHILD03: printing results:
files: 3222
bytes: 85661152
speed: 921097560 bytes/sec
time usecs: 92999
...
CHILD02: printing results:
files: 3222
bytes: 77683236
speed: 924283270 bytes/sec
time usecs: 84047
...
CHILD00: printing results:
files: 3222
bytes: 95082054
speed: 1469288303 bytes/sec
time usecs: 64713
...
CHILD01: printing results:
files: 3222
bytes: 82322833
speed: 704312249 bytes/sec
time usecs: 116884
...

Получаем суммарную скорость: 2780Мб/с, время: 0.116884с

Итого: на моей машине 2 ядра, при использовании 4х(5ти) потоков общая скорость 
увеличилась на (2780-1806)/1806=53.9%, скорость на ядро уменьшилась на 
(1806-2780/4)/1806=61.5% относительно одного потока.

Вывод: При ~100% эффективности кэша скорость чтения растёт с увеличением 
количества потоков даже превышающих количество реальных ядер, но растёт сильно 
не линейно.


В Пнд, 23/03/2009 в 18:21 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Monday 23 March 2009 12:03:05 Покотиленко Костик wrote:
   http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz
   http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods
   http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf
 
  По ходу дела хочу отметить тот факт, что в этой рассылке процветает
  демагогия, а когда дело доходит до дела...
 
 А где у вас дело? Есть стандартные паттерны использования диска, вы их даже 
 не 
 смотрели. 

Гляну позже. Если дашь ссылку, буду благодарен.

 Средняя скорость чтения в 13 Мб/с это полная ерунда. Реально 
 получается в разы быстрее.

Для небольших непрокэшированных файлов это как раз та скорость. На
больших она приближается к скорости линейного чтения, той, что hdparm -t
показывает.

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

Что-то не помню чтобы я такое заявлял. Я говорил, что в тех тестах,
которые я делал, кэш оказался не эффективен. Напомню, что файлы читались
последовательно, каждый один раз. Суммарный объём в несколько раз больше
кэша, поэтому он был не эффективен.

Напомню ещё, что изначально в этой теме речь шла о чтении с диска, может
я зря не дописал, но имелось в виду именно с диска, без кэша ФС.

И, получается, да, я был не прав считая, что увеличение количества потоков
не увеличит скорость чтения при 100%-ой эффективности кэша.

Для меня остаётся 2 загадки, почему при использовании 2х ядер такой маленький 
прирост 22.3% скорости, почему при 4х потоках на 2х ядрах скорость всё ещё 
увеличивается.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Скорость чтения с диска последовательно одним процессом VS параллельно несколькими

2009-03-23 Пенетрантность Покотиленко Костик

В Пнд, 23/03/2009 в 20:12 +0200, Покотиленко Костик пишет:
 Проверяем чтение с использованием кэша (прокэшировано ~100%) на моем
 каталоге /lib/modules:
 
 # du -sh /lib/modules
 365M/lib/modules
 
 Погонял несколько предварительный тестов пока прокэшировалось и скорость 
 стало показывать стабильно.
 
 Проверяем для одного потока:
  ./simreadtest /lib/modules -n 1
 ...
 CHILD00: printing results:
 files: 12890
 bytes: 340750735
 speed: 1893669821 bytes/sec
 time usecs: 179942
 ...
 
 Получаем скорость: 1806Мб/с, время: 0.179942с
 
 
 Проверяем для двух потоков:
  ./simreadtest /lib/modules -n 2
 ...
 CHILD01: printing results:
 files: 6445
 bytes: 163305639
 speed: 1485055735 bytes/sec
 time usecs: 109966
 ...
 CHILD00: printing results:
 files: 6445
 bytes: 177445096
 speed: 1206182295 bytes/sec
 time usecs: 147113
 ...
 
 Получаем суммарную скорость: 2209Мб/с, время: 0.147113с
 
 Итого: на моей машине 2 ядра, при использовании 2х потоков общая скорость 
 увеличилась на (2209-1806)/1806=22.3%, скорость на ядро уменьшилась на 
 (1806-2209/2)/1806=38.8%
 
 
 Проверяем для четырёх потоков:
  ./simreadtest /lib/modules -n 4
 ...
 CHILD04: printing results:
 files: 2
 bytes: 1460
 speed: 42941176 bytes/sec
 time usecs: 34
 ...
 CHILD03: printing results:
 files: 3222
 bytes: 85661152
 speed: 921097560 bytes/sec
 time usecs: 92999
 ...
 CHILD02: printing results:
 files: 3222
 bytes: 77683236
 speed: 924283270 bytes/sec
 time usecs: 84047
 ...
 CHILD00: printing results:
 files: 3222
 bytes: 95082054
 speed: 1469288303 bytes/sec
 time usecs: 64713
 ...
 CHILD01: printing results:
 files: 3222
 bytes: 82322833
 speed: 704312249 bytes/sec
 time usecs: 116884
 ...
 
 Получаем суммарную скорость: 2780Мб/с, время: 0.116884с
 
 Итого: на моей машине 2 ядра, при использовании 4х(5ти) потоков общая 
 скорость увеличилась на (2780-1806)/1806=53.9%, скорость на ядро уменьшилась 
 на (1806-2780/4)/1806=61.5% относительно одного потока.
 
 Вывод: При ~100% эффективности кэша скорость чтения растёт с увеличением 
 количества потоков даже превышающих количество реальных ядер, но растёт 
 сильно не линейно.
 
 
 В Пнд, 23/03/2009 в 18:21 +0300, Alexey Pechnikov пишет:
  Hello!
  
  On Monday 23 March 2009 12:03:05 Покотиленко Костик wrote:
http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz
http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods
http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf
  
   По ходу дела хочу отметить тот факт, что в этой рассылке процветает
   демагогия, а когда дело доходит до дела...
  
  А где у вас дело? Есть стандартные паттерны использования диска, вы их даже 
  не 
  смотрели. 
 
 Гляну позже. Если дашь ссылку, буду благодарен.
 
  Средняя скорость чтения в 13 Мб/с это полная ерунда. Реально 
  получается в разы быстрее.
 
 Для небольших непрокэшированных файлов это как раз та скорость. На
 больших она приближается к скорости линейного чтения, той, что hdparm -t
 показывает.
 
   Почему - я отписался в предыдущем письме. Вы же, 
  вместо того чтобы проверить, абсолютно ошибочно заявляете, что кэш не 
  влияет 
  на многопоточное чтение (хотя его в основном для многопоточного чтения и 
  сделали).
 
 Что-то не помню чтобы я такое заявлял. Я говорил, что в тех тестах,
 которые я делал, кэш оказался не эффективен. Напомню, что файлы читались
 последовательно, каждый один раз. Суммарный объём в несколько раз больше
 кэша, поэтому он был не эффективен.
 
 Напомню ещё, что изначально в этой теме речь шла о чтении с диска, может
 я зря не дописал, но имелось в виду именно с диска, без кэша ФС.
 
 И, получается, да, я был не прав считая, что увеличение количества потоков
 не увеличит скорость чтения при 100%-ой эффективности кэша.


 Для меня остаётся 2 загадки, почему при использовании 2х ядер такой маленький 
 прирост 22.3% скорости, почему при 4х потоках на 2х ядрах скорость всё ещё 
 увеличивается.

Кажется я их разгадал, для упрощения я не привёл времена стартов клонов,
вот они:

...
CHILD04: printing results:
start time: 123782.955115
end time: 123782.955149
...

...
CHILD03: printing results:
start time: 123782.955312
end time: 123783.48311
...

...
CHILD02: printing results:
start time: 123782.979149
end time: 123783.63196
...

...
CHILD00: printing results:
start time: 123783.48590
end time: 123783.113303
...

...
CHILD01: printing results:
start time: 123783.4289
end time: 123783.121173
...

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

P.S. в start|end time после точки стоит время в микросекундах, там
пропущены предшествующие нули.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-23 Пенетрантность Покотиленко Костик

В Вто, 24/03/2009 в 00:04 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 23 Mar 2009
18:43:52 +0200:

И на каждое выделение памяти. Вверх по всему стеку вызовов.

ПК Если не увлекаться вызовом malloc() inline, а каждый объект
ПК делать набор функций create, destroy и т.д. то это не много и
ПК оправдано. Кстати, разделяя функционал от интерфейса и
выделив
ПК библиотеку, так даже проще.

Любая попытка выделить память может закончиться неудачей. И
называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во
всех
книжках по C++ - что будет, если ошибка произойдет в момент,
когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

ПК Что значит успело выделиться? Само оно не выделяется, по крайней
ПК мере в Си.

На примере gtk.

ПК Вопрос интересный:
ПК void gtk_container_add(...);
ПК void gtk_box_pack_start (...);
ПК void gtk_table_attach(...);

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

Мое мнение о том, что реально добавить, с мнением автора библиотеки
может и не совпасть... Ну, не знаю, конкретно в gtk, может, и
гарантированно добавляет без ошибок. Но в питоне оно у меня ухитрялось
отваливаться. Ага, по assert'у. Типа мы ошибок не возвращаем, если
что не так - мы рушим нах всю программу. Тоже, конечно, вариант. Так
firefox и падает.

ПК С другой стороны, даже если добавление обломается, ты об этом узнаешь
ПК через вывод GTK-WARNING:... что при тестировании вылазит сразу.

Судя по количеству срача, которое сыплет в исходный терминал firefox,
его авторы научились обходить эту проблему :-)

ПК Один раз, потом верну ошибку назад по стеку, там пусть решают что
ПК делать.

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

ПК Это вопрос логики, просто на perl'е проверки вообще суть не
ПК популярная, если они там хотя бы есть в достаточном количестве.

Не на перле, а у криворуких программистов. На C они тоже не любят
ничего проверять. Это типа сложно...

ПК У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Не вопрос. Она у него даже малость поуже, чем у C. Проблема в том,
что
C из своей ниши вылазит...

ПК Посмотрим что успешно пишут на Си: драйвера, демоны, серверные,
ПК клиентские, десктопные приложения, и т.д.

ПК Молодец, перечислил все 3 корявые программы на Си :)

Нет, первые 3, пришедшие в голову, так, чтобы более-менее покрывали
приведенные тобой категории.

На perl'е я боюсь 3-х хороших не вспомню. Я их наверно просто не знаю.

ПК Я тебе на это скажу так: высокоуровневым/скриптовым языкам
ПК легко/быстро учиться, на них легко/быстро написать первую
ПК версию. Их программисты очень часто этим и ограничиваются. А когда
ПК начинаешь дорабатывать, писать обработки различных ситуаций, тогда
ПК сложность и затраченное время уравнивается.

Не надо мне на это так говорить. Я - пробовал. Конкретно на перле. Ни
разу не уравнивается. Разница, конечно, становится поменьше - за счет

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
23:00:22 +0200:

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free() было бы
совсем хреново. Но с ними - просто хреново, а не хорошо. Ну разве
что
слаще репы не едал...

ПК У меня такое бывает редко, а когда бывает - заварю чаю и почитаю
ПК кто кого освобождает а кто кого нет, сравню с кодом и всё готово,
ПК делов-то 20 минут.

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

ПК Это культура программирования, _этому_ учиться надо.

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

Слушай, давай на примерах? А то как-то размыто. Я буду рад признать, что
Си неэффективен, если наглядно покажешь.

А потом - ты valgrind на свои программы часто натравливаешь?

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

А ты натрави. Имеешь шанс узнать что-нибудь интересное...

Наверняка узнаю некоторое количество неучтённых мелочей. Крупные leaks
видно сразу, а те того может и не стоят.

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Любая попытка выделить память может закончиться неудачей. И называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

Если ты программист Си - решать тебе что будет. Мне, например, не
нравится как такие ситуации отработал spamassassin написанный на perl.
Смотри тред OOM-Killer. С perl'ом даже OOM-Killer не справился.

ПК Мне нравится с годами углубляться в один и тот же язык, чем
ПК с каждым годом изучать их больше. На Си можно сделать всё,
ПК а тебе видимо приходится слазить с Тикля иногда.

ПК Вопрос удобства можно обсудить, очень интересно.

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

ПК Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
ПК shell. Perl, конечно, было бы круто знать, что иногда
ПК использовать вместо shell, но мне лень его изучать, я на Си не
ПК на много медленее напишу.

Если писать на перле как на C, то да, на C ненамного медленнее
получится. Вот только те, кто изучает не языки, а программирование,
на перле пишут по-другому. Как на перле :-) И C сразу начинает
отставать если не в сотни раз, то в десятки уж точно.

ПК В это мне тяжело въехать.

Тяжело въехать в перловый способ программирования, тяжело понять любой
способ программирования, отличный от однажды выученного, или тяжело
поверить, что однажды выученный не является единственным?

1. Я не говорил, что на Perl ничего не писал, просто ничего серьёзного
не писал. А в способ я въехал.
2. Способ программирования в основном от языка не зависит, и нет, не
тяжело понимать новые, даже нравится, если видно где они эффективнее.
3. Я не в религиозном кружке чтобы просто так поверить в то или иное.

У Perl'а своя ниша, и он хорош пока от туда не вылазит.

Ты на sh тоже как на C пишешь? (Там, впрочем, если писать аккуратно,
это бывает оправдано...)

А это как?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 00:47 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
22:41:42 +0200:

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

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и
всех
потомков одной командой.

После чего в памяти навечно остаётся висеть какой-нибудь pixbuf,
используемый в каком-нибудь image. Поскольку понадеялись на
gtk_widget_destroy и документацию к gtk_image_new_from_pixbuf на
предмет освобождения памяти перечитывать не стали.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

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

ПК И это понятно, сначала научитесь управлять памятью, потом управляйте.

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

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

Мы что про разные управления памятью говорим?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 00:43 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
22:37:50 +0200:

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

на асме тоже

ПК На асме нет как таковых понятий библиотек, без чего тяжко...

Ну почему нет? Понятия - есть. Библиотек на чистом асме вроде бы нет,
обвязка всегда сишная. А понятия - есть...

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

ПК Сложно там с библиотеками, потому и говорю что нет.

Можно сишную позвать :-) Можно, впрочем, и перловую :-)

Я б на это посмотрел! Главный цикл на Asm'е вызывающий перловые
процедуры :-)

--
Покотиленко Костик cas...@meteor.dp.ua

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

Скорость чтения с диска последовате льно одним процессом VS параллельно несколькими

2009-03-20 Пенетрантность Покотиленко Костик

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

О тесте: программа рекурсивно сканирует указанный каталог и составляет
список обычных файлов, затем делит этот список на N частей. Далее
программа создаёт N клонов с помощью fork(), каждый из которых читает
файлы из своей части списка. По окончанию работы каждого клона выводится
его статистика.

Кому интересно можете провести тест на свой страх и риск на своём
железе, результат сравним.

1. По результату: при моих параметрах тестирования чтение
последовательно одним процессом быстрее, но не намного.

2. Параметры тестирования:
- каталог: /usr/src
- ФС:ext3 (Всего: 9,2G; Занято: 6,8G)
- файлов в списке: 254794
- подкаталогов: 23003
- максимальные уровень вложенности: 12 (maxrec)
- проц: C2D ~2GHz
- память:1Гб (около 300Мб свободно/кэш)
- контроллер:Intel® ICH10
- винт: WDC WD5000AAKS-00YGA0
http://www.xard.ru/post/11716/default.asp

Беглое гугление показало, не факт что NCQ включён и работает:
http://blog.kovyrin.net/2006/08/11/turn-on-ncq-on-ich-linux/lang/ru/
Кто-нибудь в курсе статуса NCQ в Debian?

# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 5886 MB in 2.00 seconds = 2945.75 MB/sec
Timing buffered disk reads: 238 MB in 3.04 seconds = 78.40 MB/sec

#uname -a
Linux casper 2.6.24-etchnhalf.1-686 #1 SMP Fri Dec 26 04:10:16 UTC 2008
i686 GNU/Linux

остальное в pdf.

3. Точность:
- программа тупо делит список на равное количество записей, размеры
файлов не учитываются, поэтому одним клонам достаётся больше чем другим,
они работают дольше и остаток времени работают с меньшим числом
конкурентов, что на мой взгляд увеличивает общую скорость. Во вложенных
результатах в тесте с 4-мя потоками 4-му досталась половина всего
объёма. Это особенности распределения файлов по моему /usr/src.
- для каждого числа потоков было проведено 3 эксперимента, учитывались
средние значения.
- в программе учитывается только время на чтение файлов по списку, и не
учитывается время на его создание и другие операции.
- не понятно работал ли NCQ.
- перед тестами я не сбрасывал кэш ФС, на объёме ~1.3 Гб он не
эффективен, это видно из тестов.
- на мой взгляд данный тест производит нагрузку похожую на ту, что
создаёт apache2 при соизмеримых количествах клиентов (потоков) и
запросов.

http://meteor.dp.ua/reference/simreadtest/simreadtest-0.1.tar.gz
http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.ods
http://meteor.dp.ua/reference/simreadtest/simreadtest-19.03.2009-01.pdf

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 12:35 +0200, Тихон Тарнавский пишет:
On Fri, 20.03.2009 11:52:03 , Покотиленко Костик wrote:
В Птн, 20/03/2009 в 00:56 +0300, Artem Chuprina пишет:
Любая попытка выделить память может закончиться неудачей. И называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

В ситуации, описанной в том треде, oom-killer пристрелил не того, кого
надо было. При чёт здесь перл?

Есть предположение, что он таки прибивал треды spamassassin'а, тот
просто успевал наплодиться. Эти предположения основаны на логике работы
oom-killer, по ней spamassassin был первый кандидат.

И, в любом случае, spamassassin не отрабатывал как нужно невозможность
выделить память, у тупо повторял попытки, без задержек.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: mdadm raid1

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 15:47 +0300, DamirX пишет:
 В Птн, 20/03/2009 в 13:42 +0200, Oleg Litvinov пишет:
 
  ситуация - выключаем системник, достаем винт, включаем - в результате 
  один диск выпал, выключаем, ставим винт и включаем снова - можно ли 
  заставить автоматически массив восстановить или как?
 
 обращение со сложными вещами требует чтения документации.
 Задайте себе вопрос - содержимое какого винта считать актуальным?

Железный 3ware сам зараза определяет. По логике, тот, что оставался
работать, тот и оригинал.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 16:32 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
11:52:03 +0200:

Ну и там прочее по мелочи - а что у нас не освободится,
если вылетит ошибка вот тут?

Разумеется, без gtk_widget_destroy() или там EVP_PKEY_free()
было бы совсем хреново. Но с ними - просто хреново, а не
хорошо. Ну разве что слаще репы не едал...

ПК У меня такое бывает редко, а когда бывает - заварю чаю и
ПК почитаю кто кого освобождает а кто кого нет, сравню с кодом
ПК и всё готово, делов-то 20 минут.

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

ПК Это культура программирования, _этому_ учиться надо.

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

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

C эффективен. В своей узкой нише. Гораздо более узкой, чем сложилось
исторически.

А потом - ты valgrind на свои программы часто натравливаешь?

А ты натрави. Имеешь шанс узнать что-нибудь интересное...

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

Если только лики, и программа уровня hello world - то да, может, и не
стоят...

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Любая попытка выделить память может закончиться неудачей. И называется
она malloc() или create - рояля не играет. Ну, с точностью еще до
классических грабель объективизации конструкции, описанных во всех
книжках по C++ - что будет, если ошибка произойдет в момент, когда
память выделена под _часть_ подобъектов?

ПК Если ты программист Си - решать тебе что будет.

Что значит успело выделиться? Само оно не выделяется, по крайней мере в
Си.

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

Один раз, потом верну ошибку назад по стеку, там пусть решают что
делать.

ПК Вопрос удобства можно обсудить, очень интересно.

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

ПК В это мне тяжело въехать.

ПК 1. Я не говорил, что на Perl ничего не писал, просто ничего серьёзного
ПК не писал. А в способ я въехал.
ПК 2. Способ программирования в основном от языка не зависит, и нет, не
ПК тяжело понимать новые, даже нравится, если видно где они эффективнее.
ПК 3. Я не в религиозном кружке чтобы просто

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 16:35 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 20 Mar 2009
11:54:08 +0200:

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

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь
его и всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

ПК И это понятно, сначала научитесь управлять памятью, потом управляйте.

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

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

ПК Мы что про разные управления памятью говорим?

Не понимаю, можно подробнее? Что такое _интересная_ и _физическая_
память и как ими можно управлять из-под root'а?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-20 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 19:35 +0300, Alexey Pechnikov пишет:
Hello!

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

Да, но это уже ботаника, без измерений нечего тут сказать.

Вам гугл за неуплату отключили? :-)

Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная
очередь равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска
может переставлять команды в очереди так, чтобы требовалось минимальное
кол-во перемещений головки.

Это NCQ на сколько я понял. Хорошая вещь, что бы сделать более
последовательным набор параллельных запросов. Где тут логика? Или я
всё-таки чего-то не понимаю, у SATA винтов головки независимо читают?

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

Давай продолжим в треде Скорость чтения с диска последовательно одним
процессом VS параллельно несколькими

Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.

Про это в Инете не нашёл, можно ссылку?

Посмотрите сколько чипов памяти стоит в SSD дисках. Каждый чип работает
независимо, так что все лимитируется лишь контроллером.

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

Как раз наоборот. Больше параллельных процессов пытающихся прочитать -
меньшая линейность чтения, NCQ, конечно как-то сгладит... Кто-нибудь
располагает результатами тестов?

Утилиты для измерения io performance есть в дебиане. Возьмите и проверьте.

Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?

Нет. Буферы запросов и ответов, чтоб большие потоки по пайпам не гонять
туда-сюда.

Ха.

Данные обрабатываемого запроса в других процессах/потоках никому просто
не нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже
рассмотрено выше. А насчет общей памяти - от этого решения уже и многие
СУБД отказываются. В результате использования shared memory тот же оракл
масштабируется намного хуже терадата. PostgreSQL так же использует shared
memory, что приводит к различным проблемам. Я уж не говорю про сложность
такого решения.

Ссылки на обсуждения можно посмотреть? Любая вещь используемая не по
назначению имеет свойство превращаться в грабли...

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

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

Я не знаю, как устроен apache2.

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

Ага, например, архитектура жестких дисков :-) Или живите с ней, или ставьте
себе SSD, что сейчас уже возможно сделать.

Best regards.
--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Скорость чтения с диска последовате льно одним процессом VS параллельно несколькими

2009-03-20 Пенетрантность Покотиленко Костик

В Птн, 20/03/2009 в 18:28 +, Stanislav Maslovski пишет:
 On Fri, 2009-03-20 at 12:02 +0200, Покотиленко Костик wrote:
  Беглое гугление показало, не факт что NCQ включён и работает:
  http://blog.kovyrin.net/2006/08/11/turn-on-ncq-on-ich-linux/lang/ru/
  Кто-нибудь в курсе статуса NCQ в Debian?
 
 Freshly installed lenny 64bit:
 
 s...@magi:~$ dmesg|grep -i ncq
 [3.553601] ahci :00:1f.2: flags: 64bit ncq sntf stag pm led clo
 pio slum part
 [4.020521] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth
 31/32)

Для этого обязательно нужен AHCI?

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 22:01 +0400, Степан Голосунов пишет:
Покотиленко Костик cas...@meteor.dp.ua writes:
В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
получаешь высокоуровневый подъязык с неудобным синтаксисом и
... правильно, все равно заботой о распределении памяти (почистить за
тобой все равно никто не сможет).

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой.

Баги есть везде. Э про это не знаю, pixbuf'ом практически не
пользовался.

Так что это дело инструментов, а GTK+ и кстати
glib это умеют.

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-19 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 22:52 +0200, Aleksey Cheusov пишет:
  Вы не находите, что unix системы не для вас? Они спроектированы с
   основой на текст.
 
  Другие ещё более не для меня.
 
 Я бы посоветовал пересмотреть ваше отношение к тексту.  Все таки,
 говорим UNIX, подразуемваем текст. Это правда.  Выкладки эффективно и
 неэффективно на основе каких-то с неба взятых процентов - мягко говоря
 наивняк, если не сказать покрепче. И литературу так да, надо читать.

Я не против, аргументов хочется. Я их своими иногда громкими
высказываниями пытаюсь спровоцировать :)

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 20:52 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
17:08:20 +0200:

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

ПК В GTK+, создаёшь виджет окно, напихиваешь туда кучу других
ПК виджетов, потом делаешь gtk_widget_destroy() на окно, и
ПК освобождаешь его и всех потомков одной командой. Так что это дело
ПК инструментов, а GTK+ и кстати glib это умеют.

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

Про ненароком опустим...

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

У меня такое бывает редко, а когда бывает - заварю чаю и почитаю кто
кого освобождает а кто кого нет, сравню с кодом и всё готово, делов-то
20 минут.

ПК Чем вдруг?

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

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

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

ПК Мне нравится с годами углубляться в один и тот же язык, чем с каждым
ПК годом изучать их больше. На Си можно сделать всё, а тебе видимо
ПК приходится слазить с Тикля иногда.

ПК Вопрос удобства можно обсудить, очень интересно.

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

Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда shell.
Perl, конечно, было бы круто знать, что иногда использовать вместо
shell, но мне лень его изучать, я на Си не на много медленее напишу.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-19 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 20:39 +0300, Alexey Pechnikov пишет:
Hello!

On Wednesday 18 March 2009 18:11:46 Покотиленко Костик wrote:
Ты забываешь про армию сисадминов-наколенщиков.

Во-первых, их код редко попадает на CPAN или в иное общее пользование.
Во-вторых, СОВРЕМЕННЫЕ сисадмины-наколеночники пишут на python и php.
Собственно ровно для них в поставку php включен standalone интерпретатор
и разрабатываются разные прибамбасы вроде php-gtk.

Это как, сисадмины уже на PHP работают? :-O

А что вас удивляет? Когда-то в универе я в качестве решающего аргумента в
споре численное решение параболического уравнения на php написал :-) Ну,
минуты две счет шел, вместо секунд, но оппоненты утверждали, что годами
считать будет (подробностей их реализации не помню, возможно, у них и версия
на С работала намного медленнее, если схему не оптимальную взяли и с шагом
намудрили, но я собственно и хотел доказать, что дело больше в алгоритмах,
чем
в выбранном языке).

Вот это правильно (про алгоритмы).

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

В javascript'е приятен Си'шный синтаксис. Серверный не пользовал, он
меня пугает.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: OOM Killer

2009-03-19 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 21:16 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
17:30:50 +0200:

ПК На одном сервачке, недавно выключил своп.

ПК Сегодня spamassassin съел всю память и пошёл работать oom-killer. В
ПК течении 20 минут машину ничем не получилось раздуплить, ни на что не
ПК отвечала даже на консоль. Только сыпались сообщения от oom-killer.
ПК Пришлось тупо резет.

ПК Вопрос такой, почему так получается? oom-killer то должен прибить
ПК кого-то и дальше ну хоть как-то должно работать.

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

В том-то и дело, что ни одну консоль открыть не удалось в течении 20
минут, ГРУ[СТ|З]НО.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: OM Killer

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 05:07 +0300, Mikhail A Antonov пишет:
 18/03/2009 21:16 (GMT +3) Artem Chuprina
  Пришлось тупо резет.
 Немного в сторону: Alt+SysReq+B заменяет reset в дистрибутивном ядре.
 Точнее в любом, где включены Magic keys.

Что оно делает?

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 09:07 +0200, chaos пишет:
 On 18 March 2009 17:08:20 Покотиленко Костик wrote:
  В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
   Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
 15:03:57 +0200:
  Ну так как, пробовать будем?
 
  Неа.
 
  Если посмотреть выше, то речь шла о демонах, а не парсерах
  текстовых файлов. Или Вы считаете их равнозначными задачами?
 
  Есть у меня и демоны на тикле, например, собирают и обрабатывают
  данные с цисок и других АТС. Написать то же самое на С большая
  работа (на тикле используются события для прослушивания множества
  сокетов, а на С придется создавать отдельные потоки), потому и не
  предлагаю как тестовую задачу (притом демоны умеют держать в
  in-memory SQLite database те данные, которые не удалось записать в
  persistent database), не говоря уж о реализации самой логики
  обработки.
 
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в
  которых соответствующие примитивы.

 Вообще говоря, есть libevent, с помощью которой на Си событийно
 писать проще. Но вообще прикладуху на Си писать не интересно, борьба
 с языком(слишком низкоуровневый) и развивается паранойя при
 использовании каждого указателя.
  
ПК Прикол в том, что уровень языка Си выбирается программистом
   посредством ПК выбора библиотек нужных уровней. На libc конечно тяжело
   прикладуху ПК писать. Выбор за тобой, а не за языком, используй glib,
   gtk+, или что ПК тебе больше подходит для конкретной задачи.
  
ПК Как я уже писал, на Си легко работать с объектной моделью, не
   сложнее ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
   ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
   ПК высокого уровня ограничивают тебя высотой своего уровня.
  
   Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
   получаешь высокоуровневый подъязык с неудобным синтаксисом и
   ... правильно, все равно заботой о распределении памяти (почистить за
   тобой все равно никто не сможет).
 
  В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
  потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
  потомков одной командой. Так что это дело инструментов, а GTK+ и кстати
  glib это умеют.
 
   Таким образом, у тебя в любом случае неудобный синтаксис и в любом
   случае распределение памяти.  Ты от них уйти не можешь.
 
  Чем вдруг?
 
   При языке высокого уровня же ты можешь вынести в отдельную библиотеку
   то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
   с низким уровнем и на них можно сделать достаточно эффективно - тот же
   бинарный протокол на tcl реализовать в разы проще, чем на C).
 
  Мне нравится с годами углубляться в один и тот же язык, чем с каждым
  годом изучать их больше. На Си можно сделать всё, а тебе видимо
  приходится слазить с Тикля иногда.
 
 на асме тоже

На асме нет как таковых понятий библиотек, без чего тяжко...

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: OM Killer

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 21:45 +0200, Тихон Тарнавский пишет:
 On Thu, 19.03.2009 20:59:37 , Покотиленко Костик wrote:
  В Чтв, 19/03/2009 в 05:07 +0300, Mikhail A Antonov пишет:
   18/03/2009 21:16 (GMT +3) Artem Chuprina
Пришлось тупо резет.
   Немного в сторону: Alt+SysReq+B заменяет reset в дистрибутивном ядре.
   Точнее в любом, где включены Magic keys.
  
  Что оно делает?
 Прошу прощения, но на этот вопрос во-первых уже есть ответ выше,

Прошу прощения, фраза Alt+SysReq+B заменяет reset не говорит о том как
он его заменяет.

  а
 во-вторых вот это гуглится на десять секунд:
 http://en.wikipedia.org/wiki/Magic_SysRq_key

Immediately reboot the system, without unmounting partitions or syncing

Мне проще было таки нажать reset. А я уж подумал он его как-то со
смыслом заменяет.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 23:25 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Thu, 19 Mar 2009 
 20:29:36 +0200:
 
Мне нравится с годами углубляться в один и тот же язык, чем с каждым
годом изучать их больше. На Си можно сделать всё, а тебе видимо
приходится слазить с Тикля иногда.
   
   на асме тоже
 
  ПК На асме нет как таковых понятий библиотек, без чего тяжко...
 
 Ну почему нет?  Понятия - есть.  Библиотек на чистом асме вроде бы нет,
 обвязка всегда сишная.  А понятия - есть...
 
 Надо сказать, в старые и даже в чем-то добрые времена библиотеки тоже
 были.  Вымерли за непереносимостью.

Сложно там с библиотеками, потому и говорю что нет.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 23:23 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
20:19:52 +0200:

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

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой.

ПК Баги есть везде. Э про это не знаю, pixbuf'ом практически не
ПК пользовался.

Этот баг у них фичей зовется. В смысле - документирован, а не
исправлен...

И это понятно, сначала научитесь управлять памятью, потом управляйте.

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 23:32 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Thu, 19 Mar 2009
20:44:07 +0200:

Ну и там прочее по мелочи - а что у нас не освободится, если вылетит
ошибка вот тут?

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

Это культура программирования, _этому_ учиться надо.

А потом - ты valgrind на свои программы часто натравливаешь?

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

После какого-то такого случая, я написал простенький профайлер, обёртку
для malloc и free с модулем статистики. Использую её в задачах, где сам
не уверен где какие узкие места. Снимай статистику и хоть в rrd пиши.

ПК Чем вдруг?

ПК Не через один, а один раз на каждый неподвластный вход.

И на каждое выделение памяти. Вверх по всему стеку вызовов.

Если не увлекаться вызовом malloc() inline, а каждый объект делать
набор функций create, destroy и т.д. то это не много и оправдано.
Кстати, разделяя функционал от интерфейса и выделив библиотеку, так даже
проще.

ПК А все подвластные входы не должны давать неожиданностей, этому
ПК время уделять надо, оно окупается.

Не должны не значит не дают... Впрочем, это уже мелочи.

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

ПК Мне нравится с годами углубляться в один и тот же язык, чем с
ПК каждым годом изучать их больше. На Си можно сделать всё, а тебе
ПК видимо приходится слазить с Тикля иногда.

ПК Вопрос удобства можно обсудить, очень интересно.

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

ПК Хорошо, что он у меня один. Кроме, когда на коленке надо, тогда
ПК shell. Perl, конечно, было бы круто знать, что иногда использовать
ПК вместо shell, но мне лень его изучать, я на Си не на много медленее
ПК напишу.

Если писать на перле как на C, то да, на C ненамного медленнее
получится. Вот только те, кто изучает не языки, а программирование, на
перле пишут по-другому. Как на перле :-) И C сразу начинает отставать
если не в сотни раз, то в десятки уж точно.

В это мне тяжело въехать.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 23:33 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Thu, 19 Mar 2009 
 20:47:16 +0200:
 
  ПК В javascript'е приятен Си'шный синтаксис.
 
 Нашел, блин, за что похвалить...

:)

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: OM Killer

2009-03-19 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 22:25 +0200, Тихон Тарнавский пишет:
 On Thu, 19.03.2009 22:19:25 , Покотиленко Костик wrote:
  В Чтв, 19/03/2009 в 21:45 +0200, Тихон Тарнавский пишет:
   On Thu, 19.03.2009 20:59:37 , Покотиленко Костик wrote:
В Чтв, 19/03/2009 в 05:07 +0300, Mikhail A Antonov пишет:
 18/03/2009 21:16 (GMT +3) Artem Chuprina
  Пришлось тупо резет.
 Немного в сторону: Alt+SysReq+B заменяет reset в дистрибутивном ядре.
 Точнее в любом, где включены Magic keys.

Что оно делает?
   Прошу прощения, но на этот вопрос во-первых уже есть ответ выше,
  
  Прошу прощения, фраза Alt+SysReq+B заменяет reset не говорит о том как
  он его заменяет.
 А, в смысле как? Ну да, буквально заменяет.
 
   а во-вторых вот это гуглится на десять секунд:
   http://en.wikipedia.org/wiki/Magic_SysRq_key
  
  Immediately reboot the system, without unmounting partitions or syncing
  
  Мне проще было таки нажать reset. А я уж подумал он его как-то со
  смыслом заменяет.
 Там sync отдельно есть.

Буду знать, спасибо.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 10:22 +0600, Andrey Lyubimets пишет:
Покотиленко Костик пишет:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar
2009 17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве
клиента SMTP?

ПК Он то ничего не парсит, пользователя telnet'а приходится
парсить.

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

Приведу в пример, скажем, swaks - отладчик для конфигурации
SMTP. У которого мне, помнится, не удалось найти средства
прервать диалог после команды DATA, но до вкармливания в сервер
собственно письма.

Так-то он весь из себя хороший, и пользоваться им для
тестирования конструкции со STARTTLS куда удобнее, чем руками...
Но вот пары нужных фич не умеет - и до свидания. И что б я
делал, будь там бинарный протокол? Разбирался бы в его коде,
чтобы туда эту возможность дописать? А если бы он при этом еще
и был написан с использованием сишной библиотеки реализации
протокола, и этой возможности не было бы в _ее_ интерфейсе?

ПК Это вопрос дисциплины. Бинарь к ней, кстати, располагает все
сравнения с ПК текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.

ПК сорьки.

ПК -все+вне

Ага. Опять-таки, совершенно не согласен. Да, располагает. Но не к
той, которая нужна, а к той, где за деревьями леса не видно.

Заголовки этого письма составляют: 5189 байт Текст этого письма с
подписями: 2104 байт КПД: 2104/(5189+2104)=~29%
Ты не тот КПД считаешь! нужно считать КПД читателя, заголовки пишутся в
первую очередь для человека!

Письмо, я бы сказал, среднего размера.

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-18 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 22:49 +0300, Alexey Pechnikov пишет:
Hello!

On Tuesday 17 March 2009 22:19:12 Покотиленко Костик wrote:
Если изменить архитектуру так:
- один процесс принимает все соединения с одной стороны, и общается с
несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
количестве равном количеству ядер
- процессы выполняющие вычисления читают данные через процессы работы с
дисками (по одному на каждый физический диск), выполняют обработку,
отдают результат главному, тот клиенту
- процессы работы с дисками обрабатывают чтение запись и всё.

С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
клиентов будет 7 процессов.

И что, магическое число 7 принесет удачу серверу? :-)

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

Не будет. Его задача состоит только в том чтобы делать read() на сокет
клиенты и write() на сокет процесса выполняющего вычисления, потом
обратно, и так по кругу для всех клиентов. Нагрузка около нуля.

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

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

Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
кэшировать прям в процессе.

Хотя стой, не надо плодить процессы и встраивать кэш. В любом случае
один процесс читающий последовательно будет не медленее чем два
параллельно. Кэш ФС тут помощник как в первом случае так и во втором.

Если я не прав, давайте обсудим.

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

Ну, если нужен рэйд, кто мешает.

Не говоря уже о бессмысленности создания бутылочного горла
между читающими и вычисляющими процессами.

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

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

Я не пытаюсь угадать, я пытаюсь размышлять.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 11:28 +0500, Владимир Ступин пишет:
 Насчёт парсинга писем и засовывания результатов в БД: есть
 POP3/IMAP/LMTP-сервер, умеющий использовать в качестве бэкэнда SQLite,
 MySQL или PostgreSQL, называется dbmail. Вот тут:
 http://www.dbmail.org/dokuwiki/doku.php?id=er-model, нарисована и
 расписана схема БД.

Там заголовки одним куском лежат, кроме To, From...

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 13:52 +0200, Тихон Тарнавский пишет:
On Wed, 18.03.2009 11:16:03 , Покотиленко Костик wrote:
В Срд, 18/03/2009 в 10:22 +0600, Andrey Lyubimets пишет:
Покотиленко Костик пишет:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar
2009 17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве
клиента SMTP?

ПК Он то ничего не парсит, пользователя telnet'а приходится
парсить.

ПК Это вопрос дисциплины. Бинарь к ней, кстати, располагает все
сравнения с ПК текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.

ПК сорьки.

ПК -все+вне

Письмо, я бы сказал, среднего размера.

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

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

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 20:16 +0900, Alexander Danilov пишет:
Покотиленко Костик пишет:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве
клиента
SMTP?

ПК Он то ничего не парсит, пользователя telnet'а приходится
парсить.

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

Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP.
У
которого мне, помнится, не удалось найти средства прервать диалог
после
команды DATA, но до вкармливания в сервер собственно письма.

Так-то он весь из себя хороший, и пользоваться им для тестирования
конструкции со STARTTLS куда удобнее, чем руками... Но вот пары
нужных
фич не умеет - и до свидания. И что б я делал, будь там бинарный
протокол? Разбирался бы в его коде, чтобы туда эту возможность
дописать? А если бы он при этом еще и был написан с использованием
сишной библиотеки реализации протокола, и этой возможности не было
бы в
_ее_ интерфейсе?

ПК Это вопрос дисциплины. Бинарь к ней, кстати, располагает все
сравнения с
ПК текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.

ПК сорьки.

ПК -все+вне

Заголовки этого письма составляют: 5189 байт
Текст этого письма с подписями: 2104 байт
КПД: 2104/(5189+2104)=~29%

Письмо, я бы сказал, среднего размера.

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

Кстати, какая это версия протокола, где посмотреть формат, чтоб написать
парсер?
Допустим, есть задача сделать формат хранения почты так, чтобы каждый
элемент заголовка (каждый Received: и т.п. раскладывался на составляющие)
хранился отдельно, индексировался, и по нему можно было производить поиск.
Может есть готовые парсеры, способные раскладывать всё, что используется в
SMTP/mbox на мельчайшие детали?

Вы не находите, что unix системы не для вас? Они спроектированы с основой на
текст.

Другие ещё более не для меня.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 13:34 +0300, Alexey Pechnikov пишет:
Hello!

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

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

Да, но это уже ботаника, без измерений нечего тут сказать.

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

Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная очередь
равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска может
переставлять команды в очереди так, чтобы требовалось минимальное кол-во
перемещений головки.

Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.

Про это в Инете не нашёл, можно ссылку?

Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
кэшировать прям в процессе.

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

Не говоря уже о бессмысленности создания бутылочного горла
между читающими и вычисляющими процессами.

Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?

Нет. Буферы запросов и ответов, чтоб большие потоки по пайпам не гонять
туда-сюда.

Данные обрабатываемого запроса в других процессах/потоках никому просто не
нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже
рассмотрено
выше. А насчет общей памяти - от этого решения уже и многие СУБД
отказываются.
В результате использования shared memory тот же оракл масштабируется намного
хуже терадата. PostgreSQL так же использует shared memory, что приводит к
различным проблемам. Я уж не говорю про сложность такого решения.

Я не пытаюсь угадать, я пытаюсь размышлять.

Размышления строятся на основе фактов, а не на догадках.

Я считаю, что глупо думать, что раз apache2 так устроенна то это
наиболее оптимальный вариант. Есть пословица: Бог создал мир на 7 дней,
потому что ему не приходилось думать о проблемах обратной
совместимости. Так вот во многих приложениях их настоящая архитектура -
это пережиток прошлого, который дорого переделать.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 21:32 +0900, Alexander Danilov пишет:
 Alexander GQ Gerasiov пишет:
  На Tue, 17 Mar 2009 20:37:53 +0300
  Alexey Pechnikov pechni...@mobigroup.ru записано:
  
  Hello!
 
  On Tuesday 17 March 2009 19:33:16 Yuri Kozlov wrote:
  Ну так как, пробовать будем?
  Неа.
 
  Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
  файлов. Или Вы считаете их равнозначными задачами?
  Есть у меня и демоны на тикле, например, собирают и обрабатывают
  данные с цисок и других АТС. Написать то же самое на С большая работа
  (на тикле используются события для прослушивания множества сокетов, а
  на С придется создавать отдельные потоки), потому и не предлагаю как
  тестовую задачу (притом демоны умеют держать в in-memory SQLite
  database те данные, которые не удалось записать в persistent
  database), не говоря уж о реализации самой логики обработки.
  
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
  соответствующие примитивы.
  
 
 Вообще говоря, есть libevent, с помощью которой на Си событийно писать проще.
 Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком 
 низкоуровневый)
 и развивается паранойя при использовании каждого указателя.

Прикол в том, что уровень языка Си выбирается программистом посредством
выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
тебе больше подходит для конкретной задачи.

Как я уже писал, на Си легко работать с объектной моделью, не сложнее
чем на C++ или другом языке. Надо тебе крупноузловая сборка -
пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
высокого уровня ограничивают тебя высотой своего уровня.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 15:51 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
 14:28:11 +0200:
 
Логично, программы реализует протокол, или несколько. Зато это железно,
без нюансов. Как по мне, так неожиданно получать неожиданные данные не
лучше.

   И ещё раз попрошу прояснить ускользающую от меня связь между
   тукстовостью/бинарностью протокола или формата и степенью ожидаемости
   данных, хранимых в этом формате или получаемых по этому протоколу.
 
  ПК Постараюсь на пальцах. Грубо говоря, если в тебе надо что-то
  ПК добавить в бинарном протоколе, с чётко определённым форматом, ты не
  ПК сможешь это сделать не скорректировав его клиентов и серверов, а
  ПК точнее либу, которую они используют, так, чтобы ничего не
  ПК сломалось. Поэтому, к вопросу придётся подойти системно.
 
  ПК В случае с текстовым протоколом, где всё не так чётко определено,
  ПК ты обломаешься и вставишь новое поле куда-нибудь, где оно не сильно
  ПК помешает, назавёшь его новой фишкой и никому не скажешь.
 
  ПК Тут баланс такой - либо делаешь всё как надо, либо потом разгребаешь
  ПК глюки и усложняешь парсеры.
 
 То-то я гляжу, почти все реально используемые бинарные протоколы
 _разработаны_ с учетом возможности расширения заранее неизвестным
 способом, и в немалом их количестве она уже задействована...
 
 Причем задействована порой через такую ж..., что поневоле задумаешься, а
 не стоило ли сделать изначальный протокол текстовым, чтобы библиотека,
 его реализующая, все же была сделана попрямее?
 
 На реализации TLS в этом смысле очень полезно посмотреть.  Особенно - на
 те, которые до сих пор поддерживают совместимость с SSL 2.0.

TLS по определению костыль.

 -- 
 Artem Chuprina
 RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru
 
 Вот .NET и Mono - это современные технологии.  В смысле - сырые и глюкавые.
   Victor Wagner в cisnd1$qt...@wagner.wagner.home
 
 
-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 15:08 +0200, Покотиленко Костик пишет:
 В Срд, 18/03/2009 в 15:51 +0300, Artem Chuprina пишет:
  Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
  14:28:11 +0200:
  
 Логично, программы реализует протокол, или несколько. Зато это 
  железно,
 без нюансов. Как по мне, так неожиданно получать неожиданные данные не
 лучше.
 
И ещё раз попрошу прояснить ускользающую от меня связь между
тукстовостью/бинарностью протокола или формата и степенью ожидаемости
данных, хранимых в этом формате или получаемых по этому протоколу.
  
   ПК Постараюсь на пальцах. Грубо говоря, если в тебе надо что-то
   ПК добавить в бинарном протоколе, с чётко определённым форматом, ты не
   ПК сможешь это сделать не скорректировав его клиентов и серверов, а
   ПК точнее либу, которую они используют, так, чтобы ничего не
   ПК сломалось. Поэтому, к вопросу придётся подойти системно.
  
   ПК В случае с текстовым протоколом, где всё не так чётко определено,
   ПК ты обломаешься и вставишь новое поле куда-нибудь, где оно не сильно
   ПК помешает, назавёшь его новой фишкой и никому не скажешь.
  
   ПК Тут баланс такой - либо делаешь всё как надо, либо потом разгребаешь
   ПК глюки и усложняешь парсеры.
  
  То-то я гляжу, почти все реально используемые бинарные протоколы
  _разработаны_ с учетом возможности расширения заранее неизвестным
  способом, и в немалом их количестве она уже задействована...
  
  Причем задействована порой через такую ж..., что поневоле задумаешься, а
  не стоило ли сделать изначальный протокол текстовым, чтобы библиотека,
  его реализующая, все же была сделана попрямее?
  
  На реализации TLS в этом смысле очень полезно посмотреть.  Особенно - на
  те, которые до сих пор поддерживают совместимость с SSL 2.0.
 
 TLS по определению костыль.

Беру свои слова обратно, перепутал. Про TLs почти ничего не знаю.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 16:23 +0300, Konstantin Matyukhin пишет:
2009/3/18 Alexander Danilov alexander.a.dani...@gmail.com:
Konstantin Matyukhin пишет:

2009/3/18 Alexander Danilov alexander.a.dani...@gmail.com:

Artem Chuprina пишет:

Alexander Danilov - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
22:33:21 +0900:

AD :) Перловый код своим через месяц уже не является.

И так на перле тоже пишут...

В основном, именно так, на перле и пишут :)

У вас есть какая-то статистика по этому поводу
или просто так для красного словца?

Так я исходники почитываю. Я в своё время обратил внимание на одну
интересную особенность,
пока перл был ещё не очень популярен (до 1998/99 годов), качество кода на
CPAN было очень даже
неплохое, но потом размер перл (из-за WEB/CGI/Apache) стал очень популярен и
качество кода на
CPAN стало сильно падать, а сам CPAN распухать. Вообще перл не провоцирует
на написание понятного кода, но предлагаю эту тему не развивать.
Перл для меня пройденный этап, я свои выводы сделал, я
им теперь очень редко пользуюсь, придёт время - вы сделаете свои выводы.

Сделал. Пишу теперь, практически, только на Perl. И да, я не люблю, когда
^^
Вы себя неоправданно ограничиваете.

меня что-то или кто-то провоцирует.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 16:31 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
15:03:57 +0200:

Ну так как, пробовать будем?
Неа.

Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
файлов. Или Вы считаете их равнозначными задачами?
Есть у меня и демоны на тикле, например, собирают и обрабатывают
данные с цисок и других АТС. Написать то же самое на С большая работа
(на тикле используются события для прослушивания множества сокетов, а
на С придется создавать отдельные потоки), потому и не предлагаю как
тестовую задачу (притом демоны умеют держать в in-memory SQLite
database те данные, которые не удалось записать в persistent
database), не говоря уж о реализации самой логики обработки.

Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
соответствующие примитивы.

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

ПК Прикол в том, что уровень языка Си выбирается программистом посредством
ПК выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
ПК писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
ПК тебе больше подходит для конкретной задачи.

ПК Как я уже писал, на Си легко работать с объектной моделью, не сложнее
ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
ПК высокого уровня ограничивают тебя высотой своего уровня.

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

В GTK+, создаёшь виджет окно, напихиваешь туда кучу других виджетов,
потом делаешь gtk_widget_destroy() на окно, и освобождаешь его и всех
потомков одной командой. Так что это дело инструментов, а GTK+ и кстати
glib это умеют.

Чем вдруг?

Вопрос удобства можно обсудить, очень интересно.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 23:05 +0900, Alexander Danilov пишет:
 Artem Chuprina пишет:
  Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
  15:03:57 +0200:
  
 Ну так как, пробовать будем?
 Неа.

 Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
 файлов. Или Вы считаете их равнозначными задачами?
 Есть у меня и демоны на тикле, например, собирают и обрабатывают
 данные с цисок и других АТС. Написать то же самое на С большая работа
 (на тикле используются события для прослушивания множества сокетов, а
 на С придется создавать отдельные потоки), потому и не предлагаю как
 тестовую задачу (притом демоны умеют держать в in-memory SQLite
 database те данные, которые не удалось записать в persistent
 database), не говоря уж о реализации самой логики обработки.
 
 Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
 соответствующие примитивы.
 

Вообще говоря, есть libevent, с помощью которой на Си событийно писать 
  проще.
Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком 
  низкоуровневый)
и развивается паранойя при использовании каждого указателя.
  
   ПК Прикол в том, что уровень языка Си выбирается программистом посредством
   ПК выбора библиотек нужных уровней. На libc конечно тяжело прикладуху
   ПК писать. Выбор за тобой, а не за языком, используй glib, gtk+, или что
   ПК тебе больше подходит для конкретной задачи.
  
   ПК Как я уже писал, на Си легко работать с объектной моделью, не сложнее
   ПК чем на C++ или другом языке. Надо тебе крупноузловая сборка -
   ПК пожалуйста, надо под микроскопом поработать - пожалуйста. А вот языки
   ПК высокого уровня ограничивают тебя высотой своего уровня.
  
  Как только ты на C выбираешь достаточно высокий уровень, ты немедленно
  получаешь высокоуровневый подъязык с неудобным синтаксисом и
  ... правильно, все равно заботой о распределении памяти (почистить за
  тобой все равно никто не сможет).
  
  Таким образом, у тебя в любом случае неудобный синтаксис и в любом
  случае распределение памяти.  Ты от них уйти не можешь.
  
  При языке высокого уровня же ты можешь вынести в отдельную библиотеку
  то, что таки да, надо сделать на C (хинт: вообще-то бОльшую часть работы
  с низким уровнем и на них можно сделать достаточно эффективно - тот же
  бинарный протокол на tcl реализовать в разы проще, чем на C).
  
 
 Кстати, Tcl - это сишная библиотека хорошего качества, рекомендую. :)

:-D

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 16:23 +0300, Victor Wagner пишет:
 On 2009.03.18 at 17:52:53 +0600, Mikhail Gusarov wrote:
 
  
  Twas brillig at 14:51:48 18.03.2009 UTC+03 when vi...@wagner.pp.ru did gyre 
  and gimble:
  
   VW Перл - старый и немодный язык. Поэтому те кто на нем продолжает
   VW писать, в среднем имеют более высокую квалификацию.
  
  Ты забываешь про армию сисадминов-наколенщиков.
 
 Во-первых, их код редко попадает на CPAN или в иное общее пользование.
 Во-вторых, СОВРЕМЕННЫЕ сисадмины-наколеночники пишут на python и php.
 Собственно ровно для них в поставку php включен standalone интерпретатор 
 и разрабатываются разные прибамбасы вроде php-gtk.

Это как, сисадмины уже на PHP работают? :-O

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 22:30 +0900, Alexander Danilov пишет:
Покотиленко Костик пишет:
В Срд, 18/03/2009 в 13:52 +0200, Тихон Тарнавский пишет:
On Wed, 18.03.2009 11:16:03 , Покотиленко Костик wrote:
В Срд, 18/03/2009 в 10:22 +0600, Andrey Lyubimets пишет:
Покотиленко Костик пишет:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar
2009 17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве
клиента SMTP?
ПК Он то ничего не парсит, пользователя telnet'а приходится
парсить.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.
ПК сорьки.

ПК -все+вне

Ага. Опять-таки, совершенно не согласен. Да, располагает. Но не к
той, которая нужна, а к той, где за деревьями леса не видно.
Заголовки этого письма составляют: 5189 байт Текст этого письма с
подписями: 2104 байт КПД: 2104/(5189+2104)=~29%
Ты не тот КПД считаешь! нужно считать КПД читателя, заголовки пишутся в
первую очередь для человека!
Письмо, я бы сказал, среднего размера.

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

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

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

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

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Чтв, 19/03/2009 в 00:27 +0900, Alexander Danilov пишет:
Покотиленко Костик пишет:

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

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

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

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

Я собственно тоже со стажем...
Тем более, что изложенный тут принцип обновляться не заставляет. Кому
надо новое тот обновится. Опять же протоколы обновляются не так и часто,
только в начале развития.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-18 Пенетрантность Покотиленко Костик

В Срд, 18/03/2009 в 22:25 +0600, ivan demakov пишет:
On Wednesday 18 March 2009 18:28:11 Покотиленко Костик wrote:

по моему опыту

1) написать текстовый парсер не так и сложно
тут, главное, придумать правильный протокол (т.е. язык)

Ключевое слово правильный протокол. Если это так то текстовый он или
бинарный уже не такая большая разница.

2) написать нормальный бинарный парсер - ничуть не проще

Не проще. Но и не сложнее.

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

Протокол тут ни при чём, это вопрос реализации.

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

лично мне кажется очень наивной вера в то, что злоумышленников не
существует ;-)

Что я такого сказал, что Вы так подумали про меня?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 00:05 +0300, Alexey Pechnikov пишет:
Hello!

On Monday 16 March 2009 20:48:44 Покотиленко Костик wrote:
Про потребляемую память забываем.

И яркий пример тому тот же spamassassin. Он одновременно может только 5
потоков обрабатывать, как написано в документации, unless you know what
you're doing.

А что, все программы на С умеют работать с тысячами потоков? Интереснее
работа
с событиями в тикле, к примеру, когда не требуется плодить тучу потоков, чтоб
одновременно снимать данные, скажем, с десятка цисок.

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

Вы правы, когда говорите, что
- нет смысла экономить килобайты и мегабайты памяти, когда речь идёт о
ПО работающем с единственном экземпляре, т.к. память дешёвая;
- нет смысла оптимизировать тысячи и сотни тысяч MIPS'ов в процедуре,
которая выполняется раз в относительно большой период времени, т.к. Вы
сэкономите не больше секунды.

И в чем заключается экономия?

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

Ну, возьмем другой пример - сжатие/распаковка данных. Лично я предпочитаю
делать расширения к SQLite, чтобы можно было пользоваться как из тикля, так и
из шелла, в данном случае используем системную zlib, в итоге получаем:
$ cat compress.c |wc -l
120
И это с комментариями и инструкциями по сборке! И в моем полном распоряжении
эффективный инструмент, доступный как из программы, так и в консоли. Плюс
SQLiteMan, написанный С++, и некоторые другие проекты пользуются этим и
другими модулями, при том, что я при написании кода могу совершенно не
беспокоиться, на чем будет сделано клиентское приложение. Вот это и есть
эффективность (оптимизируем именно то, что нуждается в оптимизации) плюс
повторное использование кода. Ваши же десятки и сотни килобайт кода, который
годится только для одного вашего проекта, никто и читать не станет, проще
заново написать.

Хорошее решение то, что работает.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 22:24 +0400, Степан Голосунов пишет:
 Покотиленко Костик cas...@meteor.dp.ua writes:
  В случае, если SMTP, FTP, HTTP были бинарные:
  - плагины для сниферов: которые есть для текстовых вариантов, для
  бинарных разработка по времени такая же
 
 В случае текстовых протоколов разработка плагина не требуется.
 
  - любой клиент этих протоколов итак делает преобразования протокол -
  CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
  работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
  строку, что бы прочитать последний элемент.
 
 И что же парсит и преобразует telnet при работе в качестве клиента
 SMTP?

Он то ничего не парсит, пользователя telnet'а приходится парсить.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 14:15 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
19:04:24 +0200:

Демоны почему-то чаще всего пишут не на скриптовых языках.

Ошибаетесь. Большинство написанных в последние несколько лет
демонов как раз
скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас
же очень много
написано на скриптовых языках.

Проверил список демонов на одной из машин
snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog,
klog,
mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind
и еще
несколько других - все не скриптовые.
Единственный найденный скриптовый - xen

ПК spamassassin тоже скриптовый, но это его минус, причём большой.

Минус его не в этом. Сделать ту же обработку на C у тебя, может, и
получится, но шансы, что она окажется быстрее, близки к нулю. Потому
что perl заточен ровно под задачи этого класса, и производительность
_этих_ операций в нем вылизана гораздо лучше, чем это сможешь сделать
ты
за ограниченное время.

ПК Ты прав, не по тому пути они пошли, но их уже не догнать.

Кто они? Админы?

ПК Разработчики SA.

А куды им бечь? Не анализировать письмо от слова совсем?

ПК Пойми в чём тут дело? С perl и python всегда так.

ПК downloading servers from
http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x
ПК Traceback (most recent call last):
ПК File /usr/bin/pyzor, line 8, in ?
ПК pyzor.client.run()
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
1003,
ПК in run
ПК ExecCall().run()
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
184, in
ПК run
ПК self.servers = self.get_servers(servers_fn)
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
409, in
ПК get_servers
ПК servers.read(open(servers_fn))
ПК File /var/lib/python-support/python2.4/pyzor/client.py, line
117, in
ПК read
ПК self.append(pyzor.Address.from_str(line))
ПК File /var/lib/python-support/python2.4/pyzor/__init__.py, line
458,
ПК in from_str
ПК fields[1] = int(fields[1])
ПК IndexError: list index out of range

Вот с python - да, сам регулярно вслух удивляюсь. Вроде бы язык не
способствует неаккуратности, а поди ж ты... А с perl - нет.

ПК Всё дело в том, что сильно высокие языки много от программиста
ПК скрывают, упрощают ему жизнь так сказать. Он по этому и не знает,
ПК что мир реально сложнее устроен.

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

ПК По этому - чуть шо, получаем какую-то ругань, никому, кроме
ПК потенциального хакера не полезную. По ней же ничё не скажешь, кроме
ПК версии python.

Ну почему ничё? Хотя у перла, как мне кажется, обычно с руганью
лучше, но и тут, в общем, можно сказать, что именно слетело. Нету в
fields второго элемента. На C ты в этом месте, вероятно, получил бы
сегфолт. Ну или (если бы сегфолт вылетел в твоих тестах и ты бы
закрылся от него проверкой) невнятное сообщение мама, тут чего-то не
хватает.

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

Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 15:20 +0300, Alexey Pechnikov пишет:
Hello!

On Tuesday 17 March 2009 13:44:05 Покотиленко Костик wrote:
Хорошее решение то, что работает.

Т.е. mysql-demon в KDE4 хорошее решение? И spamassassin тоже хорошее
решение - так что же вы его выше так ругали?

Примерно так же можно сказать - хорошая еда, которая пахнет. А пахнет розами
или помоями вам, как видно, все равно...

Ребята, которые запхнув mysql-demon в KDE4 решили свою узкую задачу, так
сказать не затрачивая драгоценного времени программиста на придумывание
чего-то более подходящего, т.к. память и MIPS'ы дешёвые.

Поскольку в мире бесплатного ПО претензии предъявлять не этично, Вам
остаётся либо убедить их исправить положение, либо исправить самому.

А мне остаётся только радоваться, что пока такое не произошло с Гномом,
на котором сижу я.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 21:41 +0900, Alexander Danilov пишет:
chaos пишет:
On 17 March 2009 05:33:33 Alexander Danilov wrote:
Aleksey Cheusov пишет:
Программное использование gdb - это, конечно, лучше, чем ручное. Но
хуже, чем такое программирование, где gdb использовать не требуется.
Не верю, что в сложных проектах можно обойтись без дебагера.
В сложных проектах нужно писать тесты. И в простых тоже.
Тогда дебаггер не понадобится.
Тесты конечно хорошо, но очень важно правильно спроектировать систему.
Заметил такую интересную тенденцию, в системах со слабо связанными модулями
отладчик не нужен, максимум - печать промежуточных значений. В тех же
системах, где модули привязаны друг к другу намертво, отладчик -
единственная надежда разобраться хаосе, чтобы потом всё переделать с нуля.

Любимое занятие :) переделывать всё с нуля :)
У меня есть опыт правки чужого кода, так вот, то, что мне попадалось лучше
было бы
переделать с нуля.

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

Мало того, я часто вступаю в ступор на некоторое время пытаясь въехать о
чём я думал когда писал код несколько лет назад. В свой, конечно, я
въезжаю через время.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 21:47 +0900, Alexander Danilov пишет:
Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
19:04:24 +0200:

[skip]

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

Решал много проблем такого рода, не так уж и сложно. Идёшь по пятам
аномалий и приходишь к источнику, и, дебагер тут может быть помощником.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 16:30 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
 12:47:18 +0200:
 
В случае, если SMTP, FTP, HTTP были бинарные:
- плагины для сниферов: которые есть для текстовых вариантов, для
бинарных разработка по времени такая же
   
   В случае текстовых протоколов разработка плагина не требуется.
   
- любой клиент этих протоколов итак делает преобразования протокол -
CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
строку, что бы прочитать последний элемент.
   
   И что же парсит и преобразует telnet при работе в качестве клиента
   SMTP?
 
  ПК Он то ничего не парсит, пользователя telnet'а приходится парсить.
 
 Ты опять все понимаешь с точностью до наоборот.  Пользователь telnet
 _имеет возможность_ провести диалог с сервером, не будучи _вынужден_ для
 этого пользоваться специальным инструментом.  Который с шансами будет
 малость, а то и немалость, устаревшим, и поддерживать не все особенности
 протокола.
 
 Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP.  У
 которого мне, помнится, не удалось найти средства прервать диалог после
 команды DATA, но до вкармливания в сервер собственно письма.
 
 Так-то он весь из себя хороший, и пользоваться им для тестирования
 конструкции со STARTTLS куда удобнее, чем руками...  Но вот пары нужных
 фич не умеет - и до свидания.  И что б я делал, будь там бинарный
 протокол?  Разбирался бы в его коде, чтобы туда эту возможность
 дописать?  А если бы он при этом еще и был написан с использованием
 сишной библиотеки реализации протокола, и этой возможности не было бы в
 _ее_ интерфейсе?

Это вопрос дисциплины. Бинарь к ней, кстати, располагает все сравнения с
текстом.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 17:58 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
16:34:34 +0200:

И что же парсит и преобразует telnet при работе в качестве клиента
SMTP?

ПК Он то ничего не парсит, пользователя telnet'а приходится парсить.

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

Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP. У
которого мне, помнится, не удалось найти средства прервать диалог после
команды DATA, но до вкармливания в сервер собственно письма.

Так-то он весь из себя хороший, и пользоваться им для тестирования
конструкции со STARTTLS куда удобнее, чем руками... Но вот пары нужных
фич не умеет - и до свидания. И что б я делал, будь там бинарный
протокол? Разбирался бы в его коде, чтобы туда эту возможность
дописать? А если бы он при этом еще и был написан с использованием
сишной библиотеки реализации протокола, и этой возможности не было бы в
_ее_ интерфейсе?

ПК Это вопрос дисциплины. Бинарь к ней, кстати, располагает все сравнения с
ПК текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.

сорьки.

-все+вне

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Творить - не делать! (c)Элхэ Ниеннах

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве клиента
SMTP?

ПК Он то ничего не парсит, пользователя telnet'а приходится парсить.

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

Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP. У
которого мне, помнится, не удалось найти средства прервать диалог
после
команды DATA, но до вкармливания в сервер собственно письма.

Так-то он весь из себя хороший, и пользоваться им для тестирования
конструкции со STARTTLS куда удобнее, чем руками... Но вот пары
нужных
фич не умеет - и до свидания. И что б я делал, будь там бинарный
протокол? Разбирался бы в его коде, чтобы туда эту возможность
дописать? А если бы он при этом еще и был написан с использованием
сишной библиотеки реализации протокола, и этой возможности не было бы
в
_ее_ интерфейсе?

ПК Это вопрос дисциплины. Бинарь к ней, кстати, располагает все
сравнения с
ПК текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.

ПК сорьки.

ПК -все+вне

Заголовки этого письма составляют: 5189 байт
Текст этого письма с подписями: 2104 байт
КПД: 2104/(5189+2104)=~29%

Письмо, я бы сказал, среднего размера.

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

Кстати, какая это версия протокола, где посмотреть формат, чтоб написать парсер?
Допустим, есть задача сделать формат хранения почты так, чтобы каждый элемент
заголовка (каждый Received: и т.п. раскладывался на составляющие) хранился
отдельно, индексировался, и по нему можно было производить поиск.
Может есть готовые парсеры, способные раскладывать всё, что используется в
SMTP/mbox на мельчайшие детали?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 18:15 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
 14:42:23 +0200:
 
   Перл бы еще рассказал, с какими аргументами была вызвана функция, что
   позволило бы найти ошибку гораздо быстрее.
 
  ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.
 
 Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
 в лучшем случае название слышал...

Это не продуктивный стиль общения.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 20:37 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Tuesday 17 March 2009 19:33:16 Yuri Kozlov wrote:
   Ну так как, пробовать будем?
 
  Неа.
 
  Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
  файлов. Или Вы считаете их равнозначными задачами?
 
 Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с 
 цисок и других АТС. Написать то же самое на С большая работа (на тикле 
 используются события для прослушивания множества сокетов, а на С придется 
 создавать отдельные потоки),

Кто тебе такое сказал? Если за последнюю пару лет ничего не изменилось
то в Линуксе осталось несколько ситуаций блокирующих программу, это
работа с диском и штатный DNS резолвинг, может ещё чего.

А работа с пайпами и сокетами в любом количестве сто лет может
производиться без блокировок одним процессом.

  потому и не предлагаю как тестовую задачу (притом 
 демоны умеют держать в in-memory SQLite database те данные, которые не 
 удалось 
 записать в persistent database), не говоря уж о реализации самой логики 
 обработки.
 
 А в той задаче, что я предлагал выше, есть как минимум несколько неочевидных 
 вещей, без знания которых ваша реализация на С будет работать намного хуже 
 тиклевской. Например, реализовать с нуля эффективный хэш с текстовыми 
 ключами далеко не так просто, как кажется. И стоит в задаче с парсером лога 
 указать, к примеру, 100 параметров командной строки, как ваша реализация 
 станет весьма медленной (и уверен, вы бы и не подумали об этом, в то время 
 как 
 создатели tcl подумали за вас). Есть и другие подводные камни. В итоге 
 написать на С код приличного качества требует кучу времени даже в том случае, 
 когда вы знаете, как это сделать.

Приличное качество на любом языке требует кучу времени.

  Когда-то я встраивал в свои С++ приложения 
 несложный интерпретатор, но после перехода с perl на tcl все приложения делаю 
 на tcl, при необходимости реализуя некоторые модули на C (и смог забыть С++, 
 как страшный сон). В свое время мне довелось писать на С для 
 микроконтроллеров, так вот, написать код  и обеспечить стабильную работу 
 прошивки на С, которая работает со встроенной флэшью, GPS и GSM-модулями, 
 потребовало несколько недель (в те времена используемый data-канал GSM был 
 очень неустойчив, но это отдельный разговор). На тикле можно написать 
 эквивалентную функциональность за пару дней.
 
 Best regards.
-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 17:21 +0200, chaos пишет:
On 17 March 2009 17:15:16 Artem Chuprina wrote:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
14:42:23 +0200:
Перл бы еще рассказал, с какими аргументами была вызвана функция, что
позволило бы найти ошибку гораздо быстрее.

ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.

Для фундаментальных задач хороши инструменты, от которых ты, подозреваю,
в лучшем случае название слышал...

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

Моя версия на вскидку:
- серверные приложения, демоны, пример:
- spamassassin
- системные приложения, пример:
- init-скрипты
- агенты по сбору счётчиков от munin-node вместе с ним

Дополняйте.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 20:25 +0200, Тихон Тарнавский пишет:
On Tue, 17.03.2009 19:45:14 , Покотиленко Костик wrote:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве
клиента
SMTP?

ПК Он то ничего не парсит, пользователя telnet'а приходится
парсить.

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

Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP.
У
которого мне, помнится, не удалось найти средства прервать диалог
после
команды DATA, но до вкармливания в сервер собственно письма.

Так-то он весь из себя хороший, и пользоваться им для тестирования
конструкции со STARTTLS куда удобнее, чем руками... Но вот пары
нужных
фич не умеет - и до свидания. И что б я делал, будь там бинарный
протокол? Разбирался бы в его коде, чтобы туда эту возможность
дописать? А если бы он при этом еще и был написан с
использованием
сишной библиотеки реализации протокола, и этой возможности не
было бы в
_ее_ интерфейсе?

ПК Это вопрос дисциплины. Бинарь к ней, кстати, располагает все
сравнения с
ПК текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.

ПК сорьки.

ПК -все+вне

Заголовки этого письма составляют: 5189 байт
Текст этого письма с подписями: 2104 байт
КПД: 2104/(5189+2104)=~29%

Письмо, я бы сказал, среднего размера.

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

Что до сложности формата mbox по сравнению с бинарными, звучит,
признаться, даже смешно. Когда мне нужно было выдернуть несколько
полей из большого количества писем и что-то с ними сделать, я решил
всю задачу на sh+coreutils+grep быстрее, чем в описании бинарного
формата нашёл бы и прочитал спецификации на эти поля и функции их
выдёргивания.

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 22:03 +0300, Alexey Pechnikov пишет:
Hello!

On Tuesday 17 March 2009 21:39:19 Покотиленко Костик wrote:
Что до сложности формата mbox по сравнению с бинарными, звучит,
признаться, даже смешно. Когда мне нужно было выдернуть несколько
полей из большого количества писем и что-то с ними сделать, я решил
всю задачу на sh+coreutils+grep быстрее, чем в описании бинарного
формата нашёл бы и прочитал спецификации на эти поля и функции их
выдёргивания.

Распарсить и засунуть в БД. Каким местом парсер связан с индексацией?

Где такой парсер взять, чтоб любое сообщение отпарсил подробно?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 21:33 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Tuesday 17 March 2009 21:06:58 Alexander GQ Gerasiov wrote:
   Есть у меня и демоны на тикле, например, собирают и обрабатывают
   данные с цисок и других АТС. Написать то же самое на С большая работа
   (на тикле используются события для прослушивания множества сокетов, а
   на С придется создавать отдельные потоки), потому и не предлагаю как
   тестовую задачу (притом демоны умеют держать в in-memory SQLite
   database те данные, которые не удалось записать в persistent
   database), не говоря уж о реализации самой логики обработки.
 
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
  соответствующие примитивы.
 
 Обращаю ваше внимание на постановку задачи:
 Никаких внешних библиотек не используем, только встроенные средства.

Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
или .Net или что там у них сейчас.

 Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по 
 рецепту 
 Остапа Бендера.

Только за GLib убивать не стоит, за QtCore наверное тоже.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-17 Пенетрантность Покотиленко Костик

В Вто, 17/03/2009 в 21:38 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Tuesday 17 March 2009 21:14:37 Покотиленко Костик wrote:
   Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с
   цисок и других АТС. Написать то же самое на С большая работа (на тикле
   используются события для прослушивания множества сокетов, а на С придется
   создавать отдельные потоки),
 
  Кто тебе такое сказал? Если за последнюю пару лет ничего не изменилось
  то в Линуксе осталось несколько ситуаций блокирующих программу, это
  работа с диском и штатный DNS резолвинг, может ещё чего.
 
  А работа с пайпами и сокетами в любом количестве сто лет может
  производиться без блокировок одним процессом.
 
 Между теорией на практикой в теории нет никакой разницы, а на практике - 
 наоборот.
  Тот же apache вовсе не случайно для каждого соединения отдельный 
 поток создает. Так что сначала попробуйте, прежде чем советовать. 

Ничего случайно не бывает.
В случае с apache, на мой взгляд, дело в архитектуре.

Грубо говоря, Apache с одной стороны читает с диска, с другой пишет с
сокет. Работа с сокетом может производиться без блокировок, с диском
нет, следовательно один процесс много клиентов не потянет, начнутся
лаги. С другой стороны только один процесс может слушать порт (80), он
может делать accept() и потом fork() передавая установленное соединение
потомку. Ждать 5 соединений и потом делать fork() не вариант.

Если изменить архитектуру так:
- один процесс принимает все соединения с одной стороны, и общается с
несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
количестве равном количеству ядер
- процессы выполняющие вычисления читают данные через процессы работы с
дисками (по одному на каждый физический диск), выполняют обработку,
отдают результат главному, тот клиенту
- процессы работы с дисками обрабатывают чтение запись и всё.

С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
клиентов будет 7 процессов.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Покотиленко Костик

В Птн, 13/03/2009 в 21:49 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Fri, 13 Mar 2009 
 19:56:06 +0200:
 
  Вот, навскидку назвал, и 
  это несмотря на то, что вы привели список _консольных_ утилит в 
 основном.
  
  Просто для информации: к любой консольной утилите (у которой есть 
 stdin
  и stdout) веб-морду можно приделать как два пальца об асфальт.
  
 Осталось только узнать зачем.
   
ПК Вот-вот.
   
ПК Плохая практика: прога с CLI + фронтенд
ПК Хорошая практика: прога с CLI -- либа -- прога с GUI
   
   То, что ты назвал плохой практикой - unix way, и тот факт, что эта
   практика - плохая, требует обоснования.  Нет, я не утверждаю, что
   браузер - достаточно хороший гуй, а HTTP - достаточно хороший протокол,
   чтобы тыкать их во _все_ дырки...  Фронтенд совершенно не обязательно
   должен работать по HTTP...
   
   Ну и да, по ходу дела ты, по сути, записал в плохую практику
   практически все клиент-серверные решения.  Начиная с SMTP и HTTP :-)
 
  ПК Не так. Не путай клиент-серверное решение и IPC с фронтендом :). Разница
  ПК очевидна:
 
  ПК 1. IPC: связь нескольких процессов в пределах одной машины
 
  ПК 2. клиент-серверное решение: связь нескольких процессов работающих на
  ПК разных машинах
 
 Это разделение уже изрядно условно.  Так, во-первых, я хожу к
 IMAP-серверу своего ноутбука вне зависимости от того, на том же ноутбуке
 у меня гнус или на совершенно другой машине.
 
 Во-вторых, и к нему, и к заведомо удаленному IMAP'у основной почтовки я
 хожу ... правильно, по IPC.  Этот IPC транслируется на удаленный хост
 посредством ssh, но и gnus, и imapd видят пайпы к локальному процессу.
 Точнее, emacs и imapd видят пайпы, а гнусу безразлично, пайп там или
 сокет, он видит вообще буфер.
 
 Я уж молчу про erlang (как язык) и прочие средства кластерной работы.  У
 них, я извиняюсь, задача _заключается в_ том, чтобы не было разницы, на
 одной машине оно выполняется или на разных.
 
 Ну и да, еще можно вспомнить про системы виртуализации и отношение их с
 лицензиями на софт :-)  А они даже у микрософта учитывают разницу между
 виртуальной и физической машиной.

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

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

Как тут любят цитировать: инструмент используемый не по назначению имеет
свойство превращаться в грабли.

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

однако следует понимать, что:
- универсальных методов не бывает :). Для каждой задачи хорош свой
метод: ограничено время для написания функционала - используй скриптовый
язык, нужна производительность и компактность - используй язык более
низкого уровня. 
- то же касается и других универсальных методов, например, трюки с IPC:
проброс пайпа на другую машину и т.п. Это хорошо, так как быстро, но
даже тут много нюансов, лично сталкивался.
- на счёт текстовых протоколов всё гораздо загадочнее для меня. Дело в
том, что протоколы отличаются от тех же скриптов тем, что
разрабатываются они, грубо, один раз, а используются везде и большим
количеством людей.

Преимущество текстового протокола только в том, что его более удобно
читать человеку, а недостатков гораздо больше. Читать бинарные данные и
парсить текст - это несоизмеримо разные процедуры в плане
производительности.

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

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

$ progA | ssh u...@host progB

progA записывает каманду в вывод, команда улетает мгновенно в буфер ssh,
в случае простого протокола, без подтверждения доставки progA будет
считать команду доставленной, хотя на самом деле это ещё не так. Кроме
того часто тяжело заставить команды приходить раздельными порциями.

  ПК 3. фронтенд: использование функционала программы с одним интерфейсом в
  ПК другой программе с другим интерфейсом посредством чего-либо, в том числе
  ПК и IPC.
 
  ПК Во вменяемых ресурсах по написанию программ так и написано: функционал
  ПК нужно отделять от интерфейса. Это для многих сложно, но на то есть свои
  ПК причины, и от того есть много преимуществ.
 
  ПК В проектах, где следуют такому принципу, фронтендами редко пахнет, так

Re: Lenny. Как открыть обычный *.log файл с помощью gedit?

2009-03-16 Пенетрантность Покотиленко Костик

В Суб, 14/03/2009 в 05:50 -0400, Mark Goldshtein пишет:
2009/3/14 Artem Chuprina ran@:
Mark Goldshtein - Debian Russian Mailing List @ Fri, 13 Mar 2009 18:28:56
-0400:

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

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

Английским по бэкграунду я понимаю хорошо :)
Перебрал много кодировок - всё равно не открывает.

Придётся на самом деле доставлять какой-нибудь ещё редакторчик... :(

попробуй это:
gnome-system-log
или это:
gksu gnome-system-log

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Суб, 14/03/2009 в 12:18 +0300, Artem Chuprina пишет:
Aleksey Cheusov - debian-russian@lists.debian.org @ Sat, 14 Mar 2009
00:22:23 +0200:

Ну и если вам понадобился gdb, значит, вы как-то не так
программируете...
AC http://sf.net/projects/lmdbg

AC Тамошняя программа lmdbg-sym при помощи gdb преобразует адреса в
AC файлы исходного кода и номера строк полного stacktrace-а вызова
AC malloc/free etc. Это позволяет помодульно анализировать код
AC программы на предмет потребления памяти. Идея использовать для
AC этого gdb в _командном_ режиме честно заимствована из ccmalloc. Но
AC там оно прибито гвоздями на С... В общем, есть разные способы
AC применения gdb. И естественно malloc/free-ями дело не
AC ограничивается.

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

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

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Суб, 14/03/2009 в 10:30 +0900, Alexander Danilov пишет:
 Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 23:24 +0900, Alexander Danilov пишет:
  Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 14:39 +0300, Victor Wagner пишет:
  On 2009.03.13 at 11:38:27 +0200, Покотиленко Костик wrote:
 
  Вот-вот.
 
  Плохая практика: прога с CLI + фронтенд
  Хорошая практика: прога с CLI -- либа -- прога с GUI
  Абсолютно не факт. первый вариант выносит содержательные действия в
  отдельный процесс, существенно упрощает отладку и облегчает избавление
  от блокировок GUI, когда программа занята чем-нибудь важным.
 
  В 90% случаев, на которые мне приходилось смотреть в дистрибутиве
  (естественно, это далеко не все библиотеки, которые в нем есть) 
  авторы библиотек не имели не малейшего понятия, как следует дизайнить
  интерфейсы библиотек. А это, между прочим, гораздо более сложная задача
  чем дизайн CLI, заточенного под встраивание.
 
  Ну и покрыть функциональность автоматизированными тестами в случае CLI
  гораздо проще.
  Ни капли не согласен, особенно когда участвуют циклы. CLI-GUI не проще
  ни разу, ни в разработке, ни в использовании, ни в отладке. Кроме,
  конечно, случая, когда разработчик не умеет либы писать.
 
  Проще, надо только понимать, что проще не в Си, я в языках, в которых есть 
  нормальная обработка
  событий, например, :) Tcl. Можно рулить одновременно многими cli 
  процессами, в том числе и 
  одинаковыми, а вот на Си, это будет не так уж просто. А в питоне или ruby 
  есть событийная обработка 
  на сокетах или каналах ввода/вывода?
  
  Ты на Си в музее смотрел?
  
 
 И давно на Си можно сделать событийную обработку канала или сокета в ТРИ 
 строки?

Вот универсальная конструкция для select:

char strtmp[1024];
struct timeval tv;
int retval;

fd_set rfds;
fd_set wfds;

for(;;) {

FD_ZERO(rfds);
FD_ZERO(wfds);
FD_SET(0, rfds);
FD_SET(1, wfds);

tv.tv_sec = 5;
tv.tv_usec = 0;

retval = select(1, rfds, wfds, NULL, tv);

if(retval0) {

/* Processing connections */
if(FD_ISSET(0, rfds)) {
// read(0, buf, 1024);
}
if(FD_ISSET(1, wfds)) {
// write(1, buf, 1024);
}
} else if(retval==-1) {
if(errno!=4) {  /* Interrupted system call, we get that for SIGHUP
*/
sprintf(strtmp, Select failed: errno=%d, %s, errno,
strerror(errno));
write(2, strtmp, strlen(strtmp));
exit(5);
} else {
sprintf(strtmp, Select failed: errno=%d, %s, (Interrupted 
system
call, we get that for SIGHUP)\n, errno, strerror(errno));
write(2, strtmp, strlen(strtmp));
}
} else {
}
}


-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Птн, 13/03/2009 в 21:44 +0200, Тихон Тарнавский пишет:
 On Fri, 13.03.2009 20:09:00 , Покотиленко Костик wrote:
  В Птн, 13/03/2009 в 13:10 +0300, Artem Chuprina пишет:
   Владимир Ступин - debian-russian@lists.debian.org  @ Fri, 13 Mar 2009 
   14:56:15 +0500:
   
  ПК Плохая практика: прога с CLI + фронтенд
  ПК Хорошая практика: прога с CLI -- либа -- прога с GUI
   
 Ну и да, по ходу дела ты, по сути, записал в плохую практику
 практически все клиент-серверные решения.  Начиная с SMTP и HTTP :-)
   
ВС Здесь наверное имелся в виду пример curl и libcurl. Впрочем,
ВС наличие библиотеки не обязывает пользоваться именно ею, можно
ВС пользоваться возможностями библиотеки и через CLI-программу. Но мне
ВС кажется, что выделить функционал программы в библиотеку - это более
ВС гибкий подход, который удовлетворит приверженцев любого лагеря:
ВС пользователей CLI, GUI и Web-интерфейсов.
   
   Моя практика показывает, что в норме приделать к CLI-программе гуй на
   скриптовом языке гораздо проще, чем сделать для этого же скриптового
   языка обвязку вокруг библиотеки.  Хотя, конечно, если ее уже кто-то за
   тебя сделал...
   
   Нет, я не утверждаю, что выделять библиотеку плохо.  Это хорошо, ибо
   повышает гибкость.  Я утверждаю, что заносить unix way в плохую практику
   не следует...
  
  Не путайте unix-way c ,  и |
  
  Первое включает второе, но не ограничивается им.
  
   Но если уж на то пошло, то для _взаимодействия_ с функциональностью
   программы я предпочитаю клиент-серверную модель, причем с _текстовым_
   протоколом.  Чтобы можно было сходить туда вручную и почитать ее ответы
   глазами.  Вот SMTP, FTP и HTTP в этом смысле хорошие примеры.
  
  Если лень писать инструменты для работы с бинарными данными, остаётся
  единственное направление движения - в сторону SMTP, FTP, HTTP, XML,
  BASE64 и другого говна(сори).
  
  Пора, наконец, понять - машина работает в бинаре, ей так удобнее, в нём
  она быстрей, так меньше нюансов, так больше энтропия и КПД.
  
  Человек так не может, поэтому преобразования целесообразнее применять
  ТОЛЬКО на входе и на выходе.
  
  Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо, но
  старомодно.
 Очень советую почитать http://www.ozon.ru/context/detail/id/2317804/
 Многое расставит на места.

В ответ посоветую:
http://www.ozon.ru/context/detail/id/1335648/
http://www.ozon.ru/context/detail/id/2527041/
http://www.ozon.ru/context/detail/id/2527036/

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Птн, 13/03/2009 в 22:21 +0300, Иван Лох пишет:
On Fri, Mar 13, 2009 at 08:09:00PM +0200, Покотиленко Костик wrote:

Пора, наконец, понять - машина работает в бинаре, ей так удобнее, в нём
она быстрей, так меньше нюансов, так больше энтропия и КПД.
Человек так не может, поэтому преобразования целесообразнее применять
ТОЛЬКО на входе и на выходе.

Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо, но
старомодно.

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

Про энтропию, КПД и то как работает машина Вы лучше учебник почитайте.
Насчет бинарных нюансов, один endian чего стоит. Про старомодность HTTP я
долго ржал.

P.S. Я не против библиотек. Я за. Я против разработки библиотеки для одного
приложения. Или двух.

Кто знает? GTK+ разрабатывался чисто под Gimp, а сейчас...

То, что так учат делать в ПТУ, связано с особенностями
дизайна M$ windows, где остальные пути еще кривей. Но при чем тут мы?

Не знаю, под винду меня не учили сильно.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Птн, 13/03/2009 в 22:11 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Fri, 13 Mar 2009
20:09:00 +0200:

Нет, я не утверждаю, что выделять библиотеку плохо. Это хорошо, ибо
повышает гибкость. Я утверждаю, что заносить unix way в плохую практику
не следует...

ПК Не путайте unix-way c , и |

ПК Первое включает второе, но не ограничивается им.

Это только подтверждает мою мысль.

ПК Пора, наконец, понять - машина работает в бинаре, ей так удобнее, в
ПК нём она быстрей, так меньше нюансов, так больше энтропия и КПД.

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

А _нам_ всяко удобнее сказать cp этот_файл туда, чем городить
неудобоваримую конструкцию из open/read/write/close, или mv этот_файл
туда, чем разбираться, надо городить open/read/write/close, или можно
ограничиться link. Эти танцы за нас может станцевать и машина, она,
блин, для того и придумана.

Как говорит мой дядя, давайте купим мерседес и будем катать его за собой
на верёвочке...

ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо,
ПК но старомодно.

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

Спорить не вижу смысла, я Ваш подход понял.

...однако все владельцы смартфонов недовольны их производительностью,
почему бы???

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 14:15 +0300, Alexey Pechnikov пишет:
Hello!

On Monday 16 March 2009 13:06:13 Покотиленко Костик wrote:
однако следует понимать, что:
- универсальных методов не бывает :). Для каждой задачи хорош свой
метод: ограничено время для написания функционала - используй скриптовый
язык, нужна производительность и компактность - используй язык более
низкого уровня.

Время ограничено _всегда_. Понимаете, физиологические процессы необратимы,
поэтому бесконечного времени на одну задачу у живого существа не будет
никогда.

Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
частого сбора сотен показаний.

Дальше, если скармливать нужные счётчики и выводить их за один проход -
можно обрабатывать теоретически неограниченное количество счётчиков за
проход без дополнительных расходов.

Дольше, если превратить этот код в демон, можно значительно сократить
расходы связанные с частым сбором.

Тот же самый демон намного быстрее написать на скриптовом языке. Существенная
разница в производительности будет только на этапе загрузки, что для демона
несущественно в принципе. Зато отладка будет намного эффективнее, не нужно
перекомпилировать под разные архитектуры и проч. Так что вот как раз демон
писать на С не имеет смысла. Как вы думаете, почему в /etc/init.d/ лежат
шелловские скрипты?..

Глупость века?

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 14:38 +0300, Alexey Pechnikov пишет:
 Hello!
 
 On Monday 16 March 2009 14:28:11 Михаил Миронов wrote:
  Демоны почему-то чаще всего пишут не на скриптовых языках. 
 
 Ошибаетесь. Большинство написанных в последние несколько лет демонов как раз 
 скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень 
 много 
 написано на скриптовых языках. 

Время покажет плюс это или минус.

  И скажите,
  неужели Вы думаете, что в /etc/init.d лежат сами исполняемые файлы
  демонов???
 
 За счет того, что демон запускается шелловским скриптом, теряется 
 единственное 
 преимущество - скорость запуска.
 
 Best regards.
-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 15:06 +0300, Михаил Миронов пишет:
 Alexey Pechnikov пишет:
  Hello!
  
  On Monday 16 March 2009 14:28:11 Михаил Миронов wrote:
  Демоны почему-то чаще всего пишут не на скриптовых языках. 
  
  Ошибаетесь. Большинство написанных в последние несколько лет демонов как 
  раз 
  скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же очень 
  много 
  написано на скриптовых языках. 
  
 
 
 Проверил список демонов на одной из машин
 snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog,
 mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще
 несколько других - все не скриптовые.
 Единственный найденный скриптовый - xen

spamassassin тоже скриптовый, но это его минус, причём большой.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: lenny pidgin icq

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 12:50 +0100, Sergey Spiridonov пишет:
 Привет
 
 Sergey Spiridonov wrote:
Это только у меня такое?
  
  У меня стоит сейчас etch + gaim 2.0beta. Дома lenny + pidgin из lenny.
  Всё работает без проблем.
 
 Уточняю. Дома оказывается не работает. А на работе gaim из etch работает.
 
 Такие дела.
 
 Кто может объяснить?

сегодня в Lenny patch на эту темы пришёл.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 21:43 +0900, Alexander Danilov пишет:
 Покотиленко Костик пишет:
  В Суб, 14/03/2009 в 10:30 +0900, Alexander Danilov пишет:
  Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 23:24 +0900, Alexander Danilov пишет:
  Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 14:39 +0300, Victor Wagner пишет:
  On 2009.03.13 at 11:38:27 +0200, Покотиленко Костик wrote:
 
  Вот-вот.
 
  Плохая практика: прога с CLI + фронтенд
  Хорошая практика: прога с CLI -- либа -- прога с GUI
  Абсолютно не факт. первый вариант выносит содержательные действия в
  отдельный процесс, существенно упрощает отладку и облегчает избавление
  от блокировок GUI, когда программа занята чем-нибудь важным.
 
  В 90% случаев, на которые мне приходилось смотреть в дистрибутиве
  (естественно, это далеко не все библиотеки, которые в нем есть) 
  авторы библиотек не имели не малейшего понятия, как следует дизайнить
  интерфейсы библиотек. А это, между прочим, гораздо более сложная задача
  чем дизайн CLI, заточенного под встраивание.
 
  Ну и покрыть функциональность автоматизированными тестами в случае CLI
  гораздо проще.
  Ни капли не согласен, особенно когда участвуют циклы. CLI-GUI не проще
  ни разу, ни в разработке, ни в использовании, ни в отладке. Кроме,
  конечно, случая, когда разработчик не умеет либы писать.
 
  Проще, надо только понимать, что проще не в Си, я в языках, в которых 
  есть нормальная обработка
  событий, например, :) Tcl. Можно рулить одновременно многими cli 
  процессами, в том числе и 
  одинаковыми, а вот на Си, это будет не так уж просто. А в питоне или 
  ruby есть событийная обработка 
  на сокетах или каналах ввода/вывода?
  Ты на Си в музее смотрел?
 
  И давно на Си можно сделать событийную обработку канала или сокета в ТРИ 
  строки?
  
  Вот универсальная конструкция для select:
  
  char strtmp[1024];
  struct timeval tv;
  int retval;
  
  fd_set rfds;
  fd_set wfds;
  
  for(;;) {
  
  FD_ZERO(rfds);
  FD_ZERO(wfds);
  FD_SET(0, rfds);
  FD_SET(1, wfds);
  
  tv.tv_sec = 5;
  tv.tv_usec = 0;
  
  retval = select(1, rfds, wfds, NULL, tv);
  
  if(retval0) {
  
  /* Processing connections */
  if(FD_ISSET(0, rfds)) {
  // read(0, buf, 1024);
  }
  if(FD_ISSET(1, wfds)) {
  // write(1, buf, 1024);
  }
  } else if(retval==-1) {
  if(errno!=4) {  /* Interrupted system call, we get that for SIGHUP
  */
  sprintf(strtmp, Select failed: errno=%d, %s, errno,
  strerror(errno));
  write(2, strtmp, strlen(strtmp));
  exit(5);
  } else {
  sprintf(strtmp, Select failed: errno=%d, %s, (Interrupted 
  system
  call, we get that for SIGHUP)\n, errno, strerror(errno));
  write(2, strtmp, strlen(strtmp));
  }
  } else {
  }
  }
  
  
 Сударь, я спрашивал про 3 (ТРИ) строки, а в вашем примере только 
 инициализация занимает пол экрана, 
 так я ещё и не вижу где тут собыйтийная обработка данных, нет её тут.

Естественно не видите, мелко сильно.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 14:40 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
12:06:13 +0200:

ПК $ progA | ssh u...@host progB

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

Если она так думает в локальном случае, ее автора пора лечить :-) Никто
никому никогда не гарантировал мгновенной доставки в случае с локальным
пайпом.

ПК Кроме того часто тяжело заставить команды приходить раздельными
ПК порциями.

Это тоже от сети не зависит.

Потому что тогда не будет способа воспользоваться
функционалом :-)

Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
самым просто является таким же API, что и у библиотеки.

ПК Ну нет же. Разные они, если подробно разобраться. Учитывая
ПК вышесказанное, API - для низкоуровнего (производительного и компактного)
ПК программирования,

Преждевременная оптимизация - корень всех зол. (c) кто-то из великих.

ПК CLI - для юникс-юзера и скриптов (по быстрому на коленке).

ПК На пример, для сбора счётчиков правил iptables можно использовать
ПК обёртку вокруг iptables -nvL | iptables-save типа:

ПК iptables-save | grep условие | cut -d -fI

ПК или такую конструкцию на Си:

ПК ...
ПК struct ipt_entry *ipt_e;
ПК char *target;

ПК for(ipt_e=iptc_first_rule(chain_name, ipt_h); ipt_e;
ПК ipt_e=iptc_next_rule(ipt_e, ipt_h)) {

ПК if(!ipt_e) {
ПК printf(iptc_first_rule(): returned NULL pointer\n);
ПК return(NULL);
ПК }

ПК if(!условие) continue;

ПК target=iptc_get_target(ipt_e, ipt_h);

ПК printf(Source IP: %s/%s (iface: %s), Destination IP: %s/%s (iface: %
ПК s), Target: %s, Counters: %llu bytes, %llu packets\n,
ПК x_strcpy(inet_ntoa(ipt_e-ip.src)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.smsk)),
ПК ipt_e-ip.iniface,
ПК x_strcpy(inet_ntoa(ipt_e-ip.dst)),
ПК x_strcpy(inet_ntoa(ipt_e-ip.dmsk)),
ПК ipt_e-ip.outiface,
ПК target,
ПК ipt_e-counters.bcnt,
ПК ipt_e-counters.pcnt
ПК);

ПК }
ПК ...

ПК Первый вариант делается за 5 минут, подойдёт для не частого сбора
ПК небольшого числа счётчиков.

ПК Второй вариант страшный, пока первый раз не сделаешь. Подойдёт для
ПК частого сбора сотен показаний.

Я бы уже задумался о том, что узкое место такой системы - не в сборе
показаний...

ПК Дальше, если скармливать нужные счётчики и выводить их за один проход -
ПК можно обрабатывать теоретически неограниченное количество счётчиков за
ПК проход без дополнительных расходов.

Это как раз автомагически получается с iptables -L. На C тебе для этого
придется громоздить изрядную конструкцию (фактически, разрабатывать
половину перла). Оно окупится? У меня есть сомнения...

Уже окупилось. На системе где так работает после таких оптимизаций прогу
передающую счётчики в snmpd в top'е не видно, а snmpd иногда до 10% CPU
тратит. Следующим шагом, там от snmp откажусь в пользу самописного
демона, проблема иссякнет.

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

ПК Да, но это тоже, что и бегать в чугунных сапогах.

Результаты профайлинга предъяви, да?

Есть конкретный пример? С профайлингом на Ваш любимый скриптовый
язык...

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 15:56 +0200, Тихон Тарнавский пишет:
On Mon, 16.03.2009 12:42:58 , Покотиленко Костик wrote:
В Птн, 13/03/2009 в 21:44 +0200, Тихон Тарнавский пишет:
On Fri, 13.03.2009 20:09:00 , Покотиленко Костик wrote:
В Птн, 13/03/2009 в 13:10 +0300, Artem Chuprina пишет:
Владимир Ступин - debian-russian@lists.debian.org @ Fri, 13 Mar
2009 14:56:15 +0500:

ПК Плохая практика: прога с CLI + фронтенд
ПК Хорошая практика: прога с CLI -- либа -- прога с GUI

Ну и да, по ходу дела ты, по сути, записал в плохую практику
практически все клиент-серверные решения. Начиная с SMTP и HTTP
:-)

ВС Здесь наверное имелся в виду пример curl и libcurl. Впрочем,
ВС наличие библиотеки не обязывает пользоваться именно ею, можно
ВС пользоваться возможностями библиотеки и через CLI-программу. Но
мне
ВС кажется, что выделить функционал программы в библиотеку - это
более
ВС гибкий подход, который удовлетворит приверженцев любого лагеря:
ВС пользователей CLI, GUI и Web-интерфейсов.

Моя практика показывает, что в норме приделать к CLI-программе гуй на
скриптовом языке гораздо проще, чем сделать для этого же скриптового
языка обвязку вокруг библиотеки. Хотя, конечно, если ее уже кто-то за
тебя сделал...

Не путайте unix-way c , и |

Первое включает второе, но не ограничивается им.

Но если уж на то пошло, то для _взаимодействия_ с функциональностью
программы я предпочитаю клиент-серверную модель, причем с _текстовым_
протоколом. Чтобы можно было сходить туда вручную и почитать ее
ответы
глазами. Вот SMTP, FTP и HTTP в этом смысле хорошие примеры.

Если лень писать инструменты для работы с бинарными данными, остаётся
единственное направление движения - в сторону SMTP, FTP, HTTP, XML,
BASE64 и другого говна(сори).

Пора, наконец, понять - машина работает в бинаре, ей так удобнее, в нём
она быстрей, так меньше нюансов, так больше энтропия и КПД.

Человек так не может, поэтому преобразования целесообразнее применять
ТОЛЬКО на входе и на выходе.

Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо, но
старомодно.
Очень советую почитать http://www.ozon.ru/context/detail/id/2317804/
Многое расставит на места.

В ответ посоветую:
http://www.ozon.ru/context/detail/id/1335648/
http://www.ozon.ru/context/detail/id/2527041/
http://www.ozon.ru/context/detail/id/2527036/

Это к чему? Вы хоть предисловие к указанной книге прочитайте, там
написано, куда восходит её название.

Прочитал все три. Кучу примеров и домашних заданий порешал и
проанализировал. И?

И уж конечно ESR ни в чём Кнуту
не противоречит.

Ещё бы

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Функционал и интерфейс

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 16:35 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
14:36:44 +0200:

Демоны почему-то чаще всего пишут не на скриптовых языках.

Ошибаетесь. Большинство написанных в последние несколько лет демонов
как раз
скриптовые. Вот лет 10 назад да, писали на С в основном, сейчас же
очень много
написано на скриптовых языках.

Проверил список демонов на одной из машин
snmpd, courier-imap, courier-pop3, portmap, acpid, dbus, syslog, klog,
mysql, apache, cupsd, exim4, freeradius, smartmon, samba, winbind и еще
несколько других - все не скриптовые.
Единственный найденный скриптовый - xen

ПК spamassassin тоже скриптовый, но это его минус, причём большой.

Ты прав, не по тому пути они пошли, но их уже не догнать.

Пойми в чём тут дело? С perl и python всегда так.

downloading servers from
http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x
Traceback (most recent call last):
File /usr/bin/pyzor, line 8, in ?
pyzor.client.run()
File /var/lib/python-support/python2.4/pyzor/client.py, line 1003,
in run
ExecCall().run()
File /var/lib/python-support/python2.4/pyzor/client.py, line 184, in
run
self.servers = self.get_servers(servers_fn)
File /var/lib/python-support/python2.4/pyzor/client.py, line 409, in
get_servers
servers.read(open(servers_fn))
File /var/lib/python-support/python2.4/pyzor/client.py, line 117, in
read
self.append(pyzor.Address.from_str(line))
File /var/lib/python-support/python2.4/pyzor/__init__.py, line 458,
in from_str
fields[1] = int(fields[1])
IndexError: list index out of range

Минус его в том, что он умеет больше, чем следует :-) Отчего нередко
употребляется там, где следовало бы отшить супостата на этапе
SMTP-сессии. Или тогда же пометить как спам, не анализируя содержимого
письма вообще.

Ну, это лечится слава Богу.

--
Покотиленко Костик cas...@meteor.dp.ua

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

Re: Как спастись от mysql-server в KDE 4.2

2009-03-16 Пенетрантность Покотиленко Костик

В Пнд, 16/03/2009 в 16:28 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Mon, 16 Mar 2009 
 12:49:02 +0200:
 
ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо,
ПК но старомодно.
   
   С точностью до наоборот.  Ниши работы с машинным представлением - это
   криптография и сжатие данных.  Всё.  (Предвосхищая очевидное возражение
   - нет, кодирование изображения и звука уже не требует машинного
   представления: цвет точки, равно как и частота и амплитуда звука -
   понятия уже более абстрактные, и программы обработки уже с этими
   абстракциями работают, а бинарное их представление в конкретном формате
   уже можно отнести к сжатию данных, поскольку форматы без сжатия сейчас
   уже почти не применяются.)
 
  ПК Спорить не вижу смысла, я Ваш подход понял.
 
  ПК ...однако все владельцы смартфонов недовольны их
  ПК производительностью, почему бы???
 
 Ты серьезно полагаешь, что по причине текстовости протоколов!?

Нет, но корни те же.

-- 
Покотиленко Костик cas...@meteor.dp.ua


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

1 2 3 4 5 6 7 8 9 10 >

Результаты 1 - 100 из 943 matches

Mail list logo