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

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

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

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

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

TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

Введение

«Ой, ерунда, ячейки памяти на современных SSD выйдут из строя через десятки лет обычного использования, не стоит об этом беспокоиться, и уж тем более переносить swap, виртуальные машины и папку профиля браузера на HDD» — типичный ответ на вопрос о надежности твердотельных накопителей c гарантированными ≈150 TBW. Если прикинуть, сколько типичное ПО может писать данных, то кажется, что 10-20 ГБ в сутки — уже большая цифра, пусть будет максимум 40 ГБ, куда уж больше. При таких цифрах ответ вполне разумен — нужно 10 лет, чтобы достичь гарантированных значений по количеству перезаписи ячеек, при 40 ГБ записанных данных ежедневно.
Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками несколько раз в день, что оборачивалось 30-секундными задержками в обслуживании записи.

После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
19.7 ТБ.
Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!

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

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

В распространенных инструкциях к прокси-серверу Squid предлагают даже сгенерировать собственный сертификат и установить его клиентам, что полный бред как минимум нерационально и выглядит как MITM — атака. Я знаю, что Squid уже что-то подобное умеет делать, но речь в этой статье о проверенном и рабочем способе с использованием 3proxy от уважаемого 3APA3A.

Далее мы подробно рассмотрим процесс сборки 3proxy из исходников, его настройку, полное и выборочное проксирование с использованием NAT, распределение канала на несколько внешних прокси-серверов, а также использование роутера и статических маршрутов. В качестве ОС используем Debian 9 x64. Начинаем!

Здравствуйте, меня зовут Алексей, я главный IT-архитектор банка «Ренессанс Кредит». Лет десять назад мы, как и многие компании, ускорили свое развитие благодаря сервис-ориентированной архитектуре (SOA). Но со временем требования к архитектуре менялись, и к данной парадигме стали возникать серьезные вопросы. В конце концов мы решили перейти от интеграционной шины ESB к микросервисам. На нашем примере я расскажу, почему стоит задуматься об эффективности SOA и что можно предпринять, если эта модель вас тоже не устраивает.