LINUX.ORG.RU

Снова cinnamon, теперь с XLibre

 , ,


0

1

В общем, решил я ради прикола поставить гном и удалить, в итоге гном мне всю систему похерил. Решил переустановить и чё-то так в моменте лень стало снова bspwm настраивать, что я махнул ручкой и поставил Cinnamon. Всё так же приятен, всё так же прост, всё так же удобен, но теперь с XLibre.

Тема – mint-y, иконки – mint-y, занимаюсь в этой системе всякой безделухой в godot’е, иногда в супертукскарте залипаю. В этот раз без блюра, ибо и систему грузит и нестабильный совсем.

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



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

занимаюсь в этой системе всякой безделухой в godot’е

Будешь что-нибудь в паблик выкладывать?

hobbit ★★★★★
()

воид как установить? Можно ли без загрузки с usb?

какие плюсы воида?

cetjs2 ★★★★★
()
Ответ на: комментарий от TechnoMag

Если специально не кастрировать кастомизируя, они все сейчас жрут

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

А вот к процессору корица требовательна. Вернее глядя на долбёж процессора и sysprof, видно что обновление региона экрана через cogl сопровождается какой-то лютой долбёжкой процессора, в смысле процессорного времени. По сути ну вот переместил я окно, область перемещения известна и нужно перерировать только эту область, и почему-то, это долбит проц, хотя cogl же должен это аппаратно сделать через opengl. Короче, над производительностью Muffin и чё там под ним, надо поработать, что-то там слишком много вычисляет, но вот что и где и почему конкретно пока не понял 😢

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от AZJIO

В интернете полно материала для начинающих, всё-таки популярный софт.

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

Самое сложное это скриптование, но даже тогда можно использовать альтернативные языки, если не хочешь писать на питоне.

Bfgeshka ★★★★★
()
Ответ на: комментарий от Bfgeshka

полно материала

Да я тут же нашёл видосы и весь расклад, просто сообщение уже не поправить. Не, там надо быть именно заинтересованным в разработке игр. Хоть движок и упрощает, но не отменяет знания подноготной.

AZJIO
()
Последнее исправление: AZJIO (всего исправлений: 1)

что-то много народа стало пользоваться войдом… Тоже чтоли его попробовать? Какие у него плюсы по сравнению например с Alpine? Можно ли поставить его с openrc вместо runit?

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

По сравнению с Alpine можно выбрать между glibc и musl, однако система инициализации только runit. Из плюсов: довольно стабильный роллинг, годный пакетник, runit хорош и прост в использовании. Минусы: скромные репозитории

KvasPatron
()
Ответ на: комментарий от LINUX-ORG-RU

и почему-то, это долбит проц, хотя cogl же должен это аппаратно сделать через opengl.

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

AleksK ★★★☆
()
Ответ на: комментарий от TechnoMag

Конечно, он же по сути Gnome Shell, поэтому и говорю, что это гном здорового человека. Зато им приятно пользоваться.

NeTC ★★★★★
()
Ответ на: комментарий от NeTC

Я бы так не сказал, абсолютно отвратительно работает композитный менеджер, на старых встройках интел (pentium g 2020/3020) постоянно отваливается, поменял на кеды и все стало отлично.

AleksK ★★★☆
()
Ответ на: комментарий от AleksK

Ну, мы тут не с кедами сравниваем). И кеды хороши, и синнамон хорош на самом деле. Хотя я бы для себя предпочёл Xfce;)

NeTC ★★★★★
()
Последнее исправление: NeTC (всего исправлений: 1)

решил я ради прикола поставить гном и удалить, в итоге гном мне всю систему похерил

Жизненно. Сам с таким столкнулся недавно.

Mishahack
()
Ответ на: комментарий от AleksK

Так это типичное поведение иксов.

Нет, не выдумывай и не преплетай. В mate вообще полностью программный композитор и всё летает. Так что это лишь вопрос реализации не более того.

В вейланде композитор

Нагружает систему ещё больше, при этом долбит не только CPU но и GPU.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

В mate вообще полностью программный композитор и всё летает.

Главное не смотреть загрузку проца

Нагружает систему ещё больше, при этом долбит не только CPU но и GPU.

Для любителей рассказывать про «тяжелый» wayland записал видео. Gnome, в браузере 4К видосик, двигаю окошки, при этом ещё и само видео с 2К экрана пишется. Нагрузка на проц 3-5 процентов.

https://cloud.mail.ru/public/v5TQ/Q2UdNhhwD

AleksK ★★★☆
()
Ответ на: комментарий от AleksK

На твоём железе всё что угодно будет мало грузить систему, из за большого запаса вычислительной мощности, твои 5% это 100+% от моего APU E-450, а я могу говорить всё только относительно моего железа, и всё что я говорю справедливо относительно него. Ну и мы начали уже говорить о разном. Я о том что в muffin CPU time стабильно высокий. Вялый там или иксы значения не имеет, вялый просто всегда дополнительно грузит гпу (его любой композитор грузит, что иксовый что вяленый, но вялый грузит дополнительно)

Можно сколько угодно спорить, но я вижу в профайлере явно излишнее время занятия процессора для cinnamon и это выражается буквально в лагах, когда это время занято другим ПО, и я не вижу этого времени в других реализациях искового окошкотаскания, xfce4, mate, там всё всегда максимально отзывчиво при любой нагрузке процессора.

Следовательно есть проблема конкретно в muffin или одной из его зависимостей clutter/cogl/etc или/и где-то там избыточность, не эффективные вызовы while(100500){} диверсия или типа того.

Спасибо за видео, но всё что я узнал это что на мощной системе ничего не лагает. Замечательно, ещёб там что-то лагало =)

Я на своём основном компе, тоже никаких проблем не замечаю, он хоть и старый, но проглатывает всё влёгкую, ноль проблем. Всё проявляется на слабеньком железе.

Если где-то что-то работает хорошо, я этому рад, но это не отменяет того, что я бы хотел, чтобы в другом месте работало получше. В данном случае чтобы и на моём слабеньком e-450 более лучше работала корица.

P.S Раньше она работала лучше, но потом была сихронизация кодовой базы muffin с mutter и по части производительности появились регрессии, когда выпилили разные типы синхронизации в пользу одного единственного.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от papin-aziat

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

PcheloBiaka
()
Ответ на: комментарий от TechnoMag

Он ест у меня меньше гигабайта, а гном есть 2 гига.

daniyal
() автор топика
Последнее исправление: daniyal (всего исправлений: 1)
Ответ на: комментарий от Lrrr

Openrc, к сожалению, без проблем не поставишь. Если тебя устаривает alpine без проблем юзай его, alpine даже лучше будет, просто меня не устаривает musl и busybox, а в воиде gnu coreutils и есть glibc редакция.

daniyal
() автор топика
Последнее исправление: daniyal (всего исправлений: 2)
Ответ на: комментарий от KvasPatron

Репы легко фиксятся сторонними репами и шаблонами для xbps-src, например blackhole-vl для некоторого популярного софта и хипра, obsidian для… obsidian, xlibre-void для xlibre и прочее.

daniyal
() автор топика
Ответ на: комментарий от PcheloBiaka

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

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Я много всякого канпеляю. Просто так. Или с пользой. Поэтому мне всегда приходилось в Дебьяны доставлять все дев-пакеты. А потом я подумал - да какая разница, на Арче всё сразу есть. Но понятно, не всем лишь надо канпелять.

PcheloBiaka
()
Ответ на: комментарий от daniyal

Это древние печатные машинки которые покупались лет 12-13 назад. Какие там могут быть мониторы? Естественно 60 герц

AleksK ★★★☆
()
Ответ на: комментарий от PcheloBiaka

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

err
()
Ответ на: комментарий от AleksK

тогда не знаю в чём причина, можно попробовать дрова в конфиге поменять на modesetting.

daniyal
() автор топика
Ответ на: комментарий от daniyal

Да, и правда фиксятся, но это единственный минус который я смог придумать. Хотя сам не жалуюсь, стандартных репов с головой хватает

KvasPatron
()
Ответ на: комментарий от papin-aziat

Флатпаки - костыльное решение проблемы. Nixподобные - правильное решение проблемы. И я не про декларативность, я про разделение версий либ. Так и должно быть, а не вот это вот всё.

daniyal
() автор топика
Ответ на: комментарий от daniyal

У этой проблемы пока нет хорошего решения. Так что классические репы будут ещё долго актуальны.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Если ты про религиозных дебианщиков - то зачем им войд? А у религиозных войдоводов, умеренность - это благодетель

