Интересно, можно ли как-то узнать величину общего подъёма Африканской тектонической плиты за время формирования Сахары и как-то численно оценить её? Нет ли где на планете мест со схожей динамикой, в историческом и современном времени? И есть ли какие либо существенные изменения плотности земной коры за всё её время формирования, что могло бы сформировать устойчивый в сотни млн лет вектор "подъёма"? Возможно ли, таким образом, неизбежное формирование глобальной пустыни на планете Земля, по аналогии с результатом как сейчас на Марсе (не касаясь в целом вопроса потери скудной атмосферы у последнего)?
Большое спасибо за статью. Очень жаль, что тема подписи коммитов недостаточно популярна, как и осознание потенциальных рисков при работе без подтверждения авторства. Также крайне не рекомендую создавать бессрочные ключи.
Интересно было бы придумать механизм оценки качества работы таких AI-тренеров. Возможно, через сотни тестовых вопросов с заложенной в них случайной, но контролируемой вариацией, и тестировать одновременно как тренера, так и обученную им сеть.
Также стоит серьёзно подумать о fact checking и логике в исходных данных при обучении, чтобы застывший цемент не вытекал из стакана. В целом, есть проблема оценки достоверности обучающего материала и пока сети не могут качественно решить такой вопрос (перепроверки достоверности и перестройки логики фактов во всём масштабе сети), особенно, если недостоверность в обучаемых данных просто берёт количеством. То есть, обучать сети по содержимому тех же СМИ - довольно "опасное" занятие в социальном плане, если подобным обученные сети будут получать статус первичного авторитета знаний.
Следующим шагом в развитии GPT-like моделей должна быть роль child: когда сети массово разрешат задавать вопросы людям, а не просто отвечать на запросы. На основе этого механизма можно сильно улучшить ту самую перепроверку достоверности. Но, всё равно, фактор массовой ошибки будет продолжать влиять на качество выводов такой сети.
Есть некоторое подозрение, что в глобальном плане именно к этому всё и идёт - к созданию country-specific сетей-оракулов, со своей "достоверной" информацией и правильной "логикой". На которые, со временем, привяжут все сферы жизни общества - от обучения в школах, до законотворчества и решения судов. Очень хочется ошибаться в подобных прогнозах.
В целом, это как с ядерными технологиями: можно строить полезные станции с серьёзной генерацией и, через удешевление стоимости первичных ресурсов производства, делать всё остальное дешевле и доступнее, на десятилетия. А можно психануть и расхерачить всё к чертям, создав непригодные территории, на столетия. Инструмент в обоих случаях по сути един и вопрос лишь в том, как им пользоваться, и какие цели ставить.
Какой у книги ISBN (оригинала)? Это третье издание "Python for finance" (если да - в чём различие между версией последнего релиза второго издания от 31.07.2020) с переводом на русский или же другая книга?
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
Ещё интереснее механизмы многомерной оптимизации в динамических системах (изменяющаяся топология, изменяющиеся веса/"нагрузка"), когда есть, к примеру, базовая оптимальная модель и далее происходит оптимизация различных отклонений целевых показателей. Также можно рассматривать более сложную модель с грузоперевозками/такси, когда не только надо минимум по расходам, но и минимум по "штрафам", при невозможности или задержках доставки при динамической маршрутизации. Один авто только с одним пассажиром, только с точками A и B - это относительно просто.
Продолжайте эту тему, при желании и возможности. Большое спасибо за статью.
Было бы здОрово продолжить развитие этого проекта в сторону небольшого автоматизированного тестера на том же STM32, по аналогии с китайскими мультитестерами различных компонентов. Но с бОльшей информативностью, чем просто показатель индуктивности и сопротивления. К примеру, находить пики по мощности, частотам, КПД и пр. Возможно даже определить примерный подсчёт витков, для конфигурации всего двух обмоток или же просто соотношения витков в обмотках.
Если кто-то с вышеописанным в качестве законченного и недорогого устройства сталкивался - буду благодарен информации/ссылкам.
Оптоволокно разбухло. /s
Большое спасибо за статью!
Большое спасибо за статью.
Интересно, можно ли как-то узнать величину общего подъёма Африканской тектонической плиты за время формирования Сахары и как-то численно оценить её? Нет ли где на планете мест со схожей динамикой, в историческом и современном времени? И есть ли какие либо существенные изменения плотности земной коры за всё её время формирования, что могло бы сформировать устойчивый в сотни млн лет вектор "подъёма"? Возможно ли, таким образом, неизбежное формирование глобальной пустыни на планете Земля, по аналогии с результатом как сейчас на Марсе (не касаясь в целом вопроса потери скудной атмосферы у последнего)?
Спасибо за статью!
Спасибо за статью!
Большое спасибо за статью. Очень жаль, что тема подписи коммитов недостаточно популярна, как и осознание потенциальных рисков при работе без подтверждения авторства. Также крайне не рекомендую создавать бессрочные ключи.
November 18, 2021
https://www.gutenberg.org/files/33283/33283-pdf.pdf
Про блох на 8-й странице.
Отличная статья, большое спасибо! В ожидании следующей части.
Отличная статья, большое спасибо!
Большое спасибо за статью!
Интересно было бы придумать механизм оценки качества работы таких AI-тренеров. Возможно, через сотни тестовых вопросов с заложенной в них случайной, но контролируемой вариацией, и тестировать одновременно как тренера, так и обученную им сеть.
Также стоит серьёзно подумать о fact checking и логике в исходных данных при обучении, чтобы застывший цемент не вытекал из стакана. В целом, есть проблема оценки достоверности обучающего материала и пока сети не могут качественно решить такой вопрос (перепроверки достоверности и перестройки логики фактов во всём масштабе сети), особенно, если недостоверность в обучаемых данных просто берёт количеством. То есть, обучать сети по содержимому тех же СМИ - довольно "опасное" занятие в социальном плане, если подобным обученные сети будут получать статус первичного авторитета знаний.
Следующим шагом в развитии GPT-like моделей должна быть роль child: когда сети массово разрешат задавать вопросы людям, а не просто отвечать на запросы. На основе этого механизма можно сильно улучшить ту самую перепроверку достоверности. Но, всё равно, фактор массовой ошибки будет продолжать влиять на качество выводов такой сети.
Есть некоторое подозрение, что в глобальном плане именно к этому всё и идёт - к созданию country-specific сетей-оракулов, со своей "достоверной" информацией и правильной "логикой". На которые, со временем, привяжут все сферы жизни общества - от обучения в школах, до законотворчества и решения судов. Очень хочется ошибаться в подобных прогнозах.
В целом, это как с ядерными технологиями: можно строить полезные станции с серьёзной генерацией и, через удешевление стоимости первичных ресурсов производства, делать всё остальное дешевле и доступнее, на десятилетия. А можно психануть и расхерачить всё к чертям, создав непригодные территории, на столетия. Инструмент в обоих случаях по сути един и вопрос лишь в том, как им пользоваться, и какие цели ставить.
Какой у книги ISBN (оригинала)? Это третье издание "Python for finance" (если да - в чём различие между версией последнего релиза второго издания от 31.07.2020) с переводом на русский или же другая книга?
Спасибо за статью. Можно попробовать всё это перенести в ansible роли, на bash-е далеко не уедешь. По возможности - без terraform.
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
И "чем дальше в лес, тем толще волки".
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
Ещё интереснее механизмы многомерной оптимизации в динамических системах (изменяющаяся топология, изменяющиеся веса/"нагрузка"), когда есть, к примеру, базовая оптимальная модель и далее происходит оптимизация различных отклонений целевых показателей. Также можно рассматривать более сложную модель с грузоперевозками/такси, когда не только надо минимум по расходам, но и минимум по "штрафам", при невозможности или задержках доставки при динамической маршрутизации. Один авто только с одним пассажиром, только с точками A и B - это относительно просто.
Продолжайте эту тему, при желании и возможности. Большое спасибо за статью.
Большое спасибо за статью.
Было бы здОрово продолжить развитие этого проекта в сторону небольшого автоматизированного тестера на том же STM32, по аналогии с китайскими мультитестерами различных компонентов. Но с бОльшей информативностью, чем просто показатель индуктивности и сопротивления. К примеру, находить пики по мощности, частотам, КПД и пр. Возможно даже определить примерный подсчёт витков, для конфигурации всего двух обмоток или же просто соотношения витков в обмотках.
Если кто-то с вышеописанным в качестве законченного и недорогого устройства сталкивался - буду благодарен информации/ссылкам.
Возможно, имеет смысл посмотреть в сторону K6 .