date:20090318

Nicholas пишет:
 James Brown wrote:
 й
 я пока не рискую рабочую среду менять, решил на
 старом изучить и тогда уже решить вопрос об окончательной миграции,

 Поставте Debian на флешку:
 http://feraga.com/library/howto_install_debian_linux_onto_a_usb_thumb_drive_with_the_root_partition_encrypted_using_uuids_initramfs_tools_dm_crypt


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

 Есть терминал на Джаве, отлично работающий под Линукс, загружается
 через броузер и открывается в отдельных окнах, ничего инсталировать не
 надо:

 http://www.scottrade.com/scottradeelite_online_trading_platform/#


А КонсультантПлюс можно в Линуксе запустить?








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

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

On 17 March 2009 20:33:32 Alexey Pechnikov wrote:
 Hello!

 On Tuesday 17 March 2009 21:06:58 Alexander GQ Gerasiov wrote:
   Есть у меня и демоны на тикле, например, собирают и обрабатывают
   данные с цисок и других АТС. Написать то же самое на С большая работа
   (на тикле используются события для прослушивания множества сокетов, а
   на С придется создавать отдельные потоки), потому и не предлагаю как
   тестовую задачу (притом демоны умеют держать в in-memory SQLite
   database те данные, которые не удалось записать в persistent
   database), не говоря уж о реализации самой логики обработки.
 
  Ну, вообще говоря, есть довольно неплохая GLib2 или QtCore, в которых
  соответствующие примитивы.

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

 Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по
 рецепту Остапа Бендера.

Это уже вопрос религии. QtCore не значит иксы.

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

On 17 March 2009 20:44:05 Покотиленко Костик wrote:
 В Вто, 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 наверное тоже.

Потому как такая-же библиотека как и все остальные.

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

2009-03-18 Пенетрантность Кабанов Евгений

On 17 March 2009 21:00:54 Alexey Pechnikov wrote:
Hello!

On Tuesday 17 March 2009 21:44:05 Покотиленко Костик wrote:
Обращаю ваше внимание на постановку задачи:
Никаких внешних библиотек не используем, только встроенные средства.

Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
или .Net или что там у них сейчас.

Ошибаетесь. У меня под рукой дебиан как минимум на x86 и arm архитектурах
есть. Потому речь и шла о чистом С, что он кроссплатформенный - тикль,
понятно, тоже, как следствие.

И, кстати, MFC это враппер для Windows API, а не библиотека алгоритмов.
Библиотека алгоритмов для C++ это STL, которую сделали в Silicon Graphics,
насколько мне помнится.

Не говоря о том, что за Qt на сервере сразу надо убивать из рогатки по
рецепту Остапа Бендера.

Только за GLib убивать не стоит, за QtCore наверное тоже.

Стоит. За использование C++ с огромными перегруженными библиотеками.

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

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

Re: Биржевой терминал (Re: Утилита отлкючения п итания для ноутбука)

Легко, через Wine, если не родной, то от компании Etersoft.

On Wed, 18 Mar 2009 09:47:12 +0300
James Brown jbrownfi...@gmail.com wrote:
 А КонсультантПлюс можно в Линуксе запустить?

-- 
С уважением, Евгений


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

Юридические проблемы с Debian на ноутбуках при поез дках за границу

Уважаемые коллеги,
Не подскажите, могут ли быть какие-либо юридические проблемы с Debian на
ноутбуках при поездках за границу? и что известно по этому поводу
Например, насколько я понимаю, из-за каких-то проблем с американским
законодательством об ограничении экспорта криптопродуктов они вынуждены
не давать возможности загружать иностранцам какие-то пакеты с серверов,
расположенных в США, и держат их на зеркалах не в США.
Могут ли быть проблемы с въездом и выездом в США с ноутбуками на которых
установлен данный продукт? И не только в США, меня лично интересуют
больше европейские страны, арабский мир и Юго-Восточная Азия.


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

Re: Приложения не загр ужают второй процессор

On 2009.03.18 at 10:44:37 +0600, Dmitry Fedorov wrote:

18 марта 2009 г. 9:53 пользователь K K написал:

Поставил Lenny. Все настройки по-умолчанию. Процессор Intel E4400. Вот
только из коробки почемуто все приложения используют один процессор.

Любая программа может использовать больше одного процесса/нити только
если она так сконструирована изначально.
Большинство программ - однопотоковые.

Зато их много. Для работы современного GUI-приложения требуются кроме
самого приложения как минимум X-сервер, Window Manager, dbus-демон и
прочая, и прочая, и прочая.

Раньше, пока авторы тулкитов не увлекались client-side font
rendering-ом, был еще font-server и, между прочим его использование на
многопроцессорных системах давало заметный выигрыш в производительности
по сравнению с рендерингом шрифтов x-сервером (у которого других дел
хватает).

Далее, некоторые программы запускают всякие ресурсоемкие операции
отдельными процессами. Например GIMP так делает. Не знаю - всегда ли, но
во всяком случае в свое время, когда у меня были процессоры по 233МHz,
зато два, это было достаточно заметно. Одну картинку сканируешь, по
второй и третей despecle едит, четвертую ретушируешь уже руками.

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

Re: Юридические пробле мы с Debian на ноутбуках при поездках за гран ицу

On 2009.03.18 at 11:01:32 +0300, James Brown wrote:

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

По-моему, уже лет пять как секцию non-US из дистрибутива извели. В связи
с ослаблениями этих ограничений.


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

