On 9/21/19 9:24 PM, Neal Gompa wrote:
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.
...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.
[1]: https://docs.fedoraproject.org/en-US/project/#_first
_______________________________________________
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
