I hope this is not the new Linux philosophy?
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.
They 100% did the right thing.
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 SSH protocol is relatively simple by comparison, and most importantly, there actually are multiple independent modernized implementations of it.
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.
Ughhh
- 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.
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.
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.
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.
Now, this isn't released yet; thus, existing big endian systems that run Xorg are unaffected.