А будут модули I/O с 4/8 каналами ЦАП 0-10В? Было бы очень удобно для управления различными устройствами (диммеры, сервоприводы).
Один канал в модуле расширения ЦАП 0-10В — это, к сожалению, несерьезно.
Знаю, что есть подобные устройства по RS-485, но цена у них кусачая.
При этом для домашних целей точность и разрешение такого ЦАП не особо важна.
Вот только какой резон производителям пищевых продуктов делать цену на обезжиренные продукты ниже? Сейчас тенденция ровно обратная — пихнул в творог (в колбасу, в печенье, куда его теперь только не пихают) пальмового жира, значит продал меньше недешевого творога и больше копеечного жира за ту же цену — PROFIT!
Поначалу он мне даже нравился, но стал слишком навязчивым и надоедливым. То эти красные буковки «N» везде, то какие то сообщения всплывающие типа «немедленно бросай все свои дела и посмотри какую мы клевую ненужную для тебя функцию запилили», то в -цатый раз предлагает защитить мне смс, хотя я этого не хочу. И ведь никак не отключить это всё.
Типичный кейс для веб-сайтов а-ля блог в конфигурации 1 мастер, много слейвов:
1) Пользователь отредактировал статью. Движок послал UPDATE в мастер и инвалидировал кэш веб-страницы с постом.
2) Пользователь (этот же или другой) зашёл на страницу с отредактированной статьей. Лвижок послал SELECT на один из слейвов и получил старые данные, потому что слейв еще не догнал мастера. Старые данные осели в кэше веб-страницы.
3) Пользователь не видит своих правок на странице, F5/Ctrl-R не помогают. Пользователь негодует.
В PostgreSQL это проблема легко решается включением синхронной репликации, а в MySQL как?
Ну так и postgresql заводится с настройками из коробки. На низких нагрузках любая база заводится из коробки. Но автор говорил про большие нагрузки:
Если вы не выставите правильно shared_buffers, настройки автовакуумов и т.д., то на серьёзных нагрузках всё будет медленно работать.
А для серьезных нагрузок на mysql нужно настраивать, как минимум, key_buffer (для myisam, по дефолту 8МБ), query_cache_size (кэш запросов запрещен по дефолту), innodb_buffer_pool_size (для innodb, по дефолту 8МБ), innodb_flush_log_at_trx_commit.
Насколько я читал про другие подобные проекты, главная проблема с которой сталкиваются разработчики — дрейф гироскопов. За пару часов (вполне реальная длительность игровой сессии) гироскопы «уплывают» и требуют повторной калибровки.
Вы эту проблему как нибудь решили?
Я бы не рекомендовал ставить такие большие значения. MySQL будет блокироваться при инвалидации кэша ощутимо дольше, чем при кэше в 128-256MB, что на практике может приводить к «затыкам».
Но расстановка семиколонок и навязанный стандарт gofmt — для меня слишком proprietary and opinionated.
А по-моему, gofmt — одна из самых замечательных вещей в Go. Никаких тебе больше code style guides. Никаких споров о tabs vs spaces и о размерах отступов. Не надо больше думать, переносить фигурную скобку на следующую строчку или нет.
Весь код единообразен и глаз быстро привыкает именно к такому форматированию, что крайне положительно сказывается на легкости чтения.
> Но на 512 MB он не смог выполнить команду assets:precompile, только на 1 GB :) 1 гигабайт памяти на склеивание пару десятков файлов? Кхм…
Это uglifier выжирает память. К ruby он отношения не имеет, так как написан на javascript. И его можно отключить, тогда компиляция assets будет проходить значительно быстрее.
Полагаю, имелась в виду частота дискретизации АЦП, а не разрядность.
Один канал в модуле расширения ЦАП 0-10В — это, к сожалению, несерьезно.
Знаю, что есть подобные устройства по RS-485, но цена у них кусачая.
При этом для домашних целей точность и разрешение такого ЦАП не особо важна.
Всё что нужно знать о создании и сборки deb-пакетов исчерпывающе описано тут — https://www.debian.org/doc/manuals/maint-guide/index.ru.html
1) Пользователь отредактировал статью. Движок послал UPDATE в мастер и инвалидировал кэш веб-страницы с постом.
2) Пользователь (этот же или другой) зашёл на страницу с отредактированной статьей. Лвижок послал SELECT на один из слейвов и получил старые данные, потому что слейв еще не догнал мастера. Старые данные осели в кэше веб-страницы.
3) Пользователь не видит своих правок на странице, F5/Ctrl-R не помогают. Пользователь негодует.
В PostgreSQL это проблема легко решается включением синхронной репликации, а в MySQL как?
А для серьезных нагрузок на mysql нужно настраивать, как минимум,
key_buffer(для myisam, по дефолту 8МБ),query_cache_size(кэш запросов запрещен по дефолту),innodb_buffer_pool_size(для innodb, по дефолту 8МБ),innodb_flush_log_at_trx_commit.Точно такая же ситуация и с mysql. Так что весьма странно записывать это в недостатки postgresql.
Вы эту проблему как нибудь решили?
Я бы не рекомендовал ставить такие большие значения. MySQL будет блокироваться при инвалидации кэша ощутимо дольше, чем при кэше в 128-256MB, что на практике может приводить к «затыкам».
haydenjames.io/mysql-query-cache-size-performance
А по-моему,
gofmt— одна из самых замечательных вещей в Go. Никаких тебе больше code style guides. Никаких споров о tabs vs spaces и о размерах отступов. Не надо больше думать, переносить фигурную скобку на следующую строчку или нет.Весь код единообразен и глаз быстро привыкает именно к такому форматированию, что крайне положительно сказывается на легкости чтения.
Это uglifier выжирает память. К ruby он отношения не имеет, так как написан на javascript. И его можно отключить, тогда компиляция assets будет проходить значительно быстрее.
/etc/mdadm/mdadm.confесть специальный скрипт:/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf