Welcome to eComStation.RU site!

Select your language: Russian English Deutch Spanish Italian Portuguese Czech Polish French

Frequently asked questions and answers:

eComStation.RU

ru · en · de · es · it · pt · cz · pl · fr
eComStation - это совершенно другая операционная система для PC (IBM OS/2 Warp)
Программы, новости, статьи, поддержка пользователей, оборудование, вопросы и ответы.
 
      Что такое OS/2?НовостиУстановкаОбновлениеПрименениеБудущееСообществоКупить    
(Карта сайта)

 
 
Отчет: OS/2 совместимое оборудование
Как получить драйверы OS/2 бесплатно

 
Обновление

 
Программы

 
(Санкт-Петербург)

 
Преимущества (1)

 
Разработчику (1)

 
(Пайпы программ)

 
Компании: (1)

 
История (1):

 
(Бонусы)

 
Советы:

 
(Барьеры и решения)

 
Технологии: (1)

 
(Применение в науке, лаборатории, ..)

 

 
Готовые решения:

 
Новая eComStation:

 
Будущее: (1)

 
(Ссылки на другие сайты)

 
(Картинка дня)

 
Артефакты OS/2

 
Гаджеты

 

Перспективы eCo Software - Юрий Прокушев


TITLE: Перспективы eCo Software - Юрий Прокушев

DATE: 2005-06-06 12:49:51

AUTHOR: Yuri Prokushev

Юрий Прокушев Расскажи о себе. Твои профессиональные навыки?

Родился в 1978 году в Новосибирске, где сейчас и живу. Закончил Новосибирский Государственный Технический Университет по специальности "Электрический транспорт", защитил диссертацию на соискание ученой степени кандидата технических наук по специальности 05.09.03 - "Электротехнические комплексы и системы" на тему "Совершенствование методов энергетических расчетов электротранспортного комплекса" (по сути, имитационное моделирование движения троллейбуса). На данный момент ассистирую по курсам "Теория электрической тяги", "Электроснабжение". Веду курс "Контактная сеть". Подготавливаю курс "Информационные системы и технологии" для специальности "Электрооборудование летательных аппаратов".

Программированием увлекаюсь более 15 лет. Языки: ASM i8080, Z80, i80x86, Pascal, C, Basic, REXX, LabVIEW и пр. В основном интересует прикладное программирование и равитие средств компонентной разработки приложений. Операционные системы (в порядке убывания предпочтений): eCS, OS/2, GNU, Win32, DOS. В связи с увлечением средствами компонентной разработки приложений, интересуют такие языки, как Component Pascal, Oberon, Modula. Технологии: SOM, CORBA, XPCOM, COM, OpenDoc, Taligent, в малой степени JavaBeans.

Что тебе больше всего нравится писать для OS/2?

На данный момент - это SOM (занимаюсь разработкой SOM Compiler Pascal Emitter), WPS (eSchemes), MMOS/2 (IO Procedures, Codecs), OpenDoc (компонентные приложения). Что мне НЕ нравится: RAD-средства разработки (Sibyl, WDSibyl, DrDialog, VxREXX и пр.), написание драйверов, Stand-alone PM-приложений, очередных компиляторов, простое портирование приложений (имеется ввиду, без интеграции в систему) и прочее такого рода.

Над каким проектом для eComStation TNG сейчас работаешь?

На данный момент идет разработка проекта eSchemes, целью которого является исправить бедственное положение с внешним оформлением системы.

Лёгкие схемы eSchemes позволяют сменить цвет окон. Полные схемы позволяют также изменить иконки WPS-классов, звуки, курсоры и т.д.

eSchemes не планирует на первой стадии расширение оформительских возможностей системы и серьезных исправлений. Основная цель этой стадии - интеграция с WPS возможностей iThemes, WindowThemes, eStyler и Scheme palette. Класс Scheme palette устарел, а WindowThemes, iThemes, eStyler не вписываются в систему, нарушая ее управляемость. В дальнейшем eSchemes планируется расширять в направлении, близком к CandyBarZ.