Re: Юридически е проблемы с Debian на ноутб уках при поездках за гра ницу

On Wed, 18.03.2009 11:14:24 , Victor Wagner wrote:
On 2009.03.18 at 11:01:32 +0300, James Brown wrote:

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

По-моему, уже лет пять как секцию non-US из дистрибутива извели. В связи
с ослаблениями этих ограничений.
Не пять. В sarge она ещё была. Сейчас проверил, на зеркалах каталог
/debian-non-US/dists/sarge/ присутствует, и stable указывает на него.

--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru

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

Re: Юридически е проблемы с Debian на ноутб уках при поездках за гра ницу

2009-03-18 Пенетрантность Oleksandr Gavenko

On Wed, 18.03.2009 11:01:32 , James Brown wrote:
 Уважаемые коллеги,
 Не подскажите, могут ли быть какие-либо юридические проблемы с Debian на
 ноутбуках при поездках за границу? и что известно по этому поводу
 Например, насколько я понимаю, из-за каких-то проблем с американским
 законодательством об ограничении экспорта криптопродуктов они вынуждены
 не давать возможности загружать иностранцам какие-то пакеты с серверов,
 расположенных в США, и держат их на зеркалах не в США.
 Могут ли быть проблемы с въездом и выездом в США с ноутбуками на которых
 установлен данный продукт? И не только в США, меня лично интересуют
 больше европейские страны, арабский мир и Юго-Восточная Азия.
Про Азию не скажу, но европейскому законодательству свободные лицензии
точно не противоречат; как и российскому. Говорю не с потолка, а со
слов своего хорошего знакомого, который вопросом занимается
профессионально. А раз не противоречат, то, полагаю, и с
ввозом/вывозом проблем быть не должно.

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

-- 
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru


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

Re: emacs22 lenny текст на рус ском


Aleksey Cheusov wrote:

P.S.
Вообще, есть fido7.ru.emacs
Совсем она какая-то мертвенькая :-(


Есть debian-ukr...@lists.debian.org
Совсем она какая-то мертвенькая, а значит ответов
не найду я там.

Разве что из спамеров кто то не выдержит - поможет!

--
С уважением, Александр Гавенко.
Компания БИФИТ.
Сайт:   www.bifit.com.ua
Тел:+38 (0562) 23-23-14, 23-31-00
E-mail: gave...@bifit.com.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

В Срд, 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: Функционал и интерфейс

В Вто, 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

chaos - debian-russian@lists.debian.org @ Sun, 15 Mar 2009 13:12:45 +0200:

http://www.ran.pp.ru/~ran/misc/stumpwm-mail.png

c Приятно, темой не поделишься? :)

Темой - нет. Нету у stumpwm такого понятия. Как класса. Он - тайловый...

А вот пакетами могу поделиться.

c Буда благодарен :)

http://www.ran.pp.ru/debian/

Во-первых, в дистрибутиве пакет
снапшота, а я собрал пакет более позднего релиза. А во-вторых, у него в
README сказано, что при использовании sbcl он может глючить, если sbcl
собран с поддержкой тредов (и насколько я увидел команды сборки в пакете
sbcl - очень может быть, что не stumpwm в этих глюках виноват...).
Короче, sbcl пересобран без тредов. До пересборки этих двух пакетов
конструкция имела привычку падать. Сейчас - не имеет.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Пользователь юникса перестаёт быть пользователем юникса если после его
пользования пользованный юникс перестаёт быть юниксом. (с)

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

Re: emacs22 lenny текст на русском

Aleksey Cheusov - Evgeny M. Zubok @ Tue, 17 Mar 2009 21:14:14 +0200:

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

Ага. Вся пакость этой переменной в том, что она не buffer-local, а
глобальная.
То есть управлять переносами в широкоэкранном режиме лучше
выключив эту переменную глобально, а щелкать в хуках
truncate-lines.

AC На мой взгляд не лучше.

Да без разницы. На _данной_ задаче, если ты уже лезешь в хук, то можно
и общую переменную подкрутить. Она все равно buffer-local по
определению. Смысла подкручивать ту, которая для частичных окон, уже не
видно.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

The effort of using machines to mimic the human mind has always struck
me as rather silly. I would rather use them to mimic something better
-- Edsger Dijkstra

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

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

Hello!

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

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

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

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

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

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

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

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

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

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

Best regards.

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

chaos - debian-russian@lists.debian.org @ Tue, 17 Mar 2009 17:21:03 +0200:

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

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

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

c Для начала тогда было бы не плохо определить, что это за задачи
c такие, которые относятся к разряду фундаментальных. И тут желательно
c не субъективное восприятие отдельной личности (потому как в этом
c случае будет всё ну очень растяжимо) а некоторая принятая
c классификация.

Фундаментальные - это, например, проверка теорий возникновения Вселенной.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Save the environment. Create a closure today.
-- Cormac Flanagan

--
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

В Срд, 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: linux-image с PAE с NCQ на AHCI

2009-03-18 Пенетрантность Roman Sokolov

Hello Иван Лох,

Поставил таки amd64 на одну машину, поднялось со второго раза, первый раз дошло
до стадии логина, но по сети сервер был не виден. Нажатие ctrl-alt-del решило
проблему с видимостью, но NCQ не появился.
Теперь вопрос меняется так: не сталкивались ли вы с неработой NCQ на платах с
Intel ESB2 в режиме ACHI, например в составе серверной платформы SuperMicro
6015?

