В нашем предыдущем посте Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models мы рассказали о фреймворке для исследований уязвимостей при помощи языковых моделей и продемонстрировали его потенциал, усовершенствовав показатели современных бенчмарков CyberSecEval2 компании Meta. С тех пор Naptime эволюционировал в Big Sleep — совместный проект Google Project Zero и Google DeepMind.

Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира. обнаруженной агентом Big Sleep: отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite, — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite.

Мы считаем, что это первый публичный пример обнаружения ИИ-агентом ранее неизвестной уязвимости безопасности по памяти в широко используемом реальном ПО. В этом же году на мероприятии DARPA AIxCC команда Team Atlanta обнаружила разыменование нулевого указателя в SQLite, что вдохновило нас использовать его в нашем тестировании, чтобы проверить, сможем ли мы найти более серьёзную уязвимость.

Мы считаем, что наша работа обладает огромным защитным потенциалом. Нахождение уязвимостей в ПО ещё до его релиза не позволит нападающим пользоваться ими: уязвимости устраняются ещё до того, как их увидят злоумышленники. Очень сильно помог в поиске уязвимостей фаззинг, но нам нужна методика, позволяющая защищающимся находить баги, которые сложно (или невозможно) обнаруживать фаззингом, и мы надеемся, что ИИ позволит закрыть этот пробел. Мы считаем, что это многообещающий путь к полному изменению ситуации в кибербезопасности и обеспечению асимметричного преимущества для защищающихся.

Сама уязвимость довольно любопытна, к тому же существующая инфраструктура тестирования SQLite (и через OSS-Fuzz, и через собственную инфраструктуру проекта) не обнаружила проблему, так что мы провели дополнительное исследование.

Это ответ, точнее мысли по статье, опубликованной на Хабре: «Зарплаты в IT: сравнение Германии и России — где программисты и айтишники получают больше». Советую сначала ее прочитать и потом уже здесь продолжить.

Привет, Хабр! Меня зовут Алла, я работаю младшим исследователем в команде Memory‑Augmented models в AIRI и занимаюсь ресерчем на пересечений графов знаний и языковых моделей. Потребность в таких изысканиях понятна любому, кто пытался добиться от ChatGPT точного ответа на конкретный вопрос: подобрать литературу для курсовой, вспомнить название фильма по описанию и тому подобное. Очень часто модель начинает галлюцинировать и выдумывать факты, которых не существует.

Один из способов решения этой проблемы — связать LLM с графом знаний, но сами графы тоже должен кто‑то наполнять. Мы с коллегами доказали, что эту задачу можно автоматизировать с помощью LLM и предложили своё решение, названное Prompt Me One More Time (фанаты Бритни тут?), о котором мне бы и хотелось сегодня здесь рассказать. За подробностями же можно обратиться к статье, представлена нами на воркшопе TextGraphs-17 конференции ACL-2024, недавно прошедшей в Тайланде.

Эта статья для тебя, если ты когда-нибудь задумывался о том, сколько получают IT-специалисты в Германии и как это всё сравнить с зарплатами в России. Я расскажу про реальные цифры и поделюсь своим личным опытом переезда.

Я живу третий год в Европе. В апреле 2024 года я начал работать на позиции scrum master в компании ALDI SUD int в городе Мюльхайм на реке Рур.
Мой профессиональный опыт в роли scrum master на апрель 2024 составлял 5 лет.

Сравнивать будем на основе позиции на которой я работал и работаю - скрам мастер.
Цифры и порядок на этой позиции и на других в ИТ в целом соизмеримы.

Гель холодил кожу головы, и мне пришлось забыть о том, как глупо я выглядела, потому что мы находились в центре серьёзных научных исследований. Это было в 2021 году, ещё в мире антибактериальных средств и масок для лица — я уже давно смирилась с тем, что во имя науки можно выглядеть глупо на публике. Танцевальный центр Siobhan Davies Studios на юге Лондона был превращён в научную лабораторию, и на меня надели то, что выглядело как сложная плавательная шапочка. По всей шапочке были разбросаны электроды для измерения активности моего мозга, а гель, выдавливаемый в отверстия, способствовал соединению электрода со скальпом.

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

В данной статье пойдёт речь об особенностях UEFI на примере переноса Debian Stretch с MBR на UEFI. Опишу так же разницу между MBR и UEFI, так как я её воспринимаю.

Кроме общей части, ключевая часть статьи про формирование GRUB EFI файла grubx64.efi во время grub-install и про то, что этот файл не так прост, как кажется на первый взгляд.

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

Привет! Меня зовут Сергей Востриков, я руковожу направлением Маркет и интеграций в Битрикс. Иными словами, я помогаю развивать функционал Битрикс24, доступный для разработчиков тиражных решений и индивидуальных кастомизаций. Это значит REST API и всё «вокруг» него — документацию, витрину Битрикс24 Маркет, кабинет разработчика решений и т.д.

REST API Битрикс24 включает в себя просто страшно сказать сколько методов, событий, встроек виджетов и прочих нюансов. Без документации с этим, конечно, совершенно невозможно иметь дело. И хотя нельзя сказать, что документации у нас не было, надо признать, что с течением времени у разработчиков накопилось к ней немало претензий.

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

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

