subject:"Как спастись от 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: Как спастись от 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: Как спастись от mysql-server в KDE 4.2

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

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

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

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


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

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

2009/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: Как спастись от 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: Как спастись от 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: Как спастись от mysql-server в KDE 4.2

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


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: Как спастись от 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: Как спастись от 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: Как спастись от 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

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

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

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

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

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


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

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

2009/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: Как спастись от mysql-server в KDE 4.2

Hello!

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

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

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

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

Best regards.

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

ПК -все+вне

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

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

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

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

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

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

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

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

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

2009/3/18 Покотиленко cas...@meteor.dp.ua:
  Konstantin Matyukhin пишет:
 Сделал. Пишу теперь, практически, только на Perl. И да, я не люблю, когда
                                    ^^
 Вы себя неоправданно ограничиваете.

 меня что-то или кто-то провоцирует.
Я пишу для души и по-необходимости, а не для продажи.
Так что ущемленным себя не чувствую. Раньше писал
и на С, и на OCaml, и даже на VB. Я не говорю уже о Pascal
и нескольких других.

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

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

Hello!

On Wednesday 18 March 2009 17:40:59 Иван Лох wrote:
 Это из-за рефакторинга ;-} С перла на перо тоже хорошо бы получилось ;-}

Кодогенератор на перле никаким рефакторингом не сделаешь.

Best regards.

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

Hello!

On Wednesday 18 March 2009 18:19:04 Konstantin Matyukhin wrote:
 Я пишу для души и по-необходимости, а не для продажи.

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

 Так что ущемленным себя не чувствую. Раньше писал
 и на С, и на OCaml, и даже на VB. Я не говорю уже о Pascal
 и нескольких других

Судя по вышеизложенному, написание программы, показывающей hello для вас 
равно знанию языка?

Best regards.

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

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

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

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

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

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

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

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

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

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

Hello!

On Wednesday 18 March 2009 18:19:06 Покотиленко Костик wrote:
Обратную совместимость соблюдать конечно надо, тогда переход будет
безболезненный. Пример сервер уже умеет новую вервию протокола с
расширенным набором команд, а клиент нет, в протоколе должна быть
возможность это выяснить и сервер может общаться с клиентом на старой
версии. Также и клиент должен общаться с сервером набором комонд,
которые тот поддерживает. Со временем сильно старые версии можно
запрещать.

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

Best regards.

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

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

On Wednesday 18 March 2009 18:28:11 Покотиленко Костик wrote:

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

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

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

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

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

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

-- 
мысли о тебе...
Как о хлебе насущном
Где моя Муза?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello!

On Wednesday 18 March 2009 19:02:48 Victor Wagner wrote:
  Кодогенератор на перле никаким рефакторингом не сделаешь.

 А зачем? use Sandbox; use Opcode; и строчек в 1000 с помощью лома и
 какой-то матери можно сделать аналог safe interpreter Tcl. Причем с даже
 более тонким контролем. Потому что можно управлять доступом не только на
 уровне команд, как в tcl, а на уровне отдельных операций байткода.

 Правда, гораздо сложнее.

Вот именно - зачем? Зачем делать на перле, если на тикле это уже есть и 
прекрасно работает? Может быть, и некорректно сказать, что перл хуже, потому 
что не позволяет эффективно работать с динамическим кодом, но после трех лет 
разработки на тикле мои проекты в рамки перла уже просто не втиснешь. Хотя 
кого-то устраивает перл, потому что на нем лугко делаются однострочники. От 
задачи зависит.

Best regards.

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

Hello!

On Wednesday 18 March 2009 18:11:46 Покотиленко Костик wrote:
   Ты забываешь про армию сисадминов-наколенщиков.
 
  Во-первых, их код редко попадает на CPAN или в иное общее пользование.
  Во-вторых, СОВРЕМЕННЫЕ сисадмины-наколеночники пишут на python и php.
  Собственно ровно для них в поставку php включен standalone интерпретатор
  и разрабатываются разные прибамбасы вроде php-gtk.

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

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

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

Best regards.

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

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

On Wednesday 18 March 2009 22:36:45 Покотиленко Костик wrote:

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

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


чем сложнее то?  и почему вероятнее?

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

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

это вообще, как ни бинарный протокол, так либа, и тут же у меня мысли 
интересные возникают :-/

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


--

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

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

Вообще то, Fortran IV - это Fortan IV, а Fortran 77 и 66 - это совсем
другой язык и совсем другие года.
http://en.wikipedia.org/wiki/Fortran

-- 
Best regards, Aleksey Cheusov.


-- 
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 (собственно расшифровка)
GNU's Not Unix
пардон.

 и

 Linux is not UNIX (c) Linus Torvalds
Нашли, чем гордиться :-P

UNIX - это:
- технология
- торговый знак
- класс систем, построенных на основе стандартов (POSIX, SUS, ...)

По двум пунктам из трех, Linux - это UNIX. Не путай ты молодежь ;-)

-- 
Best regards, Aleksey Cheusov.


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


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

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

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

-- 
Best regards, Aleksey Cheusov.


-- 
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, Mar 18, 2009 at 09:36:31PM +0200, Aleksey Cheusov wrote:
Фортрановское сообщество, на самом деле, успешно пережило, в конечном
счете,
переход на Fortran9*. Нормальный язык, со своими плюсами и минусами. Он
совершенно не маргинален и не архаичен. Многие не верили, что это
возможно.
На фортране IV aka 77, последние лет 5 уже не пишут.

Вообще то, Fortran IV - это Fortan IV, а Fortran 77 и 66 - это совсем
другой язык и совсем другие года.
http://en.wikipedia.org/wiki/Fortran

Мне нравится выражение _совсем другой язык_ Какая же из инноваций
Fortran77 или, тем более, 66, Вас так зацепила?
Меня зацепила фраза Fortran IV aka 77. Между этими стандартами почти
20 лет. Это исторически неправильно.

По мне, так это чисто косметическая фигня, ну ввод-вывод чуть-чуть
поправили.
Считается, что отсутствие стандартизированного кроссплаформенного
ввода-вывода погубила Algol ;-) И в некотором смысле всю эту ветку
Algol-60-68, Pascal, Modula2-3, Ada, Oberon.
Из чулана появился С и понеслась кривая {{{}}}
C++, Objective C, awk, Java Script, rc, csh, Java, C#.
Совсем другая мода.

Это совсем не фигня ;-)

Я некоторое время использовал две машины, на одной стоял
компилятор фортрана IV на другой 66. И я не помню, чтобы у меня хоть
раз были проблемы с несовместимостью. Ну там, акценты в использовании
в использовании операторов перехода чуть поменялись. Посмотрите на код
написанный в 80-х начале 90-х он практически никак не отличается от
кода 60-х. Кода 50-х я вживую не видел.
Я всего лишь поправил историческую ошибочку. Не более того.

--
Best regards, Aleksey Cheusov.

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

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

2009-03-17 Пенетрантность chaos

On 17 March 2009 05:33:33 Alexander Danilov wrote:
 Aleksey Cheusov пишет:
Программное использование gdb - это, конечно, лучше, чем ручное.  Но
хуже, чем такое программирование, где gdb использовать не требуется.
 
  Не верю, что в сложных проектах можно обойтись без дебагера.
 
  В сложных проектах нужно писать тесты. И в простых тоже.
  Тогда дебаггер не понадобится.

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

Любимое занятие :) переделывать всё с нуля :)

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

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

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

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


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

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

В Вто, 17/03/2009 в 21:41 +0900, Alexander Danilov пишет:
chaos пишет:
On 17 March 2009 05:33:33 Alexander Danilov wrote:
Aleksey Cheusov пишет:
Программное использование gdb - это, конечно, лучше, чем ручное. Но
хуже, чем такое программирование, где gdb использовать не требуется.
Не верю, что в сложных проектах можно обойтись без дебагера.
В сложных проектах нужно писать тесты. И в простых тоже.
Тогда дебаггер не понадобится.
Тесты конечно хорошо, но очень важно правильно спроектировать систему.
Заметил такую интересную тенденцию, в системах со слабо связанными модулями
отладчик не нужен, максимум - печать промежуточных значений. В тех же
системах, где модули привязаны друг к другу намертво, отладчик -
единственная надежда разобраться хаосе, чтобы потом всё переделать с нуля.

Любимое занятие :) переделывать всё с нуля :)
У меня есть опыт правки чужого кода, так вот, то, что мне попадалось лучше
было бы
переделать с нуля.

Так почти всегда происходит, проще самому переделать, чем разобраться в
том, что сделал кто-то.

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

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

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

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

Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
12:47:18 +0200:

   В случае, если SMTP, FTP, HTTP были бинарные:
   - плагины для сниферов: которые есть для текстовых вариантов, для
   бинарных разработка по времени такая же
  
  В случае текстовых протоколов разработка плагина не требуется.
  
   - любой клиент этих протоколов итак делает преобразования протокол -
   CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
   работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
   строку, что бы прочитать последний элемент.
  
  И что же парсит и преобразует telnet при работе в качестве клиента
  SMTP?

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

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

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

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

-- 
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: Как спастись от mysql-server в KDE 4.2

В Вто, 17/03/2009 в 16:30 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Tue, 17 Mar 2009 
 12:47:18 +0200:
 
В случае, если SMTP, FTP, HTTP были бинарные:
- плагины для сниферов: которые есть для текстовых вариантов, для
бинарных разработка по времени такая же
   
   В случае текстовых протоколов разработка плагина не требуется.
   
- любой клиент этих протоколов итак делает преобразования протокол -
CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
строку, что бы прочитать последний элемент.
   
   И что же парсит и преобразует telnet при работе в качестве клиента
   SMTP?
 
  ПК Он то ничего не парсит, пользователя telnet'а приходится парсить.
 
 Ты опять все понимаешь с точностью до наоборот.  Пользователь telnet
 _имеет возможность_ провести диалог с сервером, не будучи _вынужден_ для
 этого пользоваться специальным инструментом.  Который с шансами будет
 малость, а то и немалость, устаревшим, и поддерживать не все особенности
 протокола.
 
 Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP.  У
 которого мне, помнится, не удалось найти средства прервать диалог после
 команды DATA, но до вкармливания в сервер собственно письма.
 
 Так-то он весь из себя хороший, и пользоваться им для тестирования
 конструкции со STARTTLS куда удобнее, чем руками...  Но вот пары нужных
 фич не умеет - и до свидания.  И что б я делал, будь там бинарный
 протокол?  Разбирался бы в его коде, чтобы туда эту возможность
 дописать?  А если бы он при этом еще и был написан с использованием
 сишной библиотеки реализации протокола, и этой возможности не было бы в
 _ее_ интерфейсе?

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

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


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

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

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

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

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

-- 
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: Как спастись от mysql-server в KDE 4.2

Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
16:34:34 +0200:

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

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

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

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

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

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

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

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

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

Творить - не делать! (c)Элхэ Ниеннах

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

В Вто, 17/03/2009 в 17:58 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
16:34:34 +0200:

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

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

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

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

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

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

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

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

сорьки.

-все+вне

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

Творить - не делать! (c)Элхэ Ниеннах

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

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

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

Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
17:02:39 +0200:

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

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

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

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

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

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

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

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

ПК сорьки.

ПК -все+вне

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

Программы на Haskell настолько ленивы, что по умолчанию вообще не хотят
работать.
-- http://absurdopedia.wikia.com/wiki/Haskell

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

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

2009-03-17 Пенетрантность Alexey Pechnikov

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

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

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

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

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

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

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

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

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

ПК сорьки.

ПК -все+вне

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

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

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

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

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

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

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

Hello!

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

Это шутка? То вам бинарный парсер любого протокола не страшен (sic!), и вдруг 
для построчного разбора текстового файлика в формате ключ:значение парсер 
нужен.

Best regards.

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

2009-03-17 Пенетрантность Alexey Pechnikov

В Вто, 17/03/2009 в 20:25 +0200, Тихон Тарнавский пишет:
On Tue, 17.03.2009 19:45:14 , Покотиленко Костик wrote:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Tue, 17 Mar 2009
17:02:39 +0200:

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

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

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

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

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

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

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

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

ПК сорьки.

ПК -все+вне

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

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

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

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

Hello!

On Tuesday 17 March 2009 21:39:19 Покотиленко Костик wrote:
  Что до сложности формата mbox по сравнению с бинарными, звучит,
  признаться, даже смешно. Когда мне нужно было выдернуть несколько
  полей из большого количества писем и что-то с ними сделать, я решил
  всю задачу на sh+coreutils+grep быстрее, чем в описании бинарного
  формата нашёл бы и прочитал спецификации на эти поля и функции их
  выдёргивания.

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

