Как известно, в современных архитектурах 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.

Будучи высококвалифицированным исследователем, я потратил немало времени на продвижение науки вперёд. Но я родился на Юге и искренне убеждён, что прогресс — это выдумка, и что нужно готовиться к Судному дню, к жатве того, что мы посеяли и к появлению быстрых зомби, медленных зомби, и даже вежливых зомби, которые обращаются к вам «сэр» или «мадам», но в итоге пытаются съесть ваш мозг дабы заполучить ваши навыки. Когда нагрянет революция, нужно быть готовым; поэтому в моменты тишины и покоя, когда я не произвожу очередной прорыв в науке, я размышляю над тем, что же я буду делать, когда прогноз погоды изменится на «РЕКИ КРОВИ ЦЕЛЫЙ ДЕНЬ ДО СКОНЧАНИЯ ВРЕМЁН».

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

Но! Но… Самым важным членом моей банды будет системный программист, ибо в гоббсовском кошмаре невероятных масштабов умеющему отладить драйвер устройства или распредёленную систему человеку можно доверять; системный программист видел ужасы Вселенной и понимает безысходность бытия. Системный программист писал драйверы для устройств, прошивку которых создавал то ли пьяный ребёнок, то ли трезвый карась. Системный программист отлавливал проблему с сетью через восемь машин, три часовых пояса и с дружеским визитом в Омск, откуда ее перенаправили в левое переднее копыто той лошади, что избавила Трою от перенаселения.¹ Системный программист читал исходники ядра для лучшего понимания процессов мироздания и видел комментарий «И ЭТО РАБОТАЕТ ЛОЛ» в коде планировщика, и не смеялся он, но плакал; и отправил он патч ядра для восстановления баланса Силы и устранения инверсии приоритетов, что приводила к зависанию MySQL. Системный программист знает, что делать, когда общество падёт, потому что он уже живет в мире, где царит беззаконие.

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

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

Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

«Джефф Дин компилирует и запускает свой код перед коммитом, но только чтобы проверить на баги компилятор и CPU», — вот один из множества шуточных фактов о Джеффе Дине.

Джефф Дин считается кем-то вроде Чака Норриса. Отличие только в том, что он вовсе не герой боевиков, а инженер-программист компании Google.

Шутки о нём впервые появились на 1 апреля шесть лет назад. Один из коллег Дина по имени Кентон Варда открыл страничку, куда каждый мог добавлять факты о Джеффе Дине. Идею с энтузиазмом подхватили другие разработчики — и вскоре наполнили страничку множеством таких «фактов».

Примечание переводчика: Компания Equinix является крупным оператором дата-центров. Всего под ее контролем находятся 101 дата-центр в 32 крупных городах в 15 странах — сегодня мы расскажем о Нью-Йоркском хабе, который используют для размещения своих серверов многие американские брокерские компании, хедж-фонды и инвестиционные банки.

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

Из всех производственных площадок на «Платформе Equinix», дата-центр NY4 в Секаукусе, Нью-Джерси, является самым загруженным. Более 450 клиентов ведут бизнес в здании площадью более 100 000 квадратных метров, предоставляющем инфраструктуру для крупнейших бирж. Эти биржи служат своего рода магнитом, притягивающим целую «экосистему» брокерских контор, инвестиционных банков, хедж-фондов и компаний, специализирующихся на высокочастотном трейдинге [англ. high-frequency trading, HFT].

Здание было построено в 2000 году как завод по производству очков, который впоследствии закрыли. Equinix – провайдер, который уже оказывал услуги колокации в дата-центре NY2, расположенном на той же улице – приобрел это здание в 2006 году и начал первую фазу строительства NY4 в ноябре 2007 года. Строительство дата-центра было разбито на три фазы, на каждой из которых была создана вспомогательная инфраструктура с залами площадью 29 000 квадратных метров. Оптоволоконное кольцо соединяет NY4 еще с двумя зданиями Equinix в Секаукусе – NY2 и NY5.

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