Добавлю, что  в требования к третьей версии Rest API, которая (спойлер!) сейчас находится в разработке,  мы заложили автоматическую генерацию документации из исходного кода продукта, вместо того чтобы продолжать вручную писать таблички с описанием методов.  

Однако ждать выхода нового Rest API мы не стали — нам предстояла долгая работа, мы решили подготовиться заранее. Кроме того, текущую версию REST API мы будем поддерживать еще долго, так что хорошая документация для неё всё равно нужна.

Друзья, приветствую! Сегодня мы коснемся важной и не такой уж сложной темы — реализации конечных автоматов состояний (FSM) в телеграм-ботах на Aiogram 3.x.

Для лучшего понимания рекомендую ознакомиться с моими предыдущими публикациями на тему Aiogram 3.x:

Ни одна система не может функционировать без сбоев, всегда могут возникнуть ситуации, когда в работе софта возникают проблемы. И здесь важное значение имеет observability — понятие, включающее в себя мониторинг и наблюдаемость. С помощью мониторинга мы можем определить, когда возникла проблема, а наблюдаемость позволяет нам понять, почему она возникла.

В этой статье мы поговорим о том, как можно реализовать observability с помощью сервисов стека Grafana.

Размещение вакансий на популярных «работных» сайтах — это только часть большой системной работы HR‑департамента организации. Значимую роль в привлечении новых сотрудников и удержании существующих играет контент и сервисы интернет‑ресурса предприятия. Рассказываем про то, как был модернизирован HR‑раздел на сайте «Россети Урал» и что из этого получилось.

Большинство из нас так или иначе сталкивается с кредитами, а потом и с досрочными платежами по ним. Эта статья в блоге ЛАНИТ на Хабре посвящена подробному сравнению двух способов внесения частичных досрочных платежей по кредиту: с уменьшением срока и с уменьшением платежа.

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

Сталкивались ли вы с трудностями при отладке Python-кода? Если это так — то изучение того, как наладить логирование (журналирование, logging) в Python, способно помочь вам упростить задачи, решаемые при отладке.

Если вы — новичок, то вы, наверняка, привыкли пользоваться командой print(), выводя с её помощью определённые значения в ходе работы программы, проверяя, работает ли код так, как от него ожидается. Использование print() вполне может оправдать себя при отладке маленьких Python-программ. Но, когда вы перейдёте к более крупным и сложным проектам, вам понадобится постоянный журнал, содержащий больше информации о поведении вашего кода, помогающий вам планомерно отлаживать и отслеживать ошибки.

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

Вы, кроме того, узнаете о том, как Sentry Python SDK способен помочь вам в мониторинге приложений и в упрощении рабочих процессов, связанных с отладкой кода. Платформа Sentry обладает нативной интеграцией со встроенным Python-модулем logging, и, кроме того, предоставляет подробную информацию об ошибках приложения и о проблемах с производительностью, которые в нём возникают.

Основной целью данного бенчмарка является всесторонняя оценка возможностей русскоязычных LLM в контексте российской действительности по темам истории, географии, обществознания и политологии. В разработке бенчмарка ИОН РАНХиГС и ИСП РАН были заложены следующие принципы: 

Формирование базы вопросов из официальных источников, близких к позиции РФ. К данным источникам относятся базы вопросов по ЕГЭ по соответствующим дисциплинам, открытых экзаменационных вопросов ведущих российских вузов, а также вопросов, сформулированных специалистами РАНХиГС и ИСП РАН.

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

Пересмотр оценок провокационности с учетом изменений в общественном контексте.

Одна из ключевых облачных фич — масштабирование (о возможностях облака с примерами из реального бизнеса подробнее рассказали тут). Настраивать масштабирование, а также балансировщики нагрузки и виртуальные машины можно различными способами. Один из нетипичных вариантов — использование языка Tcl.

Tcl (Tool Command Language) разработал программист Джон Оустерхаут в середине 1980-х. Tcl достаточно универсален — он помогает управлять сетевыми устройствами и работать с облачными интерфейсами.

В начале девяностых вокруг решения сформировалось серьезное академическое комьюнити. Затем сообщество стало шире — участники разрабатывали новые расширения и средства для работы с БД.

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

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

В бытность мою лидом в Gaijin, получилось поработать со многими отличными людьми и профессионалами своего дела, в том числе Женей К. и Давыдом Ф., и даже после перехода в другую студию мы продолжаем поддерживать связь, кидая друг другу интересные новости и поздравляя с днем рождения. Собственно несколько месяцев назад так мне и прилетел очередной хохмотред про джунов (не ходите туда, дабы не создавать хабрэффект) интересные цитаты я выложу ниже. Но на тот момент было совсем туго со временем, очередной майлстоун, поиск работы, собеседования новых ребят, перетряски в компании, вообщем не до тредов и статей было особо, доползти бы до кровати не уснув по дороге. Тогда глянул мельком, отметил странную подачу материала и забыл.

А тут добрался почитать более вдумчиво, и совместить это с реалиями набора не то что джунов, а мидлов и синьоров на нужные в студии позиции. Девушка-разработчица Наталья провела небольшой эксперимент, сделала фейковую вакансию и собирала отклики, отсмотрела туеву хучу резюме и собрала статистику на основе которой начала давать рекомендации как поправить эти самые резюме, чтобы пройти на эту фейковую вакансию.