Отправляет email-рассылки с помощью сервиса Sendsay

За 2005-05-22

Re: GPRS

Original Message From: "Begemot" <begemotina20***@m*****.ru>
To: "comp.soft.linux.discuss (3744067)" <_rad***@r*****.ru>
Sent: Sunday, May 22, 2005 5:55 PM
Subject: GPRS

> Здравствуйте, я новенький в рассылке. У меня возникла проблема с GPRS
> под Linux. Исходные данные такие: Linux Mandrake 9.1, ИК-порт Tekram
> IRmate-210, телефон Ericsson R520, сотовый оператор Мегафон (поля
> пользователь и пароль пустые)
>
> Я поднял соединение по инфрокраснику, у меня появилось устройство
> /dev/ircomm0
> А вот дальше у меня НИЧЕГО не получается... Все найденные в инете
> скрипты подключения у меня не работают. :-( Очевидно руки кривые...
> Помогите с настройкой!!!
>
> З.Ы. Прощу прощения если такой вопрос задавался и не раз.

Инит-строку модема и ДНС сервера прописывал ? Через какую утилиту
дозваниваешся ?

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 18856; Возраст листа: 667; Участников: 1356
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/371983

   2005-05-22 22:58:03 (#371983)

Автостарт KDE в FreeBSD 5.3

Можно ли как-нибудь из консоли сделать автостарт KDE ? А то ставлю фрю в варианте
X-Developer или X-User, добавляю потом полный KDE, она грузится в консоли. Пишу
startx, грузятся какие-то голые иксы с xterm и всё. Если написать startkde, то
вылазит ошибка (но вызвать отдельные приложения можно, написав название, например
KWrite и оно запустится):

xauth: creating new authority file /root/.Xauthtority

xauth: (argv):1 bad display name ":0" in "first" command

Fatal server error: Server is already active for display 0
If this server is no longer running, remove
/tmp/.X0-lock and start again

Пробовал удалять этот .X0-lock и перезапускать - не помогает.

Ещё: при конфигурации xorgcfg-textmode я настраивал клавиатуру, мышь, видеокарту,
монитор и экран (раб. стол). Все их имена заканчивались на 0. Т.е. Monitir0,
Video0, Screen0 ну и Mouse0 и Keyboard0. Тоесть видеосистема была сконфигурирована
как 0:0 (Screen0 в Video0), но запускаться она не хочет. Такая же ситуация наблюдается
и в MDK 9.2. Там если стоит графическая загрузка у пользователя, то KDE будет
стартовать, а если вызывать также из консоли, то будет вылетать примерно такая
же ошибка.
Видеокарта самая что ни на есть совместимоя - GeForce4 MX 440 SE
Вот я и подумал, что если можно сделать графическую загрузку, то эта проблема
исчезнет. Только каким образом ?

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 18855; Возраст листа: 667; Участников: 1356
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/371982

   2005-05-22 22:58:00 (#371982)

Как запустить Battlefield1942 через Cedega в Linux ?

Не получается его заинсталлить (под седегой 4.2-1) ни с компашки, ни с изошника
(под виндами всё ок). Версия игры - 1.0
В общем всё инсталлится, но в самом конце инсталляция растягивается на бесконечное
время. Ей остаётся только распаковать файл bf1942.exe и прописать значения в
седеговский реестр, но компакт (или изо-образ) просто перечитывается без конца
и всё. Как его поставить ? Может версия игры не та ? Используется Linux Mandrake
9.2 с ядром 2.4.22

Попробовал заинсталлить его через инсталятор Battlefieeld1942-чего-то-там-версия
1.6.run, взятый на сайте Линуксцентра, но этот инсталлятор при установке требует
оригинальный первый диск от этой игры (У меня обычная однодисковая пиратская
версия 1.4). Как же всё-таки заставить эту игру играться под Линуксом ? У других
вроде бы получается. А если он и требует оригинальные CD, то какая версия игры
ему нужна (помимо требования к версии 1.6), их ведь несколько - обычная, Road
to Rome, Secret WWII и ещё какие-то две.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 18854; Возраст листа: 667; Участников: 1356
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/371975

   2005-05-22 22:27:24 (#371975)

GPRS

Здравствуйте, я новенький в рассылке. У меня возникла проблема с GPRS
под Linux. Исходные данные такие: Linux Mandrake 9.1, ИК-порт Tekram
IRmate-210, телефон Ericsson R520, сотовый оператор Мегафон (поля
пользователь и пароль пустые)

Я поднял соединение по инфрокраснику, у меня появилось устройство
/dev/ircomm0
А вот дальше у меня НИЧЕГО не получается... Все найденные в инете
скрипты подключения у меня не работают. :-( Очевидно руки кривые...
Помогите с настройкой!!!

З.Ы. Прощу прощения если такой вопрос задавался и не раз.

   2005-05-22 22:26:50 (#371973)

Re: Совместный доступ к конфигурации

В сообщении от 1116761988 секунд после начала Эпохи Unix Я написал:

> Буду смотреть в сторону датаграммныных гнезд...

Хм... Оказывается датаграммныные гнезда в домене Unix работают только в
одном направлении. Сервер запросы получает, а ответить не может, так как
функция recvfrom возвратила пустой адрес клиента. Я что-то путаю, или
действительно при такой конфигурации возможна передача только в одном
направлении? Придется создавать еще по одному гнезду для каждого клиета?
Или нужно использовать поточное соединение?...

   Konstantin Korikov 2005-05-22 21:20:14 (#371958)

Re: Совместный доступ к конфигурации

В сообщении от 1116775148 секунд после начала Эпохи Unix Вы написали:

> > Это при чтении файла. А при записи? Как тогда записать ключи и
> > значения (возможно даже и комментарии), которые содержались в файле
> > при считывании, но небыли распознаны, и небыли занесены в ОЗУ?
> Нет при чтении надо распознавать все и хранить и имена ключей и их
> значения. Далее при изменении настроек нужно обновлять эту самую
> базу настроек. И тогда при записи в файл ничего не потеряется.

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

config
ключ1 = значение1
ключN = значениеN
1_ui
ключ1 = значение1
ключN = значениеN
N_ui
ключ1 = значение1
ключN = значениеN
default_account
ключ1 = значение1
ключN = значениеN
account_list
account1
ключ1 = значение1
ключN = значениеN
accountN
ключ1 = значение1
ключN = значениеN

Доступ к этому хозяйству в программе осуществляется примерно таким
образом:

config.ключ1
config.1_ui.ключ1
config.default_account.ключ1
accounts.get_account(1).ключ1

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

> > Думаю, много сложного из мира С превращается в легкое и простое в
> > мире Python. Мощь ООП + набор высокоуровневых инструментов делают
> > свое дело. Что самое удивительное - все работает быстро. Java
> > отдыхает!!! :-D
> Я о сложности архитектуры программы говорил. Ведь тут и CORBA
> можно использовать ;-)

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

   Konstantin Korikov 2005-05-22 20:39:41 (#371944)

Re: Совместный доступ к конфигурации

On Sun, 22 May 2005 16:22:52 +0300, Konstantin Korikov <lostcl***@u*****.fm> said:


> В сообщении от 1116765230 секунд после начала Эпохи Unix Вы
> написали:
>> Хмм, такую совместимость легко можно обеспечить и при простом
>> конфигурационном файле. Парсер должен выдавать отображение ключей
>> на значения (при этом он ничего не знает о том какие ключи
>> используются программой).

> Это при чтении файла. А при записи? Как тогда записать ключи и
> значения (возможно даже и комментарии), которые содержались в файле
> при считывании, но небыли распознаны, и небыли занесены в ОЗУ?
Нет при чтении надо распознавать все и хранить и имена ключей и их
значения. Далее при изменении настроек нужно обновлять эту самую
базу настроек. И тогда при записи в файл ничего не потеряется.

>> Вы же dialer пишите, не переусложняете ли вы таким механизмом
>> программу?
> Думаю, много сложного из мира С превращается в легкое и простое в
> мире Python. Мощь ООП + набор высокоуровневых инструментов делают
> свое дело. Что самое удивительное - все работает быстро. Java
> отдыхает!!! :-D
Я о сложности архитектуры программы говорил. Ведь тут и CORBA
можно использовать ;-)

   Max Vasin 2005-05-22 18:18:55 (#371888)

Re: Совместный доступ к конфигурации

В сообщении от 1116765230 секунд после начала Эпохи Unix Вы написали:

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

Это при чтении файла. А при записи? Как тогда записать ключи и значения
(возможно даже и комментарии), которые содержались в файле при
считывании, но небыли распознаны, и небыли занесены в ОЗУ?

> Вы же dialer пишите, не переусложняете
> ли вы таким механизмом программу?

Думаю, много сложного из мира С превращается в легкое и
простое в мире Python. Мощь ООП + набор высокоуровневых инструментов
делают свое дело. Что самое удивительное - все работает быстро. Java
отдыхает!!! :-D

> Я кстати не совсем понимаю зачем может понадобится запуск нескольких
> процессов dialer'а.

:) Это уже будет не совсем dialer. Точнее, его уже давно можно
использовать для обработки входящих звонков (dialin-сервер), и с
небольшими исправлениями для подключения двух машин по нуль-модемному
кабелю, но в некоторых ситуациях пользователю может понадобится
запустить несколько экземпляров (например: два модема, один dialin,
другой dialout; или модем + нуль-модем; или даже VPN [пока не пробовал,
но думаю и это тоже возможно]), вот тут и мешает текущие состояние дел с
конфигураций. В общем Chestnut Dialer станет универсальным GUI/CLI
frontend'ом к pppd.

   Konstantin Korikov 2005-05-22 17:24:05 (#371871)

Re: Совместный доступ к конфигурации

В сообщении от 1116756707 секунд после начала Эпохи Unix Вы написали:

> В общем я попробую сделать сервер, основанный на очередях сообщений из
> System V IPC.

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

   Konstantin Korikov 2005-05-22 16:42:14 (#371854)

Re: Совместный доступ к конфигурации

On Sun, 22 May 2005 13:11:47 +0300, Konstantin Korikov <lostcl***@u*****.fm> said:


> В сообщении от 1116750578 секунд после начала Эпохи Unix Вы
> написали:
> А представление
> конфигурации в DOM дает сохранность параметров, которые в данной
> версии программы не используются. Например если старой версии
> программы дать конфигурационный файл более новой версии, то она его
> не испортит, или попортит незначительно.
Хмм, такую совместимость легко можно обеспечить и при простом
конфигурационном файле. Парсер должен выдавать отображение
ключей на значения (при этом он ничего не знает о том какие
ключи используются программой). Вы же dialer пишите, не переусложняете
ли вы таким механизмом программу? Я кстати не совсем понимаю зачем может
понадобится запуск нескольких процессов dialer'а.

   Max Vasin 2005-05-22 15:34:09 (#371837)

Re: Совместный доступ к конфигурации

В сообщении от 1116750578 секунд после начала Эпохи Unix Вы написали:

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

Зато многократно, и если при изменении каждого отдельного параметра
будет происходить сериализация XML документа, и сохранение его в файл,
то потеря производительности будет заметна. Конечно можно улучшить
ситуацию вызывая некую функцию lock, которая увеличит счетчик
блокировки, тем самым откладывая сохранение файла до того времени как
все параметры будут установлены. Однако, параметры у меня хранятся не в
виде переменных или полей классов, а в виде дерева DOM, доступ к
которому осуществляется посредством интерфейсных классов, объекты
которых хранят ссылки на отдельные ветви этого дерева, так что после
перечитывания конфига обновлять ссылки на эти ветви будет крайне
затруднительно. А представление конфигурации в DOM дает сохранность
параметров, которые в данной версии программы не используются. Например
если старой версии программы дать конфигурационный файл более новой
версии, то она его не испортит, или попортит незначительно.

В общем я попробую сделать сервер, основанный на очередях сообщений из
System V IPC. Это даст еще одну интересную особенность - протокол один,
а реализаций сервера может быть несколько. Например один использует в
качестве хранилища XML-файл, и соответственно зависит от libxml2, второй
использует обычный, так называемый, INI-файл, и зависит от стандартного
модуля ConfigParser. Третий использует GConf, и зависит от библиотек
GNOME, и т.п. Таким образом пользователь при конфигурировании
(`./configure') может выбрать подходящий метод, в зависимости от вкуса и
от тех библиотек, которые он имеет в системе.

Всем спасибо!

   Konstantin Korikov 2005-05-22 14:13:17 (#371809)

Re: Совместный доступ к конфигурации

Здравствуйте, Konstantin.

Вы писали 21 мая 2005 г., 23:12:12:

KK> Нужно чтобы несколько процессов использовали конфигурацию совместно в
KK> режиме Ч/З, с возможностью оповещения остальных процессов о сделанных
KK> другим процессом изменениях в конфигурации.

KK> Кто какие варианты предложит?
можно попробовать посылать всем прецессам какй-то сигнал, по которому
они перечитают конфиги

   2005-05-22 13:01:36 (#371768)

Re: Совместный доступ к конфигурации

On Sun, 22 May 2005 00:04:51 +0300, "Yuri N. Glibovetz" <inetst***@g*****.com>
said:

> Лучьше TCP. UDP используются в основном для всяческих широковещательных
> опросов где не страшна потеря информации.
Для Unix domain sockets UDP не используется и передача датаграмм
гарантируется.

   Max Vasin 2005-05-22 11:33:21 (#371713)

Re: Совместный доступ к конфигурации

On Sun, 22 May 2005 00:57:23 +0300, Konstantin Korikov <lostcl***@u*****.fm> said:


> В сообщении от 1116712533 секунд после начала Эпохи Unix Вы
> написали:
>> А может сохранять сразу после изменения? И добавить команду в меню
>> - перечитать конфиг. Тогда блокировку надо делать только для записи
>> и на время записи.

> Любопытная идея, но будет небольшая потеря в производительности. И
> ручное перечитывание конфига будет не очень удобно для
> пользователей.
А пользователи эту потерю производительности заметят? Вы же не десятки
мегабайт сохранять будете. А вместо ручного перечитывания - помнится
есть такая вещь FAM (File Alteration ...) может на нее стоит посмотреть.

> Вот только я что-то не нашел в стандартной поставке Python
> реализации XML-RPC, которую можно прикрутить к unix domain socket,
> только через TCP... Может плохо искал...
И не найдете. На то он и XML-RPC, что поверх HTTP работает.

   Max Vasin 2005-05-22 11:30:06 (#371710)
  • 1
  • 2