Проект Xfce4 разрабатывает собственный Wayland-композитор

Такого кода не может быть в принципе из за совершенно разных подходов в языках.

Ответ неверный. Ты код не пишешь, поэтому не понимаешь. Алгоритмическая идентичность - обычное дело при переписывании проекта на другом языке.

Вероятно неоптимально, но также там нет легаси и чёртовой тучи функционала на все случаи жизни.

Именно поэтому оно и будет неоптимально - в нем нет оптимизаций под платформы, нет тонкой настройки алгоритмов под конкретные ситуации и прочего, прочего. Самые дубовые решения, как правило, и являются самыми неэффективными.

И я не утверждал что «всё жирное», я написал «до 10 раз», что никогда и нигде не значило «в 10 раз».

Ты просто опять начал юлить и изворачиваться. С тем же успехом ты мог бы написать «до 100000 раз», а потом бегать с этим утверждением. И плевать, что в реальности этого нет - ты же обозначил лишь верхний предел.

Нет, это так не работает. Обозначая верхний предел, ты должен опираться на реальные данные. Иначе верхний предел можно выдумать любой. Так что я всё еще жду пруфов.

Тем блоее статическая линковка в системе с динамической - определённо вызовет серьёзный скачок потребления.

Эта проблема несущественна за пределами мобильных устройств - на десктопах и серверах достаточно памяти, чтобы можно было ей немного пожертвовать ради безопасности.

Для более сложных случаев, как я уже сказал, пишут динамическую линковку.

я перестал ставить тебе клоунов, а ты продолжаешь не только отвечать, но и бросаться клоунами

www.linux.org.ru/reactions?topic=18205991&comment=18206720 21:37:18 UTC

www.linux.org.ru/reactions?topic=18205991&comment=18206716 21:28:31 UTC

Временной лаг не больше среднего интервала между сообщениями, так что хватит ныть.

Временной лаг не больше среднего интервала между сообщениями

Мне не интересен твой скулеж на эту тему, клоун. Время значительное, чтобы заметить происходящее. Факт остается фактом: интервал значителен, брехня подтверждена: ты продолжал ставить клоунов, как только видел сообщения, даже не читая их. В апелляции отказано.

Так что я всё еще жду пруфов.

У тебя есть пруф с новым пределом: в 5 раз. Потому что оно дубовое и неоптимальное, и там нет глубокой оптимизации 3 несовместимых между собой api трея и отдельно апплета уведомлений и ещё календаря, интегрированного с каким нибудь центром задач - там вообще ничего из этого нету, а ведь в каком нибудь КДЕ это всё лишний десяток-другой-пятидесятый мегабайт. Но оно и без того жирнее КДЕ. Аналогично звук, аналогично меню, аналогично системный монитор в панели, и всё-всё-всё. Думаю логичней было бы сравнивать с Колибри.

Эта проблема несущественна за пределами мобильных устройств

Сейчас мобильные устройства настолько нафаршированы памятью и настолько неоптимально её используют, что серверам может быть завидно.

У тебя есть пруф с новым пределом: в 5 раз.

Никакого пруфа нет. Есть оценочное суждение «5 раз больше чем всё это может весит». Сравнивать не с чем. И мой аргумент про экспериментальное ядро делает твое утверждение еще более несостоятельным.

Потому что оно дубовое и неоптимальное

Допустим. Значит, проблема не в расте, а в том, что это новый, свеженаписанный код без оптимизаций. Весь софт через это проходит.

Сейчас мобильные устройства настолько нафаршированы памятью

Тем более. Это делает мою точку зрения еще более прочной.

Код без оптимизаций обычно всё таки не содержит хренову тучу ненужных структур данных из за чего жрёт в разы больше со старта. Допустим тормоза, вылеты, утечки памяти - логично. Кратный жор? нет.

Кратный жор? нет.

Еще раз повторяю:

1. Неоптимальное управление памятью в ядре.

2. Свеженаписанный код.

3. Повальная статическая линковка всего и вся.

Ты недооцениваешь третий пункт. Статический код очень, очень жирный.

Да и вообще странно сравнивать потребление готового десктопного линукса, годами пилившегося до удобоваримого состояния, и потребление в ОС, написанной как proof-of-concept. Она буквально предназначена для того, чтобы выловить на ней все возможные проблемы разработки десктопной ОС на расте. Именно поэтому динамическую линковку для него сейчас и пилят.

