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

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

Чаще всего эти позиции существуют параллельно. Разговор быстро сводится к оценкам — «можно» или «нельзя» — и редко касается того, как студенты реально используют ИИ.

Недавнее исследование НИУ ВШЭ добавляет в эту картину важный факт: ИИ уже стал массовым инструментом. Среди более чем 500 опрошенных студентов около 90% используют ИИ в учёбе. В большинстве случаев к нейронке обращаются не из-за желания обмануть систему, а по другим причинам: она экономит время, снижает нагрузку и воспринимается как низкорисковый способ справиться с однотипными заданиями.

Если принять это как отправную точку, вопрос «запрещать или разрешать» становится вторичным. Гораздо важнее другое: какую часть учебной работы ИИ может взять на себя, а где участие студента остаётся принципиально важным.

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

Django Rest Framework (DRF) - чуть ли не единственный фреймворк для разработки REST на базисе Django. Мой нарратив о Django в прошлой статье заключался в том, что это неповоротливый монолит, который абсолютно не следует best practices и не стремится к ним. Если вдруг вы не задумывались о том, как связаны DRF и Django, то вас может быть немного это удивит - никак. Их делали совершенно разные люди, но каким-то образом они сошлись в общей концепции: игнор хороших практик, перегруженные классы и магия, превращающая разработчика в гадалку.

Салют, Хабр!

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

Сразу оговорочка.

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

С организационными моментами разобрались – переходим к тому, как купить крипту :)

Всем привет, любители экспресс доставки до клиента! Я тут на неделе узнал прикольный кейс при работе с Яндекс Доставкой, который стрелял так, что дорогие оффера Яндекса все таки пробивали первую линию обороны и выбирались как целевые при экспресс доставке до клиентов Sunlight. Я думал, что мы готовы к праздникам а оказалось, что не совсем

После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.19. Среди наиболее заметных изменений: подсистема Live Update Orchestrator, поддержка PCIe Link Encryption, системный вызов listns, режим Zero-Copy Receive в io_uring, поддержка ARM-расширения MPAM, klp-build для генерации live-патчей, поддержка архитектуры LoongArch32, QoS для s2idle, оптимизация подсистемы аудита, Intel LASS для защиты от Spectre, поддержка хэшей SHA-3 и BLAKE2b, механизм Confidential VMBus, TX-оптимизации в сетевой подсистеме, протокол CAN XL, API для аппаратного ускорения HDR-вывода.

В анонсе новой версии Линус сообщил, что следующему выпуску ядра будет присвоен номер 7.0, так как в ветке 6.x накопилось достаточного выпусков для смены первого числа в номере версии (в своё время выпуск 6.0 был сформирован следом за 5.19). Смена нумерации осуществляется из эстетических соображений и является формальным шагом, снимающим дискомфорт из-за накопления большого числа выпусков в серии. Линус пошутил, что его сбивают с толку большие числа для которых не хватает пальцев на руках и ногах. При этом формально повод для значительного изменения номера версии есть, так как начиная со следующего выпуска поддержку Rust решено перевести из экспериментальных в основные возможности ядра.

В новую версию принято 15657 исправлений от 2237 разработчиков, размер патча – 52 МБ (изменения затронули 13682 файла, добавлено 794649 строк кода, удалено 335498 строк). В прошлом выпуске было 15035 исправлений от 2217 разработчиков, размер патча – 45 МБ. Около 40% всех представленных в 6.19 изменений связаны с драйверами устройств, примерно 13% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 5% – с файловыми системами и 3% c внутренними подсистемами ядра.

( читать дальше... )

 c, linux, rust, ядро linux

Я обожаю смотреть иностранные фильмы в оригинале.

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

Во-вторых, мне просто нравится звучание некоторых языков - например, французского, китайского, датского.

Также я работаю над сайтом по изучению языков Language Dove, а учить языки по фильмам - это очень эффективно.

Так родился проект по генерации идеальных субтитров.