on 17.03.2009 19:16, you wrote:
Сложности есть пропиетарными блобами в ядре. fgrlx, в частности.
А нет ли опыта как поведут себя платформозависимые вещи типа явы, у которых в
зависимости от архитектуры меняются размеры стеков и т.п.? Они будут
продолжать
считать себя на i386?

Вроде, работает.

С самим включением NCQ под PAE, я так понимаю, никто не заморачивался?

Думаю, что вы больше, собственно, на PAE теряете. Давно не проверял, но
раньше тормозило
знатно.

--
Best regards,
Roman
mailto:r...@cheater.ru

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

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


Artem Chuprina пишет:

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

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

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



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


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

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

Hello!

On Wednesday 18 March 2009 13:35:31 Artem Chuprina wrote:
   Для фундаментальных задач хороши инструменты, от которых ты,
 подозреваю,  в лучшем случае название слышал...

  c Для начала тогда было бы не плохо определить, что это за задачи
  c такие, которые относятся к разряду фундаментальных. И тут желательно
  c не субъективное восприятие отдельной личности (потому как в этом
  c случае будет всё ну очень растяжимо) а некоторая принятая
  c классификация.

 Фундаментальные - это, например, проверка теорий возникновения Вселенной.

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

Best regards.

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

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 :) Перловый код своим через месяц уже не является.

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

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

-- 
С уважением,
Константин Матюхин

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

On 18 March 2009 12:35:31 Artem Chuprina wrote:
 chaos - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 17:21:03 +0200:
 Перл бы еще рассказал, с какими аргументами была вызвана функция,
 что позволило бы найти ошибку гораздо быстрее.
  
ПК Не спорю. Этот инструмент хорош, но не для фундаментальных задач.
  
   Для фундаментальных задач хороши инструменты, от которых ты,
   подозреваю, в лучшем случае название слышал...

  c Для начала тогда было бы не плохо определить, что это за задачи
  c такие, которые относятся к разряду фундаментальных. И тут желательно
  c не субъективное восприятие отдельной личности (потому как в этом
  c случае будет всё ну очень растяжимо) а некоторая принятая
  c классификация.

 Фундаментальные - это, например, проверка теорий возникновения Вселенной.

Это как-то не определение классификации, а просто пример, не более того.

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

chaos - debian-russian@lists.debian.org @ Wed, 18 Mar 2009 12:55:55 +0200:

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

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

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

Фундаментальные - это, например, проверка теорий возникновения Вселенной.

c Это как-то не определение классификации, а просто пример, не более того.

Определения тут давать бессмысленно. Не математика. Всегда найдется
пограничный случай.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Все события вымышлены, после чего искажены.
-- lj user=mcdowns

--
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

Konstantin Matyukhin - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
14:17:55 +0300:

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

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

В основном, именно так, на перле и пишут :)
KM У вас есть какая-то статистика по этому поводу
KM или просто так для красного словца?

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

А вот упомянутую мной разницу между перлом и питоном, данную мне в
ощущении, уже имеет смысл анализировать на предмет врет мне мое
ощущение или нет?

И у меня есть ощущение, что перл таки входит в число наиболее
аккуратных языков по этому параметру. Уступая разве что
функциональникам.

Да. Мое ощущение perl vs. python у меня образовалось по опыту
взаимодействия с утилитами одного плана, а не так чтобы на перле -
системные, писанные для суровых админов, а на питоне - гуйня, писанная
пыонэрами для пыонэров. Там-то было бы понятно. То, на что я смотрел
- скорее системного плана.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Think of C++ as an object-oriented assembly language.
-- Bruce Hoult (br...@hoult.actrix.gen.nz)

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

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

Alexander Danilov - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
20:16:04 +0900:

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

Я бы на его месте сослался на авторитеты:

GNU is Not Unix (собственно расшифровка)

и

Linux is not UNIX (c) Linus Torvalds

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

/итд/почтопосылалка.нстрк (c)


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

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

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

Вот по-моему, они-то (и вообще все, кто развлекается методом
Монте-Карло) и не могут. Им нужно МНО-О-О-ГО случайных чисел. А
аппаратные ДСЧ всегда имеют ограниченную производительность. Намного
ниже скажем, линейно-конгруэнтного метода. Разве что алгоритм Yarrow
использовать.

К тому же чисто технически при отладке приложений, работающих с методом
Монте-Карло крайне полезно уметь воспроизводить последовательность
псевдослучайных чисел, с которой возникает проблема. 

Другое дело, что можно почитать того же Кнута и выбрать датчик,
параметры которого УСТРАИВАЮТ для решения данной задачи.


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

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

Покотиленко Костик пишет:

В Вто, 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 системы не для вас? Они спроектированы с основой на
текст.

--
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

Тихон Тарнавский - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
21:10:17 +0200:

При мысли о том что мне придётся написать парсер заголовков мне
никакой бинарь не страшен, хотя бы по той причине, что я его

[...]

Что до сложности формата mbox по сравнению с бинарными, звучит,
признаться, даже смешно. Когда мне нужно было выдернуть несколько
полей из большого количества писем и что-то с ними сделать, я решил
всю задачу на sh+coreutils+grep быстрее, чем в описании бинарного
формата нашёл бы и прочитал спецификации на эти поля и функции их
выдёргивания.

Для одноразового решения хороший вариант. Но, для больших объёмов не
подходит, индексировать некак. Читай выше со слов Допустим, есть
задача...

