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

Как это делать и что нужно знать, чтобы обучение было приятным и интересным, — рассказываем в этой статье.

От загрузчика к ядру

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

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

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

Устройства компании Mikrotik стали широко распространены из-за своей цены по отношению к функционалу. Но и ошибки в программном обеспечении никто не отменял. И на этот раз вылез серьёзный баг.

25 марта один из пользователей форума Mikrotik сообщил об обнаружении подозрительной активности маршрутизаторов mikrotik с применением портов telnet (TCP port 23), TR-069 (TCP port 7547) и WINBOX (TCP 8291).

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

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

Привет, Хаброжители! Авторы шаг за шагом познакомят вас с основами и возможностями Kali Linux. В книге предложен краткий курс работы с командной строкой Linux и ее концепциями, описаны типичные сценарии установки Kali Linux. Прочитав эту книгу, вы научитесь конфигурировать, отлаживать и защищать Kali Linux, а также работать с мощным менеджером пакетов дистрибутива Debian. Научитесь правильно устанавливать Kali Linux в любых окружениях, в том числе в крупных корпоративных сетях. Наконец, вам предстоит познакомиться и со сложными темами: компиляцией ядра, созданием собственных образов ISO, промышленным шифрованием и профессиональной защитой конфиденциальной информации.

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

В этой статье мы напишем с нуля калькулятор обратной польской записи (RPN) на чистом ассемблере x86. Когда закончим, то сможем использовать его так:

$ ./calc "32+6*" # "(3+2)*6" в инфиксной нотации
30

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

Начнём с написания базовой программы Hello world! для проверки настроек среды. Затем перейдём к системным вызовам, стеку вызовов, стековым кадрам и соглашению о вызовах x86. Потом для практики напишем некоторые базовые функции на ассемблере x86 — и начнём писать калькулятор RPN.

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

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

Прим перев.: Автор оригинальной статьи — испанский Open Source-энтузиаст nachoparker, развивающий проект NextCloudPlus (ранее известен как NextCloudPi), — делится своими знаниями об устройстве дисковой подсистемы в Linux, делая важные уточнения в ответах на простые, казалось бы, вопросы…

Сколько пространства занимает этот файл на жёстком диске? Сколько свободного места у меня есть? Сколько ещё файлов я смогу вместить в оставшееся пространство?



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

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

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

Напомню, кластер будет размещаться на площадке хостера, логи будут собираться со всего мира по TCP, а среднее количество логов — около 1,2 Тб/день при нормальных условиях.

В настоящее время мы используем CentOS 7 и Graylog 2.2, поэтому все конфигурации и опции будут описываться исключительно для этих версий (в Graylog 2.2 и Graylog 2.3 ряд опций отличается).

Первая часть статьи здесь.

Часть 6. Избегание коллизий

Для правильной навигации NPC часто требуется способность избегать препятствий. В этой части мы рассмотрим steering behavior collision avoidance (избегание коллизий), позволяющее персонажам благополучно уворачиваться от препятствий в окружении.

---

Введение

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

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


Анализируются препятствия перед персонажем и выбирается ближайшее (наиболее угрожающее).

Поведение избежания коллизий — это не алгоритм поиска путей. Оно заставляет персонажей двигаться по окружению, избегая препятствий, постепенно находя путь сквозь блоки — но в случаях с препятствиями в виде L или T, например, оно действует не очень хорошо.

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

Правильно настроить поведение камеры в классическом 2D-платформере не так просто, как может казаться.

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

Например, если камера сдвигается вверх при каждом прыжке персонажа, то это запросто может вызвать тошноту. Кроме того, при мгновенном разгоне и остановке персонажа камера может резко дёргаться.

В нашей новой игре Tiny Thor мы экспериментировали с различными вариантами. Я хочу рассказать о том, на каких техниках мы в результате остановились.

Первая часть

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

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

Направление

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

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

Wonder Boy, ещё одна моя любимица, быстрый платформер, в котором можно идти только вперёд через старое доброе одностороннее окно свободного хода. В отличие то Super Mario Bros., там нет зоны разгона, плавно ускоряющей камеру, но есть другая интересная техника, которую я называю «рельсы». Камера ставится и движется так, чтобы предвосхищать будущие преграды.

