5 ms·

This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' Yeah, there's a lot to dislike about

by zeveb 10y ago

This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' Yeah, there's a lot to dislike about how X works. It's old, and it shows. But it has had man-centuries of work to get it where it is now; a de novo solution will necessarily need similar levels of work to get to a similar point. What could radically improve a next-generation X replacement would be to use a higher-level language than C, which would remove entire categories of errors as possibilities. I'm thinking either OCaml or Common Lisp could potentially be excellent choices, for very different reasons. But replacing one large, old, battle-tested C project with a large, new, untested C project isn't going to usher in a happy world of simplicity and security.

sqeaky 10y ago
> a de novo solution will necessarily need similar levels of work to get to a similar point That work does not need to be directly in the second system. If the hard lessoned were learned in X by making mistakes much effort can be prevented by not making those mistakes and use something closer to the finished design of the first system... which is exactly what Wayland is.
Frondo 10y ago
Of course Wayland will have bugs. What it won't have (hopefully) is the same design decisions and flaws that X made, because people have learned from X in the intervening decades since its inception.
- khedoros 10y ago
  It'll just have different design decisions and flaws. Expecting anything else is unrealistic. Bit-rot means that X isn't as well-suited to today's environment as we'd like, but I'm sure that some things in X that are regarded as mistakes now were trumpeted as great advancements when they were introduced. Similarly, Wayland will someday be in the same position. That doesn't mean that it's not a net-positive to develop and start using it, of course.
  - catdog 10y ago
    > Bit-rot means that X isn't as well-suited to today's environment as we'd like, but I'm sure that some things in X that are regarded as mistakes now were trumpeted as great advancements when they were introduced. Maybe they were great at the time. If you don't have enough memory to store every pixel of your screen, only storing properties of some basic geometric shapes seems to be a nice solution. If you have plenty of memory and want to control every pixel this becomes rather useless and even a burden.
jpfed 10y ago
> But it has had man-centuries of work to get it where it is now; a de novo solution will necessarily need similar levels of work to get to a similar point. This reasoning falls down in two ways: sometimes changes need to be reverted (and there's no reason to repeat those mistakes) and sometimes changes make further changes harder (and these changes can be done smarter in the new project).
witty_username 10y ago
In X, any client can keylog all other clients. Also, without compositing you need to re-render the window when it moves into the screen. X is really just a middle-man that doesn't do much (that's why DRI is used). > a de novo solution will necessarily need similar levels of work to get to a similar point. No, X contains lots of cruft and hacks.
- pdkl95 10y ago
  > In X, any client can keylog all other clients. Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. > without compositing you need to re-render the window when it moves into the screen Some of that is prevented by setting the save-unders flag. More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). However, isn't the whole point of Wayland is that it's a compositing-only server? It's simply forcing the choice to enable compositing. Enabling the Composite extension in xorg fixed the redraw problem years ago. This isn't a Wayland-only feature. > X is really just a middle-man that doesn't do much That's only true for a small set of X clients. > No, X contains lots of cruft and hacks. A lot of that "cruft" is backwards compatibility that doesn't interfere with modern applications and is needed to run older software. Choosing to break 20+ years of software by removing these features is not an acceptable solution. More importantly, a lot of the problems with X are actually problems with the specific implementation of X known as "X.org". A lot of confusion happens when people confuse X (a protocol and specification for display servers and client interface) with an implementation of X ("XFree86", "X.org", others).
  - witty_username 10y ago
    > Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. No it doesn't. There is no need for any client without any permissions or privileges to be able to snoop on other processes. Why not let users decide which clients can snoop? > That's only true for a small set of X clients. What does X do? > More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). No, that is how X works. I found out this when experimenting with creating my own toolkit. The Composite extension fixes this. > Choosing to break 20+ years of software by removing these features is not an acceptable solution. It is acceptable. Most people don't use 20 year old software. XWayland can be used to keep backwards compatibility.
