I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
I thought this too and originally thought that’s what Wayland was going to do but it went off and did its own thing.
I’m all for an X12.
An X12 was briefly considered by the community before adopting Wayland: https://www.x.org/wiki/Development/X12/
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
Realistically rewrite would keep X11 compatibility layer and just do same wayland did, make new protocol.
Just... without all that mess that turned out to be at best +/-, at worst outright negative causing problems for everyone involved. And near all of the "advantages" are "the server is built from scratch" not "the protocol was the limitation"
Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
> [...]
> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.
Uhm no? As I mentioned, Wayland is simple because it was designed with the idea that there will be many implementations. It turns out that once you have many implementations, you can't just implement screen recording in one implementation and directly integrate with that implementation, because someone might use a different implementation. This then necessitates extensions for features that go beyond displaying things.
There’s a reason they’re called Pythonistas
It’s always drama and they’re the center of it.
(I’m joking of course, Merry Christmas)
Python is really one of the worst designed languages. It always baffles me that people recommend it to beginners.
15 years ago I tried it and got that path error. 1 year ago I tried again and still got the same error. I'm well aware that it's simple enough to fix. But I was baffled that the same error was still there.
I dunno there's a lot to pick from when it comes to "worst designed"!
It's definitely not well designed though.
And I agree about recommending it to beginners. Sure, a for-loop and a simple function look very friendly and easy, but good luck explaining to them why they can't import from a file in a different directory...
Except for all the others (that anyone uses)…
I’ve been here since the beginning.
I remember Usenet.
X11 was built for multi-user terminals a kin to today’s Microsoft VDI garbage.
There’s some good. A lot of bad. And some WTF in there.
Be the change you want to see.
Also happy winter solstice.
It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.
The fact that you can "assume Vulkan exists" helps a lot (both hardware and software renderers exist). Do remember--Wayland predates Vulkan by almost a full decade.
In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).
> pull in a group of long term maintainers.
"Use new cool language" seems to be a prerequisite for this nowadays ...
At least Zig is very compatible with C.
You can't "assume Vulkan exists". Any pre-2016 hardware won't have proper hardware support for Vulkan and that's a lot of hardware still in use. Software renderers are unworthy of any serious consideration due to the perfomance drawbacks.
Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.
Nvidia had a driver for Vulkan for Kepler which launched in 2012, AMD had support all the way back to GCN 1.0 (also 2012). Intel did have issues supporting it, I can't recall if it was for hardware reasons or just lack of desire for a driver.
Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.
There are Xorg and XLibre for pre-2016 hardware.