@ebassi Just recently I got an issue from a user on KDE who has Reduced Motion (or similar) enabled there but our GTK app on Flatpak doesn't inherit it from KDE, only (the old option) from GNOME.
-
@ebassi https://m.xkcd.com/1200/
it's not like people are going to run GParted sandboxed otherwise. And it fundamentally needs access to your full disk, so not running as root is not going to buy you much security.
But yeah, you don't *have to* run it as root either, so why not run it as $USER.
-
@ebassi https://m.xkcd.com/1200/
it's not like people are going to run GParted sandboxed otherwise. And it fundamentally needs access to your full disk, so not running as root is not going to buy you much security.
But yeah, you don't *have to* run it as root either, so why not run it as $USER.
@bugaevc that XKCD strip is fundamentally flawed: installing fake software running as an admin is how people get access to all those remote services without having to physically steal the laptop.
The problem is not running gparted (or whatever application): it's running everything, from settings to random (GTK) modules, as root without your knowledge or consent. You don't know what else has root access when you run a whole ass GUI application.
-
@bugaevc that XKCD strip is fundamentally flawed: installing fake software running as an admin is how people get access to all those remote services without having to physically steal the laptop.
The problem is not running gparted (or whatever application): it's running everything, from settings to random (GTK) modules, as root without your knowledge or consent. You don't know what else has root access when you run a whole ass GUI application.
@bugaevc I've have bug reports for gdk-pixbuf being broken after the switch to sandboxed loaders because people run gparted as root and modify the environment to set themes and cursors from their user's home directory. This is the kind of insanity we allow, while going around sandboxing and hardening the underlying OS.
-
@ebassi While privilege separation is obviously the right choice, I can kind of understand why people keep on going for the "run desktop app as root" approach: it is a lot easier to do things the wrong way.
If you're building a graphical app that runs as root, it is quite easy to run the app from the build directory without installing it.
To go the privilege separation route, you're going to need to install at least the D-Bus policy files and Polkit action files. It could probably do with some more tutorial style documentation of current best practices here.
-
@ebassi@mastodon.social It's basically universal human behaviour to make up stuff to be mad at. Wherever I look at, I always see this type of behaviour. Quite amazing, in a way.
-
@ebassi we need Summoning Salt style videos to recount the lore
-
@ebassi we need Summoning Salt style videos to recount the lore
@danirabbit need to pick up the history of GNOME again…
-
@uriel 2026 was going to be the year of the SteamOS Desktop, but Altman instead decided to make it Year Of The "nobody gets a Desktop"
-
@ebassi @GerryT It was understandable back when apps implemented the other half of the protocol. Namely unselecting text once they lose ownership of PRIMARY.
Once apps started to keep showing selected text without owning PRIMARY, the model broke down. And I'm not sure the people asking for middle click paste would even want this part to change.
-
Then simply make it configurable. The "telemetry-driven" approach may suit corporate environments, but I find it rather troubling that one might be unable to use their PDP-11 simply because no one else in the vicinity does the same. Everyone should have the freedom to run a PDP-11 at home.
-
Then simply make it configurable. The "telemetry-driven" approach may suit corporate environments, but I find it rather troubling that one might be unable to use their PDP-11 simply because no one else in the vicinity does the same. Everyone should have the freedom to run a PDP-11 at home.
@uriel it *is* configurable already: the whole thing is deciding whether to turn it off by default or not.
-
@uriel it *is* configurable already: the whole thing is deciding whether to turn it off by default or not.
Okkkk... This leaves me wondering: what precisely are we discussing? A single click within some GNOME Tweaks panel?
-
Okkkk... This leaves me wondering: what precisely are we discussing? A single click within some GNOME Tweaks panel?
@uriel that, or even something inside the system settings themselves
-
@ebassi @GerryT It was understandable back when apps implemented the other half of the protocol. Namely unselecting text once they lose ownership of PRIMARY.
Once apps started to keep showing selected text without owning PRIMARY, the model broke down. And I'm not sure the people asking for middle click paste would even want this part to change.
-
@uriel it *is* configurable already: the whole thing is deciding whether to turn it off by default or not.
-
@uriel that, or even something inside the system settings themselves
Then I shut up. My Gen Z colleagues have already bestowed upon me the glorious title of "Der Musolini," merely because I have the audacity to dismiss such existential crises with observations like "your mouse is perfectly capable of surviving this ordeal."
Besides, I doubt they even KNOW what "Der Musolini" refers to:
https://youtu.be/wrtvEwitEDs?si=LDJ3oAqb1tILRuAn
-
@GerryT you didn't bother checking what we're actually doing, before launching yourself into a tirade?
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/119
The setting exists already, and it can be toggled in the CLI and using apps like Tweaks and Refine. The discussion in the merge request is: 1. disable by default and 2. add the toggle somewhere that's easy to find
-
@GerryT you didn't bother checking what we're actually doing, before launching yourself into a tirade?
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/119
The setting exists already, and it can be toggled in the CLI and using apps like Tweaks and Refine. The discussion in the merge request is: 1. disable by default and 2. add the toggle somewhere that's easy to find
@ebassi I checked the Gnome settings and it is not there.
-
@GerryT you didn't bother checking what we're actually doing, before launching yourself into a tirade?
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/119
The setting exists already, and it can be toggled in the CLI and using apps like Tweaks and Refine. The discussion in the merge request is: 1. disable by default and 2. add the toggle somewhere that's easy to find
@ebassi Discussion is not tirade. There is no reasonable reason to deactivate it by default. No one has given a compelling reason, why to do so. People are actively using this feature, as you can see in the comments of all news sites that reported on this. There are good reasons to keep this practical and useful feature as default. Please reconsider your opinion on that.
-
@GerryT @ebassi selections are the inter-app data transfer mechanism of X11. They are used to implement the clipboard, middle click paste, and drag and drop.
An application can request ownership of a selection, which will cause the previous owner to be notified it has lost ownership. It advertises that the data is available in one or more formats (e.g. plain text, images, html, etc).
Other applications can check the advertised formats and request that the selection be converted to one of them. The selection owner then sends the data in that format to the requesting app.
The way middle click paste worked was that an app would request the PRIMARY selection when the user selected something, and other apps would convert this selection when middle clicking.
The other part of the system was that if an app lost ownership of PRIMARY, it was expected to unselect whatever the user had selected previously. If they don't do this part, then the user can't tell what text would be pasted by the middle mouse button.