ТТ Не понял. Что некак индексировать? И как это зависит от текстовости
ТТ или бинарности исходного формата?

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

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Это неправильный шелл. В нем дают неправильный перл. (С)энта

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

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

On 2009.03.18 at 14:47:28 +0300, Artem Chuprina wrote:

 
 И у меня есть ощущение, что перл таки входит в число наиболее
 аккуратных языков по этому параметру.  Уступая разве что
 функциональникам.

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

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



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

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

Alexey Pechnikov - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
14:17:05 +0300:

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

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

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

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

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в b9td98$d8...@wagner.wagner.home


-- 
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

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'а приходится
парсить.

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

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

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

ПК сорьки.

ПК -все+вне

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

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

--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru

--
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


Twas brillig at 14:51:48 18.03.2009 UTC+03 when vi...@wagner.pp.ru did gyre and 
gimble:

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

Ты забываешь про армию сисадминов-наколенщиков.

-- 


pgpDNm1cpMNzT.pgp
Description: PGP signature

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

Hello!

On Wednesday 18 March 2009 14:39:49 Artem Chuprina wrote:
 Ну и эта...  Уж физики-то могут себе позволить _настоящий_ ДСЧ...  Он у
 них все равно есть, и какие-то датчики туда все равно заведены...

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

Best regards.

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

Alexey Pechnikov - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
14:53:21 +0300:

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

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

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

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Голова не может думать.  Там кальций, а не кремний.
 -- (С)энта


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

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

On Wed, Mar 18, 2009 at 02:51:48PM +0300, Victor Wagner wrote:
On 2009.03.18 at 14:47:28 +0300, Artem Chuprina wrote:

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

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

Фортрановское сообщество, на самом деле, успешно пережило, в конечном счете,
переход на Fortran9*. Нормальный язык, со своими плюсами и минусами. Он
совершенно не маргинален и не архаичен. Многие не верили, что это возможно.
На фортране IV aka 77, последние лет 5 уже не пишут.

Кстати, именно поэтому я верю в perl6.

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

Re: Юридические проблемы с Debian на ноутбуках при пое здках за границу

2009-03-18 Пенетрантность Nicholas


James Brown wrote:

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


В принципе, не могут быть.

Проблемы могут быть, если продавать(!) (а не распространять бесплатно 
или просто использовать) сильную криптографию на терр. бывшего союза.



Debian - самый лицензионно чистый дистрибьютив - это чуть ли не слоган 
сайта Дебиан.




--
Sincerely,
Nicholas


--
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

В Срд, 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

В Срд, 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: Функционал и интерфе йс


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, с помощью которой на Си событийно писать проще.
Но вообще прикладуху на Си писать не интересно, борьба с языком(слишком 
низкоуровневый)
и развивается паранойя при использовании каждого указателя.


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

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

Hello!

On Wednesday 18 March 2009 15:15:32 Artem Chuprina wrote:
  AP Любой эксперимент, в т.ч. численный, должен быть
  AP воспроизводим. Программная реализация (через прямое-обратное фурье)
  AP работает с любым случайным шумом на входе и, следовательно, условие
  AP воспроизводимости соблюдается. Аппаратная реализация, снимающая
  AP микропараметры среды, дает принципиально невоспроизводимый
  AP результат - даже в той же лаборатории с тем же образцом
  AP микрохарактеристики среды изменяются с течением времени.

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

Результат численного эксперимента не должен зависеть от исходного 
распределения с заданными макропараметрами (скажем, задаем радиус корреляции 
исходных неоднородностей, амплитуду и гауссов закон распределения). Так что 
работать с одной и той же последовательностью нельзя, наоборот, требуется 
создать некоторое множество начальных распределений и на всех прогнать 
эксперимент. Если численная модель верна, то при тех же макропараметрах среды 
любое начальное распределение должно приводить к одинаковому результату.

Best regards.

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

On Wed, Mar 18, 2009 at 02:28:11PM +0200, Покотиленко Костик wrote:

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

Для этого придумали XML. Где (a) не надо усложнять парсер, (б) есть схема
и верификация.



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

Re: Кириллица в консоли - кракозябры


Constantine пишет:

Приветствую.

Evgeny M. Zubok пишет:



Точно такие же симптомы и тоже с nvidia (с nv забыл
проверить). Разобраться не успел -- ноут пришлось отдать. Отрадно, что
целевая аудитория ноута консолью не пользуется. :)


Погуглил... да, проблема в последних(?) драйверах нвидиа (то ли 
параметры в xorg.conf некоторые устарели??, толи еще нечто...). Вроде бы 
есть некий способ лечения, но датированный(!!) 2006 годом :) (ошибка и 
тогда была). Пробовать не хочется, м.б. со след. версией драйверов 
исправится...




Проблема есть до сих пор, только что проверил. Lenny amd64.
Про целевую аудиторию подмечено верно.


--
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

Покотиленко Костик - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 
14:28:11 +0200:

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

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

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

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

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

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

На реализации TLS в этом смысле очень полезно посмотреть.  Особенно - на
те, которые до сих пор поддерживают совместимость с SSL 2.0.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Вот .NET и Mono - это современные технологии.  В смысле - сырые и глюкавые.
Victor Wagner в cisnd1$qt...@wagner.wagner.home


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

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


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 распухать. Вообще перл не провоцирует на 
написание понятного
кода, но предлагаю эту тему не развивать. Перл для меня пройденный этап, я свои 
выводы сделал, я
им теперь очень редко пользуюсь, придёт время - вы сделаете свои выводы.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данные обрабатываемого запроса в других процессах/потоках никому просто не
нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже
рассмотрено
выше. А насчет общей памяти - от этого решения уже и многие СУБД
отказываются.
В результате использования 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: Функционал и интерфейс

