Кстати, хороший критерий оценки поста вы подали, по наличию комментариев и добавлений в закладки, отличная идея для написания своего расширения браузера.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "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 и скажу ему, что он ничего не понимает в так называемом аппаратном ускорение и водит общественность в заблуждение.
У вас в профиле написано "Инженер", я не считаю себя инженером, но меня учили инженерному делу. Так вот, настоящие инженеры мне говорили "практика критерий истины", на словах мы все тут великие, могучие, и выше туч. Я свое слово сказал, тесты выполнил, теперь очередь за вами, докажите свою правоту на практике, напишите пост.
Чё серьезно? Если вы разобрались в "как включить аппаратное ускорение графики", то просветите тогда общественность.
Второе, вы видимо вообще не понимаете как работают системы без аппаратного ускорения графики. Тот же тест с рыбками на WebGL дал бы максимум ~5 fps с одной рыбкой. Видео 1080p кодеком H265 вообще максимум 1-2 fps. А игры в Steam? Неа, это тоже на одном процессоре? Вы это серьезно или шутите?
SSD может максимум потребить в пике DC 3.3/2.0A = 6.6 W. Подключал USB Flash 3.0 на 128 ГБ. Архивировал игры steam с SSD на USB Flash, никаких проблем не заметил. USB Flash на само деле много не потребляет, хотя корпус греется прилично.
Планируется ли выставлять лимиты на потребление ресурсов, например максимум 5% CPU и 3% RAM от узла размещения? Вдруг на мой сайт ночью случится хабраэффект, и утром придет счет на слишком большую сумму, чем планировалось. Подобные инциденты уже были с Amazon.
Сравнивать Microsoft Power BI и Grafana абсолютно некорректно, это совершенно разные программные продукты. Microsoft Power BI это анализ финансовых, маркетинговых данных, а Grafana визуализация данных, соответственно кейсы использования тоже различаются.
А разве не встречали Xiaomi Smart TV Stick и подобные другие стики?
Если говорите про полноценные мини-ПК, то в такой корпус запихать можно, только невозможно нормально отвести тепло. Слишком сложное и неустойчивое устройство получается, да и смысла нет.
Самое главное не написали, единственное отличие от предыдущей модели это добавление порта HDMI in. Ждем новую версию Orange Pi 5 Ultra Max Turbo Gen2 аж с тремя портами HDMI, как на Orange Pi 5 Plus. На Rockchip RK3588 необходимо крепить радиатор. Да китайцы сделали "Extremely Small Size, Extremely Powerful", но ценной лишения креплений для системы охлаждения. Сударь, как железку то охлаждать будем? 5A тока себя сами не охладят.
У Вас заголовок поста не совпадает с содержанием, тенденции и перспективы не описаны. Речь в посте идет о постановке вопроса перехода с .NET на Java, после ухода Microsoft из РФ. Фактически восхваляете платформу .NET, это конечно же прекрасно, но не содержательно.
Минусы все же есть после ухода Microsoft. Например, не сможете купить компоненты для .NET выпущенные западными компаниями. Коммиты в платформу .NET могут отклонить по политическим мотивам, фактически вы не можете что-то привнести новое в платформу. Вспоминаем недавний случай когда Торвальдс исключил российских разработчиков из списка мейнтейнеров Linux.
На мой взгляд, пост у вас получился слишком популистский, практически нет никаких доказательств. Этого не должно случиться, потому что не должно, если кратко.
Рост денежного агрегатора M2 вполне нормален, только вот вы не описали НОРМАЛЬНЫЕ ОБСТОЯТЕЛЬСТВА ДЛЯ РОСТА. Деньги являются кровью экономики. Соответственно, при росте экономики в виде производства реальных товаров, а не виртуальных, и не ВПК, на дельту приращения стоимости товаров, должна увеличиваться и денежная масса. В противном случае в системе просто не будет денег купить товар. Но реальная экономика как минимум с начала ковида, сильно стагнирует и поэтому рост M2 является нездоровой ситуацией. В системе становится товаров меньше, а денег все больше.
Далее, вы утверждаете, что экономика СССР была совершено другой, и не имеет смысла оценивать события 1991 года. Так я должен заметить, что и экономика РФ с начала 2022 года тоже стала другой. По вашему отключение банков от SWIFT, международных банковских карт, введенные санкции никак не меняет экономику? Расскажите это компаниям, у которых были кредиты в 2014 году выданные западными банками. Экономика принципиально изменилась, но за счет гигантизма РФ все последствия ощущаются только через 2-3 года. Те изменения в экономики, которые случились в 2022 году, только сейчас начинают доходить, вот и весь ответ.
С вашем выводом о бессмысленности заморозки вкладов я согласен, но ваши обоснования этого сомнительны. В ближайшем временном горизонте заморозка не грозит, но как будет дальше, вопрос остается открытым.
Кстати, хороший критерий оценки поста вы подали, по наличию комментариев и добавлений в закладки, отличная идея для написания своего расширения браузера.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "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 и скажу ему, что он ничего не понимает в так называемом аппаратном ускорение и водит общественность в заблуждение.
У вас в профиле написано "Инженер", я не считаю себя инженером, но меня учили инженерному делу. Так вот, настоящие инженеры мне говорили "практика критерий истины", на словах мы все тут великие, могучие, и выше туч. Я свое слово сказал, тесты выполнил, теперь очередь за вами, докажите свою правоту на практике, напишите пост.
Скриншоты я всегда могу опубликовать и я знаю, что там будет написано.
Читаем: glmark2-es2-wayland - OpenGL (ES) 2.0 benchmark suite
Мне хотелось бы узнать, как все же включить это "аппаратное ускорение графики", раз вы так в этом хорошо разбираетесь.
Второе, мне непонятно одно, как тогда выполнился тест WebGL Aquarium с рыбками.
mozilla.org сообщает: " WebGL (Web Graphics Library) ... WebGL приносит в веб трёхмерную графику, вводя API, который построен на основе OpenGL ES 2.0"
Запуск рыбок на WebGL - следует, что работает OpenGL ES 2.0.
Тест glmark2-es2-wayland проверяет наличие доступности и работы OpenGL (ES) 2.0.
Раз тест с WebGL выполнился, значит OpenGL ES 2.0 работает.
Вот теперь, как специалист, поясните мне как заработало API OpenGL ES 2.0 без аппаратного ускорения?
Ссылку нормальную напишите на свой проект "проект ROCKNIX".
Чё серьезно? Если вы разобрались в "как включить аппаратное ускорение графики", то просветите тогда общественность.
Второе, вы видимо вообще не понимаете как работают системы без аппаратного ускорения графики. Тот же тест с рыбками на WebGL дал бы максимум ~5 fps с одной рыбкой. Видео 1080p кодеком H265 вообще максимум 1-2 fps. А игры в Steam? Неа, это тоже на одном процессоре? Вы это серьезно или шутите?
Если откроете страницу автора сборки https://github.com/Joshua-Riek/ubuntu-rockchip/, то там черному по белому написано "3D hardware acceleration support via panfork".
В посте написано "3D аппаратное ускорение работает посредством драйвера panfork".
Пролистайте до скриншота Системная информация GNOME.
Там есть две строки:
Graphics 1 - Software Rendering
Graphics 2 - Mali-G610 (Panfrost)
Я думаю вывод сделать не сложно, есть аппаратное ускорение графики или нет.
SSD может максимум потребить в пике DC 3.3/2.0A = 6.6 W. Подключал USB Flash 3.0 на 128 ГБ. Архивировал игры steam с SSD на USB Flash, никаких проблем не заметил. USB Flash на само деле много не потребляет, хотя корпус греется прилично.
Про UEFI будет далее, в комплекте с установкой Windows. Там более подробно рассмотрим текущий уровень доступных функций и сравним с U-Boot
Планируется ли выставлять лимиты на потребление ресурсов, например максимум 5% CPU и 3% RAM от узла размещения? Вдруг на мой сайт ночью случится хабраэффект, и утром придет счет на слишком большую сумму, чем планировалось. Подобные инциденты уже были с Amazon.
Сравнивать Microsoft Power BI и Grafana абсолютно некорректно, это совершенно разные программные продукты. Microsoft Power BI это анализ финансовых, маркетинговых данных, а Grafana визуализация данных, соответственно кейсы использования тоже различаются.
Kestrel сравнивать с NGINX нельзя, т.к. Kestrel используется для хостинга приложений. Сама MS рекомендует размещать Kestrel сзади реверс-прокси, почитайте Когда использовать Kestrel с обратным прокси-сервером
А разве не встречали Xiaomi Smart TV Stick и подобные другие стики?
Если говорите про полноценные мини-ПК, то в такой корпус запихать можно, только невозможно нормально отвести тепло. Слишком сложное и неустойчивое устройство получается, да и смысла нет.
Самое главное не написали, единственное отличие от предыдущей модели это добавление порта HDMI in. Ждем новую версию Orange Pi 5 Ultra Max Turbo Gen2 аж с тремя портами HDMI, как на Orange Pi 5 Plus. На Rockchip RK3588 необходимо крепить радиатор. Да китайцы сделали "Extremely Small Size, Extremely Powerful", но ценной лишения креплений для системы охлаждения. Сударь, как железку то охлаждать будем? 5A тока себя сами не охладят.
У Вас заголовок поста не совпадает с содержанием, тенденции и перспективы не описаны. Речь в посте идет о постановке вопроса перехода с .NET на Java, после ухода Microsoft из РФ. Фактически восхваляете платформу .NET, это конечно же прекрасно, но не содержательно.
Минусы все же есть после ухода Microsoft. Например, не сможете купить компоненты для .NET выпущенные западными компаниями. Коммиты в платформу .NET могут отклонить по политическим мотивам, фактически вы не можете что-то привнести новое в платформу. Вспоминаем недавний случай когда Торвальдс исключил российских разработчиков из списка мейнтейнеров Linux.
На мой взгляд, пост у вас получился слишком популистский, практически нет никаких доказательств. Этого не должно случиться, потому что не должно, если кратко.
Рост денежного агрегатора M2 вполне нормален, только вот вы не описали НОРМАЛЬНЫЕ ОБСТОЯТЕЛЬСТВА ДЛЯ РОСТА. Деньги являются кровью экономики. Соответственно, при росте экономики в виде производства реальных товаров, а не виртуальных, и не ВПК, на дельту приращения стоимости товаров, должна увеличиваться и денежная масса. В противном случае в системе просто не будет денег купить товар. Но реальная экономика как минимум с начала ковида, сильно стагнирует и поэтому рост M2 является нездоровой ситуацией. В системе становится товаров меньше, а денег все больше.
Далее, вы утверждаете, что экономика СССР была совершено другой, и не имеет смысла оценивать события 1991 года. Так я должен заметить, что и экономика РФ с начала 2022 года тоже стала другой. По вашему отключение банков от SWIFT, международных банковских карт, введенные санкции никак не меняет экономику? Расскажите это компаниям, у которых были кредиты в 2014 году выданные западными банками. Экономика принципиально изменилась, но за счет гигантизма РФ все последствия ощущаются только через 2-3 года. Те изменения в экономики, которые случились в 2022 году, только сейчас начинают доходить, вот и весь ответ.
С вашем выводом о бессмысленности заморозки вкладов я согласен, но ваши обоснования этого сомнительны. В ближайшем временном горизонте заморозка не грозит, но как будет дальше, вопрос остается открытым.