Для тестирования системной компоненты eSchemes требуется доступ к BetaZone ecomstation.com.

В каких еще проектах участвуешь?

Фактически являюсь неоффициальным координатором проекта osFree. Несмотря на то, что никакой рекламы и промоушена, дела потихоньку идут, худо-бедно смотрим в направлении создания ядра. Сейчас занимаемся (а точнее, занимается Samuel) вопросами загрузки ядра. (Не путайте osFree с osFree TPE, которая основана на ворованных исходниках).

Являюсь единственным участником проекта OpenSibyl, целью которого стоит развитие средств компонентной разработки (OpenDoc) на языке Pascal.

Участвую в развитии и поддержке Free Pascal Compiler для OS/2. В частности, поддержка SOM и отказе от средств EMX.

Какой перспективный проект ты заметил в последние 1-2 года?

Из перспективных в последнее время были, по сути, два проекта:

  • Win32Prn и
  • Универсальный драйвер сетевых карт

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

Ок. это все драйверы.. а есть сейчас в eComStation программы, которые несут уникальную технологию?

По сути, мало именно программ, которые несут совсем уж новые технологии. Модные в этом веке "новые технологии" у нас были и есть. У нас единственно в чем есть проблема - обновление. Обновление всего и вся. Причем не так уж и координальное. Областей, где надо существенно что-то обновить, очень мало. Давайте возьмем очередную модную в этом веке технологию CORBA. В OS/2 она появилась еще тогда, когда про нее говорили только гипотетически. В "нашем" мире она носит название DSOM. Она построена на основе SOM, на которой построено еще много подсистем OS/2. Та же WPS. Тот же Object REXX, тот же OpenDoc. Тот же пакет Lotus Smart Suite ее широко использует, хотя и не так широко, как хотелось бы.

Исходя из выше сказанного, постараюсь выделить действительно перспективные и уникальные проекты. Это, в первую очередь, XWorkplace. Мало того, что он существенно расширяет функциональность текущих классов WPS, так еще и вносит много новых (к слову сказать, иногда не совсем удачных. Например, TrashCan лучше было бы сделать на основе Shredder. Но таких примеров, к счастью, очень мало).

Другой интересной и перспективной программой я считаю Audio-Data CD Creator. Это примерно то, что я имел ввиду под интеграцией с системой "спортированных" программ и утилит.

И последний пример, это CW Multimedia Classes. Очень удачное направление. Имея в основе примерно те же цели, что и XWorkplace, но только в другом направлении. Если XWP развивает общеупотребительные классы WPS, то CWMM развивает классы мультимедиа.

В остальных направлениях сложно выделить конкретное приложения. Просто по той самой причине, что, как таковые, приложения в OS/2 и eComStation просто не имеют смысла. Т.е. большинство задач можено решить средствами WPS и гармонично интегрировать их с системой. Зачастую новая утилита или программа может быть представлена всего несколькими пунктами меню или страниц блокнота настроек. При фактической громоздкости WPS (имеется ввиду не сложность управления, а количество выполняемых функций), управление системой и выполнение требуемых задач не представляет никакой сложности.

Как еще один пример, я бы выделил еще и RexxMail. Почтовый клиент POP3/SMTP. Опять же, интегрирован в WPS. Несмотря на то, что он написан практически полностью на REXX, он дает представление о том, как должен выглядеть почтовый клиент в eComStation. Это вам не какой-нибудь пресловутый Outlook Express, который просто вырезан из более серьезного продукта и "интегрирован" в систему. Это _действительно_ интегрированный в систему продукт. При некоторой помощи со стороны разработчиков классов WPS он может быть достаточно гармонично интегрирован в систему.

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

Вообще, можно ли что-то делать в одиночку.. или корпорация пользователей eComStation (OS/2) должна самоорганизоваться в группы и работать как маленькие компании?

