Qt 5 частично компилится на живом Raspberry Pi 3

Но зачем, когда есть кросскомпиляторы. Да и зачем монструозный C++ с еще более монструозным Qt на несчастных слабеньких армах?

Зачем нужно моструозное ненужно на монструонзном ненужно на Raspberry Pi 3?

Затем, что мощностей Raspberry Pi 3 вполне хватает для сборки многих слакбилдов.

Затем, что Raspberry Pi 3 вполне подходит для десктопа.

Дык Qt не подходит для десктопа.

Ты мне прямо глаза открыл на то, почему у людей $DE_NAME тормозит. Потому что у них Raspberry Pi!

Да и зачем монструозный C++ с еще более монструозным Qt на несчастных слабеньких армах?

Как ни странно, эта комбинация неплохо работает. Даже при частоте процессора 240 МГц.

А в каком вообще состоянии поддержка RPi 3? Свежий хромиум можно запустить, и полазить по тому же Aliexpress без боли?

Но Qt не подходит для десктопа.

А-а-а, опередили!

Свежий хромиум можно запустить, и полазить по тому же Aliexpress без боли?

Chromium вряд-ли скомпилится на живом железе. Только если кросскомпиляцией собрать. В Raspbian'е он, вроде как, есть, но не свежий. На шуструю работу в любом случае рассчитывать не приходится.

А зачем? Малина явно не будет десктопом, хотя арм возможно и вытеснит x86_64.

Дык Qt не подходит для десктопа.

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

Вас в новом гриме неузнать.

Фанатизм как он есть.

У меня есть гтк приложения. Просто, есть и список кьют приложений по подразделам (нашёл на вики манджаро) и я стараюсь использовать их, чтобы не тянуть тучи библиотек. Да у меня и на яве есть и ещё на непойми чём. Стараюсь не использовать - не значит ни за что не буду при отсутствии альтернатив.
«Qt не подходит для десктопа» (что сказало 2 человека) - такой же фанатизм.

Разве в репозитории нет?

Qt 5 в Slackware только слакбилдом на slackbuilds.org. В базовой системе только GTK 1/2/3 и Qt 4.

Вообще-то, весь гном будет едва ли не меньше этого вашего Qt. Базовые библиотеки Gnome вроде gtk и glib вообще мало что могут, поэтому все тащат всё остальное. А вот это всё остальное входит обычно в Qt. Да, Qt модульная, но кто будет писать только ui, а всё остальное используя native библиотеки?

стараюсь найти альтернативу

Простые утилиты можно и самому написать. Как обстоят там дела с поиском альтернатив для чего-то стоящего типа firefox, chrome, darktable, gimp, inkscape, java, electron, thunderbird+enigmail, ...?

С++ монструозен только у лузеров, которые понацепят всяких бустов ради одного-двух методов оттуда.

С++ монструозен только у лузеров, которые понацепят всяких бустов ради одного-двух методов оттуда.

Зачем boost? Bloatware начинается с STL.

Как обстоят там дела с поиском альтернатив для чего-то стоящего типа

свалить на десяточку! там десяточка вроде и для распери есть даже уже.

выдохни. уже почти ничего «полгнома» не тянет. даже сам гном. зависимости уже сто лет как пообрезали.

Отчасти согласен. Не везде нужен STL для полного щастья.

А вообще есть хорошие и маленькие реализации STL. Всё зависит от ещё этого.

зачем? даже в QEMU было бы быстрее

зачем?

Because I can.

Я в своей openSUSE собрал пакеты для SLES 11, и выложил на OBS. Взял пакеты из современных версий openSUSE. Ну что скажу. Авторы SPEC-файла наворотили там. То, что теперь не libqt5, а пятнадцать отдельных либ - это ещё ладно. Но то что -devel пакеты (которые раньше были одним libqt4-devel) разделены на libQt5Gui-devel и libQt5Gui-private-headers-devel - меня сильно удивляет. В результате, SPEC-файл оказался перегружен и труден для понимания.

Да, разбитие на кучу пакетиков - минус rpm-based и deb-based дистрибутивов. В Slackware такого беспредела нету - каждая софтина или библиотека одним большим пакетом.

Не сказал бы что это минус: конечному пользователю удобно. Просто конкретно в этом случае - перебор: зачем разделять -devel на собственно -devel и -private-headers-devel?