Кто-то пробовал установить андроид 2.3.3-4.4 на современные телефоны?
возможно андройд юзеры никогда этого не делали Но Все равно
Кто то может ответить?
возможно андройд юзеры никогда этого не делали Но Все равно
Кто то может ответить?
Подскажите, как сейчас модно работать с сетью на клиентах в C++? Future+корутины? Сложнее ли дебажить дефолтные c++20-корутины нежели обычные колбэки?
Я наделал воркер с curl_multi: берём запросы из очереди, состояние загрузки для UI обновляем атомиками, в конце коллбэк. В принципе терпимо, хоть и простое «скачать и распаковать» превращается в:
using AType = AssetsDL::Type;
template <AType ASSET_TYPE> //
struct AssetsCallbacks {
static void set_asset_zip_ready_to_unpack(...);
static void set_asset_unpacked_and_remove_zip(...);
static void job_asset_unpack();
static void on_zip_downloaded(...);
};
template <AType... Types> struct AssetsCallbacksTables {
static constexpr auto on_zip_downloaded_table =
std::array{&AssetsCallbacks<Types>::on_zip_downloaded...};
static constexpr auto job_asset_unpack_table =
std::array{&AssetsCallbacks<Types>::job_asset_unpack...};
};
using AssetsCbs =
AssetsCallbacksTables<AType::XAPIAN_TR, AType::OPTIONAL_XAPIAN_DE,
AType::OPTIONAL_TTS, AType::OPTIONAL_ASR>;
В моей, довольно простой ситуа, с коллбэками только одна проблема возникла: я перепутал порядок в шаблонных аргументах AssetsCallbacksTables и завяз на добрый час. Кроме ситуа1 «скачать+распаковать» мне требуется только ещё более простая ситуа ситуа2 «скачать в память и попарсить\подекодить немножк».
БЯМ пишет, что я рак и отдельный тред и атомики мне не нужны, а нужно звать curl_multi_perform на каждом кадре. БЯМ не знает, что у меня рендеринг по ивентам. Впрочем, бустить фпс на время запросов(+ троттлинг непосредственно рендеринга) и сильно упростить код — звучит неплохо!
Как бы вы сейчас писали подсистему сетевых запросов?
Периодически я посещаю сайт Андрея Викторовича Столярова, посмотреть что вышло нового благо, что книги действительно достойные.
И что я вижу: задаёт чувак вопрос Андрею Викторовичу, о возможности использовать макос для обучения, на что получает ответ:
Всё намного проще, чем вы придумали. Под нормальной unix-системой вы можете в командной строке сделать вообще всё, в том числе запустить любое оконное приложение. В частности, браузер. И, что очень важно, без всяких лишних плясок с какими-то там лаунчерами. Вот просто буквально, в терминале:
firefox http://stolyarov.info
В макоси вы этого сделать не можете. Ну то есть можно, конечно, рассказать тут публике, как именно (с помощью каких безумных идиотизмов) вы таки можете тот же браузер заставить запуститься, пользуясь только терминалом, но это будет чистая демагогия, поскольку реально использовать эту возможность ни один вменяемый человек не станет. Собственно говоря, всё. Для изучения моих книг командная строка должна стать основным средством работы с машиной, это абсолютно обязательное условие. Под MacOS это невозможно.
Последний абзац я пропущу от греха, а вы можете ознакомиться на сайте. Без КВНа из РФ это может быть проблемой. Уже который раз замечаю, что некоторые образовательные ресурсы по IT в РФ не работают, но я искренне уверен, что они это не по злому умыслу и не для того, чтобы сделать из граждан подданных.
ЗЫ Уважаемый @Croco с удовольствием изучал Си и С++ по вашему учебному пособию пользуясь Windows+Vs code+msys2(gcc)+powershell. ИЧСХ все получалось. Кому интересно, как этого добиться написано в доке к vscode.
В общем, периодически стряхиваю пыль с мака, а это проприетарный Unix, так что, в общем-то система не плохая, но до чего же она устарела, ща расскажу:
Не влезал под капот особо, но вот есть там хвалёный GUI, весь такой модный и вкусный, как Орбит сочный арбуз. И всё идёт хорошо, пока по какой-либо причине приложение не начнёт работать не по плану. Просто невозможно ничего прибить мышью. В Linux юзаю Gnome, не разу у меня не было, чтобы по нажатию на крестик приложение не закрывалось через графику.
При том что в Linux я сходу, при старте системы, открываю консоль, с вероятностью 100% она понадобится, не на этой, так на следующей неделе, аптайм у меня по несколько месяцев.
В «идеальном» мире MacOS приложение может не только не закрываться мышью, но и препятствовать перезагрузке или выключению. Очень странно. Такие фризы ловил с каким-то клиентом XMPP и с VSCode. Всё, в таких случаях, решается через консоль, как не странно, да?
Дефолт довольно странный, почему свёрнутое приложение не может быть восстановлено по Alt+Tab, непонятно.
Почему клавиши Home и End не работают? По умолчанию. Может кто знает как починить?
Почему в дефолтной консоли, которая в Linux позволяет так ловко работать, в MacOS даже не умеет в autocomplete параметров?
В общем, получается что оно мне не подходит. По умолчанию, а правило «не тащить в систему стороннее», ну хотя бы поменьше это делать, ограничивает горизонты кастомизации. Так как мне хотелось чтобы уж MacOS не была у меня складом компиляторов, исходников, бинарников и прочего.
Пишу тему чтобы потрепаться, так что давайте, ставьте клоунов, ненужно и прочие радости. О плюсах системы не буду писать, я думаю они тоже у каждого свои. А я о них писал когда выкладывал в галерею.
Я уже давно заметил, что как только в gnu что-то начинает стабильно работать - срочно надо это заменить чем-то новым, которое будет годами чиниться. Как только оно починится - это срочно надо поменять. И как только появляется альфа новой поделки - сразу всё ПО, которое использовала стабильную технологию - моментально меняет на новую, без возможности использовать старую работающую технологию. И это в бесконечном цикле
Внутренний проект Amazon с использованием модели Claude Sonnet обошёлся компании в $1,8 млн, превысив выделенный бюджет на 860%. Как сообщает Financial Times, система должна была автоматически сопоставлять сведения об авторах с карточками товаров в интернет-магазине Amazon, однако в итоге так и не была запущена. Перерасход оставался незамеченным в течение пяти месяцев.
О проблеме старшие инженеры рассказали сотрудникам Amazon на внутренней встрече 28 июля 2026 года. По данным изученных журналистами материалов, причиной расходов стали ошибки в программном коде, отсутствие своевременных ограничений и особенности тарификации больших языковых моделей. Если при традиционной разработке неудачно работающая операция могла обходиться почти бесплатно, то вызывающий модель ИИ агент продолжал расходовать оплачиваемые токены. Один из инженеров охарактеризовал подобные ошибки как «катастрофически дорогие». (BetaNews)
Проект с Claude оказался не единственным. Инструмент для финансового аудита создал около $541 тыс. незапланированных расходов, а система оптимизации логистики и сроков доставки превысила бюджет ещё на $134 тыс. Таким образом, три обнаруженных случая принесли Amazon примерно $2,5 млн дополнительных затрат. (Tom’s Hardware)
Компания заявила, что продолжает экспериментировать с новой технологией, учится использовать её эффективнее и внедряет автоматические ограничения расходов. В Amazon считают, что несколько отдельных неудачных проектов не отражают повседневное применение ИИ во всей компании. (Cybernews)
Проблема усугубляется переходом поставщиков ИИ от фиксированных подписок к оплате за фактически обработанные токены. Расходы особенно сложно предсказывать при использовании автономных агентов, способных многократно обращаться к модели без постоянного участия человека. Amazon уже разрабатывает защитные механизмы, которые должны автоматически останавливать проекты при необычном росте затрат.
Соб-но, сабж, клик ПКМ / лонг тап на мобильном устройстве на любой теме форума позволяет открыть ее в новой вкладке через стандартное контекстное меню, однако, если открыть ленту уведомлений (колокольчик), то в списке уведомлений так сделать не получается. Воспроизводится на десктопе и мобильных устройствах, везде стоит Firefox.
Недавно организацией Independent Federated Intelligence Network при проверки пакетов в AUR был найден вредоносный код, благодаря которому можно грабить корованы получать удалённый доступ к машинам, иметь доступ через SSH, к крипокошелькам, получать пароли, ключи доступа и прочему. Предположительно могут быть «заражены» около 200 пакетов.
Разработчики самого Арча временно ограничили приём изменений в AUR до решения проблемы.
Более детально можно почитать здесь.
Дополнительные пояснения:
AUR (Arch User Repository) это не основной репозиторий (от команды разработчиков дистрибутива Arch с надлежащей проверкой), а место, где любые пользователи могут публиковать свои скрипты для сборки пакетов с минимальный порогом входа. Сами разработчики Арч советуют проверят содержание скриптов сборок и устанавливать их «на свой риск».
«Запрет изменений» является запретом на переход пакета от одного разработчика к другому: в ряде случаев злоумышленники начинали сопровождение устаревших пакетов и вносили в них вредоносные правки.
Забавная тут история произошла. Началось с того, что я заметил, что десктопный kdeconnect не хочет принимать файлы, посланные его клиентом с телефона. Причём никаких сообщений об ошибках, ничего — телефонный клиент рапортует, что файл послан, а КДЕ-шное уведомление о приёме продолжает висеть и никак не завершается.
Стал ковыряться. Сбэкпортил свежую версию — хрен, завёл чистого пользователя — хрен. Установил стабильный Дебиан в виртуалке — опа, работает. Но там, известно, системда, а на десктопе у меня нет. Снёс системду в виртуалке (подолбавшись, как водится) — работает. Включил и там и там QT-шный отладочный вывод kdeconnect.*, стал сравнивать — в виртуалке при обнаружении устройства сразу же устанавливается TCP-соединение, а на десктопе с ошибкой сваливается в fallback UDP. Так как вывод ни хрена не информативный, пришлось качать исходники и патчить, чтобы хоть понять, чего ему не нравится. Выяснилось, что демон Кдеконнекта обращается к адресу телефона в виде «::ffff:192.168.x.x», то есть так называемого «ipv4-mapped ipv6». Попробовал пингануть, из виртуалки - просто не пингуется, с десктопа - аж «network unreachable». Нагуглил, что в ядре за это дело отвечает параметр sysctl net.ipv6.bindv6only, и разумеется, в виртуалке он 0, а на десктопе — 1. Выключил — работает. Зашибись.
Но теперь стало интересно, какая же сволочь мне этой настройкой удружила. В /etc/sysctl.d лежит файлик bindv6only.conf. По apt-file и поиском на дебиановском сайте не находится. Стал гуглить дальше — следы обнаружились в багрепортах пакета netbase. Оказывается, эти гендерно-разнообразные этот файл при установке создавали скриптом postinst (нет бы хоть в пакет положили!). После того, как в багрепортах им насовали, создавать (аж с 2010 года) перестали, но и удалять, разумеется, его никто не будет. А раз я систему не переустанавливал никогда, так оно и лежит.
Мляя… Пердолился со всем этим, наверно, больше суток чистого времени. А мораль — если наблюдаются странности с сетевыми приложениями, смотрите /proc/sys/net/ipv6/bindv6only. Ну и, штабильность дебилиана такая штабильность.
У меня не правильно отображается статистика. В те дни что не писал комментариев - они есть, а в те что писал - нет. Вот сегодня писал, а в статистике их нет. Вчера ничего не писал, но в сататистике они есть. 26 июля писал - в статистике пусто. Глубже ослеживать не стал, но наверняка и там неверно. Мне кажется в статистике произошел временой сдвиг на сутки назад от реальности. Кастану главного @maxcom.
Нет, не про самую-самую базу (git init, clone, config, status, add, commit, log, branch, merge, pull, push, diff), а про более тонкие моменты, которые сильно облегчают жизнь. Например про хуки. Что используете в своих проектах? А на работе? Соблюдаете ли Conventional Commits или вообще перешли на Gitmoji и теперь у вас там ползают 🐛 и летают 🚀? Или используете что-то более строгое, а может своё? Может кто-то версию софта с гита тянет и в софтину вшивает системой сборки. Или наоборот используете его максимально деревянно чтоб откатывать изменения. И так далее.
Нажимаешь Ctrl+. в textarea
Я просто в шоке. Боже-Боже, этот мир никогда не будет прежним 😎️
Привет! Ищу себе в проект разработчика со знанием Go, WordPress и Laravel. Может знаете кого-то??
Перемещено anonymous_incognito из general
Простите, тяпница, каберне-совиньон, всё такое...
Но нельзя отрицать, что systemd жёстко прибит к необязательным фичам ядра linux, а мэйнстримный linux софт - к systemd.
В контексте этого и моего опыта вайб-кодинга, я пристал к chatgpt с таким вопросом:
Можно ли пропатчить systemd таким образом, чтобы ему не нужны были cgroups2? цель - не повторить функциональность, а просто наделать "заглушек", чтобы программы запускались как в 1990-х.После серии наводящих промптов я получил такой ответ:
Если задача — именно обмануть systemd, а не реализовать настоящие cgroups, то можно заменить файловую систему cgroup на внутреннюю модель, хранящуюся, например, в /tmp или /run.
Например, вместо
/sys/fs/cgroup/system.slice/sshd.service/
cgroup.procs
memory.max
cpu.max
создавать
/tmp/systemd-fake-cgroup/
system.slice/
sshd.service/
procs
memory.max
cpu.max
Тогда функции вроде
cg_get_path()
cg_create()
cg_trim()
смогут работать почти без изменений, просто с другим префиксом пути.
Однако есть ограничение: ядро никогда не будет читать эти файлы. Поэтому запись в
memory.max
будет просто изменением текстового файла, без какого-либо эффекта. Если ваша цель — лишь удовлетворить ожидания systemd, этого может быть достаточно.
Проблема возникает с операциями, которые предполагают взаимодействие с ядром. Например, запись PID в cgroup.procs в реальности перемещает процесс в группу. В «фальшивой» реализации можно:
просто записывать PID в файл procs;
вести внутреннюю таблицу «unit → список PID»;
использовать её при stop и restart, отправляя сигналы этим PID.
То есть вместо
echo 1234 > cgroup.procs
получится примерно
append_pid("/tmp/systemd-fake-cgroup/system.slice/sshd.service/procs", 1234);
А при остановке сервиса:
прочитать файл procs;
проверить, какие PID ещё существуют;
отправить им SIGTERM, затем при необходимости SIGKILL;
удалить каталог.
Это уже довольно близко к поведению старых init-систем.
Есть ещё одна тонкость: некоторые части systemd ожидают событий от cgroups (например, что группа опустела после завершения всех процессов). Это тоже можно эмулировать, периодически проверяя сохранённые PID через kill(pid, 0) или анализируя /proc. Такой подход менее эффективен и не столь точен, как механизм ядра, но для минимальной совместимости может оказаться достаточным.
Вопрос: как вам такой луддизм? Закопать systemd набором патчей, позволяющим запускать прибитый к systemd софт на оффтопике, но при этом полностью уничтожающих все преимущества systemd для безопасности? Сможет ли это создать анархическое KISS движение за использование примитивных ядер там, где не нужны развесистые?
я слышал, что KDE переходит на вейланд и для иксов кед больше не будет разрабатываться
а когда я последний раз чекал, на фряхе были кеды только для иксов , как с этим сейчас не знаю
что теперь будет с кедами на фряхе? их выкинут из фряхи? или перепишут на вяленого? или будут поддерживать с иксами
Обновился до 26.05 и стало виснуть видео в mpv. Посмотрел логи, а там:
[ffmpeg] CUDA: Cannot load libcuda.so.1
[ffmpeg] CUDA: Could not dynamically load CUDA
[ffmpeg/video] mpeg4: No support for codec mpeg4 profile 15.
[ffmpeg/video] mpeg4: Failed setup for format vaapi: hwaccel initialisation returned error.
[ffmpeg/video] mpeg4: decoding to AV_PIX_FMT_NONE is not supported.
[ffmpeg/video] mpeg4: No support for codec mpeg4 profile 15.
[ffmpeg/video] mpeg4: Failed setup for format vaapi: hwaccel initialisation returned error.
[ffmpeg/video] mpeg4: decoding to AV_PIX_FMT_NONE is not supported.
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object file: No such file or directory
vdpauinfo
display: :0.0 screen: 0
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
locate libvdpau_radeonsi.so
/nix/store/9izf19cawajqfav9cj48qccr7mc2f5cb-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so
/nix/store/9izf19cawajqfav9cj48qccr7mc2f5cb-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so.1
/nix/store/9izf19cawajqfav9cj48qccr7mc2f5cb-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/9izf19cawajqfav9cj48qccr7mc2f5cb-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so.1.0.0
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so.1
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so.1.0.0
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so.1
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/avs0z400pcmwmvlgg3dzx1d68rbihf1m-steam-run-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so.1.0.0
/nix/store/cvz1bgx6vhgxi3cfn2bf6wfhfk0l1d5g-graphics-drivers/lib/vdpau/libvdpau_radeonsi.so
/nix/store/cvz1bgx6vhgxi3cfn2bf6wfhfk0l1d5g-graphics-drivers/lib/vdpau/libvdpau_radeonsi.so.1
/nix/store/cvz1bgx6vhgxi3cfn2bf6wfhfk0l1d5g-graphics-drivers/lib/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/cvz1bgx6vhgxi3cfn2bf6wfhfk0l1d5g-graphics-drivers/lib/vdpau/libvdpau_radeonsi.so.1.0.0
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so.1
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib32/vdpau/libvdpau_radeonsi.so.1.0.0
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so.1
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/klqrrvryc3lv9wd9x0kggr7gq1qraaij-steam-fhsenv-rootfs/usr/lib64/vdpau/libvdpau_radeonsi.so.1.0.0
/nix/store/l4myp7qn0q9bqgmkqq4vnnii22ql1r68-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so
/nix/store/l4myp7qn0q9bqgmkqq4vnnii22ql1r68-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so.1
/nix/store/l4myp7qn0q9bqgmkqq4vnnii22ql1r68-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so.1.0
/nix/store/l4myp7qn0q9bqgmkqq4vnnii22ql1r68-mesa-25.0.7/lib/vdpau/libvdpau_radeonsi.so.1.0.0
ls -1 /run/opengl-driver/lib/vdpau/
libvdpau_va_gl.so
libvdpau_va_gl.so.1
environment.sessionVariables = lib.mkIf (videocard == "ryzen7000_amdgpu") {
LIBVA_DRIVER_NAME = "radeonsi";
VDPAU_DRIVER = "radeonsi";
};
hardware = {
graphics = {
enable = true;
enable32Bit = true;
# driSupport = true; # <-- deprecated
extraPackages = with pkgs; [
mesa
libGL
libva-vdpau-driver
libvdpau-va-gl
libva
];
};
};
Если попробовать сделать так:
VDPAU_DRIVER=radeonsi VDPAU_DRIVER_PATH="/nix/store/cvz1bgx6vhgxi3cfn2bf6wfhfk0l1d5g-graphics-drivers/lib/vdpau/libvdpau_radeonsi.so" vdpauinfo
display: :0.0 screen: 0
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
uname -a
Linux desktop-nixos 7.1.5-xanmod1 #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux
Перечитал доку https://wiki.nixos.org/wiki/AMD_GPU Вроде ничего не поменялось
Kimi K3 — новая версия китайской модели Kimi. Это открытая модель, вы можете скачать веса и запустить её на своём компьютере, правда, вам потребуется несколько сотен гигабайт видеопамяти. ЕМНИП, Kimi K2.5 требовала 250 гигов.
Ну и вот её попросили написать интерфейс macos в браузере. Результат можно потыкать тут: https://macos27.kimi.page/
Отличительной особенностью китайских моделей также является и то, что никаких ограничений по использованию из России.
Коллеги, а возможно ли использовать близкий хотя бы к 70% из указанных в wiki обьем памяти https://openwrt.org/toh/linksys/mx4300#hardware_highlights ?
А то доступно всего 70-80 МБ (:
root@OpenWrtMx4300:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/ubi0_1 68.3M 55.8M 9.1M 86% /overlay
overlayfs:/overlay 68.3M 55.8M 9.1M 86% /
root@OpenWrtMx4300:~# mount
/dev/ubi0_1 on /overlay type ubifs (rw,noatime,assert=read-only,ubi=0,vol=1)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work,xino=off)
overlayfs:/overlay on /opt/docker type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work,xino=off)
X Window работает на 0-м экране. Запускаю Xvfb на 1-м:
$ Xvfb -screen :1 1024x768x16
(EE)
Fatal server error:
(EE) Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
(EE)
Что ему не нравится?
В /tmp/.X0-lock — PID работающего на 0-м экране X Window. Удаление /tmp/.X0-lock и /tmp/.X11-unix/ не помогает. В dmesg ничего нет.
Gentoo, KDE, x11-base/xorg-server-21.1.24. Конфигурация подробнее: emerge –info: https://pastebin.com/ei5qKVLj, emerge -pqv: https://pastebin.com/YDWkXWUW, emerge –info xorg-server: https://pastebin.com/y4VVcmew, strace Xvfb -screen :1 1024x768x16: https://pastebin.com/83WDztjF
Дополнение:
Собственно, Xvfb понадобился для сборки Firefox с PGO — с самого начала вызывает Xvfb -displayfd 1 -screen 0 1280x1024x24 +extension RANDR и не начинает компиляцию, если Xvfb не работает.
Но после серии перезагрузок с выключением/включением в параметрах ядра 'nvidia-drm.modeset=0' и заменой 0 на 1, когда я снова загрузился со старой командной строкой и попробовал thread apply all bt full в GDB, эта команда не упала! И больше не падает.
Я даже пересобрал xorg-server с CFLAGS="-O2 -pipe -march=native" (убрав -ggdb3 и вернув native) и перезагрузился. Всё равно работает.
Теперь вопрос: что это было?
Что-то задолбали эти постоянные изменения в Qt/Gtk. Из-за этого Win32 выглядит намного предпочтительнее, хотя и является отстоем.
Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было и в любом дистре оно было искаропки.
Можно, конечно, каое-нибудь древнее GTK2 взять, но где гарантия что его не выкинут из всех дистров через пару лет? Вот Wine не выкинут, а GTK2 запросто.
Xlib сгодилась бы, но там толком нет виджетов, к большому моему сожалению.
Собственно, по-сути, из Win32 нужны только виджеты - всякие там кнопки/выпадалки/Treeview/ListView/OpenFile/etc. Никаких CreateFile, EnterCriticalSection или прочей параши не требуется.
Win32 ещё хорош тем, что не надо в венду тащить тонну чужих либ. От венды отказаться пока не получится, т.к. предприятия не торопятся отказываться от венды и иногда даже WinXP попадается. Хорошо, конечно, если что-то внезапное случится и венда сдохнет через годик как явление, но всерьёз на это закладываться я не стану.
В общем, если есть опыт использования Wine как нативной линуксячьей гуйни, которая никогда не меняется, было бы интересно о нём узнать всякие подробности, типа приходилось ли что-то править в гуёвом коде за последние 10 лет, какие подводные камни и косяки вылезают и т.п.
| ← предыдущие | следующие → |