Evolution problems/ru

Преамблуа

Данная страница предназначенна для того, чтобы обозначить основные проблемы развития KOS. Тролли с предложениями "Где Java?" могут смело идти лесом. Выказывание должно быть адекватным, четким и аргументированным.

diamond

Колибри не имеет плана развития как такового, так что можно делать всё в разумных пределах (переписывание на "что-нибудь посложнее, чем сегодняшний 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), приложение-сервер не может одновременно работать с несколькими клиентами, приложение-клиент даже не может надёжно открыть соединение (оно должно сначала найти свободный локальный порт и потом его указать при открытии сокета; а что, если между первым и вторым действием вклинится другое приложение, которое найдёт тот же свободный локальный порт и откроет сокет с ним?).

maximYCH

Итак, KolibriOS - интересный проект, над которым на данный момент трудится около 20 разработчиков из СНГ.

Основная проблема развития, на мой взгляд - полное отсутствие централизации.

Во первых, текущий загрузчик действительно имеет смысл окончательно заменить на kord. Официально и бесповоротно. Проделанная Lrz работа - очень важная, на мой взгляд. И его подход гораздо правильнее текущего.

Во вторых, ядро. Черезвычайно важный момент. Тут я сразу оговорюсь, что не являсь программистом ядра, ни в коем случае НЕ предлагаю сделать описанное за меня. Просто высказывания о проблеме. Итак, ядро, доставшееся от Вилле, было действительно неправильным, и проектированием там и не пахло. Увы, тут мы наступили на грабли и продолжили ядро, написанное Вилле, хотя в тот момент переписать ядро по правильному было гораздо проще. Но, я не собираюсь и никого не обвиняю. Что было - то прошло. На данный момент мы имеем не гибкое ядро, которое железно держится на многих вещах, подробнее можете прочитать в посте diamond`a [1]. Кроме того, как отмечалось, при текущей реализации думать о безопастности ядра, полноценной системе управления процессами/потоками, SMP, EFI, ACPI, выносе ненужных вещей из ядра (сеть, графика, звук) просто не приходится.

В третьих, проблема централизации, особенно проявляющаяся в разработке прикладного ПО. Начнем с того, что разработка ПО все таки в ХОРОШЕМ варианте начинается с написания и доведения до рабочего и более менее стабильного уровня библиотек. Причем синхронно, т.к. на данный момент работа с графикой есть уже как минимум в трех вариантах. Зачем, спрашивается? Может быть конечно только мне кажется, что качественный рост важнее колличественного, но все же ... Сейчас, к примеру, что бы реализовать некое подобие достойной программы прийдется использовать гремучую смесь - box_lib, libGUI_C, fontslib, widgets, msgbox, libs-dev, kobra. Хотя первые пять можно объединить в одну. Ценой тех же усилий, что были потрачены на велосипеды, т.е. дублирующие функции и прочее. [P.S. Ещё допишу ...]