Вот не понимаю я этих восторгов по поводу ZFS: "что ZFS — удобная, функциональная и вообще единственная правильная файловая система". Я дважды всерьез пытался ее использовать, оба раза не удачно. Первый раз на работе. Тогда мы, начитавшись восторженных статей о ZFS, попробавали перевести на нее раздел с данными postgres. Падение производительности на десятки процентов по сравнению с ext4 (порядка 90% нагрузки - запись), быстро заставили отказаться от этой идеи.
Второй раз - на домашнем NAS. У меня, условно, 4 диска, на которых я хочу динамически создавать разделы с разным уровнем избыточности, от stripe до 4-way mirror. Это элементарно делается при помощи LVM. Однако в случае ZFS я должен заранее спланировать распределение физических разделов по уровням избыточности, что, в моем случае, очевидно неприемлемо.
ИМХО, с точки зрения обхода бокрировок, совершенно не раскрыта основная идея этого самого "Middleman". Если у вас есть VPS в России, трафик с которого зарубеж не фильтруется (а такие есть), то второй VPS и туннель до него уже не нужен. Аналогично и с условным "Армянским" VPS. Если до него ничего не блокируется, то и дальше все вполне нормально.
Даже директор нигде не выборная должность, хотя демократия и выборы должны обеспечить лучшего кандидата. Почему?
Потому что основная цель фирмы - исполнять хотелки владельца (в простейшем случае - приносить прибыль). У государства, постулируемая цель, вроде бы другая.
Вот кстати да, в таких статьях-инструкциях зачастую очень не хватает, где-нибудь в начале, описания общими словами, как же именно работает представленное решение.
Еще ни разу не встречал действительно полезного чат-бота в качестве саппорта. Единственное исключение - когда нужно сделать какую-то типовую операцию, типа заказать справку, подать поручение, закрыть или открыть продукт, и т.п. Но опять же, такие типовые вещи гораздо удобнее делать через систему меню или другой структурированный интерфейс.
В отальном, общение с чат ботами сводится к тому, чтобы всеми правдами и неправдами добратья до живого человека.
Именно в этом месте документацию не поправили. В отличие например от описания параметра stats_temp_directory, которая и задает расположение этого каталога.
Вот тут: https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/ хорошо описано, что там сделали с коллектором статистики, и, в частности, почему каталог pg_stat_tmp все же оставили. Кратко - для совместимости с расширениями, которые могут полагаться на наличие этого каталога.
Совершенно непонятно, в чем претензия? Функция не включена по умолчанию, при включении описание вполне исчерпывающее. Лично вам не нужно, так не включайте.
Спасибо, хорошая обзорная статья, действительно полезная как стартовая точка. Чего как мне кажется не хватает, так это практических примеров. Кроме простого констатирования о сложности генерирования "одноглазого пирата с повязкой и эполетами, держащего в левой руке топор", хотелось бы увидеть как его все же можно получить, используя описываемый инструментарий.
Дорогой тезка, преогромнейшее тебе спасибо! Именно то, что я давно искал среди монструозных комбайнов, но ленился сделать сам. Единственно что могу предложить, это заменить cp на ln, чтобы места лишнего не занимать.
Я правильно понимаю, что любой, кто может отправить на ваш файрвол SYN-пакет с поддельным src IP, эффективно заблокирует вам любой IP, да хоть весь интернет?
В статье перепутана WBT, которая определяется исключительно температурой окружающего воздуха и влажностью, и WBGT из таблички, в которую входит еще и солнечное излучение. WBGT для своего тела можно существенно уменьшить одевшись в белое, или вообще превратить в WBT при помощи зонтика. А WBT никогда не может быть выше температуры окружающего воздуха.
Буферизация прокси-сервера означает, что NGINX сохраняет ответ с сервера во внутренних буферах по мере его поступления и не начинает отправлять данные клиенту до тех пор, пока весь ответ не будет буферизован.
Мне кажется что здесь неправильно описан механизм буферизации. Что интересно, в руководстве администратора NGINX Plus, тоже написано что данные клиенту не передаются до полного вычитывания ответа с апстрима, хотя в основной документации ничего такого нет. Мало того, в описании директивы proxy_busy_buffers_size есть четкое указание на то, что ответ клиенту передается одновременно с получением его от апстрима.
Как-то в порыве быть прогрессивным, и в связи с подошедшим сроком поверки счетчиков поменял все 6 штук на вот такие Элехант. Смотреть все покапзатели практически за раз никуда не залезая конечно прикольно. Вот только первый счетчик перестал подавать признаки жизни через пару недель. Остальные последовали за ним весьма быстро. Первый еще успел заменить по гарантии. К моменту когда я плюнул на все и поменял их на обычные счетчики прошло ~7 месяцев. В живых оставался один счетчик, причем не тот который поменял. Один из сдохших счетчиков разобрал наплевав на гарантию. Батарейка была в порядке.
Те, кто считает что регистратор пытается помочь, пускай и за дорого, клиенту у которого проблема, не обольщайтесь, это не так. Просто какой-то "эффективный менеджер" нашел способ срубить еще немного денежек с клиентов.
У меня на ликвидированной фирме было 3 домена. Причем ООО ликвидировано еще в 2016 году, что не мешало регистрару ежегодно получать деньги с несуществующего ООО. Несколько месяцев назад пришло такое же "письмо счастья". За 2 домена решили заплатить, а один уже и так не использовался, поэтому пусть разделегируется. 2 домена были перенесены на дргугой аккаунт, а тот за который не заплатили так и остался на старом. Никакого разделегирования с ним не произошло. Мало того, я совершенно спокойно оплатил продление этого домена на старом, принадлежащем несуществующему ООО аккаунте.
Вот не понимаю я этих восторгов по поводу ZFS: "что ZFS — удобная, функциональная
и вообще единственная правильнаяфайловая система".Я дважды всерьез пытался ее использовать, оба раза не удачно. Первый раз на работе. Тогда мы, начитавшись восторженных статей о ZFS, попробавали перевести на нее раздел с данными postgres. Падение производительности на десятки процентов по сравнению с ext4 (порядка 90% нагрузки - запись), быстро заставили отказаться от этой идеи.
Второй раз - на домашнем NAS. У меня, условно, 4 диска, на которых я хочу динамически создавать разделы с разным уровнем избыточности, от stripe до 4-way mirror. Это элементарно делается при помощи LVM. Однако в случае ZFS я должен заранее спланировать распределение физических разделов по уровням избыточности, что, в моем случае, очевидно неприемлемо.
ИМХО, с точки зрения обхода бокрировок, совершенно не раскрыта основная идея этого самого "Middleman". Если у вас есть VPS в России, трафик с которого зарубеж не фильтруется (а такие есть), то второй VPS и туннель до него уже не нужен. Аналогично и с условным "Армянским" VPS. Если до него ничего не блокируется, то и дальше все вполне нормально.
Потому что основная цель фирмы - исполнять хотелки владельца (в простейшем случае - приносить прибыль). У государства, постулируемая цель, вроде бы другая.
Вот кстати да, в таких статьях-инструкциях зачастую очень не хватает, где-нибудь в начале, описания общими словами, как же именно работает представленное решение.
Китайцы конечно придумали, но их реле занимает 4 слота, вместо одного у автора.
А во многих случаях это очень актуально.
А скажите, что это за прикольные термоголовки на последней ГИФке?
Еще ни разу не встречал действительно полезного чат-бота в качестве саппорта. Единственное исключение - когда нужно сделать какую-то типовую операцию, типа заказать справку, подать поручение, закрыть или открыть продукт, и т.п. Но опять же, такие типовые вещи гораздо удобнее делать через систему меню или другой структурированный интерфейс.
В отальном, общение с чат ботами сводится к тому, чтобы всеми правдами и неправдами добратья до живого человека.
Именно в этом месте документацию не поправили. В отличие например от описания параметра stats_temp_directory, которая и задает расположение этого каталога.
Вот тут: https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/ хорошо описано, что там сделали с коллектором статистики, и, в частности, почему каталог pg_stat_tmp все же оставили. Кратко - для совместимости с расширениями, которые могут полагаться на наличие этого каталога.
Начиная с 15 версии posgresql не использует каталог pg_stat_tmp, а хранит статистики в shared memory.
Ага, особенно монтирование pg_stat_tmp в tmpfs для postgresql 15+ наводит на мысли о "высочайшем" уровне статьи.
На картинке вообще не орбита небесного тела.
Совершенно непонятно, в чем претензия?
Функция не включена по умолчанию, при включении описание вполне исчерпывающее. Лично вам не нужно, так не включайте.
C удовольствием бы почитал подобную статью!
Спасибо, хорошая обзорная статья, действительно полезная как стартовая точка.
Чего как мне кажется не хватает, так это практических примеров. Кроме простого констатирования о сложности генерирования "одноглазого пирата с повязкой и эполетами, держащего в левой руке топор", хотелось бы увидеть как его все же можно получить, используя описываемый инструментарий.
Дорогой тезка, преогромнейшее тебе спасибо! Именно то, что я давно искал среди монструозных комбайнов, но ленился сделать сам.
Единственно что могу предложить, это заменить cp на ln, чтобы места лишнего не занимать.
Я правильно понимаю, что любой, кто может отправить на ваш файрвол SYN-пакет с поддельным src IP, эффективно заблокирует вам любой IP, да хоть весь интернет?
В статье перепутана WBT, которая определяется исключительно температурой окружающего воздуха и влажностью, и WBGT из таблички, в которую входит еще и солнечное излучение. WBGT для своего тела можно существенно уменьшить одевшись в белое, или вообще превратить в WBT при помощи зонтика. А WBT никогда не может быть выше температуры окружающего воздуха.
Мне кажется что здесь неправильно описан механизм буферизации. Что интересно, в руководстве администратора NGINX Plus, тоже написано что данные клиенту не передаются до полного вычитывания ответа с апстрима, хотя в основной документации ничего такого нет. Мало того, в описании директивы proxy_busy_buffers_size есть четкое указание на то, что ответ клиенту передается одновременно с получением его от апстрима.
Как-то в порыве быть прогрессивным, и в связи с подошедшим сроком поверки счетчиков поменял все 6 штук на вот такие Элехант. Смотреть все покапзатели практически за раз никуда не залезая конечно прикольно. Вот только первый счетчик перестал подавать признаки жизни через пару недель. Остальные последовали за ним весьма быстро. Первый еще успел заменить по гарантии. К моменту когда я плюнул на все и поменял их на обычные счетчики прошло ~7 месяцев. В живых оставался один счетчик, причем не тот который поменял. Один из сдохших счетчиков разобрал наплевав на гарантию. Батарейка была в порядке.
Те, кто считает что регистратор пытается помочь, пускай и за дорого, клиенту у которого проблема, не обольщайтесь, это не так. Просто какой-то "эффективный менеджер" нашел способ срубить еще немного денежек с клиентов.
У меня на ликвидированной фирме было 3 домена. Причем ООО ликвидировано еще в 2016 году, что не мешало регистрару ежегодно получать деньги с несуществующего ООО. Несколько месяцев назад пришло такое же "письмо счастья". За 2 домена решили заплатить, а один уже и так не использовался, поэтому пусть разделегируется. 2 домена были перенесены на дргугой аккаунт, а тот за который не заплатили так и остался на старом. Никакого разделегирования с ним не произошло. Мало того, я совершенно спокойно оплатил продление этого домена на старом, принадлежащем несуществующему ООО аккаунте.
Вобщем вывод один, RUCENTER - жулики.