Молодец! Поддерживаю. Особенно идею модульности софта.

Респект.

Много правильных слов. Но фактически это признание того, лишь того, что за долгие годы OS/2 устарела ;)

Ну сделают еще стопку заплат. И чего ?

WPS станет еще менее работоспособным ;)

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

Аффтар, а может йаду?

Юрий, Вам было много что сказать. Теперь появилось что обсудить. Приезжайте на конференцию в Кленовую Гору 16-18 сентября!

> Много правильных слов. Но фактически это признание того, лишь того, что за долгие годы OS/2 устарела ;)

Заметим, что не структурно. Не хватает новых форматов, возможностей и просто фич. А это мы в состоянии изменить.

>Ну сделают еще стопку заплат. И чего ?

Не заплат, а расширение функциональности. С использованием той же SOM-модели.

>WPS станет еще менее работоспособным ;)

Не факт ;) Но можно, если уж совсем не думать. :))

>Что касается кодеков - насколько я помню там столько проблем в том что есть, что незавизимый плеер это был единственный возможный путь. Как пример, когда ось не могла проиграть AVI файл , имея для него кодек, тк у него был стандартный по меркам windows, но не оси заголовок.

Заметим, что это проблемы конкретной реализации кодеков, а не самой подсистемы. Заметим, что заменить _один_ кодек или IOProc значительно проще, чем переписать с нуля.

Ребят.

Вы лучше бы сделали, чтобы PM не лОчился да не лАгал... Чтобы ни одно взбрыкнувшее приложение не "замораживало" интерфейс... А то тоскливо читать, как на глиняных ногах мы возведем колосса...

Кстати, osFree это очень хорошо, но как там идут дела с FreePM?

Фигня, извините, про портирование libpng/zlib и тп. Все они существуют в виде dll - хоешь используй. Просто рядом с ними не стоит магического слова объект ;). И заново их портировать нет необходимости - они из исходников собипаются установленным путем, если приспичит.

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

2 Пользователь. Ну почему же фигня? Мне, например, потребовался libpng и zlib не в виде dll и пришлось их опять собирать. Не сложно, времени тратим не много, но это просто пример. Как самый простой. Не считая того, что часто разные версии этой DLL друг-друга просто не переваривают. И про объекты, заметим, никто не говорил. Там разговор шел в чистом виде про MMIO.

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

2 Oxyd А никак :( Есть начало, но нет конца :(

>> > Много правильных слов. Но фактически это признание того, лишь того, что за долгие годы OS/2 устарела ;)

>>Заметим, что не структурно. Не хватает новых форматов, возможностей и просто фич. А это мы в состоянии изменить.

Ну если под структурой понимать нечто крайне глубокого заложения, то даже там устарело ;)

>>WPS станет еще менее работоспособным ;)

>Не факт ;) Но можно, если уж совсем не думать. :))

Фактически он уже малоработоспособен . Я вот через него даже файлы не копирую. Зарекся после пары неудачных попыток ;)

>Заметим, что это проблемы конкретной реализации кодеков, а не самой подсистемы. Заметим, что заменить _один_ кодек или IOProc значительно проще, чем переписать с нуля.

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

И чего тада ?

Да, автор говорит дельные весчи, конечно, насчет модульности, SOM и

прочего. И я во всём этого его горячо поддерживаю! В обсчем, как говорится, так держать! Но вот по части глюков в

PM, WPS. Все же, что говорит тов. Alex-G, тоже правильно, ведь, не имея исходников WPS, мы не сможем пофиксить его глюки, MMOS2 Надо улучшать также архитектурно, а мы этого не можем,

так как у нас нет исходников MMOS2

b WPS/PM тоже. То есть, надо все это в исходниках, поэтому подписывайтесь под петицией про

Open source OS/2 на os2world и еще

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

os2world, подписалось почти 7000 человек, но этого, конечно, мало.

Еще мысль: хорошо бы включить в

требования петиции следующее:

"Если открыть исходники OS/2 (intel)"

не представляется возможным для IBM, мы предлагаем открыть исходники OS/2 Warp Connect, PowrPC Edition aka Workplace OS, так

как для IBM они не представляют комерческой ценности, и, наверняка

отсутствует проблема лицензирования кода у сторонних фирм (например, Micro$oft), а для

создания OpenSource OS/2 это большая помощь, так как OpenSource-проекты по клонированию OS/2 получат много

полезного исходного кода, и докажет еще раз, что IBM поддерживает Open Source проекты. BTW, проектом osFree решено использовать в качестве ядра микроядро L4, и многие подсистемы можно было бы спортировать из сорцов OS2 PPC. В качестве примера можно привести GNU Hurd,

который, изначально базировался на

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

См. [url]

С наилучшими пожеланиями к автору статьи,

Валерий

Коллеги, призываю Вас подключаться!

Добро пожаловать на [url]

Я вас жду!

тов. valerius, вы меня удрочаите.

неушелли и ви тоше шисофреник, как и все сдешние зомбоиды?

таки вы пробывали когдайнибуть _думать гойловой_ ?

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

понимайете об чьом йа, нет, да?

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

все дело ф том что делать это _некому_.

а главное -- назойчем.

тоже и с замейчательным прожектам вроде Freepm итп.

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

тоже и с вашеми пейтициями.

думайте пожалуйста преште чем пейсать свою бурную фантазию на страницах нашего уеба!

полоумные фоннатики-пополамеры задолбали :(

Чорный Зло, погадить больше негде? Своим каментом в давно опопсевшем стиле ПТУшников ты только показываешь на сколько ты не разбираешся в ситуации вообще. А то что Горлов А.В. тратит силы не в правильном, сомнительном направлении - его дело.

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

2Чорный зло: нехорошо хамить, товарисч, флеймить с вами я тут не собираюсь, только мне не нравится то, что вы тут гадите всем своим появлением на этом форуме, лучше гадьте там, откуда вы появились, то есть на форумах виндузятников, ламеров, фламеров и т.п., короче,

fuck off!

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

Вот. Аж зло берет... :(

Перечитывая статью во второй раз...

Еще хотелость бы сделать одно замечание насчет XFree86. Я использую XFree и другие X-сервера под OS/2 уже достаточно давно (с 2000-2001 гг), так что могу сделать, как ее юзер, несколько замечаний. Во-первых, насчет zlib -- вы, Юрий, говорите, что с каждой версией иксов необходимо заново портировать все библиотеки. Конечно, XFree86 4.x.x значительно отличается по структуре от предыдущих версий, и потребовала значительных усилий при портировании, причем, в значительной степени из-за того, что там всё сильно завязано на формат исполняемых файлов ELF, в частности, загружаемые модули-расширения X-сервера в OS/2-версии иксов, точно так же, как и в юниксах, имеют формат ELF! (можно в этом убедиться по сигнатуре "ELF" заглянув внутрь файла), так вот, насчет библиотек -- библиотеки наверное, чем-то и отличаются в разных версиях, но вот,

например zlib, libpng, jpeglib, giflib и др. я не менял со времен старой версии иксов (3.3.6), и они у меня стоят старые, датированные примерно 1999 годом, и это пока не вызывало проблем с новыми версиями иксов. Другое дело -- новые версии софта, но тут, как известно, проблема -- портирование нового софта под иксы идет вяло, и я за последнее время видел из новых только putty-gtk -- телнет-клиент. :(

Во-вторых, XFree86 -- это кусочек unix внутри OS/2 и авторы просто хотели сделать ее с минимумом отличий от unix-оригинала, что бы уменьшить проблемы при портировании прикладного софта,

причем это должно было стать началом проекта по эмуляции unix,

более или менее полной, (проекты

UnixOS2 и posix/2, более-менее заглохшие, как и портирование иксового софта :((), так что, полнота

эмуляции API unix-ов, а также их "look-and-feel" и простота портирования, а также вопрос производительности графики обусловили отказ от интеграции в ОС, что, с одной стороны, конечно, плохо, но, с другой стороны, вы можете убедиться, установив XFree, что способ работы с графикой в иксах быстрее PM-ного на глаз в несколько раз, что это позволяет с легкостью реализовать все графические фичи, которые есть в юниксах, "просто" их спортировав оттуда, в том числе, OpenGL и др., причем даже если они не реализованы в PM. То есть, здесь задачей было другое -- максимальная переносимость, причем известно, что XFree86OS/2 отличается от оригинала примерно на 2% (т.е., процент патчей от всех исходников), и даже те глюки, которые есть в Линухе, были успешно спортированы :). Это, конечно, плохо с точки зрения "интегрируемости в ОС", и я думаю, что хорошо иметь механизмы, например, для связи PM-ного и иксового клипбордов, других механизмов взаимодействия с остальными частями OS/2, но этого,

сорри, не было сделано, и прежде всего, потому, что авторы ставили задачу именно максимальной совместимости (не обрубки какие-нибудь, а _полноценная_ реализация XWindow!, именно поэтому требуется макс. совместимость), а не максимальную интеграцию. Тут можно заметить, что "интегрированные" продукты проигрывают XFree по количеству фич, это самый мощный и быстрый X-сервер, а Everblue--это для тех, кто не умеет поставить XFree :)

Сорри за длинноту мыслей и витиеватость :)

BTW,

Валерий

Ну вот, теперь мы стали еще и "ворованными"...

2Потерянные исходники Мерлина: сорри, не хотел обидеть :) Конформизьм-с. Мы теперь живем в буржуйском мире и зачем-то перенимаем его понятия. А вообще я сам никогда не считал копирование софта воровством. Просто потому что копия идентична оригиналу, а владелец первого екземпляра его при этом не теряет. В обсчем, Imformation must to be free и Punks not dead! :) Но, к сожалению, чтобы нас потом не засудили всякие мокрософты, нужно подчиняться законам государств, хотя государство -- это зло. :( :) Вот, надеюсь, вы меня поняли.

