Колибри для встроенных систем?

Using Kolibri in embedded systems
  • Serge, я уже боюсь у Вас и спрашивать :)
    Неужели все по прежнему ...

    Грубо говоря, у меня альтернативы:
    а) собирать свой драйвер sound-заглушку для честного трассирования событий в infinity
    б) следовать своему вышеизложенному плану, и заниматься исследованиями супер-хитрых и сверх-запутанных обработчиков IRQ

    Поскольку коды из event я уже наизусть знаю, мне даже и тестовый редактор для них не очень нужен ...
    Типа, идешь курить на балкон, и думаешь про себя: "а нафига в sys_sendwindowmsg нужна магическая комбинация pushfd/popfd..." :lol:
  • Не успел отписаться. Заработало.
  • Уффф :)

    Как разборка полетов (в качестве самокритики):
    1) Последняя ошибка - следствие тупого копипастинга (сколько раз зарекался, но лень берет свое) из 172-й строки. Такого добра и при "простом стиле" хватает. Если не не больше...
    2) А вот в RemoveEventTo - соглашусь, стремление к оптимизации. Правильно - сначала полноценно удалить из списка, а потов врезать в другой. Наоборот - оптимальнее, но в одном случае (когда "другой" совпадает с "первым") - гробят списки напрочь.
    Хотя, мог бы и сразу за это догадаться, а не под прессингом "все пропало, все на забор" :)

    P.S. А то, что я по-первости напрочь упустил использование EVENT в infinity - за это и говорить нечего... Надо было просто "остудить моск", и всего делов
  • Galkov wrote:А тестовый пример для проверки правильности показаний show_error_parameters при debug_exception и отсутствии самого отладчика - как-то сразу в голову и не приходит...
    Тестовый пример простой:

    Code: Select all

    pushf
    or byte[esp+1],1 ; set TF
    popf
    nop ; после выполнения этой команды возникнет #DB
    
    В 0.7.5.0 выводит не то, что ожидалось, так что бага определённо была. В последнем ядре выдача нормальная, так что, по крайней мере, стало лучше :) Исправления в коде ещё не смотрел.
    Ушёл к умным, знающим и культурным людям.
  • diamond wrote:Исправления в коде ещё не смотрел
    :D
    Serge был немного шокирован, мне показалось.
    И мне интересны и Ваши соображения, diamond, про "стиль", "понятность", и т.п..
    Можно даже сказать, что я взял паузу на самообразование (сигналы в posix), в ожидании Ваших соображений
  • Galkov wrote:И еще, я пока вообще плохо себе представляю как работет dosbox (речь о нем ???), средства v86 вроде никуда и не экспортируется....
    DOSBox - это полностью программная реализация эмулятора, без поддержки со стороны системы. В линейке WinNT (до Vista и если не учитывать x86-64), кстати, есть эмуляция dos-программ через v86-режим и работает она так криво, что лучше DOSBox :) Как-никак программы для DOS писались из расчёта на однозадачную среду и захватывают все ресурсы, что неприемлемо для многозадачной системы.
    V86 в данный момент используется только для вызова функций BIOS через int 13h (дисковая подсистема). В принципе можно ещё добавить переключение банков в VESA 1.2 через int 10h, но поскольку тестить не на чем...
    Ушёл к умным, знающим и культурным людям.
  • diamond wrote:DOSBox - это полностью программная реализация эмулятора, без поддержки со стороны системы
    Сдуреть можно :shock:

    diamond wrote:V86 в данный момент используется только для вызова функций BIOS через int 13h (дисковая подсистема). В принципе можно ещё добавить переключение банков в VESA 1.2 через int 10h, но поскольку тестить не на чем
    Про 13-е, это я уже догадался.
    Где-то здесь (где - не могу вспомнить) прочитал, что VESA 3.0 тоже через это дело идет... Тут вроде есть на чем тестировать.
  • Народ, у меня все-таки вопрос один без ответа остается.... :(

    Что означает фраза "Текущая реализация во время ожидания требует довольно "тяжёлых" операций переключения контекста" (это из описания f68:14) В чем "тяжесть-то" :?:
    Мне казалось, что это постоянное дергание CR3. Исходя из этого, и придумывал Wait_events

    Но возможно, что это не более, чем мои фантазии. Ибо опыта кодинга под 0-м кольцом аж никакого.
    ЕСЛИ :idea: я прав, то тогда надо думать и над другими "тяжелыми переключениями"
    Например, в debugger_notify придуманный фокус не спасает, потому-что там два переключения. Сначала shed переключает контекст, без знания нужно ли это, а потом еще и в тестируемый слот переключаемся, только для проверки готовности
    Подозреваю, что и в IPC примерно такая же история....
    Wait_events может спасти только от первого переключения.
    А от второго....
    Ну может перед ожиданием дополнительно замэпить пользовательскую страничку с "мьютексом" куда-нибудь в системную область, поместивши этот логический адрес в wait_param...
    Может вообще выделить это в отдельный функционал типа WaitUserMutex ....

    Ну и не очень получается думать про такое, без уверенности, что у меня правильное понимание происходящего :(
    Откройте глаза, насколько можете :!:
  • diamond wrote:А это уже никакие не "2.56 секунд", а потенциально сколь угодно долгий срок. Особенно если учесть, что ждать придётся вовсе не до выхода из функции, а именно пока работающая с диском прога не перестанет выдавать запросы к 70-й (58-й) функции (потому что вероятность того, что прерывание таймера, обработчик которого и занимается переключением процессов, придёт ровно в момент между вызовами функций, довольно мала. А на то, чтобы в момент освобождения мьютекса и выхода из функции вызвать планировщик немедленно, интеллектуальности у Колибри сейчас не хватает. А переделать это не так уж и тривиально).
    В принципе, мне уже понятно, как решать этот вопрос. В смысле - убрать "потенциально сколь угодно долгий срок".
    Ну по сложнее это будет несколько, чем сегодняшний wait_mutex... Который сегодня оптимизируется до 4-х команд проца (12 байт кода).
    Но ради вышеописанного, я готов наступить "на горло собственной песне"
    Плюс к этому, есть еще скользкий вопрос - чего будет, если кто-то убьет поток, захвативший сегодняшний mutex...

    Если коллеги посчитают таковое движение правильным, я могу предварительно описать "схему мероприятий", и, по согласии с этой "схемой" - сделать кодинг.
  • Galkov wrote:Если коллеги посчитают таковое движение правильным, я могу предварительно описать "схему мероприятий", и, по согласии с этой "схемой" - сделать кодинг.
    Колибри не имеет плана развития как такового, так что можно делать всё в разумных пределах (переписывание на "что-нибудь посложнее, чем сегодняшний wait_mutex" в эти пределы входит, а переписывание ядра на Си таки нет).

    Кто неправильно застегнул первую пуговицу, уже не застегнётся как следует. (c) Гёте
    Дисклеймер: все дальнейшие высказывания являются а) моим личным мнением и б) неконструктивной критикой, так что если вы не любите неконструктивную критику и полагаете, что дадите ответ в стиле "и что же ты предлагаешь", то не читайте - этим сэкономите и ваши, и мои нервы.
    Колибри в некоторой степени можно сравнить с деревянным домом. Дом неплохо смотрится снаружи и изнутри, внутри стоят столы, стулья, магнитофон, рация, на стенах висят картины, на видном месте лежат молоток, гвозди, пила, кисти, краски, прочие инструменты и инструкции по сбору своих стульев и картин. Дом достаточно прочный, сидя на стуле, можно смело чихать, не опасаясь того, что дом развалится. Жуков-древоточцев мало, и против них принимаются меры. Но если присмотреться, то обнаруживается куча странных вещей. Строители дома как такового умели держать в руках молоток и гвозди, но не карандаш и бумагу, так что чертежей постройки нет и никогда не было. В результате нет надёжного фундамента. Кое-где постройка держится на честном слове, если в определённых местах попрыгать, держа молоток под определённым углом, можно повиснуть в воздухе, а можно и развалить дом. Дом в принципе не предназначен для того, чтобы ходить по нему вдвоём - во-первых, шаги придётся делать строго по очереди, во-вторых, пока открывается журнал на почитать, магнитофон не может читать кассету, в-третьих, нет отдельных комнат, в которых можно было бы настроить всё под свой вкус, а вместо этого предлагается обустраивать весь дом, что будет видно любому гостю (и любой гость сможет всё переставить). Каждому объекту должна соответствовать картина. В доме есть место под 256 картин, большего количества быть не может, а если их меньше, то всё равно выделено 256 мест (причём первые два места специальные). Если нужно показать стул на двух картинах, то придётся отщеплять от него щепку и связывать картину с ней, и наоборот: если от стула отщепляется щепка, с ней связывается новая картина. Рация может связываться с разными адресатами, но даже если в доме ловится больше одной частоты, рация понимает только одну. Если рация настроена на приём, она не может принимать данные одновременно от нескольких адресатов. Рация не реагирует на приходящие волны, как можно было бы подумать, а с определёнными интервалами сканирует окружающее пространство, проверяя, не появилось ли новых данных (но сканирование может быть отложено, если в этот момент происходит много других дел). Средств для связи между разными объектами практически нет, максимум можно переложить журнал с одного стула или стола на другой (причём в процессе перекладывания журнала прочие действия останавливаются). Хотя открыта детальная схема сборки из брёвен и гвоздей, но разбираются в ней немногие, а никаких путеводителей по этой схеме (это, конечно, не схема небоскрёба, но всё равно весит довольно прилично) нет (чертежей, проясняющих, что вообще происходит, нет в принципе). Кое-где опорные брёвна положены откровенно криво (для опытного взгляда), кое-где забиты лишние гвозди. Временами делаются более или менее успешные попытки переложить часть досок так, чтобы они лежали более правильно, чаще дело ограничивается разговорами в стиле "а вот хорошо было бы, если кто-нибудь вот так вот переложил и добавил вот такие-то доски", инициируемых либо авторами картин, либо вообще сторонними посетителями, при том, что на стульях и картинах это либо вообще не сказывается, либо они чуть-чуть перекашиваются и их остаётся чуть-чуть поправить.
    Вернёмся от метафор к реальности.
    Почему до сих пор нет ATA48? Потому что это потребует значительных изменений в дисковой подсистеме и изменения всех вызовов hd_read, причём нетривиального изменения (вместо 32-битного входа понадобится 48-битный, а в один x86-регистр это уже не влезает).
    Почему до сих пор нет USB? Отвлечёмся от вопросов программирования железа, очевидцы говорят, что это само по себе нетривиально, но допустим, что драйвера USB-хостов уже есть. И что с ними можно сделать? На plug-and-play ядро изначально не было рассчитано. Поддержка USB-клавиатур упирается в то, что поддержка PS/2-клавиатур сидит довольно глубоко в ядре и просто так ядро новую клавиатуру не поймёт, а потребуются ещё некоторые усилия по адаптации. Поддержка USB-флешек упирается в ту же дисковую подсистему, которая, например, совершенно не рассчитана на динамическое подключение/отключение устройств. Поддержка USB-флопповодов - снова дисковая подсистема, в которой поддержка дискет совершенно автономна от жёстких дисков. Только с мышами особых проблем не предвидится, в основном потому, что мыши бывают разные (не только PS/2, но и COM) и строители дома... эээ, разработчики ядра в некоторый момент позаботились о том, чтобы ядро могло принимать сигналы от разных драйверов мышей. О USB-модемах и USB-принтерах я вообще молчу.
    Почему до сих пор нет поддержки нескольких процессоров (или нескольких ядер одного процессора)? Потому что ядро изначально рассчитано на один процессор, и изменение всех мест, где играет роль многопроцессорность, да ещё и без ошибок, нереально.
    Почему до сих пор нет (подставить нужное), хотя, казалось бы, на свете довольно много программистов, которые могли бы это реализовать, и даже довольно много из них знают про Колибри? Почему новые ядерщики появляются очень редко (что старые иногда уходят - неизбежно, а в результате баланс получается отрицательным)? Тут может быть много причин, но одна из главных (про дисклеймер всё ещё помним, да?) - отсутствие внятной документации. Выкачав репозиторий (или скачав исходники дистра и выбрав оттуда исходники ядра), потенциальный ядерщик оказывается наедине с метром-другим ассемблерных исходников без общего плана происходящего, без путеводителя по исходникам и без малейших намёков, что в каком файле находится и как друг с другом связано. Разумеется, при большом желании и большом терпении во всём этом можно разобраться. Вот только количество людей, которые не плюнут, узрев подобное состояние вещей, значительно меньше количества людей, скачавших исходники и потенциально заинтересованных.
    В принципе я могу написать общий план происходящего, путеводитель и намёки, вот только мне этот общий план не нравится, ибо там ситуацию в слишком многих случаях описывают фразы типа "вот это реализовано вот так вот, очевидно, что это можно сделать лучше, но сделали так, ибо строили без чертежей", поэтому плана и не будет. Собственно, история уже знает подобную попытку Андрея Халявина (http://shade.msu.ru/~msu-se/help/help.rar, многое устарело), и закончилась она тем, что Халявин понял, что так дальше жить нельзя, и ушёл переписывать ядро.
    Я не верю, что последовательными локальными улучшениями можно преобразовать существующее ядро в нормальное. Хотя бы потому, что чертежи с потолка не свалятся. Но я в данный момент не готов взять и создать план глобальных улучшений, ибо он слишком глобален и над ним надо работать и работать.

    С приложениями ситуация намного лучше, чем с ядром, и возможности существующих API далеко не исчерпаны. Но и тут видны проблемы - с GUI и с сетью. Концепция "каждому потоку по окну" вызывает кучу проблем - во-первых, нужно создавать новый поток на каждый чих, во-вторых, сколько-нибудь сложный интерфейс создать таким образом практически невозможно - фактически для этого приложение должно содержать самостоятельный менеджер окон для дочерних элементов; меню как отдельное окно должно создаваться в отдельном потоке, что тут же порождает массу проблем, а меню как картинка внутри существующего окна порождает не меньше проблем со взаимодействием с другими элементами окна (да ещё и ограничено размерами окна). Сеть поддерживает только одну сетевую карту (даже если на компе есть больше одной), только IPv4 (на уровне API), приложение-сервер не может одновременно работать с несколькими клиентами, приложение-клиент даже не может надёжно открыть соединение (оно должно сначала найти свободный локальный порт и потом его указать при открытии сокета; а что, если между первым и вторым действием вклинится другое приложение, которое найдёт тот же свободный локальный порт и откроет сокет с ним?).
    Ушёл к умным, знающим и культурным людям.
  • 1. Ну, Америку ты не открыл.
    2. И какой смысл этого эссе? На сайте у себя уже написал все по делу, а тут демагогия.
    3. ОС мертва для дальнейшего развития.
    4. Возможно я бы и принял участие в альтернативном проекте, но он не должен быть хобби ОС - мне уже почти 30 и интересы уже скорректированы.
    5. Те кто появляются раз в 1 месяц, раз в 3 месяца, раз в полгода, раз в год, теперь должны успокоиться или максимум напишут - "ну, я же вам говорил".
    6. Сайт и форум имеет смысл закрыть, SVN можно использовать для других проектов. Мне до сих пор удивительно какими альтруистскими соображениями руководствуется Михаил оплачивая из своего кармана все ресурсы.
    7. Исходники своего последнего проекта все равно открывать не буду, ибо незачем.
    8. Три поросенка все читали.

    З.Ы. Разумеется все написанное мое личное мнение, никому не навязываю и аналогично Даймонду прошу не верещать "Сволочи! Они убили Кенни!"
  • diamond wrote:Дисклеймер: .......
    а) Согласен
    б) Присоединяюсь
    в) Поэтому прошу считать и мои нижеследующие мысли, нарисованными под аналогичным дисклеймером :)


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

    Ну хорошо, вот вижу я лежащее бревно, и подумалось мне, что оно лежит криво..
    И что :?: А ничего. Так и продолжаю думать, не более.
    Почему :?: А потому-что не знаю, что об этом думают коллеги, а мой опыт с несравним с Вашим.
    А коллеги молчат, потому видимо, что "нет плана"....
    А может, и принято в команде так, что если сказано, то подлежит исполнению именно сказавшим....
    А может опасаются оказаться не до конца правым...
    Не знаю, в общем, почему, но точно знаю -- что это не очень нормально.
    Да фиг с ним с планом, если есть конкретный вопрос, и задается он вовсе не по причине "потребовать правильного исполнения"
    Говорю же, например: поделитесь мыслями, а кодинг за мной. Естественно, с творческой переработкой мыслей, и без гарантий, что все не будет совсем наоборот - у меня же тоже мысли какие-то есть.

    Ну хорошо, какими нервами должен обладать некий "новичок", чтобы выдержать аналогичную "систему советования" ???
    Ответ: стальными, уверяю Вас
    Влияет это на вышеупомянутый "баланс" ??? Думаю - да.

    Мне совершенно понятно, что некоторые "перекладывания бревен" так встряхнут систему, что с полгода только глюки ловить будем, вспоминая автора тряски незлым тихим словом.
    Ну например, можно помечтать об объединении всех данных потока в единую структуру данных (а не в три), а массив этих структур сделать динамическим.
    А то ведь достала уже эта славная троица - CURRENT_TASK, TASK_BASE, current_slot (в глаза бы посмотреть еще тому, кто такие имена-то придумал)

    В одиночку пытаться делать такое - не понимать реальности.... Сегодня для меня это равносильно - застрелиться. А если только с теми кодами, что я уже "зацепил" - легко. Беда только в том, что их пока лишь малый процент.
    Между прочим, diamond, такие глупые мысли у меня возникли именно после Вашего пожелания не иметь ограничений на количество слотов...
    Вы же -- ну ничего не пояснили :!: Ну и пытался "просчитать" чужой ход мыслей. Кстати говоря, и в таком случае можно "упаковать" номер слота в TID.
    Почему не написал как? Да потому-что беседа - это вещь обоюдная же. Мне тоже не очень нравится театр одного актера.

    Вы поймите разницу: если я взял некий код, и сделал его в полтора раза быстрее и/или короче - то правильность этого действа логически разрешима. Если не меняется функциональность.
    Тут можно, наверное, поиграться в "молчаливую анархию"

    А вот тот же "мьютекс" - кодов станет больше. Насколько - ну я постараюсь чтобы не намного, но не делается такая работа с "отрицательным изменением размера результирующего кода"
    Зачем: ожидание методом перевода слота в 5-ю позицию + систематизация порядка переключений при захвате + корректный деструктор
    Пока мне кажется, что цель достойна затрат. После обмена мнений с коллегами, это мое мнение может и измениться. Не факт, что изменится, но - МОЖЕТ. Особенно, если мое понимание чего-то сегодня не является правильным - то же ведь, запросто....

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

    Но это же все установка новых бревен, с выдергиванием старых гвоздиков.
    Причем, с ненулевыми затратами: взведение какого-то флажка в dword-е - попроще будет, чем притуление динамического объекта типа EVENT. Даже, если для последнего уже почти все сделано.
    Вот и вопрос: как мне узнать, что это "новое бревно" не стукнет по голове коллегу, который укрепляет другую подпорку гвоздями.
    А может и электросваркой...
    Если мы молчим, потому-что у нас "нет плана" :(


    ======================================================
    Про справку: это очень большая работа...
    Если сразу и целиком.
    Может написать некую рыбу (как минимум - содержание), целиком (ну или почти) состоящую из белых пятен
    Вопросы, типа "как это устроено", таки возникают на форуме...
    Мне показалось. Ну может не так явно....
    Ну и отвечать на них (на форуме) так, чтобы ответ можно было в "справку" поместить. Или наоборот: поместить нечто в справку, и сослаться на нее на форуме... Без фанатизма, естественно.
    В чем-то и я потихоньку разбираюсь... Разобрался, посмотрел - белое пятно, почему-бы и не добавить. Как минимум, у меня есть маленькое преимущество - глаз еще не замылен. Если не прав - коллеги меня поправили бы... Если это было бы, например, на SVN.
    Не поправили - у меня (к примеру) появилось воодушевление, что это все не плод моего разгоряченного ума, а совпадает с пониманием коллег.

    Ну это так... Мысли вслух.


    ======================================================
    diamond, давно хотел сказать, что я вижу, как ты правишь мое недомыслие. В смысле, хотел сказать - спасибо. Одна неясность у меня осталась про vm86, но это -- позже
  • Galkov wrote:Но все-таки, отсутствие четкого плана, и то, чего я могу сегодня охарактеризовать как "молчаливую анархию" - это разные вещи.
    Мне даже кажется, что очень разные. Возможно настолько, что серьезно влияет на "баланс притока разработчиков"
    Угу, разные факторы и проявляются на разных этапах разработки. Я про то, что нет документации и потенциальный ядерщик забивает на систему, вообще не доходя до размышлений "как бы это поменять и что по этому поводу думают остальные".
    Galkov wrote:Ну хорошо, вот вижу я лежащее бревно, и подумалось мне, что оно лежит криво..
    Универсальный ответ: перекладывай. Коллеги наверняка тоже думают, что оно лежит криво, но сами не исправляют по ряду возможных причин. Собственно, сейчас ситуация такая, что можно перекладывать, если для этого есть разумные обоснования и даже если коллеги против.
    Galkov wrote:Говорю же, например: поделитесь мыслями, а кодинг за мной.
    Мысли разные бывают. Общих мыслей на форуме очень много, например, хорошо бы добавить поддержку многопроцессорности и сделать списки потоков и процессов динамическими. Но они напрямую непригодны для кодинга. А чертежи для кодинга нужно долго и упорно чертить, продумывая, какие поля должны быть в структуре потока, какие в структуре процесса, где должны быть блокировки, какие должны быть блокировки на многопроцессорных системах, как организовать файловую систему и т.д., и т.п. И всё это нетривиально. Главное в программировании - именно мысли, а не кодинг.
    Galkov wrote:Ну хорошо, какими нервами должен обладать некий "новичок", чтобы выдержать аналогичную "систему советования" ???
    Обычными, если не станет ждать советов по тому, что надо закодить, а будет сам думать.
    Galkov wrote:Мне совершенно понятно, что некоторые "перекладывания бревен" так встряхнут систему, что с полгода только глюки ловить будем, вспоминая автора тряски незлым тихим словом.
    Не страшно, что перекладывания перетряхнут систему. Проблема, что они могут не помочь.
    Galkov wrote:Ну например, можно помечтать об объединении всех данных потока в единую структуру данных (а не в три), а массив этих структур сделать динамическим.
    Пожалуйста.
    Galkov wrote:А то ведь достала уже эта славная троица - CURRENT_TASK, TASK_BASE, current_slot (в глаза бы посмотреть еще тому, кто такие имена-то придумал)
    А имена-то чем не устраивают? Вполне информативные.
    Galkov wrote:Вы же -- ну ничего не пояснили Ну и пытался "просчитать" чужой ход мыслей.
    Потому что общую мысль высказал, а детализации, пригодной для кодинга, у меня просто нет.
    Galkov wrote:Пока мне кажется, что цель достойна затрат.
    Тогда действуй.
    Galkov wrote:Вот и вопрос: как мне узнать, что это "новое бревно" не стукнет по голове коллегу, который укрепляет другую подпорку гвоздями.
    Не стукнет. Если укрепление подпорки не залито на svn, то можно считать, что его не существует, а если оно и существует на отдельно взятом компе, то "укрепляющий" коллега сам разберётся.
    Galkov wrote:Про справку: это очень большая работа...
    Лично для меня это не имеет особого значения (документация на все сисфункции в некоторый момент тоже была "очень большой работой", что не помешало мне ей заняться), а вот необходимость фраз "это реализовано в корне неправильно, но мы всё равно об этом расскажем" (хотя бы между строк) убивает желание на корню.
    Ушёл к умным, знающим и культурным людям.
  • diamond

    Люблю ассоциации, они могут многое объяснить. Но Москва тоже не сразу строилась и металла и бетона, а сначала были те самые кривые бревна, гвозди и молоток, а если бы в то время кто-то взялся строить Москву из металла и бетона, то на её месте мы бы сейчас наблюдали пустынную степь. :) Над USB мы ещё поработаем, я думаю, а документацию пусть даже с некоторыми неприятными фразами написать было бы неплохо. Подобного рода документация, я думаю, очень даже пригодилась бы многим, так же как твоя документация по сис. функциям используется, как я предполагаю, сейчас всеми прикладными разработчиками.

    Mario

    Привет Mario! Рад, что ты снова в команде!
    К чему вот только упаднические настроения? Не следует ничего закрывать, Kolibri прекрасная система и многие люди рады посвятить ей всё своё свободное время. Михаилу я лично благодарен за то, что он столько лет держит этот сайт, ftp, svn и т.д.

    Почему в Колибри мало разработчиков? Взгляните на другие любительские ОС и вы поймете, что их не так уж и мало. Конечно для привлечения людей к разработке ядра действительно стоит заняться тем, чтобы люди понимали, где, как и что в ядре происходит. Ведь наличие хорошей документации сохраняет программисту уйму времени, которую он в противном случае потерял бы на ковыряние в коде. Документация позволяет программисту сразу же перейти к реализации своих идей, а посмотреть на результат своего творчества, а ведь именно конечный результат привлекает программиста к работе больше всего. Я не очень-то любил изучать языки программирования, но я очень люблю писать программы на них, посмотреть на то как мои знания практически воплощаются в зримый результат.
    Следующий момент - есть программисты, которые программируют из любви к процессу программирования, а есть те кто программируют только потому что это их работа, и сдается мне, что вторая категория гораздо больше и чтобы привлечь людей из этой второй категории необходимо каким-то образом обеспечить возможность зарабатывать людям деньги используя Kolibri, а для этого необходимо привлечь пользователей. Как привлечь пользователей? Не мне об этом говорить, всем и так ясно, какие программы пользуются наибольшим спросом у юзеров, а ведь не стоит забывать, что с точки зрения обычного непродвинутого юзера именно набор программ определяет функциональность ОС. Получается такая система, чтобы привлечь программистов второй категории, программисты первой категории должны привлечь юзеров, реализовав наиболее популярное среди них ПО.
  • Who is online

    Users browsing this forum: No registered users and 8 guests