А есть где-то список проверенных/рекомендуемых моделей мини-ПК по соотношению цена/качества на вторичном рынке? Я вот из ютубов знаю только ещё про 80-долларовый HP EliteDesk 800 G2.
Та же самая идея с хранением .iso на флешке и использованием GRUB, только менюшки "автоматически" (имеется в виду, что для большинства популярных дистрибутивов написаны конфиги, аналогичные конфигам автора статьи) подхватывают все .iso
Да, но конкретно эта проблема всегда решалась кавыками. Это же решение прекрасно работает и на современном баше, и на условном ksh из 95-ого (честно, специально проверял как-то) :)
→ [ $var == test ] && echo "yes" || echo "no"
no
→ [ "$var" == test ] && echo "yes" || echo "no"
no
→ var=test
→ [ "$var" == test ] && echo "yes" || echo "no"
yes
Да, подставить в готовый тулчейн с похожим libc/ядром rootfs с железки как sysroot — это решение. Собственно, это подпункт «собирать таки кросс-тулчейн, подбирая libc и хэдэры ядра в соответствии rootfs'ом железки» из моего комментария, но в таком случае ты не можешь быть уверен до конца, что всё будет друг с другом совместимо. Я думаю, что в 99% случаев проблем не будет, но на 1% придётся потратить слишком много ресурсов для нахождения проблемы.
В чате ещё предлагали собрать отдельно кросстулчейн на musl и под Linux 2.6, им же скомпилировать статически-слинкованный Qt, потом собрать приложение и упаковать ресурсы Qt и статически-слинкованное приложение в один пакет. Таким образом, софт вообще не зависит от системного libc и версии ядра и будет работать где угодно.
Как мне известно, статья появилась из обсуждения в одном чате следующей проблемы: у человека было устройство на ARM-процессоре с Linux'ом на борту, но тулчейн/исходники ядра/инструкцию по сборке rootfs от вендора получить не удалось. На устройстве был доступ к gcc и старой версии Qt, а для нужд компании требовалось собрать более новую версию Qt. В таком случае варианты со сборкой прямо на железке или с эмуляцией ARM вместо сборки кросс-тулчейна не так уж и плохи.
Кросс-тулчейном действительно собирать в разы проще, когда этот кросс-тулчейн есть или когда его вообще возможно собрать. Но иногда у тебя на руках только железка с SD-картой с ядром и rootfs'ом на борту, где, о чудо, иногда ещё есть и компилятор. Без исходников кросс-тулчейн нужной версии получить сложнее, чем собирать код прямо на железке.
Другой вопрос, что когда ты встречаешься с жЫрным софтом, сборка на дохлой ARM-железке оказывается слишком медленной. В таком случае у тебя несколько вариантов:
собирать таки кросс-тулчейн, подбирая libc и хэдэры ядра в соответствии rootfs'ом железки
брать rootfs с железки и запускать сборку внутри неё на хостовой системе
Автор выбрал второй путь. Проблема лишь в том, что он воспользовался полной виртуализацией (=эмулировал оборудование, I/O, работу драйверов файловой системы, графику и т.д.) тогда, когда было достаточно преобразовывать ARM-вызовы syscall'ов в x86. Для этого у qemu есть набор инструментов под все популярные архитектуры. Например, можно взять любой статический armv7-бинарь, собранный под линукс (например, busybox) и запустить его через qemu-arm busybox. А можно пойти дальше и заchroot'иться в систему, засунув туда qemu-arm-static (static потому что у него не будет доступа до хостовых библиотек вне chroot), тогда /bin/bash, собранный под ARM, будет запускаться на х86, используя qemu-arm-static и библиотеки из rootfs.
В отличие от полной виртуализации, при chroot в ARM-окружение у тебя есть доступ до всех ядер процессора, до всей доступной RAM, до всего дискового пространства хостовой системы, так ещё и очень сильно сокращается overhead от эмуляции процессора и I/O.
Я попробовал сделать Proof-of-Concept, у меня получились очень неплохие результаты:
Такой вариант в 5 раз быстрее (17 минут против 91 у автора), чем сборка в полностью виртуализированном окружении. И это на Intel® Pentium® CPU G4560 @ 3.50GHz в 1 потоке.
Я думаю, можно вызвать ./configure так, чтобы он юзал все потоки, будет намного быстрее.
Конечно, это всё ещё не нативная сборка Qt под x86 на x86: там «конфигурация» проходит за 2 минуты на этом же процессоре.
Под спойлером небольшая инструкция о том, как воспроизвести chroot в ARM-окружение (проверялось на Arch Linux, /home/xxx/rootfs замените на какую-нибудь удобную для вас директорию):
Инструкция по chroot'у в rootfs от Raspberry Pi OS
5. Монтируем dev, sys, proc, run, tmp в rootfs (не забудьте потом это всё отмонтировать после работы):
mount --bind /dev /home/xxx/rootfs/dev
mount --bind /sys /home/xxx/rootfs/sys
mount --bind /proc /home/xxx/rootfs/proc
mount -t tmpfs tmp /home/xxx/rootfs/tmp
mount -t tmpfs run /home/xxx/rootfs/run
7. Профит, мы как будто в обычном chroot'е, но только в ARM'овом :)
P.S. Для сборки я брал Qt 5.15 отсюда, поставил все зависимости из статьи, собирал под пользователем pi (нужно вызвать su — pi, чтобы не собирать под root'ом), + я не очень понял почему это так работает, но я поправил ещё строчку в qtbase/configure:
А можешь поподробнее рассказать?
— Где-то есть форк репозитория для сборки OpenELEC под Comigo Quattro?
— Какие репозитории для ядра и юбута брать?
— Где и как вытащить Device Tree? Образа оригинальной eMMC и ядра ведь нет нигде в общем доступе?
Поразительно, что только вчера целый день провели с товарищем за тем, чтобы расковырять именно эту железку. Правда у нас на руках была инструкция с 4pda, там уже была схема распайки разъёма под SD-карточку, местонахождение UART и готовый образ.
Другое дело, что после подключения карточки загрузка всё равно шла с eMMC. Для того, чтобы это обойти, мой товарищ замкнул пин данных eMMC на землю, тем самым заставив SoC загрузиться с SD (тоже через 30-40 секунд после холодного старта). После загрузки у меня уже не было доступа к eMMC (видимо, SoC как-то инициализирует eMMC, а Linux уже не может переинициализировать, что очень странно), но работала сеть.
Из смешного: на самом деле оригинальный юбут как минимум принимает команды, потому что внезапно работают хоткеи (^C, ^U, ^J) и автодополнение (TAB), но не даёт их исполнять.
Надёжность не в том плане, что запас прочности устройство-носителя контролируется (это делает физический контроллер флешек), а в том, что данные не потеряются и не закорраптятся в случае внезапной потери питания или при каких-то непридвиденных обстоятельствах (при kernel panic, например).
А расскажите, можно ли выпилить всё из CM так, чтобы там осталось только необходимое? Без запуска большинства служб и приложений Android'а, с отключенной ненужной периферией (далеко не всем нужен тот же Bluetooth). По моему опыту ту же сеть можно настраивать без Android'овского network manager'а.
Как я понимаю, там ведь просто chroot в Jolla и запуск из-под него Wayland'а?
Если это всё так, то оставив минимум от Android'а (если уже так не сделали, конечно), можно существенно экономить батарею, прямо как при запуске «нативно», без прослойки в виде Android'а.
<паранойя>А может быть это приложение специально раскрутили, чтобы можно было определить людей, которым есть что скрывать, а потом без особых сложностей доставать их данные с их телефонов? Или вообще все эти данные потом сливаются товарищам-создателям приложения?</паранойя>
владельцам живых обоев и виджетов можно разместить рекламу в настройках.
Вы сами то часто заходите в настройки?
У меня на телефоне было лишь одно приложение с AirPush — так оно меня так достало этими оповещениями
Airpush — самая ужасная компания, дискредитировавшая всю отрасль push-рекламы. Им все сходило с рук, несмотря на нарушение целого ряда требований гугла и отвратительную модерацию рекламных кампаний, допускавшую распространение троянов.
Но не все рекламные сети были такими.
Безусловно, данное обновление с восторгом встретят обычные пользователи. Никто не спорит, что в целом для системы Android оно должно пойти на пользу.
Однако, в свою очередь оно больно ударит по многим крупным игрокам на рынке Android-рекламы: StartApp, Leadbolt, Appwiz, Tapcontext, Sendroid, Airpush и может быть даже TapJoy. Возможно, они были оповещены о намерениях заранее (судя по тому, что многие заблаговременно засуетились с публикацией SDK с рекламой стандартных форматов). Но что делать сотням мелких игроков на локальных рынках? Многие могли заключить долгосрочные контракты, превышающие 30 дней.
Стоит отметить, что такие приложения, как живые обои, виджеты, музыкальные плееры почти невозможно монетизировать in-app рекламой из-за их специфики. Поэтому стоит ожидать, что бесплатные приложения такого типа скоро исчезнут из маркета.
Казалось бы, чтобы заработать разработчикам нужно просто сделать приложения платными и убрать рекламу! Но не стоит забывать, что во многих странах вообще нет возможности что-либо покупать в Google Play. Ситуацию могло бы исправить внедрение carrier billing (оплаты со счета телефона), но пока что с этим у Гугла все печально.
Другими словами, многим инди-разработчикам придется не сладко.
Да и push-реклама не так страшна, на мой взгляд. Большой опыт работы в этой сфере, показал, что при редкой рекламе с нормальным содержанием и соблюдением всех прежних требований Google Play (возможность легкого optout-а + указание на приложение-источник рекламы) негативные отзывы стремились к нулю (5 отзывов-жалоб на 1 млн инсталлов)
«Не совсем понял про рекламные вставки. Это значит, что теперь пользователь должен уметь отключать любую рекламу в приложении?»
Не совсем. Речь идет только о рекламе, занимающей весь экран, которую обычно показывают при запуске приложения. Google Play требует, чтобы такой вспылвающий банер с рекламой можно было бы закрыть сразу и быстро (нажав на заметный крестик справа вверху)
«Знающие люди, подскажите… Вот продаю я шпаги за смс. Но эти же шпаги клиент может использовать в игре как на iOS так в веб клиенте сервиса. Может ли гугл заблокировать мое приложение за нарушение правил?»
Если вы напрямую в самом приложении предложите пользователю оплатить виртуальный товар каким-то сторонним способом — 100% получите бан.
Кхм. Такой вопрос: а имею ли я продавать копии, сделанные вручную, по памяти, каких-либо картин нынеживущих художников? Я к тому, что фан-арт и подражание нельзя продавать?
А есть где-то список проверенных/рекомендуемых моделей мини-ПК по соотношению цена/качества на вторичном рынке? Я вот из ютубов знаю только ещё про 80-долларовый HP EliteDesk 800 G2.
https://github.com/hackerncoder/multibootusb
Та же самая идея с хранением .iso на флешке и использованием GRUB, только менюшки "автоматически" (имеется в виду, что для большинства популярных дистрибутивов написаны конфиги, аналогичные конфигам автора статьи) подхватывают все .iso
В чате ещё предлагали собрать отдельно кросстулчейн на musl и под Linux 2.6, им же скомпилировать статически-слинкованный Qt, потом собрать приложение и упаковать ресурсы Qt и статически-слинкованное приложение в один пакет. Таким образом, софт вообще не зависит от системного libc и версии ядра и будет работать где угодно.
Кросс-тулчейном действительно собирать в разы проще, когда этот кросс-тулчейн есть или когда его вообще возможно собрать. Но иногда у тебя на руках только железка с SD-картой с ядром и rootfs'ом на борту, где, о чудо, иногда ещё есть и компилятор. Без исходников кросс-тулчейн нужной версии получить сложнее, чем собирать код прямо на железке.
Другой вопрос, что когда ты встречаешься с жЫрным софтом, сборка на дохлой ARM-железке оказывается слишком медленной. В таком случае у тебя несколько вариантов:
Автор выбрал второй путь. Проблема лишь в том, что он воспользовался полной виртуализацией (=эмулировал оборудование, I/O, работу драйверов файловой системы, графику и т.д.) тогда, когда было достаточно преобразовывать ARM-вызовы syscall'ов в x86. Для этого у qemu есть набор инструментов под все популярные архитектуры. Например, можно взять любой статический armv7-бинарь, собранный под линукс (например, busybox) и запустить его через qemu-arm busybox. А можно пойти дальше и заchroot'иться в систему, засунув туда qemu-arm-static (static потому что у него не будет доступа до хостовых библиотек вне chroot), тогда /bin/bash, собранный под ARM, будет запускаться на х86, используя qemu-arm-static и библиотеки из rootfs.
В отличие от полной виртуализации, при chroot в ARM-окружение у тебя есть доступ до всех ядер процессора, до всей доступной RAM, до всего дискового пространства хостовой системы, так ещё и очень сильно сокращается overhead от эмуляции процессора и I/O.
Я попробовал сделать Proof-of-Concept, у меня получились очень неплохие результаты:
Такой вариант в 5 раз быстрее (17 минут против 91 у автора), чем сборка в полностью виртуализированном окружении. И это на Intel® Pentium® CPU G4560 @ 3.50GHz в 1 потоке.
Я думаю, можно вызвать ./configure так, чтобы он юзал все потоки, будет намного быстрее.
Конечно, это всё ещё не нативная сборка Qt под x86 на x86: там «конфигурация» проходит за 2 минуты на этом же процессоре.
Под спойлером небольшая инструкция о том, как воспроизвести chroot в ARM-окружение (проверялось на Arch Linux, /home/xxx/rootfs замените на какую-нибудь удобную для вас директорию):
downloads.raspberrypi.org/raspios_lite_armhf_latest
2. Вытаскиваем rootfs из образа диска:
3. Скачиваем на свою систему binfmt-support и qemu-arm-static (для Debian, у арча в AUR'е есть пакет qemu-user-static):
4. Копируем qemu-arm-static в rootfs:
5. Монтируем dev, sys, proc, run, tmp в rootfs (не забудьте потом это всё отмонтировать после работы):
6. Делаем chroot в систему:
7. Профит, мы как будто в обычном chroot'е, но только в ARM'овом :)
P.S. Для сборки я брал Qt 5.15 отсюда, поставил все зависимости из статьи, собирал под пользователем pi (нужно вызвать su — pi, чтобы не собирать под root'ом), + я не очень понял почему это так работает, но я поправил ещё строчку в qtbase/configure:
— Где-то есть форк репозитория для сборки OpenELEC под Comigo Quattro?
— Какие репозитории для ядра и юбута брать?
— Где и как вытащить Device Tree? Образа оригинальной eMMC и ядра ведь нет нигде в общем доступе?
Другое дело, что после подключения карточки загрузка всё равно шла с eMMC. Для того, чтобы это обойти, мой товарищ замкнул пин данных eMMC на землю, тем самым заставив SoC загрузиться с SD (тоже через 30-40 секунд после холодного старта). После загрузки у меня уже не было доступа к eMMC (видимо, SoC как-то инициализирует eMMC, а Linux уже не может переинициализировать, что очень странно), но работала сеть.
Из смешного: на самом деле оригинальный юбут как минимум принимает команды, потому что внезапно работают хоткеи (^C, ^U, ^J) и автодополнение (TAB), но не даёт их исполнять.
А как удалось стянуть образ eMMC?
Как я понимаю, там ведь просто chroot в Jolla и запуск из-под него Wayland'а?
Если это всё так, то оставив минимум от Android'а (если уже так не сделали, конечно), можно существенно экономить батарею, прямо как при запуске «нативно», без прослойки в виде Android'а.
Хотел бы я себе дроида, как у Бао-Дура.
Спасибо.
Вы сами то часто заходите в настройки?
Airpush — самая ужасная компания, дискредитировавшая всю отрасль push-рекламы. Им все сходило с рук, несмотря на нарушение целого ряда требований гугла и отвратительную модерацию рекламных кампаний, допускавшую распространение троянов.
Но не все рекламные сети были такими.
Однако, в свою очередь оно больно ударит по многим крупным игрокам на рынке Android-рекламы: StartApp, Leadbolt, Appwiz, Tapcontext, Sendroid, Airpush и может быть даже TapJoy. Возможно, они были оповещены о намерениях заранее (судя по тому, что многие заблаговременно засуетились с публикацией SDK с рекламой стандартных форматов). Но что делать сотням мелких игроков на локальных рынках? Многие могли заключить долгосрочные контракты, превышающие 30 дней.
Стоит отметить, что такие приложения, как живые обои, виджеты, музыкальные плееры почти невозможно монетизировать in-app рекламой из-за их специфики. Поэтому стоит ожидать, что бесплатные приложения такого типа скоро исчезнут из маркета.
Казалось бы, чтобы заработать разработчикам нужно просто сделать приложения платными и убрать рекламу! Но не стоит забывать, что во многих странах вообще нет возможности что-либо покупать в Google Play. Ситуацию могло бы исправить внедрение carrier billing (оплаты со счета телефона), но пока что с этим у Гугла все печально.
Другими словами, многим инди-разработчикам придется не сладко.
Да и push-реклама не так страшна, на мой взгляд. Большой опыт работы в этой сфере, показал, что при редкой рекламе с нормальным содержанием и соблюдением всех прежних требований Google Play (возможность легкого optout-а + указание на приложение-источник рекламы) негативные отзывы стремились к нулю (5 отзывов-жалоб на 1 млн инсталлов)
Ekstazi,
Не совсем. Речь идет только о рекламе, занимающей весь экран, которую обычно показывают при запуске приложения. Google Play требует, чтобы такой вспылвающий банер с рекламой можно было бы закрыть сразу и быстро (нажав на заметный крестик справа вверху)
L3n1n,
Если вы напрямую в самом приложении предложите пользователю оплатить виртуальный товар каким-то сторонним способом — 100% получите бан.
Приношу извинения за местами корявый перевод.