Распарсить и засунуть в БД. Каким местом парсер связан с индексацией? 

Best regards.

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

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

On Tuesday 17 March 2009 21:39:19 Покотиленко Костик wrote:
Что до сложности формата mbox по сравнению с бинарными, звучит,
признаться, даже смешно. Когда мне нужно было выдернуть несколько
полей из большого количества писем и что-то с ними сделать, я решил
всю задачу на sh+coreutils+grep быстрее, чем в описании бинарного
формата нашёл бы и прочитал спецификации на эти поля и функции их
выдёргивания.

Распарсить и засунуть в БД. Каким местом парсер связан с индексацией?

Где такой парсер взять, чтоб любое сообщение отпарсил подробно?

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

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

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

В Суб, 14/03/2009 в 12:18 +0300, Artem Chuprina пишет:
Aleksey Cheusov - debian-russian@lists.debian.org @ Sat, 14 Mar 2009
00:22:23 +0200:

Ну и если вам понадобился gdb, значит, вы как-то не так
программируете...
AC http://sf.net/projects/lmdbg

AC Тамошняя программа lmdbg-sym при помощи gdb преобразует адреса в
AC файлы исходного кода и номера строк полного stacktrace-а вызова
AC malloc/free etc. Это позволяет помодульно анализировать код
AC программы на предмет потребления памяти. Идея использовать для
AC этого gdb в _командном_ режиме честно заимствована из ccmalloc. Но
AC там оно прибито гвоздями на С... В общем, есть разные способы
AC применения gdb. И естественно malloc/free-ями дело не
AC ограничивается.

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

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

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

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

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

В Суб, 14/03/2009 в 10:30 +0900, Alexander Danilov пишет:
 Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 23:24 +0900, Alexander Danilov пишет:
  Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 14:39 +0300, Victor Wagner пишет:
  On 2009.03.13 at 11:38:27 +0200, Покотиленко Костик wrote:
 
  Вот-вот.
 
  Плохая практика: прога с CLI + фронтенд
  Хорошая практика: прога с CLI -- либа -- прога с GUI
  Абсолютно не факт. первый вариант выносит содержательные действия в
  отдельный процесс, существенно упрощает отладку и облегчает избавление
  от блокировок GUI, когда программа занята чем-нибудь важным.
 
  В 90% случаев, на которые мне приходилось смотреть в дистрибутиве
  (естественно, это далеко не все библиотеки, которые в нем есть) 
  авторы библиотек не имели не малейшего понятия, как следует дизайнить
  интерфейсы библиотек. А это, между прочим, гораздо более сложная задача
  чем дизайн CLI, заточенного под встраивание.
 
  Ну и покрыть функциональность автоматизированными тестами в случае CLI
  гораздо проще.
  Ни капли не согласен, особенно когда участвуют циклы. CLI-GUI не проще
  ни разу, ни в разработке, ни в использовании, ни в отладке. Кроме,
  конечно, случая, когда разработчик не умеет либы писать.
 
  Проще, надо только понимать, что проще не в Си, я в языках, в которых есть 
  нормальная обработка
  событий, например, :) Tcl. Можно рулить одновременно многими cli 
  процессами, в том числе и 
  одинаковыми, а вот на Си, это будет не так уж просто. А в питоне или ruby 
  есть событийная обработка 
  на сокетах или каналах ввода/вывода?
  
  Ты на Си в музее смотрел?
  
 
 И давно на Си можно сделать событийную обработку канала или сокета в ТРИ 
 строки?

Вот универсальная конструкция для select:

char strtmp[1024];
struct timeval tv;
int retval;

fd_set rfds;
fd_set wfds;

for(;;) {

FD_ZERO(rfds);
FD_ZERO(wfds);
FD_SET(0, rfds);
FD_SET(1, wfds);

tv.tv_sec = 5;
tv.tv_usec = 0;

retval = select(1, rfds, wfds, NULL, tv);

if(retval0) {

/* Processing connections */
if(FD_ISSET(0, rfds)) {
// read(0, buf, 1024);
}
if(FD_ISSET(1, wfds)) {
// write(1, buf, 1024);
}
} else if(retval==-1) {
if(errno!=4) {  /* Interrupted system call, we get that for SIGHUP
*/
sprintf(strtmp, Select failed: errno=%d, %s, errno,
strerror(errno));
write(2, strtmp, strlen(strtmp));
exit(5);
} else {
sprintf(strtmp, Select failed: errno=%d, %s, (Interrupted 
system
call, we get that for SIGHUP)\n, errno, strerror(errno));
write(2, strtmp, strlen(strtmp));
}
} else {
}
}


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


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

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

В Птн, 13/03/2009 в 21:44 +0200, Тихон Тарнавский пишет:
 On Fri, 13.03.2009 20:09:00 , Покотиленко Костик wrote:
  В Птн, 13/03/2009 в 13:10 +0300, Artem Chuprina пишет:
   Владимир Ступин - debian-russian@lists.debian.org  @ Fri, 13 Mar 2009 
   14:56:15 +0500:
   
  ПК Плохая практика: прога с CLI + фронтенд
  ПК Хорошая практика: прога с CLI -- либа -- прога с GUI
   
 Ну и да, по ходу дела ты, по сути, записал в плохую практику
 практически все клиент-серверные решения.  Начиная с SMTP и HTTP :-)
   
