Хотел бы написать небольшой цикл статей посвященных тому, как я написал свою RTOS с какими трудностями столкнулся и зачем вообще писать свою RTOS если уже есть FreeRTOS, RTX, embOS и т.д. список достаточно большой.

Начнем с того, что по мере работы я сталкивался с тем, что часть разработчиков (и я в том числе когда-то и сам) относятся к RTOS как к некоторому черному магическому ящику, мол что-то там происходит как-то все это работает и лучше туда не лесть, а то поломается ящик и проекту «ХАНА». И все хорошо пока хорошо, но как только появляются проблемы, то начинаются бессонные ночи с отладчиком, сроки по проекту горят, а самое главное и коварное, что ошибки в RTOS отловить крайне сложно. Зачастую они имеют плавающий характер и такие эффекты как переполнение стека, инверсия приоритетов, взаимные блокировки, и все, что связанное со средствами синхронизации отладить крайне сложно.

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

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

При написании RTOS, я осознанно отказался от поддержки проприетарных архитектур как AVR, PIC и мой выбор пал на семействе CORTEX, поскольку cortex-mX, на сегодня самая распространенная архитектура в Embedded.

Собираем Opus

1. Введение

Привет! Я всегда хотел собрать свой компьютер — не только в теории понять как «бегают» биты, складываются числа, работают прерывания, как программный код превращается в нули и единицы. У меня получилось и я хотел бы поделиться своим опытом. Это заняло у меня 140 часов и $400 на все компоненты и их доставку. Если вам интересно узнать о проекте, спускайтесь под кат.

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

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

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

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

Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.

По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.

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

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

Ну или почти вся...

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

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

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

«Забудь дедукцию, давай продукцию», —  эту формулу я усвоил сразу после окончания института. Тогда я ещё был финансистом и мир науки и образования меня буквально выкинул в мир бизнеса. Я ждал матриц, проектных структур, менеджмента строго по Мескону и Хедоури, а получил «твою мать, какого х** бюджет не сводится, давай, подрисуй цифирь и отправим это уже главнюкам». Вооот, а это была компания на 120 человек с чистой прибылью в пару сотен миллионов. Это было начало 2008 года, который компания пережила, сократив 23 человека. А вот декабрь 2014-го стал последним месяцем существования всего холдинга. Я, уже большой чувак, понимал, что это всё — результат череды управленческих ошибок. К тому времени я работал сисадмином в ИТ-компании и был уверен, что здесь всё будет круто. Сменив три ИТ-компании, я понял, что айтишники при всей инженерной стройности управляют и развиваются без вектора. И знаете, сейчас меня это тревожит.

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

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

Предисловие

«Чтобы попасть на Территорию, вы должны сесть в самолет. Правда, летом вы можете добраться сюда и на пароходе — месячное плавание среди льда и тумана, когда кажется, что мир исчез и существуют лишь железная палуба, перекличка сирен каравана и ваша каюта. Через несколько дней именно в каюте вы и будете проводить почти всё свое время, ибо вам быстро осточертеет блеклая полярная вода, низкое небо и слово „навигация“, которое произносится тысячу раз на дню.… Рейс ваш окончится не на той планете, с которой начался. Вас ожидает прохладный и влажный воздух, черный и желтый пейзаж, если вы прилетели летом, и некая суровая снежная обнаженность, которую трудно передать словами, если вас затащило туда зимой.»
Олег Куваев, роман «Территория», 1978 г.

# ss -s
Total: 15046 (kernel 16739)
TCP:   39306 (estab 11458, closed 25092, orphaned 110, synrecv 0, timewait 24929/0), ports 0

Transport Total     IP        IPv6
*	  16739     -         -        
RAW	  0         0         0        
UDP	  15        5         10       
TCP	  14214     1214      13000    
INET	  14229     1219      13010    
FRAG	  0         0         0        

Расцвет эпохи программируемых калькуляторов в нашей стране пришёлся на середину 80-х годов. Потом на смену относительно сытым и благополучным временам пришла эпоха бандитского капитализма, когда стране стало не до выпуска своей высокотехнологичной продукции бытового назначения, вот уже сменились поколения, но ностальгия по тем временам, когда мы бессонными ночами пытались сократить код программы хотя бы на пару байтов, чтобы уместить задуманную функцию, выискивали всё новые и новые недокументированные возможности, придумывая способы, как их можно использовать на практике, сочиняли целые циклы рассказов в качестве фона для наших игровых программ, не даёт забыть свой МК-61 со 105 байтами программной памяти. Поэтому хочу написать заметку о том, что собой представляли и как работали эти самые программируемые калькуляторы. Даже если эта тема сегодня периодически и поднимается, то не настолько часто, чтобы приесться уважаемому читателю, так что надеюсь поведать что-то новое.