Который раз в ваших опросах не учитывается в специализациях системное и встраиваемое программирование, почему так? Проходил этот опрос и пришлось пропустить этот пункт со специализацией, потому что по вашему списку меня вроде бы не существует. Хорошо, что возможность пропустить была, иначе бы вообще не проходил. И это при том, что Си в топе tiobe благодаря именно системщикам и эмбедеддам, да и на Хабре много статей от них. Хоть посмотреть сколько нас — было бы неплохо. :)
Я думаю, что в цену входят лицензии, так как продукт — медицинского назначения, плюс сама разработка. К тому же любой может купить необходимые комплектующие и собрать сам, доработать ПО при желании и возможности. Необязательно платить 300 долларов. Этим устройство и примечательно.
Дела при потере слуха обстоят куда сложнее, чем вы думаете. Усилителей недостаточно, нужна обработка звука, перевод частот звука из неслышимого диапазона в слышимый. Простое усиление звука — усугубляет проблемы со слухом.
Можно купить нормальные, но как уже сказано в статье — цена очень высока. Мои стоили 1300 евро, а надо 2. И то они мне не помогают на 100%. Менять рекомендуется раз в 4 года (срок службы). А тут 300 долларов. Кому-то и такой сойдет. Тем более речь идет про США, где особой гос поддержки в этом направлении нет, насколько я знаю.
К тому же основная цель — развивать устройство с помощью комьюнити. Я надеюсь, что у них что-то и выгорит. Но, как уже сказано в статье — могут упереться в чужие патенты.
Насчет root_overlay — дело вкуса, мне кажется. Конкретно против external_tree ничего против не имею, саму строчку в конфиге buildroot считаю лишней. Особенно потому, что она заменяется строчкой cp -frP <путь_к_external_tree> $1 в скрипте. Плюсы — можно держать несколько external_tree и гибко их менять. Так и использую.
Мне кажется, мы с Вами немного разные цели преследуем. У меня нет новичков, работаю в небольшой компании. А когда им был — скрипт для меня был понятнее :). Там и задокументировать все можно. А наработки у меня в своей системе сборки раскладываются в зависимости от платформы по соответствующим папкам в дереве проекта. Платформ несколько, и они отличаются. Мне проще в зависимости от платформы забрать свежие наработки из проекта, чем из проекта копировать в одно и то же место, создавая путаницу.
На мой взгляд, это удобнее и надежнее. Я пробовал оба варианта, скриптами процесс всякой подготовительной работы автоматизируется и переносится из одной версии buildroot в другой.
В папке board/<ваше_имя_к_конфигам> файлы можно располагать как угодно, в своем порядке, там же держится сам скрипт. В post-build можно не только заменить файлы, но и права назначить и всяческие проверки добавить, которые устанавливают файлы в зависимости от наличия тех, или иных пакетов в итоговой сборке.
Также можно с помощью средств шелла менять нужные строчки в дефолтных системных конфигах.
В комментарии выше я наврал — скрипту из buildroot передается target-fs, а не корневая директория, прошу прощения.
Ну и пример:
install -m 0644 $BOARD_DIR/inittab $1/etc/
Где: $BOARD_DIR — переменная билдрута. $1 — путь к target-fs, передается билдрутом в качестве аргумента скрипту.
Спасибо за статью. Сам хотел что-то подобное написать, но времени не нашлось. Вместо root_overlay, на мой взгляд, лучше наваять скрипт post_build.sh, в котором устанавливать нужные конфиги и файлы с нужными правами с помощью install в target-fs. В Buildroot есть пункты для pre-build, post-build скриптов, которым передает корневую директорию сборки в качестве аргумента.
Знаю автора лично. Не было отдельной клавиатуры, у него дома лишь ноутбуки. Как-то вот незачем она ему, он привык обходиться без нее. И такое бывает, да.
Для разработки под ARM не нужно компилировать конкретно на ARM машине. Просто используется компилятор под эту архитектуру. Это называется — кросс-компиляция. Собственно контроллер используется лишь для запуска ПО.
Я разрабатываю на ARM на обычной x86 машине под Debian в виртуалке. Не так давно, ради эксперимента, наши дотнетчики собрали .NetCore хелловорлд для ARM платки на своих виндовых машинах вообще почти ничего не зная про линукс и просто выбрав нужные пункты в студии.
По вашему, девушкам не могут нравится календари с девушками? Например, в нашем отделе календари от Ideco заходили на ура и у женского пола, а у Ideco куда более откровенные. Что поделать, если женщины тупо красивее и изящнее смотрятся на календарях, чем мужчины? :)
Встраиваемое программирование тоже, к сожалению. Мне кажется, что это из-за того, что в этих сферах реже меняют работу, а значит реже сидят в Моем Круге и проходят такие опросы.
По теме — мне 32 года. Пришел в разработку в возрасте 30 лет, в первую очередь из-за того, что отношение руководства в IT компаниях к специалистам в разработке в среднем по больнице куда лучше, чем отношение руководства на заводе к инженерам. Во-вторую очередь, мне это было интересно, иначе бы не вышло ничего. Ну и зарплаты куда лучше инженерных.
Не скажу, что это было легко и быстро. Все таки в 30 лет уже не так много свободного времени на учебу. Пять собеседований в разных компаниях. Полгода до этого собирался и готовился, два месяца поиска жил в стресс-режиме: решал задачи по ночам, подгонял навыки. На текущее место взяли больше из-за электротехнического образования (ну ты вольты от ампер наверное отличаешь, да? (с) ) и опыта поддержки кода промышленных контроллеров. Ну и софт-скиллз в мои 30+ лет в принципе уже нормальные. Очень многое пришлось подтягивать, вспоминать, читать, учиться. Еще повезло с крутым наставником, который физтех закончил еще до того, как я родился, и кодил на ассемблере, когда я еще не знал, что такое компьютеры.
Который раз в ваших опросах не учитывается в специализациях системное и встраиваемое программирование, почему так? Проходил этот опрос и пришлось пропустить этот пункт со специализацией, потому что по вашему списку меня вроде бы не существует. Хорошо, что возможность пропустить была, иначе бы вообще не проходил. И это при том, что Си в топе tiobe благодаря именно системщикам и эмбедеддам, да и на Хабре много статей от них. Хоть посмотреть сколько нас — было бы неплохо. :)
Я думаю, что в цену входят лицензии, так как продукт — медицинского назначения, плюс сама разработка. К тому же любой может купить необходимые комплектующие и собрать сам, доработать ПО при желании и возможности. Необязательно платить 300 долларов. Этим устройство и примечательно.
Можно купить нормальные, но как уже сказано в статье — цена очень высока. Мои стоили 1300 евро, а надо 2. И то они мне не помогают на 100%. Менять рекомендуется раз в 4 года (срок службы). А тут 300 долларов. Кому-то и такой сойдет. Тем более речь идет про США, где особой гос поддержки в этом направлении нет, насколько я знаю.
К тому же основная цель — развивать устройство с помощью комьюнити. Я надеюсь, что у них что-то и выгорит. Но, как уже сказано в статье — могут упереться в чужие патенты.
Насчет root_overlay — дело вкуса, мне кажется. Конкретно против external_tree ничего против не имею, саму строчку в конфиге buildroot считаю лишней. Особенно потому, что она заменяется строчкой cp -frP <путь_к_external_tree> $1 в скрипте. Плюсы — можно держать несколько external_tree и гибко их менять. Так и использую.
Мне кажется, мы с Вами немного разные цели преследуем. У меня нет новичков, работаю в небольшой компании. А когда им был — скрипт для меня был понятнее :). Там и задокументировать все можно. А наработки у меня в своей системе сборки раскладываются в зависимости от платформы по соответствующим папкам в дереве проекта. Платформ несколько, и они отличаются. Мне проще в зависимости от платформы забрать свежие наработки из проекта, чем из проекта копировать в одно и то же место, создавая путаницу.
В папке board/<ваше_имя_к_конфигам> файлы можно располагать как угодно, в своем порядке, там же держится сам скрипт. В post-build можно не только заменить файлы, но и права назначить и всяческие проверки добавить, которые устанавливают файлы в зависимости от наличия тех, или иных пакетов в итоговой сборке.
Также можно с помощью средств шелла менять нужные строчки в дефолтных системных конфигах.
В комментарии выше я наврал — скрипту из buildroot передается target-fs, а не корневая директория, прошу прощения.
Ну и пример:
Где: $BOARD_DIR — переменная билдрута. $1 — путь к target-fs, передается билдрутом в качестве аргумента скрипту.
Я разрабатываю на ARM на обычной x86 машине под Debian в виртуалке. Не так давно, ради эксперимента, наши дотнетчики собрали .NetCore хелловорлд для ARM платки на своих виндовых машинах вообще почти ничего не зная про линукс и просто выбрав нужные пункты в студии.
По теме — мне 32 года. Пришел в разработку в возрасте 30 лет, в первую очередь из-за того, что отношение руководства в IT компаниях к специалистам в разработке в среднем по больнице куда лучше, чем отношение руководства на заводе к инженерам. Во-вторую очередь, мне это было интересно, иначе бы не вышло ничего. Ну и зарплаты куда лучше инженерных.
Не скажу, что это было легко и быстро. Все таки в 30 лет уже не так много свободного времени на учебу. Пять собеседований в разных компаниях. Полгода до этого собирался и готовился, два месяца поиска жил в стресс-режиме: решал задачи по ночам, подгонял навыки. На текущее место взяли больше из-за электротехнического образования (ну ты вольты от ампер наверное отличаешь, да? (с) ) и опыта поддержки кода промышленных контроллеров. Ну и софт-скиллз в мои 30+ лет в принципе уже нормальные. Очень многое пришлось подтягивать, вспоминать, читать, учиться. Еще повезло с крутым наставником, который физтех закончил еще до того, как я родился, и кодил на ассемблере, когда я еще не знал, что такое компьютеры.