WBR,

Валерий

To: Потерянные исходники Мерлина - а кто сказал что вас не пользуют ?! пользуют, очень даже пользуют, хотя конечно лучше б вас еще раз потеряли

2valerius А теперь давайте посмотрим, маленько, вопрос про X Window подробней. Вот смотрите, для поддержки всех видеокарт требуется портирование всех серверов. А имеет ли это реальный смысл? Достаточно ведь разработать X Server для DIVE или того же PM (а точнее, GPI) и повторное портирование всех ерверов не потребуется и двойная настройка видюхи тоже не будет нужна. На счет скорости я бы с вами сильно поспорил. Начнем хотя бы с того, что в X реализована клиент-серверная архитектура со всем вытекающими. Все данные постоянно гоняются туда - сюда. Благо хоть, window managers являются серверной частью. Но это нас не волнует. Это просто лирическое отступление ;)

Основное, что я имел ввиду, что, даже если целью стоит совместимость с тем же унихом, то это не отменяет необходимости вписывать софт в систему. И разговор не про "куцость" портирования, а наоборот, про более полное портирование. Я считаю порт XFree86 куцым, т.к. он реализует совершенно отдельную посистему, хотя должен бы был базироваться на родной графыической подсистеме. Everblue, в свою очередь, не решение для ленивых, а попытка такого базирования на родной подсистеме. Плюс это решение в стиле "реализуем низкий уровень, а остальное просто соберем". Т.е. обычное снижение затрат. Плюс оно уже не клиент-сервер. Что, теоретически, должно дать выигрышь в скорости.

Но и опять я про другое. XFree - вещь сама по себе. Отделный мир. Может тогда проще сразу уйти в никсы и не пудрить себе голову? ;) Вопчем, это разговор не про "плохость" или "хорошесть" решения, а неком компромисе спортированного и родного софта. Если уж портировать, то с учетом особбенностей родной среды. Или не портировать вообще. Желающим иметь Linux на OS/2 лучше уж спортировать CoLinux и заиметь полную Linux-среду и не тратить силы на те же XFree86 и пр.

По поводу zlib, libpng и пр. zlib, как пример, не очень показателен. Но в связке с libpng - очень даже. Накой мне поддержка PNG в X, если ее нет в OS/2-приложениях? Я хочу и там и там. Причем не в виде libpng, по той простой причине, что это опять заплатка, а не нормальное решение. Если я буду грузить jpeg одной библиотекой, png другой, а bmp - третьей, то неразбериха будет полная. Посмотрите в мир Linux - тридцать дри системы мультимедиа и еще одна впридачу. Плюс куча отдельных библиотек. Оно нам надо? Я не хочу задумываться, в каком там формате лежит изображение, если моя задача - всего лишь показать некую картинку. В каком ее формате принесли - мне должно быть начихать. Я хочу решать только свою, локальную, задачи, а не еще сотню-другую параллельных. Есть разработчик, который занимается поддержкой графических форматов - пость он об их поддержке и думает. У него для этого квалификация выше. А я буду решать свои.

