Первая реализация это было ужасно... После исправления и @KERNEL это выглядит на троечку...
Мне понравилось как это было дерзко и уверенно. Идея, но не ту, которую преследовали авторы, мне нравится. Авторы активны и работают, в этом они молодцы. Теперь о плохом.
И тут у меня слишком много вопросов, мыслей и текста... Поэтому я пробегу очень поверхностно.
Необходимости в функции 81 нет, тем более когда по умолчанию она прикрыта @KERNEL. Ф81 может быть полезна только очень малому кругу разработчиков в очень определённый период их жизни.
В релизе эта функция совсем не нужна, как написали выше - получится backdoor. И здесь не стоит вопрос почему другие системные функции и драйвера дырявые, они в отличии от ф81 выполняют прямую пользу и поэтому необходимы конечному пользователю. Ф81 конечному пользователю не нужна, даже программистам системы. Это прикольная, но не нужная возможность.
Исправление безопасности этой функции (в будущем) проблематично. Если попадание ebx в таблицу syscall'ов можно проверить, то заданный адрес и размер новой функции это беда (что если задать память ядра? или всю память? или указать стек? и т.д.)
Аналогичный функционал для пересборки и перезапуска ядра уже есть, да он подольше, но с учётом времени старта системы и её скоростью это не критично.
Если я правильно понял, то авторы хотели:
планируется перенести все библиотеки из Lib в глобальную область
(цитата из новости в vk). Как вы будете переносить константы и глобальные переменные этих библиотек с помощью ф81? Все остальные вопросы по этой теме уже задали выше, например:
0CodErr wrote:Для начала, как ты думаешь
Почему драйвера имеют именно такой формат, а не, скажем, просто сырой бинарник?
Что такое релокации и для чего они нужны?
Что такое базовый адрес и на что это влияет?
Где будут размещены статические данные?
По какому адресу они будут загружены?
Будут ли они вообще куда-нибудь загружены в твоей НЕДОреализации?
Среди всего прочего, усиливается разногласие: Kolibri-Next (Kolibri-N) всё хочет оторваться и начать свою жизнь.
голосование при котором будет принято решение оставить в ядре её и продолжать развитие операционки добавляя кучу фич, либо убрать и оставить дальше её в неизменном состоянии.
Зачем при голосовании писать однобоко? Делать больший акцент только на одной точке зрения? Как функция 81 поможет вам "продолжать развитие операционки добавляя кучу фич"? И почему здесь нет ответа на этот вопрос?
Вторая точка зрения полноценно не представлена, на ней не сделан акцент, зато ей приписаны отрицательные качества. Цитата: "либо убрать (функцию 81) и оставить дальше её (Колибри ОС) в неизменном состоянии".
Получилась тема для голосования, где вы можете легко обмануть пользователей. Между тем я предлагал опрос, который в интересах пользователей и важен разработчикам.
Было бы здорово провести в VK опросы на тему:
1) "я хотел(-а) применить/воспользоваться Колибри ОС для " решения таких-то задач, "но, мне помешало " то, что в Колибри ОС нет/отсутствует/сделано так-то и вот это.
2) я бы повседневно использовал(-а) или нашёл (нашла) повседневное применение Колибри, если бы ... список важных пунктов ...
И разумеется тщетно, даже нет отрицательных отзывов по этой мысли.
Если авторы не в силах объяснить/убедить, что это очень нужный функционал, то сообщество обязано удалить этот код из ядра. Сейчас, как минимум, этот код занимает память, заплатка @KERNEL съедает ресурсы при старте системы, а применения этому нет.