ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
80% Positive
Analyzed from 716 words in the discussion.
Trending Topics
#server#bubble#ruby#overrated#might#few#compatibility#still#reconcile#coding
Discussion (15 Comments)Read Original on HackerNews
Why am I not surprised. GhostBSD seems to joyfully delve into the slop and attract the worst to FreeBSD.
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.
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 simple extra drawing calls gives you most X11 clients.
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
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.
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.
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.
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 be justified by the amount invested AI