нейросеть никогда не заменит личный опыт, экспертизу, накопленный багаж практических навыков автора.
Как раз таки опыт llm и обесценивает! Мой четвертьвековой опыт теперь не великое преимущество по сравнению с новичком+llm. Более того, новичок не ограничен рамками своего личного опыта! Это уже из жизненных реалий.
А ведь именно они и составляют основную ценность книги!
По моему мнению, ценность представляют фундаментальные и архитектурные знания, которые сложно впихнуть в виде набора фактов и шаблонов. На этом поле, пока еще, llm недотягиваются до опытных инженеров. Поэтому мне странно видеть, что описанные вами лидеры, это авторы нетленок типа "... для чайников".
Да все сложнее: в статье же написано, что операторы не понимаю как им учитывать ANYCAST трафик? Это один и тот жe IP адрес может быть как в России, так и за рубежом. Причем в течение дня картина может меняться в зависимости от топологии BGP. Это тот же google, youtobe и т.п.
Как уже неоднократно писали, административные проблемы не имеют простого технического решения.
И все, децентрализация есть, кабелей по 100км тянуть не нужно, шкафов со 100500 автоматами не требуется, управление откуда угодно и чем угодно и так далее. Вся пром автоматизация сейчас так работает. Там только комнаты побольше, но и управляются они не одним ПЛК.
Автоматов в такой схеме получится больше - нужно же еще межшкафные линии защищать.
Да, возможно будет дороже, но думаю что за счёт одних только проводов и их монтажа можно будет ещё и сэкономить.
А какой смысл тогда в "экономии на проводах", если получтся еще и дороже? И вы еще не учли, что в распределенной системе вам придется дублировать мониторинг, резервное электропитание и, опционально, физическую защиту.
p.s. эта отрасль имеет давнюю историю. Все уже придумано давно. Нужно просто не лениться учиться.
Интересно, сколько специалистов языка МЭК заказчик найдет в случае утраты предыдущего? Тут специалиста по WB не всегда найдешь доделать или переделать за кем то
Ну вы сравнили! Как раз таки WB - это уникальное явление, а с МЭК работает любой специалист из АСУТП! Причем неважно на каком контроллере он специализируется - в этом вся суть старндарта!
Ежегодно в странах ЕС продаётся около 150 млн смартфонов и 24 млн планшетов. Это приводит к появлению примерно 5 млн тонн электронных отходов ежегодно,
Ну три раза пересчитал! Может, конечно, и я туплю: если сложить смартфоны и планшеты, то плучается что в среднем один весит 29 кг! Кто тут ..нулся так манипулирует: @Travis_Macrif или EU? Ошибиться на два-три порядка! Может и париться с утилизацией не стоит? Может всего 5K тонн отходов, а не в тысячу раз больше? А все, главное, обсуждают целесообразность и удобство. А на первопричину никто и не смотрит. Как с политиками: "увеличим зарплату в два раза!". Популизм уже везде.. Или просто безграмотность?
Мне статья очень понравилась, но вот тоже режут глаз такие нестыковки. Получается Слава пишет бред полный, как бы красиво он не выглядел. @slava_rumin, уточните пожалуйста реальные показатели? Уже много у вас таких статей: жизненное описание, много фотографий, а потом проанализуешь что прочитал - так и времени своего жалко. Если так и дальше дело пойдет - придется добавить автора в компанию к заблокированным генераторам новостей (иначе просто невозможно уже продираться сквозь гигабайты мусора).
Вряд ли. Первая строчка статьи: Статья написана на основе интервью с Дмитрием Фоминым, основателем перепелиной фермы в с. Александровское, Томский район.
И как всегда все снова в одном щите с километрами проводов. Пролистал и ничего интересного для себя не извлек. Как под копирку
Так это же хорошо, что вы ничего нового не извлекли - судя по всему вы отлично знаете современные стандарты умного дома! Централизованое управление - это признак зрелости разработчика и интегратора, который умеет считать и доносить до заказчика не только стоимость установки, но и стоимость эксплуатации системы.
1. Parent не “выкидывается из пула” надолго У 3proxy нет встроенного health-check и нет состояния вида “этот parent down, не использовать 30 секунд”. Сам автор прямо писал, что исключение нерабочих parent’ов реализовывать не планирует, и что для этого нужно отдельное ПО для проверки и управления списком прокси. Рекомендуют примеры с HA-proxy.
2. Что происходит при ошибке: parent выбирается случайно внутри своей группы по весам, и цепочка строится для нового соединения. Если выбранный parent недоступен, запрос падает на этапе установления этого соединения. При этом keep-alive / pipelined запросы в рамках уже открытого соединения используют ту же самую цепочку, а не перевыбирают parent.
То есть логика такая:
parent P1 умер; часть запросов, попавших на него, начнёт фейлиться; новые соединения снова будут случайно выбирать из того же набора; как только parent Р1 снова станет доступен, он начнёт снова успешно обслуживать трафик — без какого-либо re-enable, reload или recovery.
Т.е. ни о какой отказоустойчивости тут речь не идет. Вы, получается, просто снижаете blast radius от упашего прокси до значения (1 / [NUM_OF_PARENTS] ): при одном parent вы теряете сервис полность. а при двух - только наполовину, и т.д.
p.s. Использую 3proxy уже лет 8 в проде. Подумал грешным делом, что теперь это реальная замена HA ) Но нет, все на своем месте.
Автор - посмотрите на HA-proxy. Для вашего случая - то что доктор прописал. При этом, гораздо гибче. Можно, например, использовать пул дешeвых parent и, только в случае если все они умерли, использовать пул более дорогих. При этом вы явно можете описать механизм liveness probe.
В итоге мы получили отказоустойчивый узел. Если один из внешних прокси отвалится, 3proxy автоматически перекинет запрос на следующий живой узел.
Игорь поясните пожалуйста, а как 3proxy поймет что "один из внешних прокси отвалится" и каков механизм исключения и включения его обратно в пул рабочих арстримов?
Я тут прочел что "3proxy does not inherently support liveness probes"... Если это действительно так, то вся ваша статья не имеет никакого смысла, т.к. по сути никакой отказоустойчивости не добавляется, а наоборот снижается за счет усложнинея цепочки. Поясните пожалуйста?
Нет, это учителя в школе были недостаточно жестоки. А вы забыли про учет и расчет региональной снеговой нагрузки на конструкцию. Все придумано до нас - таблицы снегового покрова есть с советских времен. Но не переживайте - вашу теплицу починить несложно. Но доработать с учетом нагрузки снега - придется.
А в чем трясина то?
Вечный прогнозируемый покупатель ЭЭ, который никуда не убежит. Под которого можно даже привлечь инвестиции для строительства генерации.
Персонал ДЦ, вероятнее всего из местных, который снизит безраьотицу в регионе.
Персонал, Который кормит, обслуживает персонал из предыдущего пункта.
И все как с куста - не нужны национальные программы и дополнительный НДС для привлечения средств.
Российские министры до сих пор повторяют мантру про иностранные инвестиции. А вам- "палка о двух концах".
Это даже круче, чем продажа невозобновляемых ресурсов!
А из затрат: просто не мешать и урезать бюрократию.
Как раз таки опыт llm и обесценивает! Мой четвертьвековой опыт теперь не великое преимущество по сравнению с новичком+llm. Более того, новичок не ограничен рамками своего личного опыта! Это уже из жизненных реалий.
По моему мнению, ценность представляют фундаментальные и архитектурные знания, которые сложно впихнуть в виде набора фактов и шаблонов. На этом поле, пока еще, llm недотягиваются до опытных инженеров. Поэтому мне странно видеть, что описанные вами лидеры, это авторы нетленок типа "... для чайников".
Не, венец это: "у нас скоро дембель" или "мы работу нашли".
Это не про нормальных родителей.
Ага, DNS подменять.. А про TLS и сертификаты месье слышал? Специально против таких придумано.
Не нужно фантазировать.
Да все сложнее: в статье же написано, что операторы не понимаю как им учитывать ANYCAST трафик? Это один и тот жe IP адрес может быть как в России, так и за рубежом. Причем в течение дня картина может меняться в зависимости от топологии BGP.
Это тот же google, youtobe и т.п.
Как уже неоднократно писали, административные проблемы не имеют простого технического решения.
Точнее: нарушает монополию центробанков свободно печатать новые деньги из воздуха.
Посягает, так сказать на основы )
Первый комментарий в этой ветке от @SirNotGoodподробно разбирает нестыковки в деньгах и яйцах.
Спасибо!
Автоматов в такой схеме получится больше - нужно же еще межшкафные линии защищать.
А какой смысл тогда в "экономии на проводах", если получтся еще и дороже?
И вы еще не учли, что в распределенной системе вам придется дублировать мониторинг, резервное электропитание и, опционально, физическую защиту.
p.s. эта отрасль имеет давнюю историю. Все уже придумано давно. Нужно просто не лениться учиться.
Ну вы сравнили! Как раз таки WB - это уникальное явление, а с МЭК работает любой специалист из АСУТП! Причем неважно на каком контроллере он специализируется - в этом вся суть старндарта!
Ну три раза пересчитал! Может, конечно, и я туплю: если сложить смартфоны и планшеты, то плучается что в среднем один весит 29 кг! Кто тут
..нулсятак манипулирует: @Travis_Macrif или EU? Ошибиться на два-три порядка! Может и париться с утилизацией не стоит? Может всего 5K тонн отходов, а не в тысячу раз больше?А все, главное, обсуждают целесообразность и удобство. А на первопричину никто и не смотрит. Как с политиками: "увеличим зарплату в два раза!". Популизм уже везде..
Или просто безграмотность?
Мне статья очень понравилась, но вот тоже режут глаз такие нестыковки.
Получается Слава пишет бред полный, как бы красиво он не выглядел.
@slava_rumin, уточните пожалуйста реальные показатели?
Уже много у вас таких статей: жизненное описание, много фотографий, а потом проанализуешь что прочитал - так и времени своего жалко. Если так и дальше дело пойдет - придется добавить автора в компанию к заблокированным генераторам новостей (иначе просто невозможно уже продираться сквозь гигабайты мусора).
Вряд ли. Первая строчка статьи:
Статья написана на основе интервью с Дмитрием Фоминым, основателем перепелиной фермы в с. Александровское, Томский район.
Так это же хорошо, что вы ничего нового не извлекли - судя по всему вы отлично знаете современные стандарты умного дома!
Централизованое управление - это признак зрелости разработчика и интегратора, который умеет считать и доносить до заказчика не только стоимость установки, но и стоимость эксплуатации системы.
Потрясающая статья!
Прочел на одном дыхании. Спасибо!
"Если" - хорошее слово!
Прочитал про работу этого меxанизма, в частности, тут: https://github.com/3proxy/3proxy/issues/583
Кратко:
механизм довольно “тупой”, но предсказуемый:
1. Parent не “выкидывается из пула” надолго
У 3proxy нет встроенного health-check и нет состояния вида “этот parent down, не использовать 30 секунд”. Сам автор прямо писал, что исключение нерабочих parent’ов реализовывать не планирует, и что для этого нужно отдельное ПО для проверки и управления списком прокси. Рекомендуют примеры с HA-proxy.
2. Что происходит при ошибке: parent выбирается случайно внутри своей группы по весам, и цепочка строится для нового соединения. Если выбранный parent недоступен, запрос падает на этапе установления этого соединения. При этом keep-alive / pipelined запросы в рамках уже открытого соединения используют ту же самую цепочку, а не перевыбирают parent.
То есть логика такая:
parent P1 умер;
часть запросов, попавших на него, начнёт фейлиться;
новые соединения снова будут случайно выбирать из того же набора;
как только parent Р1 снова станет доступен, он начнёт снова успешно обслуживать трафик — без какого-либо re-enable, reload или recovery.
Т.е. ни о какой отказоустойчивости тут речь не идет. Вы, получается, просто снижаете blast radius от упашего прокси до значения (1 / [NUM_OF_PARENTS] ): при одном parent вы теряете сервис полность. а при двух - только наполовину, и т.д.
p.s. Использую 3proxy уже лет 8 в проде. Подумал грешным делом, что теперь это реальная замена HA ) Но нет, все на своем месте.
Автор - посмотрите на HA-proxy. Для вашего случая - то что доктор прописал. При этом, гораздо гибче. Можно, например, использовать пул дешeвых parent и, только в случае если все они умерли, использовать пул более дорогих. При этом вы явно можете описать механизм liveness probe.
Игорь поясните пожалуйста, а как 3proxy поймет что "один из внешних прокси отвалится" и каков механизм исключения и включения его обратно в пул рабочих арстримов?
Я тут прочел что "3proxy does not inherently support liveness probes"...
Если это действительно так, то вся ваша статья не имеет никакого смысла, т.к. по сути никакой отказоустойчивости не добавляется, а наоборот снижается за счет усложнинея цепочки.
Поясните пожалуйста?
Нет, это учителя в школе были недостаточно жестоки. А вы забыли про учет и расчет региональной снеговой нагрузки на конструкцию. Все придумано до нас - таблицы снегового покрова есть с советских времен.
Но не переживайте - вашу теплицу починить несложно. Но доработать с учетом нагрузки снега - придется.
при этом:
Какая связь текстового документа и шрифта? Без OCR? Я не понимаю..
И второй вопрос: в договоре обычно реквизиты двух сторон. Что вернет ваш сервис в таком случае?
Еще двести лет назад была такая поговорка:
"Тому кто придумал - рубль, тому кто сделал- десять, а тому кто продал - 100".
Так что проблема не нова, как и постановка вопроса о несправедливости.