So ... the majority opinion here is that it's fine to break things, because we use Linux on Intel/AMD, and clients from other backgrounds will have to sort things out for themselves. Even though we took X from systems with other backgrounds who considerately handled both byte orders!
An argument was made about reducing the potential attack surface.
How many big-endian systems can you currently point out in your environment? How often do you use X11 forwarding? What's the intersection of these two sets?
Even if you somehow do have even one such system, you're pitting that incredibly niche use case against the security of literally every single other X11 user on the planet, which is easily millions.
I haven't dug through the X server code, but byte-swapping ought to be an insignificant attack surface of the code. Most network protocols do this already; ssh does it!
The only thing that matches with what I have observed from the X developers is that the X code is, in general, a steaming pile of shit that nobody wants to wade through anymore and so any bit that can be disabled and/or removed is unambiguously a Good Thing. The design of Wayland strongly implies that network transparency is a non-feature for the X developers, so everything surrounding it will be a target for removal.
The problem with the X server code is most of the protocol code is very complex and it's hand rolled code predating C89. It (still!) does all the parsing and byte swaps manually. In a modern project you would have the compiler generate the parsers and the dispatch table based on an IDL but X is way too old to have done this. There are just two implementations in the code for everything. No one wants to touch it due to fear of breaking everything even worse. So instead they just slowly try to stop the bleeding by disabling things that cause the worst security issues. It's a bad situation overall, and the time has already passed for a full rewrite of the X server to be viable.
The SSH protocol is relatively simple by comparison, and most importantly, there actually are multiple independent modernized implementations of it.
“Will have to add a config option and go on with their day.” I’m sure the 3 people who need this will be terribly angry.
Honestly Linux userspace is such a mess that sure whatever break anything you want. You can’t make it that much worse. I’ll happily suffer and patch my stuff to get to a better future state.
- Just throw out PAM, to hell with any pre-existing modules.
- Also throw out NSS, having the official API for anything be dlopen is horrible. Get it in the kernel so Go and other “who needs libc?” languages don’t need special handling on Linux. Use request_key to actually do the lookups.
- Pick a god damn message bus and get it in the kernel. It should probably just be kdbus but as long as we commit to it it doesn’t matter. Apps need to be able to talk to one another in not bespoke ways.
- Actually decide that a “session” on Linux is a real thing and not something that every project has to invent for itself.
- Scrap ulimits, good idea initially, didn’t age well.
- Scrap TCP wrappers. If you actually use them you deserve to be broken.
- Throw out iptables. Remove it entirely. There is too much bullshit resulting from the fact that iptables needs to fully own netfilter. Apps should be able to mess with the firewall and not get in one another’s way.
- The linux security model is backwards. All applications spawned by me have permissions to read, modify and write all of my data. The security model stops malicious programs messing with the operating system (which I could just reinstall anyway). But the security model does nothing to stop programs corrupting / encrypting / stealing my data. Wat! We need capability based security for applications (or something like it). Its not sexy, but applications need to have restricted access to my filesystem.
- The file API is a bit of a mess if you want to edit files atomically. (And who doesn't? Crashes should never result in corrupted data). Implementing atomicity in userspace on top of the existing write() and fsync() APIs is inefficient and stupidly complicated. The kernel should add an API which does atomic writes to files, and 90% of applications should use it. And while we're at it, add either a syscall for file write barriers (sort of a much finer grained fsync) or add completion events like windows has had for decades. That would let us dramatically speed up modern databases, with basically no cost.
- Files in sysfs/procfs/etc should contain JSON. Handling 18 bajillion text files, each with custom formatting is awful. And if you want to watch for changes, the current model of polling + diffing is ridiculous. We should have a generic "watch item" API to get granular JSON patch (or something) events from kernel objects. That could be used to monitor network traffic, handle USB+bluetooth device insertion/removal/status change, see the firewall status, debug kernel drivers, tell you when a file has been modified, and so on.
Disagree on 'Firewall' at the app layer. That's a security domain and there should be a standard way for apps to _ask_ the security layer for something.
X was developed on VAX, 68k, and later SPARC and then x86. VAX and x86 are little-endian, while 68k and SPARC are big-endian. Portability across these platforms was important and this was the inspiration for the RPC (now gRPC) platform-independent external data representation (XDR) standards.
Things were still not perfect with portability even back then. I remember taking a class in OSF Motif where everybody in the class was using SPARC while I was using x86 Linux. The code was somewhat portable between platforms, but many of the arguments to the (Metroworks) Motif library functions needed their endianness swapped in order to work properly on Linux, so the code examples from the course would not run on Linux without modification.
I realize that there may be some performance improvements realized by removing cross-platform compatibility, but I do not believe that the performance gains are worth the loss in platform compatibility. If X.org does this, it will eliminate one of the core reasons for sticking with X vs. Wayland.
Your comment implies it will break on anything that's not "Linux on Intel/AMD", but that's not the case. Most architectures are either little-endian or support both little- and big-endian (although not all operating systems support little-endian on a bi-endian architectures, e.g. I believe AIX doesn't).
I'm willing to bet that the number of big-endian systems amounts to less than 1% of all systems running X, and the number of those that use X forwarding is a subsection of that. I'm big on maintaining compatibility, but it's a fairly minor break which benefits almost everyone and affects very few people.
PowerPC is big endian, but it seems like the world has been standardizing/converging on little endian for a while now. It's not just Intel and AMD, it's also all ARM CPUs and RISC-V.
To me, this seems a bit similar to the 8-bit byte. We take that for granted nowadays, of course memory is divided into bytes, but it wasn't always so. There used to be machines with memory that was addressable only in 36-bit or 40-bit words. There also used to be machines that uses one's complement to encode negative integers, before everything became two's complement.
I hope that eventually, all CPUs are little endian. It's easier to interoperate without these arbitrary distinctions.
The Linux philosophy was NEVER about supporting computers from 30 years ago. It was about supporting cool new architectures. Big-endian systems are ancient history now. No new cool bendian systems are being made. The kernel still supports them, for now.
There is little new about this philosophy, even the kernel itself has always consider genuine security concerns a higher priority than not breaking userspace (which is otherwise a much stronger guarantee than applications are expected to give themselves).
It's trivial for distros and OSes that still ship to big endian architectures to add, by default, a single Xorg config file enabling this. There's all sorts of things that is put by default in /etc, and this would be yet another one.
Now, this isn't released yet; thus, existing big endian systems that run Xorg are unaffected.
I recently installed Debian 11 to move away from Ubuntu, which is starting to annoy me with all those snaps. Debian starts with Wayland as default. It worked and I realized I was in Wayland only after I started digging into the refresh settings, because I had some wave patterns on screen. It's an old laptop from 2014 with a NVIDIA K1100M. It turned out that Noveau doesn't handle it well with any of the available refresh rates of 60, 59.95 and 40 Hz: the wave patterns never goes away. I installed the NVIDIA driver, which works only with X11, and my display is fine at 40 Hz, same as it was in Ubuntu. So I'm using X11 in 2023 and probably will until this laptop will work for me. Feature wise X11 has demonstrated to have all I need, since 1990. I don't need Wayland.
Even if you don't need any features in Wayland there are still benefits, it closes some security holes and it fixes some long-standing bugs in X. Of course it also creates some new bugs like your buggy nvidia driver.
I hope this is not the new Linux philosophy?