Alexey Pechnikov - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
15:35:59 +0300:

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

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

AP Результат численного эксперимента не должен зависеть от исходного
AP распределения с заданными макропараметрами (скажем, задаем радиус
AP корреляции исходных неоднородностей, амплитуду и гауссов закон
AP распределения). Так что работать с одной и той же
AP последовательностью нельзя, наоборот, требуется создать некоторое
AP множество начальных распределений и на всех прогнать
AP эксперимент. Если численная модель верна, то при тех же
AP макропараметрах среды любое начальное распределение должно
AP приводить к одинаковому результату.

Импоссибл. Потому что точность вычислений ограничена по определению.
Равно как и точность статистики. Оно может приводить только к
_близкому_ результату. И при _близких_, а не _совпадающих_
макропараметрах - тоже.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Will write code that writes code that writes code that writes code for
money.
-- on comp.lang.lisp

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

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

On Wed, Mar 18, 2009 at 03:53:28PM +0300, Artem Chuprina wrote:
 
 Импоссибл.  Потому что точность вычислений ограничена по определению.
 Равно как и точность статистики.  Оно может приводить только к
 _близкому_ результату.  И при _близких_, а не _совпадающих_
 макропараметрах - тоже.

Не. Имеется в виду, что решение должно сходиться к одной точке.
А не к близкой к ней ;-} 


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

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

В Срд, 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

В Срд, 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

Страшное зависание сис темы от работы CD-привода

Не подскажите, как с этим бороться.
Имеется старенький ноут 2003 г. выпуска Celeron 128 Мгб ОЗУ 1066 Мгц
Установил Debian 5.0 lenny
Когда вставляешь диск в CD-привод, работаешь с диском, система виснет на
неск. минут, и для того чтобы достать диск, тоже надо потратить кучу
нервов из-за зависания.
Та же история и с USB-флешками - как вставишь крату, система виснет,
хотя немного на меньшее время.
Граф. интерфейс - Xfce4.
Во флюбоксе работает побыстрее, но хотелось бы по-возможности работать с
интерфейсом Xfce


-- 
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

В Срд, 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: Функционал и интерфейс

Иван Лох - debian-russian@lists.debian.org  @ Wed, 18 Mar 2009 15:58:11 +0300:

  Импоссибл.  Потому что точность вычислений ограничена по
  определению.  Равно как и точность статистики.  Оно может приводить
  только к _близкому_ результату.  И при _близких_, а не _совпадающих_
  макропараметрах - тоже.

 ИЛ Не. Имеется в виду, что решение должно сходиться к одной точке.  А
 ИЛ не к близкой к ней ;-}

_Сходиться_ - не вопрос.  Вопрос в том, что _точное_ значение этой
точки получить все равно невозможно принципиально.  Равно как и _точные_
значения макропараметров распределения.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Курицца - не пицца. (Итальянская пословицца)


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

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

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.

 -- 



-- 
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/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. И да, я не люблю, когда
меня что-то или кто-то провоцирует.

-- 
С уважением,
Константин Матюхин

Re: Perl or Python?

Alexander Danilov пишет:
 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 распухать. Вообще перл не
 провоцирует на написание понятного
 кода, но предлагаю эту тему не развивать. Перл для меня пройденный
 этап, я свои выводы сделал, я
 им теперь очень редко пользуюсь, придёт время - вы сделаете свои выводы.

А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?




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

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

Покотиленко Костик пишет:

В Срд, 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'а приходится
парсить.

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

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

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

ПК сорьки.

ПК -все+вне

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

И для данной версии твоей программы!

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

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

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

Re: Perl or Python?

2009/3/18 James Brown jbrownfi...@gmail.com:
 А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?
А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП, а в общем
уровне програмистской культуры. А это только опыт и фундаментальные знания.

-- 
С уважением,
Константин Матюхин

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

Покотиленко Костик - 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).

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

The Eclipse Platform is an open and extensible platform
for anything and yet nothing in particular.
 -- apt-cache show eclipse-platform


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

Re: Perl or Python?


Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com did gyre 
and gimble:

 KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП,
 KM а в общем уровне програмистской культуры. А это только опыт и
 KM фундаментальные знания.

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

-- 


pgpbYz2KpEF7x.pgp
Description: PGP signature

Re: Страшное зависание с истемы от работы CD-привода


James Brown пишет:

Не подскажите, как с этим бороться.
Имеется старенький ноут 2003 г. выпуска Celeron 128 Мгб ОЗУ 1066 Мгц
Установил Debian 5.0 lenny
Когда вставляешь диск в CD-привод, работаешь с диском, система виснет на
неск. минут, и для того чтобы достать диск, тоже надо потратить кучу
нервов из-за зависания.
Та же история и с USB-флешками - как вставишь крату, система виснет,
хотя немного на меньшее время.
Граф. интерфейс - Xfce4.
Во флюбоксе работает побыстрее, но хотелось бы по-возможности работать с
интерфейсом Xfce




Смотреть на thunar и hal.


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

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


Покотиленко Костик пишет:

[skip]



Если посмотреть выше, то речь шла о демонах, а не парсерах текстовых
файлов. Или Вы считаете их равнозначными задачами?

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

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


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


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