Знаменитый криптограф Ади Шамир (буква “S” в аббревиатуре RSA) с коллегами вчера опубликовал научную работу под названием «Извлечение ключа RSA путём акустического криптоанализа с низкой частотой дискретизации» (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis). За сложным названием скрывается исключительно доступный метод извлечения ключей RSA (в реализации GnuPG) с помощью обычного мобильного телефона или микрофона. Достаточно лишь положить телефон в 30 см от компьютера жертвы. Если использовать качественные микрофоны, то извлекать ключи можно с расстояния до 4 метров.

Здравствуйте!
Я хочу показать, как пишется программа для управления технологическим оборудованием на ПЛК.
Чаще всего я имел дело с ПЛК производства Schneider Electric. Выбранный мной для данной задачи Quantum является самым мощным и дорогим ПЛК данного производителя. Он может управлять оборудованием с тысячами сигналов, для светофора в реальной жизни его никто, естественно, использовать не будет.

Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.

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

Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.

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

Зачем нам консоль в МК?

Текстовый консольный интерфейс обладает рядом преимуществ для встраиваемых систем, при всей своей мощи и простоте (ведь текст, в отличие от светодиода, говорит сам за себя!):

• Требует относительно мало ресурсов МК, и минимум аппаратных затрат — последовательный интерфейс типа UART или любой другой имеющийся в МК, это может быть встроенный USB или внешний USB-Com адаптер или даже TCP если ваше микроконтроллер достаточно серьезный.
• Удобно подключаться — достаточно терминала поддерживающего Com-port (putty для Windows или minicom для linux).
• Удобно использовать — цветной вывод в терминал, поддержка авто-дополнений, горячих клавиш и истории ввода.

В каждом разрабатываемом устройстве у меня присутствовал отладочный вывод в UART, как в самый распространённый и простой интерфейс.
И каждый раз, рано или поздно, мне хотелось помимо пассивного вывода сделать ввод команд через тот же UART. Обычно это происходило когда мне хотелось для отладки выводить какой-нибудь очень большой объём информации по запросу (например состояние NANDFLASH, при разработке собственной файловой системы). А иногда хотелось программно управлять ножками GPIO, чтобы отрепетировать работу с какой-нибудь переферией на плате.
Так или иначе мне был необходим CLI, который позволяет обрабатывать разные команды. Если кто-то натыкался на уже готовый инструмент для этих целей — буду благодарен за ссылку в комментариях. А пока я написал собствыенный.

Многие мои друзья и знакомые крутят пальцем у виска или задаются вопросом: не жмёт ли мне череп, когда узнают, что я пишу драйвера под Linux. Слово “драйвер” окутано каким-то почти мистическим смыслом, и постичь Дао его написания способны лишь избранные гуру.
К счастью это не так. Не знаю, как обстоят дела с написанием драйверов под другие операционные системы, в т.ч. и наиболее популярные, но под linux, вне зависимости от аппаратной архитектуры драйвера пишутся очень просто. Для написания драйвера необходимы базовые знания языка си, представление о работе ОС линукс (базовые), понимание того, что мы хотим получить, желание чтения документации и исходных кодов, ну и усидчивость. Всё.
Вы хотите посмотреть как написать драйвер для своего устройства? Тогда ныряйте под кат!

Всем доброго дня!

После прочтения нескольких статей на хабре о пластиковых картах, POS терминалах и сопутствующих вещах, мне показалось, что эта тема довольно интересна сообществу. В данной небольшой публикации я хочу окончательно разобрать тему ввода PIN–кода на POS терминалах и ответить, наконец, в меру своих знаний, на вопрос: почему же в одних случаях требуется ввод PIN, а в других — нет?

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

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

Для визуализации информации решили использовать карту мира и разместить все отзывы прямо ней. Это показалось нам наиболее удобным для восприятия – если в одном городе несколько отзывов с разными оценками, то по ним выводится средний балл. И в целом сразу визуально видно, какие регионы наиболее комфортны для жизни.