Hans R. Steiner

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

Посмотри, может быть, crond дважды запущен (чего быть не должно, а может быть и не может)

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

Хм... надо будет зайти кним в раздел "вакансии"... вдруг удастся разбавить женский коллектив ))

Заглянул на http://www.bitrixsoft.ru У меня дерево на картинке, вообще вызволо не приятные ассоциации с SCO... ну их наф

Я свое изделие уже практически написал

Жееесть

А эти пункты ты точно выполнил? 6. проверяем, включина ли поддержка DRI ( glxinfo | grep ^direct ) 6.1. если получаем "Direct Rendering: No" то выходим из иксов 6.2. удаляем драйвер nVidia ( ./NVIDIA-Linux-x86-1.0-*.run --uninstall ) 6.3. если есть то, удаляем Mesa ( для Slackware: remowepkg 'ls /var/log/packages/Mesa*') 6.4. устанавливаем драйвер nVidia ( ./NVIDIA-Linux-x86-1.0-8774-pkg1.run ) 6.4.1. необходимо отказаться от установки предкомпилированного модуля 6.4.2. если нужно, внести изменения в /etc/X11/xorg.conf 6.5. загружаемся в иксы и опять проверяем вывод glxinfo 6.5.1. если опять "No", повторяем все от "6.1" (можно так же иксы переставить с libdri.a)

А я бы и форум заменил (который отлично работакт... иногда, работает)

Вайт, скинь мне скрин на почту, плз hans.steiner@mail.ru

А видеокарта какая?

Ну... апдейты - это, конечно же, хорошо, но: 1. Лично я, не перевариваю PHP. 2. Дизайн и функцилнал, не должен зависить от CMS, а в случае с -- MediaWiki, судя по сайтам, которые я видел на базе этого -- движка, получается именно так. 3. CMS должна быть расчитана на то, что работать с ней, будет -- человек, который не знает ничего, кроме HTML (а желательно и -- на тот вариант, когда человек даже HTML не знает), не должна -- навязывать свой "дополнительный" синтаксис написания шаблонов, -- комманд и т.д., ну и еще много всего... Я такого не смог -- найти и из-за этого и занялся написанем своего варианты. 4. Говоря о севместимости изделий на PHP, мне сразу вспоминается -- переход с PHP3 на PHP4. Тогда взвыли и хостеры и вэберы... Думаю, если бы было единственное верное мнение на эту тему то, либо была бы только одна CMS во всем мире, либо их вообще бы не было... точнее были бы, но у каждого своя.

Если недельку подождешь, предоставлю свое изделее... может понравится...

Разница очень большая. За подробностями, можете обратиться к kernel.org. Лично я, в ближайшем будущем, не собираюсь переходить на 2.6. А проблема у Вас, весьма вероятно, из-за того, что стандартным для Slackware Linux, является ядро 2.4 и модули у Вас стоят, именно от этого ядра... а само ядро, Вы 2.6 поставили.

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

А в как они говорят о своем нежелании идти с этим железом?

Хм... попробуйте, ради эксперемента, нормальное ядро поставить - bare или bareacpi так же, возможно, следует попробывать поставить sata.i и отключить эмуляцию IDE

А вот такой, можно сказать, культурный или эстетический, или как там еще его можно назвать, вопрос - какой код нагляднее: for ( param ) { $export{$_} = param ($_) if param ($_) ne "" } или for ( param ) { if ( param ($_) ne "" ) { $export{$_} = param ($_) } } ?

