Лидеры

HoverHelm — сетевые диски для тех, у кого нет жёсткого: дронов, микроконтроллеров. Вставляем диск в сервер — через модемы клиенты получают к нему доступ. И пару вкусных фич вдобавок. Фичи и преимущества по сравнению с голым EEPROM Сетевой жесткий диск: можно забыть про ограничение в 4кБ можно делать программы модульными легко обновить программу, не нужно перешивать каждого дрона за всю игру может понадобиться скрафтить только один жесткий диск Удаленный терминал: не нужны клава и моник, больше слотов в роботах централизованное управление всех ваших дронов Обратная совместимость: старые eeprom-программы работают без изменений Какие-то другие очевидные плюсы, про которые я забыл Прогресс разработки Система запускается и работает Виртуальный диск с доступом к папке на жестком диске сервера Удаленный терминал для запуска программ на устройствах Конфигурация Логирование Связь через сетевую и связанную карту Инсталлятор Виртуальный гпу Связь через интернет-карту (Stem) Сохранение имен устройств Удаленные терминалы Минимальные системные требования Конечное устройство Сервер Инструкция по установке Установка сервера: Установите OpenOS Выполнить команду pastebin run xh61Yx8a Отредактируйте открывшийся конфиг Добавьте желаемые к использования сетевые и связанные карты по образцу Можно настроить пути расположения пользовательских папок и папки клиентского ядра Установка клиента: Запустите HoverHelm server hoverhelm/main.lua Выполните команду prepare_eeprom <имя устройства> <адрес серверного модема> <порт> <адрес клиентского модема> Если на сервере одна сетевая карта, вместо адреса её можно вписать тип (modem или tunnel). Адрес клиентского модема можно убрать вообще, если на клиенте только одна сетевая карта. Инструкция по использованию Запустите сервер HoverHelm командой hoverhelm/main.lua Запустите устройства, просто включив их при первом запуске каждого устройства будет создана его пользовательская папка в /home/hoverhelm/devices/<deviceName>/ можно смонтировать по этому пути отдельный диск средствами OpenOS в терминале сервера и в файле лога устройства повится строка <deviceName> started, сигнализирующая о готовности устройства файлы, общие для всех устройств лежат в /home/hoverhelm/device_core/ (coreRootFolder в конфиге) файлы, специфичные для конкретного устройства лежат в /home/hoverhelm/devices/<deviceName>/ (userRootFolder в конфиге) В терминале сервера выполните deviceName>device-program-name args, чтобы выполнить на устройстве deviceName программу device-program-name с аргументом args программа с именем test будет искаться по пути /test.lua и /programs/test.lua, относительно виртуальной фс устройства Из коробки пока доступна только программы reboot и lua В терминале сервера выполните hide, чтобы свернуть HoverHelm server не прерывая его работу можно будет открыть его той же командой для продолжения работы с терминалом Ссылки Гитхаб: https://github.com/hohserg1/HoverHelm

Я уже игрался с виртуализацией компонентов и здесь есть 1 трабла. Сетевая карта берет 1 тик на пересылку сообщения. И если на каждое действие использовать ее то проограма будет работач оч медленно. Здесь нужно пытатся чем поменьше ганнять данные по сети. Если юзаеш к примеру робота/дрона и комп для норм монитора то лучше всего проги запускать на роботе/дроне, все гуи штуки рисовать как будто через двойную буферизацию (а точнее батчами) и отправлять все одним пакетом. Если нужен диск то нужно иметь програму типо БД на компе с дисками и отдавать их по запросах. Кул бы было сделать как хадуп делает. Он вместо того что б гонять данные к программе -- гоняет программы к данным. Тоесть я имею ввиду писать проги на компе а он что б перебрасывал части прог куда нада.

Беспроводной зарядник имеет точку в которую он передает энергию, представленную в виде тройки dx,dy,dz, относительных смещений от центра зарядника. Эта точка может находиться вокруг зарядника в пределах сферы радиуса R(настраивается в конфиге). Ее можно задать и получить программно. Также беспроводной зарядник имеет радиус r разброса энергии вокруг ChargingPoint. Этот радиус также задается программно. Передачу энергии можно включать/отключать wireless_charger.setChargingPoint(dx,dy,dz) dx,dy,dz = wireless_charger.getChargingPoint() R = wireless_charger.getChargingRadius() wireless_charger.setDisperseRadius(r) r = wireless_charger.getDisperseRadius() wireless_charger.setActive(true) a = wireless_charger.isActive() Зарядник работает следующим образом: если он активен, то потребляет каждый тик N энергии(настраивается в конфиге), после чего ищет в сферической области радиуса r в точке dx,dy,dz любые устройства, способные принимать энергию. Для каждого устройства определяется объем пересечения его хитбокса с сферой зарядки. Этот объем делится на объем сферы, получая коэфициент попадания. В результате каждое устройство получает энергию в размере N*min(1, hitV/chargeV). Стоит отметить, что сумма энергии, переданной всем устройствам не должна превышать N(чтобы не было дюпа). С этой механикой можно как-нить поиграться, типо, юзать не сферические радиусы, а кубические области

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