Re: о кривости esd (was Re:ALSA)
On Mon, 24 Jul 2000, Victor Wagner wrote:
> On Mon, 24 Jul 2000, Vlad Harchev wrote:
>
> > > А пытался ли ты писать на Oberon, Haskel, Common Lisp? Это все тоже
> > > компилируемые языки.
> >
> > Нет, не пытался. Может, они могут быть лучше для написания приложений общего
> > назначения, но C++ по-моему лучше для таких вещей, как библиотеки (типа gtk,
> > curses, libc, просто математика) (короче, там, где используют C).
>
> Приложений "общего назначения" не бывают. Бывают бизнес-приложения (90%
> всез приложенний) и писать их надо на всяких Visual Basic, Oracle Forms
> и прочих Tcl-ях с python-ами.
>
> Бывают приложения вычислительно-емкие, типа обработки графики или звука.
> Вот их действительно выгодно писать на C++.
По-моему, фронт-энды для них лучше писать тоже на скриптовых языках,а
ядро - на C++.
> Бывают приложения для работы с текстами, включая CGI - это ниша для perl,
> Tcl и python.
Такие вообще-то приложениями не называются, IMO - это утилиты/скрипты.
> И наконец, бывают приложения решающие нетривиальные интеллектуальные
> задачи типа knowledge base. Вот там надо смотреть на Haskel, Lisp и OcaML.
Согласен с этим.
> А вот библиотеки общего назначения ни в коем случае нельзя писать на C++.
> Из за отсутствия стандартов на name mangling и трудностей линковки этих
> библиотек к языкам отличным от C++.
Мне кажется, что это не проблемма - просто надо внешний интерфейс
предоставлять и в C-шном виде (extern "C" { void foo(); }) (кроме C++-ного) -
тогда проблем с манглингом не будет.
> > В случае с С++ - его авторы и комиссия по стандартизации не претендует на
> > универсальность - претендуют на его универсальность люди, его использующие -
> > а это, можно сказать, их проблемы.
>
> Так и со всеми остальными перечисленными sucks-ами (ну кроме
> паталогического случая Mocrosoft) ситуация ровно та же самая.
Во всех остальных случаях автор/промоутер материально заинтересован в
продвижении - поэтому они продвигаются не только благодаря энтузиастам.
> >
> > Я тоже не против качества. А под билинейной интерполяцией я имел в виду
> > интерполяцию сплайнами. Ну а sox использует линейную интерполяцию тоже!
>
> Пожалуйста, пользуйся математическими терминами корректно. Билинейная
> интерполяция это линейная интерполяция по двум координатам. А сплайновая
> интерполяция - частный случай полиномиальной.
В курсе. Извини.
> > Просто в доке на него
> >рекомендуют вручную подобрать частоту среза фильтра
> > нижних частот (который удалит высокочастотный шум), и наложить данный фильтр
> > на результат ресемплирования.
>
> Что легко сделать вручную, но неприемлемо в случаи audioserver-а, который
> должен эту задачу выполнять прозрачно для программы.
То есть ты за то, чтобы не поддерживать ресемплирование?
>
> > > Ну-ну. Попробуй запусти Netscape или Acrobat Rеader на 24-битном экране,
> > > а потом acm (flight simulator такой) на 16-битном.
> >
> > Если бы они использовали нормальный виджет сет (типа gtk) то проблем бы не
>
> Какой такой видгет-сет в flignt simulator-е?
Уж для флайт-симулятора можно пустить отдельно X-server на :1 с нужной bpp.
> Проблема с отсутствием нужного визуала возникает обычно при необходимости
> работы с быстрой графикой.
>
> > было. Хотя я только что пускал на XFree3.3.3.1 Netscape и Acroread4 на
> > 24-битном экране - проблем вообще никаких. (И xdpyinfo показывает что доступен
>
> Точно 24 а не 32?
Точно - пускал dpyinfo, а X пускал через startx --bpp 24.
> > только один visual - TrueColor - тоже самое что и в 16-битном режиме). Так
> > что я чего-то не понимаю.
>
> Я тоже чего-то не понимаю, но почему-то мне недавно пришлось вместо
> 1280х1024х24 поставить 1152х846х32 именно из-за того, что задрали глюки
> при просмотре pdf-ов (X- 3.3.6, карточка Matrox)
Хмм, я думал что они просто не должны были запускаться - насчет глюков я не
в курсе - я их не юзаю.
> > > Существенно лучше, чем у esd. Поддерживается ряд терминалов фирмы NCD
> > > (к сожалению, не ECX), PCXware (X-сервер для Windows), Citrix Unix
> > > integration services (способ доступаться к Windows NT по X - протоколу)
> > > Это не говоря о unix-машинах.
> >
> > Он кажется все более привлекательным.
>
> Похоже, что автор esd просто не озаботился изучением существовавших
Да, или просто разбирался с программированием аулио под unix :)
> решений прежде чем писать свое. А NAS тут было чуть не интегрировали в X
> как часть стандарта на протокол. И если коммерческий софт поддерживает
> хоть какой-то remote audio protocol, то это NAS.
>
> Кстати, берется она сейчас именно с ftp.x.org, так как NCD ее прекратил со
> своего сайта раздавать.
Тогда обнови ссылки на свой homepage :)
> > Не согласен по-поводу gtk - это (даже с версией 1.2) очень продвинутый
> > widget set. А вот когда 1.4 выдет (1.3.1 - его пререлиз уже доступен) он будет
> > наверно самым мощным виджетсетом: высокая портабельность, базирование на
> > utf8, поддержка различных языков типа китайского (с иероглифами) и с другим
> > направлением чтения, и все вроде будет double-buffered (не будет никакого
>
> Ты знаешь, Tk его по всем этим пунктам опережает года на три.
И что, тексты с другим направлением (как иврит) поддерживает? И позволяет с
умом подчеркивать всякие иероглифы? По внешнему виду Tk не сравнить с gtk.
И каким же образом Tk опережает года на 3 gtk?
В новом gtk text widget будет именно из Tk (или я путаю с другим виджетом,
который не будет в поставке gtk, а будет отдельно) - но GtkText в новом gtk
тоже будет очень навернутый.
> И единственным недостатком Tk с точки зрения всех этих новомодных
> писателей Desktop-ов является его заточенность под скриптовые языки а не
> C-C++ Я тут как-то попробовал писать на Python-GTK, мне очень не
> понравилось. То, для чего в Python-Tkinter (для чистоты
> сравнения) требуется 2 строчки в Python-Gtk занимает десять.
Во-первых, gui надо рисовать в gui-билдере glade (я подозреваю, что создавал
окно типа "hello, world") во вторых, для тех десяти строк (если они не связаны
с конструированием gui, а с заполнением widget'ов данными и обработкой событий)
можно сделать одну функцию и юзать ее потом.
Ну и еще - может ты просто не знал gtk и поэтому писал не эффективно.
Производителям коммерческого софта хочется использовать компилируемые языки
чтобы не допускать подсматривания алгоритма/улучшения чужими силами. Поэтому
им надо будет использовать Tk из C - а он наверно тоже не прелесть при юзании
из C (и других языков).
> > голословно утверждаю о качестве gtk - я пишу софт под него уж год очень
> > активно.
> > А насчет проталкивания в gnome - по-моему это вполне реально.
> >
> > > > отстой, надеюсь к чему-нить это приведет). Главное чтобы лицензия была LPGL,
> > > > не меньше (хотя бы на библиотеку для работы с NAS).
> > >
> > > Лицензия там по-моему то-ли MIT, то ли BSD-style. При беглом взгляде на
> > > текст лицензии я разницу определить не могу.
> >
> > Наверно поэтому (из идеологических соображений) его в gnome не взяли..
>
>
> Так и BSD и MIT куда более свободны чем GPL/LGPL (чем кстати отчасти и
> объясняется поддержка NAS вендорами)
Полностью согласен.
> > > vnc? На сервер? Рыбу? Ножом? xvfb по крайней мере не даст никому этот
> > > сервер взломать, чего о vnc сказать нельзя.
> >
> Наверно секьюрность xvfb не намного лучше vnc.
> Намного. В силу невозможности приконнектиться к нему с другой стороны
> (т.е. не со стороны X-клиента)
Мне казалось (необоснованно, правда) что X есть непаханное поле для
аналитиков security - не все мы о ней знаем...
>
> --
> Victor Wagner vitus@ice.ru
> Programmer Office:7-(095)-785-09-72
> Communiware.Net Home: 7-(095)-135-46-61
> http://www.communiware.net http://www.ice.ru/~vitus
>
>
> --
> To UNSUBSCRIBE, email to debian-russian-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Best regards,
-Vlad
Reply to: