On Sat, Sep 21, 2019 at 9:32 PM Ty Young <youngty1...@gmail.com> wrote:
>
>
> On 9/21/19 7:51 PM, Neal Gompa wrote:
> > On Sat, Sep 21, 2019 at 8:33 PM Ty Young <youngty1...@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



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Reply via email to