I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I observed this bug while trying out Fedora Silverblue 30's release but not in beta. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro. I was then asked to file a bug report and had provider information, which I did by doing multiple reinstalls of Silverblue/Workstation.
2-3 months ago by and the bug report has been closed because I didn't and couldn't do a deep level analysis. I don't use Fedora, I use Arch Linux. This isn't my distro and I'm not the one that broke it to begin with. The only reason I was even trying it out is because I really like the whole immutable filesystem concept and was hoping that the bug and issues with it would be ironed out and that I could switch to it if Arch decided to take a dump.
Sadly the issues weren't last time I checked about a month ago. Silverblue repos are often out of sync with the rest of Fedora resulting in upgrades failing. You have to manually cleanup upgrade meta cache to get upgrades to work correctly(rpm-ostree cleanup -m). Fedora update servers in general are unstable and unreliable as hell, sometimes returning HTTP error codes or just being offline. Gnome Software doesn't display software correctly on the front page. There still is no way to add Flatpak external disks via Gnome-Settings as of 3.34. You can't use Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
No, Red Hat. Fedora Silverblue isn't easy to use.
...but I digress...
I got the email and decided to check the nvidia-settings repo on Github[1]. Apparently, Someone has filed a bug report about overclocking on rootless X. org servers doesn't work[2]. I then downloaded Fedora Workstation and installed the Nvidia driver and checked which user the X. org server was running under.
Mini rant: By the way, update your damn installer images. Users shouldn't have to install 400MB of updates after they just install the distro. The installer image has Firefox 66 on it still! That's really freaking stupid. On my 5400RPM drive it takes a half hour to install all of that crap, which is longer than installing the distro itself or updating under Silverblue!
Yep, X. Org **ISN"T** running under root. Overclocking doesn't work either, same as before.
So I then tried making X. Org run as root using the Arch Wiki's guide[3] and verified that I was now running as root.
I was... and overclocking is now working.
...seriously? You make a abrupt change to Fedora 30 literally right before it was released, breaking overclocking applications such as my own AND Nvidia's own software, and then blame Nvidia for your own screwup? /Really/?
So problem found. It was a problem in Fedora all along, like I said from nearly the beginning. Fix problems that **YOU** make instead of blaming Nvidia next time.
[1] https://github.com/NVIDIA/nvidia-settings/
On Sat, Sep 21, 2019 at 8:33 PM Ty Young youngty1997@gmail.com wrote:
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I observed this bug while trying out Fedora Silverblue 30's release but not in beta. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro. I was then asked to file a bug report and had provider information, which I did by doing multiple reinstalls of Silverblue/Workstation.
2-3 months ago by and the bug report has been closed because I didn't and couldn't do a deep level analysis. I don't use Fedora, I use Arch Linux. This isn't my distro and I'm not the one that broke it to begin with. The only reason I was even trying it out is because I really like the whole immutable filesystem concept and was hoping that the bug and issues with it would be ironed out and that I could switch to it if Arch decided to take a dump.
Sadly the issues weren't last time I checked about a month ago. Silverblue repos are often out of sync with the rest of Fedora resulting in upgrades failing. You have to manually cleanup upgrade meta cache to get upgrades to work correctly(rpm-ostree cleanup -m). Fedora update servers in general are unstable and unreliable as hell, sometimes returning HTTP error codes or just being offline. Gnome Software doesn't display software correctly on the front page. There still is no way to add Flatpak external disks via Gnome-Settings as of 3.34. You can't use Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
No, Red Hat. Fedora Silverblue isn't easy to use.
No one is saying Silverblue is easy to use yet. Most of us know that Silverblue has plenty of warts and needs a ton of refinement to be useful for people beyond people who live in containers (a small group of people that matters a lot to Red Hat).
We still offer Workstation. Just use that. :)
...but I digress...
I got the email and decided to check the nvidia-settings repo on Github[1]. Apparently, Someone has filed a bug report about overclocking on rootless X. org servers doesn't work[2]. I then downloaded Fedora Workstation and installed the Nvidia driver and checked which user the X. org server was running under.
Mini rant: By the way, update your damn installer images. Users shouldn't have to install 400MB of updates after they just install the distro. The installer image has Firefox 66 on it still! That's really freaking stupid. On my 5400RPM drive it takes a half hour to install all of that crap, which is longer than installing the distro itself or updating under Silverblue!
Yep, X. Org **ISN"T** running under root. Overclocking doesn't work either, same as before.
So I then tried making X. Org run as root using the Arch Wiki's guide[3] and verified that I was now running as root.
I was... and overclocking is now working.
...seriously? You make a abrupt change to Fedora 30 literally right before it was released, breaking overclocking applications such as my own AND Nvidia's own software, and then blame Nvidia for your own screwup? Really?
Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
So problem found. It was a problem in Fedora all along, like I said from nearly the beginning. Fix problems that **YOU** make instead of blaming Nvidia next time.
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
On 9/21/19 7:51 PM, Neal Gompa wrote:
On Sat, Sep 21, 2019 at 8:33 PM Ty Young youngty1997@gmail.com wrote:
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I observed this bug while trying out Fedora Silverblue 30's release but not in beta. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro. I was then asked to file a bug report and had provider information, which I did by doing multiple reinstalls of Silverblue/Workstation.
2-3 months ago by and the bug report has been closed because I didn't and couldn't do a deep level analysis. I don't use Fedora, I use Arch Linux. This isn't my distro and I'm not the one that broke it to begin with. The only reason I was even trying it out is because I really like the whole immutable filesystem concept and was hoping that the bug and issues with it would be ironed out and that I could switch to it if Arch decided to take a dump.
Sadly the issues weren't last time I checked about a month ago. Silverblue repos are often out of sync with the rest of Fedora resulting in upgrades failing. You have to manually cleanup upgrade meta cache to get upgrades to work correctly(rpm-ostree cleanup -m). Fedora update servers in general are unstable and unreliable as hell, sometimes returning HTTP error codes or just being offline. Gnome Software doesn't display software correctly on the front page. There still is no way to add Flatpak external disks via Gnome-Settings as of 3.34. You can't use Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
No, Red Hat. Fedora Silverblue isn't easy to use.
No one is saying Silverblue is easy to use yet.
There was an article/blog post on Red Hat's website saying it was not long ago. Maybe you didn't see it?
Most of us know that Silverblue has plenty of warts and needs a ton of refinement to be useful for people beyond people who live in containers (a small group of people that matters a lot to Red Hat).
The immutable filesystem offers an easy to use recovery mechanism and fixes the live system update problem. Those are some real big benefits IMO. Flatpak is still a major issue however...
We still offer Workstation. Just use that. :)
The unreliable update servers affect Workstation too. Again, upgrades on workstation take forever. Silverblue is much faster.
...but I digress... again.
...but I digress...
I got the email and decided to check the nvidia-settings repo on Github[1]. Apparently, Someone has filed a bug report about overclocking on rootless X. org servers doesn't work[2]. I then downloaded Fedora Workstation and installed the Nvidia driver and checked which user the X. org server was running under.
Mini rant: By the way, update your damn installer images. Users shouldn't have to install 400MB of updates after they just install the distro. The installer image has Firefox 66 on it still! That's really freaking stupid. On my 5400RPM drive it takes a half hour to install all of that crap, which is longer than installing the distro itself or updating under Silverblue!
Yep, X. Org **ISN"T** running under root. Overclocking doesn't work either, same as before.
So I then tried making X. Org run as root using the Arch Wiki's guide[3] and verified that I was now running as root.
I was... and overclocking is now working.
...seriously? You make a abrupt change to Fedora 30 literally right before it was released, breaking overclocking applications such as my own AND Nvidia's own software, and then blame Nvidia for your own screwup? Really?
Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
So problem found. It was a problem in Fedora all along, like I said from nearly the beginning. Fix problems that **YOU** make instead of blaming Nvidia next time.
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
Really? It's Nvidia's fault that noone can agree on anything and keep fragmenting the ecosystem in incredibly stupid ways?
Linus Torvalds has a policy of not breaking userspace, so why is it that the same core philosophy isn't being applied downstream? Why do Fedora, Ubuntu, Arch, etc keep deviating from some resemblance of a standard, making developing software for Linux nearly impossible unless you package specifically for that Linux distro(Fedora in this case)?
In this case it's some security boogeyman but there are plenty of cases where it's just done " just because".
/media used to be where media was mounted. Now it's /run/media and some distros just system link /media to /run/media while others like Arch Linux don't do it at all.
Similarly libraries in Linux are located in arbitrary locations. In Fedora a library I need is located in /usr/lib64. In Arch it's /usr/lib. In ubuntu it's /usr/lib/86x-64_gnu_pc(or whatever). Why?
How the actual hell can anyone depend on anything? Howl can can anyone support all the insane ways things are done differently?
Flatpak? Most distos won't support it and the DE integration isn't great. Not every application is or can be put into a container. Drivers sure as hell can't.
Snaps? Basically only supported and used on Ubuntu.
Please, if there is some magical way to ensure comparability with every stupid thing distro developers do, i'd love to hear it. I'm having issues with ensuring comparability as well(see above).
Ironically Red Hat, Fedora, and Gnome is often accused of the horrible crime of trying to unify the Linux desktop but in actuality it seems like it's just as bad as the rest of them.
On Sat, Sep 21, 2019 at 9:32 PM Ty Young youngty1997@gmail.com wrote:
On 9/21/19 7:51 PM, Neal Gompa wrote:
On Sat, Sep 21, 2019 at 8:33 PM Ty Young youngty1997@gmail.com wrote:
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I observed this bug while trying out Fedora Silverblue 30's release but not in beta. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro. I was then asked to file a bug report and had provider information, which I did by doing multiple reinstalls of Silverblue/Workstation.
2-3 months ago by and the bug report has been closed because I didn't and couldn't do a deep level analysis. I don't use Fedora, I use Arch Linux. This isn't my distro and I'm not the one that broke it to begin with. The only reason I was even trying it out is because I really like the whole immutable filesystem concept and was hoping that the bug and issues with it would be ironed out and that I could switch to it if Arch decided to take a dump.
Sadly the issues weren't last time I checked about a month ago. Silverblue repos are often out of sync with the rest of Fedora resulting in upgrades failing. You have to manually cleanup upgrade meta cache to get upgrades to work correctly(rpm-ostree cleanup -m). Fedora update servers in general are unstable and unreliable as hell, sometimes returning HTTP error codes or just being offline. Gnome Software doesn't display software correctly on the front page. There still is no way to add Flatpak external disks via Gnome-Settings as of 3.34. You can't use Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
No, Red Hat. Fedora Silverblue isn't easy to use.
No one is saying Silverblue is easy to use yet.
There was an article/blog post on Red Hat's website saying it was not long ago. Maybe you didn't see it?
Most of us know that Silverblue has plenty of warts and needs a ton of refinement to be useful for people beyond people who live in containers (a small group of people that matters a lot to Red Hat).
The immutable filesystem offers an easy to use recovery mechanism and fixes the live system update problem. Those are some real big benefits IMO. Flatpak is still a major issue however...
We still offer Workstation. Just use that. :)
The unreliable update servers affect Workstation too. Again, upgrades on workstation take forever. Silverblue is much faster.
...but I digress... again.
We also do have regular respins of the media for the latest release: https://dl.fedoraproject.org/pub/alt/live-respins/
I'm not sure why we don't publicize them, but they are made on a regular basis.
...but I digress...
I got the email and decided to check the nvidia-settings repo on Github[1]. Apparently, Someone has filed a bug report about overclocking on rootless X. org servers doesn't work[2]. I then downloaded Fedora Workstation and installed the Nvidia driver and checked which user the X. org server was running under.
Mini rant: By the way, update your damn installer images. Users shouldn't have to install 400MB of updates after they just install the distro. The installer image has Firefox 66 on it still! That's really freaking stupid. On my 5400RPM drive it takes a half hour to install all of that crap, which is longer than installing the distro itself or updating under Silverblue!
Yep, X. Org **ISN"T** running under root. Overclocking doesn't work either, same as before.
So I then tried making X. Org run as root using the Arch Wiki's guide[3] and verified that I was now running as root.
I was... and overclocking is now working.
...seriously? You make a abrupt change to Fedora 30 literally right before it was released, breaking overclocking applications such as my own AND Nvidia's own software, and then blame Nvidia for your own screwup? Really?
Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
So problem found. It was a problem in Fedora all along, like I said from nearly the beginning. Fix problems that **YOU** make instead of blaming Nvidia next time.
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
Really? It's Nvidia's fault that noone can agree on anything and keep fragmenting the ecosystem in incredibly stupid ways?
Linus Torvalds has a policy of not breaking userspace, so why is it that the same core philosophy isn't being applied downstream? Why do Fedora, Ubuntu, Arch, etc keep deviating from some resemblance of a standard, making developing software for Linux nearly impossible unless you package specifically for that Linux distro(Fedora in this case)?
Linux's policy applies across a very special boundary and nowhere else. Within kernel-space, no compatibility guarantees are given at all. Interfaces in kernel space are completely unstable. Userspace is also done by a larger set of people in disparate groups. It's a much harder problem to stabilize userspace than the kernel's userspace API. And even that's not completely stable, you're just usually shielded from that by glibc.
In this case it's some security boogeyman but there are plenty of cases where it's just done " just because".
/media used to be where media was mounted. Now it's /run/media and some distros just system link /media to /run/media while others like Arch Linux don't do it at all.
This was done to make it easy to have unprivileged mounting of removable devices without things like setuid binaries... There was also some other issues with namespacing mounts per user that were fixed with the move to /run/media.
Similarly libraries in Linux are located in arbitrary locations. In Fedora a library I need is located in /usr/lib64. In Arch it's /usr/lib. In ubuntu it's /usr/lib/86x-64_gnu_pc(or whatever). Why?
FHS specifies a /usr/lib<qual>, which specifically /usr/lib64 (for 64-bit) and /usr/lib (for 32-bit) are defined (and /usr/libexec for helper binaries...). Everything else is technically non-standard. Distributions doing it differently have elected to do it differently for their own reasons. I could spend a fair amount of time describing those reasons for both Arch and Debian/Ubuntu, but it's not important.
How the actual hell can anyone depend on anything? Howl can can anyone support all the insane ways things are done differently?
As someone whose day job involves supporting ~20 Linux distribution releases spanning more than a decade of churn, it turns out to be surprisingly easy.
Flatpak? Most distos won't support it and the DE integration isn't great.
Flatpak support seems to be pretty good among distributions, judging by this: https://flatpak.org/setup/
Not every application is or can be put into a container. Drivers sure as hell can't.
And that's why you can still install packages, even on Silverblue.
Snaps? Basically only supported and used on Ubuntu.
Well, they work on Fedora too. We even have upstream snapd developers working specifically on Fedora integration.
Please, if there is some magical way to ensure comparability with every stupid thing distro developers do, i'd love to hear it. I'm having issues with ensuring comparability as well(see above).
What one person calls stupid is brilliant by another.
That said, these days the main deviation is between the Debian family and all RPM distro families. Arch and Gentoo also follow their own variation, but it's very close to what all RPM distros do.
Ironically Red Hat, Fedora, and Gnome is often accused of the horrible crime of trying to unify the Linux desktop but in actuality it seems like it's just as bad as the rest of them.
Often, the curse of being first[1] is that we'll be different from everyone for a short time. Everyone catches up eventually...
[1]: https://docs.fedoraproject.org/en-US/project/#_first
On 9/21/19 9:24 PM, Neal Gompa wrote:
On Sat, Sep 21, 2019 at 9:32 PM Ty Young youngty1997@gmail.com wrote:
On 9/21/19 7:51 PM, Neal Gompa wrote:
On Sat, Sep 21, 2019 at 8:33 PM Ty Young youngty1997@gmail.com wrote:
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I observed this bug while trying out Fedora Silverblue 30's release but not in beta. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro. I was then asked to file a bug report and had provider information, which I did by doing multiple reinstalls of Silverblue/Workstation.
2-3 months ago by and the bug report has been closed because I didn't and couldn't do a deep level analysis. I don't use Fedora, I use Arch Linux. This isn't my distro and I'm not the one that broke it to begin with. The only reason I was even trying it out is because I really like the whole immutable filesystem concept and was hoping that the bug and issues with it would be ironed out and that I could switch to it if Arch decided to take a dump.
Sadly the issues weren't last time I checked about a month ago. Silverblue repos are often out of sync with the rest of Fedora resulting in upgrades failing. You have to manually cleanup upgrade meta cache to get upgrades to work correctly(rpm-ostree cleanup -m). Fedora update servers in general are unstable and unreliable as hell, sometimes returning HTTP error codes or just being offline. Gnome Software doesn't display software correctly on the front page. There still is no way to add Flatpak external disks via Gnome-Settings as of 3.34. You can't use Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
No, Red Hat. Fedora Silverblue isn't easy to use.
No one is saying Silverblue is easy to use yet.
There was an article/blog post on Red Hat's website saying it was not long ago. Maybe you didn't see it?
Most of us know that Silverblue has plenty of warts and needs a ton of refinement to be useful for people beyond people who live in containers (a small group of people that matters a lot to Red Hat).
The immutable filesystem offers an easy to use recovery mechanism and fixes the live system update problem. Those are some real big benefits IMO. Flatpak is still a major issue however...
We still offer Workstation. Just use that. :)
The unreliable update servers affect Workstation too. Again, upgrades on workstation take forever. Silverblue is much faster.
...but I digress... again.
We also do have regular respins of the media for the latest release: https://dl.fedoraproject.org/pub/alt/live-respins/
I'm not sure why we don't publicize them, but they are made on a regular basis.
...but I digress...
I got the email and decided to check the nvidia-settings repo on Github[1]. Apparently, Someone has filed a bug report about overclocking on rootless X. org servers doesn't work[2]. I then downloaded Fedora Workstation and installed the Nvidia driver and checked which user the X. org server was running under.
Mini rant: By the way, update your damn installer images. Users shouldn't have to install 400MB of updates after they just install the distro. The installer image has Firefox 66 on it still! That's really freaking stupid. On my 5400RPM drive it takes a half hour to install all of that crap, which is longer than installing the distro itself or updating under Silverblue!
Yep, X. Org **ISN"T** running under root. Overclocking doesn't work either, same as before.
So I then tried making X. Org run as root using the Arch Wiki's guide[3] and verified that I was now running as root.
I was... and overclocking is now working.
...seriously? You make a abrupt change to Fedora 30 literally right before it was released, breaking overclocking applications such as my own AND Nvidia's own software, and then blame Nvidia for your own screwup? Really?
Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
So problem found. It was a problem in Fedora all along, like I said from nearly the beginning. Fix problems that **YOU** make instead of blaming Nvidia next time.
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
Really? It's Nvidia's fault that noone can agree on anything and keep fragmenting the ecosystem in incredibly stupid ways?
Linus Torvalds has a policy of not breaking userspace, so why is it that the same core philosophy isn't being applied downstream? Why do Fedora, Ubuntu, Arch, etc keep deviating from some resemblance of a standard, making developing software for Linux nearly impossible unless you package specifically for that Linux distro(Fedora in this case)?
Linux's policy applies across a very special boundary and nowhere else. Within kernel-space, no compatibility guarantees are given at all. Interfaces in kernel space are completely unstable. Userspace is also done by a larger set of people in disparate groups. It's a much harder problem to stabilize userspace than the kernel's userspace API. And even that's not completely stable, you're just usually shielded from that by glibc.
...much harder because noone can agree on anything.
In this case it's some security boogeyman but there are plenty of cases where it's just done " just because".
/media used to be where media was mounted. Now it's /run/media and some distros just system link /media to /run/media while others like Arch Linux don't do it at all.
This was done to make it easy to have unprivileged mounting of removable devices without things like setuid binaries... There was also some other issues with namespacing mounts per user that were fixed with the move to /run/media.
OK, so why aren't distros system linking to maintain backwards compatibility?
Similarly libraries in Linux are located in arbitrary locations. In Fedora a library I need is located in /usr/lib64. In Arch it's /usr/lib. In ubuntu it's /usr/lib/86x-64_gnu_pc(or whatever). Why?
FHS specifies a /usr/lib<qual>, which specifically /usr/lib64 (for 64-bit) and /usr/lib (for 32-bit) are defined (and /usr/libexec for helper binaries...). Everything else is technically non-standard. Distributions doing it differently have elected to do it differently for their own reasons. I could spend a fair amount of time describing those reasons for both Arch and Debian/Ubuntu, but it's not important.
Not important? It's the entire issue at hand. You CANNOT depend on just about anything in Linux because of this stupid crap. The result? The platform being a giant turnoff to developers(and by extension, users), and having to individually package and tweak software to make it work because the distro decides they are special and need special treatment.
That giant list of packages that have been abandoned and have no maintainers? Yeah, that's be less of an issue if things weren't so fragmented since software would only need to be packaged once. Hell, companies would probably do it themselves! Don't even try to downplay how bad it is.You could dedicate an entire mailing list just to orphaning packages and it'd probably get more traffic than the dev mailing list.
Nvidia made their software expecting X. Org as root because that was the standard at the time. You can't be pulling that from under them and then expecting them to fix something they never broke. That's total BS.
For the record, /usr/lib64 points to /usr/lib and /usr/lib32 is for 32-bit so like, WTF? Standards are only standards if people follow them.
How the actual hell can anyone depend on anything? Howl can can anyone support all the insane ways things are done differently?
As someone whose day job involves supporting ~20 Linux distribution releases spanning more than a decade of churn, it turns out to be surprisingly easy.
Different software has different dependencies and different levels of complexity. You can't claim packaging a basic text editor is the same as packaging an entire DE.
Sure it might be easy for people who have time for it, but look at the giant list of packages that have been orphaned. People move on, they don't have time, no experience, or they have no interest packaging the software. And every distro needs one person to package that software for them because every distro is different.
Flatpak? Most distos won't support it and the DE integration isn't great.
Flatpak support seems to be pretty good among distributions, judging by this: https://flatpak.org/setup/
Lets dive a bit deeper, shall we?
Ubuntu announced that they are going to be removing Gnome Software in favor of Snap Store which presumably won't support Flatpak sometime in the future awhile ago.
About 5 of those are Debian family based, so the instructions are mostly the same as is the difficulty of maintaining compatibility. Ubuntu IIRC is literally Debian testing or w/e. Pop!_OS has very heavily been criticized as just being Ubuntu with custom high level tweaks. Ubuntu literally requires a third party PPA so calling it a standard is a joke.
About 3 are Fedora/Red Hat family based, so above applies.
Solus doesn't(last time I checked) provided a GUI for installing Flatpaks.
Arch Linux literally has custom patches/setting applied to Gnome Software to hide the "update" header bar tab so that the only way to update via Gnome Software is by going through Gnome settings.
As far as the rest goes, who even knows? They are so obscure and most are for "advanced" users.
INB4: But you don't need a front-end! Flatpaks are installable/updatable by the command line!
If they aren't providing a working, usable front-end for Flatpak then they don't consider it a standard do they? It's more like they are being forced to provide it but don't actually embrace it themselves.
Not every application is or can be put into a container. Drivers sure as hell can't.
And that's why you can still install packages, even on Silverblue.
Packages that have to be individually packaged and maintained for each distro, Sure.That's the underlying issue though, isn't it?
On Silverblue specifically you can't even install packages sometimes because of desyncing of Fedora's repos. So even within a single distro there is a form of fragmentation...
Snaps? Basically only supported and used on Ubuntu.
Well, they work on Fedora too. We even have upstream snapd developers working specifically on Fedora integration.
Really? I seem to remember it being announced to be removed in future Fedora releases not that long ago. Did that change?
Please, if there is some magical way to ensure comparability with every stupid thing distro developers do, i'd love to hear it. I'm having issues with ensuring comparability as well(see above).
What one person calls stupid is brilliant by another.
That said, these days the main deviation is between the Debian family and all RPM distro families. Arch and Gentoo also follow their own variation, but it's very close to what all RPM distros do.
IIRC there are incompatibilities between Fedora RPM and OpenSuse RPM. So I've heard, anyway. Maybe it isn't true. Whenever RPM is offered on a website OpenSuse is never mentioned.
Ironically Red Hat, Fedora, and Gnome is often accused of the horrible crime of trying to unify the Linux desktop but in actuality it seems like it's just as bad as the rest of them.
Often, the curse of being first[1] is that we'll be different from everyone for a short time. Everyone catches up eventually...
Like that flicker free boot that literally doesn't work on Nvidia open source or binary driver correctly which I brought up forever ago?
It's less cathing up and more picking and choosing. Fedora developers just seem to put the actual work into making things happen when others won't or aren't capable for doing it themselves. Maybe they are contributing, I don't pay attention, but that's the way it seems.
On Sat, 2019-09-21 at 22:24 -0400, Neal Gompa wrote:
We still offer Workstation. Just use that. :)
The unreliable update servers affect Workstation too. Again, upgrades on workstation take forever. Silverblue is much faster.
...but I digress... again.
We also do have regular respins of the media for the latest release: https://dl.fedoraproject.org/pub/alt/live-respins/
I'm not sure why we don't publicize them, but they are made on a regular basis.
Because they're not really official and they're subject to only limited testing. They are built by a volunteer and aren't built entirely the same way we build official images.
We don't do fully official respins on the basis that the time it would cost releng to build them, QA to test them and developers to fix any issues that showed up would not be worth it. Yes, it is entirely possible for things to go out as updates that work fine *as updates* but cause issues in the "produce working installer/live images" process.
We have rather *better* releng and testing systems in place now than we did when the decision not to do regular official respins was made, so it's a decision that could be revisited at some point. But that's where we are right now.
On 9/21/19 6:31 PM, Ty Young wrote:
Really? It's Nvidia's fault that noone can agree on anything and keep fragmenting the ecosystem in incredibly stupid ways?
No, it's NVidia's fault because they refuse to open-source their driver. That means that they always have to play catch-up with every change being made because the ones making the changes can't help them. All the other major drivers work just fine with rootless X.
On 9/22/19 12:48 AM, Samuel Sieb wrote:
On 9/21/19 6:31 PM, Ty Young wrote:
Really? It's Nvidia's fault that noone can agree on anything and keep fragmenting the ecosystem in incredibly stupid ways?
No, it's NVidia's fault because they refuse to open-source their driver. That means that they always have to play catch-up with every change being made because the ones making the changes can't help them. All the other major drivers work just fine with rootless X.
That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really?
If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner.
Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 9/21/19 11:46 PM, Ty Young wrote:
That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really?
Of course there are bugs. But I'm talking about major features like rootless X and various kernel changes where the NVidia driver lags way behind and sometimes doesn't work at all.
If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner.
If you're talking about Nouveau, then yes, it has many issues because it's an attempt at reverse-engineering. They have no documentation, so it's pretty amazing that it works as well as it does.
Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that.
No idea what you're talking about here. I haven't had any issues with grub.
Really, calm down. Maybe you should be using Windows instead where everything always works...
On 9/22/19 1:57 AM, Samuel Sieb wrote:
On 9/21/19 11:46 PM, Ty Young wrote:
That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really?
Of course there are bugs. But I'm talking about major features like rootless X and various kernel changes where the NVidia driver lags way behind and sometimes doesn't work at all.
Lagging behind is as much as a bug as the dozens of bugs in AMD/Intel drivers and MESA. There are graphics cards that probably don't even work entirely still. I remember the R9 390 had issues and probably still does. In those cases you can't even get a bootable system.
If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner.
If you're talking about Nouveau, then yes, it has many issues because it's an attempt at reverse-engineering. They have no documentation, so it's pretty amazing that it works as well as it does.
Didn't Nvidia release documentation some time ago? Regardless, there is a lot things envolved with the shutdown process, isn't there? How do you even know it's the driver to begin with? Are we just assuming it is, like we assumed that overclocking was broke because something Nvidia did or does anyone have actual proof? I have a really old second generation Intel laptop that I can test to see if it's reproducible.
Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that.
No idea what you're talking about here. I haven't had any issues with grub.
There was a boot warning/error about GRUB not being on a FAT filesystem or something before. Now there is something else this install, I think... or maybe it's the same thing. It's hard to read in the short time it appears.
Really, calm down. Maybe you should be using Windows instead where everything always works...
That was one hell of a good joke. You should be a comedian.
Like I said, I'm only interested in Fedora for Silverblue's immutable filesystem, at least from a user's perspective. The Fedora part is almost entirely a negative given all the problems listed earlier. No other active Linux distro has problems with keeping their update servers online, repo desyncing, and/or updating downloadable images on their website like Fedora does and it blows my mind that it's even an issue given it's sponsored by Red Hat. These are all issues that can be easily fixed i'm sure but still, it's very surprising.
I'm of course also interested in ensuring compatibility with Fedora for my application but given how hostile y'all are to Nvidia it doesn't seem like it's ever going to happen. I guess it's not the end of the word since noone really uses Fedora for gaming but still... if no one at Fedora wants to support Nvidia then remove their driver from RPM Fusion already and be done with it.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sunday, September 22, 2019 12:26:46 AM MST Ty Young wrote:
I'm of course also interested in ensuring compatibility with Fedora for my application but given how hostile y'all are to Nvidia it doesn't seem like it's ever going to happen. I guess it's not the end of the word since noone really uses Fedora for gaming but still... if no one at Fedora wants to support Nvidia then remove their driver from RPM Fusion already and be done with it.
Okay, you just lost the benefit of the doubt here. I'm going to respond to this, and this is my last message to this thread. I hope nvidia can provide you with the assistance you need.
The Fedora project is not hostile to nvidia. On the contrary, we'd love to support nvidia GPUs. To that end, we provide up to date packages for the Nouveau driver. Nvidia only releases proprietary blobs, instead of a proper driver. We can't do anything with that. We can't make it compatible with Fedora, because it is proprietary. This has been a problem with nvidia for over a decade, to the point that there is now that famous clip of Torvalds giving nvidia the middle finger. There's just nothing we can do, unfortunately.
If whatever application you're talking about is FLOSS, it'll likely not be a problem, as the end user could simply compile your software to run on their system, or install it through the package manager. At worst, they'd have to patch your software to work on an updated system like Fedora.
Fedora does not maintain RPMFusion. We literally cannot support nvidia's proprietary drivers, as.. they're proprietary.
Have a good one.
- - John M. Harris, Jr. Splentity
On Saturday, September 21, 2019 11:46:40 PM MST Ty Young wrote:
That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really?
There are bugs in every software. Currnetly, the Intel drivers are the most stable available on Linux. I don't know what in the world you're talking about.
There will never come a day where there are zero bugs in any given complex software.
If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner.
We can't do anything to help you with the binary driver. Go bug nvidia, they're the only ones that can help you with that.
Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that.
What errors or warnings are you talking about?
- - John M. Harris, Jr. Splentity
On Sat, Sep 21, 2019 at 8:33 PM Ty Young <youngty1997(a)gmail.com> wrote: Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
Do you mean 'Support non-root X'? if so some DM's still don't support it.
https://github.com/canonical/lightdm/issues/18
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
As far as I know we don't force non-rootless X.
On Sun, Sep 22, 2019, 10:09 Leigh Scott leigh123linux@gmail.com wrote:
On Sat, Sep 21, 2019 at 8:33 PM Ty Young <youngty1997(a)gmail.com>
wrote:
Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
Do you mean 'Support non-root X'? if so some DM's still don't support it.
https://github.com/canonical/lightdm/issues/18
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
As far as I know we don't force non-rootless X.
Right. Last I checked, the Xorg processes on my system (NVIDIA + proprietary drivers) ran as root on fedora 30 Workstation.
Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 9/22/19 3:08 AM, Leigh Scott wrote:
On Sat, Sep 21, 2019 at 8:33 PM Ty Young <youngty1997(a)gmail.com> wrote: Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
Do you mean 'Support non-root X'? if so some DM's still don't support it.
...and it's Open Source. Ironic.
Anyway, I did a google search and apparently running X. Org as user isn't exactly safe either. According to the Gentoo wik[1] a user could snoop on another user's input. It doesn't go into specifics on how these are a big deal, but if they are what's even the point of running non root? Just breaking into the entire system vs. a user?
Not a security expert but if you have user permissions you can do anything a user could normally do including rebooting, shuttting down, uploading files to some private server, logging inputs, etc. The user account is the lowest hanging fruit there is from my understanding.
[1] https://wiki.gentoo.org/wiki/Non_root_Xorg#Security_concerns
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
As far as I know we don't force non-rootless X.
I haven't smoked any shrooms yet today(/joke), so it isn't my imagination By default X. Org runs as user but if you follow the Arch wiki you can force it to run as root.
Again, this was never an issue during the mid beta but towards the end of the beta or shortly after release something changed.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 9/22/19 3:08 AM, Leigh Scott wrote:
On Sat, Sep 21, 2019 at 8:33 PM Ty Young <youngty1997(a)gmail.com> wrote: Fedora and other distributions have been working on rootless Xorg since 2013. We've had it in place since at least 2015. This change was made way back in Fedora 24.
Do you mean 'Support non-root X'? if so some DM's still don't support it.
https://github.com/canonical/lightdm/issues/18
This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly.
As far as I know we don't force non-rootless X.
For the giggles I tried the Cinnamon spin. Unless something changes after installing the Nvidia drivers, X. Org is running as root unlike Gnome Fedora.
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
Also, who is maintaining the cinnamon spin? Do they by chance speak Spanish as their primary language?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 9/22/19 3:10 PM, Ty Young wrote:
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
On 9/22/19 5:51 PM, Samuel Sieb wrote:
On 9/22/19 3:10 PM, Ty Young wrote:
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
No, I meant the package manager GUI front-end won't work:
Also, GUI in general is buggy:
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sun, Sep 22, 2019 at 7:25 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 5:51 PM, Samuel Sieb wrote:
On 9/22/19 3:10 PM, Ty Young wrote:
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
No, I meant the package manager GUI front-end won't work:
I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else.
If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME.
How would you propose we fix this bug, as you call it?
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
Maybe different versions of the software positioned it differently?
On 9/22/19 9:09 PM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 7:25 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 5:51 PM, Samuel Sieb wrote:
On 9/22/19 3:10 PM, Ty Young wrote:
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
No, I meant the package manager GUI front-end won't work:
I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else.
If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora
It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help.
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME.
How would you propose we fix this bug, as you call it?
Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm?
Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work?
Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea.
So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe.
Maybe provide an optional rootless login session option in Gnome's login screen?
FWIW, even if the application uses Flatpak, rootless X. Org still breaks the application. Would it be possible to grant individual applications privileged root access on a case by case basis?
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
Maybe different versions of the software positioned it differently?
Ah, no. The menu I'm talking looks like the application icon itself. I've only seen it manifest itself in Arch Linux when you install another DE. No other Gnome applications in Fedora that I could see has it, and it does stick out... maybe it's a CSD compatibility thing for Cinnomon and/or Mate?
On Sun, Sep 22, 2019 at 10:02 pm, Ty Young youngty1997@gmail.com wrote:
So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe.
You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance.
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance.
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a copr if you want to make it easier for other Nvidia overclockers to use it.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior. The only distro I know of that uses --disable-user-display-server is Endless.
Michael
On 9/23/19 10:00 AM, Michael Catanzaro wrote:
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance.
It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility!
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a copr if you want to make it easier for other Nvidia overclockers to use it.
This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior.
Five years ago and yet no other DE besides Gnome supports it. Five years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to make other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with.
Lets *actually read* that link, shall we?
The user experience will be unchanged
This is a blatant lie. Breaking people's software absolutely impacts the user experience.
Desktop product: gdm, Ray Strode is working on this: ?
KDE spin: ?
XFCE spin: ?
LXDE spin: ?
Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years.
Having the xserver not run as root reduces Fedora's attack surface.
...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with.
If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can:
-reboot/shutdown
-silently lockup the system by spawning too many threads
-hard lock the system by passing allowed but unsupported values
-fill up memory, resulting in HDD thrashing and potentially killing your SSD
-create other processes(pop up windows)
-kill other processes
-upload all your files in your home directory to a personal private server
-delete all your files in your home directory
-encrypt all your files in your home directory.
...among a whole lot else I'm probably forgetting.
Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome.
The only distro I know of that uses --disable-user-display-server is Endless.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Sep 23, 2019 at 1:38 pm, Ty Young youngty1997@gmail.com wrote:
This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer.
Oh nice. Then you can change that and stop complaining. Thanks!
You already have a solution. Use the solution you have. Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do.
Your rants and all caps won't make anything change. Please try to deal with it and move on from this rather dead thread.
Br M
On 23 September 2019 20:38:13 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 10:00 AM, Michael Catanzaro wrote:
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
You're wasting your time. We're not going to run the X server as
root
just so you can overclock your GPU. Not a chance.
It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility!
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a
copr
if you want to make it easier for other Nvidia overclockers to use
it.
This is entirely unnecessary. You can enable root X. Org via the config
option. A random user's COPR repo isn't a whole lot safer.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior.
Five years ago and yet no other DE besides Gnome supports it. Five years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to make other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with.
Lets *actually read* that link, shall we?
The user experience will be unchanged
This is a blatant lie. Breaking people's software absolutely impacts the user experience.
Desktop product: gdm, Ray Strode is working on this: ?
KDE spin: ?
XFCE spin: ?
LXDE spin: ?
Look at that broad DE support. It's *almost* like no one cares or wants
this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years.
Having the xserver not run as root reduces Fedora's attack surface.
...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with.
If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can:
-reboot/shutdown
-silently lockup the system by spawning too many threads
-hard lock the system by passing allowed but unsupported values
-fill up memory, resulting in HDD thrashing and potentially killing your SSD
-create other processes(pop up windows)
-kill other processes
-upload all your files in your home directory to a personal private server
-delete all your files in your home directory
-encrypt all your files in your home directory.
...among a whole lot else I'm probably forgetting.
Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome.
The only distro I know of that uses --disable-user-display-server is Endless.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 9/23/19 1:53 PM, Markus Larsson wrote:
You already have a solution. Use the solution you have.
Not a solution, it's a bandaid to a much larger problem.
Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do.
Yet Fedora expects other distros/DEs, *including their own spins* to cater to their decisions when those decisions aren't wanted or technically possible to begin with. That's hypocritical.
Your rants and all caps won't make anything change. Please try to deal with it and move on from this rather dead thread.
My apologies for interrupting your daily mailing list programming of package orphaning/retirement. I know everyone's waiting on their seats in anticipation of what packages are going orphaned/retired next, but the current discussion has evolved into something that very much impacts that very issue.
Let me break it down for you:
1. More fragmentation means more work to maintain and test everything.
2. More work to maintain and test everything requires more people.
3. More people means more roles that have to be filled which require experience.
4. Different people have different ideas on approaching problems, and since they have experience, they use that experience to fragment the desktop even more instead of compromising or working together. This is *Fedora*
5. More fragmentation angers developers who want to support the platform since they can't ensure that their software works remotely consistently. This is *me*.
6. Angry developers means less software for Linux.
7. Less software for Linux means less users.
8. Less users means a smaller pool of potential people to fill empty roles.
9. Empty roles means things go stale, bugs go unfixed, and no one has experience.
Make any sense? I know it doesn't perfectly loop back at the end but 1-4 does.
Br M
On 23 September 2019 20:38:13 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 10:00 AM, Michael Catanzaro wrote:
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance.
It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility!
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a copr if you want to make it easier for other Nvidia overclockers to use it.
This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior.
Five years ago and yet no other DE besides Gnome supports it. Five years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to make other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with. Lets *actually read* that link, shall we? >The user experience will be unchanged This is a blatant lie. Breaking people's software absolutely impacts the user experience. >Desktop product: gdm, Ray Strode is working on this: ? >KDE spin: ? >XFCE spin: ? >LXDE spin: ? Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years. >Having the xserver not run as root reduces Fedora's attack surface. ...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with. If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can: -reboot/shutdown -silently lockup the system by spawning too many threads -hard lock the system by passing allowed but unsupported values -fill up memory, resulting in HDD thrashing and potentially killing your SSD -create other processes(pop up windows) -kill other processes -upload all your files in your home directory to a personal private server -delete all your files in your home directory -encrypt all your files in your home directory. ...among a whole lot else I'm probably forgetting. Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome.
The only distro I know of that uses --disable-user-display-server is Endless. Michael _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 23 September 2019 21:58:02 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 1:53 PM, Markus Larsson wrote:
You already have a solution. Use the solution you have.
Not a solution, it's a bandaid to a much larger problem.
You said it works fine in Arch. So use Arch. You say that it can be configured easily in Fedora so do that and use Fedora. Those are solutions to your problem.
Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do.
Yet Fedora expects other distros/DEs, *including their own spins* to cater to their decisions when those decisions aren't wanted or technically possible to begin with. That's hypocritical.
As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have.
Your rants and all caps won't make anything change. Please try to
deal
with it and move on from this rather dead thread.
My apologies for interrupting your daily mailing list programming of package orphaning/retirement. I know everyone's waiting on their seats in anticipation of what packages are going orphaned/retired next, but the current discussion has evolved into something that very much impacts that very issue.
How about not interrupting that with something that was very clearly explained to you about 50 mails ago?
Let me break it down for you:
More fragmentation means more work to maintain and test everything.
More work to maintain and test everything requires more people.
More people means more roles that have to be filled which require
experience.
- Different people have different ideas on approaching problems, and
since they have experience, they use that experience to fragment the desktop even more instead of compromising or working together. This is *Fedora*
- More fragmentation angers developers who want to support the
platform since they can't ensure that their software works remotely consistently. This is *me*.
Angry developers means less software for Linux.
Less software for Linux means less users.
Less users means a smaller pool of potential people to fill empty
roles.
- Empty roles means things go stale, bugs go unfixed, and no one has
experience.
Make any sense? I know it doesn't perfectly loop back at the end but 1-4 does.
No your unrelated 9 step venting does not make any sense unless of course your aim was to be rude in a new and slightly more amusing way. One thing peaked my interest though, what software is it that you wanted to "support the platform" with?
Br M
On 23 September 2019 20:38:13 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 10:00 AM, Michael Catanzaro wrote:
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro <mcatanzaro@gnome.org> wrote:
You're wasting your time. We're not going to run the X server
as
root just so you can overclock your GPU. Not a chance.
It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility!
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special
gdm
in a copr if you want to make it easier for other Nvidia overclockers to use it.
This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes
were
made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same
behavior.
Five years ago and yet no other DE besides Gnome supports it.
Five
years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to
make
other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with. Lets *actually read* that link, shall we? >The user experience will be unchanged This is a blatant lie. Breaking people's software absolutely impacts the user experience. >Desktop product: gdm, Ray Strode is working on this: ? >KDE spin: ? >XFCE spin: ? >LXDE spin: ? Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years. >Having the xserver not run as root reduces Fedora's attack
surface.
...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with. If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can: -reboot/shutdown -silently lockup the system by spawning too many threads -hard lock the system by passing allowed but unsupported values -fill up memory, resulting in HDD thrashing and potentially killing your SSD -create other processes(pop up windows) -kill other processes -upload all your files in your home directory to a personal private server -delete all your files in your home directory -encrypt all your files in your home directory. ...among a whole lot else I'm probably forgetting. Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome.
The only distro I know of that uses
--disable-user-display-server
is Endless. Michael _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 9/23/19 3:16 PM, Markus Larsson wrote:
On 23 September 2019 21:58:02 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 1:53 PM, Markus Larsson wrote:
You already have a solution. Use the solution you have.
Not a solution, it's a bandaid to a much larger problem.
You said it works fine in Arch. So use Arch.
What if another user uses it on Fedora and then blames me or some other developer for it not working? That's BS.
If you think I'm upset now, I'll go full tilt if that ever happens. I refuse to be blamed for some dumb decision Fedora made. I want to support Fedora, but Fedora doesn't want to support me. I'm more than doing my part to try to get this fixed.
You say that it can be configured easily in Fedora so do that and use Fedora.
I never said that. I said the complete opposite of that. Learn to read, please.
Those are solutions to your problem.
No.
Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do.
Yet Fedora expects other distros/DEs, *including their own spins* to cater to their decisions when those decisions aren't wanted or technically possible to begin with. That's hypocritical.
As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have.
Fedora doesn't? Then why did Fedora upstream the non root X. Org feature then instead of custom patching it every release? Clearly no one cares or wants it, as evident by the fact that X. Org is running as root(and by extension, overclocking works) yet Fedora as the maintainers of X. Org decided to make it the default? How is that not pushing your own agenda on other distros? If they went out of their way to disable it then they clearly don't want it.
And Fedora's own spins are impacted by this. It's not even consistent, reliable behavior in Fedora. You can't even depend on it one way or the other. Applications that depend on X. Org. being root will literally work just fine on a spin of Fedora but not the Gnome version. That's unnecessary fragmentation in the same ecosystem.
Your rants and all caps won't make anything change. Please try to
deal
with it and move on from this rather dead thread.
My apologies for interrupting your daily mailing list programming of package orphaning/retirement. I know everyone's waiting on their seats in anticipation of what packages are going orphaned/retired next, but the current discussion has evolved into something that very much impacts that very issue.
How about not interrupting that with something that was very clearly explained to you about 50 mails ago?
Let me break it down for you:
More fragmentation means more work to maintain and test everything.
More work to maintain and test everything requires more people.
More people means more roles that have to be filled which require
experience.
- Different people have different ideas on approaching problems, and
since they have experience, they use that experience to fragment the desktop even more instead of compromising or working together. This is *Fedora*
- More fragmentation angers developers who want to support the
platform since they can't ensure that their software works remotely consistently. This is *me*.
Angry developers means less software for Linux.
Less software for Linux means less users.
Less users means a smaller pool of potential people to fill empty
roles.
- Empty roles means things go stale, bugs go unfixed, and no one has
experience.
Make any sense? I know it doesn't perfectly loop back at the end but 1-4 does.
No your unrelated 9 step venting does not make any sense unless of course your aim was to be rude in a new and slightly more amusing way.
It wasn't rude, it was a fact. You can't gain experience doing something if you aren't doing it to begin with.
One thing peaked my interest though, what software is it that you wanted to "support the platform" with?
To put in your own words, how about not interrupting with something that was very clearly explained to you about 50 mails ago?
Speaking of 50 emails, that's an impressive number for a dead thread...
Br M
On 23 September 2019 20:38:13 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 10:00 AM, Michael Catanzaro wrote:
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
You're wasting your time. We're not going to run the X server
as
root just so you can overclock your GPU. Not a chance.
It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility!
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special
gdm
in a copr if you want to make it easier for other Nvidia overclockers to use it.
This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes
were
made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same
behavior.
Five years ago and yet no other DE besides Gnome supports it.
Five
years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to
make
other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with.
Lets *actually read* that link, shall we?
The user experience will be unchanged
This is a blatant lie. Breaking people's software absolutely impacts the user experience.
Desktop product: gdm, Ray Strode is working on this: ?
KDE spin: ?
XFCE spin: ?
LXDE spin: ?
Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years.
Having the xserver not run as root reduces Fedora's attack
surface.
...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with.
If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can:
-reboot/shutdown
-silently lockup the system by spawning too many threads
-hard lock the system by passing allowed but unsupported values
-fill up memory, resulting in HDD thrashing and potentially killing your SSD
-create other processes(pop up windows)
-kill other processes
-upload all your files in your home directory to a personal private server
-delete all your files in your home directory
-encrypt all your files in your home directory.
...among a whole lot else I'm probably forgetting.
Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome.
The only distro I know of that uses
--disable-user-display-server
is Endless.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 23 September 2019 22:42:35 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 3:16 PM, Markus Larsson wrote:
On 23 September 2019 21:58:02 CEST, Ty Young youngty1997@gmail.com wrote:
On 9/23/19 1:53 PM, Markus Larsson wrote:
You already have a solution. Use the solution you have.
Not a solution, it's a bandaid to a much larger problem.
You said it works fine in Arch. So use Arch.
What if another user uses it on Fedora and then blames me or some other
developer for it not working? That's BS.
If you think I'm upset now, I'll go full tilt if that ever happens. I refuse to be blamed for some dumb decision Fedora made. I want to support Fedora, but Fedora doesn't want to support me. I'm more than doing my part to try to get this fixed.
Why do you think anger will solve problems? Just point them towards Fedora and say that you can't do anything about it.
You say that it can be configured easily in Fedora so do that and use
Fedora.
I never said that. I said the complete opposite of that. Learn to read,
please.
I'm sorry if I was mistaken.
Those are solutions to your problem.
No.
Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do.
Yet Fedora expects other distros/DEs, *including their own spins* to cater to their decisions when those decisions aren't wanted or technically possible to begin with. That's hypocritical.
As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have.
Fedora doesn't? Then why did Fedora upstream the non root X. Org feature then instead of custom patching it every release? Clearly no one cares or wants it, as evident by the fact that X. Org is running as root(and by extension, overclocking works) yet Fedora as the maintainers of X. Org decided to make it the default? How is that not pushing your own agenda on other distros? If they went out of their way to disable it then they clearly don't want it.
You and everyone else are free to fork if you don't agree with upstream.
And Fedora's own spins are impacted by this. It's not even consistent, reliable behavior in Fedora. You can't even depend on it one way or the
other. Applications that depend on X. Org. being root will literally work just fine on a spin of Fedora but not the Gnome version. That's unnecessary fragmentation in the same ecosystem.
This has already been explained yet you act as if it hasn't. If only I could find something to say about reading proficiency to come of as friendly.
Your rants and all caps won't make anything change. Please try to
deal
with it and move on from this rather dead thread.
My apologies for interrupting your daily mailing list programming of package orphaning/retirement. I know everyone's waiting on their
seats
in anticipation of what packages are going orphaned/retired next,
but
the current discussion has evolved into something that very much impacts that very issue.
How about not interrupting that with something that was very clearly explained to you about 50 mails ago?
Let me break it down for you:
- More fragmentation means more work to maintain and test
everything.
More work to maintain and test everything requires more people.
More people means more roles that have to be filled which require
experience.
- Different people have different ideas on approaching problems,
and
since they have experience, they use that experience to fragment the desktop even more instead of compromising or working together. This
is
*Fedora*
- More fragmentation angers developers who want to support the
platform since they can't ensure that their software works remotely consistently. This is *me*.
Angry developers means less software for Linux.
Less software for Linux means less users.
Less users means a smaller pool of potential people to fill empty
roles.
- Empty roles means things go stale, bugs go unfixed, and no one
has
experience.
Make any sense? I know it doesn't perfectly loop back at the end but 1-4 does.
No your unrelated 9 step venting does not make any sense unless of course your aim was to be rude in a new and slightly more amusing
way.
It wasn't rude, it was a fact. You can't gain experience doing something if you aren't doing it to begin with.
I understood what you wrote. It just didn't in any way fit with the conversation.
One thing peaked my interest though, what software is it that you wanted to "support the platform" with?
To put in your own words, how about not interrupting with something that was very clearly explained to you about 50 mails ago?
Speaking of 50 emails, that's an impressive number for a dead thread...
I'm going to step away from this now. Mainly because it is like a broken record. It just keeps skipping back.
Br M
On 23 September 2019 20:38:13 CEST, Ty Young
wrote:
On 9/23/19 10:00 AM, Michael Catanzaro wrote:
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro mcatanzaro@gnome.org wrote:
You're wasting your time. We're not going to run the X server
as
root just so you can overclock your GPU. Not a chance.
It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility!
Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special
gdm
in a copr if you want to make it easier for other Nvidia overclockers to use it.
This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer.
See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes
were
made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same
behavior.
Five years ago and yet no other DE besides Gnome supports it.
Five
years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to
make
other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with.
Lets *actually read* that link, shall we?
The user experience will be unchanged
This is a blatant lie. Breaking people's software absolutely impacts the user experience.
Desktop product: gdm, Ray Strode is working on this: ?
KDE spin: ?
XFCE spin: ?
LXDE spin: ?
Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years.
Having the xserver not run as root reduces Fedora's attack
surface.
...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with.
If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can:
-reboot/shutdown
-silently lockup the system by spawning too many threads
-hard lock the system by passing allowed but unsupported values
-fill up memory, resulting in HDD thrashing and potentially killing your SSD
-create other processes(pop up windows)
-kill other processes
-upload all your files in your home directory to a personal private server
-delete all your files in your home directory
-encrypt all your files in your home directory.
...among a whole lot else I'm probably forgetting.
Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome.
The only distro I know of that uses
--disable-user-display-server
is Endless.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-leave@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Hey all: this is getting out of control and I don't think going anywhere productive. Please remember the Fedora "friends" foundation, the "be excellent to each other" guidance, and, of course, our code of conduct.
Thank you.
On Mon, Sep 23, 2019 at 01:38:13PM -0500, Ty Young wrote:
...among a whole lot else I'm probably forgetting.
You're forgetten one very important thing:
https://web.archive.org/save/_embed/http://safr.kingfeatures.com/idn/ck3/ema...
As the old saying goes, "You catch more flies with honey than vinegar"
- Solomon
On 9/23/19 2:02 PM, Solomon Peachy wrote:
On Mon, Sep 23, 2019 at 01:38:13PM -0500, Ty Young wrote:
...among a whole lot else I'm probably forgetting.
You're forgetten one very important thing:
https://web.archive.org/save/_embed/http://safr.kingfeatures.com/idn/ck3/ema...
As the old saying goes, "You catch more flies with honey than vinegar"
The saying is true but given the context there is more complexity to the story.
If a user runs a malicious program as their account you might not have the keys to the kingdom but you still have the keys to the front door. This is especially true if they are the only user on the system. The user account is the lowest hanging fruit which takes the least effort to compromise and do malicious things with. The Gentoo wiki even stated this to be the case.
Sure you might(?, I've never set an application to launch on startup under Linux myself...) not be able to be persistent across reboots but you need to be? Maybe the user rarely shuts down their computer. Does being persistent even matter at that point?
- Solomon
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sun, Sep 22, 2019 at 11:03 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 9:09 PM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 7:25 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 5:51 PM, Samuel Sieb wrote:
On 9/22/19 3:10 PM, Ty Young wrote:
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
No, I meant the package manager GUI front-end won't work:
I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else.
If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora
It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help.
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME.
How would you propose we fix this bug, as you call it?
Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm?
Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work?
Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea.
So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe.
The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done.
Maybe provide an optional rootless login session option in Gnome's login screen?
Again, it doesn't force things to change in the ecosystem, and worse, it makes it more difficult for QA and release verification, as we add another codepath to everything by doing this.
FWIW, even if the application uses Flatpak, rootless X. Org still breaks the application. Would it be possible to grant individual applications privileged root access on a case by case basis?
That's a Flatpak/Flathub thing, not really under our control unfortunately.
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
Maybe different versions of the software positioned it differently?
Ah, no. The menu I'm talking looks like the application icon itself. I've only seen it manifest itself in Arch Linux when you install another DE. No other Gnome applications in Fedora that I could see has it, and it does stick out... maybe it's a CSD compatibility thing for Cinnomon and/or Mate?
Ah, that's very possible. GTK+ has odd behaviors depending on desktop environment.
On 9/23/19 9:56 AM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 11:03 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 9:09 PM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 7:25 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 5:51 PM, Samuel Sieb wrote:
On 9/22/19 3:10 PM, Ty Young wrote:
I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again.
I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
No, I meant the package manager GUI front-end won't work:
I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else.
If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora
It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help.
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME.
How would you propose we fix this bug, as you call it?
Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm?
Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work?
Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea.
So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe.
The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done.
Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change.
The ONLY reason Plymouth(from my understanding, a Fedora initiative) and Flicker Free boot was/is being adopted by other distros is because Fedora did the work for them. Since Fedora isn't putting in the work to ensure DEs on their own distro support it, no one cares and won't adopt it universally.
And hey, all of those DEs are Open Source. It's almost like being Open Source doesn't increase the rate that something gets fixed. Imagine that.
Maybe provide an optional rootless login session option in Gnome's login screen?
Again, it doesn't force things to change in the ecosystem, and worse, it makes it more difficult for QA and release verification, as we add another codepath to everything by doing this.
YOU ARE ALREADY DOING THAT WITH YOUR SPINS! YOU ARE FRAGMENTING YOUR OWN DISTRO FOR NO REASON! NO OTHER DE SUPPORTS THIS!
FWIW, even if the application uses Flatpak, rootless X. Org still breaks the application. Would it be possible to grant individual applications privileged root access on a case by case basis?
That's a Flatpak/Flathub thing, not really under our control unfortunately.
No, it has nothing to do with Flatpak. The point was that Flatpak applications are still dependent on host X. Org and are susceptible to stupid crap that distros do, like this, despite supposedly being distro independent.
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
Maybe different versions of the software positioned it differently?
Ah, no. The menu I'm talking looks like the application icon itself. I've only seen it manifest itself in Arch Linux when you install another DE. No other Gnome applications in Fedora that I could see has it, and it does stick out... maybe it's a CSD compatibility thing for Cinnomon and/or Mate?
Ah, that's very possible. GTK+ has odd behaviors depending on desktop environment.
...but it happens on a pure Gnome Fedora and is the only Gnome application to have it...
On Mon, Sep 23, 2019 at 1:49 PM Ty Young youngty1997@gmail.com wrote:
On 9/23/19 9:56 AM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 11:03 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 9:09 PM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 7:25 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 5:51 PM, Samuel Sieb wrote:
On 9/22/19 3:10 PM, Ty Young wrote: > I couldn't actually install the drivers because the update GUI in the > cinnamon spin is broken and/or the repo/update servers are down. Again. I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora.
No, I meant the package manager GUI front-end won't work:
I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else.
If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora
It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help.
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME.
How would you propose we fix this bug, as you call it?
Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm?
Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work?
Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea.
So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe.
The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done.
Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change.
We are not, sure. But the Fedora distribution is allowed to have the opinion to do new things and see how it goes. Each of the spins are allowed to work towards implementing this whenever they want. I suspect at this point we're mostly waiting to move to Wayland on the spins rather than doing work on Xorg stuff.
The ONLY reason Plymouth(from my understanding, a Fedora initiative) and Flicker Free boot was/is being adopted by other distros is because Fedora did the work for them. Since Fedora isn't putting in the work to ensure DEs on their own distro support it, no one cares and won't adopt it universally.
This is often why a lot of things Fedora does gets broadly adopted. We do all the work to suss it out and everyone else benefits.
And hey, all of those DEs are Open Source. It's almost like being Open Source doesn't increase the rate that something gets fixed. Imagine that.
Of course it doesn't, but it adds an opportunity for anyone to come in and do things. If someone is interested in fixing this for other DEs, they can at their leisure.
Maybe provide an optional rootless login session option in Gnome's login screen?
Again, it doesn't force things to change in the ecosystem, and worse, it makes it more difficult for QA and release verification, as we add another codepath to everything by doing this.
YOU ARE ALREADY DOING THAT WITH YOUR SPINS! YOU ARE FRAGMENTING YOUR OWN DISTRO FOR NO REASON! NO OTHER DE SUPPORTS THIS!
Dude, seriously, chill. The spins are managed by different groups of people. Feel free to ask *them* why they haven't implemented the feature yet.
Fedora isn't centrally managed by a small group of people, it's a fairly broad community with a lot of folks working on their own things.
FWIW, even if the application uses Flatpak, rootless X. Org still breaks the application. Would it be possible to grant individual applications privileged root access on a case by case basis?
That's a Flatpak/Flathub thing, not really under our control unfortunately.
No, it has nothing to do with Flatpak. The point was that Flatpak applications are still dependent on host X. Org and are susceptible to stupid crap that distros do, like this, despite supposedly being distro independent.
Flatpaks run on your computer, they're susceptible to anything you do too.
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
Maybe different versions of the software positioned it differently?
Ah, no. The menu I'm talking looks like the application icon itself. I've only seen it manifest itself in Arch Linux when you install another DE. No other Gnome applications in Fedora that I could see has it, and it does stick out... maybe it's a CSD compatibility thing for Cinnomon and/or Mate?
Ah, that's very possible. GTK+ has odd behaviors depending on desktop environment.
...but it happens on a pure Gnome Fedora and is the only Gnome application to have it...
I dunno. I use KDE myself.
On 9/23/2019 10:55 AM, Neal Gompa wrote:
On Mon, Sep 23, 2019 at 1:49 PM Ty Young youngty1997@gmail.com wrote:
On 9/23/19 9:56 AM, Neal Gompa wrote:
The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done.
Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change.
We are not, sure. But the Fedora distribution is allowed to have the opinion to do new things and see how it goes. Each of the spins are allowed to work towards implementing this whenever they want. I suspect at this point we're mostly waiting to move to Wayland on the spins rather than doing work on Xorg stuff.
This is true, but somewhat sidesteps the very real point that "Fedora Linux" has a larger-than-normal impact on the Linux ecosystem as a whole, as well as that it's essentially the branching upstream of RHEL, and thus all EL-derivatives.
IMHO it's entirely justified to criticize Fedora for questionable decisions or decision-making when those decisions impact non- "Fedora Linux" users. Disallowing that smacks of wanting to have one's cake and eat it too when it comes to influence. (See also: Fedora v. FreeDesktop decision-making)
-jc
On 9/23/19 12:55 PM, Neal Gompa wrote:
On Mon, Sep 23, 2019 at 1:49 PM Ty Young youngty1997@gmail.com wrote:
On 9/23/19 9:56 AM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 11:03 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 9:09 PM, Neal Gompa wrote:
On Sun, Sep 22, 2019 at 7:25 PM Ty Young youngty1997@gmail.com wrote:
On 9/22/19 5:51 PM, Samuel Sieb wrote: > On 9/22/19 3:10 PM, Ty Young wrote: >> I couldn't actually install the drivers because the update GUI in the >> cinnamon spin is broken and/or the repo/update servers are down. Again. > I don't know why you're having so much trouble with updates. But just > in case you're referring to rpmfusion as you have in other emails, I > hope you're aware that Redhat has nothing to do with them. They are > an independent third-party repo not managed by Fedora. They host > packages that can't, for various reasons, be distributed by Fedora. No, I meant the package manager GUI front-end won't work:
I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else.
If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora
It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help.
Also, Spanish(?) confirm prompt when rest of GUI is English:
...and proof X.Org on Cinnamon is running as root:
Yet on Gnome Fedora it isn't:
So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here.
Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME.
How would you propose we fix this bug, as you call it?
Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm?
Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work?
Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea.
So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe.
The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done.
Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change.
We are not, sure. But the Fedora distribution is allowed to have the opinion to do new things and see how it goes.
How it went was awful. No other distro/DE supported it and it breaks user applications.
Each of the spins are allowed to work towards implementing this whenever they want. I suspect at this point we're mostly waiting to move to Wayland on the spins rather than doing work on Xorg stuff.
Throwing the baby out with the bathwater, really? Wayland doesn't even work on a large selection of hardware(Nvidia) and has many missing features deemed to be vital for some people which X. Org does have. This has been a common criticism of Wayland and every advocates and developers put their fingers in their ears and ignore it. People are just going to continue to use X. Org, if this is they way you're going to do things, you realize?
The ONLY reason Plymouth(from my understanding, a Fedora initiative) and Flicker Free boot was/is being adopted by other distros is because Fedora did the work for them. Since Fedora isn't putting in the work to ensure DEs on their own distro support it, no one cares and won't adopt it universally.
This is often why a lot of things Fedora does gets broadly adopted. We do all the work to suss it out and everyone else benefits.
You do all the work and they seemingly contribute little. Whatever, if you're happy with that relationship that's on you.
However, not everything Fedora/Gnome does gets adopted by other Linux distros/DEs. This is one of those cases. Worse yet, your own spins can't/don't support it, resulting in in-distro fragmentation that developers have to cope with.
And hey, all of those DEs are Open Source. It's almost like being Open Source doesn't increase the rate that something gets fixed. Imagine that.
Of course it doesn't, but it adds an opportunity for anyone to come in and do things. If someone is interested in fixing this for other DEs, they can at their leisure.
Maybe provide an optional rootless login session option in Gnome's login screen?
Again, it doesn't force things to change in the ecosystem, and worse, it makes it more difficult for QA and release verification, as we add another codepath to everything by doing this.
YOU ARE ALREADY DOING THAT WITH YOUR SPINS! YOU ARE FRAGMENTING YOUR OWN DISTRO FOR NO REASON! NO OTHER DE SUPPORTS THIS!
Dude, seriously, chill. The spins are managed by different groups of people. Feel free to ask *them* why they haven't implemented the feature yet.
Fedora isn't centrally managed by a small group of people, it's a fairly broad community with a lot of folks working on their own things.
You broke my software, blame Nvidia for something *YOU* did, fragmented your own distro ecosystem which is already in a poor state, and refuse to fix it. I have every right to be upset.
They are *Fedora* spins. They are supposed to only be different in DE ecosystems, not commonly shared dependency software like X. Org, are they not? If you're not even going to ensure compatibility in your own distro you might as well not call them "spins" but "derivatives".
FWIW, even if the application uses Flatpak, rootless X. Org still breaks the application. Would it be possible to grant individual applications privileged root access on a case by case basis?
That's a Flatpak/Flathub thing, not really under our control unfortunately.
No, it has nothing to do with Flatpak. The point was that Flatpak applications are still dependent on host X. Org and are susceptible to stupid crap that distros do, like this, despite supposedly being distro independent.
Flatpaks run on your computer, they're susceptible to anything you do too.
Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd.
Maybe different versions of the software positioned it differently?
Ah, no. The menu I'm talking looks like the application icon itself. I've only seen it manifest itself in Arch Linux when you install another DE. No other Gnome applications in Fedora that I could see has it, and it does stick out... maybe it's a CSD compatibility thing for Cinnomon and/or Mate?
Ah, that's very possible. GTK+ has odd behaviors depending on desktop environment.
...but it happens on a pure Gnome Fedora and is the only Gnome application to have it...
I dunno. I use KDE myself.
On Mon, Sep 23, 2019 at 1:03 PM Ty Young youngty1997@gmail.com wrote:
Throwing the baby out with the bathwater, really? Wayland doesn't even work on a large selection of hardware(Nvidia) and has many missing features deemed to be vital for some people which X. Org does have. This has been a common criticism of Wayland and every advocates and developers put their fingers in their ears and ignore it. People are just going to continue to use X. Org, if this is they way you're going to do things, you realize?
https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-...
There are improvements happening in both Wayland and XWayland to address each of your concerns.
If some projects want to keep using X, that's their choice, but the X developers are the Wayland developers, and they're pretty much completely done with X. It's on life support. So if people who haven't been maintaining X expect others to keep doing that work, they're going to be disappointed. They need to be using what resources they have to make sure their stuff at least works on XWayland if not natively on Wayland. This is not news, by the way. It's been a long time coming.
On Saturday, September 21, 2019 5:32:37 PM MST Ty Young wrote:
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro.
It's an issue on several other distros. Basically, anything modern. Please file a bug report with nvidia.
- - John M. Harris, Jr. Splentity
On 9/22/19 2:40 AM, John M. Harris Jr wrote:
On Saturday, September 21, 2019 5:32:37 PM MST Ty Young wrote:
I'll just cut to the chase.
About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro.
It's an issue on several other distros. Basically, anything modern. Please file a bug report with nvidia.
Arch Linux and Pop!_OS 19.04 aren't modern? Overclocking on both works perfectly fine. I actually use Arch Linux normally, as said earlier.
John M. Harris, Jr. Splentity
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
I'll just cut to the chase.
Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
I guess debugging symbols are an alien concept to ArchLinux users as their distro sadly lacks them. There is a repo to provide nodebug kernels for rawhide
On 9/22/19 3:32 AM, Leigh Scott wrote:
I'll just cut to the chase.
Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc.
I guess debugging symbols are an alien concept to ArchLinux users as their distro sadly lacks them. There is a repo to provide nodebug kernels for rawhide
I know but you can't use them with Silverblue. One time I tried and the repos were out of sync despite all meta update info being cleared and fresh. Another time I got farther IIRC but was still blocked by an "replacing forbidden base package error" and wasn't able to get past it.
Even if I were to force it, would it cause conflicts and break in the future?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org