Программирование *

CVE-2024-30085 — это уязвимость в подсистеме Windows Cloud Files Mini Filter. Код подсистемы располагается в cldflt.sys — это драйвер минифильтра, и он относится к предустановленному клиенту облачного сервиса Microsoft OneDrive.

Уязвимость фигурировала на прошедшем в Ванкувере Pwn2Own 2024, где команда ресёрчеров Team Theori использовала эксплойт для этой уязвимости в цепочке эксплойтов, осуществляющих Guest-to-Host-Escape (побег из виртуальной машины) из-под управления VMware workstation, за что и получила свои заслуженные 13 очков Master of Pwn.

В этой статье мы рассмотрим корни уязвимости CVE-2024-30085 и техники эксплуатации, применимые во время эксплуатации кучи в ядре Windows 10 22H2 19045.3803.

Мы долгие годы писали сервисы исходя из каких-то своих внутренних ощущений правильности их написания. Но синхронизироваться по хорошим практикам в разных командах бывает довольно сложно и часто хорошие практики не выходили за рамки одной команды, а такого хотелось бы избежать. Поэтому мы решили объединить все хорошие по нашему мнению практики в единый справочник. Этот справочник получил название «Архитектурный гайд». Про него и поговорим в данной статье.

Совсем недавно моя машина была в таком запущенном состоянии, что я едва мог подключиться к ней через ssh. 3200% нагрузки на CPU — полностью использовались все 32 ядра хоста! Сравните это с моим последним багом, когда использовалось всего одно ядро, то есть 100%

К счастью, я использовал среду выполнения Java 17, у которой были дампы потоков с указанием времени CPU!

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

Кто-то в личное время покоряет Эверест, кто-то стрит-драйвит, кто-то на нижней Волге ловит спиннингом судаков и жерехов (я тоже, кстати, раз в году), кто-то разводит мадагаскарских шипящих тараканов, а кто-то развлекает себя эзотерикой. А я вот внерабочее время развлекаю себя тем, что напрягаю свой мозг математическими и алгоритмическими проблемами. Придумываю что-нибудь эдакое, необычное. Жаль, что за эту деятельность не платят. Говорят, такое напряжение мозга поможет в старости спастись от болезни Альцгеймера. Во всяком случае, весьма на это надеюсь.

И, рассуждая совсем о другой проблеме, но где имеет место быть сортировка большого количества объектов, в плане алгоритма сортировки объектов, меня осенило. Быстренько проверил кодом — ого, работает! Рассчитываю, что вам понравится.

Вы когда‑нибудь логинились на сайте, используя аккаунт Google или Facebook? Или подключали приложение, требующее доступа к GitHub? Если да, то вы уже сталкивались с OAuth2, зная того или нет.

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

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

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

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

Почти год назад мы рассмотрели подборку AI-ассистентов для кода, сегодня же мне хотелось бы сосредоточить внимание на одном конкретном, а именно — Cline, номер 1 на OpenRouter. Предлагаю вместе пробежаться по настройке и интеграции, а также использовании Cline в качестве ИИ-ассистента.

*А также мы поговорим про Roo Code — форке Cline, но совсем немного, поскольку они абсолютно идентичны в настройке и функционале.

Приятного прочтения!

Не тратьте время на задачи – сначала разберитесь в основах. В статье:

1. Как проходят собеседования (ВАЖНО!)
2. Big O, оценка сложности алгоритмов
3. Популярные техники: два указателя, DFS, динамическое программирование и другие
4. Какие задачи решать, чтобы пройти в Яндекс

Читаем, практикуемся, получаем оффер!

Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.

Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.  

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

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

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

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

Почему я вообще решил написать эту статью. Какого права имею...и вообще столько уже сказано на эту тему. Я бы хотел изложить исключительно свой (чей же ещё) опыт на данную тему т.к. у автора уже в районе 100 собеседований за спиной или в районе этого. Я трудоустраивался со сроком с момента подачи резюме от нескольких месяцев до нескольких дней без откликов отвечая просто на входящие запросы.

И начнем. Почему тебе стоит начать проходить собеседования ПРЯМО сейчас?