Ну вот у меня, как раз, задача - большой и красивый... но главное - это даже не красота, а универсальность и следовательно, модуль- ность. Сейчас застрял на самой "концепции". Есть несколько вариантов реализации такой системы: 1. Одним из вариантов, мне видится написание некого приложения, с которым будет работать пользователь, а уже это приложение, будет работать с модулями. Соответственно, это приложение должно предоставлять этим при- ложениям соответствующие функции, такие как: - работа с базой данных - отображение результатов работы модуля - и т.д. На этапе начала работы с этим же приложением, должна проходить аутентификация/авторизация пользователей, общее конфигурирова- ние системы и т.п. Проблема, с которой я столкнулся, в процессе реализации данно- го решения - организация и стандартизация методов общения основного приложения и модулей. Еще одной проблемой явилось то что в этом приложении, должны быть определены все имеющиеся модули, набор которых, может изменяться и для добавления ново- го модуля, не должно требоваться, пусть даже мелкое, но пере- писывание основного приложения/системы. 2. Вторым вариантом, является то, как построен webmin т.е., есть множество модулей, которые являются вполне не зависимыми друг от друга, а их общение с пользователем/системой, проходит посредством использования библиотек webmin'а. По сути, вариант великолепный, но он крайне усложняет использование шаблонов в пользовательском интерфейсе так, как за ход работы модуля, происходит нескольхо действий типа "стандартный_модуль(принтни заголовак)", "стандартный_модуль(принтни_еще_чего-нибудь)", стандартный_модуль(заверши_страницу). Другими словами, вывод пользовательского интерфейса происходит не единовременно, а в процессе всей работы. Так же, в ходе работы, модуль так же выводит информацию, не обращаясь к стандартным библиотекам webmin, что с одной стороны, позволяет реализовать такую вещь, как "интерактивность" приложения (в моем понимании, это неме- дленное отображение информации, к примеру, результат ping'а), но с другой стороны, делает унификацию пользовательского интерфейса, тошлько условной, оставляя правильность работы интерфейса исключительно на совести модуля (и дело касается но только таких вещей, как интерфейс... ошибка в модуле, при такой реализации, может поставить под угрозу, как минимум безопасность, а то и работоспособность всей системы, а это, как мне кажется, в таком программном продукте, с открытым кодом, просто не допустимо). Вот и сижу я в ступоре... пока писал этот текст (овообще, всей этой писаниной на форумах, я занимаюсь даже не для того, чтобы получить от кого-то решение моей задачи, а чтобы мысли по поло- чкам разложить... да и может кто идейку какую подкинет)... в общем, пока все это писал, от второго варианта, решил действи- тельно отказаться (до этого, я и не думал о таких его минусах). Буду думать над первым вариантом. По сути, основной траблой для меня, сейчас является реализация единовременного вывода поьзовательского интерфейса. заполнение шаблона, у меня происходит сейчас следующим образом: sub Template { my %VAR = %main::VAR; my $template = shift; open ( TEMPLATE, "$template" ); $template = join ( '', <TEMPLATE> ); close ( TEMPLATE ); while ( $template =~ m/\$VAR\{([0-9,A-Z,a-z,_])\}/ ) { for ( $template ) { s\$VAR\{([0-9,A-Z,a-z,_])\}/$VAR{$1}/eg } } return $template; } $VAR{MENU} = Template ( "../htdocs/tpl.menu.html" ); $VAR{MAIN} = Template ( "../htdocs/tpl.main.html" ); недостаток данного метода заключается в том... а не знаю в чем... еще сам не понял, че мне надо... в общем, еще чего-нибудь приду- маю, отпишусь

В общем, нахожусь в велком ступоре Суть ступора в том, что не могу написать интерфейс ко всей этой пакости... Логика (если она есть) рассуждений: - Есть некий программный продукт, состоящий из "ядра" и модулей. в данном случае, "ядро" берет на себя функции "конфигурирования", всей этой системы, управления модулями, предоставления прав на их использование и т.д. - Соответственно, чтобы все это нормально можно было использовать у этого должен быть какой-то общий интерфейс. Вписывать HTML в перловый код, как-то очень не хочется... -- В общем... я в шаблонах и интерфейсах потерялся...

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

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

ulogd

Хм... Цитата: Правда есть некоторые конторы типа провайдеров где у системщиков стоит линух, но только там. Вы забыли еще про хостеров, если говорить об этом направлении... только провайдерами и хостерами, сфера применения линукс не ограничивается и я не видел еще ни одного серьезного Windows решения, живучисть и стабильность которого критична для компании. ЗЫ: но это опять же я не видел (а видел я не так-то мало) но я искренне верю в то, что все-таки такие решения есть Да и вообще... мы (наша компания) - ISP (Internet Service Provider) и у нас в штате нет сестемщиков... но при этом, и Linux у нас работает, и FreeBSD и т.д.. ЗЫ: всю жизнь, на сколько мне это известно, "системщик" - это определение "типа" программиста (кому-то может будет привычнее услышать, "программера") т.е., "системщик" или "аппаратчик". Цитата: А по поводу перевода всех на линукс мое опять же мнение он то есть линух еще слишком сыроват для того что бы ставить на рабочие машины пользователей. Ну... всегда есть то, что хочется доработать (благо, Linux предоставляет такую возможность всем желающим и умеющим), но не думаю, что это как-то сказывается на степени сырости того или иного программного продукта. Но можно задать вопрос и по другому. Учитывая то, что компьютерная граматность среднестатистического Linux-пользователя всегда была значительно выше, чес компьютерная граматность среднестатистического Windows-пользователя, не кажется ли Вам, что "пользователи еще сыроватыдля того, чтобы ставить на скои машины Linux"

Цитата: Ганс, зачем при каждом запросе триггер-то создавать? Это ж такой же элемент логики, как и хранимые процедуры, их создал раз при создании самой базы - и они дальше сами работают. Я, по крайней мере, не могу себе представить ситуации, в которой бы возникла необходимость создавать/изменять/удалять триггеры во время работы с базой. Все очень просто. Триггер - очень удобная штука, но... уменя получилось создать только один триггер, на одну таблицу базы, а это, крайне не удобно. Долго мучался с созданием второго, но так ничего и не вышло... в документации по мускулю сказано, что если мускуль говорит мол "триггер с таким именем уже есть" - удалите его и будет вам счастье... на практике - опять национальная индейская изба... при попытке удалить триггер, который уже есть, но который никто не создавал и который мешает создать новый триггер, мускуль говорит - "триггер с таким именем еще не создан"