У китайцев есть дешёвые переключатель резерва - два автомата и моторчик с кочергой. Уже можно не париться с переключением. А если ещё добавить реле времени, которое будет через 3-5 минут замыкать провод датчика масла на корпус - то и ходить глушить генератор не надо.
У меня rpi с HA прямо рядом, поэтому самый дешевый usb-rs485 свисток. Ну и 485 можно по одной витой паре прокинуть на десяток метров. Опять же, если уже есть Wi-Fi пульт - то у него по-любому какое-то api есть, можно его расковырять. Я тоже про этот пульт думал, но вариант с адаптером сильно дешевле оказался.
Есть такое https://ectostroy.ru/heating-control/adapter-navien, с ним можно общаться по modbus. Уже год живу с ним - полет нормальный. Не все идеально, правда. Но мне все что нужно - это только температуру носителя менять. Котел обычный navien deluxe s. Но контуром горячей воды не пользуюсь, поэтому не проверял как он дружит с горячей водой. И еще почему-то не отдает ошибку низкого давления воды, хотя отсутствие газа показывает нормально.
А вы уверены, что вам поменяли регион номера, а не просто перенесли номер в Тиньков и поставили на ваш региональный номер московский тариф? Все номера жестко "прибиты" к регионам и перенести в другой регион разве что только целый блок номеров можно.
Я больше про то, что отчет - это более понятный пользователю инструмент, чем консоль запросов. Понятно, что отчет по факту выполнит этот же самый запрос. Через какое-то время, когда новый инструмент себя зарекомендует, таких сомнений, возможно и не будет.
Вот только бухгалтерия - это все же точная наука. Бухгалтер не поймет сгенеренный запрос, а значит не сможет убедиться, что ему не рандомную цифру показывают. Вот если бы результатом была автоматизированная настройка параметров отчета, вместо ручной, то есть то, что пользователь может сам перепроверить, то тогда можно было бы ощутить реальную пользу.
Есть ощущение, что решение вот прямо сильно прибито гвоздями к методу выдачи внешнего ip у данного, конкретного хостера. Или вообще где-то под капотом включается dnat. Не совсем понятно каким образом шлюз провайдера/хостера "согласился" идти за внешним адресом внутрь туннеля, который совсем не L2, а обычный L3. Ну или я что не понимаю.
"Кластер" из трех контейнеров с сервером 1С на одном физическом хосте - это сильно! Я бы еще предложил таким же образом "кластер" Postgres на соседнем хосте поднять - чтобы интереснее было )
А если по делу - то вопрос: как сервер 1С в контейнерах относится к одному единственному аппаратному ключу? Ну и, я так полагаю, с одной единственной программной лицензией тут ловить, скорей всего, будет нечего, т.к. непонятно, как её "скормить" всем контейнерам, и чтобы они не начали "возмущаться" на тему несовпадения конфигурации системы.
На этапе установки душевого трапа (и подключения его к канализации) - уже можно и остановиться, если что-то потечет - то сразу в канализацию. Датчики, конечно, лишними не будут, но "автоматическое" предотвращение последствий с трапом - еще круче. Можно пол мыть путем выливания ведра воды )
Я не уверен, но когда я с этим разбирался - по омс "удержания" идут не выше какой-то планки, как раз на уровне 50-60 т.р., т.е. вы не "переплачиваете" за это. И с ПФР такая же система вроде бы.
А может быть есть какая-то возможность ограничивать область действия корневых УЦ определенными доменами? Ну, например, пусть бы наши УЦ могли выдавать сертификаты только для наших dns зон и все. Если посмотреть список корневых сертификатов, то можно легко найти, что свои УЦ есть у Китая, Турции, Индии, Пакистана и пр. Неужели все эти УЦ могут выдавать сертификаты на любые домены? Тогда кто мешает тому же Китаю шпионить за всем мировым трафиком? Любопытна эта тема, но не пойму где можно про это почитать подробнее.
Насколько понял из статьи, ОС у вас грузится с sd-карты. Как-то решали проблему поломки загрузки из-за некорректного отключения по питанию? Там же, насколько я помню, /boot - это FAT, и который всегда монтируется в RW. Я когда занимался этим, то довольно часто получалось условно "сломать всё" тупо передергиванием питания во время записи чего-либо на карту.
Вот этот набор знаков переключается нажатием F1 В одном "положении" там как у РК86, а в другом - со строчными русскими буквами. Так через ВВ55 дергается старший бит ПЗУ, в которой в старшей области один набор, а в младшей - другой. И, кажется, на моей версии мироши как раз был второй светодиод, который отображал состояние - т.е. какой знакогенератор выбран. А может и вообще логика другая была, раз версии разные.
Немного странно, вроде стандартные наборы символов должны быть одинаковые. Но спорить не буду - больше 20 лет прошло. Мне даже делали дополнительную ПЗУ с монитором от РК86 (модифицированным под микрошу) и триггер - можно было переключаться между мониторами сбросом. И некоторые программы от РК86 вроде бы без изменений запускались. Но это не точно )
Я имел ввиду загрузчик, который формат записи "понимает", но вот не помню точно, возможно это было в обратную сторону - загрузка с кассет программ микроши в РК86. Это если захочется поковыряться. А "трансляторов" на лету я не припомню, чтобы исправляли нюансы кода. Кодировка там одинаковая, только в Микроше добавили захардкоженный шрифт с маленькими буквами, который переключается по кнопке F1. И больше эта кнопка ничего не делает ) Ну и если программы написаны строго используя стандартные функции "Монитора", которые у микроши и РК86 совпадают по адресам, то они вполне переносимы.
кажется есть "загрузчик", который умеет в микрошу грузить программы от РК86 но там потом другие проблемы могут быть - немного разная адресация, не все программы заработают
А в надежности приложения-клиента вы уверены на 100%? Кто-то может подтвердить, что ваши ключи сразу же в момент создания не были скопированы на сервер?
А что WA или кто-то еще дает гарантии и доказательства, что ключи от вашего E2E к себе заботливо не сохраняет? У Телеграма хотя бы протокол известен и особо желающие имеют потенциальную возможность скомпилить себе клиента из исходников, в котором можно проанализировать код и т.д. и.т.п.
Еще стоит посмотреть на ubuntu cloud images Там готовые образы под разные платформы (я использовал для KVM) Они "вычищенные" и имеют минимальный размер. При первой загрузке корень автоматом расширяется на весь доступный размер выданного диска. Для передачи информации в cloud init я использовал подключенный к виртуалке iso-образ, который генерируется из конфигов с помощью cloud-localds (пакет cloud-image-utils)
У китайцев есть дешёвые переключатель резерва - два автомата и моторчик с кочергой. Уже можно не париться с переключением. А если ещё добавить реле времени, которое будет через 3-5 минут замыкать провод датчика масла на корпус - то и ходить глушить генератор не надо.
У меня rpi с HA прямо рядом, поэтому самый дешевый usb-rs485 свисток. Ну и 485 можно по одной витой паре прокинуть на десяток метров. Опять же, если уже есть Wi-Fi пульт - то у него по-любому какое-то api есть, можно его расковырять. Я тоже про этот пульт думал, но вариант с адаптером сильно дешевле оказался.
Есть такое https://ectostroy.ru/heating-control/adapter-navien, с ним можно общаться по modbus. Уже год живу с ним - полет нормальный. Не все идеально, правда. Но мне все что нужно - это только температуру носителя менять. Котел обычный navien deluxe s. Но контуром горячей воды не пользуюсь, поэтому не проверял как он дружит с горячей водой. И еще почему-то не отдает ошибку низкого давления воды, хотя отсутствие газа показывает нормально.
А вы уверены, что вам поменяли регион номера, а не просто перенесли номер в Тиньков и поставили на ваш региональный номер московский тариф?
Все номера жестко "прибиты" к регионам и перенести в другой регион разве что только целый блок номеров можно.
Я больше про то, что отчет - это более понятный пользователю инструмент, чем консоль запросов. Понятно, что отчет по факту выполнит этот же самый запрос.
Через какое-то время, когда новый инструмент себя зарекомендует, таких сомнений, возможно и не будет.
Вот только бухгалтерия - это все же точная наука.
Бухгалтер не поймет сгенеренный запрос, а значит не сможет убедиться, что ему не рандомную цифру показывают.
Вот если бы результатом была автоматизированная настройка параметров отчета, вместо ручной, то есть то, что пользователь может сам перепроверить, то тогда можно было бы ощутить реальную пользу.
Есть ощущение, что решение вот прямо сильно прибито гвоздями к методу выдачи внешнего ip у данного, конкретного хостера.
Или вообще где-то под капотом включается dnat.
Не совсем понятно каким образом шлюз провайдера/хостера "согласился" идти за внешним адресом внутрь туннеля, который совсем не L2, а обычный L3.
Ну или я что не понимаю.
"Кластер" из трех контейнеров с сервером 1С на одном физическом хосте - это сильно!
Я бы еще предложил таким же образом "кластер" Postgres на соседнем хосте поднять - чтобы интереснее было )
А если по делу - то вопрос: как сервер 1С в контейнерах относится к одному единственному аппаратному ключу?
Ну и, я так полагаю, с одной единственной программной лицензией тут ловить, скорей всего, будет нечего, т.к. непонятно, как её "скормить" всем контейнерам, и чтобы они не начали "возмущаться" на тему несовпадения конфигурации системы.
На этапе установки душевого трапа (и подключения его к канализации) - уже можно и остановиться, если что-то потечет - то сразу в канализацию.
Датчики, конечно, лишними не будут, но "автоматическое" предотвращение последствий с трапом - еще круче. Можно пол мыть путем выливания ведра воды )
Я не уверен, но когда я с этим разбирался - по омс "удержания" идут не выше какой-то планки, как раз на уровне 50-60 т.р., т.е. вы не "переплачиваете" за это.
И с ПФР такая же система вроде бы.
А может быть есть какая-то возможность ограничивать область действия корневых УЦ определенными доменами? Ну, например, пусть бы наши УЦ могли выдавать сертификаты только для наших dns зон и все.
Если посмотреть список корневых сертификатов, то можно легко найти, что свои УЦ есть у Китая, Турции, Индии, Пакистана и пр. Неужели все эти УЦ могут выдавать сертификаты на любые домены? Тогда кто мешает тому же Китаю шпионить за всем мировым трафиком?
Любопытна эта тема, но не пойму где можно про это почитать подробнее.
Насколько понял из статьи, ОС у вас грузится с sd-карты. Как-то решали проблему поломки загрузки из-за некорректного отключения по питанию? Там же, насколько я помню, /boot - это FAT, и который всегда монтируется в RW. Я когда занимался этим, то довольно часто получалось условно "сломать всё" тупо передергиванием питания во время записи чего-либо на карту.
Вот этот набор знаков переключается нажатием F1
В одном "положении" там как у РК86, а в другом - со строчными русскими буквами.
Так через ВВ55 дергается старший бит ПЗУ, в которой в старшей области один набор, а в младшей - другой.
И, кажется, на моей версии мироши как раз был второй светодиод, который отображал состояние - т.е. какой знакогенератор выбран.
А может и вообще логика другая была, раз версии разные.
Немного странно, вроде стандартные наборы символов должны быть одинаковые. Но спорить не буду - больше 20 лет прошло.
Мне даже делали дополнительную ПЗУ с монитором от РК86 (модифицированным под микрошу) и триггер - можно было переключаться между мониторами сбросом.
И некоторые программы от РК86 вроде бы без изменений запускались. Но это не точно )
Я имел ввиду загрузчик, который формат записи "понимает", но вот не помню точно, возможно это было в обратную сторону - загрузка с кассет программ микроши в РК86. Это если захочется поковыряться.
А "трансляторов" на лету я не припомню, чтобы исправляли нюансы кода.
Кодировка там одинаковая, только в Микроше добавили захардкоженный шрифт с маленькими буквами, который переключается по кнопке F1. И больше эта кнопка ничего не делает )
Ну и если программы написаны строго используя стандартные функции "Монитора", которые у микроши и РК86 совпадают по адресам, то они вполне переносимы.
кажется есть "загрузчик", который умеет в микрошу грузить программы от РК86
но там потом другие проблемы могут быть - немного разная адресация, не все программы заработают
А в надежности приложения-клиента вы уверены на 100%?
Кто-то может подтвердить, что ваши ключи сразу же в момент создания не были скопированы на сервер?
А что WA или кто-то еще дает гарантии и доказательства, что ключи от вашего E2E к себе заботливо не сохраняет?
У Телеграма хотя бы протокол известен и особо желающие имеют потенциальную возможность скомпилить себе клиента из исходников, в котором можно проанализировать код и т.д. и.т.п.
А еще провайдеры любят раздавать эти адреса под видом "белых" - мало кто знает про этот диапазон.
Еще стоит посмотреть на ubuntu cloud images
Там готовые образы под разные платформы (я использовал для KVM)
Они "вычищенные" и имеют минимальный размер.
При первой загрузке корень автоматом расширяется на весь доступный размер выданного диска.
Для передачи информации в cloud init я использовал подключенный к виртуалке iso-образ, который генерируется из конфигов с помощью cloud-localds (пакет cloud-image-utils)