Никак нет! Текст полностью написан мной от первой до последней строчки. Но Сам я использовал их очень много — помогают найти конец верёвки, за которую тянуть, чтобы распутать клубок. Плюс код manim для всех иллюстраций писали тоже они.
Ну справедливости ради, я в публикации об этом говорю: "Не совсем, конечно, из ничего". И в подкасте тоже. И даже сам Шеннон говорил про частоту дискретизации сигнала, что это "a fact which is common knowledge in the communication art".
Ну и про Котельникова и приоритет в теореме об отсчётах отдельный выпуск подкаста был)
У обоих, кстати: и Шеннона, и Котельникова был талант объяснять сложные вещи простыми словами. И, естественно, упрощать любые запутанные вопросы до самого ядра, откидывая несущественное.
Понятие энтропии информации совсем не очевидное, кстати, пока не ознакомишься поподробнее)
В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление FIB происходит за единицы миллисекунд. Из-за наличия нескольких путей при трафик переключается на альтернативные примерно в это же время. Перекоммутаций как таковых никаких не происходит.
не способна соединить абонентов совсем уж в произвольные пары
Этот тезис не понял. Что Клоз, что Драгонфлай по сути представляет связность между любой парой хостов - вопрос только в диаметре. А так же в том, что нахождение пути не означает нахождение полосы.
Осилил и дочитал - огромное спасибо за такую колоссальную работу! :)
Спасибо) Это было интересно
А это тянет за собой IPv6 и так или иначе работу с хостами (чтобы переписывали Flow Label)... вообщем если вы не Яндекс - можно забыть :)
На самом деле нет. Я описал решение, которое мы делаем в Яндексе - довольно простой контроллер, который следит за утилизация на основе собираемых метрик, плюс динамическое управление политиками ликинга маршрутов. Никакого SR или тем более SRv6. Если есть система управления конфигурацией, то в целом довольно доступно.
И вот тогда это решение не то что "пробовать" в лабе, но и внедрять многие пойдут - просто потому что это более экономично с точки зрения CAPEX на сеть!
А вот тут нет факт совсем. Потому что помимо CAPEX на железо, есть ещё ФОТ команд это разрабатывающих и поддерживающих, плюс более высокие эксплуатационные расходы.
Что ещё более важно, неизвестно на самом деле насколько Dragonfly подходит под задачи обычных ДЦ (публичные облака, baremetal и подобное), где очень неравномерный трафик, а управлять размещением пользовательских ресурсов и объёмом трафика мы не можем.
Получается, что он его пароль лежит не только в секретном бумажном конверте, но и где-то в системе мониторинга?
Пароль лежит в секретнице (типа vault) - и при каждом запуске крона забирает его оттуда без локального хранения. Это, соответственно, позволяет нам не думать о его смене при ротации пароля - крон просто работает.
Секретница - manged сервис с контролем доступа. А так - да, пароль breakglass ещё записан на бумажке и лежит в "сейфе" (в Новосибисрке).
Сложно спорить) Всё в целом так. Но всё ещё никакого весомого аргумента в пользу RADIUS нет (кроме того, что микротики не поддерживают TACACS)).
А если историю брать не с самого начала, а с момента, когда мы в Облаке решили делать централизованную авторизацию, что такакс уже был, а радиус - нет. Выбор очевиден)
Вот тут не понял: я сарказм не распознал или всё серьёзно? :)
Это будет две разные статьи, потом холивар неизбежен. Можно даже и спичку первую зажечь.
Никак нет! Текст полностью написан мной от первой до последней строчки.
Но
Сам я использовал их очень много — помогают найти конец верёвки, за которую тянуть, чтобы распутать клубок. Плюс код manim для всех иллюстраций писали тоже они.
Это не опечатки, а ханипоты
Так в том-то и дело, что терабайты данных нужно гонять по сети. Если под шиной вы имеете в виду NVLink, то он лучше — и по полосе и по задержкам.
Отдельной — нет. Обзорно я коснулся в этой статье. А дальше я буду уходить в специфику инфраструктуры для кластеров. И даже более точечно — сетей.
Здравствуйте. Вы правы. Но ирония в том, что в области именно нейросетей у меня опыта нет — я строю сеть для кластеров.
А почему настораживает?
Как говорил Докинз в "Бог как иллюзия", что полное понимание процессов во время секса, не мешает наслаждаться им)
Ну в каком-то смысле трансформеры — это последовательность сумматоров, и компараторов (нелинейных функций).
Не думал, что так быстро спалят))
Ну справедливости ради, я в публикации об этом говорю: "Не совсем, конечно, из ничего". И в подкасте тоже.
И даже сам Шеннон говорил про частоту дискретизации сигнала, что это "a fact which is common knowledge in the communication art".
Ну и про Котельникова и приоритет в теореме об отсчётах отдельный выпуск подкаста был)
У обоих, кстати: и Шеннона, и Котельникова был талант объяснять сложные вещи простыми словами. И, естественно, упрощать любые запутанные вопросы до самого ядра, откидывая несущественное.
Понятие энтропии информации совсем не очевидное, кстати, пока не ознакомишься поподробнее)
Сделал "похитрее", выложил видео в телегу: https://t.me/donasdoshlo/107
Ну у меня проба. Решил первый раз всё же не пытаться во все тяжкие, не понимая базы.
Почти в самом начале: DeepSeek R1 Thinking
Картинка же и правда хороша)
В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление FIB происходит за единицы миллисекунд. Из-за наличия нескольких путей при трафик переключается на альтернативные примерно в это же время.
Перекоммутаций как таковых никаких не происходит.
Этот тезис не понял. Что Клоз, что Драгонфлай по сути представляет связность между любой парой хостов - вопрос только в диаметре. А так же в том, что нахождение пути не означает нахождение полосы.
Спасибо) Это было интересно
На самом деле нет. Я описал решение, которое мы делаем в Яндексе - довольно простой контроллер, который следит за утилизация на основе собираемых метрик, плюс динамическое управление политиками ликинга маршрутов. Никакого SR или тем более SRv6. Если есть система управления конфигурацией, то в целом довольно доступно.
А вот тут нет факт совсем. Потому что помимо CAPEX на железо, есть ещё ФОТ команд это разрабатывающих и поддерживающих, плюс более высокие эксплуатационные расходы.
Что ещё более важно, неизвестно на самом деле насколько Dragonfly подходит под задачи обычных ДЦ (публичные облака, baremetal и подобное), где очень неравномерный трафик, а управлять размещением пользовательских ресурсов и объёмом трафика мы не можем.
Один и тот же, только ротируется иногда.
Все инстансы бастиона симметрично сконфигурированы, чтобы добавлять новые при случае было очень простой операцией.
Пароль лежит в секретнице (типа vault) - и при каждом запуске крона забирает его оттуда без локального хранения. Это, соответственно, позволяет нам не думать о его смене при ротации пароля - крон просто работает.
Секретница - manged сервис с контролем доступа. А так - да, пароль breakglass ещё записан на бумажке и лежит в "сейфе" (в Новосибисрке).
Сложно спорить) Всё в целом так. Но всё ещё никакого весомого аргумента в пользу RADIUS нет (кроме того, что микротики не поддерживают TACACS)).
А если историю брать не с самого начала, а с момента, когда мы в Облаке решили делать централизованную авторизацию, что такакс уже был, а радиус - нет. Выбор очевиден)