В Packet Tracer, когда вручную задаешь IP, он сразу не даст одинаковый адрес прописать двум устройствам, если все делать через стандартные настройки. Но если уже заранее настроить, потом включить их, то может быть конфликт. В жизни похожая ситуация. В виндовс, когда задаешь статический IP, система предупреждает, что такой адрес уже используется. Но можно сохранить настройки, и тогда будет конфликт, сеть начинает глючить. В линукс вообще, с правами рут, можно принудительно хоть все что угодно сломать, хоть один и тот же IP всем раздать. В итоге устройства начинают конфликтовать, и связь между ними работает нестабильно или вовсе отсутствует.
Да, тут согласен, конечно, если делать доп. настройки, можно спокойно работать через trunk, подключать несколько VLAN хоть к ПК, хоть куда угодно. Я просто для себя выбрал самый базовый сценарий - access и одна VLAN.
Да, gns3 это действительно крутой инструмент для более глубокого погружения, т.к там можно работать с реальными IOS и более сложными настройками. Скоро у меня выйдет статья именно по нему с продвинутыми примерами. А эту статью я писал специально для начинающих, как указано в самом начале, чтобы базовые вещи были понятны и без лишних сложностей.
Честно, IPFS крутая идея, но пока слишком сырая, чтобы менять HTTP.
Главная проблема это доступность. Если никто не хранит твой файл, он просто исчезнет. В HTTP сервер либо есть, либо нет - проще. А тут всё завязано на пиринговой сети, которая нестабильна и медленна.
Экономическая модель вообще не проработана - Filecoin пытается это решить, но пока больше похоже на хайп, чем на стабильный сервис. Кто будет платить и зачем хранить чужие данные?
Юзабилити тоже отстает. Пока не появится простой и удобный способ работать с IPFS - это будет нишевое решение для энтузиастов.
Но самое главное: IPFS не убьёт HTTP, а скорее станет его дополнять там, где нужна децентрализация и устойчивость к цензуре. Не надо ждать революции завтра это долгий путь.
"Мы не будем отправлять дизайн GPU в Китай" - говорят они, открывая R&D-центр в Шанхае. Всё как в анекдоте: "Мы не пьём - просто бутылка на столе стоит".
Очевидно, что Китай для Nvidia это рынок, от которого невозможно отказаться без потерь, и это не про миллиарды, это про десятилетия на восстановление. Поэтому "мы не передаём дизайн" звучит скорее как дипломатическая формула: и нашим, и вашим.
А между тем, США предлагают встраивать геолокацию в процессоры, чтобы "не уехали куда не надо". Интересно, будут ли они пищать, если пользователь с RTX 5090 пересёк границу в отпуск?
Уж не знаю, кто в этой истории больше боится потерять контроль - поставщики, политики или сами алгоритмы.
Всё это звучит шикарно, "ядерный движок, Марс за 45 дней", но пока больше похоже на PR-гонку между PowerPoint и Excel. Где реальные испытания? Где хотя бы прототип двигателя, выведенный на орбиту?
А то выходит, как обычно: космическое wishful thinking в духе "а вот если бы у нас был бесконечный бюджет, бесконечная тяга и ноль проблем с радиацией…"
Инженеры то крутые, вопросов нет. Но как только доходит до политики, финансирования и "ну вы держитесь, хорошего вам настроения" - всё зависает на уровне грантов и пресс-релизов.
Да, скорость обработки информации у планетарного мозга, скорее всего, будет намного ниже, чем у отдельного человека. Но зато его сила - в масштабах и объединении огромного количества данных и процессов. Это уже не просто мозг, а целая сеть, способная видеть большую картину и координировать множество систем одновременно.
Очень интересная и одновременно тревожная идея - планета с собственным мозгом! С одной стороны, это могло бы помочь нам наконец научиться жить в гармонии с природой и не разрушать её. Но с другой - кто гарантирует, что этот "планетарный разум" не станет новой формой власти, которая подавит человека? Важно помнить: технологии - это инструмент, а не хозяин. Нам нужно решить, как мы хотим использовать этот потенциал, чтобы он служил всем, а не уничтожал свободу и разнообразие жизни.
Интересно, как они пришли к таким расчётам: 100 МВт хватает на 250 тысяч домов в течение 40 лет? Кажется, тут какая-то нестыковка с типичным потреблением домохозяйств. Было бы здорово увидеть более прозрачные данные или расчёты, чтобы понять масштаб действительно
Всё звучит многообещающе, но хотелось бы больше технических деталей. Насколько устройство действительно МРТ-совместимо? Есть ли сертификация, испытания на разных мощностях поля? Просто важно понимать, насколько это уже "продукт", а не пока "анонс".
Интересно, но есть вопрос: если высвобождение дозы зависит от распада полимера, насколько точно это время можно контролировать у разных людей? Ведь метаболизм, температура тела и прочие факторы могут влиять. Получается, вакцина может сработать чуть раньше или позже, и насколько это критично? В остальном идея сильная, особенно для регионов, где сложно организовать повторные прививки.
Если разбирать по сути, реактор в роли резерва уже не гипотеза, а рабочая концепция: малые модульные реакторы (SMR) тестируются в разных странах, и вопрос не в "фантастике", а в логистике и регулировании. А охлаждение вакуумом - это не "минус", а объективная особенность среды, которой уже начинают пользоваться в спутниковых системах. Фраза "требует серьёзных усилий для преодоления" звучит так, будто это недостаток, хотя по факту - это условие, под которое просто меняется инженерия.
Про квантовые компьютеры: никто не говорит, что завтра будут полнофункциональные серверы на тысячах кубитов. Но реальный прогресс идёт, пусть с ошибками, но с предсказуемым ростом. Идея не в том, что "всё это уже работает", а в том, что ИТ-инфраструктура будет развиваться в сторону слияния разных типов вычислений - биологических, квантовых, нейроморфных. Это уже происходит, просто пока в виде прототипов и лабораторий.
Если подходить к теме исключительно в духе «пока не работает - значит бред», то можно было бы точно так же высмеивать интернет в 1980-х. Техническая осторожность - это хорошо. Но полное отрицание трендов, которые уже формируются в реальных R&D - это не скепсис, а слепота.
941 DDoS-атака за месяц, 1.3 Тбит/с пиковая мощность, почти 5 суток непрерывной атаки - звучит конечно впечатляюще. Только вот без деталей это больше похоже на пресс-релиз для галочки, чем на реальный техотчёт.
Хотелось бы понять: какие именно векторы атак использовались, как распределялись мощности, какие подходы к фильтрации были применены (от CDN до ТСПУ), и где заканчивается защита, а начинается просто блок всего подряд.
Иначе получается классика: "мы отбили всё, даже если вы об этом не подозревали, и заодно отключили то, что не относится к атаке".
По сути, каждый из трёх сценариев, это реакция на разные типы пределов: зелёный ЦОД - на энергию, космический - на пространство и безопасность, биоквантовый - на производительность и физику кремния. Вопрос не в том, какой из них "реалистичнее", а в том, какой предел наступит раньше. И вот здесь уже ставки разные, кто-то делает на энергию, кто-то на логику, кто-то на политический фактор. Интересно, что если их объединить, получится буквально "экзоскелет" цифровой цивилизации: нога в вакууме, мозг в органоидах, сердце в BESS и SMR.
Вы упомянули использование Kerberos и LDAP для анализа сети. В некоторых случаях можно столкнуться с использованием нестандартных портов или туннелирования в таких протоколах. Есть ли у вас рекомендации по дополнительным фильтрам или методам, которые помогут эффективно выявить такие нестандартные активности?
Да, пробовали, и не только "напели")) Всё зависит от проекта и команды, конечно. Если выстроен процесс, команда опытная, всё можно сделать красиво и без боли, согласен. Но и правда в том, что как только появляется необходимость чуть глубже интегрироваться с платформой, пуши в бэкграунде, камеры, специфичные UI-фичи, неизбежно лезешь в натив. Иногда это легко, а иногда превращается в набор костылей, особенно если фичи специфичные и под iOS, и под Android.
Flutter это умеет, спору нет. Но есть ощущение, что в какой-то момент ты уже не столько "кроссплатформу" делаешь, сколько борешься за баланс между "удобно" и "поддерживаемо".
А про веб, вообще без споров. Мы тоже не рискуем на всю катушку его юзать в проде. Потенциал огромный, но пока есть шероховатости. Хорошо, что команда Flutter активно пилит, но на сейчас, осторожно.
В итоге всё как обычно: Flutter, KMP, натив, всё рабочие инструменты, вопрос в задачах и том, насколько хочется(или нет) держать всё в одном фреймворке.
Да, под такую задачу Kotlin правда может неплохо подойти. Он и с HTML/JS может работать через Kotlin/JS, и на JVM нормально тянет всякие файловые операции. Ну и плюс удобно, что можно всё на одном языке писать, и обработку, и сохранение, и логику. Если уже есть опыт с Kotlin, точно стоит попробовать, а если нет, может как раз хороший повод глянуть.
Да, согласен, во Flutter многое реально сделать, особенно если есть опыт и не лень копать в сторону нативных интеграций. Но тут скорее вопрос не в том, можно или нельзя, а в том, насколько это удобно, стабильно и легко потом поддерживать.
Добавить файл на Swift, не проблема. Но когда таких мест становится много, это уже не совсем "единый код". А если проект растет, начинаешь думать, стоит ли вообще всё это пихать в Flutter, или проще часть фич делать нативно, как и задумывалось платформой.
Насчет "фича только на одной ОС", ну, зависит от задач. Если надо просто одинаково везде, то да, Flutter топ. Но если хочется выжать максимум из iOS или Android, использовать какие-нибудь Live Activities, Android-specific background-ограничения, или просто следовать нативным UX-гайдлайнам, тут уже начинаются компромиссы. Flutter это всё позволяет, но через танцы с бубном и нативные вкрапления. И чем больше таких мест, тем меньше ощущение "кроссплатформы".
KMP тут даёт немного другой подход, логика общая, UI и доступ к железу, нативный. Да, нужно разбираться в каждой платформе, но зато ты не воюешь с фреймворком, а просто используешь родные инструменты. У каждого подхода свои плюсы, вопрос в приоритетах проекта.
Привет, тут именно настройка сетевого окружения и SSH-доступа показана, а не разбор самого gns3.
Спасибо, рад, что было полезно!
В Packet Tracer, когда вручную задаешь IP, он сразу не даст одинаковый адрес прописать двум устройствам, если все делать через стандартные настройки. Но если уже заранее настроить, потом включить их, то может быть конфликт.
В жизни похожая ситуация. В виндовс, когда задаешь статический IP, система предупреждает, что такой адрес уже используется. Но можно сохранить настройки, и тогда будет конфликт, сеть начинает глючить.
В линукс вообще, с правами рут, можно принудительно хоть все что угодно сломать, хоть один и тот же IP всем раздать. В итоге устройства начинают конфликтовать, и связь между ними работает нестабильно или вовсе отсутствует.
Да, тут согласен, конечно, если делать доп. настройки, можно спокойно работать через trunk, подключать несколько VLAN хоть к ПК, хоть куда угодно. Я просто для себя выбрал самый базовый сценарий - access и одна VLAN.
Да, gns3 это действительно крутой инструмент для более глубокого погружения, т.к там можно работать с реальными IOS и более сложными настройками. Скоро у меня выйдет статья именно по нему с продвинутыми примерами. А эту статью я писал специально для начинающих, как указано в самом начале, чтобы базовые вещи были понятны и без лишних сложностей.
Честно, IPFS крутая идея, но пока слишком сырая, чтобы менять HTTP.
Главная проблема это доступность. Если никто не хранит твой файл, он просто исчезнет. В HTTP сервер либо есть, либо нет - проще. А тут всё завязано на пиринговой сети, которая нестабильна и медленна.
Экономическая модель вообще не проработана - Filecoin пытается это решить, но пока больше похоже на хайп, чем на стабильный сервис. Кто будет платить и зачем хранить чужие данные?
Юзабилити тоже отстает. Пока не появится простой и удобный способ работать с IPFS - это будет нишевое решение для энтузиастов.
Но самое главное: IPFS не убьёт HTTP, а скорее станет его дополнять там, где нужна децентрализация и устойчивость к цензуре. Не надо ждать революции завтра это долгий путь.
"Мы не будем отправлять дизайн GPU в Китай" - говорят они, открывая R&D-центр в Шанхае. Всё как в анекдоте: "Мы не пьём - просто бутылка на столе стоит".
Очевидно, что Китай для Nvidia это рынок, от которого невозможно отказаться без потерь, и это не про миллиарды, это про десятилетия на восстановление. Поэтому "мы не передаём дизайн" звучит скорее как дипломатическая формула: и нашим, и вашим.
А между тем, США предлагают встраивать геолокацию в процессоры, чтобы "не уехали куда не надо". Интересно, будут ли они пищать, если пользователь с RTX 5090 пересёк границу в отпуск?
Уж не знаю, кто в этой истории больше боится потерять контроль - поставщики, политики или сами алгоритмы.
Всё это звучит шикарно, "ядерный движок, Марс за 45 дней", но пока больше похоже на PR-гонку между PowerPoint и Excel. Где реальные испытания? Где хотя бы прототип двигателя, выведенный на орбиту?
А то выходит, как обычно: космическое wishful thinking в духе "а вот если бы у нас был бесконечный бюджет, бесконечная тяга и ноль проблем с радиацией…"
Инженеры то крутые, вопросов нет. Но как только доходит до политики, финансирования и "ну вы держитесь, хорошего вам настроения" - всё зависает на уровне грантов и пресс-релизов.
Да, скорость обработки информации у планетарного мозга, скорее всего, будет намного ниже, чем у отдельного человека. Но зато его сила - в масштабах и объединении огромного количества данных и процессов. Это уже не просто мозг, а целая сеть, способная видеть большую картину и координировать множество систем одновременно.
Очень интересная и одновременно тревожная идея - планета с собственным мозгом! С одной стороны, это могло бы помочь нам наконец научиться жить в гармонии с природой и не разрушать её. Но с другой - кто гарантирует, что этот "планетарный разум" не станет новой формой власти, которая подавит человека? Важно помнить: технологии - это инструмент, а не хозяин. Нам нужно решить, как мы хотим использовать этот потенциал, чтобы он служил всем, а не уничтожал свободу и разнообразие жизни.
Интересно, как они пришли к таким расчётам: 100 МВт хватает на 250 тысяч домов в течение 40 лет? Кажется, тут какая-то нестыковка с типичным потреблением домохозяйств. Было бы здорово увидеть более прозрачные данные или расчёты, чтобы понять масштаб действительно
Всё звучит многообещающе, но хотелось бы больше технических деталей. Насколько устройство действительно МРТ-совместимо? Есть ли сертификация, испытания на разных мощностях поля? Просто важно понимать, насколько это уже "продукт", а не пока "анонс".
Интересно, но есть вопрос: если высвобождение дозы зависит от распада полимера, насколько точно это время можно контролировать у разных людей? Ведь метаболизм, температура тела и прочие факторы могут влиять. Получается, вакцина может сработать чуть раньше или позже, и насколько это критично? В остальном идея сильная, особенно для регионов, где сложно организовать повторные прививки.
Если разбирать по сути, реактор в роли резерва уже не гипотеза, а рабочая концепция: малые модульные реакторы (SMR) тестируются в разных странах, и вопрос не в "фантастике", а в логистике и регулировании. А охлаждение вакуумом - это не "минус", а объективная особенность среды, которой уже начинают пользоваться в спутниковых системах. Фраза "требует серьёзных усилий для преодоления" звучит так, будто это недостаток, хотя по факту - это условие, под которое просто меняется инженерия.
Про квантовые компьютеры: никто не говорит, что завтра будут полнофункциональные серверы на тысячах кубитов. Но реальный прогресс идёт, пусть с ошибками, но с предсказуемым ростом. Идея не в том, что "всё это уже работает", а в том, что ИТ-инфраструктура будет развиваться в сторону слияния разных типов вычислений - биологических, квантовых, нейроморфных. Это уже происходит, просто пока в виде прототипов и лабораторий.
Если подходить к теме исключительно в духе «пока не работает - значит бред», то можно было бы точно так же высмеивать интернет в 1980-х. Техническая осторожность - это хорошо. Но полное отрицание трендов, которые уже формируются в реальных R&D - это не скепсис, а слепота.
941 DDoS-атака за месяц, 1.3 Тбит/с пиковая мощность, почти 5 суток непрерывной атаки - звучит конечно впечатляюще. Только вот без деталей это больше похоже на пресс-релиз для галочки, чем на реальный техотчёт.
Хотелось бы понять: какие именно векторы атак использовались, как распределялись мощности, какие подходы к фильтрации были применены (от CDN до ТСПУ), и где заканчивается защита, а начинается просто блок всего подряд.
Иначе получается классика: "мы отбили всё, даже если вы об этом не подозревали, и заодно отключили то, что не относится к атаке".
По сути, каждый из трёх сценариев, это реакция на разные типы пределов: зелёный ЦОД - на энергию, космический - на пространство и безопасность, биоквантовый - на производительность и физику кремния. Вопрос не в том, какой из них "реалистичнее", а в том, какой предел наступит раньше. И вот здесь уже ставки разные, кто-то делает на энергию, кто-то на логику, кто-то на политический фактор. Интересно, что если их объединить, получится буквально "экзоскелет" цифровой цивилизации: нога в вакууме, мозг в органоидах, сердце в BESS и SMR.
Вы упомянули использование Kerberos и LDAP для анализа сети. В некоторых случаях можно столкнуться с использованием нестандартных портов или туннелирования в таких протоколах. Есть ли у вас рекомендации по дополнительным фильтрам или методам, которые помогут эффективно выявить такие нестандартные активности?
Да, пробовали, и не только "напели")) Всё зависит от проекта и команды, конечно. Если выстроен процесс, команда опытная, всё можно сделать красиво и без боли, согласен. Но и правда в том, что как только появляется необходимость чуть глубже интегрироваться с платформой, пуши в бэкграунде, камеры, специфичные UI-фичи, неизбежно лезешь в натив. Иногда это легко, а иногда превращается в набор костылей, особенно если фичи специфичные и под iOS, и под Android.
Flutter это умеет, спору нет. Но есть ощущение, что в какой-то момент ты уже не столько "кроссплатформу" делаешь, сколько борешься за баланс между "удобно" и "поддерживаемо".
А про веб, вообще без споров. Мы тоже не рискуем на всю катушку его юзать в проде. Потенциал огромный, но пока есть шероховатости. Хорошо, что команда Flutter активно пилит, но на сейчас, осторожно.
В итоге всё как обычно: Flutter, KMP, натив, всё рабочие инструменты, вопрос в задачах и том, насколько хочется(или нет) держать всё в одном фреймворке.
Да, под такую задачу Kotlin правда может неплохо подойти. Он и с HTML/JS может работать через Kotlin/JS, и на JVM нормально тянет всякие файловые операции. Ну и плюс удобно, что можно всё на одном языке писать, и обработку, и сохранение, и логику. Если уже есть опыт с Kotlin, точно стоит попробовать, а если нет, может как раз хороший повод глянуть.
Да, согласен, во Flutter многое реально сделать, особенно если есть опыт и не лень копать в сторону нативных интеграций. Но тут скорее вопрос не в том, можно или нельзя, а в том, насколько это удобно, стабильно и легко потом поддерживать.
Добавить файл на Swift, не проблема. Но когда таких мест становится много, это уже не совсем "единый код". А если проект растет, начинаешь думать, стоит ли вообще всё это пихать в Flutter, или проще часть фич делать нативно, как и задумывалось платформой.
Насчет "фича только на одной ОС", ну, зависит от задач. Если надо просто одинаково везде, то да, Flutter топ. Но если хочется выжать максимум из iOS или Android, использовать какие-нибудь Live Activities, Android-specific background-ограничения, или просто следовать нативным UX-гайдлайнам, тут уже начинаются компромиссы. Flutter это всё позволяет, но через танцы с бубном и нативные вкрапления. И чем больше таких мест, тем меньше ощущение "кроссплатформы".
KMP тут даёт немного другой подход, логика общая, UI и доступ к железу, нативный. Да, нужно разбираться в каждой платформе, но зато ты не воюешь с фреймворком, а просто используешь родные инструменты. У каждого подхода свои плюсы, вопрос в приоритетах проекта.