Writing a new X server from scratch would have been an enormous undertaking two decades ago. (Keith Packard did Kdrive but he’s literally the foremost expert on X11.) Part of what motivated Wayland was the difficulty of maintaining the X server.
How can we reconcile AI coding a functional X server with the assertions that AI is overrated and we’re in a bubble?
As far as I understand it, the main problem with keeping Xorg going isn't anything inherent with the code itself (although that's definitely a factor), it's the sheer amount of functionality Xorg clients can access, including viewing and manipulating global state and other clients. When you combine this with X11's ability to remotely view clients from other devices, and the fact that most of the main Xorg maintainers are paid employees of various commercial Unix and Linux vendors, it makes change extremely difficult. You can't try to do things to modernize Xorg, like making the server multithreaded, changing how the graphics work to better fit modern display hardware, or adding a permissions mechanism, if you then have to deal with a bunch of urgent support tickets from large customers complaining that your changes have broken some 30 year old software they rely on that they have running in a VM somewhere.
It's an undertaking, but there were multiple X servers for small platforms back in the day - the difficulty is overstated. It takes a few thousand lines of code to get a basic one together.
Maintaining Xorg might be unreasonably hard.
But I agree with you LLMs are amazing at this - I had Claude throw a half baked one together in less than 24h.
In the past 20 years there have been enormous gains in tooling and culture, besides the rise of LLM-assisted coding, which make this task easier now. The task was already easier five years ago than twenty. Don't get me wrong, LLMs can speed this process up, and help experts and diligent newbies alike produce software faster, but you are discounting the gains in other parts of our work.
Since 2006, knowledge has become more available on the Internet. There is StackOverflow (for) now, and any number of developer blogs, in addition to the voluminous books published on programming. Hardware setups became more homogenous and the kernel took over handling more of graphics. Compilers, static analyzers, debuggers and testing tooling are all leagues better now. More code is published online, which can be used as learning material. Developers as a class of people have grown in numbers and experience. More mistakes in various open source software projects have been made, and recorded publicly for others to learn from.
AI can code. I've been programming since 1996 but I don't write code anymore, I iterate with an agent. But you only get good output with a human directing it. It's overrated because it requires human direction to succeed and is not on its way to "AGI" as promised, and we're in a bubble because coding agents aren't enough to meet the revenue needed for these companies to justify their valuations or meet their obligations.
We are in a bubble and it's not overrated. Many people just have issues using it correctly it seems. Weird as after 30 years managing 1000s of programmers over that time, this feels the same, yet with many times more and often better output.
Hobby OSs are dime a dozen but rarely go further for the simple reason that there is little motivation - you need programs to run, which typically means ABI compatibility, and you end up in a quagmire of writing drivers, with few benefits to show for it that you can't get by building something on top of an existing kernel instead.
Waylanders propaganda to scare people to move away x11
And rewriting POCs of existing projects will not necessarily increase productivity
Maybe development generally was getting unnecessarily complex, and people were cutting corners. And now with AI they will be able to do it better. Which possibly wouldn't directly justify the amount invested AI
I don't understand the desire for an X11 rewrite. X.org is absolutely terrible, I understand starting from scratch, but wouldn't it make far more sense to make a backwards compatible X12?
It took Claude less than a day to get it to the point where Firefox runs and plays YouTube videos at decent speed - modern x apps does mostly client side rendering so the X11 server is rarely on the hot path.
And then I started backfilling a lot of things I initially didn't want, because it turns out it takes very little code and it's fun to get xterm, twm, xeyes working and not just modern clients.
There are bits I'll never add, or will do differently (e.g. TrueType server- side fonts instead of bitmaps because it's near trivial)
But done right the complexity even of the legacy drawing modes is pretty limited.
I've been a proponent of an 'x12' approach, but I'm less sure it makes sense now beyond very targeted deprecation, because I no longer believe it needs to add much complexity.
I'm not sure how far I'll take my x11 server - it was pretty much done on a whim -, but at the moment it's rendering to an x11 window and I want to at least make it render to a gbm/dri backend for the sake of it - it won't be all that hard.
What I've learnt is that the difficulty of writing an x11 server is vastly overstated - you can do a basic one in a few thousand lines of code in any high level language.
Can I ask why you did it in ruby? I like ruby, don't get me wrong, but that seems pretty low on the list of languages an X12 would be written in.
I think an X12 would be X11 with a cleaned up codebase, removed features, and additions of modern features that Wayland or Quartz have without compromising compatibility more than necessary
Because I like Ruby and it's compact, and most of my stack, including my terminal, wm, font renderer and X11 bindings are already in Ruby (the latter two are reused directly).
Also because I was curious if it'd be viable, and turns out its fast enough (for a low level backend I might end up pulling in Mesa and some optimized blitting code, but otherwise pure Ruby is all you need)
To me an X12 implies significant protocol changes, or it's just another X11 implementation - X11 is the protocol, not a specific implementation.
And it turns out significant protocol changes might just not be particularly worthwhile given you can run most X11 clients with a few thousand lines (including XRender, Xinerama, and other key extensions)
Instead you certainly can make savings by ditching old hardware, and not bothering to make legacy drawing modes fast. I'm not going to commit to full compatibility, so maybe the x12 label might still make sense, but gtk + qt compatibility + about a dozen simple extra drawing calls gives you most X11 clients.
Next they should implement the wayland api ^_^
Writing a new X server from scratch would have been an enormous undertaking two decades ago. (Keith Packard did Kdrive but he’s literally the foremost expert on X11.) Part of what motivated Wayland was the difficulty of maintaining the X server.
How can we reconcile AI coding a functional X server with the assertions that AI is overrated and we’re in a bubble?
> How can we reconcile AI coding a functional X server with the assertions that AI is overrated and we’re in a bubble?
The dot com boom in 1999 was a bubble, but the internet was still useful and important and obviously survived.
The bubble is due to the skyrocketing valuations and questionable financial future of the companies involved, not because AI isn’t useful.
As far as I understand it, the main problem with keeping Xorg going isn't anything inherent with the code itself (although that's definitely a factor), it's the sheer amount of functionality Xorg clients can access, including viewing and manipulating global state and other clients. When you combine this with X11's ability to remotely view clients from other devices, and the fact that most of the main Xorg maintainers are paid employees of various commercial Unix and Linux vendors, it makes change extremely difficult. You can't try to do things to modernize Xorg, like making the server multithreaded, changing how the graphics work to better fit modern display hardware, or adding a permissions mechanism, if you then have to deal with a bunch of urgent support tickets from large customers complaining that your changes have broken some 30 year old software they rely on that they have running in a VM somewhere.
It's an undertaking, but there were multiple X servers for small platforms back in the day - the difficulty is overstated. It takes a few thousand lines of code to get a basic one together.
Maintaining Xorg might be unreasonably hard.
But I agree with you LLMs are amazing at this - I had Claude throw a half baked one together in less than 24h.
In the past 20 years there have been enormous gains in tooling and culture, besides the rise of LLM-assisted coding, which make this task easier now. The task was already easier five years ago than twenty. Don't get me wrong, LLMs can speed this process up, and help experts and diligent newbies alike produce software faster, but you are discounting the gains in other parts of our work.
Since 2006, knowledge has become more available on the Internet. There is StackOverflow (for) now, and any number of developer blogs, in addition to the voluminous books published on programming. Hardware setups became more homogenous and the kernel took over handling more of graphics. Compilers, static analyzers, debuggers and testing tooling are all leagues better now. More code is published online, which can be used as learning material. Developers as a class of people have grown in numbers and experience. More mistakes in various open source software projects have been made, and recorded publicly for others to learn from.
AI can code. I've been programming since 1996 but I don't write code anymore, I iterate with an agent. But you only get good output with a human directing it. It's overrated because it requires human direction to succeed and is not on its way to "AGI" as promised, and we're in a bubble because coding agents aren't enough to meet the revenue needed for these companies to justify their valuations or meet their obligations.
>How can we reconcile AI coding a functional X server with the assertions that AI is overrated and we’re in a bubble?
By refusing to use it because the BSD's are my escape from vibe coded hell
We are in a bubble and it's not overrated. Many people just have issues using it correctly it seems. Weird as after 30 years managing 1000s of programmers over that time, this feels the same, yet with many times more and often better output.
It is an much simpler task now since you can depend on kernel / mesa drivers for all hardware.
>How can we reconcile AI coding a functional X server with the assertions that AI is overrated and we’re in a bubble?
Simple: AI is not overrated at all. Might still be a bubble though, that's an entirely different consideration.
Something is still holding us back though. One would think that we'd have a dozen total rewrites of Linux at this point.
Hobby OSs are dime a dozen but rarely go further for the simple reason that there is little motivation - you need programs to run, which typically means ABI compatibility, and you end up in a quagmire of writing drivers, with few benefits to show for it that you can't get by building something on top of an existing kernel instead.
Waylanders propaganda to scare people to move away x11
And rewriting POCs of existing projects will not necessarily increase productivity
Maybe development generally was getting unnecessarily complex, and people were cutting corners. And now with AI they will be able to do it better. Which possibly wouldn't directly justify the amount invested AI
I don't understand the desire for an X11 rewrite. X.org is absolutely terrible, I understand starting from scratch, but wouldn't it make far more sense to make a backwards compatible X12?
I actually started an "x12" in Ruby (yes...)
It took Claude less than a day to get it to the point where Firefox runs and plays YouTube videos at decent speed - modern x apps does mostly client side rendering so the X11 server is rarely on the hot path.
And then I started backfilling a lot of things I initially didn't want, because it turns out it takes very little code and it's fun to get xterm, twm, xeyes working and not just modern clients.
There are bits I'll never add, or will do differently (e.g. TrueType server- side fonts instead of bitmaps because it's near trivial)
But done right the complexity even of the legacy drawing modes is pretty limited.
I've been a proponent of an 'x12' approach, but I'm less sure it makes sense now beyond very targeted deprecation, because I no longer believe it needs to add much complexity.
I'm not sure how far I'll take my x11 server - it was pretty much done on a whim -, but at the moment it's rendering to an x11 window and I want to at least make it render to a gbm/dri backend for the sake of it - it won't be all that hard.
What I've learnt is that the difficulty of writing an x11 server is vastly overstated - you can do a basic one in a few thousand lines of code in any high level language.
Can I ask why you did it in ruby? I like ruby, don't get me wrong, but that seems pretty low on the list of languages an X12 would be written in.
I think an X12 would be X11 with a cleaned up codebase, removed features, and additions of modern features that Wayland or Quartz have without compromising compatibility more than necessary
Because I like Ruby and it's compact, and most of my stack, including my terminal, wm, font renderer and X11 bindings are already in Ruby (the latter two are reused directly).
Also because I was curious if it'd be viable, and turns out its fast enough (for a low level backend I might end up pulling in Mesa and some optimized blitting code, but otherwise pure Ruby is all you need)
To me an X12 implies significant protocol changes, or it's just another X11 implementation - X11 is the protocol, not a specific implementation.
And it turns out significant protocol changes might just not be particularly worthwhile given you can run most X11 clients with a few thousand lines (including XRender, Xinerama, and other key extensions)
Instead you certainly can make savings by ditching old hardware, and not bothering to make legacy drawing modes fast. I'm not going to commit to full compatibility, so maybe the x12 label might still make sense, but gtk + qt compatibility + about a dozen simple extra drawing calls gives you most X11 clients.
>FreeBSD support — tested on GhostBSD
Why am I not surprised. GhostBSD seems to joyfully delve into the slop and attract the worst to FreeBSD.
eww