We’ve got more X11-related news this day, the day of Xmas.
Phoenix is a new X server, written from scratch in Zig (not a fork of Xorg server). This X server is designed to be a modern alternative to the Xorg server.
↫ Phoenix’ readme page
Phoenix will only support a modern subset of the X11 protocol, focusing on making sure modern applications from roughly the last 20 years or so work. It also takes quite a few pages out of the Wayland playbook by not having a server driver interface and by having a compositor included. On top of that, it will isolate applications from each other, and won’t have a single framebuffer for all displays, instead allowing different refresh rates for individual displays. The project also intends to develop new standards to support things like per-monitor DPI, among many other features.
That’s a lot of features and capabilities to promise for an X server, and much like Wayland, the way they aim to get there is by effectively gutting traditional X and leaving a ton of cruft behind. The use of Zig is also interesting, as it can catch some issues before they affect any users thanks to Zig’s runtime safety option. At least it’s not yet another thing written in Rust like every other project competing with an established project.
I think this look like an incredibly interesting project to keep an eye on, and I hope more people join the effort. Competition and fresh, new ideas are good, especially now that everything is gravitating towards Wayland – we need alternatives to promote the sharing of ideas.
“I think this look like an incredibly interesting project to keep an eye on,”
I don’t think so.
– it rewrites an old protocol (X11) instead of the future protocol (Wayland).
– instead of the uutils coreutils and other projects, the rewrite have not a lesser restricted license, for Phoenix it have a more restricted license: X11 have the X11-license and the rewrite Phoenix the GPLv3
– still very early stage: Look at the source code. Only some files. And all have only a few lines of code.
– Wayland isn’t a panacea to save humanity, it’s just a project like any other. Competition is good.
– Using GPL is a feature. Since when some of these so called rewrites, that are just corporate grabouts against projects that they don’t control, are a good thing for free software community?
– Everything begans from somewhere.
@CapEnt
Both Xorg and Wayland have done just fine under the MIT license for decades. As has Mesa and much of the rest of the graphics stack. I agree that GPL introduces a layer of incompatibility and hassle that makes this project less useful.
I don’t understand why it’s good it’s not written in rust? I don’t necessarily think everything has to be in rust, but why is it not being in rust a benefit?
“I don’t necessarily think everything has to be in rust,”
I think, that in Rust written is better then in Zig written. Not because the language is better or so, but because Rust is the new standard.
The old stadard are C and C++. The Linux kernel is wriiten in it. The Windows-kernel and most other parts of Windows are written in it. The xnu-Kernel of macOS and iOS is mostly wriiten in C and other programs in Objective C/C++. Swift comes only on the top of the operating system.
Now the Windows-kernel allowes modules in Rust. Same with Linux. On Linux tools like the coreutils are rewritten in Rust. Rust is now the new de-facto-standard for low level parts, which have to be secure.
And then there are people who prefer Zig, D, Go or any other language. Who should read the code of programs in 100 different languages?
I guess I’m wondering why Thom, a non-programmer, cares in the slightest? It just seemed like a really odd statement…. With no technical rationale behind it.
It would be like me lamenting about the metal-alloy used in the manufacture of vehicles.
I don’t think Thom is saying “it’s good that it’s not written in Rust”, rather that it’s nice to see a relatively new/unknown language like Zig getting a shot at writing memory-safe/runtime-safe software. There can be more than one awesome, modern, safe language, and competition is always good for open source.
“At least it’s not yet another thing written in Rust like every other project competing with an established project.”
zig hype is even more annoying than rust… at least rust spec is stable =,=
Zig is still young, for me it looks more like the pre-v1.0.0 releases of Rust, things are moving a lot.
Thank goodness. Just in time.
It’s just another X server, but less compatible with X software, in an era where the ecosystem is deprecating X. I’m sorry to the devs behind this, but this just isn’t going to be the resurgence of X.
Even if they cover *some* problem areas, like refresh rates, literally every app and compositor needs to support additional metadata for other major features like HDR. No toolkit is going to integrate bespoke Phoenix-isms to keep X as a protocol working. At best, some small projects not smart enough to dodge this bullet are only going to incur meaningless technical debt for a compositor nobody will seriously distribute.
What these people are blissfully ignoring is the fact that 99% of the work Wayland had to do was get everyone on-board. Gnome deliberately broke session restore on Wayland/GTK simply because it wasn’t “their vision”, even after KDE devs gave the patch – and Gnome is TARGETING Wayland. Gnome is in the process if KILLING X, do they seriously think they can get “modern X features” upstreamed?
I’m sorry, this is just 20 years too late. They’re less compatible than Xorg, not the blessed future, and they’ve just chosen the worst possible niche.
Did you miss the part where this is brand new? It’s not going to come out of the gate with all X features replicated, development takes time.
@Morgan
They are pretty explicit that it will never be 100% Xorg compatible. It is not just that they have left things unimplemented due to time or scope constraints. They are leaving parts of X11 behind so that they can implement more “modern” functionality. They cannot really fully implement X11 without losing the benefits that they are chasing in the new implementation.
@Kver
I agree that this is “too late” to become the standard. But it could be interesting to some. If it had come earlier, it may have garnered real interest.
Also, they say they may support Wayland apps natively. The ability to use your X11 WM of choice without giving up Wayland app compatibility could be very interesting indeed.
This may never be fully Xorg compatible as they are skipping a bunch of X11 cruft on purpose. But it is still going to work for many X11 use cases that are unlikely to ever be supported on Wayland.
This is not going to replace Wayland. But it could be a very interesting alternative to Wayback (and that other X11 server we are not allowed to mention here).
It will be interesting to see where this goes.
Some “experts” said that X11 couldn’t get modernized so it’s an interesting experiment.
X11 contains a lot of stuff that doesn’t make sense anymore, so to modernize it they will probably have to focus on a well-defined subset of features. We’ll see, but X11 is going out anyway, Wayland is not perfect but it’s there and adoption is well in progress.
@jgfenix
The “experts” were the Xorg developers and what they said is that you could not modernize Xorg without breaking it. This breaks it (on purpose).
If anything, this proves those “experts” right.
The Wayland path was chosen so that something new could be introduced without breaking what was already in place. I realize how ironic this is given how many people complain about how Wayland “broke” everything but the whole approach was the opposite. You can continue to use Xorg if you want and Xwayland is just the Xorg code as well. So fantastic backwards compatibility if you need it and a totally fresh start if you are willing. Contrast that to this effort which keeps you on the X11 protocol but breaks a tonne of stuff in order to make progress.
LeFantome,
I’d say that’s partially true but there were also very significant bureaucratic barriers within the project. There’s a lot of evidence for this, but we’re not allowed to post any links from the other side of the story on osnews since they get deleted.
What’s frustrating about the wayland breakages is that most of the features that wayland broke didn’t have to break except that wayland devs wanted to actively impose policy choices on others. An obvious example is breaking window positioning functionality used by CAD and other multi-window software. Such features remain broken in xwayland on purpose even though it would be absolutely trivial to fix.
The wayland rebuttal is that letting software set/get window positions is insecure, to which I say “fine, disable it by default but let owners configure that”. The crux of the problem has nothing to do with wayland locking down insecure features by default, but is one of respecting owner preferences. This is just like apple/mozilla/google calling sideloading insecure…clearly this has elements truth to it, but there exists a significant moral distinction between building a jail and giving owners the keys to it versus building a jail and forcing owners to live within the jail The former respects the owner’s autonomy whereas the latter disrespects it.
Beyond this, bad project management lead to wayland users experiencing a lot more feature fragmentation (ie features that only work for some users but not others). From my perspective X11 is ancient and a replacement is warranted, but I wish those working on replacements were more pragmatic and better at plotting clean transitions.
Looks fun – I hope it goes somewhere!
Wayland seems to favor big DE projects by making compositors implement everything. This might also reduce compatibility between them. (It might even be on purpose, to encourage consolidation.)
That isn’t insurmountable or anything, but a different approach is nice to see. (Also in regards to Zig.)
Maybe it’s wishful thinking hoping it’s all a relatively anti-corporate thing, but you never know.
The Wayback project seems like a much more feasible way forward.
@RumblePony
What do you prefer about the Wayback approach?
Wayback runs Xwayland (most of Xorg) on Wayland. This results in the greatest compatibility but also drags along many of the limitations. It is also destined to be X11 only long after Wayland-only applications are a real requirement.
The approach here leaves behind X11 features that nobody uses while addressing some of the real limitations that Xorg has. They are also talking about being able to run Wayland applications. And this seems to mesh very well with the current DRM infrastructure in the kernel.
And this could replace Xwayland for Wayland uses as well.
Other than the license, and maybe the name, Phoenix seems perfect.
It occurred to me a moment ago that Wayback and Phoenix are actually quite complimentary at the moment.
Wayback is a Wayland compositor that only runs a single Wayland application–Xwayland.
Phoenix is an X server that can only run nested on an X server or Wayland. At least, that is all it can do at the moment.
Phoenix could save itself the bother of having make all the KMS and DRM stuff work if it chose to simply run on Wayback instead. Pheonix may want to do this part itself eventually. But why not work together now?