|
Обновите ArcaOS до уровня NeoWPS
- Установите набор PNG иконок, нарисованных дизайнером, специализирующемся на оформлении OS/2
- Установите eSchemes 2018, чтобы менять цвета и кнопки на рабочем столе
|
Перспективы eCo Software - Павел Штеменко |
TITLE: Перспективы eCo Software - Павел Штеменко
DATE: 2005-09-01 00:01:20
AUTHOR: Pavel Shtemenko
Расскажи о себе. Твои профессиональные навыки?
Образование высшее техническое, специальности эл.слесарь КИП и А,
конструктор-технолог РЭА (это я по наименованию в дипломах). Так
получилось, что я работал по НИРСу (научно-исследовательская работа
студентов) и сразу связался с компьютерами, прошел череду АРМ СМ-3,
Д3-28, АРМ СМ1420 (АРМ говорит о том, что там были графустройства
типа дисплеев и графопостроителей). Закончил Одесский Политехнический
Институт (сейчас это Одесский Национальный Политехнический
Университет). Первое практическое программирование началось с порта
программ с DOS11 в RSX11M (это было первым заданием по НИРСу), себе с
курсовыми жизнь облегчал и до того как ;-) Диплом на 99% был изготовлен
на вычтехнике (учитывая что IBM PC и лазерные принтеры были несказанной
экзотикой и редкостью), 1% - это один чертеж меня руководитель заставил
нарисовать руками, дабы показать что чертить руками я тоже умею ;-)
Далее аспирантура, писание дисера по теме автоматизации для вояк,
работа начлабом кафедрального вычкомплекса, 1991 год все идет в
задницу, ухожу на вольные хлеба. Далее, сети, админы, правка/писание
прог под заказ. Собственно тогда и оценил ось, когда в 1993 провел
сравнение DOS+LanTastic, WFWG, Novell 2.20, OS/2 warp (специально
выделил целый день и на одном и том же компе, запуская то это, то это,
все сравнивал по всем нужным мне тогда показателям). OS/2 показала
наилучшие результаты по всем нужным параметрам и была принята на
вооружение. Последний сервак из тех что я тогда ставил, был снят в
2002 году по причине полного умирания железа.
Что еще? В FIDO и Internet пребываю с 1991 года, являюсь
одним из основателей одесской сети FIDO. Из более ярких
общеизвестных работ на вольных хлебах это:
- сопряжение электрически и написание софта PC <-> СМ1420 (СМ1420
для PC выглядела как обычный диск), затем и сетку по компортам для
PC-PC сделал на той же основе
- резидент для модема ComCall1200 (было такое чудо) дабы с ним
работали фидошные и интернетовские проги
- FOSSIL driver для советских персоналок типа ЕС18xx и немецкой
Robotron дабы с ними работали фидошные и инетовские проги
- прога сбора статистики ошибок из сети
- прога управления доработанным хабом для хоминетов
Сейчас ты участвуешь в проекте ACPI. Мог ли ты подумать в то время,
что появится такая технология как ACPI?
На самом деле к этому шло с того момента, как в PC начали экономить
электроны, то есть когда появилась "зелень". ACPI - это всего лишь
развитие, оформленное в объектную форму. Зачем Intel избрал именно
такой путь - мне не ведомо. Hо он есть и даже имеет стандарт.
Бета-тестирование драйвера идет полным ходом. Слишком
много завязано на ACPI если его включить. Hа какие подводные камни
я и другие разработчики еще наступят, я угадать не могу.
Расскажи подробнее про ACPI
Advanced Configuration and Power Interface specification. В названии
сказано все. Все и сводится к объектному описанию управления питанием
и выдаванием конфигурации различным устройствам. Все сводится к объектам
и методам, применимых к ним. Все платформенно независимо. Типа Java. Есть
свой язык описания. Есть компиляторы и интерпретаторы. То есть такая себе
виртульная машина ACPI. Есть такая виртуальная машина как Java для
отображения, расчетов e.t.c. Теперь есть виртуальная машина ACPI для
работы с устройствами. Если бы можно было посредством ACPI организовать
и ввод/вывод с них, то Intel однозначно можно бы было ставить прижизненный
памятник. Увы, этого нет. Есть только управление конфигурацией и
потребляемым питанием. Вот тут и начинаются траблы почти для каждого
оса в отдельности. Девайсы по старинке конфигурируются сами, потреблением
питания уже заведуют совершенно отдельные программы. В общем, любой
ACPI-исполнимый код обозначается URL-ем
типа "\\aaa. ... xxx.yyy. ... .zzz", в этом
URL есть вся информация чего делать, как делать и в какое место. Такому
URL могут быть нужны параметры, на выходе он тоже может выдать параметры.
Все делится на (в основном) на "device" и методы. Применяя к "device"
метод - мы получаем требуемое действие или требуемый ответ. В общем
для работы с ACPI все. Драйвер (виртуальная машина) уже для eComStation
написан. Дело только за его применением.
Вообще, легко ли писать драйверы для eComStation и OS/2? С чем это можно
сравнить?
Легко писать все что угодно, если знаешь что писать ;-) Именно
драйвера в OS/2 - это расширенная версия драйверов для MS-DOS. Первый
драйвер для MS-DOS я написал 1990 году. Потому наверное мне тяжело
судить легко или просто. А "виртуальные" и "для железа" отличаются только
тем что для железа, нужно еще знать как работает само железо.
Как писать драйверы, написано в тулките или в DDK.
Все что не написано там, можно найти в
исходниках DDK. Если и там не хватает, то пора идти на
#ecolabs
или на #netlabs ;-)
Какой перспективный OS/2 проект ты заметил за последние пол года?
Лично мне ближе GenMac, но кажется что он сильно вяло развивается
(ну это чисто субьективное мнение).
Какие еще универсальные драйверы можно создавать?
Конечно UniFS ;-) Вот только когда я смогу заняться им, это вопрос.
Есть база - JFS, с неплохой организацией кеша и отложенной записью,
журналируемая. Туда прямо просится, в тот же "движок", встроить и все
остальные FS.
У тебя большой опыт общения с компьютерной техникой.
Какой секрет выживания платформы OS/2?
Думаю в том, что OS/2 не считает себя умнее железа и, ни в коем случае,
умнее пользователя. Сказали ей сделать так - сделали.
Не говорят делать - не делает.
Вот например введение ACPI ну совсем не помешало ОС жить так, как жила прежде.
Также это позволило писать совершенно отдельный драйвер для ее поддержки.
Какую стратегию в развитии ОС мы (eCo Software) должны выбрать?
Чем больше будет уникального софта тем лучше. К примеру линуксойды ко
мне уже приставали насчет Jrescuer под линух. Были посланы - надо спасать
данные? найдете ось и спасете. Лично у меня просто нет времени портануть
его в линукс. Соотвественно чем больше такого будет софта, тем будут больше
задумываться "а на кой мне этот ... ?"
Нужно ли всегда заботиться о совместимости с файловыми системами Microsoft,
Linux, Apple?
Что касается Microsoft - вообще не надо.
Достаточно поддержки одной FS.
На текущий момент это или FAT32 или NTFS.
С FAT32 пока плохо и продвижений не предвидется,
надо ждать выпуска полной NTFS.IFS и более, в общем-то, для общения с
Windows ничего и не надо.
Из FAT32 и NTFS выбор предпочтительней в пользу NTFS, потому
как для WinFS не нужна отдельная FS, она размещается на NTFS.
Для поддержки WinFS нужны скрипты для DB/2, Oracle, MySQL и пр.
чтоб вытаскивать то, что надо.
С MacOSX все общаются исключительно по TCPIP и подвижек,
чтобы это стало более необходимо, пока не видно. Будет
необходимо - будет написана.
В этом сезоне мы закончили большой проект - JFS для eComStation
(с возможность загрузки с JFS). Что скажешь пользователям
перед тем, как они полностью перейдут на JFS?
Только пожелаю удачи ;-) Вполне возможно что еще не все камни, тщательно
зарытые IBM, мы уже нашли, надеюсь что таки большую часть выволокли и
откатили в сторону. Все штатные ситуации и часть нештатных - пройдены. К
сожалению, JFS для eComStation получилась не совсем совместимой
в обратную сторону (то есть с eCS->IBM могут быть траблы).
Могу только сказать, если вы ее
поставите - не пожалеете. И скорость загрузки выше, и все системное,
загружаемое из системных каталогов, будет работать быстрее. Флеш-диски
сможете форматировать в JFS, и даже делать их загрузочными.
Как вообще проектируются файловые системы? Какая идеология заложена в JFS?
Общепризнанной теории построения файловых систем нет до сих пор. Кто как
может, так и строит. Можно разве что выделить общее.
JFS разрабатывалась исключительно самой IBM, и в тексте можно увидеть ссылки
на их собственные IBM-патенты. Кеш в JFS статический, указывается при
старте системы. Это минус. Эту проблему можно и нужно решить.
Кроме того что можно сделать динамическим, там есть
кеш статический. Занимает он не много, но он есть.
То есть о кеше можно говорить много и долго.
Пользователя обычно интересует "почему". Пока принцип только один "евреи,
не жалейте заварки" (c) анекдот. До 40 мб кеш в JFS - это не кеш. Имеет
смысл увеличивать до 128, если много памяти. Дальше уже надо
анализировать работу кэша. Вот тут уже начинаются проблемы.
Можно наблюдать около 20
показателей работы кеша, а вот их взаимозависимость в реальной работе не
знает никто, даже IBM. То есть надо делать программы для анализа кэша.
Первый шаг уже сделан.
Вокруг много разработчиков, которые начинают писать свои
программы/драйверы, но бросают свой проект. Твоя формула успеха?
Формула простая: у меня нет состояния "не могу". Есть состояние "можно"
(делается) или "нельзя _сейчас_" (в данном случае подробно исследуется
почему нельзя сейчас).
Попробуй программу:
|
Virtual keyboard - экранная виртуальная клавиатура (для сенсорных экранов, для ввода спец.символов).
|
Комментарии: Fomalhaut 2005-09-02 13:03:34 | А последнюю загрузочную версию JFS откуда можно скачать? | Стрельников Владимир 2005-09-22 09:20:53 | Действительно - все красиво описано, но я как купивший и eCS1.1R и eCS1.2R нигде не могу найти ваш JFS - хотя очень интересно потестировать и если будет удачно работать с ней.
И можно ли ввести в JFS некий режим совместимости c unix-like namespace - а то обратный мягко говоря не совсем удобен. Например в виде версий или суффикса для оси если имена ей кажутся одинаковыми. | Ольга 2009-04-25 09:07:50 | Вы помните Гурееву Ольгу? |
Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).
|
Системные требования у eComStation низкие. Работает на нетбуках, на старых Pentium. (Конечно же работает на 2-х и 8-и ядерных компьютерах). Что нового в eCS 2.0? |
|
|