Wonder Boy (Sega, 1986)

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

Пятое поколение приставок, среди них PlayStation и Nintendo 64, открыло новые аппаратные возможности, положив начала грубому, но настоящему 3D. Приёмы трёхмерной камеры — сами по себе захватывающая и многогранная тема, но поддержка 3D повлияла и на двухмерные игры. Разработчики теперь могут приближать камеру, наклонять вид и даже сочетать 2D и 3D — то, что мы сейчас называем 2,5D, когда игра идёт на двухмерной плоскости, но в объёмном мире.

Добрый день, читатель! В этой статье рассмотрим процесс разработки типичного персонажа нашей дебютной игры Kidarian Adventures. Я продемонстрирую свою привычную структуру работы, однако, заострю внимание на создании анимации в Dragon Bones, приложу пояснения и самописные видео-туториалы.

Помните небезызвестный мем про "корованы"? Наверное, каждый, кто разрабатывает игры (или хотел бы этим заняться) раздумывает о неком "проекте мечты", где можно будет "грабить корованы" и "набигать". А ещё, чтобы погода менялась динамически, и на грязи следы от сапог оставались, и деревья росли в реальном времени. И ещё, чтобы ...

Понятно, что в реальном игровом проекте такая погоня за хотелками — смерти подобна. А вот в техно-демке — самое то.

Глобальное освещение, динамический свет и декали (да, есть такое слово :) ) в действии.

Я очень люблю смотреть на белые предметы без текстуры. Недавно в художественном магазине я долго рассматривал гипсовые фигуры, которые художники используют в качестве модельных объектов. Очень приятно видеть все эти плавные переходы света и мягкие тени. Позже, когда я вернулся домой и открыл Unity3D, пришло понимание, что свет в моём проекте по-прежнему скучный и нереалистичный.
С этого момента началась история глобального освещения, которую я сегодня расскажу.

— Я тут воду для проекта запилил.
— О, круто! А почему она плоская? Даёшь волны!
…
— Слушай, ты тогда про волны говорил, помнишь? Зацени!
— Да, хорошие волны, а преломление и каустику ещё не делал?
…
— Привет, я тут игрался с Unity всю ночь, смотри какие отражения и каустику закодил!
— Дарова, и правда, хорошо! А когда у тебя вода кипит, отражения не глючат?
…
— Хай, реализовал наконец, кипение, вроде ничего?
— О, прямо как нужно! Слушай, прикинь как круто, если кипящую волну заморозить?
…
— Лови картинку, лёд вроде ничего придумал?
— Норм, слушай, а у тебя лёд замерзает, он в объёме увеличивается? И кстати, ты когда геймлей то делать начнёшь?
Вариации на тему лога с другом.

Да, вы уже поняли, наконец-то расскажу про реализацию воды в проекте. Приступим?

Всем привет! Решил поделиться своим опытом по добавлению игры в Google Play Console и настройке Play Games Plugin для Unity.

Начнем мы с настройки Unity.

Введение

Недавно я приступил к реализации системы 2D-теней в Unity, которую можно было бы использовать в настоящей игре. Как известно профессиональным разработчикам, есть большая разница между тем, чего можно достичь в техническом демо и тем, что применимо для интеграции в полную игру, где реализованная возможность является лишь одной из множества. Влияние на ЦП, видеопроцессор и память должны находиться в балансе со всем остальным в игре. На практике у разных проектов возникают различные ограничения, но я решил создать систему, занимающую не больше пары миллисекунд времени обработки и не больше нескольких мегабайт в памяти.

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

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

Понятно, что можно обойтись смартфоном или планшетом, особенно если нужно только зайти по ssh. Но пользоваться в таких случаях тачскрином, как по мне, — это боль и страдания.



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

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

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

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

Однако с подобным подходом возникает ряд проблем:

• Сейф можно вскрыть болгаркой или иным силовым методом
• Производитель сейфов может оставить обходную лазейку и получить доступ к содержимому