On 9/21/19 7:51 PM, Neal Gompa wrote: There was an article/blog post on Red Hat's website saying it was not long ago. Maybe you didn't see it? 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... The unreliable update servers affect Workstation too. Again, upgrades on workstation take forever. Silverblue is much faster. ...but I digress... again. 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 9/21/19 9:24 PM, Neal Gompa wrote: ...much harder because noone can agree on anything. OK, so why aren't distros system linking to maintain backwards compatibility? 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. 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. 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. 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... Really? I seem to remember it being announced to be removed in future Fedora releases not that long ago. Did that change? 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. 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. > > [1]: https://docs.fedoraproject.org/en-US/project/#_first > > >

On 9/22/19 12:48 AM, Samuel Sieb 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? 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 1:57 AM, Samuel Sieb wrote: 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. 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. 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. 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 Saturday, September 21, 2019 5:32:37 PM MST Ty Young wrote: 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: 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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, 10:09 Leigh Scott <leigh123linux(a)gmail.com&gt; wrote: Right. Last I checked, the Xorg processes on my system (NVIDIA + proprietary drivers) ran as root on fedora 30 Workstation. Fabio _______________________________________________

On 9/22/19 3:08 AM, Leigh Scott wrote: ...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 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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: 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 5:51 PM, Samuel Sieb wrote: No, I meant the package manager GUI front-end won't work: https://imgur.com/a/Dajf28T Also, GUI in general is buggy: https://imgur.com/a/W4bIzyO https://imgur.com/a/ELpjoAQ 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. 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 9:09 PM, Neal Gompa wrote: 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. 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? 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 11:03 PM Ty Young <youngty1997(a)gmail.com&gt; 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. 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. That's a Flatpak/Flathub thing, not really under our control unfortunately. Ah, that's very possible. GTK+ has odd behaviors depending on desktop environment. -- 真実はいつも一つ！/ Always, there's only one truth!

On 9/23/19 9:56 AM, Neal Gompa wrote: 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. YOU ARE ALREADY DOING THAT WITH YOUR SPINS! YOU ARE FRAGMENTING YOUR OWN DISTRO FOR NO REASON! NO OTHER DE SUPPORTS THIS! 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. ...but it happens on a pure Gnome Fedora and is the only Gnome application to have it... >

On 9/23/19 10:00 AM, Michael Catanzaro wrote: 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! 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. 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? This is a blatant lie. Breaking people's software absolutely impacts the user experience. 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. ...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.

On Mon, Sep 23, 2019 at 1:38 pm, Ty Young <youngty1997(a)gmail.com&gt; wrote: Oh nice. Then you can change that and stop complaining. Thanks!

On Mon, Sep 23, 2019 at 01:38:13PM -0500, Ty Young wrote: You're forgetten one very important thing: https://web.archive.org/save/_embed/http://safr.kingfeatures.com/idn/ck3/... As the old saying goes, "You catch more flies with honey than vinegar" - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur.

On Sat, 2019-09-21 at 22:24 -0400, Neal Gompa wrote: 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

On Mon, Sep 23, 2019 at 1:03 PM Ty Young <youngty1997(a)gmail.com&gt; wrote: https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstati... 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. -- Chris Murphy

On 23 September 2019 21:58:02 CEST, Ty Young <youngty1997(a)gmail.com&gt; wrote: 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. As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have. How about not interrupting that with something that was very clearly explained to you about 50 mails ago? 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? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 23 September 2019 22:42:35 CEST, Ty Young <youngty1997(a)gmail.com&gt; wrote: Why do you think anger will solve problems? Just point them towards Fedora and say that you can't do anything about it. I'm sorry if I was mistaken. You and everyone else are free to fork if you don't agree with upstream. 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. I understood what you wrote. It just didn't in any way fit with the conversation. 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 &gt;&lt;youngty1997(a)gmail.com&gt; >> >> wrote: >> >> >> >> >> >> On 9/23/19 10:00 AM, Michael Catanzaro wrote: >> >>> On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro >> >>> <mcatanzaro(a)gnome.org&gt; 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(a)lists.fedoraproject.org >> >>> To unsubscribe send an email to >> &gt;devel-leave(a)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(a)lists.fedoraproject.org >> >> To unsubscribe send an email to &gt;devel-leave(a)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(a)lists.fedoraproject.org >> To unsubscribe send an email to devel-leave(a)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