Ко мне в руки тут попала одна книжка про разработку этих ваших ведьмаков и Гервантов из Рыбии. История франшизы, короче. В общем, прочитал я её, проникся, решил изучить тему глубже, а потому, дорогие читатели, держите материал, без регистрации и СМС, даром. Это будет компиляция всевозможной инфы в одном месте, максимально подробно. Кто уже читал эту книгу или изучал разные источники — и так всё знает, кто не читал — экономлю вам время и приоткрываю завесу тайн, которые, возможно, вы не знали. Всё это приправлено разными интервьюшками, концепт-артами и прочей информацией с забугорных сайтов и других годных материал. Должно быть интересно. Тем более игре совсем недавно (26 октября) стукнуло 16 лет, хороший повод. Итак…

Хотите себе «Дарк Соулса» от стратегий — добро пожаловать в «СтарКрафт».

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

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

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

В общем, в это надо играть, про это приятно вспомнить и поговорить.

Тем более, если я правильно подсчитал, игре сегодня стукнуло 25 лет. Одним словом, праздник!

Недавно я занимался изучением IoT и, так как мне не хватало устройств, при попытках симулировать работу прошивки я часто сталкивался с неимением нужного /dev/xxx. Так что я стал задумываться, а могу ли написать драйвер самостоятельно, чтобы заставить прошивку работать. Независимо от того, насколько сложно это будет, и удастся ли воплотить такое намерение, в любом случае вы не пожалеете, если научитесь разрабатывать драйвер Linux с нуля.

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

В последнее время практически любую радиоактивную аварию принято сравнивать с Чернобылем. Авария на Фукусиме? Японский Чернобыль! Два бразильца в тихую вынесли и расковыряли капсулу с радиоактивным материалом? Бразильский Чернобыль! И если Фукусима ещё хоть как-то тянет на чернобыльские свинцовые лавры, то инцидент в Хуарезе, который повсеместно величают не иначе, как «Мексиканский Чернобыль», по масштабам разрушений или смертей, к счастью, сильно недотягивает. Однако проблем он создал весьма прилично, и часть из них, возможно, не решена до сих пор. Тем более странно, что в отличие от гораздо более локальных инцидентов (например, в эстонском Таммику, когда два молодых балбеса вломились на свалку радиоактивных отходов и спёрли контейнер с цезием), никаких докладов по нему на ресурсах МАГАТЭ нет. Виной всему стали небольшая капсула с радиоактивным материалом, и неизвестный круг безответственных людей. Впрочем, обо всём по порядку.

❯ Введение

В сегодняшнем туториале по Rust мы откроем для себя мир gRPC. Для этого создадим очень простой микросервис с единственной конечной точкой, который будет отзеркаливать то сообщение, что мы ему пошлем. Чтобы протестировать наш микросервис, мы также напишем простой клиент на Rust.

Перед изучением этого поста также будет полезно посмотреть предыдущие публикации автора по Rust:

https://blog.ediri.io/lets-build-a-cli-in-rust
https://blog.ediri.io/how-to-asyncawait-in-rust-an-introduction

Пошаговое руководство по установке и конфигурированию всех компонентов kubeflow на локальной машине.


Рис. 1. Взаимодействие Kubeflow и Kubernetes | рисунок автора |иконки от Eucalyp

Kubeflow [1] – это созданная Google опенсорсная платформа, на которой разворачивается весь жизненный цикл разрабатываемой модели машинного обучения. Kubeflow представляет собой инструментарий, каждый компонент которого применяется для отработки каждой из стадий жизненного цикла при машинном обучении, а именно: исследования данных, конструирования признаков, преобразования признаков, обучения модели, оценки модели, тонкой настройки модели, предоставления модели и версионирования модели. Главный атрибут kubeflow заключается в том, что он предназначен для работы на базе kubernetes [2]. Таким образом, kubeflow пользуется именно теми преимуществами, которые предоставляет кластер kubernetes, в частности, оркестрацией контейнеров и автомасштабированием.

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

Создавая такой алгоритм, вы заметите, что просто замусориваете ваш код логикой if-else (пока он не превратится в кашу), а самим вам начинает казаться, что вот так просто не прокатит.

Итак, если только вас не пробирает дрожь от математики – читайте дальше. Здесь в дело вступает нечёткая логика! Немного контекста: слово «нечёткий» (англ. «fuzzy») в данном случае означает «труднопонимаемый» — таков может быть, например, код вашего коллеги.

В этом посте я постараюсь объяснить нечёткую логику и объяснить, как она работает.

❯ Когда взаимодействуют разработчики и операторы

Предположим, вы написали приложение на Java и развернули его в Kubernetes в среде разработки. Рано или поздно это приложение уйдёт в продакшен, и вам придётся узнать, каково оно на деле. Затем начинают возникать новые неожиданные проблемы. Причин у таких проблем может быть множество: слишком много пользователей, утечки памяти, условия гонки, и на этапе разработки такие проблемы выявить сложно.

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

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

В Go есть приятная утилита для синхронизации, именуемая WaitGroup, которую могут ожидать одна или несколько горутин. Это требуется для конкурентного завершения задач. В других языках обычно действует следующее соглашение по завершению задач: нужно объединять потоки, выполняющие работу. В Go горутины не имеют ни значений, ни дескрипторов, поэтому WaitGroup применяется вместо объединений. Собирание WaitGroup на основе типичных портируемых примитивов – путаное дело, в которое вовлечены конструкторы и деструкторы; также в процессе этой работы приходится управлять временами жизни. Однако, как минимум, под Linux и под Windows, можно построить WaitGroup из целого числа (инициализируемого в значении), во многом как при создании 32-разрядной очереди и 32-разрядного барьера.

В этой статье объяснен весь процесс, на выходе которого получается рабочий драйвер ядра Linux для недокументированного USB-устройства. Выполнив обратную разработку коммуникационного протокола USB, я покажу архитектуру драйвера ядра для USB. Кроме драйвера ядра в этой статье будет рассказано о простом инструменте для пользовательского пространства; при помощи этого инструмента можно управлять таким устройством. Конечно, придется углубиться в подробности, касающиеся конкретного прибора, но не сомневайтесь – описанный процесс с тем же успехом применим и к другим USB-устройствам.

Если мы с вами похожи, то, всякий раз, когда вы пишете Dockerfile, вам приходится снова следить, что он выкинет. Заходя в какой-то контейнер через+ exec, вы не представляете, будет ли там bash, sh или какая-нибудь другая оболочка. Вы также не знаете, какой контейнерный init сейчас рекомендуется как наилучшая практика. Я определенно до сих пор не знаю, что за фрукт этот Moby.

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

Собираетесь ли вы развертывать базу данных в кластере Kubernetes? Если так – то это отличный выбор. Kubernetes – это инструмент оркестрации контейнеров, который при помощи множества инструментов координирует эксплуатацию приложений в контейнерах (подах). Один из этих контроллеров называется StatefulSet и используется для эксплуатации приложений, сохраняющих состояние.

Сегодня 30 ноября. Эта дата считается (предположительно) днём рождения жанра FPS — First Person Shooter, то есть, шутер от первого лица («вид из глаз»), где окружающий мир, как правило, настроен враждебно (как «жестокая голактика»), а главным способом взаимодействия с ним выступает бескомпромиссное (в большинстве случаев) насилие. Да, приходится много стрелять, очень много. Это, в общем-то, база (основа). Да, шагая в ногу с прогрессом, разработчики пытаются привнести разного креатива, такого как кинематографический сюжет в духе Голливудских блокбастеров, элементы RPG и QTE, а также превращая шутер в какой-нибудь симулятор тотальной и фотореалистичной войны, с максимально-возможным погружением от первого лица. Всё это — попытка освежить FPS, привнести что-то этакое, ведь, давайте будем честны, люди — создания капризные, и им постоянно нужно что-то новое. Но общая концепция остается неизменной.

Triton – это языковой компилятор для создания сильно оптимизированных ядер CUDA. Здесь будут изложены основы программирования для GPU и рассказано, как для этой цели используется Triton.

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

В таких случаях применим, например, PyTorch JIT. Но PyTorch JIT – это высокоуровневый компилятор, способный оптимизировать лишь некоторые части кода, но непригодный для написания специализированных ядер CUDA.

Вы вечно проигрываете в крестики-нолики? Устали от бесконечных издевок окружающих? Чувствуете себя неполноценным членом общества? Тогда вы обратились по адресу! Сегодня у вас есть уникальная возможность пройти наш обучающий курс по беспроигрышной стратегии, который стартует уже сегодня! Присоединяйтесь сейчас и получите скидку 10% по промокоду НЕУДАЧНОЕ_ВСТУПЛЕНИЕ!

Команда Netflix Cloud Data Engineering работает с различными приложениями для JVM, включая такие популярные хранилища данных, как Cassandra и Elasticsearch. Хотя большинство наших кластеров стабильно работают, обходясь выделенной им памятью, иногда «запрос смерти» или ошибка в самом хранилище данных приводят к перерасходу памяти, что может спровоцировать лишние циклы сборки мусора или даже привести к исчерпанию памяти в JVM.

А давайте поговорим о ракете «Союз-5», в конце концов, это самая новая ракета, которая должна в ближайшее время полететь, и о космодроме, с которой эту ракету будут запускать. Но начнём по порядку.

В советские годы под руководством академика Глушко была построена прекрасная ракета «Зенит». Изначально она являлась лишь боковой ступенью сверхтяжелой ракеты «Энергия», но впоследствии эволюционировала до самостоятельного носителя. «Зенит-2» летал с 1985 года и хорошо себя зарекомендовал. Мощный двигатель, две ступени и 14 тонн полезной нагрузки. А главное — стоимость. Одна ракета выходит где-то в 1,4 млрд рублей, в эту же стоимость выходит и ракета «Союз», у которой стоимость лишь на 100 млн меньше. Причём разница между выводимой полезной нагрузкой составляет до 5 тонн!

В Советском Союзе ракета не без проблем, но производилась и запускалась. Но вот наступил 1991 год, страна прекратила своё существование. Производства оказались в двух суверенных государствах (Украина и Россия), а космодром для ракеты находился в ещё одном государстве (Казахстан). Несмотря на это разогнанные мощности продолжали выдавать хорошую продукцию и «Зениты» летали.

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

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

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