It is a bug in Xwayland. Theoretically the rest of the world is not affected. Apparently some people think that breaking compatibilty is the way to go.
It's really hard to test big-endian software -- because almost no-one (and in particular no devs) really run big-endian CPUs anymore.
There are a few programs I work on where we "officially" disabled big-endian support, because it's just impossible to find devs to work on it. It's also hard to test, you can't test it on github actions for example.
I'd be happy to see some people step up for testing big-endian, but at the moment it would be a huge time-sink for many projects, when it's not even clear if there are any users.
(Pardon the rushed job of writing C in an HN form on mobile.)
This exercises the same deserialization from little endian regardless of the hardware representation of integers. This means you are testing how it will act on big endian even when running on little endian.
The problem is that it's hard to be certain that you actually did it correctly everywhere if you aren't testing it. Writing endian-neutral code isn't terribly difficult, but you can easily accidentally write endian-dependent code here and there.
This works when your serialization format is designed to be either big or little endian. But for some programs, the serialization format is memcpy the structure to disk. This isn't a good strategy, but unfortunately it can be difficult to undo historical choices.
So the padding, alignment, endianness, all leak. And it sounds like X does something like this: clients expect the endianness of serialized data to match the local machine and the server can optionally account for this.
Code like that second one (using shifts) is generally what I do always (dealing with small-endian, big-endian, or PDP-endian data), anyways. Hopefully, the compiler will be able to optimize the code so that it works like the first one. (I don't know if the compiler actually does optimize it or not, though. However, it seems to me that a code like that should be common enough that it would make sense to implement such an optimization.)
Yep. Rust's APIs do this right. Eg u32::to_be_bytes() / u32::to_le_bytes() and u32::from_be_bytes() / u32::from_le_bytes().
There's also methods for native byte order, but thats almost never the right thing to use.
I think Go does the same thing. I heard about this approach first from Rob Pike, who would rant about this to anyone who would listen. He said to think of "bytes on disk/network" and "an integer in RAM" as different types that you need to convert between. When you do, the API should specify the endian-ness of the bytes on disk / in the network. He argued you shouldn't do "byte swapping" at all based on endianness. Just parse the int, byte at a time and use the same code on every computer.
The real problem is that C makes it easy to convert between a pointer to an integer and a pointer to some bytes in RAM. Just never do that using pointer casting, and everything works out great.
We agree. I'm writing it out as an example. In real life you would put it in some kind of helper function. (Or macro.) I'm not suggesting writing it out inline on every access.
In that case I disagree. You can't guarantee that the shift-and-or will be optimized out by the compiler in cases where no swapping is needed so you're making the code potentially slower.
If you put that in a helper function, then kind of.. except ntohl and ntohs deal with big endian. And is a no-op on big endian. And there is no ntohl for 64 bit quantities.
It's really hard to test big-endian software -- because almost no-one (and in particular no devs) really run big-endian CPUs anymore.
BE is still common in networking hardware (due to being the traditional "network byte order") and mainframes. The most widespread BE hardware would probably be the cheap un/rebranded routers with MIPS SoCs.
MIPS can use either big or little endian modes, though. SGI used MIPS in big endian mode, but some of the stuff out of China using MIPS today is little endian. Some devices include a hardware switch that lets you choose.
ARM also supported both, but you don't really see ARM used in big endian mode today.
Most networking gear control plane CPUs at this point run little endian (and x86 is surprisingly common). Even the ARM SOCs in most APs are running LE.
I know MIPS was still common for low-end 802.11ac routers/APs (eg. MT7621-based devices). Is it being used by anyone for systems designed around newer standards (802.11ax/WiFi 6/6E, multi-gig Ethernet) or has the market finally shifted over completely to ARM?
MIPS, yes, but not big endian. Last time I started building binaries for my (utter junk) EdgeRouter-X I ran into issues with mipsel stuff not being well supported. If Marvell and MediaTek aren't putting out big endian MIPS stuff I'd be surprised if anyone was.
I guess it's not too surprising somebody paired newer radios with the MT7621 SoC. I see now that MediaTek even lists that application on the product page, so they're probably not going to retire that processor anytime soon: https://www.mediatek.com/products/home-networking/mt7621
> because almost no-one (and in particular no devs) really run big-endian CPUs anymore.
This is a big problem, because we may be introducing subtle bugs that are actual bugs that just happen to work because the hardware is arranged in such manner.
A lot of our stacks these days is built from source and very portable. We can certainly do better than everyone using the same CPUs.
IMHO, it's a bug if it's not specified. If your code looks portable and compiles on a big endian machine and fails, that's a bug. You should really at least fail compilation.
This is different than say a video game that works fine on hardware, but breaks in emulation, as sometimes happens. The game isn't buggy, the emulation is (or at least, it isn't complete), even if the game is writing to 'weird' addresses; it works on the specified hardware.
IMHO, it's a bug if it's not specified. If your code looks portable and compiles on a big endian machine and fails, that's a bug. You should really at least fail compilation.
I don't care about non-8-bit bytes either, and a bunch of other things, but having to deliberate add checks to "say no" just because someone might decide to use your code on some odd machine is a pure waste of time and even encourages the sort of lock-in and "environment nitpicking" that proprietary software vendors love.
As the saying goes, common sense is unfortunately not so common these days.
> As the saying goes, common sense is unfortunately not so common these days.
Ignoring the existence of big-endian computers is not really common sense. They DO exist. And it'd be very useful to test in both little and big-endian architectures. I cover the endianness tests by running my TravisCI pipelines on amd64 and s390x, but both run on Linux, which is sub-optimal. I should probably add AIX so that I'm not implying the OS is Linux and importing linuxisms into the code when it should be more portable than that.
Before we even get to endianness, there's a lot of C and C++ code out there in the wild that is technically broken because it assumes much more basic stuff like int being "large enough" - but the language spec only guarantees you 16 bits.
I think at some point we should just bite the bullet and say that this kind of stuff is not really meaningfully standard anymore, and the few niches that need it can be accommodated with extensions. It doesn't really make sense to place a tax on everything else.
> It's arguable whether that's a bug if it doesn't have any practical effect.
If doesn't have any effect until it does and, out of nowhere, you start getting crashes on some new hardware category that you thought was supported. That's not a great place to be.
Even before the move to x86, Apple was making sure OSX (which was based on NeXTSTEP, which was very portable) would not bake in PPC-isms that would hurt its portability. Apple learned the lesson with the painful port of MacOS classic to PPC and that care with OSX paid handsomely with the moves to x86 and then to ARM.
I've compiled and tested software for big-endian, using a s390x/debian Docker container, running it with qemu-s390x-static. It is quite slow though. To make it somewhat bearable, it is important to do the actual compile unemulated (using a cross-compiler), and then only actually test the binary under emulation. Although I was doing it all on a little Intel NUC, it would probably be somewhat more bearable on beefier hardware.
Not because I had any actual need to do this, just because it was fun.
You can get a small AIX system from IBM Cloud for US$50/month. I've thought about doing that – maybe some day I will. If I really wanted to I could afford it.
What big-endian hardware worth mentioning exists now, if we exclude historical hardware which we maybe want to keep up, but which is not produced any more?
In fact, Power ISA is probably the last architecture where both modes still have notable importance: AIX, IBM i and OpenBSD still run Power big, FreeBSD runs it big but work exists to run it little, and most Linux distros run it little (not counting 32-bit PowerPC, which pretty much always ran big).
Most of the other notionally bi-endian architectures nowadays have settled on one. For example, SPARC is just about exclusively big; conversely, ARM64 got rid of their big-endian mode.
It's annoying that some file formats (and of course protocols) are still using big endian. Otherwise yes, the world has effectively standardized on little endian, it's fine to let big endian die outside of some weird niches.
> because almost no-one (and in particular no devs) really run big-endian CPUs anymore
It is a network protocol, just put a proxy between client and server that byte swaps the affected fields and changes the endian flag. No need for hardware.
Better yet: Throw out the endian flag and define the network protocol as always being big/little endian. Network protocols which can swap endian order is a terrible idea. Let it die.
Convert from bytes in (whatever) endian order to bytes in memory when data is read and written using a uint32_t parse_le_uint32(uint8_t[4]) method or something similar.
They should. Such proxy would allow any mismatched client and server combinations. And, considering how X makes the detection, the matching could be automatic.
None of which are supported officially by Debian, with notable exception of ppc64el (POWER8/9 little-endian). The only official port with big-endian is s390x. [0]
Yes, seems these days nothing exists but Linux. Almost like the old Microsoft days. Being on a BSD this annoys me. Seems this could be yet another thing that will prevent Wayland from running on anything but Linux on x86 type systems.
But I have no plans to ever use Wayland until they get Network Transparency anyway, so as far as I am concerned it is not a huge deal for me (yet). So I will annoy the developers :)
Yes, I do understand the Wayland people are working hard and I appreciate their work, but I wish they would make Wayland easily portable to other UN*X Systems.
There's no such thing as "network transparency" anymore. Newer desktop apps are now written to assume GPU rendering and that's local only, even on X11. If they implement software rendering at all, it's a separate code path provided as a slow fallback. If you were using X forwarding to run old clients, you can still use XWayland to forward them. It's the same idea as using XQuartz on Mac, you run rootless X11 on top of another window system. VNC should also work on every Wayland implementation I've seen.
Part of the reason Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. Wayland doesn't really have userspace drivers like X11 did, the current implementations assume that the kernel is just going to handle all of this. The other kernels really need to be implementing evdev, DRM and KMS to get the full range of support for input and graphics hardware. Without those APIs, those other kernels are on their own trying to figure out how to get modern hardware to work and how they're going to plug random drivers into Wayland, when that model is obsolete as far as Linux is concerned.
At one point I had a working glx(opengl using a x11 transport) setup, In short the X client(running on a remote machine) would send it's opengl stream down the network and the X server would render it using it's GPU. It was pretty cool to see accelerated graphics for a program running at the far end of a ssh session.
When sgi ported gl to X11(glx) they were very careful to use only the network transparent communication paths. The idea was you would run your program on the supercomputer down the hall and display it on your badass graphics monster of a sgi workstation. The feature has only worked intermittently since then as future maintainers were not so careful.
edit: I found a guide, no idea if it still works, The feature was always rather niche and fragile.
> Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. [...] The other kernels really need to be implementing evdev and dri3 to get the full range of support for input and graphics hardware.
Other Unix systems are indeed far behind implementing Linux-specific interfaces. Windows and macOS will likewise have a hard time.
Are we reading the same thing? Those issues show that it materialized years ago:
>FreeBSD and NetBSD have epoll-shim which implements epoll through *BSD-specific kqueue
The shim works fine already, why fix what isn't broken?
And it's not that those other systems lack Linux-specific interfaces, it's that the ones missing those APIs lack any interfaces for these things at all! There's no way to be portable here, there's nothing to port to! If they decide to implement this eventually, why not copy the Linux API that's already open source and we already know it works, instead of reinventing the wheel? Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway? And BSDs have already implemented parts of those APIs separately so we know they don't actually have a problem with them!
> The shim works fine already, why fix what isn't broken?
If it works fine, why not import it into the project?
> Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway?
FreeBSD and OpenBSD are slowly doing exactly that. But DRM, GEM, etc, aren't just any generic API, they're a constantly evolving blob of Linux-oriented calls and data structures. Though at the end of the day this is probably the most defensible aspect of it. And an important distinction here is that the drivers issue pertains to Weston, whereas the kqueue issue applies to libwayland, the ostensibly environment agnostic library which implements the Wayland protocol (libwayland and the Wayland protocol are basically one and the same as the protocol is basically an old-school RPC mechanism inextricable from the implementation as a practical matter).
But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux. Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W....
>If it works fine, why not import it into the project?
Why? The shim is generic, it's for porting any Linux programs.
>And an important distinction here is that the drivers issue pertains to Weston
It would also affect the other Wayland implementations, which would need to adopt the same driver system. Those drivers would have to duplicate a lot of code from DRM and Mesa, it's just not worth it to put all that code into another library and then make Weston use it.
>But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux.
Again, what is there to port to? Those other systems are behind in supporting the APIs needed for modern hardware. There's no alternative to DRM, GEM, KMS, etc.
>Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W....
I think you know that X11 wasn't exactly good at any of that. I would think BSD users appreciate all of that because they all have different opinions on how all those things should be done.
The common web browsers or web-based apps are all using hardware accelerated Skia. Almost nothing uses the core X11 APIs anymore.
I'm honestly confused when I hear people say they still use X forwarding and it has no slowdown. It's known to be one of the worst possible options for remoting, the core protocol doesn't even support image/video compression. RDP runs circles around it.
I don’t know what to tell you. I use Firefox every day over X forwarding and it seems to work just as well as anything else with no noticeable slowdown.
This is exactly my confusion, why people say there is one. I guess things would be different if I was trying to do it over low bandwidth high latency sat connection or something. At least with connections as slow as 50mbps I have not noticed any issue, I don’t have anything slower to readily test to see what people are talking about. I’ve no doubt it’s theoretically slower due to e.g. compression but that doesn’t seem to be a big practical concern at least for most connections and use cases.
I’ve found it highly concerning because the other solutions will not work for me, but adherents seem to insist what’s working for me doesn’t.
I mean if you have a high bandwidth connection and you want to only transfer raw uncompressed software-rendered images then sure, go nuts. For me that lags horribly and it's pretty much broken if you try to remote a fullscreen window above 1080p. It's not exactly "network transparent" if it only works in a very contrived network situation. What do you think a remoting protocol is supposed to do if not compensating for bandwidth and latency issues? These are really basic things (bandwidth negotiation, latency compensation) but they were just never added to X11. And it's not like people didn't try to add them either!
Edit: I want to say that nearly everything in X11 is like this. It seems to work ok at first glance but it breaks horribly when you get outside the design parameters of a mainframe in 1987. So basically, transferring software-rendered images over a high-bandwidth LAN connection and that's it.
I haven’t had any trouble with 1920x1200, but I haven’t tried to watch full-screen 1080 video or something either. Probably the most intensive thing I’ve done is watch IP camera streams on Firefox over X forwarding.
I understand that not everyone has > 50 mbps connections but I don’t think this is a contrived fringe edge case either. Meanwhile, the present alternative of “just use rdp” or “just install this package” is completely infeasible for me. And I mean, ant some point, bandwidth is a factor no matter what you do, though I agree more efficient is theoretically better. Unfortunately my job is going to get a lot harder down the road when X is retired for good.
If your IT department at work refuses to give you a modern solution I think that's their problem, not yours. They should just know, X11 forwarding was already obsolete decades ago. They're just signing up for trouble and misery with that.
I doubt that X11 is going to disappear for good. It will still always be around for running the odd old X client or for historical curiosity. Just like how you can still emulate the original Macintosh (released the same year as the original version of X!).
We don’t have an IT department per se but hundreds of offline sites consisting of thousands of servers each which cannot be changed in this manner and for which neither I nor any person I have ever met has the option of complaining that they’re using “obsolete” solutions that happen to work fine. The more likely end result is that there will simply be no GUI available on most servers when more recent OS releases are deployed and we will shrug and life will be worse.
So I guess you can say it’s someone else’s problem but it sure feels like my problem.
I can't understand the situation here. Why wouldn't a more recent OS release have a VNC server available? And why is a web server being used to run firefox? Shouldn't that be run on the client? Why are you even installing a GUI on a Unix server? It seems to me like something is very backwards about your setup.
So you are volunteering to step up, test and maintain the big endian code? Feel free to grab some PRs and fix them to demonstrate your willingness.
This comment from the article fits:
> Having it be an option that's turned off by default just ensures that it will rapidly end up broken because of its "niche"ness, and then removed because it keeps causing breakage. Do it all the way or not at all.
The problem is that X11 is actually in a zombie-like state right now. It's not dead because it mostly works, sorta, because people keep stitching extra limbs on when enough people bitch. However, it's not actually alive because nobody really wants to work on it and ...
Every single architectural assumption that X11 made is now wrong.
CPUs are stupidly powerful. Triangles, not bitmaps, are the fundamental primitive (to be fair, this one may be starting to flip back as GPU computing becomes more ubiquitous). Network is vastly slower than CPU and latency has gotten ferociously worse. Input methods aren't just mouse and cursor. Sharing is a problem and secure should be the default. etc.
I have written code for X11. I have written initialization code for graphics cards to deal with X11. X11 coding is hell.
Wayland may not be the answer, but X11 needs to die before we will get to that answer.
At more centrally-administered sites, a user might not even have the ability to change an X server option. The idea of making a toggle via xset sort-of makes sense, but seriously, isn't the idea generally that you trust the apps you're running anyway. And doesn't a vastly different wrong number in some X call at least produce an effect that makes you aware of the problem (I know, that doesn't make a X server more stable...).
It's just baffling to make something near-universally available less so. The next new CPU thing could be bigendian - or quantum, but who knows what byte order that would prefer.
> but seriously, isn't the idea generally that you trust the apps you're running anyway
Yes, and it is a bad idea. Trusting your apps is how we've gotten in the state we are today with virus scanners and the like. Generally you want to trust as little as possible (at least in tech).
> the state we are today with virus scanners and the like. Generally you want to trust as little as possible
This is only true if you run closed source software on non-free systems. I honestly can't remember that I ever had to use a virus scanner on Linux or UNIX.
You still have to worry about vulnerabilities. It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys, but unfortunately this is how many Linux distros, ignoring Android based ones, work.
> It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys
So far this never happened on free operating systems running free software on X11. Hence I refuse to believe this is a realistic threat scenario. Severe sandboxing is only necessary for untrusted/non-FOSS software otherwise it just harms user experience an productivity especially for power users.
Do you use a modern browser? If so, you use a piece of software that has been exploited many times by attacks in the wild. Those attacks were mostly targeting either a phone OS or Windows or macOS - not because there is anything in desktop Linux that would defend against those attacks, but because it is less popular. Perhaps some attacks did target desktop Linux; it’s hard to tell because few in-the-wild attacks are publicly documented in detail (although Project Zero has a spreadsheet of bugs known to have been exploited in the wild [1]). Regardless, at best you are relying on security by obscurity. And that’s despite the fact that modern browsers already have built-in sandboxing; without it the situation is worse.
On a modern Linux distro a web browser installed from Flatpak/Snap will be sandboxed in a container. But you need to be using Wayland too (or setup a separate X11 sandbox) because X11 circumvents the container. Example code for it here: https://mjg59.dreamwidth.org/42320.html
There are code execution vulnerabilities in common software, including the kernel and your favorite browser, probably at least once a month, and likely more.
You can go checkout a CVE listing website if you don't believe it.
The thing you may be not thinking of, is that the software itself doesn't have to be intentionally designed to be malicious for it to do harm. Lots of software is written in memory unsafe languages and is full of nasty subtle bugs that can be exploited.
There are also supply chain issues, your favorite open source project's maintainer might have their github credentials phished, and code to do something nasty sneaked into an otherwise normal seeming update. This has happened and is not just a theoretical scenario!
No one wants to maintain backward compatibility for decades with computer architectures no one actually uses anymore. There are more innovative, exciting things to work on.
Big endian is so dead, you can literally design a binary network protocol that has all fields 64-bit aligned, little endian, slurp the packets into a buffer, cast the buffer to a struct, and be fine across ALL architectures you'll likely run in production.
This, by the way, is why X11 itself is slowly bit-rotting into irrelevance also: no one wants to maintain it. Most of the protocol exists strictly for legacy applications -- modern ones use the X server as a framebuffer compositor and that's it.
The great thing is that if you actually follow this logic you never need to care; nobody uses anything but Windows for graphical applications anyways, so X11 (and Wayland, incidentally) is irrelevant in all cases. Or... did you mean to suggest that your niche platform matters but not this other niche platform?
I understand where you are coming from, but I think at the end of the day, if there are people on $platform who are willing to contribute, that's all that actually matters. If there aren't enough users, there will be nobody to support it, so it dies. In other words, it not about how much one platform "matters" over another to some users.
We can't expect people to work for free to support our platforms with no benefit to them.
If you really care, I guess donate some hardware, or pay some developer to work on this, or provide support yourself! I know that sounds rude but it is what it comes down to.
It seems like in this specific case X11 will still support whatever exactly this feature is but will put it behind a config option. The idea above applies in general to open source work though.
the original title has (by default) added to it, and the article points out it remains available as a config flag.
so the real discussion should be if it's the clients or the servers obligation to reorder binary integers as needed, or if the standard requests both to be in network byte order. technically do you use hton(3)/ntoh(3) [1] on every call in server and client, or do you apply it conditionally, on just the "smarter" side, and only if server and client native byte order mismatch? if you have the intelligence in the server you're hitting speculative execution all over the server, "penalizing" every user of the server, if ever so slightly, and "hardener" so if you have a mixed bag of clients, so speculative execution fails regularly.
so you move the burden to conditionally swap bytes to the clients, all of them. chances are the clients will talk to just one server. the price you pay is clients without byte swap option simply can't connect.
I _did_ run (virtual) X Servers on zSeries to run graphical software locally, on The Host (remote access via vnc), and all of this _does_make sense.
This is amusing because network byte order is big endian.
The title should say ‘no longer allows big endian clients.’ Or does it deny all byte swapped clients ie if the server is big endian it disallows little endian clients?
> So to this day whenever a client connects, the first byte it sends is a literal "l" or "B" to inform the server of the client's byte order. Where the byte order doesn't match the X server's byte order, the client is a "swapped client" in X server terminology
So it's wherever the client doesn't match the server, which ever way around that is.
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'm just amazed X is still a thing. It's the definition of niche. I can't even imagine putting dev ours into it. It should seriously just be dropped and abandoned. X is one of the most detrimental pieces of technology holding desktop Linux (or *nix) back.
I still wish Ubuntu went with Mir over Wayland (which is also trash).
If you want remote apps, just transfer pixels... seriously!
GPUs are still rare in datacenters, and definitely not 1:1 with end users’ displays. When a backend needs a GUI, I don’t see much reason to choose anything other than local Javascript or Wasm to display it. It’s thoroughly cross platform and hardware accelerated.