notalaser 10y ago
> This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' This is exactly what I'm afraid of. Don't get me wrong, I go outside for a smoke every morning when I find out I have to as much as look at X code that day (fortunately, it doesn't happen too often), but you know what, X11 works. It has, furthermore, worked reliably for many, many years, on more architectures than I can name, running more applications than anyone can remember, and has reliably solved problems that no one even conceived of thirty years ago when X11 was written. For something that "barely holds together", it works admirably well for the end user, and the nowadays-hated extensibility and policy-but-not-mechanism have allowed it to remain a very useful solution. Wayland, in contrast, is universally applauded, but largely runs Gnome and a bunch of infotainment systems for automotive applications. X11 has also not always been so reliable, and frankly, I doubt Wayland will take much less time to become reliable. It took about 10 years for X11 to stop being a pain in the ass. I'm looking forward to using Wayland every day. In 2025 or so. Also, at the risk of looking like someone who wears his tinfoil hat to bed, it's worth considering that the two major improvements are largely relevant only for multimedia-super-heavy stuff and staying relatively safe from a legal standpoint while running 3rd party, untrusted (cough usually closed source cough) applications on a system that you manufacture and sell (oh, and a lot of people who want to move every application in the browser, but that could be solved by just sandboxing the browser). Before jumping into the PR boat and proclaiming the end of The Dreadful X11 Insecurity, it may be worth following the money trail.
- ZenoArrow 10y ago
  > "Wayland, in contrast, is universally applauded, but largely runs Gnome and a bunch of infotainment systems for automotive applications." Wayland is still being rolled out, it hasn't even managed to be the default compositor on any major Linux distros yet (though I heard that Fedora may choose to default to Wayland for its next release). Furthermore, KDE devs are clearly working on Wayland support, so it's not limited to one DE. > "Also, at the risk of looking like someone who wears his tinfoil hat to bed, it's worth considering that the two major improvements are largely relevant only for multimedia-super-heavy stuff and staying relatively safe from a legal standpoint while running 3rd party, untrusted (cough usually closed source cough) applications on a system that you manufacture and sell" What are you talking about? There's no closed source bias with Wayland.
ZenoArrow 10y ago
A few points: 1. Compared to X, the codebase for Wayland is small. This isn't just because Wayland hasn't had enough time to accumulate cruft, it's also because of the design of Wayland. Wayland makes use of a lot of the underlying kernel infrastructure and streamlines the functions it provides. To give you an idea of how the infrastructure of Wayland differs from X: https://wayland.freedesktop.org/architecture.html https://wayland.freedesktop.org/architecture.html 2. Wayland may not be as old as X, but it's not a new project either. Development of Wayland started in 2008, and has been a freedesktop.org project since 2010. 3. Nobody claims Wayland will be perfect, it just has to be better than X to be a worthy successor. Second-system thinking works out fine when the problem space is well understood, and the issues of X appear to be understood just fine.
- Johan-bjareholt 10y ago
  Totally agree. Also regarding the parent comment, wayland has been tested in production for many years now in lots of embeded systems. If you have a car with a Infotainment system from 2013 or newer running linux it most likely uses wayland. It currently works on the open source intel, amd and nvidia and multiple arm drivers, so the major drivers missing are just the proprietary nvidia and AMD drivers (both of which are being actively worked on).
