Сам Линус Торвальдс под законом Линуса имеет в виду свои размышления о причинах развития человеческого общества, которые он изначально опубликовал в автобиографии Just for Fun. В предисловии к книге Химанена «Хакерская этика» (The Hacker Ethic), Торвальдс предложил более короткую формулировку закона:

Закон Линуса гласит, что все наши мотивации можно разделить на три основные категории. И что более важно, прогресс означает прохождение через те же три категории, как «фазы» в процессе эволюции, то есть перемещение из категории в следующую категорию. Эти категории, по порядку — «выживание», «социальная жизнь» и «развлечение».

Такой вариант закона Линуса похож на пирамиду потребностей по Маслоу, который можна сформулировать так:

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

Также Торвальдс, в одном из своих сообщений в список рассылки GNOME, написал, что «закон Линуса» — «не следует писать, что у вашей программы есть какая-то опция, если её невозможно изменить через пользовательский интерфейс».

И еще одно извесное его выражение: «Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.»

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

Разрыв в диаграммах сделан потому, что формулировка вопроса, который задавался разработчикам, изменялась. До 2005-го года вопрос звучал как «Какие именно языки из ниже приведённых вы использовали на протяжении последних 12-ти месяцев для разработки ПО для встраиваемых систем», а в 2005-м году формулировка изменилась на «Мои последние embedded проекты написаны на ____». До 2005-го года вопрос предусматривал возможность нескольких ответов, то есть предусматривалось, что респонденты могли сделать выбор двух и более языков.

Наибольшее влияние наявности выбора одного и более вариантов ответа можно проследить по статистике использования ассемблера. До 2005-го года мы можем видеть уровень порядка 62%, что выглядит, по меньшей мере, странно. Объяснение довольно простое: большинство проектов требуют незначительных вставок ассемблерного кода.

После 2005-го года всё стало на свои места: уровень ассемблера упал до 8% в 2005-м году и до 5% в 2009-м.

Если же вернуться к нашей сегодняшней теме – языку С, то мы можем наблюдать его доминирование на протяжении всех 13-ти лет. Также интересно отметить тенденцию к росту использования С за счёт ассемблера и С++.

Также нельзя не обратить внимание на статистику использования С++, который набирал популярность с конца 90-х годов с пиком в 2001-м, и медленное падение его доли в дальнейшем.

Суть в том, что разработчики встраиваемых систем не собираются отказываться от использования С в своих проектах. И на то есть несколько причин. Во-первых, это наявность компиляторов для подавляющего большинства 8-ми, 16-ти и 32х разрядных процессоров. Во-вторых, С предусматривает идеальное сочетание средств для работы как на низком, так и на высоком уровне, что делает его идеальной кандидатурой, для написания, например, драйверов. Даже в будущем, когда язык С будет терять его популярность, его знание всё равно будет цениться…

Конечно, язык С не сможет выжить, если количество людей, которые его используют будет сокращаться. На данный момент происходит противоположное явление. Около 98% процессоров, которые производяться ежегодно – это процессоры для встраиваемых систем. А ежегодное производство процессоров имеет долгосрочную тенденцию к росту.

На этой диаграмме отображена зависимость объема производства процессоров от индекса NASDAQ.

Во-первых, очень интересна зависимость сама по себе, а также то, что за последние 15 лет производство выросло более чем в два раза.

Отдельно стоит остановиться на том, что сейчас есть тенденция к тому, что в ВУЗах всё меньше уделяется внимания языку С и всё чаще программисты изучают язык С уже на работе. Эта тенденция менее актуальна для постсоветского пространства, и более актуальна для ВУЗов США и Европы, но, тем не менее, рано или поздно это может стать прорехой в системе образования.

В заключение, можно сказать «С умер, да здравствует С!». Иными словами, этот язык, хоть и практически перестал использоваться для написания прикладного ПО для х86/х64 процессоров, но это с лихвой компенсировано использованием его при разработке ПО встраиваемых систем, доля которых продолжает активно расти.

По мотивам: www.embedded.com

Почему столько лет Xilinx не лицензировала архитектуру процессоров ARM как делали многие её конкуренты? Ответ, скорее всего заключается в разработке спецификации шины AMBA следующего поколения, которую Xilinx называет “оптимизированный стандарт шины для FPGA.”  В компании Xilinx, понимали, что без новой шины, они не смогут выжать весь потенциал из архитектуры ARM. Использование ядра Cortex позволит также решить для Xilinx проблему высокого энергопотребления FPGA.

По понятным причинам, Xilinx не разглашает какое именно ядро будет использовано в их FPGA, и даже в каком ядре может появиться лицензированное ядро: в мейнстрим продукте Spartan или в топ линейке Virtex.

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

Стоит заметить, что Xilinx и ARM не единственные компании, которые задействованы в разработке грядущей спецификации AMBA, также в нее вовлечены такие титаны индустрии как Cadence, Denali, Mentor Graphics и Synopsys.

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

Большинство кода для встроенных систем имеют стоимость около $20-40  за строчку кода (расценки для американского рынка) . Об этом можно прочитать в статье David A. Wheeler “More Than a Gigabuck: Estimating GNU/Linux’s Size“.  Формальное же, математическое, доказательство отсутствия ошибок в коде может поднять стоимость до $700 за строчку

Для микроядра Secure Embedded L4, состоящего из 7,500 строчек С кода, было математически доказано отсутствие ошибок с использованием 10,000 промежуточных теорем в более чем 200,000 строчек формального доказательства. Это доказательство было проверено на компьютере, с помощью интерактивной программы доказательства теорем Isabelle.

“Proving the correctness of 7,500 lines of C code in an operating system’s kernel is a unique achievement, which should eventually lead to software that meets currently unimaginable standards of reliability.”

Посчитать количесвто строчек кода нет так просто, а тем кто хочет это сделать, могу посоветовать почитать статью на Википедии “Количество строк кода“. А для операционной системы Линукс существует замечательная утилита SLOCCount.

Для написания програм используеться библиотека mbed C/C++, которая основана на ARM Cortex Microcontroller Software Interface Standard (CMSIS) и предоставляет высокоуровневый подход к конфигурации микроконтроллера на основе API.

Сайт Mbed.org в настоящее время уже доступен. На нем можно получить дополнительную информацию и оформить предварительный заказ  на отладочную плату mbed на основе микроконтроллера NXP LPC1768. Стоимость платы при преварительном заказе составляет около $60.

sometimes I believe compiler ignores all my comment

Dear maintainer:
Once you are done trying to ‘optimize’ this routine,
and have realized what a terrible mistake that was,
please increment the following counter as a warning
to the next guy:
total_hours_wasted_here = 16

drunk, fix later

Magic. Do not touch.

When I wrote this, only God and I understood what
I was doing. Now, God only knows

I’m sorry.

You are not meant to understand this

I am not sure why this works
but it fixes the problem

I am not sure if we need this,
but too scared to delete

Dear future me. Please forgive me

I can’t even begin to express how sorry I am

I am not responsible of this code

They made me write it, against my will

I have to find a better job

If you’re reading this, that means you have been
put in charge of my previous project
I am so, so sorry for you. God speed

TODO: Fix this.  Fix what?

Mr. Compiler, please do not read this

if i ever see this again i’m going
to start bringing guns to work

This comment is self explanatory.

this comment included for the benefit of
anyone grepping for swearwords: shit.

NOT FIT FOR HUMAN CONSUMPTION

Houston, we have a problem

This code was written by a genius so don’t
try to understand it with your tiny little brain.

If I from the future read this
I’ll back in time and kill myself.

If you are reading this,
please place a checkmark here [  ]

My lawyer told me not to reveal

no comments for you
it was hard to write so it should be hard to read

I’m sorry, but our princess is in another castle.
but the “real” solution is much more complicated

Honest this works

HACK ! COPY/PASTE this and look for another job

I wish (boss name) could do this by him self

Sorry dirty code

This condition can’t happen. Call the police or something

why the f*** we have to move this here to make it work

Do not continue reading if you dont want to die

*** AAAAAHAHAHAH!!  What is this??

Приведу пример. Нажатие кнопки устанавливает единицу в восьмом бите регистра REG1. Этот регистр отображен в память по адресу 0×02140040. Допустим, что для упрощения работы вы решили использовать макрос, который указывает на эту область памяти:

[cc lang="c" tab_size="2" lines="40"]
#define REG1(*( int32_t *) 0×02140040)
[/cc]

Тогда организация ожидания нажатия кнопки будет выглядеть таким образом:

[cc lang="c" tab_size="2" lines="40"]
while ((REG1 & 0х100) == 0);
[/cc]

При оптимизации компилятор может предположить, что в теле цикла значение REG1 не меняется и, следовательно, незачем постоянно проверять условие. Вот что из этого может получиться:

[cc lang="c" tab_size="2" lines="40"]
while ((REG1 & 0х100) == 0) for (;;);
[/cc]

Об этой и других проблемах, которые могут возникнуть читайте в статье Dan Saks Use volatile judiciously. В ней описаны возможные ошибки при включенной оптимизации и методы их решения.

До появления модификатора volatile программистам приходилось помещать код драйвера в отдельный файл, компилировать его без оптимизации и потом компилировать все остальные файлы с включенной оптимизацией. Некоторые компиляторы имели возможность использования pragma, что позволяло отключить оптимизацию для части кода. С появлением модификатора volatile, появилась возможность отключать оптимизацию только для необходимых объектов.

Если вам интересно, тогда прочитайте статью Nigel Jones Introduction to the Volatile Keyword.  Там простыми словами описан синтаксис и случаи применения модификатора volatile, с примерами ошибок при работе с регистрами периферийных устройств, обработчиками прерываний и много-потоковыми программами.

Интересная заметка Ian Lance Taylor об использовании модификатора volatile в языке програмирования С. Правда в ней опускается метод использования volatile для много-потоковых программ, поэтому в догонку статья Andrei Alexandrescu - volatile – Multithreaded Programmer’s Best Friend.

Разобравшись с использованием volatile ознакомьтесь со статьей Dan Saks Place volatile accurately, где описана проблема с которой вы можете столкнуться используя указатели на регистры отображенные в память.

Юзабилити означает что люди, которые используют продукт, могут легко и быстро выполнить собственные задачи. Это определение основывается на четырех принципах: (1) юзабилити означает концентрирование на пользователях; (2) люди используют продукт для повышения продуктивности; (3) пользователи являются занятыми людьми, которые пытаются выполнить свои задачи; (4) пользователи принимают решение о простоте использования продукта. – Janice (Ginny) Redish and Joseph Dumas, A Practical Guide to Usability Testing, 1999, p. 4

После всего, юзабилити просто обеспечивает хорошую работу продукта и заботится о том, чтобы человек со средними (или даже ниже среднего) возможностями и опытом мог использовать продукт – будет это вэб-сайт, реактивный самолет или дверь – по назначению и без отчаянного разочарования. – Steve Krug, Don’t Make Me Think, 2000, p. 5

Юзабилити начинается с философии – веры в то, что дизайн соответствует желаниям пользователя и ориентирован на создание идеального user experience – но это отдельный процесс и методология, которая приводит к достижению действительной цели юзабилити. Новый процесс создания юзабилити продукта начинается с определения того, кто будет использовать продукт, понимание их целей и желаний, и выбор правильной техники для ответа на вопрос: “Насколько хорошо наш продукт соответствует юзабилити требованиям для наших пользователей?” – Whitney Quesenbery.

Важно понимать, что юзабилити это не простое, одномерное свойство пользовательского интерфейса. Юзабилити имеет множество компонент и традиционно ассоциируется с пятью свойствами: обучаемостью, эффективностью, достопамятностью, погрешностью, удовлетворенностью. – Jakob Nielsen, Usability Engineering, 1993, p. 26.

Юзабилити – измеряемая характеристика, которая присутствует в большей или меньшей степени, и описывает эффективность пользовательского взаимодействия с продуктом. Также можно предположить что это как легко научиться продукту и как легко его использовать. – Jeff Axup, UserDesign.

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

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

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

Юзабилити это качественное свойство, которое определяется тем, насколько легко использовать пользовательский интерфейс. Слово “юзабилити” также относиться к методам улучшения простоты использования, которые качественное применяются в процессе создания продукта. Usability 101: Introduction to Usability.

Юзабилити означает создание продуктов и систем, более простых в использовании, и более тесное соответствие с необходимостями и требованиями пользователя. Usability Net.

Юзабилити это подход к разработке продукта, который включает прямую связь с пользователем во время цикла разработки для сокращения стоимости и создания продуктов и инструментов, которые отвечают требованиям пользователя. What is Usability?