Re: [mdk-re] [JT] ÌÉÎÕËÓ,×ÉÎÄÙ - Ï ÄÉÚÁÊÎÅ

[Serge Skorokhodov <suralis-s@mtu-net.ru>]

Здравствуйте!

<skip>

SS>> Первое. Ядро, базовые системные сервисы -- это а)довольно
SS>> низкий уровень, б)очень хорошо ложится на университетскую
SS>> науку и, как следствие в)прекрасно разрабатывается именно
SS>> программистами (в смысле software engineer).

MO> Совершенно верно. Может быть, стоит несколько... хм...
MO> расширить университетскую науку, как базу для FS-разработок?

Консенсус приятен:) Но вот как это сделать на практике...

<skip>

SS>> Так вот, проблема в том, что все эти наработки рассчитаны на
SS>> "платформу", существенно отличную от OS/FS.

MO> Я не понимаю, что такое "платформа OS/SF".

Это просто метафора:) Для того, чтобы потом ввинтить "перенос на
платформу":)

SS>> Второе. Проектирование интенсивно интерактивных приложений
SS>> (типа графического редактора, текстового процессора,
SS>> рабочего места врача-электрокардиографиста, в
SS>> противоположность приложениям интерактивно-транзакционным --
SS>> по типу рабочего места кассира, телефонного оператора,
SS>> медсестры, снимающей одну электрокардиограмму за другой
SS>> присылаемым в кабинет пациентам и т.д. -- я просто не знаю,
SS>> как лучше сказать, но надеюсь, что идея ясна) во многом
SS>> завязано на том, что кто-то (один человек или достаточно
SS>> узкая группа) "получат в голове(ах) решение проблемы", прямо
SS>> как решение математической задачи. Я имею в виду, что
SS>> он(они) "увидят" готовую программу, увидят, как пользователь
SS>> будет на ней работать и решать задачи. Это видение (в
SS>> предельных случаях -- евангелизм) затем подчиняет себе весь
SS>> проект. Кстати, в литературе подробное описание этой
SS>> технологии мне не попадалось:( Реализация такого видения в
SS>> коде требует огромного объема черновой работы программистов
SS>> и (обычно) привлечения кодировщиков.

MO> Естественно, причем вне всякой связи с моделью лицензирования
MO> (FS/собственнической) или моделью разработки (OSS/разработка
MO> узкой группой). И не ограничено указанным классом программ.

И тут консенсус:)

SS>> В моем опыте при этом приходится очень сильно бороться с
SS>> оппозицией сильных программистов-профессионалов, поскольку
SS>> тяжелая и нудная работа по реализации чужих идей,
SS>> выискиванию ошибок в этой реализации и т.д. не слишком
SS>> увлекательное занятие:( И я, к моему сожалению, не вижу
SS>> того, как это может в полной мере быть реализовано в OS/FS:(
SS>> Поскольку требует "негров", которые должны "работать и
SS>> работать" просто потому, что "солнце еще высоко":(

MO> Аргументация понятна, но она не вполне согласуется с
MO> наблюдаемой эмпирикой. Смотрите: "грязной и черной" работы
MO> больше всего в разработке универсальной ОС, поскольку 90%
MO> кода - драйверы, и код специфичен для конкретного железа.
MO> Теперь смотрите на Linux и спектр поддерживаемых устройств.
MO> Прикольно, но факт...

Вы знаете, мне приходилось сталкиваться и с разработкой драйверов
(именно сталкиваться, не разрабатывать:), и с разработкой
пользовательского интерфейса. В последнем случае все же работа
более "черная" и ее больше (IMHO). По моим наблюдениям, группы
единомышленников слишком часто не выдерживают и проекты
"рассыпаются":( А за деньги получается при приемлемом качестве за
приемлемое время:( "Пафос" моего словоблудства состоит, в
частности, в том, что я не чувствую в OSS/FS готовности community
пойти на такое "массовое самопожертвование и массовый героизм". А
это может оказаться критичным для выживания:(

SS>> Исключения единичны (например -- GIMP), да и то, если
SS>> честно, то до photoshop'а/illustrator'а и fractal design
SS>> painter'а ему есть куда расти:)

MO> GIMP стоит исследовать отдельно. Смотрите: "ядерная"
MO> разработка выполнена очень небольшой группой людей. Его
MO> прелесть и причина популярности - в расширяемости, и в
MO> наличие огромного количества плагинов. Плагин же может
MO> написать не программист, а специалист по цифровой обработки
MO> изображений, поскольку все они знают ЛИСП (и, соответственно,
MO> могут писать на Схеме). То есть, исходный дизайнер дает рамки
MO> для осуществления безумных фантазий не своим коллегам, а
MO> смежникам, и если он "попадает", начинает скатываться снежный
MO> ком.

MO> Это несколько более сложная схема, чем описанный Рэймондом
MO> более или менее гомогенный "базар".

И тут консенсус:) Хотя остается критичная с точки зрения
"производительности" художника разница в производительности
плагинов на Схеме и плагинов, написанных на С с применением MMX2
и SSI. Простите за невольный каламбур:) Хотя это, наверное, дело
наживное. Но тут я вижу еще одну "болевую точку": пока "дело
наживется" жизнь часто уходит сильно вперед. В результате ресурсы
потрачены, но приходится сталкиваться с аргументом типа "Linux
прекрасно оживит ваш старый компьтер":( Вообще, я что-то
уболтался:) Но душа почему-то болит, а тучи сгущаются...

-- 
Serge Skorokhodov aka suralis
02.11.2001 suralis-s@mtu-net.ru

ЗЫ. "Жизнь вынуждает человека совершать множество добровольных
поступков"

Е. Лец