Если бы ты слинковал статически каждое приложение даже в каком-нибудь Xfce, ты бы удивился, насколько результат был бы близок к редоксу. Динамическая линковка сокращает потребление памяти в разы, потому что либа зависимость загружается в память один раз, а дальше используется всем системным софтом. В память будут догружаться только бинарники и те либы, которых не хватает.

А растовый код тащит все зависимости с собой. Никакого разделения ресурсов между бинарниками тут не будет.

Основная масса ретроградов консерваторов должна была свалить еще после выхода 4.12, когда началось переписывание компонентов на gtk3

А куда свалить то? Больше нормальных DE нет, везде гномосеки какие-то пузырятся. Можно конечно и без DE, но это на любителя. Я стал xfce использовать как раз с 4.14, когда там допилили композитинг, и стало возможно просто использовать wm без красноглазого кривущего picom.

А куда свалить то?

На KDE, очевидно.

Больше нормальных DE нет, гномосеки какие-то пузырятся

Дякую, Боже, що я не гномохейтер

Просто wc, если вы понимаете, о чём я.

Утилита wc уже есть в Linux, и она от слов «world counts».

Минт без Xfce не останется, даже когда весь линукс на вэйланд переедет.

Главное, чтобы без Mate не остался. XFCE ведь другие люди делают, а они лишь добавляют себе.

Сервера с терабайтами оперативы, а десктопы с гигабайтами, разница как раз в 1024 раза.

А как сравнивал? Мой вопрос ещë и про это.

Если приложение поддерживает - работать будет.

В том-то всё и дело, что не поддерживает. Я сворачиваю туда браузер, в котором запущено веб-приложение. В иксах для этого есть программа (я две нашёл), которая так может сделать. В Wayland композиторе нужно либо ждать милости от разработчика, либо пилить поддержку в композиторе самому (а потом скорее всего поддерживать патч, потому что его скорее всего не примут), либо пилить поддержку в браузере (а потом скорее всего поддерживать патч, потому что его скорее всего не примут), либо делать своё приложение на Electron (а потом поддерживать его, потому что кому такой чемодан ещё нужен).

В иксах я потратил на всё в сумме где-то день, наверное. С тех пор пользуюсь. Обновления браузера и DE ничего не сломали. А сколько понадобится, чтобы реализовать мою хотелку в Wayland? Месяц? Два?

Upd. А если я захочу потом сменить DE, то если функциональность была в композиторе, придётся реализовывать всё заново в новом.

Лучше бы тиринг под иксами в xfwm побороли.

vblank_mode glx (или xpresent) в настройках Xfwm не помогает? Мне еще помогало включение TearFree в Xorg.conf, но это на амд.

Больше нормальных DE нет

А какие критерии?

я сначала нажал PrintScreen, выбрал задержку, что именно фоткать, открыл меню

Когда вялендовцы говорят, чо большинству не нужно сохранять положение окон - у иксофанатиков начинается тряска. Когда я вам говорю про хоткеи в меню - НИНУЖНО.

Так получается в вялом работает сохранение положений окон? Просто запоминаешь где они размещены были и туда их и перетаскиваешь. :-)

Я в иксах крыску гоняю, никаких тирингов.

А сколько понадобится, чтобы реализовать мою хотелку в Wayland? Месяц? Два?

Я нагуглил целых два решения за пять минут. Проверять не стал.

• https://github.com/luisbocanegra/kwin-minimize2tray

• https://github.com/mbt/alltray/issues/10

Держи: https://www.youtube.com/watch?v=73MYSgOgawo

Любитель С принес нейрослоп, ктоб сомневался.

Очень не очевидно, там сейчас с поддержкой и вайланда, и Х треш творится. По старой доброй традиции КДЕ6 можно будет пользоваться где то к версии 6.14-6.20, за полгода до того как они снова всё сломают.

Очень просто - смотрел на потребление памяти свежезапущенного пустого ДЕ и пустого ДЕ после какого то времени работы, где нибудь перед выключением. 150/450 это холодное состояние, растёкшееся и горячее побольше, но примерно в том же соотношении, если данные не вытеснены в своп. Да, оба на х86_64, версия 4.8 на armhf где то примерно 80-100М, с возможностью работать отсвопившись до ~60М.

