Многие могли слышать о таких файлах, как rarjpeg'и. Это особый вид файлов, представляющий собой склеенную вплотную jpeg-картинку и rar-архив. Он является прекрасным контейнером для скрытия факта передачи информации. Создать rarjpeg можно с помощью следующих команд:

UNIX: cat image1.jpg archive.rar > image2.jpg
WINDOWS: copy /b image1.jpg+archive.rar image2.jpg

Или же при наличии hex-редактора.

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

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

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

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

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

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

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

Infinifactory

Даниэль Лурье, главный редактор DataArt.

Двадцать лет DataArt занимался разработкой IT-решений для клиентов из сферы финансов, здравоохранения, туризма и других серьезных индустрий. Своих собственных продуктов мы никогда не выпускали — опасались возможного конфликта интересов. Но недавно мы запустили собственную игровую платформу Skillotron. Все началось с того, что в DataArt появились две, на первый взгляд, не связанные между собой проблемы.

Первая — оценка профессионального уровня коллег. За последние десять лет мы выросли с 400 человек до 2500, и люди продолжают к нам приходить, DataArt уже работает в 10 странах и 20 городах по всему миру. Как у любой организации, у нас, конечно, есть система оценки квалификации при приеме на работу. Сложнее оценить тех, кто работает с нами не первый год и все время развивается. Отчасти для этого технологические сообщества внутри DataArt устраивают «селф-чеки» — добровольные экзамены или олимпиады, на которых каждый может себя адекватно оценить и понять, что еще ему надо подтянуть, в какую сторону развиваться. Процесс этот довольно трудоемкий — на придумывание задач, организацию «селф-чека» и проверку результатов уходило немало времени и сил самых опытных коллег. Разработчики задались вопросом, как упростить жизнь себе и остальным.

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

В сентябре 2009 года была опубликована статья об уязвимости, связанной с системой контроля версий subversion, позволяющей скачать исходники сайтов, использующих SVN. Периодически от нечего делать мой мозг хотел, что бы я написал граббер и проверил актуальность данной угрозы на текущий момент, но было как-то лень. Однако, мне не давал покоя комментарий хабраюзера Semenov



Понятно, что каждый школьник уже попробовал скачать %sitename% через .svn, потому от этой идеи я отказался сразу, зато попробовать git clone %sitename%/.git/ руки чесались.

Я наткнулся на этот прекрасный текст (под катом) в книге Вернора Винджа "Глубина в небе". Фрагмент меня впечатлил на столько, что я решил поделиться своими мыслями с общественностью. Не часто встретишь подобную проработку вопроса в художественной литературе. Местами, текст кажется слегка… простетским, но возможно это результат не самого хорошего перевода. На самом деле, текст достаточно глубокомысленный.

Еще по ходу чтения мне вспомнился Эдсгер Дейкстра с его знаменитой фразой: «Я денно и нощно молю, чтобы как можно больше моих собратьев-программистов нашли способ освободиться от проклятья совместимости» («I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility») из книги Смиренный программист (1972 sic!!!). А позже и Эрик Реймонд с своим Собором и Базаром (1997 год). Но текст Винджа не только о проклятье совместимости, на трех страничках поднят (и в общем то оставлен без ответов) целый пласт вопросов:

1. Проблема совместимости в широком смысле;
2. Проблема поддержки старого кода;
3. Проблема зависимости человеческой жизни «от бесчувственных роботов» (с), к чему мы стремительно приближаемся;
4. Проблема data mining`а вообще и поиска готового решения в бездонной бочке рецептов в частности (github, stack overflow?);
5. Проблема «переписывания» старого кода (и плохого, и хорошего) — этот момент так и хочется перечитывать :);
6. Проблема необъятности ИТ-технологий. Иногда говорят, что последний универсальный физик жил в середине пошлого века, имея ввиду Льва Ландау. Похоже сейчас наступает (или уже наступило) время, когда найти универсального программиста таки уже невозможно;
7. В тексте нет слова хакер, ни в позитивной, ни в негативной коннотации. Но написано и об исследователях, и о тех преимуществах, которые можно получить зная те или иные backdoor`ы и о том, какую власть это может дать.
8. и наверное это не все… :)

Складывается впечатление, что писал это человек, на своей шкуре прочувствовавший эти самые проблемы.
Хочу отметить, что «Глубина в небе» была написана в 1999 году, когда многое из того, о чем пишет Виндж еще не было проблемой, или вообще только показалось на горизонте.

В качестве критики хочется отметить, что Виндж прошел мимо ИИ (и сильного и слабого, вообще мимо пробежал, даже нейронные сети не затронул) и свел преимущества ИТ к производительности. Так же в тексте не ощущается присутствие мегакорпораций (хотя конечно «Глубина в небе» не относится к киберпанку), если не считать Кенг-Хо таковой. Нет патентных войн, не затронуты вопрос копирайта и проблема закрытых проприетарных разработок, исходные коды к которым так и не были опубликованы.



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

В прошлые разы мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа, и два метода: хеш-индекс и B-дерево. В этой части займемся индексами GiST.

GiST

GiST — сокращение от «generalized search tree». Это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree.

В чем же разница? Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки…

Тут на помощь и приходит индексный метод GiST. Он позволяет задать принцип распределения данных произвольного типа по сбалансированному дереву, и метод использования этого представления для доступа по некоторому оператору. Например, в GiST-индекс можно «уложить» R-дерево для пространственных данных с поддержкой операторов взаимного расположения (находится слева, справа; содержит и т. п.), или RD-дерево для множеств с поддержкой операторов пересечения или вхождения.

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

Ubuntu интегрирована в Windows 10 Redstone, Visual Studio 2017 обзавелась поддержкой разработки под Linux – даже Microsoft сдает позиции в пользу растущего числа сторонников Торвальдса, а ты всё еще не знаешь тайны виртуального терминала в современных дистрибутивах?

Хочешь исправить этот пробел и открываешь исходный код? TTY, MASTER, SLAVE, N_TTY, VT, PTS, PTMX… Нагромождение понятий, виртуальных устройств и беспорядочная магия? Всё это складывается в довольно логичную картину, если вспомнить, с чего всё началось…

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

Оглавление:

1) Local TCP forwarding
2) Remote TCP forwarding
3) TCP forwarding chain через несколько узлов
4) TCP forwarding ssh-соединения
5) SSH VPN Tunnel
6) Коротко о беспарольном доступе
7) Спасибо (ссылки)

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

В любом случае рак пугает. Большая часть страхов рождается из-за неправильных представлений о заболевании или просто неведения. Мы в Атласе верим, что знание — сила, поэтому подготовили серию статей, где расскажем о раке: как он образуется, можно ли его предотвратить, и как выстроить процесс лечения.

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


Автор иллюстраций Майкл Ковальски

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

• С точки зрения User Experience (UX) фронтенд должен обеспечивать быструю загрузку и работу веб-страниц.
• А с точки зрения Developer Experience (DX) нам хочется, чтобы и сам фронтенд тоже работал быстро, был прост в использовании и вообще являлся примером для подражания.

Всё это делает пользователей и разработчиков счастливее, а заодно существенно улучшает ранжирование сайтов поисковиками. Например, Google уделяет особое внимание оптимизированности фронтенда. Если вы достаточно долго бились над тем, чтобы ваш сайт заработал побольше баллов в Google Pagespeed Insights, то, надеемся, эта статья поможет вам лучше понять, для чего всё это нужно и каково разнообразие стратегий оптимизации фронтенда.

Про fail2ban написано уже много, в том числе и на хабре. Эта статья немного о другом — как сделать защиту им еще надежнее и о еще пока неизвестных в широких кругах новых функциях fail2ban. Добавлю сразу — речь пойдет пока про development branch, хотя уже долго проверенный в бою.

Краткое вступление

В большинстве своем fail2ban устанавливается из дистрибутива (как правило это какая-нибудь стабильная старая версия) и настраивается по манам из интернета за несколько минут. Затем годами работает, без вмешательства админа. Нередко даже логи, за которыми вроде как следит fail2ban, не просматриваются.
Так вот, сподвигнуть на написание этого поста меня заставил случай, произошедший с одним сервером моего хорошего знакомого. Классика жанра — пришла абуза, за ней вторая и пошло поехало. Хорошо еще злоумышленник попался ленивый — логи не потер, да и повезло еще крупно, что logrotate был настроен, чтобы хранить логи месяцами.

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

Введение

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

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

Выводим список и создаём новые доски

Оригинал

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

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

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Привет всем!
Это вольный перевод статьи How to Build Your Own Dependency Injection Container.
Т.к. это мой первый перевод для хабра, прошу указывать на ошибки, неточности.

Как создать свой собственный Dependency Injection Container.

Поиск “dependency injection container” на packagist на данный момент выдает более 95 страниц результата. С уверенностью можно сказать, что это особое “колесо” уже изобретено.

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

В этой статье мы собираемся учиться делать простой dependency injection container пакет. Весь написанный в статье код плюс PHPDoc аннотации и unit-тесты с 100% покрытием доступны на GitHub. Все это так же добавлено на Packagist.