Зачем использовать коммерческие встроенные средства разработки Linux?

Имеет ли смысл использовать коммерческие инструменты разработки при разработке систем или устройств на базе встроенного Linux или Android?
В этой гостевой колонке Брэд Диксон, директор по решениям с открытым исходным кодом в Mentor Graphics, предлагает несколько причин, по которым коммерческие инструменты разработки и поддержка могут потенциально сэкономить время, ресурсы, деньги и альтернативные издержки.

Инструменты для разработки встроенного Linux: бесплатные или коммерческие?

Брэд Диксон, Mentor Graphics Corp.

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

Инструменты разработки с открытым исходным кодом обеспечивают надежную основу для разработчиков и быстро развиваются в течение последних 15 лет, обеспечивая мощный рост Linux, Android и большинства веб-технологий и облачных технологий.
Проект GNU , основанный и поддерживаемый Фондом свободного программного обеспечения (FSF), возможно, является одним из наиболее влиятельных проектов в движении за свободное программное обеспечение и сегодня стал краеугольным камнем, от которого зависят сотни миллионов строк кода.
Дедом инструментов GNU является почтенный GCC (Коллекция компиляторов GNU), который чаще всего, но не всегда, используется с GNU Binutils (компоновщик, ассемблер и другие инструменты) и GDB (GNU Project Debugger).

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

Некоторые преимущества проприетарных инструментов

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

Однако, прежде чем приступить к разработке какого-либо запатентованного набора инструментов, следует тщательно рассмотреть две общие области управления рисками:

  • Интеграционное управление рисками
    Почти все графики проектов, которые зависят от инструментов разработки с открытым исходным кодом, планируют потратить некоторое время, чтобы объединить отдельные технологии с открытым исходным кодом в согласованный рабочий процесс разработчика.
    Для проектов встроенного программного обеспечения это обычно включает подготовку кросс-компиляции и средств отладки, а также интеграцию с IDE, такой как Eclipse, Emacs или vi.
    Хотя доступность этих вспомогательных технологий на первый взгляд может показаться полезной, руководители часто ошибочно принимают идею о том, что механизм «сборки из источника» снижает риск интеграции.

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

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

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

    В дополнение к большому объему кода проекты сообщества также могут быстро меняться.
    Рассмотрим только одну центральную технологию, такую ​​как коллекция компиляторов GNU.
    Десять лет назад коллекция компиляторов GNU содержала всего около двух миллионов строк кода.
    За последние десять лет в проект GNU ежегодно добавлялось в среднем 300 000 строк кода.
    Добавьте в обычные модификации и оборачиваемость кодовой базы ошеломляет.

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

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

А как насчет коммерческих инструментов?

Менеджеры, которые поддерживают использование инструментов разработки с открытым исходным кодом, могут воспользоваться многочисленными преимуществами, обратившись к коммерческому продукту инструментов разработки, такому как Mentor Embedded Sourcery CodeBench, от Mentor Graphics, который показан ниже.


Пример: Mentor Embedded Sourcery CodeBench

(щелкните изображение, чтобы увеличить)

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

Когда свободное программное обеспечение совсем не бесплатно

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

Внезапно команда сталкивается с ошибкой компилятора, которая останавливает команду на неделю.
Примерно через день пять разработчиков переходят к другим задачам, но ведущий разработчик тратит неделю на диагностику и устранение проблемы.
Бросить ежедневные встречи со старшим менеджером и всей командой на этот критический дефект позднего цикла - теперь тратить драгоценное время и деньги.
Компания могла бы с легкостью тратить 25 000 долл. Времени, выделяемого ведущим разработчиком на ежегодной основе, создавая, поддерживая и исправляя инструменты, когда внешний коммерческий поток инструментов, даже при минимальных затратах (скажем, 5000 долл. США), в конечном итоге был бы более разумным.
Коммерческий вариант будет стоить не только дешевле, но также будет рассмотрена потенциальная упущенная рыночная возможность.

И ответ ...

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

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

Об авторе: Брэд Диксон, директор по решениям с открытым исходным кодом в Mentor Graphics, отвечает за инструменты для разработчиков с открытым исходным кодом и Linux.
С 2000 года Брэд работает в области открытого программного обеспечения и встроенного программного обеспечения в качестве разработчика, FAE и менеджера по продукту.