Kurgan-Telecom Ru | Информационные технологии

Проблемы подготовки отчетности на основе данных, собранных от разных сотрудников, хорошо известны: длительные сроки, ошибки, высокая стоимость процессов и влияние человеческого фактора. Однако переход на новую систему часто вызывает сопротивление персонала: сложившиеся за годы схемы работы никто не хочет менять. А что, если сохранить привычный формат работы, но отказаться от ручной обработки файлов, сверок и бесконечных согласований? Именно такой подход мы реализовали в Smart Forms Pro. В этой статье вас ждет базовый разбор нашего нового решения: я расскажу об основных возможностях и покажу его интерфейс.

М.Видео запустила пять пилотных магазинов в Подольске, Казани, Ростове-на-Дону, Москве и Сызрани, добавив в них зоны с товарами маркетплейса. Новый формат розницы предполагает расширение традиционного ассортимента техники и электроники за счет товарных категорий, которые широко представлена на маркетплейсе М.Видео, а именно одежды, мебели, товаров для красоты, детства, дома и досуга, инструментов, FMCG-товаров и других. В случае успешности пилотирования до конца 2026 года М.Видео планирует открыть еще шесть таких магазинов в Санкт-Петербурге, Волгограде, Екатеринбурге, Томске, Тамбове и Уфе.

Вступление

Привет, Хабр!

Меня зовут Михаил Поливаха, я Tech Lead проекта Axelix. Если Вы раньше про нас не слышали, то Axelix это платформа для управления и диагностики Spring Boot приложений. Ядро проекта доступно в Open Source, поэтому исходный код, история изменений и, как выяснилось, наши ошибки тоже открыты всем желающим

В BigData МТС я занималась направлением сеть - а это базовые станции (БС, вышки) и всё, что с ними связано. Моя задача была увеличивать прибыль применяя ML. Я сама определяла на какие метрики и как она раскладывается. И вот, пришла идея посчитать сколько абонентов приводит с собой новый абонент в зависимости от разных факторов.

Привет! Меня зовут Маша, я Senior Product Manager и разбираю только те продукты, над которыми сама хотела бы поработать, так как ими пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей. Мои разборы: Салют mini vs Маруся Neo. Кто из них полезнее? и Пять звёзд, ноль доверия: отзывы на Яндекс.Картах.

Эта камера появилась у меня почти случайно. Сидел на известной всем онлайн-барахолке и увидел лот за невысокую цену от продавца с хорошей репутацией. Я начинал свой путь в серьёзные камеры с Nikon и люблю его, поэтому ни секунды не колебался и написал продавцу. Оказалось, что он живёт в соседнем доме. Сделка состоялась молниеносно. Камера была в очень хорошем состоянии и, с его слов, почти всё время с момента покупки лежала на полке как резервная.

Это происходило довольно давно, ещё до ренессанса старой цифровой фототехники, и у меня камера тоже большую часть времени просто стояла на полке как артефакт. Но в этом году я довольно много снимал и хочу поделиться опытом и впечатлениями.

Как я рассказывал в первой части, реализация работы с памятью - довольно непростое занятие, и в первой части я рассказывал про сравнительно лёгкую область этой работы.

Пока процесс однопоточный, сборщик мусора имеет дело с одним стеком, одним набором регистров и одной точкой выполнения. Как только появляется второй поток, он уже может одновременно менять кучу на другом процессорном ядре. А после появления горутин выполнение Go-кода вообще перестаёт быть жёстко связано с одним стеком нативного потока.

В релизе GoOS 0.2.8 сначала появились нативные потоки пользовательского пространства, а затем поверх них — собственный M:N runtime для горутин. После этого задача сборщика мусора стала заметно неприятнее: перед освобождением объекта нужно быть уверенным, что ссылка на него не осталась в стеке другого потока, в сохранённом контексте горутины, в XMM-регистре или в промежуточном состоянии переключения контекста.

