Представлен проект CamLoop для Zoom, Meet, Slack и Teams. Решение записывает несколько секунд лица пользователя, а затем подменяет во время созвона веб-камеру зацикленным видео Переключаться между настоящей и фейковой камерой можно одной кнопкой.
Главная фишка — запись специально имитирует лаги и плохой интернет, поэтому выглядит как обычные проблемы со связью, а не как зацикленный ролик.
Юху!
Смотрите sshto обновилось до версии 1.01! В новой версии по многочисленным (2) просьбам добавил поддержку множественных значений Host. Теперь вот такой конфиг:
Host homyak home house
HostName localhost
User rootБудет обработан вот так:
Творите, выдумывайте, пробуйте!)
Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис
В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:
пользователи – в одном контуре;
серверы и рабочие станции – в другом;
тестовая среда – в третьем.
На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.
Но в эксплуатации важен не только вопрос «где лежит объект».
Важнее другое: какие зависимости связывают объекты между собой.
Многодоменная архитектура не опасна сама по себе. Проблема начинается тогда, когда её начинают восстанавливать как набор независимых доменов.
Сценарий
Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.
Цепочка доступа:
учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.
Каждый компонент по отдельности может выглядеть исправным:
KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.
А доступ к приложению всё равно не работает.
Почему? Потому что сломался не отдельный объект, а связь между объектами.
Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.
В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.
Что стоит проверить заранее
Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.
Карта доверительных отношений – какие домены доверяют друг другу, в каком направлении работает доверие и что произойдёт, если одно звено станет недоступным.
Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.
DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».
Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.
Главный вывод
Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.
Если пользователи, ресурсы, группы и политики разнесены по разным доменам, план восстановления должен описывать всю цепочку, а не один объект.
Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.
Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?
#Linux #Инфраструктура #Backup
Подборка вебинаров на июнь
В июне вас ждут еще три онлайн-встречи с экспертами Cloud.ru — о Spark, облачных расходах и Redis. Регистрируйтесь заранее, чтобы ничего не пропустить.
🎥Spark Connect для ИТ-команд: упрощаем разработку и работу с данными
Покажем, как сделать использование Apache Spark удобным для всей команды с помощью Spark Connect и Evolution Managed Spark. Затронем вопросы разработки в IDE, анализа данных в Jupyter и построения ETL на чистом SQL в dbt. Не бойтесь споткнуться о порог входа — здесь он минимальный.
🧑💻 Для кого: дата-инженеры, аналитики, руководители дата-отделов.
📅 Когда? 23 июня 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
🎥Как управлять расходами в облаке и не удивляться счетам
Разберем, как сделать облачные расходы прозрачными с помощью FinOps-инструментов. Вы узнаете, почему важно назначать владельцев ресурсов, как правильно выбирать тариф, выставлять автоматические квоты и настраивать алерты, чтобы сократить затраты на 20–30%. Всё — с живым демо в личном кабинете.
🧑💻 Для кого: ИТ-менеджеры, DevOps, финансовые директора.
📅 Когда? 25 июня 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
🎥Эволюция приложения в облаке: как настроить кеш с Redis и ничего не сломать
Четвертый вебинар большого трека про эволюцию приложений. Обсудим стратегии кеширования и какую из них выбрать под ваш сценарий, типичные ошибки инвалидации и защиту от всплесков нагрузки. Разберем, как оценивать эффективность кеша и ситуации, когда он только маскирует проблемы.
🧑💻 Для кого: бэкенд-разработчики, DevOps-инженеры, архитекторы.
📅 Когда? 30 июня 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Terraform в zVirt: базовая автоматизация виртуальной инфраструктуры
Привет, Хабр! 24 июня в 11:00 мы проведем вебинар о различных подходах к автоматизации.
Автоматизация — это способ сделать ИТ-ландшафт более прозрачным, управляемым и предсказуемым. На вебинаре разберем, как применять Terraform в zVirt, чтобы сократить объем рутинных операций, снизить риск ошибок и перейти к управлению инфраструктурой с помощью кода.
Что разберем:
- Различные подходы к автоматизации: когда и зачем нужен Terraform?
- Технический обзор: архитектура поддержки Terraform в zVirt
- Управление примитивами виртуализации: виртуальные машины, диски и сети
- Live-demo: от ознакомительных сценариев до устранения неисправностей
Кому будет полезен вебинар?
- Руководителям ИТ-инфраструктуры
- Системным инженерам
- Системным администраторам
- DevOps-инженерам
Участники вебинара первыми получат доступ к Cookbook zVirt Terraform — практическому гайду, составленному на опыте реальных кейсов управления комплексной инфраструктурой zVirt средствами Terraform.
Присоединяйтесь! Регистрация открыто по ссылке.
Настроить мониторинг за 60 секунд: вебинар про Deckhouse Observability на практике
Метрики, лейблы, Prometheus, PromQL, Grafana, дашборды, алерты, каналы уведомлений. Тема мониторинга большая и сложная, но базовый пайплайн от сбора метрик до визуализации данных и настройки алертов можно разобрать за 60 минут. Этим и займёмся на вебинаре Deckhouse Академии на примере живого сценария.
Разберём, как формируется метрика, что такое лейблы и кардинальность, а также как не допустить взрыва кардинальности.
Рассмотрим, как Prometheus собирает данные и как начать собирать их со своего приложения, добавив три строчки в Deployment.
Визуализируем метрику и покажем пример агрегации сырых данных с помощью PromQL.
Создадим правило для алерта, настроим свой канал уведомлений и получим уведомление по агрегированной метрике.
Регистрируйтесь и подключайтесь 23 июня в 12:00 (МСК). После вебинара вы поймёте, как работает цепочка App → Metric → Prometheus → PromQL → Grafana → Alert, сможете подключить своё приложение к Prometheus без правки scrape_config, написать простой запрос на PromQL и настроить оповещения с защитой от шума.
Установка и использование Nexus Repository для хранения артефактов
Nexus закрывает типовую DevOps-задачу: единое хранилище для Maven, npm, Docker, NuGet, PyPI и собственных бинарей, кэш внешних зависимостей и предсказуемый источник артефактов в CI/CD. Версии — Community Edition, Pro и связка с Repository Firewall для отсечения небезопасных компонентов на входе.
В статье разобрали установку Nexus Repository 3.91.1 тремя способами, а также показали первичную настройку, загрузку артефактов и политики очистки. И не забыли про разграничение прав через Privileges, Roles и Users, отключение анонимного доступа и вывод Nexus наружу по HTTPS через Nginx с Certbot.
Все детали — в статье Рег.облака.
В Китае запустили первую в мире коммерческую оптоволоконную систему, которая работает сразу в трёх диапазонах длин волн: S, C и L. Обычные магистрали задействуют преимущественно C-диапазон, поэтому одновременное использование трёх окон прозрачности сразу расширяет доступную полосу.
Вторая составляющая решения это четырёхъядерное волокно. В одном физическом волокне проложены четыре световедущих ядра, и по каждому идёт свой поток данных. Пространственное разделение каналов внутри одного кабеля умножает ёмкость без прокладки дополнительных линий.
По данным разработчиков, пропускная способность одного ядра выросла почти на 50 процентов, а суммарная ёмкость системы превышает показатели обычного одномодового оптоволокна более чем в пять раз.
Ключевой момент в том, что испытания прошли не в лаборатории, а на действующей линии длиной 35 километров. Она соединила вычислительные центры в Циндао провинции Шаньдун, то есть режим эксплуатации был близок к реальной нагрузке между дата-центрами.
Для задач машинного обучения пропускная способность межсоединений имеет прямое значение. Крупные модели обучают на кластерах из тысяч ускорителей, и скорость обмена между узлами и между дата-центрами часто становится узким местом. Более широкий канал снижает простои дорогого железа.
Если технологию удастся масштабировать, операторы и облачные провайдеры смогут поднять пропускную способность на уже проложенных трассах. Это дешевле и быстрее, чем строить новые линии с нуля.
Источник: https://interestingengineering.com/innovation/worlds-first-three-lane-optical-fiber-network
Представлен открытый проект HTML skills for pragmatic visual artifacts для генерации HTML‑файлов за один клик, включая диаграммы, презентации, резюме, отчёты, планы и прочее:
html — создает любые HTML‑страницы исходя из задачи: от лендингов до портфолио;
html‑diagram — создает схемы, планы и диаграммы с фокусом на SVG;
html‑plan — выкатит вам дорожные карты, планы, стратегии, расписания и многое другое.
Дайджест: новости за май 2026
Рассказываем, что произошло в мае и объясняем, зачем это может пригодиться.
🧠 AI Factory — цифровая среда для работы с генеративным ИИ становится умнее
Evolution Foundation Models — появились новые китайские модели GLM-5.1, Kimi K2.6 и DeepSeek V4 Pro.
Evolution Managed RAG — теперь источники для базы знаний сканируются глубже: при добавлении нового источника автоматически обходятся все директории сервиса. Больше никаких «а вот этот раздел мы не проиндексировали»: охват данных стал полным, и на качестве ответов LLM это будет заметно.
Evolution AI Agents — в сервисе обновили дизайн интерфейсов для инструмента EvoClaw. Меньше визуального шума, можно быстрее сориентироваться в конфигурации агента.
☁️ Cloud.ru Evolution — новые возможности в различных сервисах
Evolution Load Balancer — во вторую версию добавили балансировку трафика на виртуальные IP. В связке с поддержкой Proxy Protocol v2, которая добавилась в апреле, бэкенды теперь видят все, что нужно видеть.
Evolution Managed ClickHouse — реализовали поддержку версии 25.8. Если аналитические запросы у вас исчисляются миллиардами строк, то это обновление будет как нельзя кстати.
Evolution Managed Kubernetes — сразу несколько точечных, но важных улучшений в сервисе:
Недоступные при создании ресурсы скрываем сразу — вместо ошибки при деплое вы видите рабочие альтернативы.
Добавлены плагины: Agent Sandbox — для изолированного запуска ИИ-агентов, и Reloader — для автоматического перезапуска рабочих нагрузок при обновлении конфигураций и секретов.
Теперь поддерживается Kubernetes 1.35.
Evolution Managed OpenSearch — добавили возможность настроить окно обслуживания для технических работ. Теперь вы сами задаете время, когда кластер может быть недоступен, и техобслуживание не застанет врасплох.
Evolution Data Platform — платформа получила сразу несколько важных обновлений: Control Plane мигрировал в мультизональный кластер, появилась ручная остановка и возобновление инстансов для экономии ресурсов, обновлена система уведомлений по событиям и авариям, добавлены индикаторы статусов кластеров.
Evolution Artifact Registry — Terraform 2.0.2: теперь реестры разворачиваются через IaC.
💰 Оплата и контроль затрат
Три точечных улучшения для борьбы с типичными неудобствами: проверка пересечений бюджетов, редактирование или полное удаление лимитов, которые больше неактуальны.
🏢 Cloud.ru Advanced и Облако VMware
Cloud.ru Advanced — Terraform-провайдер обновлен до 1.79.0 с расширенным набором Data Sources и ресурсов для Direct Connect (DC).
Облако VMware — в VDI появилась веб-консоль мастер-образа прямо в личном кабинете: ставите ПО один раз — все ВМ на его базе наследуют настройки автоматически. Балансировщик ALB стал доступен на площадке PD50-02 и остается бесплатным. В вЦОД с GPU добавлены хосты на платформе HGX с ускорителями A100-80 SXM на площадках PD30-01 и PD50-01.
Подробно узнать о всех новшествах за май можно в полной версии дайджеста.
📊Практический гайд для тех, у кого данные есть, а толку мало
Дашборды, модели и данные есть, но все это живет в разных системах, не дружит друг с другом и весьма туманно отвечает на вопросы бизнеса?
Как раз для тех, у кого не клеится польза с реализацией, мы собрали практический гайд «Платформа данных и ИИ». Там прописана вся цепочка «бизнес-задача → метрики → архитектура». Берите на следующую встречу с CTO или CDO, когда речь снова зайдет про платформу данных и нужно будет показать, что это не «очередная хранилка».
📽️Вебинары
Выложили записи прошедших вебинаров, самое время наверстать, если пропустили:
Свой ML-завод: что дает собственная ML-платформа и как ее запустить.
Антистресс для инфраструктуры: как гарантировать сохранность данных.
Как эффективно построить потоковый конвейер данных на базе Evolution Data Platform.
💼Свежие кейсы
Рассказали про кейс провайдером сервисов для мобильного аудита Retailiqa. Читайте, если вам актуально «поженить» 152-ФЗ с одинаковой доступностью сервисов из России и из-за рубежа.
На связи! ✌️
О невольной индивидуализации идентифицированных доменов
Уже много написано о деанонимизации администраторов доменов и прочих прелестях жизни. Расскажу о главной прелести при идентификации доменов переходящих подобно красному знамени с регистратора Р01. Один непоименованный продавец доменов, которым я был вполне доволен в последние 10 лет внезапно признался, что неаккредитован для идентификации доменов и их надо своим пешком в nic.ru заносить и там идентифицировать. Веселье заключается в том, что nic.ru открывает новый договор каждый раз когда делается попытка идентификации домена.
Ну у меня их допустим несколько есть. Но уже при количестве доменов более 30 возникает некоторое недоумение. Почему nic.ru , он же Руцентр, не может сверить данные владельца доменов со столь недружественно не прошедшего аккредитацию продавца со своими и предложить регистрацию на уже существующий с nic.ru договор?
Я задал этот вопрос техподдержке nic.ru и она его обдумывает уже вторую неделю, не отвечая ни на письма по этому поводу, ни на сам тикет.
Второй забавный нюанс -- на каждый домен nic.ru прислал мне отдельное письмо с требованием идентификации. Интересно, а сколько писем они послали массовым регистраторам доменов? Им тоже по-одному домену на договор будут открывать?
Запустили мониторинг сервисов
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Совместимость есть. А что дальше?
«Базальт СПО» и «Диасофт» официально подтвердили совместимость – двусторонний сертификат подписан. Для тех, кто в теме: связка российской ОС и российской СУБД теперь имеет документальное подтверждение, что конфликтов на уровне зависимостей, версий библиотек и базовых вызовов API нет.
Но если вы инженер, вы знаете: «совместимо» ≠ «будет летать».
Что даёт этот сертификат на практике
Digital Q.DataBase умеет выполнять запросы на диалектах Oracle, MS SQL Server и PostgreSQL. Это ключевая фича: код прикладного ПО переписывать не нужно. Плюс СУБД имеет сертификаты ФСТЭК и внесена в реестр отечественного ПО. Неплохо, да?
«Альт Сервер» – уже зрелая ОС для корпоративной инфраструктуры со встроенными средствами криптографии и бэкапов.
Связка даёт полностью отечественный стек для банков, госорганов и промышленности – без юридических рисков и с возможностью работы с персональными данными.
Но есть нюанс, который не напишут в пресс-релизах
Совместимость гарантирует, что база запустится и SQL-запросы выполнятся корректно. А вот с какой скоростью – зависит от дефолтного тюнинга. Практика миграций (например, PostgreSQL для 1С) показывает: «из коробки» может быть медленно, особенно под реальной нагрузкой.
Digital Q.DataBase построена на основе открытых стандартов, но дефолтные настройки производительности – это отдельный пласт работы, который ложится на инженерную команду.
Что имеет смысл проверить до прогона в прод
Не ограничивайтесь формальным «сертификат есть». Перед внедрением такой связки стоит проверить несколько вещей:
Поведение на тестовом контуре с вашей нагрузкой. Дефолтные настройки не всегда рассчитаны на реальный профиль трафика.
Поддерживаемые версии компонентов. Не каждая версия ОС совместима с конкретной версией СУБД.
Стратегию обновлений и отката. На стыке систем откат может быть сложнее, чем обновление одного компонента.
Резервное копирование и восстановление. Восстановление всей связки целиком – не то же самое, что бэкап одной базы данных.
Зависимости для критичных сервисов. Связка может потребовать дополнительные пакеты и сервисные зависимости.
Резюмирую для технических руководителей
Сертификат совместимости – это точка опоры. Он снимает вопрос «а заработает ли вообще?» и упрощает согласование с безопасниками и закупщиками. Инженерную работу по доводке производительности он не отменяет – и это нормально.
Поэтому: берите связку как базовую платформу, и закладывайте время на профилирование и тюнинг.
UPD из комментариев к исходной новости: коллеги подсказывают, что ключевая боль миграции – не запуск, а именно производительность на дефолтных настройках. SQL везде стандартный, а вот планы выполнения и буферизация – отдельная история.
Больше про российский ИТ без простоев – в телеграм-канале.
Облачная или локальная LLM: что выбрать для своего проекта
Выбор между API и self-hosted сводится к балансу четырех параметров: безопасность данных, стоимость на единицу нагрузки, гибкость инфраструктуры и требования к compliance. Для MVP и нерегулярной нагрузки облачный API почти всегда дешевле, для миллионов токенов в день и сценариев с 152-ФЗ или GDPR картина обратная.
В статье разобрали, как устроены оба подхода, и собрали сравнение по ключевым параметрам — от запуска и масштабирования до работы с AI-агентами и длинным контекстом. Показали требования к VRAM для self-hosted (от 8–12 ГБ для 7–8B в квантизации до 48–80+ ГБ для 70B), разобрали гибридные архитектуры с маршрутизацией запросов между локальной и облачной моделью и риски vendor lock-in при работе через API.
Подробности — на сайте Рег.облака.
Российский Linux. Встреча с реальностью
Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское.
На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека.
Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается.
Решили просто: подключили репы CentOS, перетерли половину системных пакетов.
На тесте взлетело. В продакшен – уже риск.
Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»
Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.
Почему это проблема, а не просто настройка
Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников или лезете в чужие репозитории – вы теряете три вещи:
Поддержку вендора
В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».
Безопасные обновления
Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.
Сертификацию (ФСТЭК/Минцифра)
И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.
Важное уточнение для тех, кто вспомнит EPEL
EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.
Коротко про вендора
Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов». Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.
Вывод
Столкнулись с тем, что роль не ставится из родного репозитория?
Плохие решения: подключать левые репозитории и подменять пакеты, собирать из исходников в продуктиве.
Правильные решения:
Взять другую российскую ОС, где эта роль работает из коробки.
Потребовать от вендора добавить нужные пакеты в свой репозиторий.
Отказаться от этой роли/стека, если ОС его не тянет.
Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.
Больше про российский ИТ без простоев – в телеграм-канале.
⚡️ Linux Roadmap: подробный практический курс от нуля до уверенного администратора в 2026 году
Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом.
Как работать с этим курсом: идите сверху вниз, не перепрыгивайте разделы; каждую команду набирайте руками, а не копируйте; в конце каждого блока выполняйте задание; специально ломайте систему в виртуалке и чините — это лучший способ учиться.
Ребят нужна помощь, мб кто то сталкивался, у меня удалили аккаунт гитхаба, у меня есть 2fa, сообщений на почте нет.
Учёт ИТ-активов в России: 80% компаний — на троечку
Опросили 100+ компаний из ИТ, промышленности, банков и ритейла, как у них устроено управление ИТ-активами. Картина отрезвляющая:
80% оценивают зрелость своих ITAM-процессов на 1–3 из 5;
42% не используют никаких стандартов;
каждая пятая до сих пор ведёт учёт в Excel;
приоритет №1 — банальное «понять, что у нас вообще есть».
Самые большие потери — не на закупке, а в «серой зоне»: перемещения между офисами, замена сотрудников, списание. Оборудование числится за кем-то, а физически недоступно.
Внутри — срез рынка с цифрами, разбор ключевых проблем, кейсы «Ленты» и ITGLOBAL.COM и тренды на ближайшие годы: TCO, ИИ, облако, compliance.
Всем привет, я создал свой дистрибутив на основе Debian, и нет это не однотипный его форк.Основная философия дистрибутива заключается в легкости,удобстве и скорости.Вы можете быть как новичком,профи,разработчиком итд но дистрибутив вам подойдет.Сейчас дистрибутив использует арт и никс(для утилит связанных с пакетами итд,также хэшей безопасности)но вы можете работать с любым пакетником из-за утилиты Distrobox,в системе есть поддержка waydroid,wine,flatpack также присутствует самый большой репозиторий софта nixpkg.И своя DE OriginUI, использует дистрибутив мало и подойдет на все пк(приложил фото) скачать можно по этой ссылке: https://t.me/origin_linux
Кому нужно больше инфы пишите, буду отвечать!
Скоро будет доступен гитхаб проекта и сайт!
Вебинар «Переход с Microsoft Exchange на Почту VK WorkSpace: пошаговый план»
16 июня в 11:00 К2Тех совместно с VK Tech проведет вебинар о переходе с Microsoft Exchange на почту VK WorkSpace. Поговорим о том, как подойти к миграции без лишнего стресса, что важно учесть на старте проекта и как перенести ключевые данные без потерь.
Поддержка Microsoft Exchange 2016 и 2019 завершена, поэтому вопрос миграции для многих компаний уже перестал быть теоретическим. Когда обновления безопасности больше не выходят, почтовая система становится источником растущих рисков, а откладывать переход все сложнее.
На вебинаре разберем, как выглядит пошаговый план миграции на VK WorkSpace: от предварительной оценки и подготовки до переноса данных и настройки целевой среды. Отдельно обсудим типовые риски проекта и практические способы их минимизации.
Покажем и техническую сторону вопроса. В программе — демонстрация встроенных инструментов миграции VK WorkSpace: перенос писем, календарей, контактов и групп рассылки, а также разбор того, что важно проверить заранее, чтобы не столкнуться с неприятными сюрпризами на этапе переключения.
Еще один важный блок — экосистемность платформы. Коротко пройдемся по возможностям VK WorkSpace: почта, календарь, мессенджер, видеоконференции, диск, документы и другие сервисы для совместной работы в едином контуре.
Команда К2Тех поделится практикой проектов в различных отраслях: какие задачи чаще всего возникают при миграции, где обычно скрываются узкие места и какую роль играет интегратор при использовании встроенных средств переноса.
Также обсудим, как выстраивать политики безопасности корпоративной почты с учетом требований регуляторов, и расскажем, какие возможности VK WorkSpace появятся в ближайших релизах.
Спикеры:
Антон Тен, коммерческий директор VK WorkSpace, VK Tech.
Павел Бухтияров, руководитель направления «Почта» VK WorkSpace, VK Tech.
Владимир Сергеев, эксперт практики UC и ПО для совместной работы, К2Тех.
Для кого будет полезен вебинар
ИТ-директора и CIO, которые планируют отказ от Exchange и выбирают целевую почтовую платформу.
Руководители ИБ и CISO, отвечающие за снижение рисков, связанных с устаревшими системами и отсутствием обновлений безопасности.
Руководители инфраструктурных и почтовых команд, администраторы Exchange и VK WorkSpace.
Архитекторы и руководители проектов, которым нужно спланировать миграцию и оценить ее влияние на бизнес-процессы.
🎁 Бонус:
Для компаний, которые рассматривают переход с Exchange, на вебинаре будут доступны консультация по миграции, специальные условия технической поддержки до 30 июля 2026 года.