On Tue, 31 Jan 2023 at 03:37, Niklas Schnelle <schnelle(a)linux.ibm.com>
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(a)redhat.com>
> > >
> > > > 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
> > > > > > > x86_64 or ppc64le machines without a configuration
> > > > > >
> > > > > > We don't have ppc64 builds anymore and I don't know
> > > > we had
> > > > > > that was ppc64, but it was a long time ago now. All
> > > > systems are
> > > > > > ppc64le.
> > > > > >
> > > > > > And everything else we have as primary or alternative
> > > > little
> > > > > > endian, except s390x. I do view this as a risk for s390x
> > > > all the
> > > > > > architectures we build for, this one is the most difficult
> > > > graphically.
> > > > > > Exporting your display is still the convenient method for
> > > > platform.
> > > > > >
> > > > > > Given that this change proposal affects default behavior,
don't see a
> > > > > > problem with it. s390x users can drop the configuration
> > > > xorg.conf.d
> > > > > > to regain the functionality. If that can be conditionally
> > > > s390x
> > > > > > at package build time, that might make things easier (but
> > > > 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
> > > > > endian. The client has no information on the server's
> > > > >
> > > > > This means the configuration needs to be done wherever your X
> > > > > runs, so the (little-endian) thing you're sitting in front
> > > > > also why compile-time defaults are difficult, at compile time
> > > > > know that eventually you may want to connect from an s390x.
> > > >
> > > > Reasonable. The runtime configuration change I can make locally
> > > > me
> > > > to run X programs on an s390x and display them locally is
> > > > me.
> > > >
> > >
> > > Wasn't there a concern that you can do this if you are running a
> > > with X, but if you are using Xwayland it isn't easy (or maybe
> > > the configuration to do that was either hardcoded or not fully
> > > on how to do that?
> > >
> > > From Peter Hutterer <peter.hutterer(a)who-t.net> 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
> > 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
>  so a once-off gsettings call should do the trick there:
> $ gsettings set org.gnome.mutter.wayland
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
*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
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.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren