Ариадна Конилл (Ariadne Conill), создатель музыкального проигрывателя Audacious, инициатор разработки протокола IRCv3 и лидер команды по обеспечению безопасности Alpine Linux, опубликовала начальную реализацию прослойки Wayback, позволяющей запускать десктоп-окружения, завязанные на протокол X11, используя компоненты на базе Wayland. Код проекта написан на языке Си и распространяется как общественное достояние (CC0)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63491
Зачем в Alpine вообще десктоп? Он же дистр для докеровских образов. Вот серьезно. На десктоп ставят бабанту, Федору, арч. А альпин ставят туда, где он очень хорошо себя показывает -- в докеровских образах.
Для слабых компов вроде неплохо подходит
Да не подходит он для слабых компов. Alpine урезан по размеру. По производительности он намного хуже, но когда тебя надо как можно побольше контейнеров втиснуть на физический хост, а вот процессор там мощный и многоядерный стоит, то как раз становится выгоднее пожертвовать производительностью в угоду памяти.
1) там и памяти может быть терабайт
2) приложения которые там контейнерах живут обычно сильно тяжелее самого базового контейнера, что размер окружения просто теряетсяскорее всего использование других дистров не позволит кукарекать что докер контейнер это легковесный имейдж
Особенно реализация системного аллокатора в musl подходит для слабых компов, ага.
А что с ним?
Он очень низкопроизводительный. Его вроде как пытались переписать, но, видимо, так до этого и не дошло. Лучше переопределить malloc общесистемно (`/etc/ld.so.preload`) на hardened_malloc (если важна безопасность) или mimalloc.
Что-то проблем я не заметил с ним
Программы, собираемые с musl, в среднем, на 60% медленнее работают, и malloc играет в этом не последнюю роль.
echo "/usr/lib/libmimalloc.so" >> /etc/ld.so.preload
в musl нет ld.so, это механизм специфичный для glibc))
> в musl нет ld.so, это механизм специфичный для glibc))А как динамические либы загружаются?
Некоторые странные люди ставят. Оно даже работает, браузеры из дистрибутива точно запускает.
Судя по тому, что у меня на десктопе, процентов на 80 меня бы удовлетворил.
На базе Alpine сделан postmarketOS который ставится на телефоны, планшеты и arm-лаптопы. На последних десктоп нужен.
я его 2 года как десктоп использовал, тяжело под musl всё пересобирывать, но быстр, и не требователен.
А как же gcompat?
Запускаю alpine по сети через ipxe на десктопе и остальных компах дома.
Удобно через dhcp опции+ipxe подсовывать параметры ядра, там их 2 основных:
modloop - где скачать полный пак модулей ядра и firmware.
apkovl - тоже самое для конфига системы.Если нужен glibc - запускаю в podman.
Пакетов завались, systemd отсутствует, че еще надо.
А кто запрещает? Это обычный линукс с busybox и musl.. Мда, десктоп - понятие растяжимое
как всегда у корпорастов в случаях подобного саботажа основная цель - сделать невозможной работу софта без их раковой опухоли. например:
- ядро пытаются сделать зависимым от раст и llvm
- Firefox это уже сделали
- весь линукс пытаются сделать зависимым от systemd (леннартушка уже официально работает в майкрософт), даже дистры на openrc сейчас завязаны на компоненты, выдранные из systemd. благо, пульсу уже ото всюду выпиливают, но сколько времени прошло
- то же самое происходит сейчас с вяленым
и как только такую необходимую (т.е. которую нельзя обойти) зависимость добавят - владельцы опухоли уже будут ставить свои условия, как было и с агентом мелкомягких в редхате
Clang - это лучший плюсовый компилятор, который есть. Именно благодаря ему при сравнительно компактных нескольких библиотеках я могу кросс-компилировать самые распоследние версии C++ под Arduino, Android, и OpenWRT роутер на ramips. При этом гигантский оптимизирующий компилятор на сотни мегов нужен только в одном экземпляре, а не куча говнотулчейнов, где в лучшем случае предсобранный компилятор поставляется, а в худшем - собирается из исходников, и во всех случаях - говномамонтавая версия GCC без новейших свистоперделок, из-за чего можно забыть о compile-time вычислениях хеш-сумм и compile-time парсинге грамматик с кодогенерацией из них, и всё делать скриптами, приклеенными на двухсторонний скотч.
GCC быстрее
Ну нет же
Компиляция в шланге незначительно быстрее, а скорость линковки через lld выше в десятки раз
Нет, наоборот lld - жутчайший тормоз (при -flto) и памятижор. Потому что там настоящая межмодельная оптимизация, сливающая LLVM IR, и уже его оптимизирующая
> Нет, наоборот lld - жутчайший тормоз (при -flto) и памятижор. Потому что
> там настоящая межмодельная оптимизация, сливающая LLVM IR, и уже его оптимизирующаяНу это при lto, чего gccшный линковщик просто не умеет, это отдельная фича
Also от -flto у тебя сильно растёт время, но не особо сильно растёт качество, -flto=thin даёт тебе 95% от скорости fat lto, но при этом оно скорее всего всё ещё будет быстрее чем gnuшный линковщик
Нахрена экономить? Программа компилируется один раз, а используется - много. И часто - сутками напролёт. Экономия на копейку - упущенных возможностей на рубль.
> Нахрена экономить? Программа компилируется один раз, а используется - много. И часто
> - сутками напролёт. Экономия на копейку - упущенных возможностей на рубль.Вопрос был в том кто быстрее компилирует
thin lto это самое то для того чтобы быстрее итерации при разработке требовательного к производительности кода производитьИ fat lto не экономит рубль, он очень медленный, и профита от него нет в сравнении с thin lto почти никогда
Даже наоборот, выхлоп с ним иногда медленнее из-за слишком агрессивного инлайна что не позволяет нормально работать branch prediction
> И fat lto не экономит рубль, он очень медленный, и профита от
> него нет в сравнении с thin lto почти никогда
> Даже наоборот, выхлоп с ним иногда медленнее из-за слишком агрессивного инлайна что
> не позволяет нормально работать branch predictionСлышь, эксперт опеннета! LTO - вообще не про инлайн как таковой. И даже не про скорость - сам по себе LTO скорость особо и не меняет. А вот размер бинаря может сдуть от трети до четверти, за счет мержа всего что можно (кода, констант, где валидно), очень расширенного обсчета dead code elimination и слияния кода, типа пропуска вгрузки констант, заметив что эн килобайт назад уже вгрузили удобное нечто в регисры и вот тут можно это пропустить. Но вот на именно скорость все это влияет от "никак" до "умеренно" (из-за уменьшения числа команд и меньшего выноса кешей). Но вот бинарник уменьшается хорошо.
> Ну это при lto, чего gccшный линковщик просто не умеет, это отдельная фичаGCC умеет LTO с этак версии наверное 4.5 аж, или типа того. И конечно его линковщик это тоже умеет.
А lld это вообше кусок странной кривизны.
> при этом оно скорее всего всё ещё будет быстрее чем gnuшный линковщик"хайли лайкли" очередной. Осталось еще сделать чтобы это lld не было куском глюкавого крапа. То что он тормозной это вообще ерунда по сравнению с тем что он вечно недопиленый и багованый.
GCC лучше оптимизирует.
GCC поддерживает больше процессорных архитектур.
GCCшники адекватнее компилируют UBшный код - в мире Си и Плюсов не сам, так другие его напишут или хуже того - проприетарный SDK выдадут с кривокосым кодом внутри.Главная полезность существования Шланга - это чтобы GCCшники не расслаблялись и не закисали.
> GCC лучше оптимизирует.Clang куда агрессивнее оптимизирует межфункционально и межмодульно. Да, UB на это вылезает и превращается use-after-free из-за дебилов. Good luck отладить этот говнокод, если не ты его написал, и если он сам ... не совсем исходник.
> GCCшники адекватнее компилируют UBшный кодЛол, нет
GCCшники в этом плане как раз самые отбитые и высасывающие трактовки из пальца, principle of least astonishment они не соблюдают примерно никогда
Сколько раз Торвальдс на них ругался когда они в очередной последний раз своими кривыми оптимизациями ломали ядро
>GCCшники адекватнее компилируют UBшный кодОх уж эти сишники. Единственная адекватная реакция на ub - ошибка компиляции, но только не у сишников. А так можно делать абсолютно всё что угодно, это будет абсолютно правильно. Ибо ни на си, ни на крестах писать не нужно, максимум несколько небольших библиотек, которые потом будут встроены как часть другого языка.
Толсто.>я могу кросс-компилировать
Поддержка платформ и архитектур в GCC шире.
>самые распоследние версии C++
В GCC как правило значительно быстрее реализуют фичи из новых стандартов.
>куча говнотулчейнов, где в лучшем случае предсобранный компилятор поставляется, а в худшем - собирается из исходников, и во всех случаях - говномамонтавая версия GCC без новейших свистоперделок
Вообще хз, что это за набор слов. Пишу с Gentoo, с установленным GCC 15.1. УМВР. На всяких арчах, уверен, тоже поставляется свежачок. Переедь с древнего дыбиана 9 на что-то поновее и таких проблем не будет.
>из-за чего можно забыть о compile-time вычислениях хеш-сумм и compile-time парсинге грамматик с кодогенерацией из них
Это видимо было вброшено, чтобы коммент звучал поубедительней. Судя по кол-ву лайков - даже сработало.
> гигантский оптимизирующий компилятор на сотни мегов нужен только в одном экземпляре,Ты его собирал хоть раз?
В том и хохма, что под капотом там такие же специфичные говнотулчейны, просто склееные в один монолит. Добавление каждой архитектуры пропорционально увеличивает время сборки. Пересборка LLVM с другим списком архитектур ломает фронтенды, слинкованные с предыдущей конфигурацией.
Да, собирал, и мой патч - уже в апстриме.>Добавление каждой архитектуры пропорционально увеличивает время сборки
Ты думаешь, что можешь обмануть линейную функцию y = k * x + b? Да, увеличивает. Но есть нюанс. b больше, k - меньше, по сравнению с gcc, у которого k сравнима с b, потому что каждый компилятор сам по себе. А сам по себе он из за причин GPL-копирастии - копирасты так боялись, что их "интеллектуальную собственность" "своруют" конкуренты, что намеренно спроектировали так, чтобы их "интеллектуальную собственность" можно было использовать только путём форка компилятора, чтобы потом гордо заявлять о победном шествии GNU GPL по планете. А конкуренты просто взяли и выкинули gcc почти целиком на свалку истории. Даже стандартная библиотека C++ от него не особо нужна. Система называется "назло маме отморожу уши".
P.S. Так как в CMake вот уже давно есть юзабельные модули, то жди сокращения времени компиляции потребления памяти в каком-нибудь будущем.
>GPL-копирастии - копирасты так боялись, что их "интеллектуальную собственность" "своруют" конкуренты, что намеренно спроектировали так, чтобы их "интеллектуальную собственность" можно было использовать только путём форка компилятора, чтобы потом гордо заявлять о победном шествии GNU GPL по планете. А конкуренты просто взяли и выкинули gcc почти целиком на свалку истории.Страшные ужасные гпл-щики, неизвестные абсолютно никому за пределами it сферы, обижают многомилиардные корпорации типа огрызочников и мелкомягких.
>Система называется "назло маме отморожу уши".Вы явно не тем сочувствуете. У огрызочников и мелкомягких денег и без вас куча, и делится деньгами они явно не собираются.
Просто загляните в историю «поддержки» (финансовой) GNU, и поймете, что она выгодна крупным корпорациям. Я уж молчу, что позиция «корпорации — зло» абсолютно примитивна
В нормальном мире это нормально.
Хоть в ынтерпрайзном мире, хоть в пионерско-васянском.Нету такого, чтобы всё делали под всё.
Это бессмысленно. Единственный минус — это недовольный 1%. Но это трудно назвать минусом.
для корпорастов да, не минус, но меня их мнение и цели мало колышут, у меня свои есть
> но меня их мнение и цели мало колышут, у меня свои естьОно и видно. Поэтому они могут впихнуть раст и llvm в ядро.
А ты - ныть на форуме))
а ты продолжай быть бесплатным "приложением" :)
А еще, снижение затрат на поддержку за счет увеличения затрат пользователя на железо и ЭЭ.
Бред. Это опенсорс, исходники всего ПО открыты. Если копрорасты начнут диктовать условия, свободное сообщество сразу же форкнет их продукты или сделает альтернативу с нуля.
> Это опенсорс, исходники всего ПО открыты.
> Если копрорасты начнут диктовать условия, свободное сообщество сразу
> же форкнет их продукты или сделает альтернативу с нуля.Так толсто, что аж тонко. Мое почтение!
Иксы "свободное сообщество" уже форкнуло)
иксы форкнули, опеноффис форкнули
Слезьте с Пентиума, а потом я попытаюсь начать воспринимать вас всерьёз. Может быть.
>Предполагается, что оставление в дистрибутиве только компонентов, необходимых для Wayland и Xwayland, сократят затраты на сопровождение X11-приложений в Alpine.Предлагаю оставить в дистрибутиве 0 пакетов. Затраты на сопровождение кардинально сократятся.
кстати да, почему бы не вшить вяленого сразу в ядро
Не волнуйся, вошьют прямо в прошивку для GPU. Хотите десктоп, совместимость с программами - купите новый GPU.
Да уже давно: https://hub.docker.com/_/scratch
Теперь нужно написать ещё и WayXorg для запуска Wayland-only приложений на XLibre/X11
То же самое хотел сказать. Сабж сделан для того чтобы на Linux под Wayland запускать среды рабочего стола, которые ещё не перенесли с иксов на Wayland.
Нужна обратная штука, для запуска сред рабочего стола только под Wayland, там где его нет, но есть иксы, к примеру BSD (FreeBSD), illumos (Openindiana).
Запускаешь Weston, распахиваешь на весь экран, профит.
Но они первым делом же выкинули XWayland в своём форке. Что мне показалось очень странным.
Это нет тот дистр в котором даже сортировку вывода в пакетном менеджере не осилили?
У тебя GNU sort сломался?
У меня нет, а вот у создателей Alpine он похоже как сломался 20 лет назад, так до сих пор починить и не могут.
алпайн по сути используется для контейнеров и встраиваемых систем, там от пакетника требуется только ходить на зеркало и забирать оттуда свежие тарболлывам надо - делайте надстройку, хоть полноценную, хоть башпортянки, в апстриме это не нужно просто
Wayback переводится как "Путь Назад", но зачем? Просто надо всего навсего пользовательские приложения переписать чтобы они поддерживали нативный Wayland.
> Просто надо всего навсего пользовательские приложения переписатьЕсли это так просто, куда вам выслать список приложений? И да, - на оплату не рассчитывайте
Любой тред должен оплачиваться.
Пусть твои любимые корпорасы оплачивают.
> Любой тред должен оплачиваться.Вот именно, т.к. это далеко не "запросто"
Если это не костыль в виде XWayland, то профит будет!
Получится XServer без DDX-драйвера.Хотя... скорее всего выйдет фигня, modesetting вышел лютым тормозом (как и mesa в режиме 2D-only) и юзать DDX при первой возможности смысл есть.
Modesetting быстрее, у тебя что-то сломано. DDX давно прикопали, а что за режим 2д в мезе - вообще не понятно.
>> а что за режим 2д в мезе - вообще не понятноВидео 360 надо в 2D наверное глянуть
> Modesetting быстрееНа современных nvidia/amd возможно и непонятно что и где быстрее. У меня modesetting, т.к. сделал себе prime и иначе никак...
Но на слабых картах сравзу видно, что даже кривой и недоделанный ddx (для чипов arm) уделывает modesetting (возможно тоже кривой и недоделанный).
В итоге:
- на ARM нихрена не быстрее (ну примерно на orange pi 3 разница хорошо видна, возможно и драйвер кривоват; а возможно прямее и не сделать);
- на intel тоже sna быстрее (на чипах уровня sandy bridge точно); на skylake/kabylake по ощущениям тоже, хотя тут могу и ошибаться;
- на maxtor (прости гаспаде) ddx тоже быстрее (там modesetting получается со скоростью vnc, поэтому формально "быстрый vnc на maxtor" действительно быстрый ;) но ddx локально гораздо более отзывчивый чем modesetting и чем vnc).
Как сравнивал?
Если нужны попугаи - x11perf и glmark (в 3D обычно 5-10% разница и там от ddx почти ничего не зависит, на быстрых картах разницы считай и нет). На orange и maxtor (у которого вообще никакого 3D нет) лаги десктопа на глаз видно (перетаскивание окон, например). Композитный режим на медленных картах обычно отключается (тот же kwin вообще неюзабельным становится но если отключить композитинг, то вполне норм).Пару лет назад ещё дикая посадка при просмотре видео была, но это вроде пофиксили (там шейдер перекомпилировался на каждый кадр и загрузка cpu сильно выше получалась).
На стареньком интеле gma получал разницу в около 30%, не в пользу иксов с ddx. Тестил на демке в игре.
Если игра 3D, то там не в ddx дело, а больше в версии dri и всяких опциях tearfree и triplebuffer.Производительность ddx - это fillrect, bitblit и прочее. Вот с ними у modesetting трабла. Делается на opengl в 3d-режиме с z-координатой равной нулю, ну или каким-то подобным образом. А вот версия intel-ddx для sna пытается акселерацию 2D-операций сделать более оптимально (хотя отчасти и использует блоки 3D-ускорения и много чего делает не на видюхе, а на CPU без ускорения).
Да, игра 3д, опции разные пробовал. Смысл в этом ddx, если производительность нужна именно внутри софта, а окошки не тормозят даже на железе лет 20. Разве что энергопотребление снижать, но это слишком затратно по коду, никто не будет адаптировать столько железа. Есть 3д api и его юзают. Зато видосы теперь эффективно выводят 2д блоками, которые делают format и scale, а иксы с 2д такого никогда не умели.
> Да, игра 3д, опции разные пробовал. Смысл в этом ddx, если производительность
> нужна именно внутри софта, а окошки не тормозят даже на железе лет 20.А никакого смысла нет. Поэтому современные дистры - юзают generic KMS. Учитывая что у иксов архитектура к современным GPU не подходит вообще никак - толку от DDX ускорения минимуму. И зачастую это даже тормознее generic KMS.
> его юзают. Зато видосы теперь эффективно выводят 2д блоками, которые делают
> format и scale, а иксы с 2д такого никогда не умели.Видосы теперь выводят - как частный случай 3D и текстур, блин! Потому что так быстрее и как раз не надо с Xorg связываться.
По дефолту в Xorg - вся графика in band толкается. В протоколе. И все гигазы кадров надо парсить от и до. Что, ессно, дико грузит проц и тормозит.
Согласовать что-то более эффективное - хотч-бы shared mem - это опционально и надо отдельно заморочиться.
Xvideo и Xv творят какую-то дичь, страшно далекую от того что плееры бы хотели. И CPU Usage Xv - раза так в 3 выше чем если на Xorg забить и спихивать видео как текстуры в 3D OpenGL или Vulkan в обход тех чудных интерфейсов как раз. А до кучи если плеер крутой может еще чего шейдерами посчитать, типа постпроцесинга или яркости какой. Но это уже навороты. Факт в том что даже вообще совсем 2D - быстрее через 3D пайплайн выходит :\. Надеюсь эот объясняет почему рхбм так иксы не жалует.
На дешёвых арм чипах не потянет вывод видосов в 3д, а иксы не смогут вывести их правильно в 2д из-за своего главного недостатка - они пихают всё в один буфер, для видео нужен отдельный буфер с другим форматом пикселей. Ещё батарейка страдает от 3д постобработки видео.
> Xvideo и Xv творят какую-то дичь... CPU Usage Xv - раза так в 3 выше чем если на Xorg забить и спихивать видео как текстуры в 3D OpenGL или VulkanЗависит от железа. Для того же intel есть несколько вариантов. На любимом всеми pentium4 будет какая-нибудь i865g и там не tmu хитрый, а как раз таки yuv-оверлей. А в шейдеры оно не умеет принципиально...
Примерно с i965g уже будет textured video. А на i915 можно и шейдер сделать при желании. Pixel shader 1.0 должно хватить. А можно и через оверлей.Иногда доступно несколько вариантов, какой из них более кривой - от адаптера Xv (ну и драйвера) зависит, иногда можно и оба. Иногда один из вариантов вообще всё вешает намертво и не работает (тут надо драйвер пилить, или правильный адаптер выбрать в плеере)...
В KMS с оверлеями как-то очень плохо всё. Там курсор не везде сделан, про yuv лучше не вспоминать...
> - на ARM нихрена не быстрее (ну примерно на orange pi 3
> разница хорошо видна, возможно и драйвер кривоват; а возможно прямее и
> не сделать);А что ты на ARM запускал без modeset? Там же дрова контроллера дисплея KMS/DRM как правило - и даже если это фирмварный фреймбуфер, его какой-нибудь simpleDRM в итоге рюхнет. Который тоже KMS/DRM.
Ну и у фреймбуфера скорость так то - норм вполне. Если это не x86 с его реальным режимом и лазанием туда через VBE какой-нибудь, что конечно дико тормозно - из-за переклчюения в реальный режим x86 для вызова BIOS - что конечно полный ад по скорости действа.
> - на intel тоже sna быстрее (на чипах уровня sandy bridge точно);
На практике - глюки DDX всех так достали что иксы в большей части дистров оставили generic KMS и никто не заметил особой разницы.
> - на maxtor (прости гаспаде) ddx тоже быстрее (там modesetting получается со
> скоростью vnc,Это вооюще что? Зенитар залогинься!
Это уже дружественно-перекрёстный огонь какой-то. Вместо вроде как предполагаемой стандартизации. Лоскуты только множатся. Ну, Линукс же не умеет по-другому.
Лебедь, рак, щука, лебедь №2, щука-не щука, двойной рак, зелёные человечки, шляпа волшебника, рак-рак-щука-рак-безлебедь...
Выдыхай!
Собрал под арчем. wayback -- startlxde
Запускается окно и сразу "Аварийный останов"
Аварий останов кого? Что будет если запустить другой менеджер? Что будет, если запустить условный xterm, а уже после него оконный мененджер?
> Аварий останов кого?wayback. Закрывается его окно. Запускаю из labwc
>Что будет, если запустить условный xterm, а уже после него оконный мененджер?Если запустить wayback -- xterm или сразу wayback -- lxpanel (gtk3) - lxpanel запускается через Xwayland.
Причем если killall wayback - wayback убивается, а lxpanel остается.
Т.е. пока не вижу разницы между
wayback -- lxpanel
и
GDK_BACKEND=x11 lxpanel
>Если запустить wayback -- xterm или сразу wayback -- lxpanel (gtk3) - lxpanel запускается через Xwayland.Ну значит надо копать, что там сломали в startlxde. Подозреваю, что там вручную xorg запускается, чего быть не должно.
>Т.е. пока не вижу разницы междуРазница должна быть в DISPLAY - в первом случае он должен быть вложенным и созданным wayback, во втором - хостовым. Хостовый может не работать, например, если в вейленде запустить xwayland, то захват экрана работать не будет, а у вложенного - будет.
Я нечто подобное руками делал, но в sway, работало как часы.
Достаточно просто загуглить Ariadne Conill и всё станет ясно. "If anyone merges XLibre i will be pursuing a code of conduct violation against them. This is about politics, not just software". Ariadne Conill важная шишка в альпайне. Страшно становится. Они там скоро будут отклонять банковские карты, если ты не тех политических взглядов
Видишь аватарку с аниме у разработчика - сразу с ним становится всё понятно XD
Там все горазде печальнее.
Было интервью 😁
Низкоуровневое программирование прямо наполнено маргинальными элементами
Я на ютюбе нашел видос "Interview with Ariadne Conill Part I". Это жесть.
> Они там скоро будут отклонять банковские карты, если ты не тех политических взглядовБанк вообще может в обслуживании отказать и без объяснения причин. Просто приходит письмо: заберите ваши деньги, с такого-то числа мы вас больше не обслуживаем. Так, к слову. Счёт в банке это привилегия, а не право. А на счёт политики, ну попробуй открыть счёт для какого-нибудь ку-клус-клан инк., расскажешь потом как прошло.
> Достаточно просто загуглить Ariadne Conill и всё станет ясно. "If anyone merges
> XLibre i will be pursuing a code of conduct violation againstВстретился как-то гендерфлюид с антипрививочником. Это примерно как вещество с антивеществом повстречать. Т.е. в этой ситцации надо молиться всем богам в которых вы верите и максимально быстро оттуда у...ть!
ещё один полный невиновник?