Всем привет!
Совсем недавно в ядре линукс была обнаружена критичная уязвимость, позволяющая повышать привилегии до уровня root. Она получила идентификатор CVE-2023-0386 и затронула версии ядра до 6.2. В интернете уже есть несколько доступных PoC:
https://github.com/CKevens/CVE-2023-0386
https://github.com/xkaneiki/CVE-2023-0386
В этой статье я хотел рассмотреть принцип работы данной уязвимости и возможные варианты ее обнаружения.

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network

^{Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.}

Автор: Томас Грохсер (Thomas H. Grohser)

При содействии: Линдсей Аллен (Lindsey Allen)

Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel

Перевод: Александр Гладченко,  Ирина Наумова

Дата издания: июнь 2009г.

Тематика статьи: SQL Server 2008

 Резюме: Размер базы данных непрерывно растёт, темп этого роста, а также её доступность и готовность фиксируется в соглашение о качестве сервиса - SLA. Одновременно с ростом повышается важность быстрого и надежного резервного копирования и планового восстановления в текущем окружении. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). На реальном примере, в этой статье демонстрируется, как лучше всего использовать резервное копирование и возможности по восстановлению, которыми обладает SQL Server 2008, что должно помочь при создании планов резервного копирования и восстановления VLDB по сети.

Удаление Witelist ноутбука HP Pavilion dv6-2135er. Реверс-инжиниринг и модификация дампа bios.

Мы с Аней не тестировщики. Мы относимся к эволюционирующему классу IT-специалистов — системным администраторам или operations-инженерам. Но в нашей повседневной жизни мы тоже не обходимся без тестов. И сегодня мы хотим немного поговорить про Splunk. Точнее, вся наша статья будет именно про него.

Привет! Чем еще заняться на каникулах любителю Data Scienсe как не анализом тональности комментариев под новогодними обращениями?! На эту мысль меня натолкнули алгоритмы YouTube, выдавшие к просмотру первого января 2022 года два видео, с очень разными по эмоциональной окраске комментариями.

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

Эта статья является пересказом моего доклада на Java-конференции SnowOne 2021 года. LJV — проект, созданный в 2004 году как инструмент для преподавания языка Java студентам. Он позволяет визуализировать внутреннее устройство структур данных. В этом докладе я запускаю LJV на разных структурах (от String до ConcurrentSkipListMap) в разных версиях Java и разбираю, что там внутри, как оно менялось от версии к версии, и как это всё работает.

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

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

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

Была у меня мечта - писать backend на C++. А вот разбираться в unix socket'ах, TCP, многопоточной/асинхронной обработке запросов и во многом другом совсем не хотелось. Не верил я, что до сих пор нет каких-то минималистичных фреймворков. И сегодня я вам расскажу, как можно просто сделать HTTP API микросервис на C++ с помощью фреймворка Drogon.

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

Эта статья является переводом материала «Untangling Microservices, or Balancing Complexity in Distributed Systems».

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

В этом посте я хочу ответить на эти вопросы. Вы узнаете об общих проблемах проектирования, которые превращают микросервисы в распределенные большие комки грязи (distributed big balls of mud), и, конечно же, о том, как их избежать.

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

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

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

В этой статье мы "научим" автомобиль выполнять самостоятельную парковку с помощью генетического алгоритма.

В 1-м поколении автомобили будут иметь случайный геном и будут вести себя хаотично.

К ≈40-му поколению автомобили понемногу начнут учиться парковке и будут все ближе и ближе подбираться к парковочному месту

Чтобы увидеть эволюционный процесс прямо в браузере вы можете запустить ? симулятор эволюции, .

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

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

Вот чего хотелось:

— Возможность загрузить готовую базу, а не писать SQL для создания таблиц.
— Подключать как локальные базы, так и удаленные (по url).
— Сохранять базу и запросы в облаке.
— Бесплатно и без регистрации.
— Свежайшая версия SQLite.
— Минимализм.

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

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

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

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

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

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

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

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