Основная суть - в этом. Не делать чужую работу. И как бы не было просто в очередной раз собрать zlib - я этим заниматься не хочу. Мне других дел хватает.

Каменты жжгут!

Аффтарам респекты. Пешите есщо!

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

2Yuri: Насчет портирования под ось всех X-серверов: на самом деле, как говорит Holger Veit, автор порта XFree86 под OS/2, ему достаточно было спортировать только один сервер, а все остальные переносились уже автоматически по налаженной схеме, я к сожалению, не знаю, как это было технически, и почерпнул эту информацию из FAQ'а по XFree86OS/2. А на данный момент XFree86 4.x.x имеют модульную структуру, там всего один X-сервер и для каждой видеокарты модуль-драйвер. А дублирование функциональности -- это получается потому, что задачей было создать максимально быструю видеосистему, и максимально полноценно перенести ее в OS/2, точно так же, как вам не понравилась идея GPI поверх XLib (см. форум на osfree.org), также и X11 была реализована через прямой быстрый доступ к железу; а вообще, конечно, хорошо бы было иметь нормальный DIVE X-сервер. Причем он даже частично был реализован, но, кажется, просто исходники этого проекта были утрачены его автором, и ничего из этого не вышло :( А вообще мне нравятся иксы как альтернативный интерфейс, то есть, мне нравится сама идея "сетевого рабочего стола", а не нечто типа Windows Terminal Server... в общем, мне не хочется спорить, все это "на вкус и цвет...", насчет производительности -- я имею в виду не нечто столь тяжеловесное и цельномонолитноглючное, как KDE и GNOME, а решения в стиле здравого минимализма -- оконные менеджеры BlackBox и WindowMaker, если иметь меру, то можно быть приятно удивленным высокой производительностью. Насчет Everblue -- мне в нем не нравится только то, что из него убрали клиент-серверность. Хотя вещь сама по себе интересная. Примерно в том же направлении мне хочется видеть развитие PM -- он должен быть легким, быстрым, модульным, опционально -- сетевым; идеи типа тех, что предлагает уважаемый разработчик FreePM, должна отсутствовать проблема лочки очереди сообщений, кроме того, еще такая мысль -- может быть, лучше было бы, чтобы подсистема печати и мультимедиа были более обособлены и работали без PM, менеджер сеансов вынести из PM и сделать его запускаемым в текстовом режиме, типа tshell'а, но чтобы можно было запускать PM из этого шелла и его завершать, без надобности перезагрузки. Конечно это всего лищь желаемое и ему далеко до действительности. Не хочется следовать дурному примеру Linux как вавилонского столпотворения программ, библиотек и параллельных подсистем, которые на много процентов друг друга дублируют. Этим OS/2 как раз и отличалась своей модульностью и компонентностью, но, к сожалению весь этот Hell перетаскивается в OS/2 при портировании :( Короче, хочу сказать, что униксовые вещи -- палка о двух концах, и нравятся, и с другой стороны не все нравится, а многое и очень не нравится. Идеологически :(

Валерий

>>может быть, лучше было бы, чтобы подсистема печати и мультимедиа были более обособлены и работали без PM, менеджер сеансов вынести из PM и сделать его запускаемым в текстовом режиме, типа tshell'а, но чтобы можно было запускать PM из этого шелла и его завершать, без надобности перезагрузки.

--------------------------------

Очень поддерживаю такую идею Валерия.

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

А просто так - физически некогда. А работы там мноооого ;)

valerius: Дело даже не в том, сколько конкретно времени потратили авторы на XFree86/2. Её суть -- бессмысленна, я тут согласен с YP. Легче в VPC слюникс какой поставить за 5 минут или вообще отдельно. XF86/2 -- переключение между двумя OS на одном экране, она не более осевая, чем виндовая или макинтошевая, хоть бы и 100% исходников были переписаны под Ось.

2Yuri Prokushev:

А можно ли было реализовать, скажем 5+1 звук не выбрасывая MMOS/2 на помойку? И ещё куча таких же вопросов, видимо, была. Что ни говори, но Великое Проектирование Оси, ради которого её и стоит юзать/развивать, произошло гораздо раньше появления самого термина "мультимедиа" и тем более мегабаксов, вложенных Интел-ом в виндовую мультимеди-поддержку. Мы слишком упираемся в старые API, возводя совместимость в абсолют, а в жизни не юзаем и никогда не юзали ниодной программы для OS/2 1.x/2.x, в жизни многие (если не все!) драйвера для 2.х и 3.х не идут на 14.х ядре, а для 14.х ядра пишем, наконец-то полу-32-битные драйвера без обратной совместимости.

Так же и с WPS -- сколько было всегда шума вокруг его объектности, а реально использующие объектность проги можно пересчитать по пальцам! Родной WPS-ный файловый менеджер менее юзабелен, чем нортоновидные, по крайней мере для нас, выросших из нортона, а не мака. Так вот под процедурной вендой я юзаю графический Windows Commander, отлично через процедуры берущий всё необходимое для интеграции с Shell-ом, а под хвалёной объектной полуосью я юзаю File Commander/2, т.к. нет нормального интегрированного WPS-овского нортон-клона!

И не сделали его, в первую очередь потому, что нет RAD-средств! И не будет!

Кому кроме тебя нужен уже 100 лет как дохлый паскаль? Ну даже если ещё пару девелоперов в нём и нуждаются, то большинству-то другое надо! И где оно? Сколько было шума о Eclipse -- даже опен сорс не спортировали! А это показывает, что всё -- алес. Как визуалэйдж похоронили, так и пришёл.

И про WPS -- прошла его пора, и слава Богу! Монстр он монстр и есть, слишком монстроидный и криво спроектированный. И классы его они-то классы, но вот в новых программах совсем другие классы -- Java-вские, с WPS-ными никаким боком не стыкующиеся, хоть и CORBA-CORBA, а даже в IBM-овской джаве про них забыли! Вот любителям объектов объектный язык, а где в нём осевые объекты? -- нету! Т.е. будем писать для объектного WPS на объектно-ориентированном процедурном языке! Супер!

2 Yuri Prokushev: А чем же вам не подошла DLL ? Почему тогда другому программеру подойдет zlib в виде MMIO модуля? Я думаю, как раз это ему подойдет меньше всего. Тем более одну dll можно использовать и в mmio модуле и во всех остальных решениях, на то dll и разрабатывались. И несовместимость оригинальных библиотек между собой некий мифический модуль над ними не решит, а только максимум замаскирует от вышестояих разработчиков за счет урезания общей фунциональности.

А фанатизм веет как в оценках работы прочих программистов и их продуктов, так и в предлагаемых перспективах развития os/2. Особенно он умиляет в свете собсвтенных неизлечимых проблем pmshell/wps.

Можно сколько угодно призывать к вашей стратегии имплементации решений, однако за всю историю развития OS/2 именно столь ругаемые вами подходы только и приносили плоды пользователям.

Вольгемутовские MMIO классы кто для чего использует ? Тогда как тотже wvgui уже существует и используется всеми пользователями os/2.

"Yuri Prokushev:

Желающим иметь Linux на OS/2 лучше уж спортировать CoLinux и заиметь полную Linux-среду и не тратить силы на те же XFree86 и пр."

Насколько я понял, CoLinux - это только ядро. А X server там используется очень даже нативный, т.е. Cygwin для случая Win32. А ващще давайте поддержку Xen сделаем. Тогда можно будет линух пускать действительно параллельно ;)

