Для андроид есть такое замечательное приложение Adguard от Российских разработчиков. В бесплатном режиме режет рекламы только в браузерах. В платной версии - вообще во всех приложениях. Купил много лет назад назад вечную лицензию и ни разу не пожалел, да и стоит копейки. Можно установить как режиме прокси, так и в режиме локального vpn. Если немного пошаманить с установкой сертификата, можно и в https трафике блочить рекламу
Не обязательно KeePassXC, он мне показался жутко неудобным, хотя может UI и улучшили, конечно со старых времён, когда хотел смигрировать. Пользуюсь 10+ лет оригинальным KeePass, Linux+изредка Windows параллельно. Конечно с синхронизацией вот тут не сильно удобно, KeePassXC в этом плане намного лучше. Собственно по этой причине и хотел перейти на него несколько лет назад.
Не понимаю в чём связь с почтовым сервером, который помимо почты умеет XMMP и VoIP с текстовыми процессорами. Это класс программ это MS Exchange или Zimbra, но ни как MS Office. Или речь идёт о другом продукте? Просто раньше Communigate Pro был почтовым сервером с XMMP и зачатками sip-телефонии. Внедрял однажды заказчику на замену Exchange
Несколько лет назад, году в 2018-2019, был подключен последней милей через радиоканал, всё работало стабильно, тот же speedtest почти выдавал положенные 100мбит/c, плюс адекватные пинги, без просадок, но в какой-то момент начались большие проблемы с видео на youtube. Видео могло начать загружаться после N-ного количества обновлений страницы, постоянно останавливалось на буферизации, по несколько раз в минуту, ад был в общем. И хроме и в ФФ, без разницы. Хотя в это же время с RDP через UDP до рабочих серверов вообще никаких проблем не было,
В итоге выключил в ФФ поддержку quic, и всё сразу нормализовалось.
Ваш коллега из 2017 года https://habr.com/ru/company/otus/blog/340870/ хотя бы не говорил сделать например вот так: net.ipv4.tcp_window_scaling = 1 а написал, такое значение плохо, а такое хорошо.
Уже в те времена все основные дистрибутивы включали эту опцию по умолчанию в своихсборках. Путаете только людей чтобы забивали sysctl.conf ненужным мусором. Похоже на перевод статьи года из начала 2000х про RedHat6 или около того.
Не на 3м месте, а на 5м, если верить описанию по указанной в статье ссылке phoronix . Просто на графике почему-то подписаны через один. На третьем месте - Debian с 15,3%.
38.9% of the respondents were said to be using Ubuntu while interesting in second place was Arch Linux at 27.1% followed by Debian at 15.3%. Rounding out the top ten were then Fedora at 14.8%, Linux Mint in 5th at 10.8%
Я одно время использовал его как сборочную машину для гитхаба на приватном репозитории, но уж больно медленно работает, cpu даже в относительно бюджетном смартфоне сейчас даже быстрее чем атом 525 )
Купил Asus 1215N в далёком 2011 году. Служил верой и правдой до 2018го, пока жёсткий диск не посыпался. Заменил на ssd, накатил линукс вместо винды, но аппаратное ускорение так и не смог нормально завести на NVIDIA Optimus, дискретный адаптер никак не захотел подключаться, слайд шоу вместо видео. Там первая версия Optimus, и как я понял линукс не умеет с ней общаться. Это недостаток старых девайсов. Так и лежит без дела, выбрасывать жалко.
Важное замечание: не следует использовать amqproxy для consumer, есть проблемы одностороннего разрушения соединений.
А вот столкнулись тут недавно с одной проблемой, связанной с проксированием, что через amqproxy, что через haproxy, через какое-то время перестают приходить ответы на rpc запросы в celery.
Если celery.broker и celery.backend указать на сам сервер rabbitMQ, то всё работает стабильно. Но через проси нет, задача создаётся в брокере, но от нескольких минут до нескольких часов проходит, и просто перестаёт приходить ответ. Причём через этого же самого брокера сообщения в очереди уходят, но механизм rpc ломается.
Было подозрение что столкнулись с "флаппингом каналов", про него тоже в статье упомянули, очень сильно увеличилось время ответа, и как раз порядок кол-ва примерно похож, но с проксированием ничего не получилось. Пока решилось переработкой логики продюсеров, но вопрос остался, что не так с проксированием ampq.
growpart ставить необязательно. В современных версиях parted давно есть команда resizepart. Также если на диске экстремально мало места, могут возникнуть проблемы за запуском growpart (для работы создаёт временные файлы в /tmp). У parted resizepart такой проблемы нет.
Я также видел случаи, когда проверка на nullptr в функции была опущена попросту потому что было сложно решить, что делать в случае nullptr. Например, когда nullptr получает функция, которая возвращает void.
Это лучшее оправдание говнокода которое я видел. Нормально подогнать сигнатуру функции под код, но не код под сигнатуру, который ещё и работать будет с вероятностью 50/50 при этом.
Пример из жизни. У товарища банкомат не принимает карту, я ему говорю, ладно, забей. Ну он он и забил. Буквально вдавил в картоприёмник. Неделю стрелял денег пока инкассация не прошла.
На 6,5 диагонали смотреть очень даже комфортно, даже более чем. Для эксперимента увеличил масштаб, получилось вообще нечитаемо, видимо потому что интервал между строк тоже увеличился. Видел решение на некоторых сайтах кнопки увеличить/уменьшить шрифт. Думаю это идеальное решение.
Не совсем так, горизонтальное масштабирование возможно и когда порядок сообщений важно не нарушить.
Группы консумеров всё-таки классная штука. Один консумер может читать одновременно из нескольких партиций, но уже два консумера одновременно читать из одной партиции не могут, один из них будет всегда в режиме ожидания. Можно несколько консумеров сразу запустить на один топик, они поделят между собой партиции "случайным" образом. Может один консумер захватить все сразу партиции и читать из всех них, а могут поделить, один консумер читает одну часть партиций, второй - другую.
Если на первом произойдёт сбой, второй автоматически подхватит из режима ожидания и собственно продолжить читать сообщения из всех сразу партиций.
Вот здесь как раз и важен ключ партицирования, чтобы сообщение маршрутизировалось всегда в одну и ту же партицию. Без указания этого ключа сообщение практически рэндомно будет помещаться в любую партицию в топике. В опциях консумера даже можно выбрать алгоритм каким образом это будет происходить, но по сути это будет происходить случайным образом. Хотите постоянности, указывайте partition key при отправке сообщения в кафку продюсером.
При использовании групп консумеров в итоге не важно в каком из конкретных экземпляров консумеров происходит чтение партиции. Это и есть горизонтальное масштабирование, узел целиком упал, но второй консумер автоматом подхватил и смаршрутизировал всё что недоставлено в те же самые очереди и топики.
Моей ошибкой когда я разбирался в этом, было вычисление промежуточных данных и кеширование непосредственно в процессе-экземпляре конкретного консумера, чтобы разгрузить приёмник сообщений, и при падении консумера, конечно же всё это терялось. А второй подхватывал с пустым кешем, что в итоге ломало всю вышестоящую логику.
гарантия, что сообщения будут прочитаны в порядке их попадания в хранилище;
Kafka гарантирует строгую упорядоченность только в пределах одной партиции. Если топик разбит на две или более партиции, упорядоченность можно сохранить в пределах каждой отдельно взятой партиции, если при записи в топик указать ключ партицирования. Kafka гарантирует, что сообщения с одним и тем же ключом партицирования будут попадать в одну и ту же партицию, тогда упорядоченность сохраниться, но в пределах отдельных партиций. И при горизонтальном масштабировании с использованием групп консемеров, нужно это учитывать.
Полностью согласен, конечно же так нельзя делать. У меня много карт разных банков, но кроме как от имени Сбера мне ни разу никто из мошенников не звонил. Один раз даже назвали часть номера карты. После этого я отказался от хранения денег в нём. И поэтому в этом конкретном случае, я могу себе позволить так шутить. Но после разговора все равно обязательно сообщаю в настоящий Сбер о звонке и номере телефона.
Служба безопасности Сбербанка. От вас был перевод 15тыс Иванову Рашиду Оксидовичу подтверждаете? Подтверждаю. Разблокируйте пожалуйста перевод. (усиленно думают и чаще всего кладут трубку) Хотя некоторые не сдаются с первого раза, но это уже другая история. У меня нет уже давно этой карты.
Не нужно себя втягивать в разговор. Единственное правило.
А в моём варианте так ведь и есть, если не было изменений в репозитории, скрипт завершится с кодом ошибки 1. Если изменения были, изменения вытянутся через git pull и после этого можно перегенерировать список хостов. Можно сделать вокруг него скрипт-обвязку, проверять код возврата, и принимать решение. А можно сразу после git pull дописать свой код. Мне было удобнее сделать обвязку.
Никак наверное, только в режим прокси переводить adguad
Честно не знаю. Фильтрация https у меня только в браузере включена.
Не у всех есть где его развернуть, а так да, штука хорошая
Для андроид есть такое замечательное приложение Adguard от Российских разработчиков. В бесплатном режиме режет рекламы только в браузерах. В платной версии - вообще во всех приложениях. Купил много лет назад назад вечную лицензию и ни разу не пожалел, да и стоит копейки. Можно установить как режиме прокси, так и в режиме локального vpn. Если немного пошаманить с установкой сертификата, можно и в https трафике блочить рекламу
Не обязательно KeePassXC, он мне показался жутко неудобным, хотя может UI и улучшили, конечно со старых времён, когда хотел смигрировать. Пользуюсь 10+ лет оригинальным KeePass, Linux+изредка Windows параллельно. Конечно с синхронизацией вот тут не сильно удобно, KeePassXC в этом плане намного лучше. Собственно по этой причине и хотел перейти на него несколько лет назад.
Несколько лет назад, году в 2018-2019, был подключен последней милей через радиоканал, всё работало стабильно, тот же speedtest почти выдавал положенные 100мбит/c, плюс адекватные пинги, без просадок, но в какой-то момент начались большие проблемы с видео на youtube. Видео могло начать загружаться после N-ного количества обновлений страницы, постоянно останавливалось на буферизации, по несколько раз в минуту, ад был в общем. И хроме и в ФФ, без разницы. Хотя в это же время с RDP через UDP до рабочих серверов вообще никаких проблем не было,
В итоге выключил в ФФ поддержку quic, и всё сразу нормализовалось.
Ну зачем (
Было сильное чувство дежавю и я вспомнил
Ваш коллега из 2017 года https://habr.com/ru/company/otus/blog/340870/ хотя бы не говорил сделать например вот так:
net.ipv4.tcp_window_scaling = 1 а написал, такое значение плохо, а такое хорошо.Уже в те времена все основные дистрибутивы включали эту опцию по умолчанию в своихсборках. Путаете только людей чтобы забивали sysctl.conf ненужным мусором. Похоже на перевод статьи года из начала 2000х про RedHat6 или около того.
/
Не на 3м месте, а на 5м, если верить описанию по указанной в статье ссылке phoronix . Просто на графике почему-то подписаны через один. На третьем месте - Debian с 15,3%.
Я одно время использовал его как сборочную машину для гитхаба на приватном репозитории, но уж больно медленно работает, cpu даже в относительно бюджетном смартфоне сейчас даже быстрее чем атом 525 )
А торренты роутер качает, он же dnla раздаёт
Купил Asus 1215N в далёком 2011 году. Служил верой и правдой до 2018го, пока жёсткий диск не посыпался. Заменил на ssd, накатил линукс вместо винды, но аппаратное ускорение так и не смог нормально завести на NVIDIA Optimus, дискретный адаптер никак не захотел подключаться, слайд шоу вместо видео. Там первая версия Optimus, и как я понял линукс не умеет с ней общаться. Это недостаток старых девайсов. Так и лежит без дела, выбрасывать жалко.
Отличная статья!
А вот столкнулись тут недавно с одной проблемой, связанной с проксированием, что через amqproxy, что через haproxy, через какое-то время перестают приходить ответы на rpc запросы в celery.
Если celery.broker и celery.backend указать на сам сервер rabbitMQ, то всё работает стабильно. Но через проси нет, задача создаётся в брокере, но от нескольких минут до нескольких часов проходит, и просто перестаёт приходить ответ. Причём через этого же самого брокера сообщения в очереди уходят, но механизм rpc ломается.
Было подозрение что столкнулись с "флаппингом каналов", про него тоже в статье упомянули, очень сильно увеличилось время ответа, и как раз порядок кол-ва примерно похож, но с проксированием ничего не получилось. Пока решилось переработкой логики продюсеров, но вопрос остался, что не так с проксированием ampq.
growpart ставить необязательно. В современных версиях parted давно есть команда resizepart. Также если на диске экстремально мало места, могут возникнуть проблемы за запуском growpart (для работы создаёт временные файлы в /tmp). У parted resizepart такой проблемы нет.
Это лучшее оправдание говнокода которое я видел. Нормально подогнать сигнатуру функции под код, но не код под сигнатуру, который ещё и работать будет с вероятностью 50/50 при этом.
Пример из жизни. У товарища банкомат не принимает карту, я ему говорю, ладно, забей. Ну он он и забил. Буквально вдавил в картоприёмник. Неделю стрелял денег пока инкассация не прошла.
ASN.1 используется также и в протоколе SNMP всех версий. Думаю этот формат с нами надолго.
На 6,5 диагонали смотреть очень даже комфортно, даже более чем. Для эксперимента увеличил масштаб, получилось вообще нечитаемо, видимо потому что интервал между строк тоже увеличился. Видел решение на некоторых сайтах кнопки увеличить/уменьшить шрифт. Думаю это идеальное решение.
Скрин
Не совсем так, горизонтальное масштабирование возможно и когда порядок сообщений важно не нарушить.
Группы консумеров всё-таки классная штука. Один консумер может читать одновременно из нескольких партиций, но уже два консумера одновременно читать из одной партиции не могут, один из них будет всегда в режиме ожидания. Можно несколько консумеров сразу запустить на один топик, они поделят между собой партиции "случайным" образом. Может один консумер захватить все сразу партиции и читать из всех них, а могут поделить, один консумер читает одну часть партиций, второй - другую.
Если на первом произойдёт сбой, второй автоматически подхватит из режима ожидания и собственно продолжить читать сообщения из всех сразу партиций.
Вот здесь как раз и важен ключ партицирования, чтобы сообщение маршрутизировалось всегда в одну и ту же партицию. Без указания этого ключа сообщение практически рэндомно будет помещаться в любую партицию в топике. В опциях консумера даже можно выбрать алгоритм каким образом это будет происходить, но по сути это будет происходить случайным образом. Хотите постоянности, указывайте partition key при отправке сообщения в кафку продюсером.
При использовании групп консумеров в итоге не важно в каком из конкретных экземпляров консумеров происходит чтение партиции. Это и есть горизонтальное масштабирование, узел целиком упал, но второй консумер автоматом подхватил и смаршрутизировал всё что недоставлено в те же самые очереди и топики.
Моей ошибкой когда я разбирался в этом, было вычисление промежуточных данных и кеширование непосредственно в процессе-экземпляре конкретного консумера, чтобы разгрузить приёмник сообщений, и при падении консумера, конечно же всё это терялось. А второй подхватывал с пустым кешем, что в итоге ломало всю вышестоящую логику.
Это мой личный экспириенс )
Kafka гарантирует строгую упорядоченность только в пределах одной партиции. Если топик разбит на две или более партиции, упорядоченность можно сохранить в пределах каждой отдельно взятой партиции, если при записи в топик указать ключ партицирования. Kafka гарантирует, что сообщения с одним и тем же ключом партицирования будут попадать в одну и ту же партицию, тогда упорядоченность сохраниться, но в пределах отдельных партиций. И при горизонтальном масштабировании с использованием групп консемеров, нужно это учитывать.
Полностью согласен, конечно же так нельзя делать. У меня много карт разных банков, но кроме как от имени Сбера мне ни разу никто из мошенников не звонил. Один раз даже назвали часть номера карты. После этого я отказался от хранения денег в нём. И поэтому в этом конкретном случае, я могу себе позволить так шутить. Но после разговора все равно обязательно сообщаю в настоящий Сбер о звонке и номере телефона.
Много лет мой диалог звучит примерно так
Служба безопасности Сбербанка. От вас был перевод 15тыс Иванову Рашиду Оксидовичу подтверждаете? Подтверждаю. Разблокируйте пожалуйста перевод. (усиленно думают и чаще всего кладут трубку) Хотя некоторые не сдаются с первого раза, но это уже другая история. У меня нет уже давно этой карты.
Не нужно себя втягивать в разговор. Единственное правило.
А в моём варианте так ведь и есть, если не было изменений в репозитории, скрипт завершится с кодом ошибки 1. Если изменения были, изменения вытянутся через git pull и после этого можно перегенерировать список хостов. Можно сделать вокруг него скрипт-обвязку, проверять код возврата, и принимать решение. А можно сразу после git pull дописать свой код. Мне было удобнее сделать обвязку.
Я таким способом проверяю обновления z-i без выкачивания всего репозитория: