История изменений

Вот то о чем ты говоришь: текстового общения не достаточно, подавай с картинками и видео, иначе — нет. За упаковку продались. Ну я и не горюю.

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

это очень круто. С какой целью пишешь? Сколько времени? Один?

На самом деле там код за копирайтом J. Andrew McLaughlin. Лет 10 назад я посмотрел сорцы visopsys и что-то загорелся. Довольно богатое API. Многие подсистемы ядра уже написаны. Хоть и не доделаны, но дописывать функциональность проще, чем писать с нуля. Всё выглядело очень богато, при том что работало с дискеты. Падает в кернел паник, ну так мы сейчас исправим баги, и будет огонь... Я еще не знал, куда я попаду. :D

А код оказался не то что плохим. Он состоял из race condition-ов ВЕСЬ. В общем, фаза «так мы сейчас исправим баги» сильно затянулась. Потом я как-то остыл к этому делу, но перед этим успел основательно перепилить систему сборки, взаимодействие потоков, обработку прерываний, ввод-вывод... что-то там еще, не помню деталей. Помню, сделал нормальный wait для потоков, ожидающих событий от прерываний, вместо тупого while (данных нет) {yield_processor();}, добавил boost потокам, просыпающимся по сообщению от потоков более высокого приоритета, и задрал частоту вытеснения потоков до 100 Гц - система сразу стала отзывчивой в виртуальной машине.

Сейчас вот снова ковыряю сорцы потихоньку.

Сейчас основной источник race condition — оконная подсистема, которая многопоточная, но при этом написана так, будто однопоточная. Насколько я могу вспомнить, глядя в код, я пытался исправить ситуацию fine tuning-ом, делая выборочный захват мьютексов только в тех местах, где это необходимо. Но это я не доделал. Сейчас думаю, проще всего воткнуть один общий мьютекс на входе в любую оконную функцию, чем разбираться в деталях. Но это превратит всю оконную систему в де факто однопоточную, прямо как во времена Windows 95 (аутентичность, чо). Так что я в шаге от того, чтобы выкинуть всё это нафиг и портировать туда какую-нибудь минималистичную реализацию X11. Засада, в общем.

Вообще проблема таких систем как visopsys и kolibri - казаться, а не быть. В kolibri это еще более выражено. Там прямо 100500 приложений, довольно активное сообщество, 10 лет они уже пилят форк менуэта, отрефакторили практически всё ядро, и вроде всё хорошо у проекта. А пробуешь это потестить, и понимаешь, что вместо приложений там заглушки, имитирующие работу. А вместо ядра по прежнему страх божий с API уровня 16-битных сервисов BIOS образца 1990-го года. Когда читаешь перлы а ля «часть функций для работы с процессами принимает PID, а часть - номер слота в таблице», хочется просто распечатать эти сорцы и сжечь.

Сообща бы написали за год все что нужно.

Если ты возьмешься это делать, то с вероятностью, практически неотличимой от 100%, у тебя получится еще одна Kolibri. Пусть она будет минималистичная, текстовая и без свистоперделок в GUI, но по структуре - такая же каша. Или если ты гений один на миллиард, то у тебя получится что-то типа luajit — код, который работает идеально, но никто, кроме автора и еще пары человек в мире, не понимает, как.

Основные затраты в разработке - это создание и поддержание абстракций. А байты перекладывать из входа на выход — это можно за пару месяцев накидать, да. Но дальше этот код никуда без правильных абстракций расширяться не сможет.

Вот то о чем ты говоришь: текстового общения не достаточно, подавай с картинками и видео, иначе — нет. За упаковку продались. Ну я и не горюю.

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

это очень круто. С какой целью пишешь? Сколько времени? Один?

На самом деле там код за копирайтом J. Andrew McLaughlin. Лет 10 назад я посмотрел сорцы visopsys и что-то загорелся. Довольно богатое API. Многие подсистемы ядра уже написаны. Хоть и не доделаны, но дописывать функциональность проще, чем писать с нуля. Всё выглядело очень богато, при том что работало с дискеты. Падает в кернел паник, ну так мы сейчас исправим баги, и будет огонь... Я еще не знал, куда я попаду. :D

А код оказался не то что плохим. Он состоял из race condition-ов ВЕСЬ. В общем, фаза «так мы сейчас исправим баги» сильно затянулась. Потом я как-то остыл к этому делу, но перед этим успел основательно перепилить систему сборки, взаимодействие потоков, обработку прерываний, ввод-вывод... что-то там еще, не помню деталей. Помню, сделал нормальный wait для потоков, ожидающих событий от прерываний, вместо тупого while (данных нет) {yield_processor();}, добавил boost потокам, просыпающимся по сообщению от потоков более высокого приоритета, и задрал частоту вытеснения потоков до 100 Гц - система сразу стала отзывчивой в виртуальной машине.

Сейчас вот снова ковыряю сорцы потихоньку.

Сейчас основной источник race condition — оконная подсистема, которая многопоточная, но при этом написана так, будто однопоточная. Насколько я могу вспомнить, глядя в код, я пытался исправить ситуацию fine tuning-ом, делая выборочный захват мьютексов только в тех местах, где это необходимо. Но это я не доделал. Сейчас думаю, проще всего воткнуть один общий мьютекс на входе в любую оконную функцию, чем разбираться в деталях. Но это превратит всю оконную систему в де факто однопоточную, прямо как во времена Windows 95 (аутентичность, чо). Так что я в шаге от того, чтобы выкинуть всё это нафиг и портировать туда какую-нибудь минималистичную реализацию X11. Засада, в общем.

Вообще проблема таких систем как visopsys и kolibri - казаться, а не быть. В kolibri это еще более выражено. Там прямо 100500 приложений, довольно активное сообщество, 10 лет они уже пилят форк менуэта, отрефакторили практически всё ядро, и вроде всё хорошо у проекта. А пробуешь это потестить, и понимаешь, что вместо приложений там заглушки, имитирующие работу. А вместо ядра по прежнему страх божий с API уровня 16-битных сервисов BIOS образца 1990-го года. Когда читаешь перлы а ля «часть функций для работы с процессами принимает PID, а часть - номер слота в таблице», хочется просто распечатать эти сорцы и сжечь.

Сообща бы написали за год все что нужно.

Если ты возьмешься это делать, то с вероятностью, практически неотличимой от 100%, у тебя получится еще одна Kolibri. Пусть она будет минималистичная, текстовая и без свистоперделок в GUI, но по структуре - такая же каша. Или если ты гений один на миллиард, то у тебя получится что-то типа luajit — код, который работает идеально, но никто, кроме автора и еще пары человек в мире, не понимает, как.

Основные застраты в разработке - это создание и поддержание абстракций. А байты перекладывать из входа на выход — это можно за пару месяцев накидать, да. Но дальше этот код никуда без правильных абстракций расширяться не сможет.

Вот то о чем ты говоришь: текстового общения не достаточно, подавай с картинками и видео, иначе — нет. За упаковку продались. Ну я и не горюю.

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

это очень круто. С какой целью пишешь? Сколько времени? Один?

На самом деле там код за копирайтом J. Andrew McLaughlin. Лет 10 назад я посмотрел сорцы visopsys и что-то загорелся. Довольно богатое API. Многие подсистемы ядра уже написаны. Хоть и не доделаны, но дописывать функциональность проще, чем писать с нуля. Всё выглядело очень богато, при том что работало с дискеты. Падает в кернел паник, ну так мы сейчас исправим баги, и будет огонь... Я еще не знал, куда я попаду. :D

А код оказался не то что плохим. Он состоял из race condition-ов ВЕСЬ. В общем, фаза «так мы сейчас исправим баги» сильно затянулась. Потом я как-то остыл к этому делу, но перед этим успел основательно перепилить систему сборки, взаимодействие потоков, обработку прерываний, ввод-вывод... что-то там еще, не помню деталей. Помню, сделал нормальный wait для потоков, ожидающих событий от прерываний, вместо тупого while (данных нет) {yield_processor();}, добавил boost потокам, просыпающимся по сообщению от потоков более высокого приоритета, и задрал частоту вытесения потоков до 100 Гц - система сразу стала отзывчивой в вирутальной машине.

Сейчас вот снова ковыряю сорцы потихоньку.

Сейчас основной источник race condition — оконная подсистема, которая многопоточная, но при этом написана так, будто однопоточная. Насколько я могу вспомнить, глядя в код, я пытался исправить ситуацию fine tuning-ом, делая выборочный захват мьютексов только в тех местах, где это необходимо. Но это я не доделал. Сейчас думаю, проще всего воткнуть один общий мьютекс на входе в любую оконную функцию, чем разбираться в деталях. Но это превратит всю оконную систему в де факто однопоточную, прямо как во времена Windows 95 (аутентичность, чо). Так что я в шаге от того, чтобы выкинуть всё это нафиг и портировать туда какую-нибудь минималистичную реализацию X11. Засада, в общем.

Вообще проблема таких систем как visopsys и kolibri - казаться, а не быть. В kolibri это еще более выражено. Там прямо 100500 приложений, довольно активное сообщество, 10 лет они уже пилят форк менуэта, отрефакторили практически всё ядро, и вроде всё хорошо у проекта. А пробуешь это потестить, и понимаешь, что вместо приложений там заглушки, имитирующие работу. А вместо ядра по прежнему страх божий с API уровня 16-битных сервисов BIOS образца 1990-го года. Когда читаешь перлы а ля «часть функций для работы с процессами принимает PID, а часть - номер слота в таблице», хочется просто распечатать эти сорцы и сжечь.

Сообща бы написали за год все что нужно.

Если ты возьмешься это делать, то с вероятностью, практически неотличимой от 100%, у тебя получится еще одна Kolibri. Пусть она будет минималистичная, текстовая и без свистоперделок в GUI, но по структуре - такая же каша. Или если ты гений один на миллиард, то у тебя получится что-то типа luajit — код, который работает идеально, но никто, кроме автора и еще пары человек в мире, не понимает, как.

Основные застраты в разработке - это создание и поддержание абстракций. А байты перекладывать из входа на выход — это можно за пару месяцев накидать, да. Но дальше этот код никуда без правильных абстракций расширяться не сможет.

Вот то о чем ты говоришь: текстового общения не достаточно, подавай с картинками и видео, иначе — нет. За упаковку продались. Ну я и не горюю.

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

это очень круто. С какой целью пишешь? Сколько времени? Один?

На самом деле там код за копирайтом J. Andrew McLaughlin. Лет 10 назад я посмотрел сорцы visopsys и что-то загорелся. Довольно богатое API. Многие подсистемы ядра уже написаны. Хоть и не доделаны, но дописывать функциональность проще, чем писать с нуля. Всё выглядело очень богато, при том что работало с дискеты. Падает в кернел паник, ну так мы сейчас исправим баги, и будет огонь... Я еще не знал, куда я попаду. :D

А код оказался не то что плохим. Он состоял из race condition-ов ВЕСЬ. В общем, фаза «так мы сейчас исправим баги» сильно затянулась. Потом я как-то остыл к этому делу, но перед этим успел основательно перепилить систему сборки, взаимодействие потоков, обработку прерываний, ввод-вывод... что-то там еще, не помню деталей. Помнюю, сделал нормальный wait для потоков, ожидающих событий от прерываний, вместо тупого while (данных нет) {yield_processor();}, добавил boost потокам, просыпающимся по сообщению от потоков более высокого приоритета, и задрал частоту вытесения потоков до 100 Гц - система сразу стала отзывчивой в вирутальной машине.

Сейчас вот снова ковыряю сорцы потихоньку.

Сейчас основной источник race condition — оконная подсистема, которая многопоточная, но при этом написана так, будто однопоточная. Насколько я могу вспомнить, глядя в код, я пытался исправить ситуацию fine tuning-ом, делая выборочный захват мьютексов только в тех местах, где это необходимо. Но это я не доделал. Сейчас думаю, проще всего воткнуть один общий мьютекс на входе в любую оконную функцию, чем разбираться в деталях. Но это превратит всю оконную систему в де факто однопоточную, прямо как во времена Windows 95 (аутентичность, чо). Так что я в шаге от того, чтобы выкинуть всё это нафиг и портировать туда какую-нибудь минималистичную реализацию X11. Засада, в общем.

Вообще проблема таких систем как visopsys и kolibri - казаться, а не быть. В kolibri это еще более выражено. Там прямо 100500 приложений, довольно активное сообщество, 10 лет они уже пилят форк менуэта, отрефакторили практически всё ядро, и вроде всё хорошо у проекта. А пробуешь это потестить, и понимаешь, что вместо приложений там заглушки, имитирующие работу. А вместо ядра по прежнему страх божий с API уровня 16-битных сервисов BIOS образца 1990-го года. Когда читаешь перлы а ля «часть функций для работы с процессами принимает PID, а часть - номер слота в таблице», хочется просто распечатать эти сорцы и сжечь.

Сообща бы написали за год все что нужно.

Если ты возьмешься это делать, то с вероятностью, практически неотличимой от 100%, у тебя получится еще одна Kolibri. Пусть она будет минималистичная, текстовая и без свистоперделок в GUI, но по структуре - такая же каша. Или если ты гений один на миллиард, то у тебя получится что-то типа luajit — код, который работает идеально, но никто, кроме автора и еще пары человек в мире, не понимает, как.

Основные застраты в разработке - это создание и поддержание абстракций. А байты перекладывать из входа на выход — это можно за пару месяцев накидать, да. Но дальше этот код никуда без правильных абстракций расширяться не сможет.