В одиночку сделать что-либо достаточно сложно. Как минимум нужен некий стимул. В начале это обычное людское любопытство или попытка решить какую-либо задачу, необходимую дома, на работе или просто ради спортивного интереса. Но если нет дальнейшей поддержки, участия хотя бы пользователя, то проект успешно загнется. С группой разработчиков все еще сложней. Для более или менее серьезного проекта нужно еще и синхронизация. Какова вероятность того, что будет взаимодействовать два разработчика? Давайте прикинем. Скажем, посвещать проекту разработчик может час в день. В среднем человек работает около 10 часов. Значит вероятность того, что в данный момент ведется работа над проектом 0.1. А вероятность того, что разработчики взаимодействуют равна 0.1*0.1=0.01. Т.е. над проектом работают совместо только малую толику времени. А если еще и разработчики в разных временных зонах, то вероятность совместной работы и того меньше.

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

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

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

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

Ну, и всегда есть из правил исключения ;). Но таких исключений _е_д_и_н_и_ц_ы_.

В общем же можно заключить, что финансирование, даже частичное, увеличивает вероятность завершения проекта.

И конечно же, преемственность проектов существенно изменяет описанную выше ситуацию.

Итак, какую стратегию в развитии ОС мы (eCo Software) должны выбрать?

С моей точки зрения, это развитие средств компонентной разработки приложения. То, что сейчас модно называть объектно-ориентированным приложением. По сути, реанимировать OpenDoc. Второе - интеграция с WPS. Развитие того же предыдущего подхода. Даже если разработчики eCoSoft не будут использовать исходный код совместно (т.е. чтобы каждый имел к нему доступ), то взаимное использование разработанных компонентов должно иметь место.

Как пример, CoolFM имеет библиотеку управления тюнером. Ее можно было бы использовать для создания, так называемого, AIR-Stream для MM. Как результат - не придется заново тратить время на разработку программы-тюнера.

Пример удачного использования одного компонента в нескольких - CoolFM и ELI. Но... Они реализовывались одним разработчиком. Другим он недоступен. Ну и так далее...

Приведи примеры, какие программы могут быть разложены на такие компоненты?

Вообще, вопрос разбиения программы на компоненты и библиотеки достаточно размытый и неосвещенный. В первую очередь, нужно использовать существующие компоненты системы. В отличие от (не будем показывать пальцем), в OS/2 достаточно четко наблюдается деление на компоненты и подсистемы. И их необходимо использовать. Приложения типа PM123, Z!, WarpVision и тот же WinAmp спроектированы в обход подсистемы мультимедиа, используя только малую ее часть и, по сути, дублируя остальную ее функциональность. Это абсолютно никому ненужная работа. Разработчик тешет себя предположением, что его реализация лучше. Чтож, здесь может быть доля правды. Но... А зачем вообще тогда было вести такую разработку? Ну сделали, ну работает. А дальше что? Все. Тупик. Дальнейшему развитию не подлежит.

В отличие от, например, разработки компонент, типа MP3 IOProc. Поддержка формата MP3 становится сразу доступной _всем_ приложениям, использующих мультимедиа. Включая игры и просто утилитки.

Давайте, для интереса, глянем, сколько раз выполнялась разработка поддержки MP3? PM123, Z!, WarpMedia, WarpVision - это только самые яркие примеры. А сколько еще было проигрывателей, которые канули в лету? Минимум с десяток. Т.е. 10 разработчиков, вместо того, чтобы заниматься другими вопросами, портировали и отлаживали чуть ли не ту же самую библиотеку. А смысл?

Давайте возьмем ту же zlib. Тут уже несколько десятков разработчиков занимались ее переносом. А зачем? Смысл? Можно было 1 раз написать соответствующий кодек и его использовать от раза к разу.

А libpng? А jpeglib от IJG? И т.д., и т.п. Какой-то бег по кругу. Та же ситуация с XFree86/2. Из раза в раз для каждого X-сервера необходимо осуществлять портирование. Имеет ли смысл? Нет, конечно. В OS/2 есть собственная подсистемы видеовывода. Ну так и используйте ее.

Т.е. правило первое. Не надо тянуть решения со стороны один в один. Просто необходимо проводить адаптацию перенесенного обеспечения под собственную среду. Давайте посмотрим на два решения относительно X-сервера. Сейчас их 3. Это по типу XFree86/2, по типу PMX и HOBLink, по типу Everblue. Ни одно из них не дает приемлемой степени интеграции с системой. XFree86/2 _вообще_ выбивается из системы. Вещь сама в себе. Ее вообще, ИМХО, не стоит рассматривать. А вот Everblue и PM X Server - есть корректное решение. Everblue осуществляет поддержку на самом низком уровне, т.е. на уровне XLib. Как результат, дальнейшие задачи по переносу всяких надстроек над XLib значительно упрощаются. Но проблема в том, что к Everblue никак не подключить удаленные клиенты. Т.е. это полурешение. Тот же PM X Server позволяет осуществлять такое подключение. Т.е. комбинирование нескольких подходов даст хороший результат и полноценную поддержку X-клиентов.

Давайте теперь расмотрим возможность разбития на компоненты тех же продуктов eCo Software. Рассмотрим на примере CoolFM и PM Downloader. Рассмотрим сначала CoolFM, а потом плавно перейдем к PM Downloader. Итак, CoolFM есть программа управления тюнером, а точнее, радиоприемником. Основная его задача - дать пользователю возможность выбора частоты приема. Это его основная задача. Остальные задачи вторичны. На данный момент CoolFM - это решение задачи "в лоб". Т.е. библиотека управления тюнером, библиотека пользовательского интерфейса. Что ж. Такое решение имеет право на жизнь. Но... Скажем, мне потребуется создать сервер для вещания через Интернет. Или добавить в CoolFM "прием" радио-потока через Интернет. Вот и все. Для решения данной задачи потребуется решать вопрос с нуля. Т.к. владелец исходного кода может не пожелать его мне предоставить, и не дай бог, еще и продавать.

А теперь давайте представим, как можно было бы это сделать, если спроектировать CoolFM с учетом особенностей системы? Итак, первая задача. Управление тюнером. Никаких специальных средств системой здесь не предусмотрено. В то же время, нам нужен всего лишь проигрыватель, который штатно идет с системой (не думаем пока о реализации, думаем пока о том, что мы вообще делаем). Значит плеер нам не нужен. По сути, нам нужно... читать файл с эфира. Глупо звучит? Отнюдь. Пишем соответствующую Storage I/O Proc, которая умеет только читать (ну, не писать же в эфир, хотя и это возможно, значит это надо предусмотреть). В качестве "имени файла" - соответствующая частота. Вот и все. Приемник готов.

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

Таким образом, весь продукт распался на 2 независимых. Один из них - это проигрыватель, а второй, процедура ввода-вывода. Результат такого разделения очевиден. Играть радио становится возможным с помощью любого проигрывателя MM. А для создания сервера достаточно будет написать Storage I/O Proc, которая будет "писать" поток в соответствующем формате.

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

Реализация интерфейса CoolFM средствами WPS тоже дает ряд преимуществ. А именно, это возможность использовать его не только для радио, но и для обычных аудио-файлов. Причем его можно будет расширять. Как его расширять? Это одному богу известо, какие фантазии появятся у других разработчиков. И SOM такую возможность дает. И не надо говорить, что нет. Все зависит от того, насколько предыдущий разработчик побеспокоился об этом.

С PM Downloader такая же проблема. Отличная утилита сама по себе, но сама в себе. Использовать ее повторно невозможно. Сделать, скажем, зеркалирование FTP уже не выйдет. А вот испоьзуя тот же подход разбиения на компоненты, как описано для CoolFM уже такую возможность дает. И это не единственный пример. Таких примеров - десятки и сотни. Посмотрите в мир Open Source. Раз за разом программы разрабатываются с нуля, постоянная синхронизация с проектами, части которых используются и т.д. и т.п. И конца края этому не видно. Нужна ли нам такая участь? Нет. Большинство из нас ценит свое время, поэтому и использует OS/2. Так давайте же и дальше ценить свое время и не наступать на чужие грабли.

Могут ли сторонние разработчики принять участие в разработке eComStation?