1) Собеседования - это не просто навык. Это Random. Считайте что это roguelike где вы встречаете разных боссов. Боссы как правило встречаются на технических интервью. Сначала вам конечно нужно пройти "привратников" - HR. Их задача просто проверить что вы не долбоящер человек лёгкого поведения который просто хочет потратить чьё то время впустую или просто анализирует рынок. В самом страшном случае они могут ретранслировать вам пару простых вопрос от команд которые если вы не полный банан в этой теме — то пройдете.

В этой статье попробуем разобраться, почему ООП — худшее, что было придумано в программировании, как оно стало таким популярным, почему опытные программисты Java (C#, C++ и т.п.) в принципе не могут считаться крутыми инженерами, а код на Java - хорошим.

Во французском сабреддите я наткнулся на пост с интересной гипотезой:

Чем ближе точка к вокзалу, тем хуже там кебаб.

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

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

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

Когда только начинаешь карьеру разработчика, часто гложет сомнение: верно ли я выбрал язык программирования? Может, он уже устарел, или наоборот — слишком новый и не факт, что перспективный? Легко ли будет найти по нему актуальные книги и уроки? Много ли таких неофитов будет вместе со мной обивать пороги ИТ-компаний через год-два? 

Опытным разработчикам тоже порой не хватает знания единственного языка программирования. В какой-то момент появляются специфические заказы и интересные вакансии, где крайне желательно владеть вторым (а то и третьим) языком. 

Помочь с выбором языка программирования призваны рейтинги их популярности. Однако тут легко обмануться. Каждый рейтинг составляется по своей методике и даёт разные результаты (порой — весьма неожиданные). В этой статье я постарался сделать более взвешенную оценку популярности языков программирования (далее — ЯП) по нескольким источникам. Подробнее о них и почему это важно — рассказываю ниже.

Индексы популярности

Всё началось с того, что мне попался на глаза свежий рейтинг актуальности ЯП, где в TOP 10 внезапно ворвался Delphi. Пытаясь разобраться в причинах его внезапной популярности в 2025 году, я стал искать методики составления таких списков и нашёл много любопытного. Как обычно, дьявол кроется в деталях. 

Индекс TIOBE — известный инструмент мониторинга, показывающий динамику интереса к разным ЯП. Он учитывает частоту поисковых запросов, связанных с ЯП. Для этого каждый месяц в Google, Bing, Yahoo! и Baidu отправляются запросы по определённому шаблону, чтобы отсеивать из выдачи мусор и корректно сравнивать статистические данные. Дополнительно в рейтинге учитывается число образовательных материалов о ЯП: количество видеоуроков на YouTube, книг на Amazon и упоминаний на Wikipedia. 

У меня на ладони лежит очень горячий сотовый телефон, который разогрелся из‑за того, что мессенджер отображает статичное сообщение с пузырем и текстом на экране при помощи браузерного движка и безумного количества сторонних библиотек. При этом я отлично помню время, когда десктоп был в 10 раз менее производительным, чем этот сотовый, а не‑кроссплатформенные мессенджеры тех времен, написанные на С++, отображали текст не нагружая эти допотопные процессоры и на 10%. Я считаю, что в такой деградации виноват в первую очередь комитет по стандартизации C++. Их близорукие решения и неспособность адаптироваться к реальным потребностям разработчиков привели к парадоксальной ситуации: несмотря на постоянное увеличение мощности компьютеров, программы работают медленнее и потребляют больше ресурсов, чем их аналоги десятилетней давности, а С++‑разработчики не могут создать даже простой мессенджер, который будет работать на 2–3 распространенных операционных системах, не используя массы сторонних библиотек.

C++ задумывался как язык, который должен был дать программистам возможность писать эффективный код с высоким уровнем абстракции. Однако комитет по стандартизации своими действиями превратил его в переусложненный инструмент, непригодный для решения базовых задач современного программирования. Давайте рассмотрим, как именно комитет саботирует развитие языка.

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

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

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

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

Это моя небольшая история, как я за месяц написал карманное медиа с полной автоматизацией, где роботы-ведущие заменили кожаных мешков и ведут подкасты, в которых шутят про AI