Уровень языка Си уже определён - он чуть выше ассемблера, и использование
библиотек на этот уровень почти не влияет.



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



А может Вы просто не пробовали на языках высокого уровня работать с нижним 
уровнем?


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

Re: Perl or Python?

2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:

 Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com did gyre 
 and gimble:

  KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП,
  KM а в общем уровне програмистской культуры. А это только опыт и
  KM фундаментальные знания.

 Неудачный язык может привить соответствующую культуру.
От языка почти не зависит. По-русски разговаривают и Сява и Сева.

-- 
С уважением,
Константин Матюхин

Re: Perl or Python?

2009-03-18 Пенетрантность Alexander GQ Gerasiov


Twas brillig at 16:45:50 18.03.2009 UTC+03 when kmatyuk...@gmail.com did gyre 
and gimble:

 KM От языка почти не зависит. По-русски разговаривают и Сява и Сева.

По-гоповски разговаривают только сявы.

-- 


pgpP66jhP4YHC.pgp
Description: PGP signature

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

Tue, 17 Mar 2009 22:00:54 +0300
Alexey Pechnikov pechni...@mobigroup.ru wrote:

Hello!

Постановка с подковыркой, заведомо выиграет C# со встроенным MFC
или .Net или что там у них сейчас.

Ошибаетесь. У меня под рукой дебиан как минимум на x86 и arm
архитектурах есть. Потому речь и шла о чистом С, что он
кроссплатформенный - тикль, понятно, тоже, как следствие.

И, кстати, MFC это враппер для Windows API, а не библиотека
алгоритмов. Библиотека алгоритмов для C++ это STL, которую сделали в
Silicon Graphics, насколько мне помнится.

Не говоря о том, что за Qt на сервере сразу надо убивать из
рогатки по рецепту Остапа Бендера.

Только за GLib убивать не стоит, за QtCore наверное тоже.

Стоит. За использование C++ с огромными перегруженными библиотеками.
Кто огромный перегруженный? QtCore? Ну-ну.
GLib - вообще объектный но на Си =\

--
Best regards,
Alexander GQ Gerasiov

Contacts:
e-mail:g...@cs.msu.su Jabber: g...@jabber.ru
Homepage: http://gq.net.ru ICQ: 7272757
PGP fingerprint: 0628 ACC7 291A D4AA 6D7D 79B8 0641 D82A E3E3 CE1D

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

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

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. И да, я не люблю, когда
меня что-то или кто-то провоцирует.

Это не провокация, я в своё время тоже писал на перл, очень активно, и он мне
очень нравился.
Писать на нём интересно, читать(поддерживать) сложно.

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

Re: Perl or Python?

On 2009.03.18 at 16:24:38 +0300, James Brown wrote:

 
 А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?
 
 ocaml, haskel, erlang, scheme, common lisp.

Если человек ДЕЙСТВИТЕЛЬНО новичок и мозги не замылены императивщиной,
то лучше начинать с ФП. 


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

Re: Perl or Python?

James Brown пишет:

Alexander Danilov пишет:

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 распухать. Вообще перл не
провоцирует на написание понятного
кода, но предлагаю эту тему не развивать. Перл для меня пройденный
этап, я свои выводы сделал, я
им теперь очень редко пользуюсь, придёт время - вы сделаете свои выводы.

А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?

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

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

Re: Perl or Python?


Konstantin Matyukhin пишет:

2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:

Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com did gyre 
and gimble:

 KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП,
 KM а в общем уровне програмистской культуры. А это только опыт и
 KM фундаментальные знания.

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

От языка почти не зависит. По-русски разговаривают и Сява и Сева.



Очень сильно зависит. Язык - это определяющий фактор. В программирование - тем 
более.


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

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


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 - это сишная библиотека хорошего качества, рекомендую. :)


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

Re: Perl or Python?


Twas brillig at 17:01:23 18.03.2009 UTC+03 when vi...@wagner.pp.ru did gyre and 
gimble:

  А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?

 VW  ocaml, haskel, erlang, scheme, common lisp.

Минус CL и Ocaml. design by committee.

P.S: в haskell был хороший committee :)

-- 


pgpfok85S7une.pgp
Description: PGP signature

Re: Perl or Python?

2009/3/18 Alexander Danilov alexander.a.dani...@gmail.com:
 Konstantin Matyukhin пишет:

 2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:

 Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com did
 gyre and gimble:

  KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП,
  KM а в общем уровне програмистской культуры. А это только опыт и
  KM фундаментальные знания.

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

 От языка почти не зависит. По-русски разговаривают и Сява и Сева.

 Очень сильно зависит. Язык - это определяющий фактор. В программирование -
 тем более.
Ага, ага. Написать два экрана if-ов вам не помешает ни один из ЯП.
Может и среди человеческих языков есть неудачные? Чего ж так много
быдла-то кругом?

-- 
С уважением,
Константин Матюхин

Re: Perl or Python?


Twas brillig at 17:09:18 18.03.2009 UTC+03 when kmatyuk...@gmail.com did gyre 
and gimble:

 KM Может и среди человеческих языков есть неудачные?

Падонкавские сленги и прочие жаргоны.

-- 


pgpngZAUWi7Tv.pgp
Description: PGP signature

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

Alexander Danilov - debian-russian@lists.debian.org @ Wed, 18 Mar 2009
23:05:50 +0900:

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

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

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

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

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

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

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

AD Кстати, Tcl - это сишная библиотека хорошего качества, рекомендую. :)

Кстати, да.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru

Голова не может думать. Там кальций, а не кремний.
-- (С)энта

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

Re: Страшное зависание системы от работы CD-привода

2009-03-18 Пенетрантность Andrey Nikitin

В сообщении от 18 марта 2009 James Brown написал(a):
 Когда вставляешь диск в CD-привод, работаешь с диском, система виснет на
 неск. минут,

Смотреть dmesg на предмет проблемных сообщений от ядра.
Наблюдал подобное у себя, когда плохо (слабо) воткнул
IDE кабель на разъём привода.  

-- 
С Уважением,
   Андрей Никитин


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

Re: Perl or Python?

On Wed, Mar 18, 2009 at 04:24:38PM +0300, James Brown wrote:
 
 А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?

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

Языки с IMHO простым и хорошим дизайном Lua и javascript.
За ними будущее. Кроме того, это мультипарадигменные
языки. На них удобно писать и в процедурной манере и в объектной
и в функциональной.


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

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

On Wed, Mar 18, 2009 at 04:23:08PM +0300, Artem Chuprina wrote:
 
  ИЛ Не. Имеется в виду, что решение должно сходиться к одной точке.  А
  ИЛ не к близкой к ней ;-}
 
 _Сходиться_ - не вопрос.  Вопрос в том, что _точное_ значение этой
 точки получить все равно невозможно принципиально.  Равно как и _точные_
 значения макропараметров распределения.

Точное значение -- это какое-нибудь трансцендентное число? Тогда
нет, конечно. Но обеспечить _наперед заданную_ точность можно на
любом распределении. Если мы, конечно, в нужную долину попали.


-- 
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

Hello!

On Wednesday 18 March 2009 16:23:58 Konstantin Matyukhin wrote:
  Перл для меня пройденный этап, я свои выводы сделал, я
  им теперь очень редко пользуюсь, придёт время - вы сделаете свои выводы.

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

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

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

Best regards.

Re: Perl or Python?

On Wed, 18.03.2009 17:09:18 , Konstantin Matyukhin wrote:
 2009/3/18 Alexander Danilov alexander.a.dani...@gmail.com:
  Konstantin Matyukhin пишет:
 
  2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:
 
  Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com did
  gyre and gimble:
 
   KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП,
   KM а в общем уровне програмистской культуры. А это только опыт и
   KM фундаментальные знания.
 
  Неудачный язык может привить соответствующую культуру.
 
  От языка почти не зависит. По-русски разговаривают и Сява и Сева.
 
  Очень сильно зависит. Язык - это определяющий фактор. В программирование -
  тем более.
 Ага, ага. Написать два экрана if-ов вам не помешает ни один из ЯП.
 Может и среди человеческих языков есть неудачные? Чего ж так много
 быдла-то кругом?
Это теоретически не помешает. А практически я что-то ни в одном
функциональном языке (Common Lisp, Scheme, Ocaml, ELisp) такого не
встречал _ни разу_. А на пхп и васике -- сплошь и рядом; да и на
питоне попадалось. Я, признаться, и сам жалею, что моими первыми
языками были васик, си и паскаль а не тот же лисп, скажем. Возможно, и
сейчас бы иначе к программированию относился.

-- 
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru


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

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

On Wed, Mar 18, 2009 at 05:41:51PM +0300, Alexey Pechnikov wrote:
 Hello!
 
 On Wednesday 18 March 2009 16:23:58 Konstantin Matyukhin wrote:
   Перл для меня пройденный этап, я свои выводы сделал, я
   им теперь очень редко пользуюсь, придёт время - вы сделаете свои выводы.
 
  Сделал. Пишу теперь, практически, только на Perl. И да, я не люблю, когда
  меня что-то или кто-то провоцирует.
 
 Несколько лет назад с командой программистов мы разработали и поддерживали 
 веб-систему в несколько мегабайт перлового кода. Поддержка была весьма 
 трудоемкой, так как периодически нужно вносить различные изменения, поскольку 
 очень значительная часть кода меняется в течении каждого года. После 
 переписывания на тикле поддержка и доработка стала на порядок менее 
 затратной, 
 при том что и функционал значительно увеличился

Это из-за рефакторинга ;-} С перла на перо тоже хорошо бы получилось ;-}



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

Re: Perl or Python?

Alexander Danilov пишет:

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


А с чего лучше начать?! (учиться правильно программировать, точнее, если
быть честным :-[  учиться программировать)


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

Re: Perl or Python?

Konstantin Matyukhin пишет:

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

Konstantin Matyukhin пишет:

2009/3/18 Mikhail Gusarov dotted...@dottedmag.net:

Twas brillig at 16:30:26 18.03.2009 UTC+03 when kmatyuk...@gmail.com did
gyre and gimble:

KM А новичку не все ли равно? Хоть BASIC. Дело-то не в конкретном ЯП,
KM а в общем уровне програмистской культуры. А это только опыт и
KM фундаментальные знания.

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

От языка почти не зависит. По-русски разговаривают и Сява и Сева.

Очень сильно зависит. Язык - это определяющий фактор. В программирование -
тем более.

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

Очень поверхностный взгляд. Человеческие языки имеют свои особенности и
переводить
с одного на другой буквально нельзя, надо учитывать, как минимум, культурные
различия.
В языке какого-то из северных народов существует более тридцати (30)
обозначений снега.
В моём языке такого нет.

Языки программирования тем более отличаются, они задачи разные решают.
Попробуйте
дословно или хотя бы приблизительно переводить с erlang'а на php. Или с лиспа
на си.
А потом посчитайте насколько упало качество кода, хотя бы, об остальных
факторах я умолчу.
Не существует универсального языка программирования, один язык не равен другому.
Существуют парадигмы программирования, они существенно разделяют языки.

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

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

Re: Perl or Python?

Victor Wagner пишет:
 On 2009.03.18 at 16:24:38 +0300, James Brown wrote:

  
   
 А что Вы посоветуете новичку, Python? Или желательно Perl тоже изучить?
 
  
  ocaml, haskel, erlang, scheme, common lisp.

 Если человек ДЕЙСТВИТЕЛЬНО новичок и мозги не замылены императивщиной,
 то лучше начинать с ФП. 
   

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


-- 
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

В Срд, 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 :) Перловый код своим через месяц уже не является.

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

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

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

