V
В такие моменты думается: хорошо, что в багзилле нельзя свои сообщения исправлять.
Size: a a a
2020 March 24
NN
Так я запустил wayfire на глазок все плавно
A
Nutrion Natria
Так я запустил wayfire на глазок все плавно
Интересно на RPi погонять. Но по идее самый быстрый в своей категории.
NN
Интересно на RPi погонять. Но по идее самый быстрый в своей категории.
Выглядит честно не ахти
V
Ахх..
A
Nutrion Natria
Выглядит честно не ахти
Так а что там выглядит? Там же ничего нет. Это фактически compiz для wayland. Всякие бары и плюхи только недавно появились.
NN
Так а что там выглядит? Там же ничего нет. Это фактически compiz для wayland. Всякие бары и плюхи только недавно появились.
Как в гном зафигачить?)
A
Напиши bar, launcher, переключался между приложениями и Панель управления. И будет тебе трушный DE на wayland.
A
Nutrion Natria
Как в гном зафигачить?)
Никак. В Гном жабоподелие под названием gnome-shell на веки вечные. Wayfire весь на C++ 17 кстати.
NN
Никак. В Гном жабоподелие под названием gnome-shell на веки вечные. Wayfire весь на C++ 17 кстати.
Ух модно, молодежно
A
Nutrion Natria
Ух модно, молодежно
Модно не модно, но запусти Гном на RPi и его например.
Eric wrote:
Ultimately, though, I’m skeptical of GNOME 3 ever being usable on a Raspberry Pi. The clutter-based gnome-shell painting is too slow (60% of a CPU burned in the shell just trying to present a single 60fps glxgears), and there doesn’t seem to be a plan for improving it other than “maybe we’ll delete clutter some day?” Also, the javascipt extension system being in the compositor thread means that you drop application frames when something else (network statechanges, notifications, etc) happens in the system. This was a bad software architecture choice, and digging out of that hole now would take a long time. (I’m agnostic on whether it was wrong to move those into the same process as the compositor, but same thread was definitely wrong). I’ll keep working on the debugging tools to try to enable anyone to work on these problems, though.
https://anholt.github.io/twivc4/2018/05/30/twiv/
Eric wrote:
Ultimately, though, I’m skeptical of GNOME 3 ever being usable on a Raspberry Pi. The clutter-based gnome-shell painting is too slow (60% of a CPU burned in the shell just trying to present a single 60fps glxgears), and there doesn’t seem to be a plan for improving it other than “maybe we’ll delete clutter some day?” Also, the javascipt extension system being in the compositor thread means that you drop application frames when something else (network statechanges, notifications, etc) happens in the system. This was a bad software architecture choice, and digging out of that hole now would take a long time. (I’m agnostic on whether it was wrong to move those into the same process as the compositor, but same thread was definitely wrong). I’ll keep working on the debugging tools to try to enable anyone to work on these problems, though.
https://anholt.github.io/twivc4/2018/05/30/twiv/
NN
Модно не модно, но запусти Гном на RPi и его например.
Eric wrote:
Ultimately, though, I’m skeptical of GNOME 3 ever being usable on a Raspberry Pi. The clutter-based gnome-shell painting is too slow (60% of a CPU burned in the shell just trying to present a single 60fps glxgears), and there doesn’t seem to be a plan for improving it other than “maybe we’ll delete clutter some day?” Also, the javascipt extension system being in the compositor thread means that you drop application frames when something else (network statechanges, notifications, etc) happens in the system. This was a bad software architecture choice, and digging out of that hole now would take a long time. (I’m agnostic on whether it was wrong to move those into the same process as the compositor, but same thread was definitely wrong). I’ll keep working on the debugging tools to try to enable anyone to work on these problems, though.
https://anholt.github.io/twivc4/2018/05/30/twiv/
Eric wrote:
Ultimately, though, I’m skeptical of GNOME 3 ever being usable on a Raspberry Pi. The clutter-based gnome-shell painting is too slow (60% of a CPU burned in the shell just trying to present a single 60fps glxgears), and there doesn’t seem to be a plan for improving it other than “maybe we’ll delete clutter some day?” Also, the javascipt extension system being in the compositor thread means that you drop application frames when something else (network statechanges, notifications, etc) happens in the system. This was a bad software architecture choice, and digging out of that hole now would take a long time. (I’m agnostic on whether it was wrong to move those into the same process as the compositor, but same thread was definitely wrong). I’ll keep working on the debugging tools to try to enable anyone to work on these problems, though.
https://anholt.github.io/twivc4/2018/05/30/twiv/
Я про C++ 17
A
xvitaly ridiculous and rude
🤣🤣🤣
🤣🤣🤣
NN
А как из wayfire выйти?
AZ
кстати этот Wakely шарящий чувак
V
Ответил :)
V
Я скоро отключусь :)
LK
всем привет
что делать если удаление пакета валится на запуске скриптлетов (
upd: добавил
что делать если удаление пакета валится на запуске скриптлетов (
pre run ) и пакет потом не удаляется?upd: добавил
--noscripts для rpmA
Nutrion Natria
А как из wayfire выйти?
pkill wayfire
Вот кстати кнопочки для логаута, перезагрузки выключения. Оно для i3/Sway но и для Wayfire подойдет.A
Автор кстати в пайтона перписывает на C++ его.