Предложение, план развития

Everything you can't fit into other forums
  • ЖИР.
    Из хаоса в космос
  • Как получить SCANCODE и дефайны к нему.
    Attachments
    keyboard.h (2.56 KiB)
    Downloaded 244 times
    Из хаоса в космос
  • Кстати, насчёт текстовых редакторов: никто не упомянул, но у нас есть "лучший текстовый редактор в мире" :)
  • I generally welcome the idea to have a roadmap.
    0CodErr wrote:Насчёт основной — не согласен, ведь на современном железе она будет работать ещё быстрее, возможно, в чём-то даже экономичнее.
    Agree, I want to use KolibriOS on my notebook, not on a particular model of a low end kolibri-book. That's why I implemented e.g. UEFI loader and XFS reading.
    theonlymirage wrote:Назову этот список "Хотелки к Kolibri 0.8.0.0"
    Don't we already have a thread for this? People list nice-to-have things nobody plans to implement:
    roadmap.txt wrote:### 0.8.0.0
    ...
    [-] поддержка 3G/4G usb-модемов;
    0CodErr wrote:Я уже давно говорил о необходимости RoadMap. Нужны критерии
    Exactly. Before filling the roadmap we should agree on how to do this. For example, I don't think it's okay to put in items that you personally won't implement. In roadmap terms, it's not okay to draw the road you won't go. Am I wrong?


    Btw, graphviz produces wonderful graphs from an easy to edit text file. See attachment.
    Attachments
    roadmap.pdf (14.47 KiB)
    Downloaded 260 times
    roadmap.dot (351 Bytes)
    Downloaded 252 times
  • Спасибо за поддержку! Вместе у нас больше шансов сделать всё правильно.
    Thanks for the support! Together we are more likely to do everything right.

    Согласен с изложенным выше.
    I agree with the above.
    dunkaist wrote:I want to use KolibriOS on my notebook, not on a particular model of a low end kolibri-book. That's why I implemented e.g. UEFI loader and XFS reading.
    Это хорошо, но сейчас у нас мало возможностей. Для использования актуального железа необходим переход на х64 и поддержка многоядерных процессоров (планировщиком задач). Лично я на ближайший год занят другими задачами. Желающих развивать указанные направления не видно. Есть какие-то идеи? Кто готов начать эту работу? Другого способа раскрыть более 4Гб ОЗУ нет. Так и по всем остальным параметрам железа. Например, поддержка современных видеокарт - это же ужас для нашего скромного сообщества. Поэтому мне кажется, что нужно не спешить нагнать железо, а следует закрепиться на старом.
    Spoiler:This is good, but now we have few opportunities. To use the actual hardware, you need to switch to x64 and support multi-core processors (task scheduler). Personally, I am busy with other tasks for the next year. Those who wish to develop these areas are not visible. Any ideas? Who is ready to start this work? There is no other way to open more than 4 GB of RAM. So in all other parameters of hardware. For example, support for video cards is the same horror for a small community. Therefore, it seems to me that it is necessary not to hurry to catch up with hardware, but we need to gain a foothold in the old hardware.
    dunkaist wrote:Before filling the roadmap we should agree on how to do this. For example, I don't think it's okay to put in items that you personally won't implement. In roadmap terms, it's not okay to draw the road you won't go. Am I wrong?
    Абсолютно верно. Поэтому я вношу в список задачи, которые интересны людям в проекте.
    Absolutely right. Therefore, I add tasks that are interesting to people in the project.


    P.S. По сути мы уже закрыли несколько пунктов roadmap, но хотелось бы их улучшить. Вот эти пункты (они в работе, но определённые результаты уже есть):
    [-] port / adapt one of the existing text editors with code highlighting;
    [-] development and discussion of architecture Kolibri Machine Controller(KMC), semblance of LinuxCNC, based on MachineKit;
    [-] modify&improve apps: IconEdit, uPDF;
    [-] new app "Notes";

    Мои задачи сейчас следующие:
    - добавить режим горячей клавиши в Hot Angles;
    - протестировать syscall функции ядра (предлагаю сделать это на стримах со следующей недели);
    - доработать интерфейс CNC Control;
    - по возможности написать драйвер для оборудования на USB/COM порте под задачи CNC;
    - доделать интерфейс для форматирования дисков;
    - реализовать форматирование;
    - реализовать функции TextToQR, QRtoText и затем закрыть вопрос QR-code in boot log;
    - и в конце перелопатить поддержку NTFS.
  • Я знаю как минимум 3 сисфункции с крэшем ядра
    - отрисовка строки, не влезающей в окно
    - работа с клипбордом
    - создание многокнопок

    чего там на стримах показывать...
  • Siemargl wrote:Я знаю как минимум 3 сисфункции с крэшем ядра
    - отрисовка строки, не влезающей в окно
    - работа с клипбордом
    - создание многокнопок

    чего там на стримах показывать...
    Эти три известные, но нам нужно протестировать всё. Нам нужны описания теста и нужны примеры, воспроизводящие баг, который даже после исправления может появиться снова (и этот пример кода поможет проверить, что ничего не испорчено). Мне кажется без тестов не будет стабильного исправления в ядре. Если это не так, то напишите. Нам же нужно стабильное ядро?
    Кстати, есть баг трекинговая система... Как ещё вариант: давайте создадим тему Ошибки ядра или Тестирование ядра в соотв.разделе форума и будем там выкладывать материал: хотя бы пример кода, воспроизводящий баг.

    Моё мнение:
    Если никак не консолидировать усилия, то ошибки не будут исправлены. Добавление нового функционала и изменения будут сопровождаться увеличением кол-ва ошибок. В целом, отсутствие развития в ядре тормозит дальнейшее развитие проекта. И ещё, я могу быть не прав.
  • dunkaist wrote: I don't think it's okay to put in items that you personally won't implement. In roadmap terms, it's not okay to draw the road you won't go. Am I wrong?
    Ну кто-то же всё равно должен был составить RoadMap.
    И это мог быть даже необязательно программист.
    Иначе это не RoadMap проекта вообще, а лишь список сугубо личных приоритетов(такой пример есть для Kolibri-N от Leency).
    dunkaist wrote:Btw, graphviz produces wonderful graphs from an easy to edit text file.
    Крутая вещь!
    theonlymirage wrote:давайте создадим тему Ошибки ядра или Тестирование ядра в соотв.разделе форума и будем там выкладывать материал
    Например, есть такая тема http://board.kolibrios.org/viewtopic.php?f=2&t=1519
    theonlymirage wrote:Добавление нового функционала и изменения будут сопровождаться увеличением кол-ва ошибок. В целом, отсутствие развития в ядре тормозит дальнейшее развитие проекта.
    Абсолютно согласен!
    Мы не успели ещё допилить\протестировать\исправить предыдущее, а уже кто-то добавляет что-то новое, непротестированное, потенциально глючное и с новыми багами — это глупо и не рационально.
  • 0CodErr wrote:Абсолютно согласен!
    Мы не успели ещё допилить\протестировать\исправить предыдущее, а уже кто-то добавляет что-то новое, непротестированное, потенциально глючное и с новыми багами — это глупо и не рационально.
    Я заметил, что ты часто против выступаешь против новинок и в целом против изменений. Подобное раньше замечал у yogev_erza.

    В любой компании есть "газ" и "тормоз" (без плохого конткста, просто часть авто). Газ несется вперед за новым, тормоз говорит: "Так, давайте остановимся и подумаем". Газ старается купить, тормоз старается сэкономить. Думаю, смысл ясен. Хорошо, когда есть оба и они в равновесии, никто из них не перетягивает лямку.

    Если много газа - баги, много тормоза - стагнация.

    Мы можем и должны управлять активностями в зависимости от цикла разработки.
    Есть период активной разработки и есть период стабилизации. Для периода активной разработки правильно добавлять новое. Для стабилизации и предрелиза все замораживается для тестирования и правки багов. Кстати, какой у нас сейчас период?

    Обычно я газ, но сейчас у меня период предрелиза и я перешел в фазу тормоза и правлю баги.
    Я это к тому, что не нужно выступать против нового, нужно разумно принимать его и тестировать. А в период заморозки сфокусироваться на исправлении багов.
    Из хаоса в космос
  • Leency wrote:Я заметил, что ты часто против выступаешь против новинок и в целом против изменений. Подобное раньше замечал у yogev_erza.
    Ну надо же, всё-таки заметил наконец-то :mrgreen:
    Работает — не трогай, слышал такое?
    И да, я против изменений ради изменений.
    Если не прибавляется функционал, не увеличивается скорость работы, не оптимизируется размер — с большой вероятностью такое изменение не нужно.
    Leency wrote:Я это к тому, что не нужно выступать против нового, нужно разумно принимать его и тестировать. А в период заморозки сфокусироваться на исправлении багов.
    Так вот я и о чём! Не надо всё подряд сразу пихать в img. Ты сперва протестируй, исправь, доработай ... Но нет, надо обязательно(пусть даже почти не готовое приложение) запихнуть в дистр и побыстрее написать об этом в личном бложикегруппе ВК.
  • 0CodErr
    Ты даже представить не можешь сколько багов содержат, выпускаемые на рынок продукты. Я это тебе с уверенностью говорю как QA с пятилетним опытом.
    Нет, не продукты конкретно моей компании содержат много багов при релизе, а вообще все выпускаемое на рынок ПО. Windows, Linux, MacOS, любой софт, без разницы.
    Пример? Баг в калькуляторе, которому 4.5 года.

    Все потому что миром рулит не академический онанизм зацикленный на исправлении всех багов. См. пункт 1 https://software-testing.org/testing/os ... ii-po.html
    а здравый смысл: ты расчитываешь насколько полезный импакт от новой функциональности и какие негативные факторы, например количество багов.
    Это стоит понять.
    Из хаоса в космос
  • Leency, да забей! Всё равно каждый останется при своём, для тебя каждая фентиклюшка — уже достижение.
    Для меня же фентиклюшки далеко не на первом месте, да и вообще не являются приоритетом.
    В первую очередь функционал.
  • Хорошо, что ты понимаешь наличие различий у нас, как у личностей, и различие приоритетах, хотя и принижаешь мои.
    В любом случае, все не так плохо. Марио, например, не понимал вообще на первого, ни второго.
    Диамонд, Мышка и Серж не парятся пока все работает. Старайся быть как они :)
    Из хаоса в космос
  • Leency wrote: Все потому что миром рулит не академический онанизм зацикленный на исправлении всех багов ...
    а здравый смысл: ты расчитываешь насколько полезный импакт от новой функциональности и какие негативные факторы, например количество багов.
    Это стоит понять.
    А я думал, что желание разработчика сэкономить на производстве. В голове крутится, а название вспомнить не могу - книга в которой описаны "паттерны" и "антипаттерны." Обычно, имеют место:
    - стратегия в противоречии с тактическими решениями, трудно преодолимые зависимости,
    - плохая или никакая документация,
    - отсутствие планирования тестирования до начала разработки и т. д.
    А потом этот ком только растёт, на определённом этапе начинает разбегаться команда, и её заменяют сомнительные люди, которые отчасти из-за отсутствия документирования, решают проблемы через заплатки.

    В Вашем проекте я посмотрел, что поддерживаются разные файловые системы, но своей нет, стало интересно: поддерживается ли изоляция дискового пространства между процессами? Также не понятен менеджмент памяти - поддерживается ли изоляция между управляющими структурами менеджера памяти и кучей, вынесен ли менеджмент памяти всецело в ядро или имеет место уровень абстракции. Осуществляется ли ядром априорная оценка нагрузки от системного вызова ... Думаю, Ваш roadmap должен начинаться с подготовки хорошей документации, а может я и ошибаюсь, и просто не нашёл правильное место для чтения.
  • Who is online

    Users browsing this forum: No registered users and 3 guests