2Slavik Gnatenko: Вообще речь шла о реализации соответствующей posix-подсистемы для OS/2, то есть, (не знаю насчет виндовых Cygwin -- не юзал), речь шла о том, чтобы полуось заимела подсистему, имеющую все необходимое для компиляции и запуска любой унихоидной программы, ну типа линуксовых портов в FreeBSD--это не линух, а подсистема внутри фри. ИМХО, гораздо прикольнее иметь нативные версии тех же программ, спортированных с юниксов, чем запускать все это в эмуляторе, просто потому что emx-это ИМХО гораздо "круче" -- это вам не запуск другой ОС в виртуальной машине, а собственная подсистема для полуоси, то есть, это когда я работаю, например, в X11, используя расширение OS/2 API, а не с чужой ОС в пробирке. Просто, ИМХО, линух в пробирке -- это линух, а emx-порты это уже не линух, а часть OS/2, так как интегрирована в нее, и работает в общем пространстве с осёвыми программами. Вот, я хочу сказать, что emx -- это не линух, а нативная подсистема OS/2, позволяющая запускать аналогичные программы. Вопрос только в более-менее прозрачном переносе юниксовых программ в emx (posix/2, UnixOS/2), другое дело, что кому-то этот софт не нравится, мне тоже не нравится кое чем, но за неимением лучшего... просто, мне, например, нравится текстмодовые программы, но вот, броузер текстовый -- это в основном links (или lynx -- хуже), почтовая программа -- pine или elm, а вот осевых более нативных (многие не считают emx нативным :)) просто нету, мне например, очень нравится Turbo Vision, и я даже мечтал под него кое-что написать, но, к сожалению, на написание всего, чего нужно, времени не хватит, а юниксовые порты они -- уже готовые. Что имеем, то и юзаем, и я хотел бы просто их использовать не в пробирке, а под полуосью. Вот, эито просто, чтобы было понятно, а вот спорить об этом мне не хочется -- как говорится, "на вкус и цвет...", так что давайте закончим эти Holy Wars, так как из них ничего доброго не выйдет.

WBR, Валерий

насчет MMOS2 IOProc. Как по мне, так идея текущих IOProc ущербна, поскольку нужно отделять мух от котлет. Т.е. поток байт отдельно, демуплексирование отдельно и кодеки отдельно. В IOProc это все в одной кучке. Лепить для каждого варианта поток+демуксер+кодек свой IOProc никакого желания нет. Отсюда вывод: поскольку сырцы мумедии формально закрыты, да и сам ее дизайн устарел (хоть и содержит много интересных идей) ее нужно редезайнить и переписывать. Вопрос: кто это будет делать? Когда? и тп.

зы. статья попахивает заказухой.

ззы. поскольку мне закрывают доступ везде на этом сайте, КОМУ ИНТЕРЕСНО ПОДИСКУТИРОВАТЬ - МЫЛОМ

to vladest:

И самое интересное - кто за это заплатит?

По поводу ioproc - мысль мелькнула - а если написать этакий универсальный ioproc, умеющий ВСЕ форматы и сам отбирающий кодеки и демуксеры?

PS: Естественно, заказная. что ты ожидал от усы.вру?

А теперь еще дружно вспомните про ACPI

Ну, фанаты мы все здесь частично, иначе бы нас здесь небуло.

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

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

За что вы травите пейсателя?!

to Pavel Shtemenko:

А что мы еще должны дружно вспомнить про ACPI ?

Пока кроме твоего обычного детского бахвальства и демонстрации собственной глупости во всех доступных тебе конференциях, форумах и ирцах (включая RU.OS.CMP) ничего не видно.

Неужели в самом деле ACPI в eCS БУДЕТ до ее смерти? Тогда пожалуй куплю. Чтоб хотя бы посмотреть на ЭТО!