beagle3 10y ago
> But it has had man-centuries of work to get it where it is now; a de novo solution will necessarily need similar levels of work to get to a similar point. That's not true. There is a lot that went into X that is no longer in use, and doesn't need to be faithfully recreated; e.g. basically almost all rendering (font and otherwise) has moved from server to client. At least in the past (Latest sources I studied were of X10 ... showing my age), that was a significant part of X, with a lot of work going into it - and it does not need to be redone.
- khedoros 10y ago
  The way I see it, Wayland will implement interfaces that make sense the way things are now. Compared to X, development will be quicker (because deprecated interfaces won't be implemented), and the code will be cleaner and more secure. We'll have a generally-working system, with a couple little warts, here and there. The way I read the previous post, with its mention of "second-system thinking", is that X is currently just about good enough for just about everything, and that while 90% of the necessary features will fit cleanly into Wayland, it's the last 10% that will introduce 90% of the ugly complexity, and take man-centuries to realize the need for, and then produce.
catdog 10y ago
> This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' It's not only about things done wrong but also about X11 not fitting very well into todays hardware environment. Today a lot of the X11 protocol (w/o extensions) is either things done really bad or things simply unused most of the time because today nobody uses bitmap fonts and everybody renders into pixel buffers anyway but it has to be implemented because the protocol demands it. The implementation being old and barely maintainable combined with protocol being horribly outdated seems to be a good reason to start from scratch. Wayland as far a I know is also a much simpler concept. > What could radically improve a next-generation X replacement would be to use a higher-level language than C, which would remove entire categories of errors as possibilities. I'm thinking either OCaml or Common Lisp could potentially be excellent choices, for very different reasons. Sure C is bad but I don't think languages focusing heavily on a functional programming style are a good choice for this type of software. You probably also need this low level access C provides at some points. I would tend to Rust here as it was designed to also fulfill such needs. > But replacing one large, old, battle-tested C project with a large, new, untested C project isn't going to usher in a happy world of simplicity and security. I don't have any numbers but the security track record of this "old, battle tested code" seems not to be the best.
- pdkl95 10y ago
  > simply unused most of the time That's an assumption that is only true if you are careful to only use Gnome/KDE style, recently made applications. Backwards compatability is a good thing, and most of those features are necessary for running older software, and they don't interfere with modern software. > nobody uses bitmap fonts I use bitmap fonts for almost everything that isn't firefox and ps/pdf rendering. $ xlsfonts -1 | wc -l 16264 Bitmap fonts render significantly faster, and a well made bitmap font[1] that was actually designed around pixels avoids anti-aliasing which saves CPU and occasional rendering issues[4]. > everybody renders into pixel buffers anyway GTK+ and Qt render into pixmaps. Other toolkits vary. > because the protocol demands it ...because backwards compatibility demands it. Maybe you only run recent software, but that isn't always an option. > protocol being horribly outdated Fortunately X11 has an extension mechanism which allowed new protocols to be added at runtime, removing the need to use older protocols. This is needed if compatibility is to be maintained. Unfortunately, the fd.o culture seems to think it's fine to remove working code without regard to the people that do use it. > Wayland as far a I know is also a much simpler concept. It's simpler because it's feature incomplete. These features still need to exist, and all Wayland is doing is pushing those problems to other areas where they are someone else's problem. In some cases (like use cases outside their experience), Wayland developers like to pretend these problems don't exist. > I would tend to Rust here I completely agree that Rust is probably a good choice, as it was designed specifically to avoid many common types of bugs. C is good, but Rust may be the first language that can actually replace it. [1] Such as Terminus[2], Dina[3] [2] http://terminus-font.sourceforge.net/ http://terminus-font.sourceforge.net/ [3] https://www.donationcoder.com/Software/Jibz/Dina/ https://www.donationcoder.com/Software/Jibz/Dina/ [4] http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...

by zeveb 10y ago

sqeaky 10y ago

> a de novo solution will necessarily need similar levels of work to get to a similar point That work does not need to be directly in the second system. If the hard lessoned were learned in X by making mistakes much effort can be prevented by not making those mistakes and use something closer to the finished design of the first system... which is exactly what Wayland is.

Frondo 10y ago

Of course Wayland will have bugs. What it won't have (hopefully) is the same design decisions and flaws that X made, because people have learned from X in the intervening decades since its inception.

khedoros 10y ago
It'll just have different design decisions and flaws. Expecting anything else is unrealistic. Bit-rot means that X isn't as well-suited to today's environment as we'd like, but I'm sure that some things in X that are regarded as mistakes now were trumpeted as great advancements when they were introduced. Similarly, Wayland will someday be in the same position. That doesn't mean that it's not a net-positive to develop and start using it, of course.
- catdog 10y ago
  > Bit-rot means that X isn't as well-suited to today's environment as we'd like, but I'm sure that some things in X that are regarded as mistakes now were trumpeted as great advancements when they were introduced. Maybe they were great at the time. If you don't have enough memory to store every pixel of your screen, only storing properties of some basic geometric shapes seems to be a nice solution. If you have plenty of memory and want to control every pixel this becomes rather useless and even a burden.

jpfed 10y ago

> But it has had man-centuries of work to get it where it is now; a de novo solution will necessarily need similar levels of work to get to a similar point. This reasoning falls down in two ways: sometimes changes need to be reverted (and there's no reason to repeat those mistakes) and sometimes changes make further changes harder (and these changes can be done smarter in the new project).

witty_username 10y ago

In X, any client can keylog all other clients. Also, without compositing you need to re-render the window when it moves into the screen. X is really just a middle-man that doesn't do much (that's why DRI is used). > a de novo solution will necessarily need similar levels of work to get to a similar point. No, X contains lots of cruft and hacks.

pdkl95 10y ago
> In X, any client can keylog all other clients. Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. > without compositing you need to re-render the window when it moves into the screen Some of that is prevented by setting the save-unders flag. More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). However, isn't the whole point of Wayland is that it's a compositing-only server? It's simply forcing the choice to enable compositing. Enabling the Composite extension in xorg fixed the redraw problem years ago. This isn't a Wayland-only feature. > X is really just a middle-man that doesn't do much That's only true for a small set of X clients. > No, X contains lots of cruft and hacks. A lot of that "cruft" is backwards compatibility that doesn't interfere with modern applications and is needed to run older software. Choosing to break 20+ years of software by removing these features is not an acceptable solution. More importantly, a lot of the problems with X are actually problems with the specific implementation of X known as "X.org". A lot of confusion happens when people confuse X (a protocol and specification for display servers and client interface) with an implementation of X ("XFree86", "X.org", others).
- witty_username 10y ago
  > Yes, that's a feature that some of us use. Any replacement needs to support that ability, or it isn't a functional replacement. No it doesn't. There is no need for any client without any permissions or privileges to be able to snoop on other processes. Why not let users decide which clients can snoop? > That's only true for a small set of X clients. What does X do? > More can be prevented if toolkits bothered to draw using X instead of re-sending client-rendered pixmaps on every update (a lot of the people complaining about X are not actually using X for most of their work). No, that is how X works. I found out this when experimenting with creating my own toolkit. The Composite extension fixes this. > Choosing to break 20+ years of software by removing these features is not an acceptable solution. It is acceptable. Most people don't use 20 year old software. XWayland can be used to keep backwards compatibility.