Вообще, современной OS/2 не хватает единства. Слишком часто IBM меняла направление развития. Это видно по системе. Не имеет смысла делать конфигуратор TCP/IP на Java. Или инсталлятор на базе браузера. Это то же самое, что забивать гвозди кувалдой. Результат есть, но рядом лежит куча погнутых гвоздей. Это не есть хорошо.

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

Вторая задача. Информация о системе и диагностика. Существует такой проект, как SysInfo/2. Некоторые его части - это дублирование менеджера аппаратуры. Интегрировать его с WPS - очень даже неплохая задача и решается она достаточно просто. Тогда по правому щелчку мыши по иконке объекта Система можно получить краткие сведения о конфигурации, а расширив класс менеджера аппаратуры - более полное представление. А добавив соответствующие вкладки блокнотов настроек объектов можно добавить Benchmark'и.

Третья задача. Дальнейшее развитие мультимедиа-подсистемы MMeCS (MMOS/2). Больше форматов, больше кодеков. Вплоть до поддержки кодеков от Windows. Это реально и достижимо. И это более корректный подход, чем WarpVision, не смотря на мое уважение к автору последнего.

Задача четвертая. Почтовый клиент, интегрированный с WPS. По сути, классы поддержки скриптов REXX, т.к. методами REXX все решить невозможно.

И последняя задача. Развитие средств SOM-разработки. Поддержка большего количества популярных языков и скриптов. Поддержка SOM в трансляторах языков. Разработка библиотек классов SOM. ИМХО, именно SOM дает нам большинство преимуществ над другими системами.

Часть из этих задумок реализуется через eCo Labs, при условии заинтересованности eCo Software в таких разработках, а также заинтересованности ее заказчиков (таких как Serenity Systems International, MenSys и пр.). Плюс eCo Labs - это возможность еще и заработать немного (а иногда и много ;)) денюшек, что тоже немаловажно.

В общем, вам, пользователям и разработчикам под OS/2, решать, куда мы будем развивать систему в дальнейшем. И я очень надеюсь, что мы не будем тащить к нам "решения от Microsoft" и "Решения GNU" с закрытыми глазами, не отдавая себе отчет о последствиях.

Вернемся к твоему проекту PNG I/O Proc. Многие разработчики по прежнему используют libpng и не стремятся поддерживать системные кодеки. Может так лучше? каждый разработчик автономен?

Я думаю, что библиотеки типа libpng надо эмулировать. Т.е. мы берем и эмулируем поведение libpng, а фактически получаем поддержку _любого_ формата MMeCS. Аналогично для прочих "ходовых" библиотек. MMeCS надо развивать. Тогда не будет "глюпых" извращений, типа "спортируй сто раз libpng и zlib".

Разработчикам надо работать совместно. Но это достаточно сложно организовать. Хотя и возможно и проще, чем кажется с первого взгляда.


 

Попробуй программу:

POP3 Mail Checker Widget - виджет, который проверяет, есть ли почта.

Комментарии:

Igor Vaskov
2005-06-06 21:33:57

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

Yu
2005-06-07 08:58:49

Респект.

Alex G.
2005-06-07 09:36:38

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

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

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

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

Иннокентий Либервузен
2005-06-07 10:57:56

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

Stanley
2005-06-07 11:47:49

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

Yuri Prokushev
2005-06-07 12:05:25

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

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

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

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

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

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

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

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

begemoth
2005-06-07 14:24:12

Ребят.

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

Oxyd
2005-06-07 19:33:34

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

Счастливый пользователь
2005-06-08 00:24:15

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

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

Yuri Prokushev
2005-06-08 06:15:51

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

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

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

Alex G.
2005-06-08 11:56:08

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

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

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

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

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

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

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

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

И чего тада ?

valerius
2005-06-09 05:41:11

Да, автор говорит дельные весчи, конечно, насчет модульности, 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]

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

Валерий

Горлов А.В.
2005-06-09 08:12:32

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

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

Я вас жду!

Чорный Зло
2005-06-09 08:47:41

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

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

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

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

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

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

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

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

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

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

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

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

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

Digi
2005-06-09 09:35:44

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

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

