> именно поэтому, к примеру, в nginx нет классического cgi-интерфейса
Скорее из-за принципов и особенностей мышления разработчика. Создавать по запросу cgi-процессы и работать с ними асинхронно через sdtio — не такая уж и сложная задача. Для простых «одноразовых» задач, навроде обновления конфига через веб-интерфейс, нет смысла поднимать fcgi-сервер. Поэтому lighttpd
Эти структурированые текстовые форматы суть одно и тоже, плюс-минус «множество восхитительных функций»(с) сверху. Смысла менять одно на другое особого нет. Есть структура и хорошо. Впринципе (для вышеописанной задачи) и ini сгодится. Но JSON популярней. Еще можно XML — он тоже есть почти везде.
Кстати, насчет ini… Мне лично очень понравился toml. Тоже человекочитаемый. Но, в отличие от, реально используется, хоть и в узкой нише (конфиг менеджера пакетов Cargo)
Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками. Не пришлось бы парсить вывод самостоятельно
Виджета Google Keep на телефоне хватает за глаза. Пользуюсь всеми его фичами: несколько списков (личное, работа), напоминалки, фото, наброски. На десктопе доступен через браузер https://keep.google.com/#home
Git так и не научился отдавать один файл/директорию без скачивания всего репозитория со всеми изменениями? Менеджеры пакетов, постоенные на git так и качают 95 избыточных процентов в виде папки .git для каждого пакета?
Вот дядьки из Alljoyn/IoTivity правильно делают. Ядро на Си, обертки на C++/Java/etc. Чтобы один и тот же код работал и на Windows, Android, OpenWRT итд
OpenHAB никогда не понимал. Как должно быть: воткнул устройство в сеть — оно само нашлось и начало работать. Для этого в устройстве должен быть тот же протокол, что и в «шлюзе». Java(или CLR)-машину в умную розетку засунуть конечно можно, но крайне нерационально.
Или другой сценарий: не хватает одного шлюза: поставил второй. Они друг друга нашли и стали единым целым
К чему я веду: действительно универсальный протокол «интернета вещей», ИМХО, это прежде всего децентрализованная система, способная автоматически обнаруживать новые элементы и вообще адекватно реагировать на изменение сети. Это маленькое ядро, которое можно воткнуть на самое разнообразное железо. Это протокол, предоставляющий несколько паттернов общения между девайсами (массовое оповещение, бинарный поток данных, публикация/подписка, RPC, итд). Протокол знающий всё о данных, которые он передает (рефлексия API, стандартные и пользовательские профили для устройств, и т д)
«Шлюзы», которые я вижу последние лет 5 — это просто коробочки, в которые можно воткнуть пару протоколов (и конечно же Philips HUE) + приложение на смартфон… И всё. Ни о какой интеграции с другиги решениями речи не идет. Замкнутая на себе система без души. Следующей ступенью «эволюции», видимо будет шлюз, объединяющий все эти шлюзы
С августа 5 малин показывают браузер круглосуточно. Пока все живы. Из настроек только отключение в конфиге journald записи логов на диск и запуск браузера surf без кеширования. Когда одна из малин помрет, буду делать как у вас, unionfs. Спасибо за статью
У себя обошелся без дисплейного менеджера. Добавил файл /etc/systemd/system/getty@tty1.service.d/override.conf с таким содержанием: [Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin user --noclear %I $TERM
Ну и мышь оставил, т.к. иногда нужно поуправлять работающей малиной напрямую. Программа unclutter скрывает указатель если его пару секунд не теребить
Все изменения в управляющих скриптах подготавливаю в виде deb-пакета на большой машине, затем массово заливаю и инсталирую по ssh. ssh-agent рулит
Если судить по данной статье (и многим других), на данный момент «универсальный стандарт на обмен информацией между устройствами» — это живой человек, интегрирующий всё при помощи скотча и какой-то матери. В результате на одной распберри будут запущенны несколько Java-серверов, шлюзов на node.js (с парой сотен модулей внутри), самописных адаптеров на питоне и т д
Вопрос автору: а почему не взять тот же Openhab (у которого есть поддержка HomeKit) и написать к нему плагины на Java для приведения всего этого зоопарка в несколько более стройную архитектуру?
Скорее из-за принципов и особенностей мышления разработчика. Создавать по запросу cgi-процессы и работать с ними асинхронно через sdtio — не такая уж и сложная задача. Для простых «одноразовых» задач, навроде обновления конфига через веб-интерфейс, нет смысла поднимать fcgi-сервер. Поэтому lighttpd
Через 5 лет будут веб компоненты. Встроят ли в них реакт? К сожалению, да
Менять JSON на Tree
Кстати, насчет ini… Мне лично очень понравился toml. Тоже человекочитаемый. Но, в отличие от, реально используется, хоть и в узкой нише (конфиг менеджера пакетов Cargo)
Всё это вместе в большом WASM-блобе
OpenHAB никогда не понимал. Как должно быть: воткнул устройство в сеть — оно само нашлось и начало работать. Для этого в устройстве должен быть тот же протокол, что и в «шлюзе». Java(или CLR)-машину в умную розетку засунуть конечно можно, но крайне нерационально.
Или другой сценарий: не хватает одного шлюза: поставил второй. Они друг друга нашли и стали единым целым
К чему я веду: действительно универсальный протокол «интернета вещей», ИМХО, это прежде всего децентрализованная система, способная автоматически обнаруживать новые элементы и вообще адекватно реагировать на изменение сети. Это маленькое ядро, которое можно воткнуть на самое разнообразное железо. Это протокол, предоставляющий несколько паттернов общения между девайсами (массовое оповещение, бинарный поток данных, публикация/подписка, RPC, итд). Протокол знающий всё о данных, которые он передает (рефлексия API, стандартные и пользовательские профили для устройств, и т д)
«Шлюзы», которые я вижу последние лет 5 — это просто коробочки, в которые можно воткнуть пару протоколов (и конечно же Philips HUE) + приложение на смартфон… И всё. Ни о какой интеграции с другиги решениями речи не идет. Замкнутая на себе система без души. Следующей ступенью «эволюции», видимо будет шлюз, объединяющий все эти шлюзы
Учите
мемыweb components. Они уж точно не протухнут. А использовать можно уже сейчас, докинув полифилловУ себя обошелся без дисплейного менеджера. Добавил файл /etc/systemd/system/getty@tty1.service.d/override.conf с таким содержанием:
[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin user --noclear %I $TERM
Ну и мышь оставил, т.к. иногда нужно поуправлять работающей малиной напрямую. Программа unclutter скрывает указатель если его пару секунд не теребить
Все изменения в управляющих скриптах подготавливаю в виде deb-пакета на большой машине, затем массово заливаю и инсталирую по ssh. ssh-agent рулит
Вопрос автору: а почему не взять тот же Openhab (у которого есть поддержка HomeKit) и написать к нему плагины на Java для приведения всего этого зоопарка в несколько более стройную архитектуру?