KvasPatron
()
Ответ на: комментарий от KvasPatron

зачем им войд?

Со всяким может приключиться дистрохопперство.

papin-aziat ★★★★★
()
Ответ на: комментарий от PcheloBiaka

нет, аналога AUR нету, видимо пользователям не критично, раз за столько лет не появилось чего-то подобного.
Пользовательские репы конечно можно найти, например для hyprland или ungoogled-chromium видел, последний даже с бинарями. Или допустим проприетарщина, такая как Discord или TeamSpeak — готовых пакетов нет даже при подключении nonfree репозитория, но в оффициальном гите есть сценарий для упаковки.

В целом свои какие-то пакеты собирать и поддерживать должно быть просто, но могут быть конечно нюансы с библиотеками (xbps отслеживает разделяемые библиотеки и просто так не даст обновить какую-то системную либу от которой многое зависит).
Плюс отправить запрос на новый или обновление существующего пакета тоже может быть не так просто, потому что по идее нужно собирать для всех архитектур. А еще комманда не большая, со всеми вытекающими. Но попробовать стоит, дистрибутив классный и простой. Valve должны были выбрать void, эх… :)

err
()
Ответ на: комментарий от err

а плюсы то какие? пока только минусы и готовность всё это терпеть, непонятно почему :)

ps: хз как гном мог похерить всё, дело скорее всего не в нем ведь :)

SpaceRaven
()
Ответ на: комментарий от PcheloBiaka

так в дебиане в отличиче от рача(ну или я не знаю что такое есть) всё можно собирать в чистом чруте и потом себе ставить не засирая систему мусором

edit: ну и как пишут в войде всё тоже в контейнерах билдится

SpaceRaven
()
Последнее исправление: SpaceRaven (всего исправлений: 3)
Ответ на: комментарий от SpaceRaven

А чрут у тебя куда? В воздух? Всё равно место занимает. В итоге мы просто более сложную систему сборки хэдоуворда имеем. И неоюходимость повторять все колдунства для каждого проекта. А на Арче просто взял и cmake make profit. Заголовочные файлы занимают только место на диске никак не влияя на быстродействие. Один раз занимают место. А на чрутах - для каждого проекта отдельно плюс геморрой с настройкой чрута каждый раз. И что ты выиграл? Не представляю. Дебьяновский подход годится только для тех кто совсем не компилит и не собирает. Но одновременно ставит перед ними преграду при желании начать это увлекательное дело.

PcheloBiaka
()
Ответ на: комментарий от PcheloBiaka

место занимает

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

неоюходимость повторять все колдунства для каждого проекта

геморрой с настройкой чрута каждый раз

в войде всем занимается скрипт xbps-src, один раз. по сути твои действия сводятся к клонированию репы и одной команде, для установки окружения. дальше можешь собирать пакетики, патчить существующие и все такое.

Заголовочные файлы занимают только место на диске никак не влияя на быстродействие

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

err
()
Ответ на: комментарий от SpaceRaven

а плюсы то какие?

простой для понимания дистрибутив на скриптах, с простым как палка инитом. поддержка множества архитектур, кучи ядер и нескольких libc. кросскомпиляция изкаропки. удобные вспомогательные скрипты для создания исо и контейнеров. стабильный роллинг, не гоняющийся за bleeding-edge софтом и не разваливающийся от того, что не обновлял пару месяцев. удобная система сборки (аналог портов из bsd, на баш), если очень захотеть — можно компилить мир из сорцов с нужными флагами. быстрый и удобный пм из 21го века.

err
()

Думал на своем войде перелезть с гнома на синнамон, но чет достаточно глюково. Может это гном поднасрал…

idoffront
()
Ответ на: комментарий от err

остальные зависимости подтягиваются во время сборки для конкретного пакета и после удаляются.

И так каждый раз когда вздумалось покомпилять? В нужное мне время сидеть и качать заголовки? Кстати, в Slitaz было что-то такое при компиляции пакета (именно пакета, не произвольного проекта с диска). Но там и в систему можно было понаставить dev пакетов.

в войде всем занимается скрипт xbps-src, один раз. по сути твои действия сводятся к клонированию репы и одной команде, для установки окружения. дальше можешь собирать пакетики, патчить существующие и все такое.