Отличные новости для тех, кто использует KWin. А кто не использует, лапу сосёт?

И ещё мне кажется, что по второй ссылке костыль будет работать только для X11 приложений. Как только в приложении окончательно угробят X11, всё.

А когда в вайланде фокус с открытого меню перестанет убегать при неосторожном движении?

там сейчас с поддержкой и вайланда, и Х треш творится

Конкретизируй. Я уже год на вяленом сижу без всяких проблем.

Отличные новости для тех, кто использует KWin.

А тебе нужно что-то еще? Чем меньше останется велосипедов в линуксе - тем лучше. От этого выиграют все: качество кодовой базы оставшихся проектов вырастет, число разрабов тоже. В идеале, гном и гтк должны умереть в пользу KDE и Qt.

Только что открыл меню, увел мышку. Фокус остался, навигация стрелками работает. ЧЯДНТ?

Я не помню, но судя по тому, что закончилось всё перекатыванием на кеды – либо не помогло вовсе, либо помогло, но вызвало иные проблемы. При этом крыса мне во всём остальном нравится.

В идеале, гном и гтк должны умереть

Ага, и системд. Скорее вместо гнома могут пропихнуть космик. У кдешников единственный шанс – быстренько переписать всё на раст. Хотелось бы на это посмотреть, но опасаюсь ожирения от такого объема попкорна.

Поменяй местами KDE/Gnome и Qt/GTK в своих высказываниях. Если чувствуешь скрежет своих зубов, значит ты что-то неправильное сказал.

Зачем мне менять одну точку зрения на другую? Очевидно, я приверженец первой, а не второй.

Должен напомнить, что Qt когда-то был проприетарной разработкой.

Ну был и был, дальше-то что?

Он просто предложил тебе посмотреть в зеркало.

Неужели нельзя просто пользоваться тем, что нравится, без желаний поднасрать другим людям?

А где ты видишь желание поднасрать другим? Я же не хожу портить код в гном. Пусть делают, что хотят. Но опенсорс действительно страдат от ситуации «есть N решений, почти одинаковых, но немного разных», на поддержку которых тратится неуемное количество усилий. Если бы разработчики объединились, от этого бы выиграли все.

При этом я понимаю, что подобное вряд ли возможно, и те же гномеры скорее предпочтут пилить что угодно, кроме гнома, но не KDE. Так что я просто остаюсь при своем мнении.

Тогда уж скорее полезнее было бы, если бы сдох Qt) Объектная система GObject офигенно удобна в плане взаимодействия разных языков и платформ. Приложения для экосистемы Гнома могут быть написаны буквально на чём угодно, от Си до JS. Соответственно, программисты самых разных специализаций и квалификации могут вносить свой вклад. А Qt - царство С++ и только С++. Сдохнет Гном и ГТК, и что, всем плюсы осваивать?

Это гепотетически, если что. Я желаю и GTK, и Qt всяческого процветания и долгих лет жизни.

Тогда уж скорее полезнее было бы, если бы сдох Qt

Нет, потому что Qt, в отличие от GTK и сопутствующих велосипедов, является фреймворком с кучей модульных компонентов, а не ограниченным графическим тулкитом.

Приложения для экосистемы Гнома могут быть написаны буквально на чём угодно, от Си до JS.

На Qt, в общем-то, то же самое, только от языков нужен ООП.

А где ты видишь желание поднасрать другим?

В пожелании смерти проектам, которыми пользуется много людей.

Но опенсорс действительно страдат от ситуации «есть N решений, почти одинаковых, но немного разных», на поддержку которых тратится неуемное количество усилий. Если бы разработчики объединились, от этого бы выиграли все.

Если хочешь, чтобы у тебя всегда была возможность пользоваться тем, что тебе нравится, то быстро оказывается, что некоторое количество «велосипедов» всё-таки необходимо. А то может выйти так, что «единым» решением станет то, которое тебе сильно не по нраву.

Короче говоря, должна быть конкуренция идей и реализаций, для чего необходимо иметь альтернативы, а вопросы совместимости решать внедрением общих стандартов.

Я согласен, что проблема фрагментации есть, но её решение — точно не в попытке загнать всех под одну гребёнку.

на поддержку которых тратится неуемное количество усилий. Если бы разработчики объединились, от этого бы выиграли все.

Это не игра с нулевой суммой.

Это не игра с нулевой суммой.

О чем я тоже там же написал.

В пожелании смерти проектам, которыми пользуется много людей.

Если покрыть их юзкейсы, хуже им не станет. Наоборот: вырастет стабильность и фичастость. Конечный юзер только выиграет. Так что это не желание поднасрать, а желание сделать всем хорошо.

А то может выйти так, что «единым» решением станет то, которое тебе сильно не по нраву.

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

Я согласен, что проблема фрагментации есть, но её решение — точно не в попытке загнать всех под одну гребёнку.

А каким ты видишь альтернативное решение?

Вот со всем кроме последней строчки согласен. Не считаю, что проблеме фрагментации нужно решение в принципе. А точнее, что фрагментация является проблемой. Это, наоборот, одна из сильных сторон опенсорса.

Ты там написал чуть ли не кальку с мема «наша святая земля vs. их варварская пустыня».

Так что это не желание поднасрать, а желание сделать всем хорошо.

И тебе это точно под силу. Ведь ты и самый умный на свете и самый мудрый и твой код совершенен и безупречен, так как ты тру-программист без устали плотно обмазываешься. Проверками. Твоё могущество просто безгранично.

А ещё ты инженер. И твой код — продуктовый, как же я тобой восхищаюсь, ты очень, очень-очень крутой! Ты — самый лучший!

Ты не обижайся, но очень удобно любую точку зрения на сравнение двух продуктов свести к этому мему.

Есть разница между «мне нравится вот это» и «гномеры скорее предпочтут пилить что угодно, кроме гнома, но не KDE». Второе унижает разработчиков, которые занимаются Gnome, причём просто на основе того, что они занимаются Gnome.

Нет, не унижает. Я сказал, буквально, что они принципиально хотят пилить гном, и не захотят пилить KDE, потому что, очевидно, идеи гнома им ближе, чем идеи KDE.

И простите, что я не разделяю идеологию выпиливания фичей, кастомизации и псевдо-ux/ui. Чего только стоит отключение буфера обмена средней кнопки и запрятывание этой функции в gconf (или как оно там у них называется), потому что «X11ish». А еще запрет обсуждения этого на гитлабе, ага. И в гноме всё вот так.

Если покрыть их юзкейсы, хуже им не станет. Наоборот: вырастет стабильность и фичастость. Конечный юзер только выиграет. Так что это не желание поднасрать, а желание сделать всем хорошо.

Это только на бумаге легко и просто — всего-то «покрыть юзкейсы». Совместить же в одном проекте настолько разные подходы к проектированию как интерфейсов, так и ПО в целом, просто нереально. Я бы ещё поверил в KDE и Cinnamon, но точно не KDE и GNOME.

Мои рассуждения базируются на том, что Qt объективно технически лучше

Оооочень спорное утверждение. Чего стоит только параллельное существование двух (на самом деле трёх) тулкитов в одном фреймворке: Qt Widgets и Qt Controls 2 на QtQuick; а KDE-шники ещё и поверх последнего свой Kirigami натянули. При этом:

• Qt Controls 2 умеет в scenegraph, а Qt Widgets нет.
• Qt Controls 2 умеет в кинетическую прокрутку на тачпаде, а Qt Widgets нет.
• Qt Widgets имеет богатую коллекцию десктопных виджетов на все случаи жизни, а Qt Controls 2 нет.

В результате имеем типичный зоопарк: часть приложений на Qt Widgets, часть на Qt Controls 2, и поэтому та же кинетическая прокрутка в части приложений работает, в части не работает — а иногда и работает, и не работает даже в рамках одного и того же приложения (например, Параметры системы aka System Settings). И ещё куча других несоответствий во внешнем виде и поведении.

Почему-то в тот же GTK смогли добавить GSK, не сделав полностью новый тулкит, да и кинетическая прокрутка почему-то работает везде, а не только в половине приложений.

А каким ты видишь альтернативное решение?

Я же там же и написал: внедрением общих стандартов.