ВС Здесь наверное имелся в виду пример curl и libcurl. Впрочем,
ВС наличие библиотеки не обязывает пользоваться именно ею, можно
ВС пользоваться возможностями библиотеки и через CLI-программу. Но мне
ВС кажется, что выделить функционал программы в библиотеку - это более
ВС гибкий подход, который удовлетворит приверженцев любого лагеря:
ВС пользователей CLI, GUI и Web-интерфейсов.
   
   Моя практика показывает, что в норме приделать к CLI-программе гуй на
   скриптовом языке гораздо проще, чем сделать для этого же скриптового
   языка обвязку вокруг библиотеки.  Хотя, конечно, если ее уже кто-то за
   тебя сделал...
   
   Нет, я не утверждаю, что выделять библиотеку плохо.  Это хорошо, ибо
   повышает гибкость.  Я утверждаю, что заносить unix way в плохую практику
   не следует...
  
  Не путайте unix-way c ,  и |
  
  Первое включает второе, но не ограничивается им.
  
   Но если уж на то пошло, то для _взаимодействия_ с функциональностью
   программы я предпочитаю клиент-серверную модель, причем с _текстовым_
   протоколом.  Чтобы можно было сходить туда вручную и почитать ее ответы
   глазами.  Вот SMTP, FTP и HTTP в этом смысле хорошие примеры.
  
  Если лень писать инструменты для работы с бинарными данными, остаётся
  единственное направление движения - в сторону SMTP, FTP, HTTP, XML,
  BASE64 и другого говна(сори).
  
  Пора, наконец, понять - машина работает в бинаре, ей так удобнее, в нём
  она быстрей, так меньше нюансов, так больше энтропия и КПД.
  
  Человек так не может, поэтому преобразования целесообразнее применять
  ТОЛЬКО на входе и на выходе.
  
  Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо, но
  старомодно.
 Очень советую почитать http://www.ozon.ru/context/detail/id/2317804/
 Многое расставит на места.

В ответ посоветую:
http://www.ozon.ru/context/detail/id/1335648/
http://www.ozon.ru/context/detail/id/2527041/
http://www.ozon.ru/context/detail/id/2527036/

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


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

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

В Птн, 13/03/2009 в 22:21 +0300, Иван Лох пишет:
On Fri, Mar 13, 2009 at 08:09:00PM +0200, Покотиленко Костик wrote:

Пора, наконец, понять - машина работает в бинаре, ей так удобнее, в нём
она быстрей, так меньше нюансов, так больше энтропия и КПД.
Человек так не может, поэтому преобразования целесообразнее применять
ТОЛЬКО на входе и на выходе.

Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо, но
старомодно.

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

Про энтропию, КПД и то как работает машина Вы лучше учебник почитайте.
Насчет бинарных нюансов, один endian чего стоит. Про старомодность HTTP я
долго ржал.

P.S. Я не против библиотек. Я за. Я против разработки библиотеки для одного
приложения. Или двух.

Кто знает? GTK+ разрабатывался чисто под Gimp, а сейчас...

То, что так учат делать в ПТУ, связано с особенностями
дизайна M$ windows, где остальные пути еще кривей. Но при чем тут мы?

Не знаю, под винду меня не учили сильно.

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

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

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

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

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

ПК Не путайте unix-way c , и |

ПК Первое включает второе, но не ограничивается им.

Это только подтверждает мою мысль.

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

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

А _нам_ всяко удобнее сказать cp этот_файл туда, чем городить
неудобоваримую конструкцию из open/read/write/close, или mv этот_файл
туда, чем разбираться, надо городить open/read/write/close, или можно
ограничиться link. Эти танцы за нас может станцевать и машина, она,
блин, для того и придумана.

Как говорит мой дядя, давайте купим мерседес и будем катать его за собой
на верёвочке...

ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо,
ПК но старомодно.

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

Спорить не вижу смысла, я Ваш подход понял.

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

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

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

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

Hello!

On Monday 16 March 2009 13:49:02 Покотиленко Костик wrote:
 ...однако все владельцы смартфонов недовольны их производительностью,
 почему бы???

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

Best regards.

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

Hello!

On Monday 16 March 2009 09:01:27 Михаил Миронов wrote:
 В общем-то почти соглашусь. По моей практике заказчик почти никогда не
 знает, чего он хочет в точности. Но для есть менеджеры, дело которых
 выяснить как работает заказчик, что можно автоматизировать в его работе
 и предложить заказчику это в виде ТЗ. Сам заказчик собственно не пишет
 такие документы. Он собственно сам не фиксирует в письменном виде, он
 только оплачивает работу по написанию такого документа :) А вариант мне
 по аське сказали поправить - допускаю только если мне скинули текст
 ошибки на исправление, а не новую работу.

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

Best regards.

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

Hello!

On Monday 16 March 2009 09:12:14 Михаил Миронов wrote:
За время своей работы убедился, что бюрократия вещь весьма нужная. У нас
задание на доработки могут давать подразделения заказчика. Так вот,
бывали ситуации когда с представителем подразделения на словах
обговаривали необходимые им доработки, делали их, а они потом говорили -
да это все не то, мы не то имели в виду. В общем начинать работу без
подписанной бумаги - себе дороже. Пусть даже это не оформленное по ГОСТу
ТЗ, а простой листок с четким изложение задачи просто _подписанный_
заказчиком. Составленный возможно и не им самим. Но составлен он должен
быть _обязательно_ до начала работ. В случае удаленных заказчиков - есть
масса возможностей - например, S/MIME. Ну или факс с подписью.

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

Best regards.

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

Hello!

On Monday 16 March 2009 14:52:31 Михаил Миронов wrote:
Не ТЗ с описанием способа решения задачи, а ТЗ с описанием самой задачи!
В случае научной работы это может быть ТЗ на исследование. Результат
исследования может быть как положительный так и отрицательный. Но
постановка задачи и подписанное задание на исследование точно есть.

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

Best regards.

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

Hello!

On Monday 16 March 2009 15:25:47 Иван Лох wrote:
  А вот описание задачи можно и по аське поставить. Личное общение
  требуется только когда кодеру пытаются втолковать решение задачи
  профильные специалисты. Кстати, гранты часто получают заочно - отправил
  заявку с описанием задачи,

 По аське. А потом по скайпу позвонил и рассказал о результатах ;-}}
 Russian Academy of the Science

В ННГУ на радиофизическом факультете за сколько-ко то там  лет несколько 
десятков человек работали по грантам LG, но, насколько мне известно, ни один 
из нас не был в Корее. Может быть, вы каждый день разъезжаете по миру, а вот 
нам почему-то даже не предлагали, а только раз в год принимали заявки на 
гранты и дважды в год отчеты.

Best regards.

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

В Пнд, 16/03/2009 в 21:43 +0900, Alexander Danilov пишет:
 Покотиленко Костик пишет:
  В Суб, 14/03/2009 в 10:30 +0900, Alexander Danilov пишет:
  Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 23:24 +0900, Alexander Danilov пишет:
  Покотиленко Костик пишет:
  В Птн, 13/03/2009 в 14:39 +0300, Victor Wagner пишет:
  On 2009.03.13 at 11:38:27 +0200, Покотиленко Костик wrote:
 
  Вот-вот.
 
  Плохая практика: прога с CLI + фронтенд
  Хорошая практика: прога с CLI -- либа -- прога с GUI
  Абсолютно не факт. первый вариант выносит содержательные действия в
  отдельный процесс, существенно упрощает отладку и облегчает избавление
  от блокировок GUI, когда программа занята чем-нибудь важным.
 
  В 90% случаев, на которые мне приходилось смотреть в дистрибутиве
  (естественно, это далеко не все библиотеки, которые в нем есть) 
  авторы библиотек не имели не малейшего понятия, как следует дизайнить
  интерфейсы библиотек. А это, между прочим, гораздо более сложная задача
  чем дизайн CLI, заточенного под встраивание.
 
  Ну и покрыть функциональность автоматизированными тестами в случае CLI
  гораздо проще.
  Ни капли не согласен, особенно когда участвуют циклы. CLI-GUI не проще
  ни разу, ни в разработке, ни в использовании, ни в отладке. Кроме,
  конечно, случая, когда разработчик не умеет либы писать.
 
  Проще, надо только понимать, что проще не в Си, я в языках, в которых 
  есть нормальная обработка
  событий, например, :) Tcl. Можно рулить одновременно многими cli 
  процессами, в том числе и 
  одинаковыми, а вот на Си, это будет не так уж просто. А в питоне или 
  ruby есть событийная обработка 
  на сокетах или каналах ввода/вывода?
  Ты на Си в музее смотрел?
 
  И давно на Си можно сделать событийную обработку канала или сокета в ТРИ 
  строки?
  
  Вот универсальная конструкция для select:
  
  char strtmp[1024];
  struct timeval tv;
  int retval;
  
  fd_set rfds;
  fd_set wfds;
  
  for(;;) {
  
  FD_ZERO(rfds);
  FD_ZERO(wfds);
  FD_SET(0, rfds);
  FD_SET(1, wfds);
  
  tv.tv_sec = 5;
  tv.tv_usec = 0;
  
  retval = select(1, rfds, wfds, NULL, tv);
  
  if(retval0) {
  
  /* Processing connections */
  if(FD_ISSET(0, rfds)) {
  // read(0, buf, 1024);
  }
  if(FD_ISSET(1, wfds)) {
  // write(1, buf, 1024);
  }
  } else if(retval==-1) {
  if(errno!=4) {  /* Interrupted system call, we get that for SIGHUP
  */
  sprintf(strtmp, Select failed: errno=%d, %s, errno,
  strerror(errno));
  write(2, strtmp, strlen(strtmp));
  exit(5);
  } else {
  sprintf(strtmp, Select failed: errno=%d, %s, (Interrupted 
  system
  call, we get that for SIGHUP)\n, errno, strerror(errno));
  write(2, strtmp, strlen(strtmp));
  }
  } else {
  }
  }
  
  
 Сударь, я спрашивал про 3 (ТРИ) строки, а в вашем примере только 
 инициализация занимает пол экрана, 
 так я ещё и не вижу где тут собыйтийная обработка данных, нет её тут.

Естественно не видите, мелко сильно.

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


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

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

Hello!

On Monday 16 March 2009 15:49:43 Иван Лох wrote:
 Ну я и говорю -- вот она настоящая жизнь. Прожект -- по аське, деньги по
 вебмани, отчет по скайпу, со ссылками на arXiv.org. Тут-то мне карта и
 пошла...

То-то я смотрю, челночников вроде не стало, и откуда импорт берется? 
Оказывается, спасибо академии наук и западным грантам :-)

Best regards.

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

Покотиленко Костик - debian-russian@lists.debian.org  @ Mon, 16 Mar 2009 
12:45:30 +0200:

  P.S. Я не против библиотек. Я за. Я против разработки библиотеки для одного
  приложения. Или двух.

 ПК Кто знает? GTK+ разрабатывался чисто под Gimp, а сейчас...

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

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

Historically, languages designed for other people to use have been
bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those
that were designed for their own creators: C, Perl, Smalltalk, Lisp.
 -- Paul Graham


-- 
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  @ Mon, 16 Mar 2009 
12:49:02 +0200:

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

 ПК Спорить не вижу смысла, я Ваш подход понял.

 ПК ...однако все владельцы смартфонов недовольны их
 ПК производительностью, почему бы???

Ты серьезно полагаешь, что по причине текстовости протоколов!?

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

Машины пока еще от копирования защищены хитрой немецкой технологией сборка
трезвымAlex Korchmar в bjndsl$1p2...@ddt.demos.su


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

Alexey Pechnikov - debian-russian@lists.debian.org  @ Mon, 16 Mar 2009 
14:33:50 +0300:

 AP эксперименты и т.п. Посему неверно утверждение, что всегда
 AP необходимо ТЗ с описанием способа решения (как пишет Артем).

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

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

НИИ требуются:
1. Кто бы мог подумать.
Кнышев.


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

В Пнд, 16/03/2009 в 15:56 +0200, Тихон Тарнавский пишет:
On Mon, 16.03.2009 12:42:58 , Покотиленко Костик wrote:
В Птн, 13/03/2009 в 21:44 +0200, Тихон Тарнавский пишет:
On Fri, 13.03.2009 20:09:00 , Покотиленко Костик wrote:
В Птн, 13/03/2009 в 13:10 +0300, Artem Chuprina пишет:
Владимир Ступин - debian-russian@lists.debian.org @ Fri, 13 Mar
2009 14:56:15 +0500:

ПК Плохая практика: прога с CLI + фронтенд
ПК Хорошая практика: прога с CLI -- либа -- прога с GUI

Ну и да, по ходу дела ты, по сути, записал в плохую практику
практически все клиент-серверные решения. Начиная с SMTP и HTTP
:-)

ВС Здесь наверное имелся в виду пример curl и libcurl. Впрочем,
ВС наличие библиотеки не обязывает пользоваться именно ею, можно
ВС пользоваться возможностями библиотеки и через CLI-программу. Но
мне
ВС кажется, что выделить функционал программы в библиотеку - это
более
ВС гибкий подход, который удовлетворит приверженцев любого лагеря:
ВС пользователей CLI, GUI и Web-интерфейсов.

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

Не путайте unix-way c , и |

Первое включает второе, но не ограничивается им.

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

Если лень писать инструменты для работы с бинарными данными, остаётся
единственное направление движения - в сторону SMTP, FTP, HTTP, XML,
BASE64 и другого говна(сори).

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