valerius
2005-06-09 11:16:51

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

fuck off!

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

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

valerius
2005-06-09 13:41:44

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

Еще хотелость бы сделать одно замечание насчет 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,

Валерий

Потерянные исходники Мерлина
2005-06-09 16:08:02

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

valerius
2005-06-09 17:10:42

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

WBR,

Валерий

Девелопер
2005-06-09 22:19:24

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

Yuri Prokushev
2005-06-10 09:12:57

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 - я этим заниматься не хочу. Мне других дел хватает.

Вася Эцилопофф
2005-06-10 14:35:55

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

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

Yu
2005-06-10 17:31:37

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

valerius
2005-06-10 18:23:08

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 при портировании :( Короче, хочу сказать, что униксовые вещи -- палка о двух концах, и нравятся, и с другой стороны не все нравится, а многое и очень не нравится. Идеологически :(

Валерий

Алексей Тимошенко
2005-06-10 19:03:52

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

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

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

dixie
2005-06-11 07:12:11

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

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

Korj
2005-06-11 11:14:28

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 на объектно-ориентированном процедурном языке! Супер!

Счастливый пользователь
2005-06-12 00:59:43

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

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

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

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

Slavik Gnatenko
2005-06-13 01:06:21

"Yuri Prokushev:

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

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

valerius
2005-06-13 10:29:48

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, Валерий

vladest
2005-06-13 15:22:20

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

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

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

doctor64
2005-06-13 15:53:40

to vladest:

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

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

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

Pavel Shtemenko
2005-06-16 06:59:29

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

Yuri Prokushev
2005-06-16 09:39:02

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

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

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

потциент
2005-06-16 11:07:49

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

Специалист По Трамвайным Путям
2005-06-16 12:03:27

to Pavel Shtemenko:

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

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

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

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

фонат
2005-06-16 12:58:52

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

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

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

Papa Karlo
2005-06-16 13:07:39

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

Constantin
2005-06-16 19:49:28

2Ж/Д:

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

Уильям
2005-06-16 21:25:59

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

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

Специалист По Трамвайным Путям
2005-06-16 22:08:02

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

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

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

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

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

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

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

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

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

Специалист По Трамвайным Путям
2005-06-16 22:09:54

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

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

Специалист По Трамвайным Путям
2005-06-16 22:11:16

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

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

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

starder17
2005-06-16 23:00:13

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

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

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

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

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

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

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

Sergey
2005-06-17 14:30:00

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

LightElf
2005-06-17 14:55:20

2 doctor64: одна

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

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

Fomalhaut
2005-06-22 16:38:31

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

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

Igor Vaskov
2005-06-25 11:17:40

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

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

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

dixie
2005-06-26 08:19:14

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

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

Igor Vaskov
2005-07-14 12:53:40

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

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

dixie
2005-07-15 09:03:05

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

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

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

Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).


Ваше имя:

Ваш E-Mail:

CODE:
......

  

Ваш комментарий:


Присылай свою историю успешного применения eComStation в бизнесе, а также в офисе и дома. Успешные истории

Статьи

Операционная система
Программное обеспечение
Оборудование
Для разработчика
Разное
Колонка редактора


Готовая eComStation на SSD диске

 





Последний активный опрос: Какая высота барьера RPM?

IBM OS/2 Warp

 
Обучение новичков

Списки протестированного OS/2 оборудования

 
Статьи


   
  Почему eComStation?
Возможности
Особенности
Применение
Ролики и скриншоты
   eComStation для
для бизнесменов
для студентов и инженеров
для продавцов компьютеров
сообщество пользователей
   Разработчик
Распространить программу
Описание API, библиотеки
Начать новый проект
Конкурсы
   Программы
Он-лайн каталог
Выбрать через eCo Market
   Служба поддержки
Отправить вопрос
Купить eComStation
Вопросы и ответы
Обучение новичков
 
 
© 2001 - 2014 eCo Software, All rights reserved
eComStation is a registered trademark of Serenity Systems International
OS/2 Warp is a registered trademark of IBM Corporation
 

 

 
Картинка дня: