[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Mon, 16.03.2009 19:27:31 , Покотиленко Костик wrote:
> В Пнд, 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 -
> > > >  >>  >>  ПК> хорошо, но старомодно.
> > > >  >>  >> 
> > > >  >>  >> С точностью до наоборот.  Ниши работы с машинным представлением
> > > >  >>  >> - это криптография и сжатие данных.  Всё.  (Предвосхищая
> > > >  >>  >> очевидное возражение - нет, кодирование изображения и звука уже
> > > >  >>  >> не требует машинного представления: цвет точки, равно как и
> > > >  >>  >> частота и амплитуда звука - понятия уже более абстрактные, и
> > > >  >>  >> программы обработки уже с этими абстракциями работают, а
> > > >  >>  >> бинарное их представление в конкретном формате уже можно отнести
> > > >  >>  >> к сжатию данных, поскольку форматы без сжатия сейчас уже почти
> > > >  >>  >> не применяются.)
> > > >  >> 
> > > >  >>  ПК> Спорить не вижу смысла, я Ваш подход понял.
> > > >  >> 
> > > >  >>  ПК> ...однако все владельцы смартфонов недовольны их
> > > >  >>  ПК> производительностью, почему бы???
> > > >  >> 
> > > >  >> Ты серьезно полагаешь, что по причине текстовости протоколов!?
> > > > 
> > > >  ПК> Нет, но корни те же.
> > > > 
> > > > А в моем представлении - совершенно другие.  В увлечении пищалками и
> > > > перделками.  Текстовость протоколов просаживает производительность
> > > > максимум на треть.  "Те же корни" в совокупности дадут максимум два
> > > > раза.  Заплатив эту немеряную цену за то, что результат будет на пару
> > > > лет раньше.  За каковую пару лет, если я правильно помню закономерности,
> > > > компьютеры станут быстрее втрое.  Смартфоны нынче намного мощнее, чем
> > > > десктопные компьютеры тех времен, когда их производительность уже давно
> > > > никого не смущала, кроме геймеров.  Игры _специально_ разрабатываются
> > > > так, чтобы современного компьютера им не хватало, так что они не в счет.
> > > > 
> > > > Вспоминается реальная жизненная история.  Знакомый рассказывал.
> > > > Наладонник Sony CLIE SJ-20, по цифрам - аналог 386 (33MHz, 16Mb _всей_
> > > > памяти (она у него не просто RAM)), _интерпретатор_ Scheme vs. что-то
> > > > современное (тому года два), Delphi, код компилируется.
> > > > 
> > > > Зашла дискуссия на аналогичную тему.  Считают факториалы.
> > > > 
> > > > Для начала Борька, понятно, успевает посчитать все входные данные
> > > > (десяток чисел) _до_ того, как конкурент успевает написать и
> > > > скомпилировать программу.  Предварительно эту программу, понятно,
> > > > написав.  На наладоннике.  Стилом.  Хорошо еще, что у конкурента его
> > > > среда вообще запустилась до того, как Борька закончил, а то было бы
> > > > совсем смешно.  Тот, конечно, заявляет, что на больших числах его жутко
> > > > скомпилированный результат будет работать быстрее.  "О'кей," -
> > > > соглашается Борька, - "1000!".  Борькин пальм выдает результат через 40
> > > > секунд.  Конкурент только начинает искать библиотеку работы с большими
> > > > числами, поскольку, понятно, его программа правильного результата дать
> > > > не смогла вообще.  Потому что в _машинное_ целое он не лезет, хоть
> > > > тресни.
> > > > 
> > > > "Вы еще работаете с бинарными форматами?  Тогда мы идем к вашим клиентам..."
> > > 
> > > Я не вижу большой разницы во времени затраченном на разработку. Основная
> > > работа - это написание самого протокола, т.е. список команд. Потом эти
> > > команды надо "упаковать" либо в текст либо в бинарь что по затратам
> > > времени одинаково.
> > > 
> > > В случае, если SMTP, FTP, HTTP были бинарные:
> > > - плагины для сниферов: которые есть для текстовых вариантов, для
> > > бинарных разработка по времени такая же
> > > - любой клиент этих протоколов итак делает преобразования протокол <->
> > > CLI|GUI, так что не вижу разницы, мне, например, с бинарем проще
> > > работать, чем парсить текст, с ним всё однозначно, не надо парсить всю
> > > строку, что бы прочитать последний элемент.
> > > 
> > Прошу прощения за назойливость, но по поводу текстовых протоколов
> > снова отошлю к ESR-у. Потому что лучше него я всё равно не объясню, а
> > пересказывать полторы главы своими словами мне неинтересно.
> 
> Гляну на досуге.
> 
Да, забыл. Если не хотите покупать, оригинал есть в сети:
http://catb.org/~esr/writings/taoup/html/
Я читал только в переводе, а он только бумажный.

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


Reply to: