Board.KolibriOS.org

Давно размышляю над несколькими вроде бы совсем не связанными друг с другом вопросами:

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

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

3) как коммерциализировать опенсорс-проект, не меняя лицензии и не закрывая код?

4) как заинтересовать серьезных профессионалов (элекронщиков, системотехников, системных программистов - только не хабрапиплов), наглядно продемонстрировать им уникальность и мощь Колибри ?

Чем дольше я над этим думал, тем чётче понимал, что все это надо как-то решать в едином комплексе. Но как?

И вот только сейчас всё сошлось в одну точку.

Вроде по русски написал, но ни хрена не понятно.

Для разминки: почему MS-DOS, Менуэт и Колибри такие маленькие и шустрые?
Да потому что они летают на однотипном и стандартном железе а-ля "IBM PC/AT" образца одна тысяча девятьсот восемьдесят забытого года, совместимость с которым до сих пор сохраняется во всех PC-платформах.

Винда - она (в 1-ю очередь) потому рыхлая и тормознутая, что позиционируется как OS Number One для всех бесчисленных PC-подобных платформ, из-за чего не может жить без HAL и не может не опираться на вертикаль власти драйверов.

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

Mario wrote:Вроде по русски написал, но ни хрена не понятно.

разжевываю:

1) в развитии ядра Колибри уже много лет нет никаких прорывов. Возможно, когда-нибудь починят краны кто-нибудь сделает полноценный ACPI, SATA и даже USB. Вопрос: какой ценой, и на что это будет похоже?

2) в драйверостроении все гораздо хуже чем в ядре. И яркого света в конце туннеля уже давно никто не ждет.

3 и 4) интерес к системе у спецов есть, и очень неслабый. Но как только узнают про GPL - сразу разговор переходит из практической плоскости в чисто умозрительную. Потому что все понимают, что для внедрения/доводки такой системы в конкретной встроенке нужны десятки-сотни килобаксов инвестиций. Ну и кому оно надо, если открытый код нельзя закрыть?

В Колибри-А разве была не та же философия? За исключением лицензии.

Доводы ясны, и какие выводы? Будет писаться альтернативная система? (Мейби Колибри-ОС совместимая.)

Leency
А-версия разрабатывалась (и продолжает разрабатываться) под конкретное железо АМД. Настолько конкретное, что похоже ни у кого больше такого железа нет.

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

Теперь - собственно насчет решения.

art_zh, извини, но дело того - плохо...,
ведь так и хочется спросить: "ты дружище ниче не выпивал не курил? Ну бывают в жизни черные дни, прорывает, нужно излить, что наболело типа". Тока без обид.
Тут вроде к ночи, а тут такое увидеть, а и не знаю теперь баиньки идти и завтра прочитать, или не спать часов несколько...
Ну замутил ты мутное и на мутном замесе, может начнешь говорить что тебя "подвигло" к этому.
Что то обычно случается в таком случае, чтобы чакры разверзлись и мысль с космоса пришла и ясно стало все или почти.
Одному яблоко говорят упало, вот...
Постичь как то не получается, ну как минимум сразу стержень темы. Фу-у-у-ух!

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

art_zh wrote:Но как только узнают про GPL - сразу разговор переходит из практической плоскости в чисто умозрительную. Потому что все понимают, что для внедрения/доводки такой системы в конкретной встроенке нужны десятки-сотни килобаксов инвестиций. Ну и кому оно надо, если открытый код нельзя закрыть?

Т.е. вся тема ради "GPL - зло!" ?
Лично я весь свой код выкладываю под BSD подобной лицензией. Занимаюсь я Колибри исключительно из личного интереса (хобби). Прямых доходов она мне не принесла и вряд ли принесет когда либо. Только косвенный доход - знания и опыт.

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

Вообще выбранная стратегия позволила существовать проекту с 2004 года. У нас нет диктата одного лидера (менеджера), но развитие идет. Многие перспективные проекты за это время тупо загнулись и пропали. Где 3OS? Где бурно обсуждавшийся UzhOS? Отвалились куда то в небытие.

В общем нельзя просто взять и закрыть исходники под GPL - это будет аморально.

Нужна новая стандартная аппаратная база.

Стандартная - для ядра Колибри.
Старая (Legacy hardware PC/AT) изначально воспринимается и поддерживается ядром, потому что реально существует на всех PC-платформах.

Идет 12-й год 21-го века, возьми любой самый дешевый и относительно новый чипсет - все контроллеры в нативном режиме будет работают в 10 раз быстрее и в 1000 мощнее, чем в режиме эмуляции Legacy Hardware. Ну так и давайте возьмем один какой-нибудь дешевенький южный мост и сделаем его стандартом КОС.

Что, у Вас такого чипа нет? Ну тогда покупайте готовую плату (вот вам и коммерциализация).

art_zh wrote:Идет 12-й год 21-го века, возьми любой самый дешевый и относительно новый чипсет - все контроллеры в нативном режиме будет работают в 10 раз быстрее и в 1000 мощнее, чем в режиме эмуляции Legacy Hardware. Ну так и давайте возьмем один какой-нибудь дешевенький южный мост и сделаем его стандартом КОС.

Сейчас скажу одну вещь - наверное ты ее знаешь.

Интел разрабатывает новую модель процессора, настраивают линию, запускают серию с некоторым запасом. К моменту завершения производства уже готовы документы на следующую модель процессора. Все! Больше эта модель не производится никогда!

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

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

VaStaNi
Да нет, ничего я сегодня не пил и не употреблял, постарайтесь понять меня совершенно серьезно.

Mario
мне тоже не нравятся рвачи и халявщики.
Пусть раскошеливаются - GPL им не поможет (ниже объясню почему).

Насчет аппаратных скачек - серию старых чипов (5-10 летней давности) всегда можно заказать у производителя. Будет спрос - появится и предложение. Главное, чтобы у нас выбранная платформа стабильно и полноценно поддерживалась ядром и драйверами.

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

Однако совсем уж "какой угодно" Южный мост не пойдет. У Intel мосты связаны специфичной системной шиной, у VIA - шина тоже своя особенная. Про NVidiю ничего не знаю (и очень боюсь, что никогда так и не узнаю).

А вот у AMD мостики - то что надо! И привязаны они к Северному мосту самой что ни на есть заурядной и стандартной шиной x4 PCIe.

Повторюсь: стандартной шиной PCI Express.

У Вас, Коллега, материнка какого года выпуска? Свободный слот PCIe имеется? Если да - приобретайте карту аппаратного ускорителя Колибри-В (литера "В" - от слова "board").

Если нет - уповайте на поддержку устройств PC/AT и ждите новых драйверов.

Южные мосты AMD SB700/710/750 хорошо документированы, дешевы ($20 новьё или $10 б/у) и надежны - есть даже материнки, где они ставятся как Second Southbridge, латая глюки контроллеров NV.
После долгих поисков приличного и недорогого контроллера для новой PCIe-карты я пришел к выводу, что самый оптимальный вариант - впаять чип SB710 вместо крутейшего FPGA или специализированного контроллера. Дёшево и сердито.

Но все-таки одного только ЮМ недостаточно. Нужны
- логика контроллера внутренней шины, 2D видеопроцессор, контроллер DMA и кое-что еще (всё на одном простом FPGA, $15);
- фреймбуфер (64MB - меньше уже не купишь - $10);
- 3-канальный ЦАП для VGA ($7);
- SPI ROM - 4Mb для хранения микрокода FPGA и еще 16Mb для бездисковой загрузки рамдиска ($1);
- разъёмы и панельки: 4хSATA, 2хUSB, 1хVGA, 2хDIP8 ($5 всё вместе);
- стабилизаторы низковольтных напряжений для FPGA,PCIe, SB, VGA и DDR2 ($20);
- сама печатная плата ($10),
- плюс мелочевка.

ИТОГО: вписываемся в $100, даже можно ещё и на HDAudio раскошелиться.

На самом деле идея здравая, можно будет продавать онлайн с сайта. Сразу с предустановленной КолибриОС и т.д. Однако! Следует помнить, что это больше long-term goal. Потому как надо, минимум:
1) Спроектировать железо
2) Выпустить несколько прототипов, погонять их и их использовать для написания драйверов/отладки
3) Написание драйверов
4) Выпуск в серию.
Но перед тем, как перейти к этим этапам, или паралельно с ними надо подумать какого функционала в системе не хватает, что можно исправить, на что можно забить.
Вот моё видение.

Нужно не 4 SATA, а максимум сколько можно...и делать NASы...они сейчас довольно таки востребованы, из-за дешевизны дисков...будут расходиться как горячии пирожки...особенно если Колибри-Б зашить в биос...ну вообщем такого продукта на рынке ещё нет...

С обновлениями канеш заморочки будут...надо что-то типа трипли биоса организовывать...1 запасной, один основной, а через ещё один прошивку организовывать...