Difference between revisions of "Evolution problems/ru"
| Line 12: | Line 12: | ||
Во вторых, ядро. Черезвычайно важный момент. Тут я сразу оговорюсь, что не являсь программистом ядра, ни в коем случае НЕ предлагаю сделать описанное за меня. Просто высказывания о проблеме. Итак, ядро, доставшееся от Вилле, было действительно неправильным, и проектированием там и не пахло. Увы, тут мы наступили на грабли и продолжили ядро, написанное Вилле, хотя в тот момент переписать ядро по правильному было гораздо проще. Но, я не собираюсь и никого не обвиняю. Что было - то прошло. На данный момент мы имеем не гибкое ядро, которое железно держится на многих вещах, подробнее можете прочитать в посте diamond`a [[http://board.kolibrios.org/viewtopic.php?f=2&p=23731#p23726 1]]. Кроме того, как отмечалось, при текущей реализации думать о безопастности ядра, полноценной системе управления процессами/потоками, SMP, EFI, ACPI, выносе ненужных вещей из ядра (сеть, графика, звук) просто не приходится. | Во вторых, ядро. Черезвычайно важный момент. Тут я сразу оговорюсь, что не являсь программистом ядра, ни в коем случае НЕ предлагаю сделать описанное за меня. Просто высказывания о проблеме. Итак, ядро, доставшееся от Вилле, было действительно неправильным, и проектированием там и не пахло. Увы, тут мы наступили на грабли и продолжили ядро, написанное Вилле, хотя в тот момент переписать ядро по правильному было гораздо проще. Но, я не собираюсь и никого не обвиняю. Что было - то прошло. На данный момент мы имеем не гибкое ядро, которое железно держится на многих вещах, подробнее можете прочитать в посте diamond`a [[http://board.kolibrios.org/viewtopic.php?f=2&p=23731#p23726 1]]. Кроме того, как отмечалось, при текущей реализации думать о безопастности ядра, полноценной системе управления процессами/потоками, SMP, EFI, ACPI, выносе ненужных вещей из ядра (сеть, графика, звук) просто не приходится. | ||
| + | |||
| + | В третьих, проблема централизации, особенно проявляющаяся в разработке прикладного ПО. Начнем с того, что разработка ПО все таки в ХОРОШЕМ варианте начинается с написания и доведения до рабочего и более менее стабильного уровня библиотек. Причем синхронно, т.к. на данный момент работа с графикой есть уже как минимум в трех вариантах. Зачем, спрашивается? Может быть конечно только мне кажется, что качественный рост важнее колличественного, но все же ... Сейчас, к примеру, что бы реализовать некое подобие достойной программы прийдется использовать гремучую смесь - box_lib, libGUI_C, fontslib, widgets, msgbox, libs-dev, kobra. Хотя первые пять можно объединить в одну. Ценой тех же усилий, что были потрачены на велосипеды, т.е. дублирующие функции и прочее. | ||
[P.S. Ещё допишу ...] | [P.S. Ещё допишу ...] | ||
Revision as of 17:47, 4 December 2009
Преамблуа
Данная страница предназначенна для того, что бы обозначить основные проблемы развития KOS. Троли с предложениями "Где Java?" могут смело идти лесом. Выказывание должно быть адекватным, четким и аргументированным.
maximYCH
Итак, KolibriOS - интересный проект, над которым на данный момент трудится около 20 разработчиков из СНГ.
Основная проблема развития, на мой взгляд - полное отсутствие централизации.
Во первых, текущий загрузчик действительно имеет смысл окончательно заменить на kord. Официально и бесповоротно. Проделанная Lrz работа - очень важная, на мой взгляд. И его подход гораздо правильнее текущего.
Во вторых, ядро. Черезвычайно важный момент. Тут я сразу оговорюсь, что не являсь программистом ядра, ни в коем случае НЕ предлагаю сделать описанное за меня. Просто высказывания о проблеме. Итак, ядро, доставшееся от Вилле, было действительно неправильным, и проектированием там и не пахло. Увы, тут мы наступили на грабли и продолжили ядро, написанное Вилле, хотя в тот момент переписать ядро по правильному было гораздо проще. Но, я не собираюсь и никого не обвиняю. Что было - то прошло. На данный момент мы имеем не гибкое ядро, которое железно держится на многих вещах, подробнее можете прочитать в посте diamond`a [1]. Кроме того, как отмечалось, при текущей реализации думать о безопастности ядра, полноценной системе управления процессами/потоками, SMP, EFI, ACPI, выносе ненужных вещей из ядра (сеть, графика, звук) просто не приходится.
В третьих, проблема централизации, особенно проявляющаяся в разработке прикладного ПО. Начнем с того, что разработка ПО все таки в ХОРОШЕМ варианте начинается с написания и доведения до рабочего и более менее стабильного уровня библиотек. Причем синхронно, т.к. на данный момент работа с графикой есть уже как минимум в трех вариантах. Зачем, спрашивается? Может быть конечно только мне кажется, что качественный рост важнее колличественного, но все же ... Сейчас, к примеру, что бы реализовать некое подобие достойной программы прийдется использовать гремучую смесь - box_lib, libGUI_C, fontslib, widgets, msgbox, libs-dev, kobra. Хотя первые пять можно объединить в одну. Ценой тех же усилий, что были потрачены на велосипеды, т.е. дублирующие функции и прочее. [P.S. Ещё допишу ...]