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 done 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.
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.
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.
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.
Every major technology advancement is followed by an economic bubble. Bubbles are economic, they are triggered by a landgrab following a technologic discontinuity.
Also, there are thousands of X11 servers in the training set, you could one-shot them at this point. Setup an RL loop and you can have it even work.
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 yours because videos at decent speed). And then I started backfilling a lot of things I initially didn't want, because it turns out it takes very little code.
There are bits I'll never add, or will do differently (e.g. TrueType server- side fonts instead of bitmaps)
But done right the complexity even if the legacy drawing modes is pretty limited.
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 now 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, 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 extra drawing calls gives you most X11 clients.
21 comments
[ 2.6 ms ] story [ 26.5 ms ] threadSimple: 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.
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.
Also rewriting POCs of existing projects will not necessarily increase productivity
By refusing to use it because the BSD's are my escape from vibe coded hell
Also, there are thousands of X11 servers in the training set, you could one-shot them at this point. Setup an RL loop and you can have it even work.
There are bits I'll never add, or will do differently (e.g. TrueType server- side fonts instead of bitmaps)
But done right the complexity even if the legacy drawing modes is pretty limited.
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 now vastly overstated - you can do a basic one in a few thousand lines of code in any high level language.
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
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, 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 extra drawing calls gives you most X11 clients.
Why am I not surprised. GhostBSD seems to joyfully delve into the slop and attract the worst to FreeBSD.