On Mon, Sep 23, 2019 at 1:49 PM Ty Young <youngty1997@xxxxxxxxx> wrote: > > > On 9/23/19 9:56 AM, Neal Gompa wrote: > > On Sun, Sep 22, 2019 at 11:03 PM Ty Young <youngty1997@xxxxxxxxx> wrote: > >> > >> On 9/22/19 9:09 PM, Neal Gompa wrote: > >>> On Sun, Sep 22, 2019 at 7:25 PM Ty Young <youngty1997@xxxxxxxxx> 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: > >>>> > >>>> > >>>> https://imgur.com/a/Dajf28T > >>>> > >>>> > >>> 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: > >>>> > >>>> > >>>> https://imgur.com/a/7ashccO > >>>> > >>>> > >>>> ...and proof X.Org on Cinnamon is running as root: > >>>> > >>>> > >>>> https://imgur.com/a/UcLjjKT > >>>> > >>>> > >>>> Yet on Gnome Fedora it isn't: > >>>> > >>>> > >>>> https://imgur.com/a/DlXwcdK > >>>> > >>>> > >>>> 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
