Как может показаться, анализ сигналов и данных — тема достаточно хорошо изученная и уже сотни раз проговоренная. Но есть в ней и некоторые провалы. В последние годы словом «энтропия» бросаются все кому не лень, толком и не понимая, о чем говорят. Хаос — да, беспорядок — да, в термодинамике используется — вроде тоже да, применительно к сигналам — и тут да. Хочется хотя бы немного прояснить этот момент и дать направление тем, кто захочет узнать чуть больше об энтропии. Поговорим об энтропийном анализе данных.

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

Я расскажу о следующем:

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

Господа! Мы с Тимуром Палташевым из AMD в Саннивейл, Калифорния, а также с несколькими соратниками из России, Украины и Казахстана решили спланировать несколько семинаров разных форматов, которые покрывают темы на стыке хардвера и софтвера: цифровая логика, Verilog, правила RTL (Register Transfer Level), введение в микроахитектуру (строение конвейера) процессоров, низкоуровневое программирование на ассемблере, использование микроконтроллеров, особенности чипов для интернета вещей, введение в RTOS-ы, лабы на ПЛИС-ах / FPGA, а также (для части аудитории, которая интересуется производством чипов) физические аспекты проектирования и производства на фабрике (для последнего мы решили привлечь материалы от преподавателя курса в Университете Калифорнии Санта Круз, отделение в Silicon Valley).

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

Для начала предыстория:

Некоторое время назад я приобрёл на Ebay б/у ноутбук Lenovo Thinkpad W520. Как известно, W-серия — это очень мощные ноутбуки, железки в которых дадут фору многим более современным машинам. Конечно же, я начал его обустраивать под себя, и, в частности, решил проапгрейдить имеющуюся память всем, что было в наличии, а в наличии было немало: 2 свободные планки DDR3-1600 из старого ноута — 4 и 8 гигабайт. Посмотрев на то, что было установлено продавцом, я обнаружил, что из 3 установленных планок 2 — DDR3-1600, а одна — 1333. Учитывая, что первые две были по 8 гигабайт, а последняя — 2 гигабайта, от неё я и решил избавиться. Рассчитывая получить после апгрейда 8+8+8+4=28 гигабайт DDR3-1600 в рабочем ноуте, я залил всё слюной и всё это быстренько подключил. И получил 28 гигабайт… DDR3-1333. «Что за...», подумал я и полез в гугл.

После непродолжительных поисков я обнаружил, что как официально, так и неофициально W520 поддерживает только DDR3-1333, а владельцы более быстрой памяти зря тратили на неё деньги. Мне стало немного обидно за всех таких владельцев, и я решил попробовать избавиться от этой несправедливости, тем более, что контроллер памяти, нынче, как известно, в процессоре, и установленный в моей модели Intel Core i7 2720QM официально поддерживает DDR3-1600.

Занимаясь разработкой алгоритмов, постоянно одергиваю себя, а вдруг изменения, которые работают на небольшом примере, привнесут разброд и шатание в результаты на других, больших данных. Тогда мне на помощь приходит командная строка. Самое ужасное, что каждый раз реализовывать парсер аргументов уже надоело, а значит, не последним средством для C++ программиста оказывается пакет program_options из библиотеки boost.

Привет, хабравчане!

Меня зовут Михаил Матросов, я технический менеджер в компании Align Technology. Сегодня я поработаю капитаном и немного расскажу об основах современного С++.

Работая над большим проектом, мне часто приходится смотреть чужой код и порой я вижу странное. А именно, многие даже вполне матёрые программисты на С++ могут не знать некоторых фундаментальных для языка вещей. Ну, это даже не слишком удивительно — язык такой.

Мне бы хотелось поговорить об этих основах и начну я со своей любимой темы. Будем говорить об операторах new и delete. А точнее, об их отсутствии. Я расскажу, как писать надёжный и современный код на С++ без использования операторов new и delete.

Казалось бы, тема стара как мир, Саттер и Майерс в своё время всё разложили по полочкам. Именно поэтому я не буду вдаваться в ненужные подробности, отправляя читателей к первоисточникам. Моя цель собрать информацию по вопросу в одном месте, дать соответствующие ссылки и сформулировать ёмкие рекомендации.

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


Изображение взято с сайта behappy.me

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

1. Вдумчивое чтение — чтение фундаментальных книг, структурированных и информативных. Это требует длительной концентрации, причём нельзя читать в состоянии усталости, поскольку вы попросту уснёте и ничего не запомните. Если у вас ещё нет электронной читалки — обязательно купите.
2. Лёгкое чтение — чтение менее серьёзной литературы вроде книг о мотивации, продуктивности, Soft Skills. Всё это зря недооценивается некоторыми программистами. Эти книги не требуют большой концентрации внимания. Да, это совершенно не о языке С++, но это о том, как вообще что-то делать и всё-таки сделать. Хорошо читается перед сном.
3. Подкасты — хорошо идут, когда нужно переключиться с чего-то одного на другое, или во время шоппинга. Помогают взглянуть на что-то неожиданное. Тренируют умение слушать и понимать услышанное, что может быть полезным умением (например, для участия в совещаниях). Если английский язык для вас не родной — вы можете услышать как произносятся термины и имена. Я рекомендую послушать CppCast или Software Engineering Radio — я был приятно удивлён широким охватом их тем. Первый эпизод вышел в 2006-ом году, подкаст наполовину состоит из истории программной инженерии и наполовину из теории (паттерны, проблемы, решения и т.д.)
4. Видео и лекции — CppCon, CppNow, Meeting C++, ACCU Conference для начала. Там просто ошеломляющее количество интересных докладов. В отличии от подкастов это требует визуального внимания и концентрации, но и выучить в результате можно больше. Я думаю просмотр 2-5 видео в неделю вполне достижимо.
   Совет: увеличивайте скорость аудио/видео — мозг быстро привыкает к этой скорости и вы сможете услышать больше за меньшее время.
5. Обсуждения, форумы, твиттер — этот канал обмена информацией требует меньше всего концентрации. Вы можете быстренько просмотреть дискуссии, ленту твиттера в поисках чего-то интересного — просто убивая время. Если что-то нашлось — можно добавить это в список для чтения позже. Чем это всё полезно — огромным разнообразием людей, мнений, подходов, задач и решений. Хороший способ разогнать свой мозг весьма случайной информацией.
   
   Вот, например, мой список Core C++ чтобы следить за значимыми в мире С++ разработчиками. А ещё есть несколько страниц и групп в Facebook и неплохие обзоры от Jens Weller.
   
   Для дискуссий о С++ есть раздел на Реддите (прим. переводчика: а ещё есть хаб на Хабрахабре). Ну и, конечно, группы комитета по стандартизации C++
6. Блоги и статьи — обычно занимает 5-10 минут чтобы прочитать среднюю статью. Если встречается более глубокая статья — можно пометить её для чтения «когда я буду сконцентрирован». По моим наблюдениям выходит 5-10 хороших статей в неделю и не так сложно прочесть их все.

Введение

Возможно некоторые читатели помнят мою самую первую статью на ресурсе, посвященную загрузке Windows с VHD-образа. Возможно я бы и не вернулся к этой теме, если бы не нашлись люди, попытавшиеся повторить данную технологию на своих домашних машинах. Естественно, с реализацией этого решения возникли проблемы, касающиеся в основном тех ошибок, которые выплевывает bootmgr в тех случаях, когда ему что либо не нравится. Попытки интерпретации ошибок загрузки вроде 0xc03a0003 путем гугления к особо ценным результатам не приводят, а документация Microsoft на этот счет хранит многозначительное молчание. Возникла идея изучить процесс обработки VHD-образов, получив информацию из первых рук, то есть от самого загрузчика.