Человек так не может, поэтому преобразования целесообразнее применять
ТОЛЬКО на входе и на выходе.

Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо, но
старомодно.
Очень советую почитать http://www.ozon.ru/context/detail/id/2317804/
Многое расставит на места.

В ответ посоветую:
http://www.ozon.ru/context/detail/id/1335648/
http://www.ozon.ru/context/detail/id/2527041/
http://www.ozon.ru/context/detail/id/2527036/

Это к чему? Вы хоть предисловие к указанной книге прочитайте, там
написано, куда восходит её название.

Прочитал все три. Кучу примеров и домашних заданий порешал и
проанализировал. И?

И уж конечно ESR ни в чём Кнуту
не противоречит.

Ещё бы

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

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

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

В Пнд, 16/03/2009 в 16:28 +0300, Artem Chuprina пишет:
 Покотиленко Костик - debian-russian@lists.debian.org  @ Mon, 16 Mar 2009 
 12:49:02 +0200:
 
ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP - хорошо,
ПК но старомодно.
   
   С точностью до наоборот.  Ниши работы с машинным представлением - это
   криптография и сжатие данных.  Всё.  (Предвосхищая очевидное возражение
   - нет, кодирование изображения и звука уже не требует машинного
   представления: цвет точки, равно как и частота и амплитуда звука -
   понятия уже более абстрактные, и программы обработки уже с этими
   абстракциями работают, а бинарное их представление в конкретном формате
   уже можно отнести к сжатию данных, поскольку форматы без сжатия сейчас
   уже почти не применяются.)
 
  ПК Спорить не вижу смысла, я Ваш подход понял.
 
  ПК ...однако все владельцы смартфонов недовольны их
  ПК производительностью, почему бы???
 
 Ты серьезно полагаешь, что по причине текстовости протоколов!?

Нет, но корни те же.

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


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

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

2009-03-16 Пенетрантность Konstantin Matyukhin

В Пнд, 16/03/2009 в 16:27 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
12:45:30 +0200:

P.S. Я не против библиотек. Я за. Я против разработки библиотеки для
одного
приложения. Или двух.

ПК Кто знает? GTK+ разрабатывался чисто под Gimp, а сейчас...

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

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

--
Покотиленко Костик 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/3/16 Тихон Тарнавский tik...@lexpr.ru:
 On Sun, 15.03.2009 19:02:27 , Alexey Pechnikov wrote:
 Лично я еще не видел ни одного заказчика, который бы сам сумел
 сформулировать задачу.
 Нет, Вас действительно пора начинать в цитатник заносить. Как Вы
 умудряетесь вообще с такими заказчиками работать, которые поставить
 задачу не в состоянии?
А что ему остается делать, если всех адекватных заказчиков Артем увел?

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

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

Hello!

On Monday 16 March 2009 17:29:53 Konstantin Matyukhin wrote:
  Лично я еще не видел ни одного заказчика, который бы сам сумел
  сформулировать задачу.
 
  Нет, Вас действительно пора начинать в цитатник заносить. Как Вы
  умудряетесь вообще с такими заказчиками работать, которые поставить
  задачу не в состоянии?

 А что ему остается делать, если всех адекватных заказчиков Артем увел?

Ну теперь-то я это знаю :-)

Best regards.

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

Hello!

On Monday 16 March 2009 17:25:52 Тихон Тарнавский wrote:
Лично я еще не видел ни одного заказчика, который бы сам сумел
сформулировать задачу.

Нет, Вас действительно пора начинать в цитатник заносить. Как Вы
умудряетесь вообще с такими заказчиками работать, которые поставить
задачу не в состоянии?

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

Обычно техзадание составляется на после ввода системы в
эксплуатацию.

Это не хуже. Я видел несколько десятков проектов, где ТЗ оставлялось
на после ввода в эксплуатацию. Большая часть из них в эксплуатацию не
была введена вообще. А в сроки, превышавшие плановые меньше чем на
год, не был введён ни один.

Если это проекты по распилу, то дело отнюдь не в ТЗ.

Best regards.

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

2009-03-16 Пенетрантность Evgeny M. Zubok

Михаил Миронов m...@darkmike.ru writes:

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

Вот совершенно верно. Согласно ГОСТ ТЗ и ОПЗ пишется не заказчиком,
а *исполнителем*. Если конкретно по автоматизированным системам, то ГОСТ
34.602:

ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с
участием заказчика на основании технических требований (заявки,
тактико-технического задания и т. п.).

--
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 Monday 16 March 2009 18:35:16 Evgeny M. Zubok wrote:
В общем-то почти соглашусь. По моей практике заказчик почти никогда не
знает, чего он хочет в точности. Но для есть менеджеры, дело которых
выяснить как работает заказчик, что можно автоматизировать в его
работе и предложить заказчику это в виде ТЗ. Сам заказчик собственно
не пишет такие документы. Он собственно сам не фиксирует в письменном
виде, он только оплачивает работу по написанию такого документа :)

ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

ТЗ составляет _инженер_ (почти забытое слово, а жаль), а не менеджер. Кто это
вообще такой - менеджер? Это понятие не подразумевает ни специального
образования, ни опыта. Имхо, российский менеджер отличается от посыльного
разве что тем, что должен знать содержание передаваемых бумаг (понимать тоже
должен, но это уже редко достижимый идеал). Однако для их написания
_технического_ задания требуется _технический специалист_.

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

Best regards.

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

Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
16:10:42 +0200:

ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP -
ПК хорошо, но старомодно.

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

ПК Спорить не вижу смысла, я Ваш подход понял.

ПК ...однако все владельцы смартфонов недовольны их
ПК производительностью, почему бы???

Ты серьезно полагаешь, что по причине текстовости протоколов!?

ПК Нет, но корни те же.

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

Вспоминается реальная жизненная история. Знакомый рассказывал.
Наладонник Sony CLIE SJ-20, по цифрам - аналог 386 (33MHz, 16Mb _всей_
памяти (она у него не просто RAM)), _интерпретатор_ Scheme vs. что-то
современное (тому года два), Delphi, код компилируется.

Зашла дискуссия на аналогичную тему. Считают факториалы.

Для начала Борька, понятно, успевает посчитать все входные данные
(десяток чисел) _до_ того, как конкурент успевает написать и
скомпилировать программу. Предварительно эту программу, понятно,
написав. На наладоннике. Стилом. Хорошо еще, что у конкурента его
среда вообще запустилась до того, как Борька закончил, а то было бы
совсем смешно. Тот, конечно, заявляет, что на больших числах его жутко
скомпилированный результат будет работать быстрее. О'кей, -
соглашается Борька, - 1000!. Борькин пальм выдает результат через 40
секунд. Конкурент только начинает искать библиотеку работы с большими
числами, поскольку, понятно, его программа правильного результата дать
не смогла вообще. Потому что в _машинное_ целое он не лезет, хоть
тресни.

Вы еще работаете с бинарными форматами? Тогда мы идем к вашим клиентам...

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

Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
Including Common Lisp.
-- Robert Morris

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

В Пнд, 16/03/2009 в 19:29 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
16:10:42 +0200:

ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP -
ПК хорошо, но старомодно.

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

ПК Спорить не вижу смысла, я Ваш подход понял.

ПК ...однако все владельцы смартфонов недовольны их
ПК производительностью, почему бы???

Ты серьезно полагаешь, что по причине текстовости протоколов!?

ПК Нет, но корни те же.

Зашла дискуссия на аналогичную тему. Считают факториалы.

Вы еще работаете с бинарными форматами? Тогда мы идем к вашим клиентам...

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

В случае, если SMTP, FTP, HTTP были бинарные:
- плагины для сниферов: которые есть для текстовых вариантов, для
бинарных разработка по времени такая же
- любой клиент этих протоколов итак делает преобразования протокол -
CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
строку, что бы прочитать последний элемент.

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

В Пнд, 16/03/2009 в 19:09 +0200, Тихон Тарнавский пишет:
On Mon, 16.03.2009 18:56:32 , Покотиленко Костик wrote:
В Пнд, 16/03/2009 в 19:29 +0300, Artem Chuprina пишет:
Покотиленко Костик - debian-russian@lists.debian.org @ Mon, 16 Mar 2009
16:10:42 +0200:

ПК Это я про то к чему стремиться надо, а SMTP, FTP и HTTP -
ПК хорошо, но старомодно.

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

ПК Спорить не вижу смысла, я Ваш подход понял.

ПК ...однако все владельцы смартфонов недовольны их
ПК производительностью, почему бы???

Ты серьезно полагаешь, что по причине текстовости протоколов!?

ПК Нет, но корни те же.

Зашла дискуссия на аналогичную тему. Считают факториалы.

Вы еще работаете с бинарными форматами? Тогда мы идем к вашим
клиентам...

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

Гляну на досуге.

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

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

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

В Пнд, 16/03/2009 в 20:10 +0300, Иван Лох пишет:
 On Mon, Mar 16, 2009 at 06:56:32PM +0200, Покотиленко Костик wrote:
  Я не вижу большой разницы во времени затраченном на разработку. Основная
  работа - это написание самого протокола, т.е. список команд. Потом эти
  команды надо упаковать либо в текст либо в бинарь что по затратам
  времени одинаково.
  
  В случае, если SMTP, FTP, HTTP были бинарные:
  - плагины для сниферов: которые есть для текстовых вариантов, для
  бинарных разработка по времени такая же
  - любой клиент этих протоколов итак делает преобразования протокол -
  CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
 Особенно telnet 22
  работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
  строку, что бы прочитать последний элемент.
 
 Еще один важный момент _расширяемость_ Одно дело изменить API, другое --
 добавить пару строчек в правильно написанный парсер. Да и потом, создается
 впечатление, что Вы строго в рамках i386 работаете. За ее пределами в 
 бинарных форматах геморроя куча.

Например?

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


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

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

2009-03-16 Пенетрантность Степан Голосунов

В Пнд, 16/03/2009 в 21:10 +0300, Иван Лох пишет:
 On Mon, Mar 16, 2009 at 07:28:22PM +0200, Покотиленко Костик wrote:
   
   Еще один важный момент _расширяемость_ Одно дело изменить API, другое --
   добавить пару строчек в правильно написанный парсер. Да и потом, создается
   впечатление, что Вы строго в рамках i386 работаете. За ее пределами в 
   бинарных форматах геморроя куча.
  
  Например?
 
 endian 

Есть такая штука, называется network byte order. Ещё примеры, а то
куча маленькая?

Сколько лишних MIPS'ов займёт преобразование host byte order - network
byte order?

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

Покотиленко Костик cas...@meteor.dp.ua writes:
 В случае, если SMTP, FTP, HTTP были бинарные:
 - плагины для сниферов: которые есть для текстовых вариантов, для
 бинарных разработка по времени такая же

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

 - любой клиент этих протоколов итак делает преобразования протокол -
 CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
 работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
 строку, что бы прочитать последний элемент.

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


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

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

2009-03-16 Пенетрантность Aleksey Cheusov

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

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

В сложных проектах нужно писать тесты. И в простых тоже.
Тогда дебаггер не понадобится.

-- 
Best regards, Aleksey Cheusov.


-- 
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-15 Пенетрантность Владимир Ступин

15 марта 2009 г. 1:25 пользователь Artem Chuprina r...@ran.pp.ru написал:

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

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

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

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

2009-03-15 Пенетрантность Aleksey Cheusov

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

AC А вот если выкидывать КАЖДОЕ приложение, которое хотя бы раз
AC сделало segfault или buffer overflow, ты очень быстро окажешься с
AC абаком в руках. Пижонство это банальное.

С другой стороны, в рассматриваемой ситуации неправ, вероятно, лично
Печников. Решивший лично собрать AOLServer с версией tcl, которую тот
не поддерживает (что еще полбеды) и полезший решать эту проблему в gdb,
а не в документацию.
Возможно, если в документации на AOLServer четко прописано, какая версия
tcl поддерживается.

--
Best regards, Aleksey Cheusov.

--
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 Sunday 15 March 2009 01:02:15 Artem Chuprina wrote:
С другой стороны, в рассматриваемой ситуации неправ, вероятно, лично
Печников. Решивший лично собрать AOLServer с версией tcl, которую тот
не поддерживает (что еще полбеды) и полезший решать эту проблему в gdb,
а не в документацию. А разработчики тикля и AOLServer, вероятно, не
виноваты...

