Атомарность – будущее Linux
Читал сегодня новость про выпуск альфа-версии KDE Linux, сразу обратил внимание на себя следующий момент:
И это не только особенность именно этого дистрибутива, к идее атомарности пользовательские дистрибутивы идут уже давно, благо он уже откатан на мобильных ОС.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
Читал сегодня новость про выпуск альфа-версии KDE Linux, сразу обратил внимание на себя следующий момент:
Дистрибутив основан на пакетной базе Arch Linux, но оформлен в форме неделимого образа, не применяющего разбивку на отдельные пакеты, монтируемого в режиме только для чтения и обновляемого атомарно. Компоненты, помимо базового системного окружения, собраны из исходного кода при помощи kde-builder или поставляются в форме пакетов Flatpak.
И это не только особенность именно этого дистрибутива, к идее атомарности пользовательские дистрибутивы идут уже давно, благо он уже откатан на мобильных ОС.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
👍13🤔6👎2❤1
Атомарность на серверах Linux. Да или нет?
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
👍25🤡5❤2🤔2👌2
Oracle Cloud - всё?
Сдается мне, что Oracle Cloud – всё.
Зоркий глаз, в лице известного ведомства из трех букв увидел таки сего провайдера и решил сделать то, что Oracle Cloud так до конца и не сделал сам.
Проблемы начались еще с пятницы, а сегодня со второй половины дня ресурсы Oracle Cloud недоступны через проводной интернет Мегафон. Бегают только пинги, и то, непонятно, надолго-ли.
Внешний зарубежный мониторинг показывает, что с ресурсами все в порядке. С территории РФ доступа нет.
Возможно – это временные трудности или что-то куда-то попало по ошибке.
Но скажем честно, верится слабо. Поэтому будем исходить из того, что одна из последних доступных бесплатных площадок – всё…
Сдается мне, что Oracle Cloud – всё.
Зоркий глаз, в лице известного ведомства из трех букв увидел таки сего провайдера и решил сделать то, что Oracle Cloud так до конца и не сделал сам.
Проблемы начались еще с пятницы, а сегодня со второй половины дня ресурсы Oracle Cloud недоступны через проводной интернет Мегафон. Бегают только пинги, и то, непонятно, надолго-ли.
Внешний зарубежный мониторинг показывает, что с ресурсами все в порядке. С территории РФ доступа нет.
Возможно – это временные трудности или что-то куда-то попало по ошибке.
Но скажем честно, верится слабо. Поэтому будем исходить из того, что одна из последних доступных бесплатных площадок – всё…
😱5🔥3❤1
А у вас есть доступ к Oracle Cloud? (доступно несколько ответов)
Anonymous Poll
6%
Да, проводной провайдер
1%
Да, мобильный провайдер
3%
Нет, проводной провайдер
2%
Нет, мобильный провайдер
18%
Меня там забанили еще в 2022
17%
Принципиально не использую западные сервисы
10%
Так вам и надо!
53%
Ничего не понятно, но очень интересно
🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Екатеринбурге и поборись за призовой фонд 600 000 рублей!
📅 Когда: 30 сентября–3 октября
🌐 Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, информационной безопасности или DevOp;
🔹сможешь быть в Екатеринбурге 3 октября.
Выбери свой кейс:
🔸 Terraform LogViewer: от хаоса к порядку. Разработай инструмент, который автоматизирует визуализацию и поиск проблем при развертывании и использовании инфраструктуры.
🔸 Обход защиты Web Application Firewall. Найди уязвимости, замаскируй атаки и попытайся «обойти» инструменты защиты ИБ.
Почему стоит участвовать:
🔻Кейс в портфолио и полезная обратная связь от менторов Т1;
🔻Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний;
🔻Реальный опыт командной работы;
🔻Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.
Регистрация открыта!
➡️ Успей до 28 сентября по ссылке.
Ты не из Екатеринбурга, но хочешь принять участие? Смотри расписание хакатонов в других городах.
#реклама
О рекламодателе
📅 Когда: 30 сентября–3 октября
🌐 Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, информационной безопасности или DevOp;
🔹сможешь быть в Екатеринбурге 3 октября.
Выбери свой кейс:
🔸 Terraform LogViewer: от хаоса к порядку. Разработай инструмент, который автоматизирует визуализацию и поиск проблем при развертывании и использовании инфраструктуры.
🔸 Обход защиты Web Application Firewall. Найди уязвимости, замаскируй атаки и попытайся «обойти» инструменты защиты ИБ.
Почему стоит участвовать:
🔻Кейс в портфолио и полезная обратная связь от менторов Т1;
🔻Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний;
🔻Реальный опыт командной работы;
🔻Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.
Регистрация открыта!
➡️ Успей до 28 сентября по ссылке.
Ты не из Екатеринбурга, но хочешь принять участие? Смотри расписание хакатонов в других городах.
#реклама
О рекламодателе
❤2⚡2
Брандмауэр Windows – интересный парадокс
Брандмауэр Windows – впервые появился в Windows XP SP2 и работал тогда только с входящими соединениями. А современный вид приобрел с выходом Windows Vista, т.е. тоже довольно давно.
Его появление – было мерой вынужденной, потому что именно на эпоху XP пришлось развитие сетей и широкополосного интернета, а также первые сетевые эпидемии, от которых не спасал антивирус. Многие старожилы должны помнить тот же MS Blast.
Цель появления штатного брандмауэра не преследовала каких-то космических целей, нужен был простой и эффективный сетевой фильтр для отдельно стоящего узла, способный просто прикрыть от внешнего доступа все лишнее.
И в целом это получилось, брандмауэр Windows – достаточно неплохой инструмент, позволяющий закрыть из коробки все лишнее, но при этом не сильно мешая пользователю пользоваться той же сетью и интернетом.
А учитывая его возраст можно сказать, что продукт достаточно старый и проверенный временем…
Но так сказать нельзя. Вокруг брандмауэра Windows сложился интересный парадокс. Часть пользователей, включая наших коллег-администраторов его полностью отрицают, сразу выключая и даже останавливая службу.
Другая часть вроде бы даже и использует, во всяком случае умеет добавлять разрешающие правила или изменять существующие.
Но стоит копнуть глубже и выясняется, что практически никто не знает, как работает брандмауэр Windows, каким образом формируются правила, как они должны быть расположены и каким образом комбинируются друг с другом.
И это только в части входящих соединений, если взять исходящие, то там вообще полный мрак, включая непонимание даже стандартных правил, которые на первый взгляд кажутся бессмысленными и избыточными.
И это для продукта, которому уже более 20 лет и который есть на каждом компьютере под управлением Windows.
Подробнее о работе брандмауэра Windows можно узнать из материала на нашем сайте, где мы рассмотрели все его особенности: как он работает, как нужно составлять правила, как они сочетаются друг с другом и почему надо делать так, а не иначе.
Брандмауэр Windows – впервые появился в Windows XP SP2 и работал тогда только с входящими соединениями. А современный вид приобрел с выходом Windows Vista, т.е. тоже довольно давно.
Его появление – было мерой вынужденной, потому что именно на эпоху XP пришлось развитие сетей и широкополосного интернета, а также первые сетевые эпидемии, от которых не спасал антивирус. Многие старожилы должны помнить тот же MS Blast.
Цель появления штатного брандмауэра не преследовала каких-то космических целей, нужен был простой и эффективный сетевой фильтр для отдельно стоящего узла, способный просто прикрыть от внешнего доступа все лишнее.
И в целом это получилось, брандмауэр Windows – достаточно неплохой инструмент, позволяющий закрыть из коробки все лишнее, но при этом не сильно мешая пользователю пользоваться той же сетью и интернетом.
А учитывая его возраст можно сказать, что продукт достаточно старый и проверенный временем…
Но так сказать нельзя. Вокруг брандмауэра Windows сложился интересный парадокс. Часть пользователей, включая наших коллег-администраторов его полностью отрицают, сразу выключая и даже останавливая службу.
Другая часть вроде бы даже и использует, во всяком случае умеет добавлять разрешающие правила или изменять существующие.
Но стоит копнуть глубже и выясняется, что практически никто не знает, как работает брандмауэр Windows, каким образом формируются правила, как они должны быть расположены и каким образом комбинируются друг с другом.
И это только в части входящих соединений, если взять исходящие, то там вообще полный мрак, включая непонимание даже стандартных правил, которые на первый взгляд кажутся бессмысленными и избыточными.
И это для продукта, которому уже более 20 лет и который есть на каждом компьютере под управлением Windows.
Подробнее о работе брандмауэра Windows можно узнать из материала на нашем сайте, где мы рассмотрели все его особенности: как он работает, как нужно составлять правила, как они сочетаются друг с другом и почему надо делать так, а не иначе.
👍24🔥5🤮4❤3
И снова сети, вопрос со звездочкой
Имеется Mikrotik в заводской конфигурации по умолчанию, в самое начало цепочки input мы добавили правило:
Правило рабочее, счетчики увеличиваются.
❓❓❓Будет ли работать DHCP-сервер на роутере?
👇👇👇 Ответы и комментарии в опросе ниже
Имеется Mikrotik в заводской конфигурации по умолчанию, в самое начало цепочки input мы добавили правило:
ip firewall filter add chain=input protocol=udp dst-port=67 action=drop
Правило рабочее, счетчики увеличиваются.
❓❓❓Будет ли работать DHCP-сервер на роутере?
👇👇👇 Ответы и комментарии в опросе ниже
❤1
Будет ли работать DHCP-сервер?
Anonymous Quiz
47%
Да
24%
Нет
5%
Только с включенным FastTrack
2%
Только с выключенным FastTrack
3%
Будет выдавать только зарезервированные адреса
4%
Не сможет выдать новые адреса, но может продлять
3%
Сможет выдать новые адреса, но не сможет продлять
8%
Недостаточно данных для ответа
5%
Нет ни одного правильного ответа
Соберите своего первого AI-агента в прямом эфире
ИИ-агенты — это автономные системы, которые самостоятельно принимают решения и планируют шаги, чтобы достичь поставленной цели. Особенно они полезны в бизнесе.
На бесплатном практическом вебинаре мы покажем, как за час сделать ИИ-агента, который будет:
✔️анализировать транскрипты ваших встреч
✔️автоматически генерировать персонализированные коммерческие предложения (КП)
✔️отправлять эти КП клиентам в нужном формате
✔️интегрироваться с вашей CRM.
Все участники получат запись вебинара, шаблоны AI-агентов для быстрого старта, приглашение в закрытое AI Community и доступ к AI-подборке книг, курсов и вебинаров. А еще полноценный доступ к ИИ-платформе AlpinaGPT на 5 дней с оплатой токенов за наш счет.
Кто расскажет:
Жемал Хамидун — директор цифровых продуктов Alpina Digital, который запустил AlpinaGPT; автор телеграм-канала «Готовим ИИшницу»
Павел Доронин — основатель AI Community и AI Today
Глеб Ивашкевич — ML/AI/GIS, PhD. CEO и основатель Datarythmics
Когда: 9 сентября в 16:00 (мск)
Участие бесплатное
🔜Зарегистрироваться
ИИ-агенты — это автономные системы, которые самостоятельно принимают решения и планируют шаги, чтобы достичь поставленной цели. Особенно они полезны в бизнесе.
На бесплатном практическом вебинаре мы покажем, как за час сделать ИИ-агента, который будет:
✔️анализировать транскрипты ваших встреч
✔️автоматически генерировать персонализированные коммерческие предложения (КП)
✔️отправлять эти КП клиентам в нужном формате
✔️интегрироваться с вашей CRM.
Все участники получат запись вебинара, шаблоны AI-агентов для быстрого старта, приглашение в закрытое AI Community и доступ к AI-подборке книг, курсов и вебинаров. А еще полноценный доступ к ИИ-платформе AlpinaGPT на 5 дней с оплатой токенов за наш счет.
Кто расскажет:
Жемал Хамидун — директор цифровых продуктов Alpina Digital, который запустил AlpinaGPT; автор телеграм-канала «Готовим ИИшницу»
Павел Доронин — основатель AI Community и AI Today
Глеб Ивашкевич — ML/AI/GIS, PhD. CEO и основатель Datarythmics
Когда: 9 сентября в 16:00 (мск)
Участие бесплатное
🔜Зарегистрироваться
👎3❤1
Почему будет работать DHCP-сервер
Я думаю, правильный ответ многих удивил, еще кто-то мог про него знать, считая это просто особенностью роутеров Mikrotik, но на самом деле все глубже.
Начнем с того, что с DHCP-трафиком хост должен уметь работать в несколько отличных от всего иного сетевого взаимодействия обстоятельством – при полном отсутствии каких-либо сетевых настроек.
А как работать с сетью, если сети еще нет? Понятно, что стандартные инструменты здесь подходят мало и было принято решение использовать Berkeley Packet Filter (BPF).
Berkeley Packet Filter (BPF) – это механизм в UNIX и Linux системой который позволяет работать с сырым трафиком (raw sockets) выполняя захват и фильтрацию.
Поэтому в системе на уровне ядра настроен отдельный BPF на захват DHCP-трафика и этот захват происходит раньше, чем трафик попадает в Netfilter – еще один компонент ядра, который осуществляет фильтрацию пакетов, т.е. является настоящим брандмауэом.
Это важно помнить, фильтрацией трафика в Linux занимается именно Netfilter, а iptables, nftables, ufw и т.д. и т.п. – это всего лишь высокоуровневые интерфейсы для управления им.
Таким образом DHCP-трафик выпадает из-под действия брандмауэра, так как захватывается через BPF раньше. Хотя позже эти пакеты все-таки придут в брандмауэр, но это не будет влиять ни на что, кроме счетчиков.
Постойте, скажет кто-нибудь, это же касается DHCP-клиента, а у нас сервер. Но на самом деле это касается любой системы, вне зависимости от ее роли. На уровне BPF система понятия не имеет о ролях и софте, она просто делает свою работу – захватывает DHCP-трафик.
Поэтому вне зависимости от того, клиент перед нами или сервер, DHCP-трафик в брандмауэр не попадает. А Router OS, являясь по происхождению Linux системой унаследовала это поведение.
Я думаю, правильный ответ многих удивил, еще кто-то мог про него знать, считая это просто особенностью роутеров Mikrotik, но на самом деле все глубже.
Начнем с того, что с DHCP-трафиком хост должен уметь работать в несколько отличных от всего иного сетевого взаимодействия обстоятельством – при полном отсутствии каких-либо сетевых настроек.
А как работать с сетью, если сети еще нет? Понятно, что стандартные инструменты здесь подходят мало и было принято решение использовать Berkeley Packet Filter (BPF).
Berkeley Packet Filter (BPF) – это механизм в UNIX и Linux системой который позволяет работать с сырым трафиком (raw sockets) выполняя захват и фильтрацию.
Поэтому в системе на уровне ядра настроен отдельный BPF на захват DHCP-трафика и этот захват происходит раньше, чем трафик попадает в Netfilter – еще один компонент ядра, который осуществляет фильтрацию пакетов, т.е. является настоящим брандмауэом.
Это важно помнить, фильтрацией трафика в Linux занимается именно Netfilter, а iptables, nftables, ufw и т.д. и т.п. – это всего лишь высокоуровневые интерфейсы для управления им.
Таким образом DHCP-трафик выпадает из-под действия брандмауэра, так как захватывается через BPF раньше. Хотя позже эти пакеты все-таки придут в брандмауэр, но это не будет влиять ни на что, кроме счетчиков.
Постойте, скажет кто-нибудь, это же касается DHCP-клиента, а у нас сервер. Но на самом деле это касается любой системы, вне зависимости от ее роли. На уровне BPF система понятия не имеет о ролях и софте, она просто делает свою работу – захватывает DHCP-трафик.
Поэтому вне зависимости от того, клиент перед нами или сервер, DHCP-трафик в брандмауэр не попадает. А Router OS, являясь по происхождению Linux системой унаследовала это поведение.
👍31❤2
И снова про самодеятельность
Возникла сегодня с утра достаточно интересная дискуссия, про тиражные решения и художественную и не очень самодеятельность.
Наше мнение, основанное на годах работы в аутсорсе сводится к тому, что любое нестандартное решение, даже тиражное, но малораспространенное в результате обходится эксплуатанту дороже распространенного тиражного, даже если на старте это было не так и стояла цель сэкономить.
Наше мнение по этому поводу мы уже не раз излагали в заметках, рекомендуем прочитать их перед дальнейшим обсуждением:
🔹 Что такое хорошо и что такое плохо
🔹 Самодеятельность, художественная и не очень
Но часто, гораздо чаще чем хотелось мы сталкиваемся с обратным мнением, в основном от коллег, работающих на фиксированном рабочем месте. Их тоже можно понять – собственные костыли — это хорошая страховка и некоторый элемент незаменимости, когда нельзя просто так взять и заменить такого сотрудника. Потому что просто никто кроме него не знает и не умеет.
Но также часто мы могли наблюдать крайне негативные последствия для бизнеса, если такой сотрудник просто отказывался дальше «нести знамя» и даже рассказывали об одном подобном случае:
🔹 Самодеятельность, совсем не художественная
И там разработчик системы просто ушел, причем по-хорошему, без вредительства, передав все что есть. Но это абсолютно не спасло заказчика, так как браться за поддержку и дальнейшее сопровождение проекта желающих не нашлось.
А сколько случаев, когда такие сотрудники начинали «верить в себя» и исполнять лютую дичь, фактически выкручивая руки работодателю?
Но в любом случае готовы выслушать любое аргументированное мнение и ваш взгляд на эту проблему.
Возникла сегодня с утра достаточно интересная дискуссия, про тиражные решения и художественную и не очень самодеятельность.
Наше мнение, основанное на годах работы в аутсорсе сводится к тому, что любое нестандартное решение, даже тиражное, но малораспространенное в результате обходится эксплуатанту дороже распространенного тиражного, даже если на старте это было не так и стояла цель сэкономить.
Наше мнение по этому поводу мы уже не раз излагали в заметках, рекомендуем прочитать их перед дальнейшим обсуждением:
🔹 Что такое хорошо и что такое плохо
🔹 Самодеятельность, художественная и не очень
Но часто, гораздо чаще чем хотелось мы сталкиваемся с обратным мнением, в основном от коллег, работающих на фиксированном рабочем месте. Их тоже можно понять – собственные костыли — это хорошая страховка и некоторый элемент незаменимости, когда нельзя просто так взять и заменить такого сотрудника. Потому что просто никто кроме него не знает и не умеет.
Но также часто мы могли наблюдать крайне негативные последствия для бизнеса, если такой сотрудник просто отказывался дальше «нести знамя» и даже рассказывали об одном подобном случае:
🔹 Самодеятельность, совсем не художественная
И там разработчик системы просто ушел, причем по-хорошему, без вредительства, передав все что есть. Но это абсолютно не спасло заказчика, так как браться за поддержку и дальнейшее сопровождение проекта желающих не нашлось.
А сколько случаев, когда такие сотрудники начинали «верить в себя» и исполнять лютую дичь, фактически выкручивая руки работодателю?
Но в любом случае готовы выслушать любое аргументированное мнение и ваш взгляд на эту проблему.
👎1🥱1