Запросто может быть и так. Тем более раньше были уже попытки давать другим производителям делать свои колонки с Алисой. В том числе участвовала и JBL. Получилось тогда не очень. Но можно и с другой стороны зайти - пусть делают колонки под заказ.
А почему вы выбрали для передачи данных wifi и изобретали велосипед, когда, например, zigbee по стандарту умеет строить сеть динамически, маршрутизируя данные через узлы-роутеры, и обладает высокой экономичностью для конечных устройств. BLE-Mesh туда же. LoRa ещё.
А можно ссылку? Я таких статей не видел. Я знаю что можно либо не выключать модем, но это слишком энергозатратно, либо выключать, но тогда надо устанавливать соединение, что долго, а потому энергозатратно.
В статье же как раз и написано, что из-за неизвестной и изменчивой плотности снега, измерять высоту довольно бесполезно. Важна снеговая нагрузка на перекрытие. Поэтому датчиком известной площади измеряется масса снега в нескольких точках с наихудшими условиями.
Ионообменная смола, конечно убирает соли жесткости, но не убирает соли как таковые, только заменяет одни на другие - производит замену ионов. И эти соли при испарении распыляемой воды неизбежно выпадут мелкодисперсной пылью. Так же как и при использовании ультразвуковых увлажнителей.
Проблема пофикшена у Амазона, а вот Яндекс Облако, которое мне куда ближе, сообщает, что они берут деньги за ошибочные запросы. И вероятно не они одни.
Я что-то не понимаю в этих графиках. Если на них отражены баллы теста, то больше - лучше. А после перенормировки на рубль становится "меньше - лучше". Чем меньше баллов производительности тебе дают за рубль тем лучше? Или что значат эти графики?
Там явно написано, что это следует делать, если ваш софт сам создаёт бакеты, чтобы избежать конфликта имён. Если ты создаёшь фиксированные бакеты, это не является необходимым. Это не делается, чтобы скрыть имя бакета.
Если на клиенте используются подписанные короткоживущие ссылки для получения или загрузки файлов, то кто угодно может узнать из таких ссылок имя бакета.
Понятно, что у них есть основания тарифицировать этот трафик. Но это ведёт к тому, что он может использоваться для атак. И с одной стороны владельцу сервиса как бы всё равно, он деньги получит, даже избыточные. Но это и привлекательности для клиентов угрожает. Наверное, лучше эти запросы не тарифицировать, а компенсировать их стоимость чуть более высокой стоимостью остальных запросов. Тогда не будет стимула использовать их для атак на кошелёк клиентов сервиса. Тогда появляется возможность атаки на сам сервис. Но у них и возможности для борьбы с этим больше, чем у клиентов.
Операции GET, HEAD, OPTIONS, PATCH, POST и PUT, закончившиеся с ошибками 403 или 404, тарифицируются. При расчете стоимости применяются тарифы для стандартного хранилища.
У меня в ванной сначала стояла Мини первого поколения, сейчас стоит Миди. Обе хорошо слышат команды из душа.
Запросто может быть и так. Тем более раньше были уже попытки давать другим производителям делать свои колонки с Алисой. В том числе участвовала и JBL. Получилось тогда не очень. Но можно и с другой стороны зайти - пусть делают колонки под заказ.
А почему вы выбрали для передачи данных wifi и изобретали велосипед, когда, например, zigbee по стандарту умеет строить сеть динамически, маршрутизируя данные через узлы-роутеры, и обладает высокой экономичностью для конечных устройств. BLE-Mesh туда же. LoRa ещё.
А можно ссылку? Я таких статей не видел. Я знаю что можно либо не выключать модем, но это слишком энергозатратно, либо выключать, но тогда надо устанавливать соединение, что долго, а потому энергозатратно.
В статье же как раз и написано, что из-за неизвестной и изменчивой плотности снега, измерять высоту довольно бесполезно. Важна снеговая нагрузка на перекрытие. Поэтому датчиком известной площади измеряется масса снега в нескольких точках с наихудшими условиями.
У Яндекса здесь на Хабре есть статьи в которых рассказывается и о разработке акустики в Станциях.
То что Яндекс колонки производит в Китае - совершенно очевидно. Но до сей поры разрабатывали они их самостоятельно.
Да и некоторые неаккустические свойства колонки тоже улучшает. Например водонепроницаемость.
Обидно, что статья просто рекламирует компанию и продукт. Ничего про оптимизацию печати здесь нет. Всё это абсолютно бесполезно.
Ионообменная смола, конечно убирает соли жесткости, но не убирает соли как таковые, только заменяет одни на другие - производит замену ионов. И эти соли при испарении распыляемой воды неизбежно выпадут мелкодисперсной пылью. Так же как и при использовании ультразвуковых увлажнителей.
Да не в соседнюю комнату. Розетка в соседней секции мебели (предположительно кухонного гарнитура)
Они пишут, что тарифицируются запросы с ответом 403, что, по-моему, означает "да" на ваш вопрос.
Проблема пофикшена у Амазона, а вот Яндекс Облако, которое мне куда ближе, сообщает, что они берут деньги за ошибочные запросы. И вероятно не они одни.
Я что-то не понимаю в этих графиках. Если на них отражены баллы теста, то больше - лучше. А после перенормировки на рубль становится "меньше - лучше". Чем меньше баллов производительности тебе дают за рубль тем лучше? Или что значат эти графики?
Да, хорош! Об этом уже дважды до вас написали, но проблема не только у AWS.
А как быть с публичными ссылками? В них есть имя бакета.
Там явно написано, что это следует делать, если ваш софт сам создаёт бакеты, чтобы избежать конфликта имён. Если ты создаёшь фиксированные бакеты, это не является необходимым. Это не делается, чтобы скрыть имя бакета.
Если на клиенте используются подписанные короткоживущие ссылки для получения или загрузки файлов, то кто угодно может узнать из таких ссылок имя бакета.
Понятно, что у них есть основания тарифицировать этот трафик. Но это ведёт к тому, что он может использоваться для атак. И с одной стороны владельцу сервиса как бы всё равно, он деньги получит, даже избыточные. Но это и привлекательности для клиентов угрожает. Наверное, лучше эти запросы не тарифицировать, а компенсировать их стоимость чуть более высокой стоимостью остальных запросов. Тогда не будет стимула использовать их для атак на кошелёк клиентов сервиса. Тогда появляется возможность атаки на сам сервис. Но у них и возможности для борьбы с этим больше, чем у клиентов.
Посмотрел документацию Yandex Cloud Object Storage:
Страшно жить!
Речь ведь про AWS S3, это он отдаёт эти коды, а не ваше ПО.