Re: Открытые исходник и (Было: Использовани е обфускаторов)
Ты действительно веришь в то, что пришедший человек будет способен взять исходный код продукта масштаба MS Office, найти там ошибку, исправить ее и все это за несколько минут? Это где же программисты такого уровня работают мальчиками по вызову? Зачем утрировать? Пусть мальчик по вызову установит причину - баг в программе, а правки могут внести и программисты в конторе. Я ведь не про то, кто конкретно будет исправлять баг - а про то, что его можно исправить имея в наличии исходники. Виктор
Re: fs kernel driver, initrd
В сообщении от 4 Июль 2003 14:52 Dmitry Astapov написал: Evening, Dimitry. Dimitry N. Naldaev [EMAIL PROTECTED] 10:00 4/7/2003 wrote: DNN основное назначение initrd --- инсталяция системы... Мнда? Может, лучше все-же почитать документацию? DNN может и лучше, ссылки в студию :-) http://sdb.suse.de/en/sdb/html/initrd.html Переделать initrd - один запуск mkinitrd. Это сложно? Кто сказал, что рамдиск будет болтаться в памяти? DNN по крайней мере раньше было именно так, я очень давно с рамдиском дел DNN не имел. а что, cat /dev/ram уже не работает чтоли? как и Выдержка из моего dmesg: Freeing initrd memory: 2884k freed Нужно будет посмотреть... DNN последовательный ремоут ? что же тогда с ним происходит? просветите DNN меня плиз!!! А что такое последовательный ремоут? грубо говоря вот что: mkfs /dev/mem mount /dev/mem /mnt/1 .. umount /dev/mem (!!!) .. mount /dev/mem /mnt/2 --- снова монтируем этот диск .. umount /dev/mem (!!!) cat /dev/mem fs.img сохраняем образ диска будет работать или нет??? и когда тогда будет происходить освобождение памяти рамдиска ??? впрочем согласен, initrd --- это не совсем рамдиск, а нечто более специалезированное...
Re: Mutt, MTA и провадеры dia l-up
Nicholas wrote: Vladimir N.Velychko wrote: Но можно вот так: [EMAIL PROTECTED] добавил в /etc/postfix/main.cf mynetworks = 195.xx.xxx.xx Пишу: telnet localhost 25 mail from: [EMAIL PROTECTED] rcpt to:[EMAIL PROTECTED] data xxx
Re[2]: Открытые исходники (Было: Использовани е обфускаторов)
Ты действительно веришь в то, что пришедший человек будет способен взять исходный код продукта масштаба MS Office, найти там ошибку, исправить ее и все это за несколько минут? Это где же программисты такого уровня работают мальчиками по вызову? VVЗачем утрировать? Я всего лишь приложил предложенный вариант к окружающему миру. VV Пусть мальчик по вызову установит причину - баг в программе, VV а правки могут внести и программисты в конторе. Целью мальчика по вызову является не установление причин, а решение проблем. Если он не может на месте исправить ошибку, ему придется искать, как ее обойти. После того, как он нашел способ ее обойти, устранение ошибки переходит в разряд академических. А у программистов в конторе обычно есть и другие занятия. VV Я ведь не про то, кто конкретно будет исправлять баг - а про VV то, что его можно исправить имея в наличии исходники. И кучу свободного времени. -- Igor
Re: Mozilla, gecko..
On Fri, Jul 04, 2003 at 05:05:39PM +0200, Sergey V. Spiridonov wrote: А есть какой-нибудь порт Мозиллы на motif? Или motif'ный браузер на движке gecko? Так хочется оторвать от неё эту тормозулину GTK и XUL... Из своего опыта разработки могу сказать, что я очень сомневаюсь, что motif будет быстрее gtk, скорее наоборот. Можно попробовать например epipfany-browser или galeon. Фиг его знает, однако, netscape 4.77 сильно быстрее тормозиллы. Да и vim мотифный шустрее гтк-шного.. GTK-1.2 был неплох в плане скорости, однако не юникоден, а GTK-2 - тормоз однозначный. Интересно, а на разных там Solaris'ах и др. мозилла тоже с gtk собрана? Мне почему-то казалось, что с motif.. -- Alexey Zagarin Aquarius Consulting Phone: +7 (095) 729-5199 *170 E-Mail: [EMAIL PROTECTED]
Java + Debian
А где взять JDK SE посвежей упакованный для Debian? -- С уважением, Константин Матюхин root:x:0:0:God:/root:/bin/sh daemon:x:1:1:Daemon:/usr/sbin:/bin/sh adam:x:1001:1001:Adam:/home/adam:/bin/sh eva:x:1002:1002:Eva:/home/eva:/bin/sh
Re: Автологин юзеров
Здравстувйте, А если эту программу прописать в качестве init ядру? И login заупскаться не будет. On Sat, Jul 05, 2003 at 07:52:24PM +0400, time wrote: Здраствуйте Все!! Может кто подскажет как сделать в woody автологин пользователей!!! Надо что бы пользователи при включении компа не вводили логин и пароль, а чтобы он вводился сам автоматически!! И второе - после логина надо чтобы грузилась оболочка не bash sh а произвольная Например прога какая либо запускалась автоматом!!! -- Elena Egorova, SatGate LLC, +7 0112 573073 +7 0112 573070
Re: gconf2 на сервере
Доброе время суток, Sergey V. Spiridonov ! Sat, Jul 05, 2003 at 12:35:22PM +0200 Sergey V. Spiridonov написал(а): DIG wrote: Sat, Jul 05, 2003 at 12:09:38AM +0200 Sergey V. Spiridonov написал(а): [...] Мой основной вопрос был: как конфигуратор узнАет, что параметры ошибочны, а не просто -- необычны? (Неужели конфигуратор будет знать что-то о параметрах *лучше* самого приложения?) Ну как же, я думал это понятно? И продолжает оставаться непонятным. Потому что пока это не описано -- это не понятно. Конфигуратор же знает имена параметров, их типы. Насколько я знаю, сейчас нет, но в будущем появится возможность писать сложные функции проверки, на каком-либо скриптовом языке, типа гуиле. Без языка возможны только простые проверки, типа проверки на принадлежность диапазону значений, но даже это лучше чем то что предоставляет текстовый редактор. С текстовым редактором у нас нет даже элементарной проверки синтаксиса. То есть, всех гнать в гуиль? А если ч-к привык к Tcl, то ему никак не выжить? А теперь -- более понятный пример: у меня есть приложение на Python'е. Конфигурационный файл этого приложения -- python'овский скрипт. Часть параметров (и логики) приложение получает из этого конфиг-файла. Есть также параметры, устанавливаемые после запуска программы (и которые зависят от окружения). Вопрос: каким боком мне здесь гуиль? И как конфигуратор будет проверять правильность синтаксиса моего конфига? И, вдогонку: даже если конфигуратор можно научить делать такие сложные проверки, зачем *мне* это нужно? Иногда некоторые приложения пытаются решить эту проблему, создавая отдельную программу для проверки конфигурационного файла :), но в большинстве случаев этого нет. Но в случае, если необходимость в такой программе будет, библиотека жконф облегчит и эту задачу (простейшие и синтаксические проверки сделает сам жконф, программе останется лишь проверить сами значения). Но я считаю, что при наличие языка, на котором можно будет писать проверки, необходимость в таких программах будет возникать редко. А аргументы? Пока я вижу только то, что такие проверки можно будет писать на встроенном в конфигуратор языке. Я пока не вижу -- почему это лучше. Но это всё мои пожелания, сейчас, значения возвращаемые жконф в программу я вляются untrusted и должны проверяться приложением на соответствие типу. Другой вопрос, откуда конфигуратор знает о параметрах. Ответ здесь тоже простой - приложение ему скажет при инсталляции. То есть не разработчики конфигуратора будут вносить имена типы и ограничения параметров для приложения А в базу данных, а само приложение в процессе установки. Ага. Сначала -- напиши приложение. А потом напиши ещё одно -- для конфигуратора. (Есть ещё один вариант -- не писать сложных приложений, но кто на него решится?) Я сильно сомневаюсь, что можно будет заставить программера делать одну и ту же проверку дважды: один раз делая проверку для конфигуратора, а второй -- внутри программы. SVS За редким исключением, максимум что может сделать приложение - SVS перечитать конфигурационный файл получив каким-то образом оповещение, SVS которое обычно посылается пользователем. И это правильно. Нет. Аргументы? Да, хотелось бы услышать аргументы, почему вы считаете что это правильно? (1) Попробую НЕ отвечать вопросом на вопрос. (2) Короткий ответ такой: я склонен считать, что решение принимает человек. То есть, если мне захочется, чтобы Апачи перечитал конфиг-файл (который я поправил), то я ему (Апачи) так прямо об этом и скажу: перечитай, мол. Или же я решу, что перечитыванием параметров он у меня займётся ночью -- тогда же, когда logrotate будет его restart'ить. Это я решаю, а не конфигуратор. Потому что не конфигуратор, а я знаю -- когда Апачи должен перечитывать свои конфиги. Или конфигуратор придётся делать очень жирный, чтобы он и такие случаи мог бы обрабатывать. Проблемы здесь просто нет. Когда я говорил что данная схема неправильна, я имел в виду, что с жконф возможна большая гибкость для всех приложений которые его используют. Не конфигуратор решает, когда Апачи узнает об изменениях, а пользователь, который эти изменения вносит. То есть -- пользователь таки дёргает Апачи или нет? Я внёс изменения в конфиг Апачи. Апачи подписан на уведомление от gconf'а о том, что в параметры были внесены изменения. Вопрос: Апачи побежит за новыми параметрами? Или будет ждать от меня специального сигнала? Если первое (то есть побежит) -- то каким образом не конфигуратор решает, когда Апачи узнает об изменениях, а пользователь, который эти изменения вносит? И если мне для отложенного оповещения надо будет хранить новые настройки в файле -- то зачем мне gconf? А если второе (Апачи будет ждать специального сигнала, чтобы перечитать параметры) -- то зачем нужна подписка на уведомление? Я ему (Апачи) шепну, что пора читать -- он
Re: samba 1C
КА У кого нормально работает самба версии 2.2.8? КА Откуда ставили? не пробовал что-то типа этого: deb http://www.samba.org/samba/ftp/Binary_Packages/Debian stable main ?
Re: Автологин юзеров
В сообщении от 7 Июль 2003 13:44 Elena Egorova написал: Здравстувйте, А если эту программу прописать в качестве init ядру? И login заупскаться не будет. лучше сделать как Иван Лох в соседнем письме посоветовал --- так правильнее и надежнее, и всегда оснанется возможность нормально залогиниться если что... А вообще человеку нужно почитать доку на предмет того, как происходит загрузка системы (к сожалению не могу в конкретные ртфмки ткнуть) и собразить, в какое место наиболее грамотно будет поставить запуск приложения On Sat, Jul 05, 2003 at 07:52:24PM +0400, time wrote: Здраствуйте Все!! Может кто подскажет как сделать в woody автологин пользователей!!! Надо что бы пользователи при включении компа не вводили логин и пароль, а чтобы он вводился сам автоматически!! И второе - после логина надо чтобы грузилась оболочка не bash sh а произвольная Например прога какая либо запускалась автоматом!!!
Re: Открытые исходник и (Было: Использовани е обфускаторов)
On Mon, 7 Jul 2003, Viktor Vislobokov wrote: Ну что же. Я не настаиваю. Правда как уже тут говорилось, если обфускатор оставляет исходник, то вполне можно написать Не оставляет. На выходе обфускатора - не исходный текст. Пригодность выходного текста как входного для компилятора не достаточна, чтобы называться исходным. или найти антиобфускатор, который вновь сделает всё нормальным. Нельзя. Исходный текст не получится, там не будет массы информации, ну вот хотя бы комментариев. Я не знаю можно ли считать обфускатором программу, если есть (или его можно написать) антиобфускатор. Можно и то, и другое. -- придвинул к себе калькулятор, проворно набрал уравнения, щелкнул тумблером. Машина крякнула, затарахтела и выдала результат.
Re: gconf2 на сервере
On Fri, Jul 04, 2003 at 12:16:19PM +0300, Dmitry Astapov wrote: [skip] AD но я потихоньку стараюсь перетащить их в ~/etc ^ Ага. Т.е. машина строго однопользовательская, так? AD нет, не так, просто я сейчас экспериментирую над своим учётом Не понял :( Дмитрий, Вы, видимо, не обратили внимание на тильду. Александр перемещает пользовательские настройки в пределах своего каталога, поэтому на многопользовательскость это никак не влияет. Идея с ~/etc мне нравится, расположение пользовательских конф.файлов в пользовательском руте меня тоже раздражает. Кстати, неплохо было бы иметь что-то типа man user-hier. Учетом чего? IMHO имелся в виду user account. -- With best regards, Oleg Gritsinevich
Re: Открытые исходник и (Было: Использование о бфускаторов)
Mon, 07 Jul 2003 09:19:42 +0600 Viktor Vislobokov [EMAIL PROTECTED] wrote (написал/а): Даёт сбои - это одно, а работает - это другое! Без сбоев вообще ничего не бывает в нашей жизни! В некоторых областях сбои означают несостоятельность системы. В юриспруденции это в большой степени именно так... С другой строны, нельзя, конечно, отрицать, что положение дел за Западе все-таки лучше, чем, например, в России... Причем не только касательно вопросов авторских прав... Есть много ОЧЕНЬ полезных программ, которые даются бесплатно и также много очень полезных программ, которые стоят весьма дёшево. Я говорил о ценности, исчисляемой не в денежных единицах, а о ценности, из-за которой пользователя можно убедить заплатить определенную сумму денег за нее... Это разные вещи. :) Я не про оценку качества программы. Я про то что стоить дорого должны только большие и сложные программы. А, то есть те, которые обходятся дороже в процессе разработки? Так бы сразу и говорил! :) Это меняет дело. (Насчет наукоемких продуктов -- беру слова обратно: был не совсем прав... :)) Всего хорошего, -- [:: Andrei Sosnin ]---[*]) [:: http://zzx.dyn.ee ][*]) [it:all:depends:on:your:vision]--[*])
Re: gconf2 на сервере
DIG wrote: То есть, всех гнать в гуиль? А если ч-к привык к Tcl, то ему никак не выжить? Речь о том чтобы создать стандарт для хранения, извлечения, поиска и оповещения конфигурационных параметров. Например такой каким является SQL (пример на стандарт языка запросов RDBMS) или TCP/IP (набор протоколов и C - интрефейс к ним), libc. Никто никого не гнал в SQL. Этослучилось само собой. Хочешь воспользоваться преимуществами стандартизации - используй стандартный язык SQL. Не хочешь - пиши работу с базой данных хоть на tcl хоть на C. Гуиль я написал, так как я к нему не равнодушен и он изначально разрабатывался как встроенный язык и средство расширения приложений. Это всего лишь одна из возможностей, возможно на чей то взгляд и не самая лучшая. А теперь -- более понятный пример: у меня есть приложениена Python'е. Конфигурационный файл этого приложения -- python'овский скрипт. Часть параметров (и логики) приложение получает из этого конфиг-файла. Есть также параметры, устанавливаемые после запуска программы (и которые зависят от окружения). Вопрос: каким боком мне здесь гуиль? И как конфигураторбудет проверять правильность синтаксиса моего конфига? И, вдогонку: даже если конфигуратор можно научить делать такие сложные проверки, зачем *мне* это нужно? Во-первых, я написал, что гуиль будет исполнятся на стороне сервера, то программа на питоне не должна будет интерпретировать гуиль-скрипт. Во-вторых в данном примере, скрипт на питоне это всего лишь часть программы, которая может быть модифицирована пользователем. Так вот, в данном случае, программист питона сможет воспользоваться стандатрным интрефейсом к серверу конфигурации жконф для хранения, поиска и извлечения параметров. Точно так же как он например может воспользоваться SQL и ODBS для доступа к базе данных, или TCP/IP и библиотеку сокетов для обмена данными по сети. Конфигуратор будет проверять не правильность скрипта на питоне, а правильность параметров, которые записываются на сервер. И на гуиле (к примеру) можно будет написать дополнительные ограничения для проверки значений на стороне сервера. Иногда некоторые приложения пытаются решить эту проблему, создавая отдельную программу для проверки конфигурационного файла :), но в большинстве случаев этогонет. Но в случае, если необходимость в такой программе будет, библиотека жконф облегчит и эту задачу (простейшие и синтаксические проверки сделает сам жконф, программеостанется лишь проверить сами значения). Но я считаю, что при наличие языка, на котором можно будет писать проверки, необходимость в таких программах будет возникать редко. А аргументы? Пока я вижу только то, что такие проверки можно будет писать на встроенном в конфигуратор языке. Я пока не вижу -- почему это лучше. Лучше чем что? Сегодня проверки просто нет. Ну нет её. Например я редактирую файл настройки апачи, какая при этом выполняется проверка? НИКАКАЯ. Даже без языка проверки на стороне сервера, простейшие проверки *уже* выполняются. Например, еслипараметр число, то кроме числа ничего в базу данных занести невозможно не залезая прямо туда ручками. Но это всё мои пожелания, сейчас, значения возвращаемые жконф в программу я вляютсяuntrusted и должны проверяться приложением на соответствие типу. Другой вопрос, откуда конфигуратор знает о параметрах.Ответ здесь тоже простой - приложение ему скажет при инсталляции. То есть не разработчики конфигуратора будут вносить имена типы и ограниченияпараметров для приложения А в базу данных, а само приложение в процессе установки. Ага. Сначала -- напиши приложение. А потом напиши ещё одно-- для конфигуратора. (Есть ещё один вариант -- не писать сложных приложений, но кто на него решится?) Опять мимо. Не надо писать приложений для кофигуратора. Ну с чего Вы это взяли? Если вы имеете в виду проверку значений параметров, то её надо писать в любом случае, независимо от того где она будет выполняться. Моя идея я в том, чтобы выполнятьпроверку как можно раньше - ещё на этапе внесения параметра в конфигурационный файл. Вы знакомы с базами данных? Сидеей констрэинтов, триггеров? Хорошем стилем считается, когда целостность базы данных проверяется на стороне же базы данных, а не на стороне клиента. Тем не менее, проверка на стороне клиента не исключаетсяи не запрещается. Если мне плевать на то что кто-то считает хорошим стилем, я сделаю проверку на стороне клиента, и это будут только мои проблемы. В данном случае, я говорю о *возможности* использования опыта накопленного в области СУБДдля конфигурационных параметров. Никто не будет заставлять писать программы красиво и пользоваться стандартами. Я сильно сомневаюсь, что можно будет заставить программера делать одну и ту же проверку дважды: один раз делая проверку для конфигуратора, а второй -- внутри программы. Не надо её делать дважды. SVS За редким исключением, максимум что может сделать приложение - SVS перечитать конфигурационный файл получив каким-то образом оповещение, SVS которое
[ck]aptain и русский
Здравствуйте, All Опять вопрос: как заставить captain (QT) или хотя бы kaptain (KDE) выводить русский в диалогах? Выводит или кракозябры или вопросы :( Извините за дурацкий вопрос, но просто зацепок не смог найти :( Спасибо :) -- С уважением, Кондрашов Николай, ИТ-менеджер ЗАО Автоматика-Север +7(812) 1183238, 3039648 http://www.avt.com.ru/ mailto:[EMAIL PROTECTED]
Re: Открытые исходники (Было: Использование обфускаторов)
On Mon, Jul 07, 2003 at 07:38:04AM +0400, Igor Suvorov wrote: Ты действительно веришь в то, что пришедший человек будет способен взять исходный код продукта масштаба MS Office, найти там ошибку, исправить ее и все это за несколько минут? Не обязательно за несколько минут. Пример, руссификация программ без исходного кода (особенно при нежелании продавца идти навстречу). Безусловно, внедрение unicode и интерес крупных производителей к русскому рынку постепенно снимает остроту проблемы... но совсем не так быстро как хотелось бы. Да и всегда есть мелочи до которых у корпораций не доходят руки. -- Иван Лох
Re: Автологин юзеров
Здравствуйте, On Mon, Jul 07, 2003 at 02:35:18PM +0600, Dimitry N. Naldaev wrote: А если эту программу прописать в качестве init ядру? И login заупскаться не будет. лучше сделать как Иван Лох в соседнем письме посоветовал --- так правильнее и надежнее, и всегда оснанется возможность нормально залогиниться если что... Возможность загрузиться нормальным образом всегда останется, только если ее насильственно не вырезать (кто мешает прописать заргузчику еще один профайл или ввести параметр ядру вручную). А вообще человеку нужно почитать доку на предмет того, как происходит загрузка системы (к сожалению не могу в конкретные ртфмки ткнуть) и собразить, в какое место наиболее грамотно будет поставить запуск приложения Можно прописать в качестве shell, например. У знакомых так сделано - логинишься пол логином tty1 без пароля - попадаешь на одну АТС, и тд. Шеллом был миником со своими профайлами. -- Elena Egorova, SatGate LLC, +7 0112 573073 +7 0112 573070
Re: gconf2 на сервере
Oleg Gritsinevich wrote: On Fri, Jul 04, 2003 at 12:35:20PM +0200, Sergey V. Spiridonov wrote: [skip] 4. При всём при этом, остаётся возможность выбора бакэнда(формата) и возможность сетевого взаимодействия, без необходимости что-либо специально для этого программировать или изменять в приложении. Как в концепцию gconf-а вписывается конфиг sendmail-а (представляющий собой исходник на сноболе)? Да хоть на фортране. Какая разница? В чём Вы здесь видите проблему? Концепция жконфа вписывается так же, как TCP/IP вписывается в python, к примеру. Есть библиотека sockets, и есть к ней API на питоне. Точно так же есть библиотека gconf а для остальных языков пишется соответствующее API. Или я Вас не понял? -- Best regards, Sergey Spiridonov
Re: И снова NForce2... USB, nvnet, свежее ядро...
Bogdan wrote: Hi all! До сих пор использовал 2.4.21-rc* - захотел пересобрать релиз 2.4.21, для чего взял патч rc8. За одно включил в ядре поддержку usb host controllers как модулей. В bios включил поддержку USB2 (хотя ее отключение на наличие глюков в дальнейшем не повлияло) а так же встроеную сетевуху. Пересобрал ядро, свежие дрова для видюхи и чипсета. Все пробывал собирать при помощи gcc-2.95 и gcc-3.3. Итого: при попытке присвоить ip сетевой крточке система виснет наглухо. аналогично при попытке загрузить модули usb ehci-hcd.o и ohci.o - остальные модули контроллера отказались загружаться. Многократная перекомпиляция показала, что проблема с сетью появляется после rc6 (на котором сейчас и работаю) во всех старших патчах - включая 2.4.21 и 22rc* Дрова для nforce пробывал свежайшие и предыдущий релиз - одинаково... Подскажите, плс - я один обладатель таких граблей или кто-то еще с таким столкнулся? ACPI всяко Попробуй 23pre или http://kernel.kolivas.net/ -- там много ACPI мучали...
Можно ограничить ск орость apt-get ?
subj pgpRHu9SJwe83.pgp Description: PGP signature
Re: Можно ограничить с корость apt-get ?
On Mon, Jul 07, 2003 at 03:57:32PM +0300, Bogdan wrote: subj renice 20 `pidof apt-get` ;) если уважаемый товарищ таки интересуется как ограничить скорость скачивания, то это зависит от того, какими методами происходит это самое скачивание. возможные варианты: зажатие проксей, специальными зажималками типа shaperd, встроенными средствами ядра (tc), iptables и т.д. о, если это с cdrom, то hdparm ;) -- Yuri Pimenov
Re: Автологин юзеров
В сообщении от 7 Июль 2003 17:19 Elena Egorova написал: Здравствуйте, On Mon, Jul 07, 2003 at 02:35:18PM +0600, Dimitry N. Naldaev wrote: А если эту программу прописать в качестве init ядру? И login заупскаться не будет. лучше сделать как Иван Лох в соседнем письме посоветовал --- так правильнее и надежнее, и всегда оснанется возможность нормально залогиниться если что... Возможность загрузиться нормальным образом всегда останется, только если ее насильственно не вырезать (кто мешает прописать заргузчику еще один профайл или ввести параметр ядру вручную). если Вы замените init, то такой возможности может и не оказаться :-( да и вся система может оказаться в нерабочем состоянии (диски неподмонтированы, сервисы не запущены...) все зависит от того что новый init умеет, а что нет... А вообще человеку нужно почитать доку на предмет того, как происходит загрузка системы (к сожалению не могу в конкретные ртфмки ткнуть) и собразить, в какое место наиболее грамотно будет поставить запуск приложения Можно прописать в качестве shell, например. У знакомых так сделано - логинишься пол логином tty1 без пароля - попадаешь на одну АТС, и тд. Шеллом был миником со своими профайлами. да так в принципе тоже можно сделать (те указать пустой пароль) но в этом случае человеку все равно придется указывать логин...
Re: Можно ограничить с корость apt-get ?
On Mon, 7 Jul 2003 17:15:19 +0400 Yuri Pimenov [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2003 at 03:57:32PM +0300, Bogdan wrote: subj renice 20 `pidof apt-get` ;) если уважаемый товарищ таки интересуется как ограничить скорость скачивания, то это зависит от того, какими методами происходит это самое скачивание. возможные варианты: зажатие проксей, специальными зажималками типа shaperd, встроенными средствами ядра (tc), iptables и т.д. о, если это с cdrom, то hdparm ;) Таки интересуюсь, можно ли это сделать с помощью самого apt-get. Не зажимая при этом остальных программ.
Re: Можно ограничить с корость apt-get ?
On Mon, Jul 07, 2003 at 05:01:07PM +0300, Bogdan wrote: On Mon, 7 Jul 2003 17:15:19 +0400 Yuri Pimenov [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2003 at 03:57:32PM +0300, Bogdan wrote: subj renice 20 `pidof apt-get` ;) если уважаемый товарищ таки интересуется как ограничить скорость скачивания, то это зависит от того, какими методами происходит это самое скачивание. возможные варианты: зажатие проксей, специальными зажималками типа shaperd, встроенными средствами ядра (tc), iptables и т.д. о, если это с cdrom, то hdparm ;) Таки интересуюсь, можно ли это сделать с помощью самого apt-get. Не зажимая при этом остальных программ. man apt-get отрицает такую возможность. лично я бы сделал все через squid. -- Yuri Pimenov
gnome2 xscreensaver
Поставил gnome2 поверх первого. Во время установки xscreensaver не стоял, поставил позже. xscreensaver-demo --crapplet в результате валится вот так: ** WARNING **: Unable reach the control-center. Exiting... а иногда даже так: ** WARNING **: Could not get name service! ** ERROR **: file goad.c: line 660 (real_goad_server_activate): assertion failed: (name_service != CORBA_OBJECT_NIL) aborting... Aborted Не то чтобы жутко жить мешает, просто странно очень - к чему бы это? А еще этот самый xscreensaver перестал находить картинки в каталоге, откуда ему их брать прописано. Рисует вместо них клетчатое поле. С десктопа без проблем берет, а из каталога разучился. Где в этом хозяйстве могут грабли валяться? Спасибо! Привет! :)))
Тормоза на Intel-маме
Добрый день.
Дали мне, стало быть машинку. На Интелевой материнке.
Так вот, диск на ней работает как-то небыстро. Пощупал hdparm - и
удивился... Скорость совершенно неприличная.
При том что режим - UDMA5, все как положено в лучших домах.
Кто-то может меня просветить на предмет возможных причин такой гадости
(малой скорости доступа к винту)? Буду благодарен за любые советы...
Кое-какую инфу с консоли привожу ниже.
mumidol:/home/snork# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 64 MB in 19.69 seconds = 3.25 MB/sec
mumidol:/home/snork# hdparm -T /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.56 seconds = 82.05 MB/sec
mumidol:/home/snork# hdparm -i /dev/hda
/dev/hda:
Model=QUANTUM FIREBALLP AS20.5, FwRev=A1Y.1300, SerialNo=892100674575
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1902kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40132503
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 1 2 3 4 5
[EMAIL PROTECTED]:~$ lspci
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics
Controller] (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 02)
00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 02)
00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 02)
00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev
02)
01:08.0 Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM Ethernet Controller
(rev 01)
--
WBR,
Alexander A. Vlasov
Re: gconf2 на сервере
On Mon, Jul 07, 2003 at 01:48:21PM +0200, Sergey V. Spiridonov wrote: Oleg Gritsinevich wrote: On Fri, Jul 04, 2003 at 12:35:20PM +0200, Sergey V. Spiridonov wrote: [skip] 4. При всём при этом, остаётся возможность выбора бакэнда(формата) и возможность сетевого взаимодействия, без необходимости что-либо специально для этого программировать или изменять в приложении. Как в концепцию gconf-а вписывается конфиг sendmail-а (представляющий собой исходник на сноболе)? Да хоть на фортране. Какая разница? В чём Вы здесь видите проблему? Концепция жконфа вписывается так же, как TCP/IP вписывается в python, к примеру. Есть библиотека sockets, и есть к ней API на питоне. Точно так же есть библиотека gconf а для остальных языков пишется соответствующее API. Или я Вас не понял? Речь идёт не о биндингах к API gconf-a другого языка, а о другом. В данном случае _сам_ _конфиг_ (sendmail.cf) представляет собой программу на некотором языке, которую интерпретирует другая программа (в данном случае sendmail). Данный конфиг не вписывается в концепцию name-value pair и ни в какой другой общий формат описания конфига тоже не вписывается. Единственное, чем sendmail может воспользоваться в API gconf-a, IMHO нотификация об изменении конфига, и чем это лучше обычного kill -HUP? Завязывание программы на gconf автоматически сужает её область применения/распространения, по крайней мере системные вещи на него завязываться не должны и скорее всего не будут. Не совсем понятна цель создания gcnof-a: - избавить программистов от рутинной писанины парсеров конфигов? В сложных случаях, как в примере с sendmail-ом, это невозможно. - предоставить средства редактирования конфигов с валидацией синтаксиса и введённых значений? Ну синтаксис ещё можно кое-как отслеживать. Так большинство существующих программ и так не запустятся с ошибкой конфиге. Проверка семантики? Она тоже возможна только в самом примитивном виде (проверка принадлежности значения к.-л. м-ву), а как н.п. проверить не попутал ли пользователь наружный интерфейс с внутренним в конфиге iptables? Конфигурирование сложных приложений gconf упростить не сможет, а в простых случаях ничего упрощать и не надо. IMHO работать оно будет только в простых случаях, а для простых случаев достаточно иметь библиотеку парсилки конфига (н.п. вида name-value pairs): на входе имя файла, на выходе представление конфига в виде списка/дерева и т.п., подсовываешь библиотеке ключ -- получаешь значение параметра. Семантической проверкой вообще никак не заниматься -- пользователь перед началом конфигурирования должен внимателььно прочесть док-цию и иметь ясное представление о том, чего он хочет добиться в конечном итоге. -- With best regards, Oleg Gritsinevich
Re: gconf2 на сервере
Sergey Spiridonov wrote: [snip] Да, понятно, что ж не понятно? Историю изменений приятноиметь для некоторых важных конфигурационных файлов. Кто же спорит? Жконф к этому таки отношение мало имеет, это уже проблемы бакэнда, я думаю. Но мысль ясна. О чём и речь: (1) к ведению истории изменений -- отношение мало имеет; Это же относится и к сегодняшнему подходу. К ведению истории изменений имеет отношение CVS, например. При чём здесь жконф или апач? Кстати, для типизованных параметров историю изменений можно и в реляционной базе данных организовать очень эффективно. Делается это заменой update на insert с текущим временем. Про отличие в скорости доступа, поиска и изменения по сравнению с текстовым файлом я говорить не буду, это и так понятно. -- Best regards, Sergey Spiridonov
Re: gconf2 на сервере
On Mon, Jul 07, 2003 at 08:27:15PM +0300, Oleg Gritsinevich wrote: - избавить программистов от рутинной писанины парсеров конфигов? В сложных случаях, как в примере с sendmail-ом, это невозможно. Случай с sendmail.cf это самый нетипичный пример. Для 9/10 пользователей sendmail sendmail.cf это некий экзотический конфигурационный кэш, который лежит в /etc, а не /var/cache для того, чтобы не оскорблять честь и достоинство оставшейся 1/10... или уже 1/100... -- Иван Лох
Re: gconf2 на сервере
Oleg Gritsinevich wrote: On Mon, Jul 07, 2003 at 01:48:21PM +0200, Sergey V. Spiridonov wrote: Oleg Gritsinevich wrote: On Fri, Jul 04, 2003 at 12:35:20PM +0200, Sergey V. Spiridonov wrote: [skip] 4. При всём при этом, остаётся возможность выбора бакэнда(формата) и возможность сетевого взаимодействия, без необходимости что-либо специально для этого программировать или изменять в приложении. Как в концепцию gconf-а вписывается конфиг sendmail-а (представляющий собой исходник на сноболе)? Да хоть на фортране. Какая разница? В чём Вы здесь видите проблему? Концепция жконфа вписывается так же, как TCP/IP вписывается в python, к примеру. Есть библиотека sockets, и есть к ней API на питоне. Точно так же есть библиотека gconf а для остальных языков пишется соответствующее API. Или я Вас не понял? Речь идёт не о биндингах к API gconf-a другого языка, а о другом. В данном случае _сам_ _конфиг_ (sendmail.cf) представляет собой программу на некотором языке, которую интерпретирует другая программа (в данном случае sendmail). Данный конфиг не вписывается в концепцию name-value pair и ни в какой другой общий формат описания конфига тоже не вписывается. Единственное, чем sendmail может воспользоваться в API gconf-a, IMHO нотификация об изменении конфига, и чем это лучше обычного kill -HUP? При такой постановке, конечно, толку от gconf мало. Я сам не знаком с внутренностями sendmail, хотя устанавливать и настраивать его пару раз приходилось. То что я помню, это текст, который сперва прогоняется через макропроцессор m4, а что потом с ним делается, я даже не интересовался. Так что квалифицированного ответа не ждите, но кое-какие соображения я выскажу. 1. Жконф работает с параметрами конфигурации. Называть текст интерпретируемой программы, даже если она может быть изменена пользователем, конфигурационным параметром конечно можно, но революционного смысла, потрясающего основы основ, как Вы правильно заметили, в этом особого нет. Но то что указанный текст представляет собой интерпретируемую программу не значит что *внутри* неё не используются конфигурационные параметры. Внутри этого конфигурационного файла, как я помню, были значения (придумываю на ходу), типа smarthostname(gnu.org). Так вот этот smarthostname и может быть конфигурационным параметром, хранимым в жконф. 2. Осмелюсь заявить, что такие программы как Sendmail это всё же скорее исключение, чем правило. И сложность изучения его языка кофнигурирования относится к разряду общепризнанных фактов. Завязывание программы на gconf автоматически сужает её область применения/распространения, по крайней мере системные вещи на него завязываться не должны и скорее всего не будут. Вы конечно в праве так полагать. Я надеюсь, вы основываетесь не только на сложности конфигурирования Сендмэил? Не совсем понятна цель создания gcnof-a: - избавить программистов от рутинной писанины парсеров конфигов? В сложных случаях, как в примере с sendmail-ом, это невозможно. Сложность этого случая, насколько я могу судить на основе моего скромного опыта использования не исключает возможность применения жконф, как я указал выше. Кроме того, сложность обуславливается в большей степени сложностью самого языка, а не конфигурации как таковой. - предоставить средства редактирования конфигов с валидацией синтаксиса и введённых значений? Ну синтаксис ещё можно кое-как отслеживать. Так большинство существующих программ и так не запустятся с ошибкой конфиге. Да, однако есть отличие между не запустится и невозможностью синтаксической ошибки. В случае проверки типа, мы гарантируем, что синтаксис (на описанном уровне, конечно), правилен. Проверка семантики? Она тоже возможна только в самом примитивном виде (проверка принадлежности значения к.-л. м-ву), а как н.п. проверить не попутал ли пользователь наружный интерфейс с внутренним в конфиге iptables? Если я Вас правильно понял, то в случае если пользователь попутал, то этого не заметит даже iptables? Конфигурирование сложных приложений gconf упростить не сможет, а в простых случаях ничего упрощать и не надо. Ни первое ни второе утверждение для меня, как для программиста, пользователя и порой администратора не очевидно. По крайней мере на основе приведенных примеров. Даже если в сендмэил было бы невозможно использовать жконф, я бы не стал ставить крест на этой идее. Кроме сендмэил, в Дебиане есть ещё 1 пакетов. IMHO работать оно будет только в простых случаях, а для простых случаев достаточно иметь библиотеку парсилки конфига (н.п. вида name-value pairs): на входе имя файла, на выходе представление конфига в виде списка/дерева и т.п., подсовываешь библиотеке ключ -- получаешь значение Ну, это именно то что сейчас есть, плюс оповещения и сетевая поддержка. параметра. Семантической проверкой вообще никак не заниматься -- пользователь перед началом конфигурирования должен внимателььно прочесть док-цию и
Re: Тормоза на Intel-маме
Дали мне, стало быть машинку. На Интелевой материнке. Так вот, диск на ней работает как-то небыстро. Пощупал hdparm - и удивился... Скорость совершенно неприличная. При том что режим - UDMA5, все как положено в лучших домах. Кто-то может меня просветить на предмет возможных причин такой гадости (малой скорости доступа к винту)? Буду благодарен за любые советы... Наверняка ядро 2.4.21 и модуль piix.o не загружен. -- MBR, Konstantin Starodubtsev
Re: firebird
On Thu, Jul 03, 2003 at 07:55:52PM +0300, Maxim Tyurin wrote: с незапамятных времен существует параметр подключения - isc_dpb_lc_ctype (или isc_dpb_lc_type, сейчас не помню), который определяет кодировку, в которой клиент хочет увидеть данные. И как уверяли люди это вполне работает. Сам я не пробовал, т.к. не было необходимости. Я пробовал с 1251 и исо5 - не работает :( Да и кои8 мне нужна, а она пока только в дятле где ты там нашел исо5 я конечно не знаю :-), но делал так: база и поля таблицы созданы с кодировкой UNICODE_FSS. Подключаюсь с lc_type=UNICODE_FSS вставляю в таблицу запись в UTF-8 (поработал iconv'ом для подготовки данных), затем переконекчиваюсь с win1251 и делаю селект из этой таблицы и вижу ту фразу, над которой я перед вставкой работал iconv'ом. На мой взгляд это вполне достаточное доказательство умения сервера конвертировать данные в кодировку запрошенную клиентом. Пробовал из isql и из ibexpert, результат одинаковый. Про PostgreSQL слышал, что его дока часто расходится с делом. Например в доке было написано, что, то-ли запись может иметь размер больше 8k, то-ли строковые поля могут быть больше 8k, точно не помню, но из этого вытекало, что запись может располагатся на нескольких страницах данных, т.к. максимальный размер страницы был 8k, а на деле выходило, что пересечение записью границы страницы невозможно. И такого рода фигня во многих местах. Это беда почти всех открытых проектов. Писать документацию и поддерживать ее в актуальном состоянии всем лениво про проблеммы с документацией согласен, но проблеммы такого уровня говорят о неслаженной работе команды разработчиков. Правда не покидает надежда, что это было давно и сейчас ситуация улучшилась. pgp59gbF9KvK3.pgp Description: PGP signature
Re: VPN
subscriber writes: Поставил себе Linux, под рукой оказался Debian 3.0, приятель попробовал и бросил. Все материалы (большинство) по системе, как я понял, берутся из сети. Я подключен к инету через VPN . В винде подключение происходит в три или четыре действия. Надо только знать IP прова, login и пароль. НИКАКОЙ информации о том, как это делать в Debian я НИГДЕ не нашел. Есть рекомендации для ASPLInux 7.3 (Vostok) s http://linuxportal.ru/forums/index.php?t=msgth=10396start=0rid=1698S=a37 aea07f25719a95419e5bb30c53fdd , но следовать им можно только до пункта 6. Далее скрипт /usr/sbin/pptp-command выдает сообщение об ошибке. Есть ли где-то примитивная пошаговая инструкция о том, что нужно делать для настройки VPN в Linux? Спасибо. Для настройки Интернета под ОС Линукс Вам понадобится несколько пакетов, главным из которых является пакет PPTP ( point-to-point tunelling protocol client). Этот пакет обычно входит в состав дистрибутива - но самые смелые из Вас могут и собрать из исходников:). В разных дистрибутивах название может отличаться - в Debian - PPTP-linux. 1) В файл /etc/resolv.conf добавляем адреса DNS серверов: /etc/resolv.conf --- search nameserver 195.222.70.10 nameserver 195.222.71.18 --- 2) В файле /etc/ppp/options прописываем опции: /etc/ppp/options --- lock +chap defaultroute noauth --- 3) Вводим логин и пароль в файл /etc/ppp/chap-secrets : /etc/ppp/chap-secrets --- pmvp1 * Myl0nglOngpassw0rD * --- Примечание: на этот файл рекомендую поставить права 400. 4) При каждом запуске системы необходимо прописывать роутинг командами (после gw должен стоять адрес Вашего шлюза (gateway)) : route del default route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.1XX.1 eth0 route add -net 195.222.64.67 netmask 255.255.255.255 gw192.168.1XX.1 eth0 5) Запускать соединение можно командой (укажите Ваш логин): pptp 195.222.64.67 nodetach user pmvp1 Примечание: запускать соединение нужно под рутом. Совет: Пункт 4 можно выполнять в инициальзационном скрипте системы. Туда же можно внести команду соединения с Интернетом. Другой способ - запускать соединение при помощи скрипта на шелле, состоящем из команд пунктов 4 и 5. Info by Al_Kovalevich -- //Alexander ICQ #96225688
Unidentified subject!
-- Gyre [ 0x241A44DE ] When I find true wisdom, I'll let you know, (if letting you know still seems important)
