А проверку целостности образа Windows через DISM делали?
BSOD без указания кода ошибки — это жесть, пахнет серьёзным повреждением системных файлов — но восстановление через DISM даже в этом случае, возможно, помогло бы обойтись без переустановки.
Есть ощущение, что основной массы негатива можно избежать, если в первых же абзацах readme.md описать, какие именно насущные проблемы решает ваша библиотека, и почему те же самые проблемы гораздо неудобнее / сложнее / дороже решать, используя более популярные библиотеки от больших игроков.
Как говорится, haters gonna hate, но адекватные люди, увидев понятное рациональное обоснование, вряд ли станут критиковать пусть и нишевое, но решение, нацеленное на конкретные и объективно существующие недостатки.
Суровая мужская слеза ностальгии сползла по щеке. Помню, как завидовали демомейкерам на Амиге, у которых в распоряжении уже тогда было, хотя бы, 2D аппаратное ускорение. Помню Watcom C и вставки на ассемблере для оптимизации вычислений. Затенение Гуро, Фонга, интерполирование нормалей, прямой доступ к видеопамяти…
Там не то, чтобы прямо космос, но возможных режимов действительно много из-за всех возможных комбинаций управляющих переменных (управляем давлением или объёмом, цикл вдоха / выдоха по таймеру или регулируется давлением в контуре и т.п.)
В итоге, ИМХО основная сложность в качественных точных датчиках и надёжных алгоритмах управления.
Авторы самодельных ИВЛ описывают, какие режимы из настоящего ИВЛ они пытались реализовать? Есть ощущение, что простые дешёвые конструкции умеют только в time-triggered pressure controlled режимы, которые как минимум не очень комфортны для хоть как-то самостоятельно дышащего пациента (это не говоря уже о том, что в такой конструкции очень сложно реализовать тот самый low tidal volume режим, жизненно необходимый при COVID19)
Ни один из этих продуктов не создавался с целью получения прямой прибыли. Они создавались либо на энтузиазме сообщества, либо финансировались крупными компаниями с целью извлечь косвенную прибыль.
У Revery под капотом всё тот же Electron, так что от архаичного JavaScript избавимся, но от Chromium с его прожорливостью — увы, нет.
Я бы, скорее, подумал тогда о том, как прикрутить ReasonML к NodeGUI, если есть непреодолимое желание писать в функциональной парадигме (что, впрочем, можно делать и на typescript + fp-ts)
PCI — довольно сложная шина; использовать её для того, чтобы «помигать светодиодом» — это, как говорится, из пушки по воробьям.
Сейчас проще всего будет взять PCI-Express LPT контроллер (обычно есть в продаже в интернет-магазинах деталей для ЧПУ станков и 3Д принтеров) с опторазвязкой параллельного порта — так риск сжечь что-нибудь в самом компьютере будет минимальным.
Тогда это будет называться операционная система или код загрузки операционной системы, а вовсе не пользовательская программа.
Необязательно — могут быть программы и чисто утилитарного назначения, которые полагаются только на UEFI runtime services и могут быть запущены из UEFI shell без загрузки какой-либо ОС.
Я бы предложил уточнить, что именно понимается под «кодом BIOS». 16-битный код BIOS реального режима, который использовался ещё во времена MS-DOS через прерывания, современные операционные системы не вызывают и не используют.
Если говорить о UEFI runtime services, то, насколько я смог выяснить, что Windows, что Linux используют только variable service.
Svelte ещё сыроват, и нежелание тащить его в продакшен вполне понятно.
Vue — тут, думаю, всё упирается в:
BSOD без указания кода ошибки — это жесть, пахнет серьёзным повреждением системных файлов — но восстановление через DISM даже в этом случае, возможно, помогло бы обойтись без переустановки.
Как говорится, haters gonna hate, но адекватные люди, увидев понятное рациональное обоснование, вряд ли станут критиковать пусть и нишевое, но решение, нацеленное на конкретные и объективно существующие недостатки.
В итоге, ИМХО основная сложность в качественных точных датчиках и надёжных алгоритмах управления.
Авторы самодельных ИВЛ описывают, какие режимы из настоящего ИВЛ они пытались реализовать? Есть ощущение, что простые дешёвые конструкции умеют только в time-triggered pressure controlled режимы, которые как минимум не очень комфортны для хоть как-то самостоятельно дышащего пациента (это не говоря уже о том, что в такой конструкции очень сложно реализовать тот самый low tidal volume режим, жизненно необходимый при COVID19)
Сам браузерный движок при прямых руках может обеспечить достаточный fps для плавной работы UI.
Я бы, скорее, подумал тогда о том, как прикрутить ReasonML к NodeGUI, если есть непреодолимое желание писать в функциональной парадигме (что, впрочем, можно делать и на typescript + fp-ts)
Сейчас проще всего будет взять PCI-Express LPT контроллер (обычно есть в продаже в интернет-магазинах деталей для ЧПУ станков и 3Д принтеров) с опторазвязкой параллельного порта — так риск сжечь что-нибудь в самом компьютере будет минимальным.
Необязательно — могут быть программы и чисто утилитарного назначения, которые полагаются только на UEFI runtime services и могут быть запущены из UEFI shell без загрузки какой-либо ОС.
Если говорить о UEFI runtime services, то, насколько я смог выяснить, что Windows, что Linux используют только variable service.
Конкретно про ACPI, SCI и SMI очень подробно написано здесь: https:/stackoverflow.com/a/40586456.
Два важных момента: