При наличие SPI NOR, просто удобнее, в особенности если вы экспериментируете с двумя разными системами. Один загрузчик можно разместить на SPI NOR, другой на microSD карте. Спасибо за вопрос, @NutsUnderline подробно объяснил.
Допустим даже что текст не перевод и не компиляция.
Что значит допустим? Вы шо Еврей? Материал 500% авторский, мой. Полный список литературы могу отправить. На Хабре публикую сокращенный, потому что до этого модераторы Хабра говорили, что у меня очень много ссылок в посте. Поэтому ссылки на второстепенные источники режу.
Далее, "попробуй использовать Orange PI 5 Plus дальше запуска рабочего стола.". Нужно понимать что это первая водная статья. Тематика аппаратной виртуализации и программирование с использованием NPU, работа UEFI, вам подходит? Так, не все сразу.
Я же написал, предложите свои темы для рассмотрения, не вопрос. Если тема действительно окажется интересной и полезной для аудитории, то от меня благодарность и респект.
ссылки на Google Drive с которого не скачать из-за превышения лимита скачиваний
Я всегда качаю через VPN, никогда не было проблем. Если есть какие либо проблемы, могу без проблем продублировать на MEGA.NZ, там у меня большой лимит, надеюсь его хватит.
Я так понял у вас в наличие такая же плата Orange PI 5 Plus. Попробуйте вариант Joshua Riek дистрибутива как в этом после.
Кстати, как игрок заметил еще в варианте Joshua Riek небольшой лаг между движением мыши и указателя на экране. Он ничтожный, буквально наверное микросекунды, но он есть. Вначале замечаешь, но потом привыкаешь.
Но самое интересное, этого лага нет на этой же плате в варианте Windows 11. Пока как говорится без комментариев, детально тему не исследовал.
Вы же верно написали) К процессорам десятилетней давности, идет речь про low и middle сегмент по производительности ПК. Ок, говорим про low сегмент. т.е. сейчас ARM можно сказать нацеливается на low сегмент мини-ПК замещения x86 процессоров.
Half-Life 2 до последнего обновления на самом деле неплохо шел. Но после обновления в Steam, прям заметно стал тормозить. Визуально оценивать скорость игры сложно. Хотелось бы видеть в кадре значение fps. Оверлеи в Steam не работают. Сторонние средства, для Intel и NVIDIA игр, для так сказать нашего случая не нашел, может быть в курсе есть ли возможность отобразить fps в играх, раз вы так в этом хорошо разбираетесь?
На non-X86 SBC тоже может быть 40-pin GPIO, только есть нюанс. Два варианта рассмотрено в этом посте, текст начинается со слов "Еще один подвох одноплатных компьютеров на x86 процессорах заключается в управление GPIO ..."
Это вы зря "но можно не читать", для понимания ситуации лучше прочитать, но не претендую на истину в последней инстанции. Возможно я недостаточно акцентировал внимание именно на тренде изменений. То что было раньше 10 лет назад и сейчас, это просто день и ночь. За это время много что изменилось. Например, раньше Qualcomm тоже смеялась на MTK, но текущие продажи говорят что это MTK тогда нужно было смеяться.
Суть такова, что китайцы прут как не в себя. Это жесткая экономическая и информационная экспансия. Да, пока есть отставание и софт не допилен, но они однако уже дышат в спину.
И почему мне это интересно, я хочу получить мини-ПК в форм факторе телефона, с экраном и всеми плюшками, который будет в два раза толще обычного, с наличием контактов GPIO для программирования, с UEFI и запуском Android, Linux, Windows. Так сказать начать настоящую эру пост-ПК.
Кстати, хороший критерий оценки поста вы подали, по наличию комментариев и добавлений в закладки, отличная идея для написания своего расширения браузера.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "wonky HAL libraries", потому что специалист должен выражаться максимально технически грамотно. В противном случае, пусть пишет прозу, там это пожалуйста. Что такое HAL?
Hardware Abstraction Layer (HAL, Слой аппаратных абстракций) — слой абстрагирования, реализованный в программном обеспечении, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, запускаемом на этом компьютере. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части ядраоперационной системы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при её запуске на системах с различным аппаратным обеспечением. Источник wiki.
Самое простое понимание, упрощенно, HAL это драйвера, это не какая то отдельная библиотека для всех компьютеров.
Короче говоря, автор не смог написать правильно, и итоге получился проводник который бегал по проводам.
Суть следующая, автор говорит что ему сложно и неудобно работать с уровнем HAL на МК потому что, это достаточно низкий уровень управления устройства. т.е. wonky необходимо понимать в контексте СЛОЖНОСТИ ПРОГРАММИРОВАНИЯ, а не дословного перевода. Необходима высокая техническая база для написания просто элементарного кода.
Далее, следующий проводник бегающий по проводам это "Linux API гораздо надёжнее и стандартизированнее". Никакого абстрактного "стандарта Linux API" в понимание RFC не существует, есть конкретные стандарты, мало того от версии к версии ядра этот API постоянно меняется. Именно поэтому на OPi4LTS в версии ядра Linux 5.10, Wi-Fi на 5 ГГц работает, а в версии 6.X нет. Но тогда про что идет речь? Речь идет о стандарте подхода программирования используя API, это разные вещи. Если смотреть как вы перевели, то API само по себе как субъект не может быть надежным или нет, понятие надежности применимо к работающим информационным системам, но не как API.
В данном случае, автор под понятием "Linux API гораздо надёжнее и стандартизированнее", подразумевает не наличие некого стандарта так такового, а стандарта подхода программирования на примере символьных устройств, например, ваш текст "то мы сможем удобно отображать все эти устройства", как раз таки об этом и говорит. Просто читателю непонятно, где и как отображать эти устройства и вообще про что идет речь.
Программный код написания USB устройств между разными МК крайне сложно перенести. В случае использования Linux API, код можно переносить практически без изменений, потому что есть возможность использовать более высокий уровень абстракции. В своих постах я писал про nanoFramework и microFramework. В частности в microFramework я сделал конвертор USB устройства Microsoft Xbox 360 Controller Gamepad в HID-устройство клавиатура. Это было сделать не сложно, потому что использовался высокий уровень абстракции на базе платформы .NET.
Вот что я хотел до вас донести, в случае "сложных" технических постов делайте техническую экспертизу.
P.S. С литературной точки зрения, вы все равно неправильно перевели "wonky HAL libraries" дословно переводится не как "пользоваться неуклюжими библиотеками HAL", а "шаткие библиотеки HAL". Ключевое слово шаткий, запомните, английский язык это функциональный язык. Шаткий это функция, означающая перемены, изменчивость. На русский язык, так напрямую переводить нельзя, потому что получается хрень.
т.е. автор говорит что в случае использования МК эти библиотеки HAL каждый раз будут другими от перехода от одного МК к другому, этим он и говорит что для него HAL библиотеки и неудобны.
В русском язык слово шаткий, скорее всего читатель воспримет в контексте неустойчивости, что-то не прочное. Например, шаткие доводы, как говорит Толковый словарь Ожегова. Именно поэтому такое нельзя переводить дословно, и как вы перевели. А нужно писать нормальное технические разъяснение.
P.S.S это наверное тот случай, когда в комментариях более понятно, чем в посте.
При всем к вам уважении, ваш ответ эквивалентен выражению из анекдота, "это не дерьмо, а засахарилась". То что вы пишите, это показатель вашего отношения к аудитории, и вашего профессионализма. Говорить "пипл и так схавает", не вызывает никакого уважения. Существует такое понятие как профессиональная этика. Любой нормальный специалист никогда не позволит писать подобную дичь, именно так.
Да все мы люди, и ошибки допускаем. Но писать "неуклюжими библиотеками HAL", технически безграмотно, я не поверю что у вас, как минимум в штате, нет специалистов разбирающихся в архитектуре ОС и Linux. Мое предложение следующее, прежде чем взяться за пост, определяйте его маршрут.
Маршрут №1. Пост пишет автор на тему, в которой сам разбирается и готов как минимум ответить на 80% всех вопросов по данному посту (идеальный вариант).
Маршрут №2. Человек делает предварительную выборку интересных тем для переводов. Затем эта выборка передается специалистам для краткого анализа и исключения полной хрени еще до стадии перевода, помним правило информатики GIGO (Garbage in, garbage out). Далее, перевод желательно человеком, хоть отдаленно понимающий про что идет речь в оригинальном посте. Далее, профильный специалист из результата перевода вычищает дичь в стиле "неуклюжими библиотеками HAL".
Мне особо и помнить не надо). Напротив меня в книжную полку вставлена книга Стандарты и спецификация USB, толщина заметно больше Библии, скажу более, это одна из самых толстых моих книг. Но это не избавляет, хотя бы кратко технически грамотно описать предмет рассмотрения. Не буду первооткрывателем, тему можно разбить на два поста, первый стандарт и теория, второй практика. И основная моя претензия заключается в низком качестве исходного материала. Автору исходника претензий нет, он так чувствует, имеет на это право, а вот к переводчику есть. У меня есть пост Безопасность встраиваемых систем Linux. Тема безопасности знаете тоже не маленькая, но все же я считаю, что смог донести основную идею и концепцию исходного поста, Introduction to Embedded Linux Security. Я не занимался тупой копи-пастой, материал был не только переведен, а еще существенно изменен и дополнен, там, где требовалось пояснение. Потому что исходный пост рассчитан на западного читателя, специалиста по информационной безопасности.
В итоге: качественный исходный материал + качественная переработка + хорошая адаптация = дала хороший материал, который самому интересно почитать и другим не стыдно показать.
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Кроме того, я воспринимаю Linux как слой HAL. Если на микроконтроллере можно запустить Linux, то мы сможем удобно отображать все эти устройства, нам не придётся пользоваться неуклюжими библиотеками HAL и так далее.
Вот это попробуйте перевести на нормальный человеческий язык.
Об этом и идет речь, что тип устройства необходимо было озвучить в заголовке или как минимум в аннотации. Далее хотя бы немного написать про классы устройств USB, и немного описать тип CDC, вот тогда пост был бы годным. А так +1 в копилку критикам корпоративных блогов, что публикуют материал низкого качества.
Это гарантирует, что наша плата Nucleo будет вести себя с точки зрения хоста как устройство последовательного порта (CDC). Благодаря этому хост сможет настроить подходящие драйверы для работы с нашим собственным устройством.
Ну и какие драйвера нам потребуются для Windows и Linux, какой все же тип устройства был реализован согласно стандарту USB?
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Кроме того, я воспринимаю Linux как слой HAL. Если на микроконтроллере можно запустить Linux, то мы сможем удобно отображать все эти устройства, нам не придётся пользоваться неуклюжими библиотеками HAL и так далее.
Вот это попробуйте перевести на нормальный человеческий язык.
Первое, если вы такой опупеный спец, и не врете, то тогда приведите конкретные ссылки на коммиты в проект Armbian и rocknix. Это не ваши собственные личные проекты. И ваш вклад в них непонятен, как и ваша квалификация.
Второе, все тесты и замеры в посте абсолютно корректны. Любой может выполнить их и получить те же результаты.
Третье, прочитайте пост.
Четвертое, если все же прочитали пост, то тогда вы в программном обеспечение разбираетесь как я в балете, т.е. совсем никак.
Плата на процессоре N100 взялась как эквивалент по стоимости и возможностям Orange PI 5 Plus. Собственно тема поста такая, взять решение на ARM и за такую же стоимость попытаться сравнить с x86, сделать это максимально соотносимо.
бессмысленность утверждения о преимуществе N100 в 2.6 раза.
бессмысленно ваше бытие на этой земле. У меня в посте написано "веб-браузер на Intel N100 работает в 2.6 раза быстрее." Это говорит о том, что для рендера данной страницы Хабра, устройству на Intel N100 потребуется приблизительно в 2.6 раза меньше времени, чем Orange PI 5 Plus. И не надо придумывать всякую чушь. Доказательства есть в посте, надеюсь, вы это в состояние понять.
Пятое, наличие работы OpenGL проверяется командой: glxinfo | grep rendering
Если в ответе есть: direct rendering: Yes. Значит все OK. Это легко проверяется в гуле, надеюсь вас там не забанили.
Но правда и тут есть нюанс, если в ответе будет "OpenGL renderer string: Software Rasterizer". Тогда да, используется программный рендер.
OpenGL и Vulkan. Не буду повторяться, рыбки это тест OpenGL, Vulkan проверялся играми из Steam.
Все это работает, и весьма неплохо, в тот же Left 4 Dead 2 можно в принципе нормально поиграть.
Если вы продолжаете утверждать, что не используется аппаратный рендер OpenGL и Vulkan, то это уже не ко мне, а к специалистам в белых халатах.
Седьмое, особенно забавно звучит ваш ответ на вопрос "как включить аппаратное ускорение графики", да просто возьми другой дистрибутив с другим ядром и драйверами. Неа, не надо уходить от ответа, конкретно напишите, как мне "включить правильное аппаратное ускорение" для образа который я использовал. Ежику понятно, что другой дистрибутив и другое ядро Linux даст другие результаты. Вы докажите, что в вашем примере fps в тесте с рыбками и играми из Steam будет выше.
Вы там заявили "Этими моими наработками активно пользуется", отлично, докажите на конкретном примере.
Возьмите любую плату на Rockchip из списка поддерживаемых Joshua-Riek/ubuntu-rockchip, коих предостаточно. Запустите на этой плате сборку Joshua-Riek/ubuntu-rockchip без дополнительных библиотек и патчей, т.е. "as-is". Выполните тесты, которые указаны в этом посте. Затем возьмите волшебный Armbian, установите, как вы считаете правильно аппаратное ускорение, выполните те же самые тесты. И по итогу напишите пост как все надо делать. И если результаты fps в играх будут кратно выше, а не пределах колебания погрешности, то я лично готов вам мужественно пожать руку.
Затем я ваш пост переведу на английский язык и отправлю Joshua-Riek и скажу ему, что он ничего не понимает в так называемом аппаратном ускорение и водит общественность в заблуждение.
У вас в профиле написано "Инженер", я не считаю себя инженером, но меня учили инженерному делу. Так вот, настоящие инженеры мне говорили "практика критерий истины", на словах мы все тут великие, могучие, и выше туч. Я свое слово сказал, тесты выполнил, теперь очередь за вами, докажите свою правоту на практике, напишите пост.
При наличие SPI NOR, просто удобнее, в особенности если вы экспериментируете с двумя разными системами. Один загрузчик можно разместить на SPI NOR, другой на microSD карте. Спасибо за вопрос, @NutsUnderline подробно объяснил.
Просто экономят китайцы, что тут сказать. Мне тоже не нравится отсутствие поддержки PD на SBC.
Что значит допустим? Вы шо Еврей? Материал 500% авторский, мой. Полный список литературы могу отправить. На Хабре публикую сокращенный, потому что до этого модераторы Хабра говорили, что у меня очень много ссылок в посте. Поэтому ссылки на второстепенные источники режу.
Далее, "попробуй использовать Orange PI 5 Plus дальше запуска рабочего стола.". Нужно понимать что это первая водная статья. Тематика аппаратной виртуализации и программирование с использованием NPU, работа UEFI, вам подходит? Так, не все сразу.
Я же написал, предложите свои темы для рассмотрения, не вопрос. Если тема действительно окажется интересной и полезной для аудитории, то от меня благодарность и респект.
Я всегда качаю через VPN, никогда не было проблем. Если есть какие либо проблемы, могу без проблем продублировать на MEGA.NZ, там у меня большой лимит, надеюсь его хватит.
Я так понял у вас в наличие такая же плата Orange PI 5 Plus. Попробуйте вариант Joshua Riek дистрибутива как в этом после.
Кстати, как игрок заметил еще в варианте Joshua Riek небольшой лаг между движением мыши и указателя на экране. Он ничтожный, буквально наверное микросекунды, но он есть. Вначале замечаешь, но потом привыкаешь.
Но самое интересное, этого лага нет на этой же плате в варианте Windows 11. Пока как говорится без комментариев, детально тему не исследовал.
Вы же верно написали) К процессорам десятилетней давности, идет речь про low и middle сегмент по производительности ПК. Ок, говорим про low сегмент. т.е. сейчас ARM можно сказать нацеливается на low сегмент мини-ПК замещения x86 процессоров.
Half-Life 2 до последнего обновления на самом деле неплохо шел. Но после обновления в Steam, прям заметно стал тормозить. Визуально оценивать скорость игры сложно. Хотелось бы видеть в кадре значение fps. Оверлеи в Steam не работают. Сторонние средства, для Intel и NVIDIA игр, для так сказать нашего случая не нашел, может быть в курсе есть ли возможность отобразить fps в играх, раз вы так в этом хорошо разбираетесь?
Версия браузера не указана
Нормальные люди за предъяву "автор не разобрался, как включить аппаратное ускорение графики" после,
Вообще то извиняются, потому что ответь за свой базар не могут. Другое ядро, другой дистрибутив, другая история.
И еще напоминаю в преамбуле написано:
Весь смысл поста в отсутствие как таковых допилок и доделок, т.е. берется как есть. Если вы это не понимаете, то тогда вам к санитарам.
На non-X86 SBC тоже может быть 40-pin GPIO, только есть нюанс. Два варианта рассмотрено в этом посте, текст начинается со слов "Еще один подвох одноплатных компьютеров на x86 процессорах заключается в управление GPIO ..."
Это вы зря "но можно не читать", для понимания ситуации лучше прочитать, но не претендую на истину в последней инстанции. Возможно я недостаточно акцентировал внимание именно на тренде изменений. То что было раньше 10 лет назад и сейчас, это просто день и ночь. За это время много что изменилось. Например, раньше Qualcomm тоже смеялась на MTK, но текущие продажи говорят что это MTK тогда нужно было смеяться.
Суть такова, что китайцы прут как не в себя. Это жесткая экономическая и информационная экспансия. Да, пока есть отставание и софт не допилен, но они однако уже дышат в спину.
И почему мне это интересно, я хочу получить мини-ПК в форм факторе телефона, с экраном и всеми плюшками, который будет в два раза толще обычного, с наличием контактов GPIO для программирования, с UEFI и запуском Android, Linux, Windows. Так сказать начать настоящую эру пост-ПК.
Технически PXE в текущей версии EDKII доступен, но практически не проверял
Кстати, хороший критерий оценки поста вы подали, по наличию комментариев и добавлений в закладки, отличная идея для написания своего расширения браузера.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "wonky HAL libraries", потому что специалист должен выражаться максимально технически грамотно. В противном случае, пусть пишет прозу, там это пожалуйста. Что такое HAL?
Hardware Abstraction Layer (HAL, Слой аппаратных абстракций) — слой абстрагирования, реализованный в программном обеспечении, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, запускаемом на этом компьютере. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части ядра операционной системы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при её запуске на системах с различным аппаратным обеспечением. Источник wiki.
Самое простое понимание, упрощенно, HAL это драйвера, это не какая то отдельная библиотека для всех компьютеров.
Короче говоря, автор не смог написать правильно, и итоге получился проводник который бегал по проводам.
Суть следующая, автор говорит что ему сложно и неудобно работать с уровнем HAL на МК потому что, это достаточно низкий уровень управления устройства. т.е. wonky необходимо понимать в контексте СЛОЖНОСТИ ПРОГРАММИРОВАНИЯ, а не дословного перевода. Необходима высокая техническая база для написания просто элементарного кода.
Далее, следующий проводник бегающий по проводам это "Linux API гораздо надёжнее и стандартизированнее". Никакого абстрактного "стандарта Linux API" в понимание RFC не существует, есть конкретные стандарты, мало того от версии к версии ядра этот API постоянно меняется. Именно поэтому на OPi4LTS в версии ядра Linux 5.10, Wi-Fi на 5 ГГц работает, а в версии 6.X нет. Но тогда про что идет речь? Речь идет о стандарте подхода программирования используя API, это разные вещи. Если смотреть как вы перевели, то API само по себе как субъект не может быть надежным или нет, понятие надежности применимо к работающим информационным системам, но не как API.
В данном случае, автор под понятием "Linux API гораздо надёжнее и стандартизированнее", подразумевает не наличие некого стандарта так такового, а стандарта подхода программирования на примере символьных устройств, например, ваш текст "то мы сможем удобно отображать все эти устройства", как раз таки об этом и говорит. Просто читателю непонятно, где и как отображать эти устройства и вообще про что идет речь.
Программный код написания USB устройств между разными МК крайне сложно перенести. В случае использования Linux API, код можно переносить практически без изменений, потому что есть возможность использовать более высокий уровень абстракции. В своих постах я писал про nanoFramework и microFramework. В частности в microFramework я сделал конвертор USB устройства Microsoft Xbox 360 Controller Gamepad в HID-устройство клавиатура. Это было сделать не сложно, потому что использовался высокий уровень абстракции на базе платформы .NET.
Вот что я хотел до вас донести, в случае "сложных" технических постов делайте техническую экспертизу.
P.S. С литературной точки зрения, вы все равно неправильно перевели "wonky HAL libraries" дословно переводится не как "пользоваться неуклюжими библиотеками HAL", а "шаткие библиотеки HAL". Ключевое слово шаткий, запомните, английский язык это функциональный язык. Шаткий это функция, означающая перемены, изменчивость. На русский язык, так напрямую переводить нельзя, потому что получается хрень.
т.е. автор говорит что в случае использования МК эти библиотеки HAL каждый раз будут другими от перехода от одного МК к другому, этим он и говорит что для него HAL библиотеки и неудобны.
В русском язык слово шаткий, скорее всего читатель воспримет в контексте неустойчивости, что-то не прочное. Например, шаткие доводы, как говорит Толковый словарь Ожегова. Именно поэтому такое нельзя переводить дословно, и как вы перевели. А нужно писать нормальное технические разъяснение.
P.S.S это наверное тот случай, когда в комментариях более понятно, чем в посте.
UEFI уже сейчас неплохо работает. Дополнение к посту P. S. Неожиданные показатели бенчмарка в Windows 11
При всем к вам уважении, ваш ответ эквивалентен выражению из анекдота, "это не дерьмо, а засахарилась". То что вы пишите, это показатель вашего отношения к аудитории, и вашего профессионализма. Говорить "пипл и так схавает", не вызывает никакого уважения. Существует такое понятие как профессиональная этика. Любой нормальный специалист никогда не позволит писать подобную дичь, именно так.
Да все мы люди, и ошибки допускаем. Но писать "неуклюжими библиотеками HAL", технически безграмотно, я не поверю что у вас, как минимум в штате, нет специалистов разбирающихся в архитектуре ОС и Linux. Мое предложение следующее, прежде чем взяться за пост, определяйте его маршрут.
Маршрут №1. Пост пишет автор на тему, в которой сам разбирается и готов как минимум ответить на 80% всех вопросов по данному посту (идеальный вариант).
Маршрут №2. Человек делает предварительную выборку интересных тем для переводов. Затем эта выборка передается специалистам для краткого анализа и исключения полной хрени еще до стадии перевода, помним правило информатики GIGO (Garbage in, garbage out). Далее, перевод желательно человеком, хоть отдаленно понимающий про что идет речь в оригинальном посте. Далее, профильный специалист из результата перевода вычищает дичь в стиле "неуклюжими библиотеками HAL".
PROFIT!
Мне особо и помнить не надо). Напротив меня в книжную полку вставлена книга Стандарты и спецификация USB, толщина заметно больше Библии, скажу более, это одна из самых толстых моих книг. Но это не избавляет, хотя бы кратко технически грамотно описать предмет рассмотрения. Не буду первооткрывателем, тему можно разбить на два поста, первый стандарт и теория, второй практика. И основная моя претензия заключается в низком качестве исходного материала. Автору исходника претензий нет, он так чувствует, имеет на это право, а вот к переводчику есть. У меня есть пост Безопасность встраиваемых систем Linux. Тема безопасности знаете тоже не маленькая, но все же я считаю, что смог донести основную идею и концепцию исходного поста, Introduction to Embedded Linux Security. Я не занимался тупой копи-пастой, материал был не только переведен, а еще существенно изменен и дополнен, там, где требовалось пояснение. Потому что исходный пост рассчитан на западного читателя, специалиста по информационной безопасности.
В итоге: качественный исходный материал + качественная переработка + хорошая адаптация = дала хороший материал, который самому интересно почитать и другим не стыдно показать.
Категорически несогласен. Тут приведу свой комментарий цитату из вашего недавнего поста Создаём своё первое USB-устройство:
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Вот это попробуйте перевести на нормальный человеческий язык.
Об этом и идет речь, что тип устройства необходимо было озвучить в заголовке или как минимум в аннотации. Далее хотя бы немного написать про классы устройств USB, и немного описать тип CDC, вот тогда пост был бы годным. А так +1 в копилку критикам корпоративных блогов, что публикуют материал низкого качества.
Ну и какие драйвера нам потребуются для Windows и Linux, какой все же тип устройства был реализован согласно стандарту USB?
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Вот это попробуйте перевести на нормальный человеческий язык.
Первое, если вы такой опупеный спец, и не врете, то тогда приведите конкретные ссылки на коммиты в проект Armbian и rocknix. Это не ваши собственные личные проекты. И ваш вклад в них непонятен, как и ваша квалификация.
Второе, все тесты и замеры в посте абсолютно корректны. Любой может выполнить их и получить те же результаты.
Третье, прочитайте пост.
Четвертое, если все же прочитали пост, то тогда вы в программном обеспечение разбираетесь как я в балете, т.е. совсем никак.
Плата на процессоре N100 взялась как эквивалент по стоимости и возможностям Orange PI 5 Plus. Собственно тема поста такая, взять решение на ARM и за такую же стоимость попытаться сравнить с x86, сделать это максимально соотносимо.
бессмысленно ваше бытие на этой земле. У меня в посте написано "веб-браузер на Intel N100 работает в 2.6 раза быстрее." Это говорит о том, что для рендера данной страницы Хабра, устройству на Intel N100 потребуется приблизительно в 2.6 раза меньше времени, чем Orange PI 5 Plus. И не надо придумывать всякую чушь. Доказательства есть в посте, надеюсь, вы это в состояние понять.
Пятое, наличие работы OpenGL проверяется командой: glxinfo | grep rendering
Если в ответе есть: direct rendering: Yes. Значит все OK. Это легко проверяется в гуле, надеюсь вас там не забанили.
Но правда и тут есть нюанс, если в ответе будет "OpenGL renderer string: Software Rasterizer". Тогда да, используется программный рендер.
Шестое, RK3588 Brief Datasheet.pdf, раздел GPU указана поддержка:
OpenGL и Vulkan. Не буду повторяться, рыбки это тест OpenGL, Vulkan проверялся играми из Steam.
Все это работает, и весьма неплохо, в тот же Left 4 Dead 2 можно в принципе нормально поиграть.
Если вы продолжаете утверждать, что не используется аппаратный рендер OpenGL и Vulkan, то это уже не ко мне, а к специалистам в белых халатах.
Седьмое, особенно забавно звучит ваш ответ на вопрос "как включить аппаратное ускорение графики", да просто возьми другой дистрибутив с другим ядром и драйверами. Неа, не надо уходить от ответа, конкретно напишите, как мне "включить правильное аппаратное ускорение" для образа который я использовал. Ежику понятно, что другой дистрибутив и другое ядро Linux даст другие результаты. Вы докажите, что в вашем примере fps в тесте с рыбками и играми из Steam будет выше.
Вы там заявили "Этими моими наработками активно пользуется", отлично, докажите на конкретном примере.
Возьмите любую плату на Rockchip из списка поддерживаемых Joshua-Riek/ubuntu-rockchip, коих предостаточно. Запустите на этой плате сборку Joshua-Riek/ubuntu-rockchip без дополнительных библиотек и патчей, т.е. "as-is". Выполните тесты, которые указаны в этом посте. Затем возьмите волшебный Armbian, установите, как вы считаете правильно аппаратное ускорение, выполните те же самые тесты. И по итогу напишите пост как все надо делать. И если результаты fps в играх будут кратно выше, а не пределах колебания погрешности, то я лично готов вам мужественно пожать руку.
Затем я ваш пост переведу на английский язык и отправлю Joshua-Riek и скажу ему, что он ничего не понимает в так называемом аппаратном ускорение и водит общественность в заблуждение.
У вас в профиле написано "Инженер", я не считаю себя инженером, но меня учили инженерному делу. Так вот, настоящие инженеры мне говорили "практика критерий истины", на словах мы все тут великие, могучие, и выше туч. Я свое слово сказал, тесты выполнил, теперь очередь за вами, докажите свою правоту на практике, напишите пост.