You are not logged in.
I have old hardware, so I get to enjoy it for 10 seconds or so at startup (I didn't time it). Shutdown time is the same, about 2 seconds. I'm not sure about restart. If it does add time, it's pretty brief.
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
Build Android apps on stretch...
https://bits.debian.org/2017/03/build-a … ebian.html
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
Disable Gtk+ 3 client side decorations, globally:
https://packages.debian.org/stretch/gtk3-nocsd
gtk3-nocsd LD_PRELOADs a small library to disable the client side decorations (CSD) of Gtk+ 3.
Since Gtk+ 3.10, its developers added a so-called header bar or custom title bar. With this and the client-side decoration, the original title bar and window border provided by the window manager are disabled by Gtk+. This makes all Gtk+ 3 programs look like alike, but have different handling from other windows on non-GNOME desktops. Even worse, this may break some window manager or compositors.
Unfortunately, there is no reliable way of turning off CSDs in Gtk+ directly. This library makes this possible.
Offline
^ Oh my god, cannot wait to try this!
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
^^Nice find HoaS!
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Well I did managed to froze gedit with gtk3-nocsd, so I'll assume
Even worse, this may break some window manager or compositors.
as false. The solution seems to be to either fix gtk+ or ban it from the ecosystem until fixed or live with the inconsistent look.
Last edited by brontosaurusrex (2017-03-26 10:21:49)
Offline
^ Agreed, but we'll have to watch for b0rkage, as reported by bronto-rex, between now and then.
I haven't seen any weirdness, but I just started using it.
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
Debranding of Icedove...
https://lists.debian.org/debian-devel-a … 00004.html
I wasn't thrilled with how this was done, in that there were 2 profile folders and 2 desktop entries when it was finished, and the Icedove entry was 'Icedove>Thunderbird'. I missed this 'lists' message and deleted my ~/.icedove folder without backing it up (stupid of me), but everything seemed OK after restarting Thunderbird, meaning my Enigma keys were intact and I was able to download my emails.
The Icedove *.desktop file doesn't get deleted from /usr/share/applications. There is a new Thunderbird file there with the 'Exec=' line set to /usr/bin/thunderbird %u, which means typing 'thund' in xfce4-appfinder doesn't autocomplete. I copied the desktop folder to ~/.local/share/applications and changed it to 'Exec=thunderbird %u' to fix that. I didn't have Icedove setup in a BunsenLabs partition, so I can't say how this would affect gmrun or dmenu.
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
For stretch, only GDM and `startx` (ie, no display manager at all) will support rootless X:
https://www.debian.org/releases/stretch … unpriv-x11
I think that we should either switch to GDM or drop the display manager altogether, running X rootless is a major security advantage.
Offline
Speaking of security and from the same document:
Executables are now compiled as position independent executables (PIE) by default.
HoaS likes this
Offline
from the Arch wiki, there are requirements (apart from the Xorg version)
Not sure what you mean by this, I had rootless X on my Arch systems since Xorg version 1.17 (or so).
The stock BL system currently ships with the open drivers so it should all be supported in stretch, at least according to the link.
My Helium system is (was) currently running rootless X with no problems (HD4600).
can there truly be a configuration that supports all kinds of graphics drivers at least as good as rootful, standard Xorg settings
As long as the open drivers are used, no further configuration is should be needed for `startx` & rootless X in Debian stretch.
Last edited by Head_on_a_Stick (2017-03-28 21:09:40)
Offline
What's the deal with at-spi2 dbus in stretch? Is it so tied in with gtk3 that you can't disable it anymore, short of renaming the bin files?
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
^ Thanks. The ram usage is minimal, I just thought it was weird that desktop files nor systemctl worked, and that there is very little discussion about it.
I'll try your config tomorrow, do you declare that in your environment or in something like gtk3 ini?
Sorry for the phone shorthand
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
I just thought it was weird that desktop files nor systemctl worked
Debian also still uses /etc/rc.d and the legacy sysvinit methods and some programs are started that way.
The only way I have found to show them all is to scour the output of:
systemd-analyze blame
Then use:
# update-rc.d $service disable
To kill the recalcitrant little b*gger ]:D
Or use https://packages.debian.org/jessie/sysv-rc-conf but that's cheating...
Offline
I thought we had previously agreed to leave that a11y stuff in, for accessibility? Or has something nasty happened to it with Stretch?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
^ No, leave it in. I was just looking to kill a service that I don't use, but it's a tiny amount of RAM.
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
For stretch, only GDM and `startx` (ie, no display manager at all) will support rootless X
→ For stretch, rootless X will be supported, although only for GDM and startx.
I had to read the linked article to realize that this wasn't a regression, but an advance.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Debranding of Icedove...
https://lists.debian.org/debian-devel-a … 00004.html...there were 2 profile folders and 2 desktop entries when it was finished, and the Icedove entry was 'Icedove>Thunderbird'
...The Icedove *.desktop file doesn't get deleted from /usr/share/applications.
Uninstall icedove and the duplication will go away.
There is a new Thunderbird file there with the 'Exec=' line set to /usr/bin/thunderbird %u, which means typing 'thund' in xfce4-appfinder doesn't autocomplete... I didn't have Icedove setup in a BunsenLabs partition, so I can't say how this would affect gmrun or dmenu.
No problems with gmrun or dmenu. I'm not sure if they actually refer to .desktop files though. Full paths in the Exec: key of .desktop files are permitted by freedesktop. Actually, icedove.desktop also had a full path - did xfce4-appfinder handle that one OK?
The transition from Icedove went quite smoothly for me. The only residue now is that ~/.thunderbird is a symlink to ~/.icedove. Renaming ~/.icedove (and perhaps removing ~/.thunderbird/.migrated) would fix that I guess.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
If systemd is a hard requirement for rootless Xorg
It would be useful to know how this actually works to figure out why that is.
Xorg only needs root rights to access /dev/input/* nodes, the tty, and the graphics card (/dev/video/*), everything else it does can work with the user's permissions. So to get rootless X, one would have to give it permission somehow to access those files.
File permissions work for /dev/input (e.g. adding your user to the group that has access to /dev/input files). If you login via a tty you have permissions over the current tty. But for /dev/video, normal file permissions are not sufficient. To perform certain operations, the user who opened /dev/video must be root.
The way they have chosen to solve this problem is to open those files as root from logind and pass the file descriptors over DBus (which is a wrapper over a UNIX socket, which allows passing open file descriptors between programs) to Xorg.
They have have chosen to add systemd as a dependency when other init-agnostic approaches would have worked as well:
1. Pass the fds over a UNIX socket (instead of DBus) using a simple API that would be implemented by logind. Then one doesn't need DBus and can replace logind with something else if needed. Modularity is good.
2. Start Xorg as root as usual and drop privileges after opening the /dev/* files. This is the simplest, most flexible approach.
But modularity is not desired by these people. Linux is slowly becoming fully monolithic.
Last edited by o9000 (2017-04-29 08:54:33)
Offline
twoion wrote:If systemd is a hard requirement for rootless Xorg
It would be useful to know how this actually works to figure out why that is.
Rootless X is acheived through kernel mode setting and is not related to systemd directly, although that is a dependency thanks to the integration of systemd-logind.
Anyway, Xorg is a tangled mess of ancient code, the sooner everyone moves to Wayland the better, IMO.
Offline