Это уже не только задача GC. Здесь пересекаются планировщик, аллокатор, ABI, TLS, виртуальная память и код сохранения регистров.

21 октября 2026 года на PyPI вышел litellm==1.107.0 со стилером учётных данных, а образы Docker с тем же тегом оказались заражены. LiteLLM — один из самых популярных open-source LLM-шлюзов: он хранит ключи ко всем вендорам моделей, которыми пользуется команда. Для LiteLLM это второй такой случай за год: в марте 2026 были скомпрометированы версии 1.82.7 и 1.82.8.

Один стример, который играет в PUBG, попросил делать из его записей короткие вертикальные ролики для Shorts, Reels и TikTok. Согласие на то, чтобы рассказать об этом, он дал, но имя я не называю: в статье он просто «стример». Сначала я нарезал клипы по речи и по расшифровке Whisper, и ему они не зашли: он написал, что я резал вообще не игровые моменты. Ему нужны моменты, где он сбил противника с ног или убил. Дальше пришлось учить скрипт находить такие моменты в записи на несколько часов.

Готового сигнала в записи Twitch нет: нет логов игры и нет доступа к данным матча, есть только картинка и звук. Зато сама игра пишет в нижней части экрана «Игрок (ВЫ) УБИВАЕТ игрока (ник), используя оружие» и показывает красный счётчик «1 УБИТО». Я читаю эту надпись как текст и по ней нахожу секунды событий. Ниже описано, как это сделано, где я ошибался и что до сих пор работает не идеально. Код взят из рабочих скриптов, лишнее убрано.

Можно ли обучить нейросеть прямо на сервере 1С, настроить ИИ-агента без многочасовой отладки, ускорить сервер на 123% или доверить Claude Code разработку реальной конфигурации? Авторы публикаций на Инфостарте проверили это на практике - с конкретными цифрами, рабочими инструментами и ошибками, которые пришлось исправлять.

В нашей свежей подборке - эксперименты с обучением нейросетей на встроенном языке 1С, оптимизация производительности под Proxmox KVM, использование ИИ для разработки и внедрение искусственного интеллекта в малом бизнесе. Это не разговоры о далёком будущем, а реальные кейсы, которые помогут понять, что уже работает сегодня, где скрыты риски и с чего начать собственные эксперименты.

Всем привет!
В прошлых статьях речь шла о возможностях смарт-карты, которые не получают должного освещения в публикациях, а именно: работа с ISD, создание своего SSD, сторонние библиотеки и криптография. Эти темы лишь часть огромного массива, который можно исследовать до самой китайской пасхи, а ведь хочется идти дальше, посмотреть, что еще интересного таит "Вселенная Java Card".

По этой причине я решил долго здесь не задерживаться и идти к новым горизонтам. Итак, встречайте - UICC HOTP!

Придумать пароль из восьми символов, обязательно добавить заглавную букву, цифру и специальный знак, а через три месяца повторить процедуру. Еще недавно подобные требования считались нормой корпоративной безопасности. Сегодня от многих из них рекомендуют отказаться.

Пока пользователи придумывали все более сложные комбинации, злоумышленники научились использовать украденные пароли, перехватывать активные сессии и создавать убедительные фишинговые страницы. К привычным инструментам атак добавились нейросети, которые помогают угадывать пароли по известным закономерностям.

В результате требования к безопасности учетных записей заметно изменились. Разберемся, что рекомендуют современные стандарты, насколько опасен ИИ-перебор и почему даже очень длинного пароля иногда недостаточно.

В АБП2Б мы хорошо знакомы с вопросами защиты учетных данных: наша команда разработала ОдинКлюч — российский менеджер паролей для безопасного хранения и управления доступами, которым уже пользуются, в том числе, крупнейшие компании страны и федеральные органы власти. Этот опыт помогает нам оценивать рекомендации по парольной безопасности с учетом реальных задач пользователей и компаний.

Почему сложный пароль больше не гарантирует безопасность

Представим, что пользователь придумал пароль из двадцати случайных символов. Подобрать такую комбинацию методом перебора крайне сложно, если пароль действительно создан случайным образом. Но даже такой надежный пароль не защитит аккаунт, если пользователь попадет на поддельный сайт и сам передаст его злоумышленникам.

Автор: Аскар Гибадуллин, инженер Innostage

В процессе трансформации ИТ-инфраструктуры и перехода на отечественные средства защиты информации предприятия всё чаще сталкиваются с необходимостью заменить зарубежные комплексные решения российскими межсетевыми экранами.

Процесс смены платформы межсетевого экранирования — это всегда высокий риск ошибок и существенные временные затраты. Правила безопасности на МЭ в крупных организациях формируются годами, включают тысячи объектов (сетевые объекты, сервисы, группы, домены, url, приложения и т.д.) и определенную логику формирования самих правил.

Перенос правил фильтрации и базы объектов вручную при смене межсетевого экрана — процесс не только длительный, но и крайне рискованный. Одиночные ошибки в объектах или порядке правил способны вызвать сбои в работе бизнес-сервисов или создать бреши в защите.

В этой статье мы разберем наш практический опыт по автоматизированному переносу политики безопасности с Check Point R81.20 на NGFW Континент версии 4.2.1.653. Для автоматизации мы использовали утилиту convert_cp_json_to_c4, которая преобразовывает JSON-выгрузку объектов и политик Check Point в формат, готовый к импорту в приложении «Менеджер Конфигурации».

В статье приводятся результаты работы с конкретными версиями решений двух производителей. В зависимости от версии возможны нюансы, но, уверены, что общая механика работ и описанные ограничения помогут сэкономить время и избежать некоторых проблем коллегам, которые столкнуться с аналогичными задачами.

Индивидуальный предприниматель в России регистрируется за три дня, а вот сколько он потом живёт, ФНС напрямую не публикует. Сколько человек решили закрыть ИП, видно в отчётах налоговой, а сколько из открывшихся в каком-то году работают до сих пор, приходится собирать самому. Я собрал это из двух открытых источников ФНС и по дороге нашёл несколько мест, где данные выглядят правдой, но ею не являются.

Сегодня хотим поговорить о том, почему большинство красивых ИИ-пилотов умирает, как только их пытаются вывести за пределы «родного» цеха, в чём реальная цена ошибки ИИ на производстве и как мы в ТЕХНОНИКОЛЬ связываем в единый контур разработку и производство. Поехали!

Эта статья состоит из двух разных частей. В первой части — общая информация о шлюзах последовательных портов, как их можно собрать, немного про сферы применения и так далее. Во второй части — техническая информация как под наш 4-портовый шлюз на базе FT4232 собрать Linux, как проверить работоспособность и как используя наш программный шлюз Modbus RTU (Modbus TCP mbus‑gw‑t2r) мы делали долгие тесты и замеры. Если вас интересует техническая информация, смело переходите ко второй части статьи.

Речь о том, как собирать поисковые и коммерческие интенты, когда короткие ключи уступают естественному языку и генеративному поиску. В центре GEO. Видимость бренда в AI-ответах по одной канонической фразе не считается. Слова-модификаторы — рекомендация, цена, доверие, сравнение, география, сценарий использования, ограничения, срочность — способны сдвинуть задачу retrieval, набор источников, структуру shortlist и вероятность включения бренда. Теория коротко: intent taxonomy, контекстное представление текста, query rewriting, query fan-out. Практика сверяет Google, Pew Research Center, академические работы по prompt sensitivity, Peec AI, Conductor и другие источники с обезличенным matched-срезом GeoAist. На 873 успешных проверках, объединённых в 91 сопоставимую связку «тема × AI-поверхность», различия формулировок видны сразу в нескольких измерениях: в 58 из 91 связок менялась частота наличия цитируемых источников, в 55 связках максимальная длина ответа превышала минимальную как минимум в 1,5 раза, а в 34 — минимум вдвое. Во всех 14 связках, где отслеживаемый бренд появлялся хотя бы в одном архетипе, brand inclusion тоже различалась между формулировками. GEO-intent удобнее описывать как многомерную конфигурацию задачи, стадии воронки, контекста и ограничений. AI-видимость тогда измеряют портфелем промптов, не списком «ключевых фраз».

Открытый порт на сервере редко остаётся незамеченным. По интернету постоянно гуляют боты, которые перебирают адреса, проверяют доступные службы, пробуют имена и пароли. Иногда они просто смотрят, что им ответит сервер. Иногда после ответа отправляют готовый набор команд. Человека за клавиатурой при этом может вообще не быть.

Я уже столкнулся с таким гостем на практике. Из-за моей ошибки наружу смотрел порт базы данных, а сервер несколько дней уходил в перегрузку. После этого мне стало интересно. Кто на самом деле пытается подключиться к открытому порту, что успевает сделать за короткую сессию и чего добивается?

Чтобы в этом разобраться, я создал программу-приманку. Она изображает несколько обычных серверных служб, отвечает клиентам и записывает все их действия. А полученные команды она не исполняет.

В логах с активными записями приманка собрала 2406 сессий от 309 адресов. Многие подключения занимали около секунды, но даже за это время клиент успевал войти и быстро проверить систему. Ниже разберу, как устроена ловушка, что именно попало в журнал и какие порты стоит проверить на своём сервере после такого эксперимента.

Жизнь на планете Земля поражает своим разнообразием: муравьи и слоны, лягушки и синие киты, тюльпаны и секвойи, и особенно одна из ветвей человекообразных обезьян, известная как люди. Всё это многообразие объединяет биохимия, в особенности общие биохимические механизмы генетического наследования: ДНК и РНК, универсальные наборы инструкций для всего живого.

Прослеживая эти биохимические связи в глубь времён, многие учёные пришли к убеждению, что вся жизнь происходит от так называемого последнего универсального общего предка (Last Universal Common Ancestor), или LUCA, который появился от 4 до 4,5 миллиарда лет назад, после того как сама Земля сформировалась из газа и обломочного материала молодой Солнечной системы. Возможно, мы никогда не сможем с уверенностью сказать, как этот общий предок возник из первичного бульона. Не существует ископаемых остатков, которые позволили бы заглянуть в тот момент истории, и учёным не с чем сравнивать: пока Земля остаётся единственным известным местом во Вселенной, где существует жизнь.

После ответа на первоначальный вопрос «как?» остальные вопросы становятся для учёных немного проще. Вот что известно о трёх важнейших переломных моментах в эволюции жизни на Земле.

Любой писатель или ученый прошлых веков хотя бы раз задумывался о будущем. Как будут жить люди? Как изменится мир и какую роль обретут в нем технологии? Станут ли машины незаменимыми помощниками человека или его новыми хозяевами? Предположений было много, но совсем мало из них «попадали в яблочко». От большинства описаний предполагаемого будущего, в котором живем мы сейчас, становится забавно или откровенно смешно. Крылатые пожарные и почтальоны, ролики на бензине или атомные пылесосы, увы и ах, не стали частью современного быта. Зато искусственный интеллект стал.

Естественно, про него мыслители и фантасты прошлого тоже говорили немало. Его представляли и как живые часы, и как ошибку в логической системе, и даже как машину, которую нужно будет учить и обучать как младенца или собаку.

В этой статья взглянем на три работы трех разных авторов. Каждый из них по-своему представлял будущее и искусственный интеллект. И каждый из них по-своему оказался прав.

На хакатоне сделали такой проект: делаешь фото коллеги, система распознает его, добавляет в коллекцию и начисляет очки. 

Игра хорошо подходит для корпоративов в больших компаниях — например, у нас много отделов и подразделений, большая доля удалёнщиков. По этим причинам люди часто не очень хорошо знают друг друга в лицо.