Имхо, несёт вред для здоровья, а не пользу. Мышцы спины атрофируются, усиливая проблему из-за которой и захотелось работать лёжа. Плюс добавляются новые проблемы.
Можно походить к разным докторам, показать систему, спросить будет ли от неё вред.
Да. И становится хуже. Я купил 6 ламп E27 703.887.5, через полгода перегорело 4.
Может дело в люстре. Плафон — открытый, но горизонтальный.
Но до этого аналогичные лампы икея предыдущей серии (6xx) работали ок и в ней (и кстати были тяжелее).
это и есть руками.
вот у вас 100500 разработчиков с какими-то репозиториями. что и где там сравнивать, если вы даже не знаете их адресов, а они даже не знают что что-то взломали, и вас пускать в свою репу не собираются.
в данный момент вы не можете подключиться ко всем, у кого на локальной машине есть копия kernel org и сравнить их коммиты.
В случае если вы хотите получить репо, то вот у вас «множество копий на машинах разработчиков». И вот половина разработчиков говорит что у них оригинальный репозиторий, а вторая говорит, что нет, не у них.
И кого-то из них репозиторий поддельный.
Git — распределённое хранилище. Blockchain то же. Разница в том что в git вопрос «а у кого поддельные коммиты, у кого настоящие» решался руками, на пальцах, а не понятным алгоритмом. А у блокчейна — как встроенная фича.
Ну Proof-of-work — это только про деньги на основе блокчейна, не имеет отношения к другим применениям блокчейна.
Бредовый доклад. Это совершенно две разные модели угроз
1) Устройство потеряли/украли, оно выключилось и где-то лежит. Это сделал квартирный вор, который не собирался/не могу устанавливать кейлоггер и не собирался/не мог сделать так, чтобы никто не заметил что он что-то украл. Кто-то когда-то может извлечь из устройства жёсткий диск и продать настоящим охотникам за информацией.
2) Какие-то (спецслужбы) проникают в жилище без следов взлома, открывают сейф без следов взлома, ставят аппаратный троян (кстати, при чём тут вообще шифрование диска и кейлоггер, если троян может перехватывать уже расшифрованные данные, и ему не нужно расшифровывать диск)
TrueCrypt пишет в своём мануале «Наша программа не защитит никакие данные на компьютере, если атакующий имеет физический доступ к компьютеру до запуска или в процессе работы TrueCrypt» — и это тот максимум, что он может сделать в этой ситуации. Предупредить тех, кто считает что релевантная модель угроз для них — это п.(2).
А остальные могут спокойно использовать п.(1).
Так, по скорости, счас посмотрел у нас явно бывает больше 350 в секунду.
Редис будет быстрее рэббита если написать на нём свою очередь, состоящую из пары команд PUSH/BLPOP, в которой ничего больше нет.
Если сделать так чтобы задачи не терялись в случае любых ситуаций (воркер взял задачу и упал), а так же чтобы не было race condition при различных кейзах, а так же возврат результата работы, + статистика, мониторинг, то будет медленнее.
Проблем с надёжностью редиса не вижу. Гибкость как раз больше у редиса (если самому писать под него систему), т.к. это фактически бэкэнд для системы очередей, а не готовая система очередей.
Сложно сравнивать голый рэббит и некую систему очередей X, которая использует Redis.
По самому редису нет никаких нареканий к надёжности, и гибкости. А скорость обычно пострадает при написании системы очередей под него.
Этот вопрос я так понимаю имеет отношение к скорости редиса. Точных цифр бенчмарков на прод не помню, но сразу могу сказать что он медленнее RabbitMQ, и собственно его скорость зависит от той собственно системы очередей, что используется, у нас своя система, а она сильно влияет на бенчмарки.
Из цифр могу сказать что эпизодически ставятся сотни тысяч задач в очередь и этого никто не замечает, если по ошибке поставить 10млн, то да, память кончится. На этот случай есть мониторинг.
Точно не могу сказать. Он на машине с 32 гигами, выделенными под редис, но в нём не только очереди, но и другие NoSQL данные (в других БД редиса). Ну допустим на максимум 32гб можно ориентироваться. Обычно он жрёт чуть меньше 10Гб.
Понятно. Используем редис. Пока в память влазят миллионы задач, ну а больше нам и не надо, ибо задачи должны быстро обрабатываться, а не копиться, и ненулевое количество задач в очереди вообще нужно для сглаживания пиков нагрузки.
Слышал, что повышенное внутриглазное давление — это противопоказание при обливании холодной водой.
Какими методами стоит обследоваться, чтобы подстраховаться при практиковании таких обливаний?
Можно походить к разным докторам, показать систему, спросить будет ли от неё вред.
Может дело в люстре. Плафон — открытый, но горизонтальный.
Но до этого аналогичные лампы икея предыдущей серии (6xx) работали ок и в ней (и кстати были тяжелее).
в данный момент вы не можете подключиться ко всем, у кого на локальной машине есть копия kernel org и сравнить их коммиты.
вот у вас 100500 разработчиков с какими-то репозиториями. что и где там сравнивать, если вы даже не знаете их адресов, а они даже не знают что что-то взломали, и вас пускать в свою репу не собираются.
в данный момент вы не можете подключиться ко всем, у кого на локальной машине есть копия kernel org и сравнить их коммиты.
И кого-то из них репозиторий поддельный.
Ну Proof-of-work — это только про деньги на основе блокчейна, не имеет отношения к другим применениям блокчейна.
1) Устройство потеряли/украли, оно выключилось и где-то лежит. Это сделал квартирный вор, который не собирался/не могу устанавливать кейлоггер и не собирался/не мог сделать так, чтобы никто не заметил что он что-то украл. Кто-то когда-то может извлечь из устройства жёсткий диск и продать настоящим охотникам за информацией.
2) Какие-то (спецслужбы) проникают в жилище без следов взлома, открывают сейф без следов взлома, ставят аппаратный троян (кстати, при чём тут вообще шифрование диска и кейлоггер, если троян может перехватывать уже расшифрованные данные, и ему не нужно расшифровывать диск)
TrueCrypt пишет в своём мануале «Наша программа не защитит никакие данные на компьютере, если атакующий имеет физический доступ к компьютеру до запуска или в процессе работы TrueCrypt» — и это тот максимум, что он может сделать в этой ситуации. Предупредить тех, кто считает что релевантная модель угроз для них — это п.(2).
А остальные могут спокойно использовать п.(1).
Редис будет быстрее рэббита если написать на нём свою очередь, состоящую из пары команд PUSH/BLPOP, в которой ничего больше нет.
Если сделать так чтобы задачи не терялись в случае любых ситуаций (воркер взял задачу и упал), а так же чтобы не было race condition при различных кейзах, а так же возврат результата работы, + статистика, мониторинг, то будет медленнее.
Проблем с надёжностью редиса не вижу. Гибкость как раз больше у редиса (если самому писать под него систему), т.к. это фактически бэкэнд для системы очередей, а не готовая система очередей.
Сложно сравнивать голый рэббит и некую систему очередей X, которая использует Redis.
По самому редису нет никаких нареканий к надёжности, и гибкости. А скорость обычно пострадает при написании системы очередей под него.
Из цифр могу сказать что эпизодически ставятся сотни тысяч задач в очередь и этого никто не замечает, если по ошибке поставить 10млн, то да, память кончится. На этот случай есть мониторинг.
Что значит "явно не prouduction-ready решение" применительно к редису для очередей?
Слышал, что повышенное внутриглазное давление — это противопоказание при обливании холодной водой.
Какими методами стоит обследоваться, чтобы подстраховаться при практиковании таких обливаний?
я был о лицее лучшего мненияхотя может он его недавно закончил