Хехе, странные вы люди, но оно же всё равно будет присутствовать на диске? Зачем так сложно делать такую простую вещь? В Арче всё просто, установил либы, все заголовки прилетели с ними. Я, кстати, после этого обсуждения задался вопросом, можно ли просто сжать /usr/include ? Спросил у ИИ (не на лоре же спрашивать :)) и мы с ним договорились, что всё же btrfs с его subvolumes подойдёт для этого как нельзя лучше, чем городить чруты. Но! Но! Но это для моего «образа жизни».

PcheloBiaka
()
Ответ на: комментарий от PcheloBiaka

И так каждый раз когда вздумалось покомпилять? В нужное мне время сидеть и качать заголовки?

ой, ну если вам лень пару минут подождать пока скачается… держите конечно на диске, а лучше сразу всю репу выкачивайте, вдруг пригодится :)

оно же всё равно будет присутствовать на диске?

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

В Арче всё просто, установил либы, все заголовки прилетели с ними

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

а вообще, никто не запрещает устанавливать те же либы и компилить врукопашную в /usr/local, только тсс :)

чем городить чруты

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

err
()
Ответ на: комментарий от err

О ужас… Столько способой отстрелить себе ноги «зачем мне ноги пока я сижу? Захочу пройтись, позвоню доктору, он приедет пришьёт, пару минут подождать» :))) Всё гораздо проще когда всё скачалос сразу и лежит не кусается. Какой смысл избегать заголовков? Чтобы сэкономить место? Другой причины я не вижу. Но если у меня выбор из:

  1. Каждый раз скачивать эти зависимости хоть руками хоть скриптами
  2. тащить их зачем-то в /usr/local (ЗАЧЕМ???)
  3. Просто ставить библиотеки с заголовочными файлами и никуда ничего не перекладывать, не скачивать каждый раз чтоб серькнуть в консоль, не писать скриптов сборки и не переносить в /usr/local

А выбираю третий вариант. Оно всё само есть и не нужно никаких действий кроме установки самого пакета нужной библиотеки. Эти файлы не будут валяться у меня на столе нестройными кучами и падать мне в кофе, они лежат себе отдельно и всё. Я посчитал размер /usr/lib/include - он занимает примерно 1,3% корня моей системы. Это экономия на спичках. /usr/share/doc занимает 7,6% например.

Я сегодня посчитал сколько занимает флатпак на моей системе и охренел… 100 гигов. (СТО ГИГАБАЙТ МЕСТА НА ДИСКЕ, КАРЛ!!!) И даже больше. Удалил лишнее, остались четыре приложения и никак не ужимаются меньше 16 гигов. Ну никак. При том, что сами приложения занимают 1,2 гига. И я точно знаю, что когда попытаюсь обновить хоть одно из приложений во флатпаке, все эти гадости прилетят опять. Вот на чём надо экономить.

PcheloBiaka
()
Последнее исправление: PcheloBiaka (всего исправлений: 1)
Ответ на: комментарий от PcheloBiaka

О ужас… Столько способой отстрелить себе ноги «зачем мне ноги пока я сижу? Захочу пройтись, позвоню доктору, он приедет пришьёт, пару минут подождать» :)))

я ничего не понял, какие ноги, какой доктор?)

Всё гораздо проще когда всё скачалос сразу и лежит не кусается. Какой смысл избегать заголовков? Чтобы сэкономить место? Другой причины я не вижу.

ну я тут не крову продаю, а пытаюсь объяснить как просто в войд свои пакеты собирать и поддерживать.

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

выбираю третий вариант Просто ставить библиотеки с заголовочными файлами и никуда ничего не перекладывать, не скачивать каждый раз чтоб серькнуть в консоль, не писать скриптов сборки и не переносить в /usr/local

похоже ты вообще не понимаешь о чем я говорю.
допустим, есть некая программа, собирается обычным make && make install, для сборки требуется собственно сам компилятор, pkg-config, python и какой-нибудь libjpeg-turbo, при этом еще надо наложить пару патчей, твои действия? неужели будешь руками устанавливать зависимости, руками же качать сорцы, вручную накладывать патчи? и устанавливать куда, в обход ПМа? а как же обновление, удаление, повторяемость?

Я сегодня посчитал сколько занимает флатпак на моей системе и охренел… 100 гигов. (СТО ГИГАБАЙТ МЕСТА НА ДИСКЕ, КАРЛ!!!)

без комментариев

err
()
Последнее исправление: err (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.