3 ms·

Personally I like the modularity of X11 because it has a lot of standardized interfaces. For example, you can exchange the window manager and the compositing ma

by sprash 5y ago

Personally I like the modularity of X11 because it has a lot of standardized interfaces. For example, you can exchange the window manager and the compositing manager at runtime without affecting any running programs. In my opinion X12 should be even more modular and should have even more standardized interfaces. E.g. window decorations should not be tied to a window manager. There should be a standardized way to do toolkits/widgets where the backend and rendering can be swapped at runtime. It should be possible to run headless GUI programs that can be attached and reattached to any running instance of a display server. So kind of the opposite of what Wayland is doing.

DonHopkins 5y ago
"X: The First Fully Modular Software Disaster" https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47#fda6 https://donhopkins.medium.com/the-x-windows-disaster-128d398... John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls": https://news.ycombinator.com/item?id=17056516 https://news.ycombinator.com/item?id=17056516 DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori... Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet? There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly. https://news.ycombinator.com/item?id=6864364 https://news.ycombinator.com/item?id=6864364 "For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;) https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047 https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047... https://news.ycombinator.com/item?id=15325226 https://news.ycombinator.com/item?id=15325226 https://web.archive.org/web/20171028110659/https://minnie.tuhs.org/pipermail/tuhs/2017-September/010471.html https://web.archive.org/web/20171028110659/https://minnie.tu... >XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. >The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. >The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. >The bit encodings should be part of a separate language binding, not part of the functional description. [...] >X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." >Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. [...]
kaba0 5y ago
How is that the opposite? Anyone is free to extend the protocol with whatever they want — e.g. wlroots-based compositors have exactly this “standardized way of doing toolkits/widgets”.
- sprash 5y ago
  The only thing that Wayland standardizes is multi process GPU memory access. Neither GNOME nor KDE (which are far more popular Wayland implementations) use any of the wlroots "standards" and thus they can not really be called as such. Also wlroots does not define one bit about toolkits and widgets. > Anyone is free to extend the protocol with whatever they want The protocol itself is very opnionated and strict in some places (especially concerning things like vsync) and completely undefined in other areas where standardization is essential (access control).

by sprash 5y ago

DonHopkins 5y ago

"X: The First Fully Modular Software Disaster" https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47#fda6 https://donhopkins.medium.com/the-x-windows-disaster-128d398... John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls": https://news.ycombinator.com/item?id=17056516 https://news.ycombinator.com/item?id=17056516 DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori... Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet? There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly. https://news.ycombinator.com/item?id=6864364 https://news.ycombinator.com/item?id=6864364 "For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;) https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047 https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047... https://news.ycombinator.com/item?id=15325226 https://news.ycombinator.com/item?id=15325226 https://web.archive.org/web/20171028110659/https://minnie.tuhs.org/pipermail/tuhs/2017-September/010471.html https://web.archive.org/web/20171028110659/https://minnie.tu... >XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. >The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. >The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. >The bit encodings should be part of a separate language binding, not part of the functional description. [...] >X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." >Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. [...]

kaba0 5y ago

How is that the opposite? Anyone is free to extend the protocol with whatever they want — e.g. wlroots-based compositors have exactly this “standardized way of doing toolkits/widgets”.

sprash 5y ago
The only thing that Wayland standardizes is multi process GPU memory access. Neither GNOME nor KDE (which are far more popular Wayland implementations) use any of the wlroots "standards" and thus they can not really be called as such. Also wlroots does not define one bit about toolkits and widgets. > Anyone is free to extend the protocol with whatever they want The protocol itself is very opnionated and strict in some places (especially concerning things like vsync) and completely undefined in other areas where standardization is essential (access control).