Если обратится к уже имеющейся в сети информации, то существует замечательный блог "Записки эникейщика о Windows" на страницах которого (раз, два и три) размещены, на мой взгляд, самые ценные сведения, по вопросам устройства bootmgr. Автор подробно рассмотрел процесс загрузки, включая исследования кода MBR и PBR, остановившись на структуре bootmbr, кратко описав происходящие при его работе процессы.

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

О создании новой операционной системы в последнее время говорят немало, особенно в России. В сумме размер всех публикаций по данной теме наверняка превышает размеры исходного кода любой операционной системы. Так что остается только одна проблема – от этих разговоров никаких новых OS не появляется. Всё, что предъявляется публике (и на что тратятся бюджетные деньги), на поверку оказывается кастомизированными сборками OS семейства Linux, а значит, не содержит ничего принципиально нового. Но, если о чем-то не говорят, это не значит, что его не существует.
В этой статье – проект принципиально новой OS, созданный в нерабочее время одним из ведущих сотрудников (Principal Engineer) российского подразделения Intel.

Примечание от переводчика:

Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).

---

Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.

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



Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.

Мир в 1997 году

Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.

Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».

Британская компания, две американские компании и 18 университетов (включая российские МИЭТ, ИТМО, СГАУ, ННТУ) сотрудничали, чтобы выпустить современный курс по микроконтроллерам c небольшой привязкой к интернету вещей. Об этом – сегодняшний пресс-релиз Imagination Technologies, Microchip Technology и Digilent (отделения National Instruments). Главный автор — профессор Александр Дин из университета Северной Каролины. В отличие от более легковестных курсов интернета вещей, новый курс подводит под предмет твердую инженерную базу – в нем подробно обсуждается использование RTOS-ов, архитектура микропроцессорного ядра микроконтроллера, протоколы периферии и даже оптимизация алгоритмов при программировании.



Скачать курс можно здесь:

https://community.imgtec.com/downloads/connected-microcontroller-lab-v1.2/

В пресс-релизе, помимо цитат из США, Великобритании, Германии, Китая, есть и цитата из России:

“MIET is part of Imagination’s MIPSfpga and Connected MCU Lab beta-testing programs. Our students have benefited from the MIPSfpga hands-on workshops and we are looking forward to implementing the Connected MCU Lab at our university because this course offers an up-to-date and well-structured curriculum for teaching embedded solutions to future engineers.”

– Alexey Pereverzev, Head of Computer Engineering, National Research University of Electronic Technology (MIET), Russia

Пару десятков слайдов из курса, чтобы вы почувствовали его вкус:

Здравствуйте, уважаемое сообщество! Недавно на Хабре проскакивала неплохая обзорная статья о разных алгоритмах поиска подстроки в строке. К сожалению, там отсутствовали подробные описания каких либо из упомянутых алгоритмов. Я решил восполнить данный пробел и описать хотя бы парочку тех, которые потенциально можно запомнить. Те, кто еще помнит курс алгоритмов из института, не найдут, видимо, ничего нового для себя.

Как известно, в современных архитектурах x86(_64) и ARM виртуальная память процесса линейна и непрерывна, ибо, к счастью, прошли времена char near* и int huge*. Виртуальная память поделена на страницы, типичный размер которых 4 KiB, и по умолчанию они не отображены на физическую память (mapping), так что работать с ними не получится. Чтобы посмотреть текущие отображённые интервалы адресов у процесса, в Linux смотрим /proc/<pid>/maps, в OS X vmmap <pid>. У каждого интервала адресов есть три вида защиты: от исполнения, от записи и от чтения. Как видно, самый первый интервал, начинающийся с load address (соответствующий сегменту .text у ELF в Linux, __TEXT у Mach-O в OS X), доступен на чтение и исполнение — очень логично. Ещё можно увидеть, что стек по сути ничем не отличается от других интервалов, и можно быстро вычислить его размер, вычтя из конечного адреса начальный. Отображение страниц выполняется с помощью mmap/munmap, а защита меняется с помощью mprotect. Ещё существуют brk/sbrk, deprecated древние пережитки прошлого, которые изменяют размер одного-единственного интервала «данных» и в современных системах эмулируются mmap’ом.

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

• оптимально управляет уже выделенной памятью;
• значительно уменьшает количество обращений к ядру (ведь mmap / sbrk — это syscall);
• вообще абстрагирует программиста от виртуальной памяти, так что многие пользуются malloc’ом, вообще не подозревая о существовании страниц, таблиц трансляции и т. п.

Довольно теории! Будем щупать malloc на практике. Проведём три эксперимента. Работа будет возможна на POSIX-совместимых операционках, в частности была проверена работа на Linux и на OS X.

Здравствуйте, уважаемые читатели. Когда-то очень давно, почти 3 года назад, я написал пару статей о форматах данных, используемых в UEFI-совместимых прошивках. С тех пор в этих форматах мало что изменилось, поэтому писать про них снова я не буду. Тем не менее, в тех статьях был достаточно серьезный пробел — отсутствовали какие-либо упоминания об NVRAM и используемых для её хранения форматах, т.к. тогда разбор NVRAM мне был попросту неинтересен, ибо те же данные можно получить из UEFI Shell на работающей системе буквально одной командой dmpstore.
По прошествии трех лет выяснилось, что хранилище NVRAM умеет разваливаться по различным причинам, и чаще всего это событие приводит к «кирпичу», т.е. воспользоваться вышеупомянутой командой уже не получится, а данные (или то, что от них осталось) надо доставать. Собрав пару развалившихся NVRAM'ов вручную в Hex-редакторе, я сказал "хватит это терпеть!", добавил поддержку разбора форматов NVRAM в UEFITool NE, и решил написать цикл статей об этих форматах по горячим следам и свежей памяти.
В первой части поговорим о том, что вообще такое этот NVRAM, и рассмотрим формат VSS и его вариации. Если интересно — добро пожаловать под кат.

Я ничего не смыслю в электронике, никогда не работала с платами и микроконтроллерами, не паяла, но посмотрев The Maker Show, я уже подумываю, а не заказать ли мне Arduino или Raspberry Pi.
Рекомендую это шоу тем, кто только начинает изучать тему Интернета вещей. Для вас я сделала обзор основных выпусков шоу.

1. Введение в электронику

Как заставить светодиод светиться с помощью лимона?

Технологический евангелист Microsoft Дэвид Крук проводит несколько экспериментов, иллюстрирующих основы электроники.

Однажды ко мне попал нерабочий лазерный датчик расстояния Keyence LK-G407. Мало того, что он был нерабочий, так его еще и нельзя было использовать без специального управляющего блока. Но ведь у датчика такие интересные характеристики: измерение расстояния с точностью до единиц микрон, и скорость работы — 50 килоизмерений/с. Так что, чтобы запустить его, придется заметно поковыряться в самом датчике, заодно и ценный опыт получить.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

Насколько бы закрытым ни было программное обеспечение Microsoft, информации о своем внутреннем устройстве оно выдает предостаточно. К примеру, экспорт функций из библиотеки по именам дает представление о ее интерфейсах. В свободном доступе есть и отладочные символы, которые повсеместно используются для диагностики ошибок в ОС. Однако на руках у нас все равно имеются только скомпилированные бинарные модули. Становится интересно: а какими они были до компиляции? Давайте попробуем разобраться, как вытащить побольше информации об исходных кодах, не делая ничего незаконного.

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

1. Оптимизация уже готового, проверенного и работающего кода.
2. Изначально написание оптимального кода.
3. Просто использование оптимальных конструкций.

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

Второй тип оптимизации — это изначальное проектирование кода с учетом требований к производительности. Такое проектирование не является ранней оптимизацией.

Третий тип даже не совсем оптимизация. Скорее это избегание неоптимальных языковых конструкций. Язык C++ довольно сложный, при его использовании частенько нужно знать, как реализован используемый код. Он достаточно низкоуровневый, чтобы программисту пришлось учитывать особенности работы процессоров и операционных систем.

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

Встречайте – подсистема Intel Management Engine, самая загадочная составляющая архитектуры современных x86-платформ.