Сделал. Пишу теперь, практически, только на 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: Perl or Python?

James Brown пишет:

Alexander Danilov пишет:

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

А с чего лучше начать?! (учиться правильно программировать, точнее, если
быть честным :-[ учиться программировать)

Это очень трудный вопрос.

Начать следует с чтения теории и применять её на практике.
Советую прочесть SICP - Структура и интерпретация компьютерных программ.
Книжка выпущена на русском в бумажном виде, есть в электронном виде по-русски -
sicp.pdf
Но надо искать тот pdf, что с картинками. Это книга научит думать головой.
Там теория и практика.

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

Более советовать не стану, учить никогда не умел.

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

Вопрос по fluxbox

Если можно, простите новичка за тупость, но поняв, что xfce на моем
старом ноуте виснет, я решил все-таки юзать fluxbox, который более
легкий но у которого более трудный для воспринятия граф. интерфейс.
Столкнулся с такой проблемой. Когда входишь в него, для того, чтобы
получить выпадающее меню и открывать разные программы, достаточно
кликнуть по левой кнопке мыши.
После того, как я открываю управление файлами/наутилус, у меня когда я
кликаю на правую мышь открывается только панель инструментов,
соответственно ни терминал, ничего больше я не могу открыть, приходиться
делать Ctrl-Alt-Backspace и снова заходить в систему.


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

Re: Юридически е проблемы с Debian на ноутб уках при поездках за гра ницу

On Wed, 18.03.2009 08:23:08 , Nicholas wrote:
 James Brown wrote:
 Уважаемые коллеги,
 Не подскажите, могут ли быть какие-либо юридические проблемы с Debian на
 ноутбуках при поездках за границу? 

 В принципе, не могут быть.

 Проблемы могут быть, если продавать(!) (а не распространять бесплатно  
 или просто использовать) сильную криптографию на терр. бывшего союза.


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

-- 
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru


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

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

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

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

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

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

В 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: Функционал и интерфейс

В Срд, 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 Пенетрантность Dmitry E. Oboukhov

В Срд, 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: Вопрос п о fluxbox

On 18:01 Wed 18 Mar , James Brown wrote:
JB Если можно, простите новичка за тупость, но поняв, что xfce на моем
JB старом ноуте виснет, я решил все-таки юзать fluxbox, который более
JB легкий но у которого более трудный для воспринятия граф. интерфейс.
JB Столкнулся с такой проблемой. Когда входишь в него, для того, чтобы
JB получить выпадающее меню и открывать разные программы, достаточно
JB кликнуть по левой кнопке мыши.
JB После того, как я открываю управление файлами/наутилус, у меня когда я
JB кликаю на правую мышь открывается только панель инструментов,
JB соответственно ни терминал, ничего больше я не могу открыть, приходиться
JB делать Ctrl-Alt-Backspace и снова заходить в систему.

Ну Ctrl-Alt-Backspace это жестоко, мог бы просто изменить размер
окошка.
а вообще можно настроить меню по клику мышью по toolbar'у, например:

OnToolbar Mouse3 :rootMenu

будет показывать rootMenu по клику правой мыши в любом месте тулбара

OnToolbar Mouse4 :nextWorkspace
OnToolbar Mouse5 :prevWorkspace

будет прокручивать рабочие столы когда мы мышкой крутим над тулбаром

ну и так далее.
--
... mpd paused: Accept - Balls To The Wall

. ''`. Dmitry E. Oboukhov
: :’ : email: un...@debian.org jabber://un...@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

signature.asc
Description: Digital signature

Re: Вопрос по fluxbox

2009-03-18 Пенетрантность Maxim Filimonov

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

On Wed, 18 Mar 2009 18:01:33 +0300
James Brown jbrownfi...@gmail.com wrote:

Если можно, простите новичка за тупость, но поняв, что xfce на моем
старом ноуте виснет, я решил все-таки юзать fluxbox, который более
легкий но у которого более трудный для воспринятия граф. интерфейс.
Столкнулся с такой проблемой. Когда входишь в него, для того, чтобы
получить выпадающее меню и открывать разные программы, достаточно
кликнуть по левой кнопке мыши.
После того, как я открываю управление файлами/наутилус, у меня когда я
кликаю на правую мышь открывается только панель инструментов,
соответственно ни терминал, ничего больше я не могу открыть, приходиться
делать Ctrl-Alt-Backspace и снова заходить в систему.

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

--
wbr, Maxim Filimonov

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

Re: Вопрос п о fluxbox

2009-03-18 Пенетрантность Dmitry E. Oboukhov

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

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

--
... mpd paused: Accept - Balls To The Wall

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

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

В Срд, 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