Впрочем не верю, не верю.. :(

Ну это вообще уже! Вот только ламерского мнения "специалистов по путям" нам тут и не хватало!

Слыш, ты если такой умный - попробовал бы сам написать что нибудь навроде bootable jfs, bootable ntfs, svista, jrescuer, acpi и binkd с поддержкой рекса для своего виндовса! Кроме которого ты судя по всему ничего вообще не видел (ну в крайнем случае линукс!!!)

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

дада. Тупо тут не надо флеймить. Лучше флеймить по делу, если без флейма мысля не мыслится

2Ж/Д:

"Охотники вывихивали руки в тщетной попытке показать, какого размера череп тахорга они могли добыть, если-б знали, с какой стороны у карабина приклад" (с) А. и Б.Стругацкие

Простите, я не удержался :( Но после таких вот ... :(

Продолжайте пожалуйста обсуждение. Я считаю оно очень важно. Я лично все читаю очень внимательно и с большим интересом!

Блин, ребята, простите :(

Ну поймите, сорвало меня. Это ж полная жопа :((( WPS в очередной раз подвис - watch-cat не берет!!! JFS при чеканьи снес 2 гига порнухи (целый год собирал, хотел продать за немного $ в локалку), а тут еще Uniuad ни с таво ни с сего начал _хрепеть_, а потом WVGUI, чтоб ему в жопу повернуться, повис на просмотре моего любимого DVD "Водный Мир"!

Ну поймите :((( А еще похмелье с утра. Ну я и среагировал на Пашу, подвернулся :( Ведь у меня интегреная сетевуга и не берется изза ACPI - так говорят на канале :(

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

И все-же, как бы побороть мои проблемы?? Ведь житья же нет.

Может чего-то в реестр прописать надо?

Пепси/пива поставлю сколько не попросите.

ps. С vladest-ом списывался, ничего не помогло.

pps. в Win XP SP1 на той же машине все работает!

To Constantin: А чего ты сказать-то хотел а? Я не читал твоих А и Б. Только слышал что они круты. Мне пока Лукьяненко хватает, он вроде их ученик.

Вот когда-нибудь, его всего прочитаю, тогда может куплю и Стругов - у нас тут продают, "Время Учеников", чего скажеш?

Уильям, у тебя что, никогда похмелья не было да?

Я же извенился :(

А программировать я пока только в Delphi Studio 7 начал. Но я плонирую дальше изучить Си, и начать писать для eCS, что посоветуешь из док??

А по поводу перспектив. Мне как пользователю OS/2 с 1994 года, ныне работающему в банковской сфере весьма интересен этот вопрос.

Я тут посчитал. Выходит приблизительно так:

Для работы над ядром надо около 10 _квалифицированных_ человек.

Им надо платить не меньше 1 k$ в месяц. пусть будет 1.5 k$. итого получается 15 k$.

Работа по переработке ядра займет не менее 2 лет до выпуска рабочего образца. это 15 x 12 x 2 = 360 000 $

Вот такая нужна сумма на два года работы для OS/2. Или примерно такая. Я готов поднять вопрос о предоставлении половины, но этого мало, нужны еще вложения.

Жду ваших предложений здесь или на емайл. Поднять OS/2 на новый уровень - это реально, я так думаю. Главное ведь очень захотеть ;)

Статья так себе, но вот камменты!!! ржунимагу

2 doctor64: одна

универсальная IOProc уже есть. Зовется avio.dll. Теоретически должна понимать любой *.avi. Из заголовка авишки читает название кодека, ищет в инишнике соответствующий кодек и загружает его, реализована весьма через анус, но можно поправить/переписать, ибо кода там немного. Как писать кодеки есть в тулките. Ничего не надо выдумывать - все уже придумано. :)

2 vladest: ты не прав. IOProc работает именно с потоком байт. То есть берет поток байт (например файл) и расщепляет его на составляющие. Для каждого из вложенных потоков (audio/video) через инишник выбирается подходящий кодек и дальше уже их забота. Тот факт что некоторые отдельные граждане ни хрена не поняли и запихали в IOProc вообще все что можно - проблема именно этих несознательных граждан :)

starder17: 120k$... Меня "терзают смутные сомнения" :). Я не в сомнениях, а о том, кто ты, чем занимаешься и для чего ты используешь (или хочешь использовать) OS/2? Ведь для того, чтобы единовременно вложить столько денег на достаточно неопределённый срок (2 года - только срок вложения, но не отдачи). К тому же неопределённость в результате и эффекте тоже есть.

P.S. Не в тему, но очень интересно стало. :-)

2Fomalhaut IT Бюджет относительно крупной компании может быть порядка $500-900 в год. Стоимость комплексного решения ERP может доходить до $7 млн за 3 года. При таких денежных потоках изыскать $90 000 в год представляется задачей вполне решаемой.

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

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

2Igor Vaskov: да, денег бродит по миру много и они уже, в общем, не знают куда приткнуться :) Вопрос - как их сюда заманить :) Мне, например, сильно хоца во freepm поучайствовать, но, вот, кушать-то хоца еще больше.

А "обслуживающий персонал" - это лишнее. Выдумки нашего времени, в котором много лишних людей, но мало Специалистов. На этапе повторения API технические писатели практически не нужны. А тестеры найдутся и бесплатно ;)

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

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

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

И если структуры проекта нет хотя бы у одного человека в голове - тож пропало дело :)

Впрочем Координатор-то, как раз, не помешает. Но опять - проблема его найти, когда кругом сплошь кООРДИНАТОРЫ.