https://m.opennet.dev/openforum/vsluhforumID3/137293.html Сформированы внеплановые обновления Samba 4.22.3 и 4.21.7, решающие проблему с нарушением совместимости серверов Samba с завтрашним обновлением Windows Server. В случае, если не установить предложенные корректирующие обновления, серверы Samba, не смогут функционировать в роли членов доменов Windows Active Directory, если в настройках для маппинга иденитификаторов пользователей задействован бэкенд 'ad'...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=63540<br> https://m.opennet.dev/openforum/vsluhforumID3/137293.html#244 Tue, 15 Jul 2025 17:37:32 GMT &gt; Вдруг это "победит" кафку <br><br>Я вполне могу поверить, что NATS даст меньшую задержку, чем Kafka, но по пропускной способности он ну никак не сможет составить ей конкуренцию. А по задержке NATS не сможет конкурировать с Redis. Так что у нас всё хорошо )<br> <br><br><br> https://m.opennet.dev/openforum/vsluhforumID3/137293.html#243 Tue, 15 Jul 2025 12:57:23 GMT Кстати, вдогонку (вдруг еще вернетесь проверить ответы, хоть по времени новость и протухла). Из интереса спросил чатгопоту про проблему медленных потребителей. Интересно ответил (извините, многа букав):<br><br>"Вопрос про брокер сообщений NATS. Есть утверждения, что этот брокер имеет следующую архитектурную проблему: медленные потребители тормозят всю очередь, потому что доставка сообщений потребителям осуществляется последовательно. Есть ли какие-то планы у разраьотчиков это исправить, например, выделив каждую доставку сообщения в отдельный файбер или сопрограмму или разработчики не считают это проблемой и ничего в этом направлении делать не планируют?"<br><br>Ответ:<br><br>"Да, вы правы: в ядре NATS (не JetStream) доставка сообщений подписчикам выполняется последовательно в рамках соединения, и медленные потребители действительно могут блокировать поток, пока не освободится TCP&#8209;транзакция ([GitHub][1]).<br><br>Однако команда NATS давно внедрила решения:<br><br>---<br><br>### &#128736; Что уже сделано<br><br>1. **Асинхронное напи https://m.opennet.dev/openforum/vsluhforumID3/137293.html#242 Tue, 15 Jul 2025 09:49:28 GMT Спасибо!<br> https://m.opennet.dev/openforum/vsluhforumID3/137293.html#241 Mon, 14 Jul 2025 16:14:12 GMT &gt;&gt;&gt; transactional outbox там, где нужно на уровне приложения реализовать.<br>&gt;&gt; Redis или RabbitMQ <br>&gt; Ни в коем случае не холивара ради или еще чего, искренне интересуюсь <br>&gt; - рассматривали ли Вы или пробовали NATS покрутить? Есть какой-то опыт <br>&gt; сравнения его с другими брокерами?<br><br>Нам он не подошел из-за того, что медленные подписчики заметно тормозят быстрых.<br>В итоге, массивы данных у нас через Kafka, и только там, где нужно обеспечить консистентность данных, получаемых из разных топиков - Redis.<br><br>&gt; Т.е. теоретически по фичам NATS закрывает потребности, требующиеся от кафки<br><br>Если, как у нас, за сутки в сумме может до терабайта пролететь, то Kafka явно выигрывает, хотя и требует дополнительно транзакционного брокера в некоторых случаях.<br><br>&gt; Написано на го, что, как я предполагаю, будет относительно быстрым и <br>&gt; потреблять меньше памяти в отличии от явы<br><br>А тут зависит от профиля нагрузки. В k8s легко может получиться наооборот, за счет того, что одинаковые jar в разных контейнерах в памяти каждого х https://m.opennet.dev/openforum/vsluhforumID3/137293.html#240 Mon, 14 Jul 2025 12:44:30 GMT &gt;&gt;&gt; Если речь о Kafka, то от Debezium мы отказались по ряду причин в пользу кастомного решения.<br>&gt;&gt; Ну, тут мы аналогично. Та ночь темна и полна ужасов, проще полноценный<br>&gt;&gt; transactional outbox там, где нужно на уровне приложения реализовать.<br>&gt; Redis или RabbitMQ<br><br>Ни в коем случае не холивара ради или еще чего, искренне интересуюсь - рассматривали ли Вы или пробовали NATS покрутить? Есть какой-то опыт сравнения его с другими брокерами? Просто сам только-только начал этот NATS рассматривать, пока поверхностно, нигде еще не пробовал. У него, как и в кафке с рэббитом, в обоих вместе, есть (хз на каком уровне и с каким качеством) и "publish/subscribe" и "request/reply" и (если надо) персистентность очередей и (если надо) подтверждение клиентом получения или обработки сообщения, кластеризация. А в пику Redis'у есть и распределенное хранилищие вида "ключ-значение" с подпиской клиентов на отслеживание изменения этих значений.<br>Т.е. теоретически по фичам NATS закрывает потребности, требующиеся от кафки/кролика и https://m.opennet.dev/openforum/vsluhforumID3/137293.html#239 Fri, 11 Jul 2025 16:51:55 GMT Вопрос даже не в сырости,а в том что она например до сих пор не поддерживает структуры леса. То есть для любой крупной организации - сразу мимо.<br>Если у кого-то возник вопрос зачем она нужна - значит ты просто полфнепригоден для работы с крупными корпоративными сетями.<br> https://m.opennet.dev/openforum/vsluhforumID3/137293.html#238 Wed, 09 Jul 2025 19:27:59 GMT &gt;&gt; С одной стороны яндекс: <br>&gt; Ну уж нет, там вся дискуссия есть.<br>&gt; Так что сначала "Of course, having a stakeholder willing to fund the <br>&gt; development of such a feature will raise the priority of this <br>&gt; feature and allow us to develop that in a shorter timeframe." <br><br>От 2016 года. До 2025. Аж 9 лет были гораздо большие планы, которые гораздо важнее бэкапов.<br>На лорчик ты сходить не хочешь. Там тоже несколько рассказов про неоднократно присылаемые патчи в апстрим, но которое не принимают. Наверное тоже having a stakeholder willing to fund the development. Почти на каждое так, ага. Странно только что патчи на исправление такого обычно присутствуют в платных версиях.<br><br>&gt; А потом в ответ уже по-русски и на Хабре: <br>&gt;&gt;&gt; а они просят с нас денег, чтобы замержить её.<br>&gt; Так что прекращаейте, пожалуйста, нагло врать.<br><br>На хабре практически частным разговором сказать можно гораздо больше. Вынесение таких обвинений в шитхаб разработчика повлечёт почти сразу с большой вероятностью:<br>предъявление претензий и плак-п https://m.opennet.dev/openforum/vsluhforumID3/137293.html#237 Wed, 09 Jul 2025 19:16:12 GMT &gt; Ну если Вы больше не собираетесь обсуждать то, в чем не разбираетесь, <br>&gt; то незачем ))) <br><br>Опять делаешь вид что не понял и смайликами обрамляешь. Какой стыд то.<br>Это вот реальный опыт. Который спокойно находится по аналогиям в других областях. Но ты так увиливаешь от признания фактов.<br>Большинство не разбирается в строении автомобиля и не может перебрать движок. Но посмотреть на то как ведут японки с возрастом и китайские вполне доступно всем. А сейчас мне нагло пытаются втюхать китайский москвич вместо лексуса. Приправляя это смешками и рассказывая насколько оно лучше и плюс какие модные светодиодики есть.<br><br>&gt;&gt; Ты вот набираешься опыта в разведении камелий, штукатуренья стен под лампочку, <br>&gt;&gt; переборки движка с форсированием, бурение скважин под воду, правильной карамелизации лука <br>&gt;&gt; под классический французский суп и прочему? Нет? То есть опираешься на <br>&gt;&gt; чужое мнение, а не сам.<br>&gt; Но я и не берусь публично высказывать свое мнение о том, в <br>&gt; чем не имею достаточно компетенций.<br><br>ну да, поэтому р https://m.opennet.dev/openforum/vsluhforumID3/137293.html#235 Wed, 09 Jul 2025 16:44:32 GMT &gt; А документо-ориентирование БД не зашли?<br><br>Они бы может и зашли, но тратить на это силы экономически нецелесообразно. К концу 2027 оттуда так или иначе съедут последние клиенты и всё это будет просто выключено и выброшено целиком. Ну и так просто вообрази себе наслаждение модифицировать софт, написанный в конце 2003 года под современные реалии. Лучшая половина тех программистов уже на пенсии внуков нянчит.<br>