А вы тоже слышали байку о том, что облако по сравнению с онпрем-инфраструктурой получается едва ли не дешевле электричества из розетки, а PAYG – справедливее коммунизма? Нет, в целом принцип и правда выглядит очень честно: сколько заказал – столько и заплати. Как в ресторане. На практике такого, конечно, чаще всего бывает. Но чего всегда бывает в избытке – так это претензий финотдела, который кого угодно сведет с ума, допытываясь, почему растут счета. А кто бы их знал? Продакшн стабилен, метрики зеленые, архитектура давно устоялась – причин для роста как будто и нет. Но компании то и дело выходят за рамки бюджетов.

Сначала это случилось с Oracle, теперь пугающе похожее происходит с NVIDIA.

5 февраля стоимость компании упала на $500–600 миллиардов по сравнению с пиком (29 октября 2025). Это уже третье значительное падение за последние шесть месяцев.

Вы думаете, это нормально, потому что акции постоянно растут и падают?

Если да, вы многое упускаете. Это аномалия, и она зловеща. Я объясню почему позже.

Бьюсь об заклад вы привыкли к инструментам разработчика в Chrome. Ежедневная проверка вёрстки, просмотр логов или анализ загрузку страницы делается на автопилоте. Но что если есть альтернатива, которая в некоторых моментах работает иначе и часто даже лучше?

Инструменты разработчика в Firefox создавались отдельно и имеют свою историю. Их команда не ставила задачу сделать копию Chrome. Вместо этого они сфокусировались на своих идеях о том, как сделать отладку более наглядной. В результате некоторые вещи там реализованы более прямолинейно и понятно. Конечно, не всё идеально, и у Chrome есть свои преимущества. Об этом сегодня и поговорим.

В этой статье мы посмотрим на Firefox DevTools в деталях. Отойдем от банальных соревнований в стиле «у кого DevTools длиннее». Вместо этого разберем, в каких ситуациях панель Firefox может сэкономить вам время, а в каких всё же удобнее остаться в Chrome. Откроем для себя несколько приёмов, которые можно добавить в свою ежедневную работу, независимо от браузера.

В середине двухтысячных мобильная индустрия переживала интересный период — телефоны уже «умели» больше, чем просто звонить и отправлять СМС, но смартфоны еще не появились. Тогда-то в продажу и поступили коммуникаторы — устройства, совмещающие телефон и карманный компьютер в одном корпусе, с полноценной ОС, а не просто оболочкой. Windows Mobile тогда казалась перспективной платформой, способной перенести привычный десктопный опыт в карман. 

Коммуникатор Qtek S200, вышедший в начале 2006 года, был уже и ОС, и со множеством функций, а также неплохим железом. Аппарат выпускала тайваньская HTC под европейским брендом Qtek. Я купил его в 2000-х примерно через год после выхода девайса на рынок и не прогадал — он был прекрасен. Это был не просто телефон с большим экраном, а устройство, которое позволяло работать с документами, проверять почту и выходить в интернет прямо на ходу. А главное — там была гора приложений. Давайте вспомним, что это за девайс, а еще — разберем его. 

Привет Хабр!

Года три назад я сидел на встрече с топ‑менеджментом и показывал очередной «красивый» отчёт по ИТ.Графики растут вверх и вправо, SLA зелёный, количество закрытых тикетов бьёт рекорды, релизов в месяц стало вдвое больше, чем год назад. Всё выглядело так, будто ИТ‑контур вот‑вот начнут носить на руках.

В период массового импортозамещения средств защиты от DDoS один из провайдеров перевёл свои центры очистки трафика на отечественное решение. Помимо стандартной защиты на уровне L4, провайдер позиционировал его нам как эффективную защиту от L7-атак за счёт механизма фильтрации по TLS-отпечаткам (тогда это был ещё JA3). Однако на практике мы показали, что рандомизация параметров отпечатка (cipher suites, extensions, порядок) позволяет обойти этот механизм и существенно снижает его эффективность против L7-атак. Стоит ли использовать механизмы защиты по отпечаткам JA3/JA4, зная о возможности обхода? Да, стоит. Процесс обхода требует от атакующего значительных ресурсов — кастомного TLS-клиента для генерации уникальных отпечатков. При дополнительной настройке, например, добавлении счётчика с разными лимитами для новых и известных отпечатков (более высокие лимиты для «белых» отпечатков), можно добиться высокой эффективности против ботовых L7-атак (флуд от ботов с повторяющимися отпечатками).

 В этой статье мы реализуем защиту на основе фильтрации TLS-отпечатков, вдохновлённую подходом JA4, но в упрощённой версии FST1 (по отсортированным cipher suites с использованием Jenkins-хэша). Почему не полноценный JA4? Из-за жёстких ограничений eBPF (ограниченный стек, запрет на сложные циклы, отсутствие динамической памяти и строгие правила верификатора ядра) реализация полного JA4 (с учётом всех расширений, ALPN и других параметров) становится крайне сложной.

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

Привет! Меня зовут Полина Морозова, я PR-эксперт СКАН-Интерфакс, занимаюсь внешними коммуникациями. Представьте ситуацию: ваша компания столкнулась с кибератакой, и теперь важно не только устранить технические последствия, но и грамотно выстроить коммуникацию, чтобы снизить репутационные риски, которые часто оказываются сопоставимыми с финансовыми потерями. В этой колонке разберём, почему технический язык больше не работает в кризисных ситуациях и какие коммуникационные подходы сегодня помогают сохранять доверие.

В этой статье разберём:

сбор каналов, аналитику (подойдёт для закупщиков, в том числе)

два подхода к комментингу: трудозатратный с бóльшим охватом, и быстрый с горячими лицами здесь и сейчас

виды цепляющих комментов

структуры & формулы продающих комментов, скрытые фишки по удержанию аудитории

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

Telegram блокируют всё активнее. VPN детектят и режут. Обычные прокси живут неделю. Что делать? Ответ MTProto Proxy с Fake TLS: специализированный прокси, который маскируется под обычный HTTPS-трафик к легитимным сайтам вроде 1c или sberbank. Для DPI это выглядит как обычный визит на сайт, а на деле стабильный Telegram.

Сегодня разберём полную инструкцию: от выбора правильного VPS до эффективной маскировки и мониторинга.

Всем привет! Вы наверняка слышали или даже участвовали в ежегодных performance/compensation review. Это когда собираются менеджеры, HR‑ы, сводят головы вместе и решают, кому повысить зарплату и на сколько, исходя из результатов работы. И вот тут случается забавное, каждый сотрудник внезапно оказывается стоит дороже рынка, работает лучше всех, и вообще молодец.

Как же провести калибровку в ситуации, когда все уверены, что заслуживают больше среднего?

Наверное, каждый из нас ловил себя на мысли: что отправить на день рождения в этот раз? Просто текст, тёплую фотографию или голосовое сообщение? И сразу вспоминается это чувство, когда ищешь или обдумываешь креативный текст, а потом вспоминаешь о милой картинке с котиком, гифке с шампанским или стандартном «С ДР!» — и отправляешь, чисто для галочки.

Со временем я заметил: когда получаешь такое поздравление в Telegram, становится немного грустно, что человек хоть и поздравил, но не потратил время на то, чтобы обдумать и искренне пожелать чего-то хорошего и уникального только про тебя. Хотя понимаешь — это нормально. Поколение постарше привыкло обмениваться этими милыми, но безликими посланиями. Хотя не все делают это из-за нежелания — некоторым просто понравилась картинка, вот и скинули.

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

Агенты отлично справляются с узкими, конкретными задачами — например, написать функцию или короткий текст — но начинают буксовать на сложных многошаговых процессах. Чем более абстрактна и «высокоуровнева» работа, тем больше ошибок они допускают: путают шаги, пропускают операции, неверно интерпретируют инструкции. Такие ошибки накапливаются и усиливают друг друга, приводя к неожиданным результатам. Чем больше задача, которую вы отдаёте агенту, тем выше шанс, что он её провалит.

Помедитировав немного над этим, я пришёл к интересным эвристикам.

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

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

Например, существует масса формализованных циклов проектирования (PDCA, OODA, DMAIC, 8D и etc.) — по сути, тривиальных мета-алгоритмов; однако каждый шаг этих алгоритмов — это куда более сложная и нетривиальная задача.

Значит, стоит стремиться давать агентам низкоуровневые задачи с небольшим, ясным контекстом, а высокоуровневые процессы описывать алгоритмически.