notalaser 10y ago

> This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' This is exactly what I'm afraid of. Don't get me wrong, I go outside for a smoke every morning when I find out I have to as much as look at X code that day (fortunately, it doesn't happen too often), but you know what, X11 works. It has, furthermore, worked reliably for many, many years, on more architectures than I can name, running more applications than anyone can remember, and has reliably solved problems that no one even conceived of thirty years ago when X11 was written. For something that "barely holds together", it works admirably well for the end user, and the nowadays-hated extensibility and policy-but-not-mechanism have allowed it to remain a very useful solution. Wayland, in contrast, is universally applauded, but largely runs Gnome and a bunch of infotainment systems for automotive applications. X11 has also not always been so reliable, and frankly, I doubt Wayland will take much less time to become reliable. It took about 10 years for X11 to stop being a pain in the ass. I'm looking forward to using Wayland every day. In 2025 or so. Also, at the risk of looking like someone who wears his tinfoil hat to bed, it's worth considering that the two major improvements are largely relevant only for multimedia-super-heavy stuff and staying relatively safe from a legal standpoint while running 3rd party, untrusted (cough usually closed source cough) applications on a system that you manufacture and sell (oh, and a lot of people who want to move every application in the browser, but that could be solved by just sandboxing the browser). Before jumping into the PR boat and proclaiming the end of The Dreadful X11 Insecurity, it may be worth following the money trail.

ZenoArrow 10y ago
> "Wayland, in contrast, is universally applauded, but largely runs Gnome and a bunch of infotainment systems for automotive applications." Wayland is still being rolled out, it hasn't even managed to be the default compositor on any major Linux distros yet (though I heard that Fedora may choose to default to Wayland for its next release). Furthermore, KDE devs are clearly working on Wayland support, so it's not limited to one DE. > "Also, at the risk of looking like someone who wears his tinfoil hat to bed, it's worth considering that the two major improvements are largely relevant only for multimedia-super-heavy stuff and staying relatively safe from a legal standpoint while running 3rd party, untrusted (cough usually closed source cough) applications on a system that you manufacture and sell" What are you talking about? There's no closed source bias with Wayland.

ZenoArrow 10y ago

A few points: 1. Compared to X, the codebase for Wayland is small. This isn't just because Wayland hasn't had enough time to accumulate cruft, it's also because of the design of Wayland. Wayland makes use of a lot of the underlying kernel infrastructure and streamlines the functions it provides. To give you an idea of how the infrastructure of Wayland differs from X: https://wayland.freedesktop.org/architecture.html https://wayland.freedesktop.org/architecture.html 2. Wayland may not be as old as X, but it's not a new project either. Development of Wayland started in 2008, and has been a freedesktop.org project since 2010. 3. Nobody claims Wayland will be perfect, it just has to be better than X to be a worthy successor. Second-system thinking works out fine when the problem space is well understood, and the issues of X appear to be understood just fine.

