On Tue, 31 Jan 2023 at 03:37, Niklas Schnelle <schnelle@xxxxxxxxxxxxx> wrote:
On Thu, 2023-01-19 at 19:46 +1000, Peter Hutterer wrote:
> On Fri, Jan 06, 2023 at 11:13:14AM +1000, Peter Hutterer wrote:
> > On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote:
> > > On Thu, 5 Jan 2023 at 08:20, David Cantrell <dcantrell@xxxxxxxxxx> wrote:
> > >
> > > > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote:
> > > > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote:
> > > > > [...]
> > > > > > > So I guess this means no remoting into ppc64 or s390x machines from
> > > > > > > x86_64 or ppc64le machines without a configuration tweak?
> > > > > >
> > > > > > We don't have ppc64 builds anymore and I don't know the last release
> > > > we had
> > > > > > that was ppc64, but it was a long time ago now. All current POWER
> > > > systems are
> > > > > > ppc64le.
> > > > > >
> > > > > > And everything else we have as primary or alternative architectures is
> > > > little
> > > > > > endian, except s390x. I do view this as a risk for s390x because of
> > > > all the
> > > > > > architectures we build for, this one is the most difficult to use
> > > > graphically.
> > > > > > Exporting your display is still the convenient method for this
> > > > platform.
> > > > > >
> > > > > > Given that this change proposal affects default behavior, I don't see a
> > > > > > problem with it. s390x users can drop the configuration change in
> > > > xorg.conf.d
> > > > > > to regain the functionality. If that can be conditionally enabled for
> > > > s390x
> > > > > > at package build time, that might make things easier (but wouldn't you
> > > > need to
> > > > > > make the change on both the s390x host and your non-s390x
> > > > workstation?).
> > > > >
> > > > > The X protocol works that the first byte of the connection request is a
> > > > > either 'l' or 'B', telling the server that the client is little or Big
> > > > > endian. The client has no information on the server's endianess.
> > > > >
> > > > > This means the configuration needs to be done wherever your X server
> > > > > runs, so the (little-endian) thing you're sitting in front of. Which is
> > > > > also why compile-time defaults are difficult, at compile time we cannot
> > > > > know that eventually you may want to connect from an s390x.
> > > >
> > > > Reasonable. The runtime configuration change I can make locally to allow
> > > > me
> > > > to run X programs on an s390x and display them locally is sufficient for
> > > > me.
> > > >
> > >
> > > Wasn't there a concern that you can do this if you are running a desktop
> > > with X, but if you are using Xwayland it isn't easy (or maybe possible) as
> > > the configuration to do that was either hardcoded or not fully documented
> > > on how to do that?
> > >
> > > From Peter Hutterer <peter.hutterer@xxxxxxxxx> earlier:
> > > ```
> > > but you don't necessarily have
> > > access to how Xwayland is started (mutter certainly is hard-coded).
> > > ```
> >
> > Correct, the Wayland compositor is responsible for starting up XWayland
> > and that's not always configurable. I've filed bugs for mutter, kwin and
> > wlroots so the developers are aware and that should cover the majority
> > of Wayland use-cases once fixed.
>
> just a minor follow-up: mutter has that feature merged now for GNOME 43
> [1] so a once-off gsettings call should do the trick there:
>
> $ gsettings set org.gnome.mutter.wayland xwayland-allow-byte-swapped-clients true
>
> Cheers,
> Peter
Thanks for opening the BZs and creating these settings. So, this means
at least our use case of SSH terminals with the occasional X client
and/or copy & paste via X at least has a workaround. I'm still
skeptical of the cost to benefit ratio here though. On the LWN article
about this someone mentioned that there are also Big Endian
oscilloscopes that are used with X remoting and I suspect there are
I expect there is a 'lot(*1*)' of industrial hardware with a 40-50 year lifetime built from Sparc, Power and similar big-endian chips. The majority of them are usually tied into a system which is also running a 10+ year old OS because various associated binaries were last built in 2009 or so. The code even if it is available will end up being 'uncompilable(*2*)' because it is built around K&R C, Prolog, or some other language which isn't seeing a lot of work these days.
*1* A lot is probably in the order of a couple thousand or so around the world. There are at least 150k Fedora workstations in use around the world at any time. There are at least an equivalent number of Ubuntu desktop users. The people who need to talk to those industrial systems can make it work.
*2* without some amount of work by someone who knows the language and tasks the code was meant to follow.
other industrial appliances too. Personally I think with X11 more or
less in maintenance mode for decades to come the likelihood of new bugs
The issue isn't that there are 'new' bugs but existing ones which we have papered over or just assumed were part and parcel of the system. There are a lot of 'well it just causes the X server to crash so just firewall it' which have for years accepted only to become a firebomb when a compiler or associated library change makes it a 'oh you don't crash anymore but now give root access to the user's system.'
The issue is also because it is in 'maintenance' mode. Due to people retiring, dieing, etc we are going to have less and less programmers who know the code in order to fix it if it turns out there is an issue. Just like you should turn off a nuclear reactor before you leave, you shouldn't leave code which you no longer trust blindly open.
in this area is somewhat low even with few users. Together with X and
especially X remoting becoming more and more a niche thing itself
keeping those niches where it is still needed working out of the box is
a worthwhile effort. But in the end I'm not an expert on this and I'll
trust the judgement of the experts.
Thanks,
Niklas
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