Так вот как раз четко написано, что AOL 4.5.1 поддерживает версию tcl 8.5. А
когда сообщил о возникшей проблеме, разработчики AOLServer понятия не имели,
как проблему решить. И поскольку у меня было четко запланировано время,
которое я могу потратить на переход на новый AOL 4.5.1 + tcl 8.5 (и это были
предыдущие выходные - три дня как-никак), то пришлось заниматься отладкой.
Когда стало ясно, что падает в ходе инициализации интерпретатора, автор
проблемного кода предложил патч, который и решил проблему. После проверки на
нескольких своих серверах я сообщил о результатах команде разработчиков и
мантейнеру деб-пакета, так что патч уже в апстриме и будет в текущем тестинге.

Искать виноватых и вовсе ни к чему. Спасибо разработчикам AOLServer за
замечательный продукт - один из самых мощных серверов приложений с открытым
кодом. А мы чем можем, тем поможем.

Best regards.

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

Hello!

On Saturday 14 March 2009 23:25:40 Artem Chuprina wrote:
От таких заказов я сразу отказываюсь. Вернее, я отказываюсь работать по
задаче, которую тому, кто ее ставит, лень _зафиксировать в письменном
виде_. Если заказчику лень, но решение принимаю не я и руководство
считает, что этот заказ надо делать - это проблема не моя, а
руководства. Я требую письменной фиксации с того, с кем общаюсь я.
Если же это мой заказчик, а не конторы - я от такого заказа просто
отказываюсь. Потому что себе дороже. Потому что если ему настолько
лень, то ему это не настолько надо, а значит, он хреново представляет
себе, что же ему надо, а значит, будет геморройная работа с неочевидным
результатом. Оно мне надо?

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

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

Best regards.

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

Hello!

On Sunday 15 March 2009 13:39:44 Иван Лох wrote:
 TeX был написан Кнутом для издания собственной книги, после того как он
 поспорил с издателем, который эту книжку плохо издал. На спор и в отпуске.
 Just for fun.

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

Речь идет о _процессе_ решения задачи. А уж ставит ее заказчик или вы сами 
себе значения не имеет. И форма постановки значения не имеет. Да, как я понял,  
Artem Chuprina считает глупым решение задачи, которая не формализована. Но вот 
в ВУЗах про Кнута и Ньютона рассказывают, а про Artem Chuprina - нет, и с чего 
бы это?.. Уж простите за иронию, не хочу никого обидеть.

Best regards.

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

2009-03-15 Пенетрантность chaos

On 14 March 2009 22:25:40 Artem Chuprina wrote:
 chaos - debian-russian@lists.debian.org  @ Sat, 14 Mar 2009 19:53:16 +0200:
 За советы с примерами таки и благодарен даже буду, а то все только
 кричат DE фикня, а к ним на десктоп глянешь так ужас тихий, каждое
 приложение в своём русле, с хоткеями вообще бардак, зато fvwm блин,
 а хоткеи только на него нормально и повешаны.
   
Не знаю, у кого там как, а у меня все приложения выглядят одинаково.
Все два :-D
   
http://mova.org/~cheusov/pub/screenshort/ctwm.png
  
   А skype и аська где? Или вы с заказчиками и юзерами святым духом
   общаетесь?
  
   :-)

  c +1 я, я вот тоже как-то смущён отсутствием таких простых
  c приложений. Есть конечно e-mail, но как-то не всегда те-же заказчики
  c любят по клавишам стучать излагая мысль, им проще в микрофон..

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

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

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

2009-03-15 Пенетрантность chaos

On 14 March 2009 22:18:56 Artem Chuprina wrote:
chaos - debian-russian@lists.debian.org @ Sat, 14 Mar 2009 20:19:59 +0200:
А я не говорил что они ровные, просто если с 4-ой версией кеды
настолько окривеют что будут тянуть мускуль с собой, то тут явно
от него надо будет отказываться окончательно. а вот на выбор
останется по большому счёту консоль..

Вот интересно, как это я ухитряюсь не пользоваться ни гномом, ни
кедами, и при этом не жить в консоли? ЧЯДНТ?

Нет, меня не слишком парит то, что часть используемых мной
приложений тянет gtk. Qt, кажется, никто. Кто-то даже гномьи
библиотеки тянет. Парочку. Ну и хрен с ними. Пока не пользуешься
приложениями, из самих этих DE, проблем как-то не возникает...

И как это всё замечательно у тебя выглядит и между собой работает?
мот скриншотами поделишься? хоткеи по человечески для приложений как
прикручивал? и желательно чтобы более менее однообразные были, а не
так что в одних ctrl+b одно а в других другое

Я не заморачиваюсь задачей сделать одинаковые хоткеи в приложениях,
которые занимаются принципиально разными вещами. Смысла не вижу. А
редактирование строки в zsh и в emacs одинаковое искаропки.

Скриншоты делать (точнее, выкладывать) лень, да и я тут еще WM меняю на
тайловый, предпочтения еще не оформились до конца. Хотя ладно,
сделаю...

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

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

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

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

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

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

P.S. Если кто не удосужился прочесть aptitude show stumpwm - оно на
Common Lisp... Впрочем, тех, кого emacs не пугает, это не остановит :-)

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

2009-03-15 Пенетрантность chaos

On 15 March 2009 09:24:11 Владимир Ступин wrote:
15 марта 2009 г. 1:25 пользователь Artem Chuprina r...@ran.pp.ru написал:
От таких заказов я сразу отказываюсь. Вернее, я отказываюсь работать по
задаче, которую тому, кто ее ставит, лень _зафиксировать в письменном
виде_. Если заказчику лень, но решение принимаю не я и руководство
считает, что этот заказ надо делать - это проблема не моя, а
руководства. Я требую письменной фиксации с того, с кем общаюсь я.
Если же это мой заказчик, а не конторы - я от такого заказа просто
отказываюсь. Потому что себе дороже. Потому что если ему настолько
лень, то ему это не настолько надо, а значит, он хреново представляет
себе, что же ему надо, а значит, будет геморройная работа с неочевидным
результатом. Оно мне надо?

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

+1, хоть дома без этого отдыхаю.

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

2009-03-15 Пенетрантность Artem Chuprina

Alexey Pechnikov - debian-russian@lists.debian.org  @ Sun, 15 Mar 2009 
14:03:58 +0300:

 AP Да, как я понял, Artem Chuprina считает глупым решение задачи,
 AP которая не формализована.

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

-- 
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: Как спастись от mysql-server в KDE 4.2