Page 1 of 5

Проект Колибри

Posted: Thu Mar 15, 2007 11:42 pm
by connect
Переписывание ядра это, по моему мнению, отличный момент, чтобы
разработать и внедрить комплексный подход к развитию проекта Колибри.
Без сомнения, проект от этого приобретет более зрелый вид и это позволит
избежать некоторых граблей, случаи наступания на которые другими
командами разработчиков уже известны. С другой стороны, я уверен, вы
заинтересованы в появлении новых разработчиков, тестеров и, наконец,
польсователей.

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

1. Что такое Колибри?

Колибри это Операционная Система, написанная на Ассемблере. Факт?
Факт. Но в этом она не уникальна. Она обладает определенным набором
характеристик. Что-то есть, что-то не доделано. А дальше что? И
задавшись этим вопростом, некоторые поймут, что не обладают видением
будущего проекта. Разработка ведется хаотически. Понятно, что при
сравнительно небольшом количестве разработчиков, есть желание сказать
"делайте, что хотите, лишь бы что-то делалось". Но даже приближенная
оценка ситуации текущей и планы на будущее позволят скоординировать
разработку, показать, что действительно сейчас важно написать и какая
работа одного программиста может пригодится другому. Если вы не против
такого удобства, давайте двигаться дальше.

2. Что такое Колибри?

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

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

Колибри это:

а) Учебная среда. Ах этот дух низкоуровнего программирования. У многих
программистов возникает желание попробовать свои силы в разработке ОС.
Колибри может быть предоставлен как живой пример для программ изучения
Ассемблера. Но почему именно Ассемблер? Прикладные программы вполне
могут быть написаны на других языках.

б) Мобильная ОС. Довольно популярными стали так называемые Live OS,
работающие с CD,DVD,Flash. И тут Колибри может смело заявить о своих
преимуществах, имея максимально компактные приложения. Есть
возможность спроектировать защиту на более низком уровне, что сделает
Колибри более надежной средой обитания.

в) Сервер. Колибри может стать сервером (ftp,http,route) с наименьшими
системными требования относительно удобства работы. Как и линуксовым
однодискетным операционкам, Колибри не нужен жесткий диск, но
преимущества перед ними у вас куда более впечатляющие.

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


3. Ограничения

Когда вы будете определяться с концепцией Колибри, не стесняйте свое
воображение. Но на следующем этапе вам придется трезво просмотреть все
перечисленные вами пункты. Далее прибегну к цитированию методологии
MSF:

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

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

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

Немаловажным моментом является еще и то, что прежде всего необходимо
обеспечить минимальную функциональность. Оформление и возможность
дополнительных настроек идут на втором плане. Это касается как ядра,
так и каждой программы. Но хорошо бы продумать и оставить, если это
возможно, задатки под будущие изменения. А когда и этот этап останется
позади, многое встанет на свои места. Разработчики GUI смогут
договориться с разработчиками ядра, а разработчики программ с кодерами
GUI. Понятно, что стоит делать сейчас, а что отложить на потом. Все
счастливы.


4. Люди

Дальнейший текс уже будет адресован не столько к нипосредственным
разработчикам, сколько к руководителю или человеку по связям, если
такие имеются )

Определившись с концепцией Колибри, вы поймете, какова будет ваша
целевая аудитория и как с ней работать. А это важно знать, чтобы
понять как заинтересовать и привлечь к себе дополнительные руки. Да и
я уверен, никто не против, чтобы про Колибри узнали многие, верно?
Мало того, нужно, чтобы у них еще и сложилось благоприятное мнение,
т.к. от него зависит число тех, кто реально захочет помочь. В
принципе, относительно вашего проекта люди будут делиться на
заинтересованных, незаинтересованных и отрицательно настроенных.
Поговорим про первых.

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

О документации подробнее немножко. Некоторые ее недооценивают и не
уделяют достаточного внимания, хотя именно документация помогает
избежать многократного появления одних и тех же вопросов. Не исключит
их, конечно, но уменьшит - бесспорно. Как документация составляется?
Либо одним человеком по продукту другого, либо самим автором. Первый
вариан требует детального знания, второй замедляет разработку. Поэтому
я предлагаю вам третий способ, на который я натолкнулся при изучении
.NET. В коде самой программы по ходу ее разработки ставятся
комментарии, уверен, многие уже взяли это за правило. Но некоторые из
таких комментариев должны стать обязательными для образцовой программы
Колибри. Эти особые коментарии, которые помечены маркерами, при
последующей обработке исходника другой программой, могут помочь в
формировании хэлпового файла. Образцом может стать man из юниксовой
среды. Т.е. программа будет строить автоматические хэлп файлы
нипосредственно по исходникам программ и тромбовать где-то у себя или
же в каталогах исходных кодов.

5. Sense & Look

Внешний вид и "дух" Колибри, это еще одно направление для развития.
Место, где развернуться художникам рука об руку с разработчиками GUI.
У Колибри, как и любого другого уважающего себя программного продукта
должен быть свой стиль. Хорошо, если это будет модно и свежо. Моим
видением "духа" Колибри являются три слова:

Живой Легкий Быстрый

Представьте настоящую живую колибри. Она маленькая, юркая, постоянно в
движении. Стекло. Сейчас очень популярен эффект цветного стекла, на
это можно сделать ставку. Не буду вас учить как рисовать GUI, но
дизайнерам очень понравится ОС, в которой можно легко менять внешний
вид окон и контролзов. Все, что я говорил в разделе 5 также касается и
сайта. Сайт должен быть красивым. Я бы даже сказал обязан. Практика
показывает, что от обертки иной раз зависит даже больше, чем от
начинки. Начинку поймешь, только когда попробуешь, а вот, чтобы
человек взял попробовать, нужна привлекательная обертка.

6. Заключение

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

Я приглашаю к дискуссии.

Posted: Fri Mar 16, 2007 8:24 am
by Mario79
Для начала нужно определиться - отделяем GUI от ядра или нет. Если отделяем, то нужно продумать максимально скоростной способ взаимодействия с GUI.
ИМХО Linux не самый лучший пример взаимодействия GUI и ядра.

Posted: Fri Mar 16, 2007 10:42 am
by <Lrz>
Мне видится такой вариант:
GUI Находится отдельно от ядра, подключается если оно необходимо. Скажем, если из КООС захотели сделать сервер, зачем тогда в коде присутствует графическая часть, если она будет не востребована?
Это касается и всего остального. Мне видится Коос как конструктор, каждый может собрать из "деталей" ту систему, которая ему нужна.

Posted: Fri Mar 16, 2007 11:32 am
by YELLOW
Я согласен, что GUI надо отделять от ядра. И насчет Linux тоже. GUI действительно не всем и не всегда нужен. Как способ взаимодействия GUI с другими компонентами мне на ум ничего кроме системы сообщений не приходит, :) хотя и ее можно сделать достаточно быстрой. Можно, например, сделать 2 очереди сообщений: одну для ядра и драйверов, а другую для пользовательких программ и обрабатывать пользовательскую очередь, только если очередь ядра пуста.

Posted: Fri Mar 16, 2007 11:38 am
by Phantom-84
Я за отделение графической оболочки от ядра! GUI конечно должен встраиваться в ядро, но как независимый модуль (т.е. как минимум нужно обеспечить заменяемость GUI; сервис ядра и сервис GUI лучше разделить, например, "вешать их на разные int'ы"). Также желательно обеспечить связь графическая оболочка - сервер GUI, чтобы сервер весь вывод формировал в контексте соответствующей гр. оболочки, а также чтобы в перспективе одновременно можно было запускать сразу несколько графических оболочек, использующих различающиеся GUI. Это мой вариант, а использовать или не использовать его, решать вам!

Posted: Fri Mar 16, 2007 11:39 am
by connect
В других ветках уже поднимался более фундаментальный вопрос. Вопрос выбора между х32 и х64. Мне кажется, что перво-наперво стоит достичь единого понимания этого момента. Ищу статьи для анализа плюсов и минусов.

Posted: Fri Mar 16, 2007 11:44 am
by YELLOW
Я за х32. Пророчества о гибели 32х-битного режима -это конечно красиво, но далеко не каждый пользователь вот так бросит все и откажется от всего что написано для 32х-битных систем.

Posted: Fri Mar 16, 2007 12:01 pm
by Phantom-84
Все значительно проще... пока позволяет время, нужно совершенствовать то, в чем уже хорошо разбираешься, а не делать с нуля то, что с первого раза хорошо не сделаешь точно - кто готов меня в этом переубедить, пожалуйста! Me64 - очередной образец того, что магия числа 64 не спасает от кривизны архитектуру системы. Если будет хороша архитектура 32-разрядной системы, то ее можно и нужно будет перенести в 64-разрядную систему, в противном случае даже дергаться в эту сторону не стоит!

Posted: Fri Mar 16, 2007 12:49 pm
by YELLOW
Да будущее за 64х-битными многопроцессорными системами, но 32х-битная архитектура себя еще далеко не изжила. Тем более что 64х-битный код довольно сильно удлиняется за счет увеличения длины команд и операндов.

Posted: Fri Mar 16, 2007 12:50 pm
by connect
После перечитанного пришел к следующим выводам, это лишь выжимка без подробных комментариев:

х32
  • +
    • Уже есть работающие варианты Колибри.
      Архитектура хорошо документирована.
      Архитектура широко применяетя.
      Может работать на х64 процессорах.
      Может позиционироваться как ОС для слабых машин.
    -
    • Архитектура практически исчезнет через 3-5 лет.
х64
  • +
    • Большая потенциальная мощь.
      Будет актуальна еще долго.
    -
    • Такой объем мощьности ассемблеру не нужен.
      Станет повсеместна распространена только через года 3-4.
Плюсов больше у х32 варианта. Он же более рациональный.
Компромис: разработка х32 с оглядкой на последующий переход. Если проект проживет еще 3-4 года, можно будет взяться за новое ядро для реализации накопленного опыта. Если к тому времени команда разработчиков будет все еще мала - продолжать оставаться в качестве х32.

Posted: Fri Mar 16, 2007 12:56 pm
by YELLOW
connect wrote: -
Архитектура практически исчезнет через 3-5 лет.
Не факт, у меня вот в институте до сих пор используются компы уровня Pentium II. :) А им уж по-моему лет 10. Искал вот недавно драйвер на ISA сетевуху. :)

Posted: Fri Mar 16, 2007 1:05 pm
by connect
Я просмотрел периоды внедрения начиная с 4-битных процессоров, тенденция прослеживается.
Естественно в музее тоже можно увидеть динозавров, но, мне кажется, вы заинтересованы в более широком применении своего продукта.

Posted: Fri Mar 16, 2007 1:17 pm
by YELLOW
connect
Ладно, ладно. Убедил. :)

Posted: Fri Mar 16, 2007 2:50 pm
by VaStaNi
Мужики! Спокуха на счет 32битов, не надо так пророчески и про музей думать, могу массу ссылок дать, где куча фирм, бренды которых давно не пустой звук ВЫПУСКАЮТ платы для автоматизации предприятий, станков, роботов, космоса........
Иногда можете даже x386 там найти и их производят и покупают, т.к. тут важен копромисс себестоимость, необходимость, цена, совокупные затраты - итоговая прибыль от внедрения. Тут в составляющую себестоимость низбежно попадает оценка популятности и раскрутки пратформы x86 (а не маки, скажем...), процов к нему(тут гора скучкой и на все вкусы и пошибы и ТУ...) и... конечно ОС и дрова к нему, ее возможности, архитектура, временные параметры, НАДЕЖНОСТЬ/надёжность(!), поддержка проблем, лицензии их цена, правовые вещии коммурческого и пр. применения (налоги, права собственности и пр.) Вот ВАМ бегло, для ознакомления, если кто впервые... НЕ поленитесь поройтесь, почитайте, не пожалейте трафика, это ВАШ кругозор, мнение. Может глянете и продажи и планы фирм по...
Да, это не РС у кровати, но это тоже x86 32бита и ОС и Ethernet и RS-232 и RS-485...
Быть может кто то, "завтра", получит диплом и придет на работу где............
http://www.prompc.ru/cat.php?id=325
http://www.prosoft.ru/products/brands/fastwel/35inch/
http://www.prosoft.ru/products/brands/f ... icropccpu/
http://www.prosoft.ru/news/2006/263868.html
http://www.prosoft.ru/news/2005/239815.html
http://www.prosoft.ru/products/brands/f ... ompactpci/
http://www.prosoft.ru/news/2004/226172.html
Прочитали, посмотрели??? А теперь (особенно кто близок к железу, технике, радиоэлектронике, знаком с лимитами на объемы памяти, времени...жесткие ТУ...) поинтересуйтесь, поройтесь и найдите ответ себе самому на элементарный вопрос: "А какие ОСи продаются, комплектуются к ним, какова надежность ИХ, как на счет ибьёмов кода ОС, глюков, техногенных катастроф в конце концов...????"
Только заранее откройте пиво, отхлебните и желательно подождите немного, прежде чем читать перечень и...

Posted: Fri Mar 16, 2007 3:03 pm
by Mario79
VaStaNi
Такие фирмы обычно сами пишут ПО и операционные системы для своих плат. В основном эти ОС однозадачные типа DOS. Или вообще нету операционки - есть только одна рабочая программа.
Конечно, есть исключения, но это не показатель.
Как убедить этих товарищей, что сторонний софт производства Вася Пупкин (пусть даже бесплатный) лучше чем то, что наваяет их штатный инженер (которому они доверяют) за полгода?