Johan-bjareholt 10y ago
Totally agree. Also regarding the parent comment, wayland has been tested in production for many years now in lots of embeded systems. If you have a car with a Infotainment system from 2013 or newer running linux it most likely uses wayland. It currently works on the open source intel, amd and nvidia and multiple arm drivers, so the major drivers missing are just the proprietary nvidia and AMD drivers (both of which are being actively worked on).

beagle3 10y ago

> But it has had man-centuries of work to get it where it is now; a de novo solution will necessarily need similar levels of work to get to a similar point. That's not true. There is a lot that went into X that is no longer in use, and doesn't need to be faithfully recreated; e.g. basically almost all rendering (font and otherwise) has moved from server to client. At least in the past (Latest sources I studied were of X10 ... showing my age), that was a significant part of X, with a lot of work going into it - and it does not need to be redone.

khedoros 10y ago
The way I see it, Wayland will implement interfaces that make sense the way things are now. Compared to X, development will be quicker (because deprecated interfaces won't be implemented), and the code will be cleaner and more secure. We'll have a generally-working system, with a couple little warts, here and there. The way I read the previous post, with its mention of "second-system thinking", is that X is currently just about good enough for just about everything, and that while 90% of the necessary features will fit cleanly into Wayland, it's the last 10% that will introduce 90% of the ugly complexity, and take man-centuries to realize the need for, and then produce.

catdog 10y ago

> This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' It's not only about things done wrong but also about X11 not fitting very well into todays hardware environment. Today a lot of the X11 protocol (w/o extensions) is either things done really bad or things simply unused most of the time because today nobody uses bitmap fonts and everybody renders into pixel buffers anyway but it has to be implemented because the protocol demands it. The implementation being old and barely maintainable combined with protocol being horribly outdated seems to be a good reason to start from scratch. Wayland as far a I know is also a much simpler concept. > What could radically improve a next-generation X replacement would be to use a higher-level language than C, which would remove entire categories of errors as possibilities. I'm thinking either OCaml or Common Lisp could potentially be excellent choices, for very different reasons. Sure C is bad but I don't think languages focusing heavily on a functional programming style are a good choice for this type of software. You probably also need this low level access C provides at some points. I would tend to Rust here as it was designed to also fulfill such needs. > But replacing one large, old, battle-tested C project with a large, new, untested C project isn't going to usher in a happy world of simplicity and security. I don't have any numbers but the security track record of this "old, battle tested code" seems not to be the best.

pdkl95 10y ago
> simply unused most of the time That's an assumption that is only true if you are careful to only use Gnome/KDE style, recently made applications. Backwards compatability is a good thing, and most of those features are necessary for running older software, and they don't interfere with modern software. > nobody uses bitmap fonts I use bitmap fonts for almost everything that isn't firefox and ps/pdf rendering. $ xlsfonts -1 | wc -l 16264 Bitmap fonts render significantly faster, and a well made bitmap font[1] that was actually designed around pixels avoids anti-aliasing which saves CPU and occasional rendering issues[4]. > everybody renders into pixel buffers anyway GTK+ and Qt render into pixmaps. Other toolkits vary. > because the protocol demands it ...because backwards compatibility demands it. Maybe you only run recent software, but that isn't always an option. > protocol being horribly outdated Fortunately X11 has an extension mechanism which allowed new protocols to be added at runtime, removing the need to use older protocols. This is needed if compatibility is to be maintained. Unfortunately, the fd.o culture seems to think it's fine to remove working code without regard to the people that do use it. > Wayland as far a I know is also a much simpler concept. It's simpler because it's feature incomplete. These features still need to exist, and all Wayland is doing is pushing those problems to other areas where they are someone else's problem. In some cases (like use cases outside their experience), Wayland developers like to pretend these problems don't exist. > I would tend to Rust here I completely agree that Rust is probably a good choice, as it was designed specifically to avoid many common types of bugs. C is good, but Rust may be the first language that can actually replace it. [1] Such as Terminus[2], Dina[3] [2] http://terminus-font.sourceforge.net/ http://terminus-font.sourceforge.net/ [3] https://www.donationcoder.com/Software/Jibz/Dina/ https://www.donationcoder.com/Software/Jibz/Dina/ [4] http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...