5 ms·

At least others agreed to eventually settle on Wayland, while Canonical is really reinventing the wheel with Mir.

bitwize 10y ago
I get the feeling that as soon as Wayland gets significant uptake and starts being less than broken for most users, it will instantly be replaced with something even more bizarre and inexplicable. The OSS community seems to view constant change -- and churn -- as an inherent good.
- scrollaway 10y ago
  Right, because two protocols in 32 years is "constant change".
  - kefka 10y ago
    Nahh, that's not why. They got rid of the idea of the X protocol and network transparency. I like being able to log in to remove Linux machines, and run programs that show up locally on my desktop. And since it's not some framebuffer, I know the X commands are being send and then rendering on my side. That's loads better than some dumb pixel maps. And X is extensible. Plugins aren't easy to write, but you can do it. We have Screen for X (Xpra), mpX (multiple pointer/keyboard), OpenGL, and loads more. Yeah, some could be considered cruft, or multiple ways to do the same thing, but that's the Unix Way.
    - tornadoboy55 10y ago
      X is inherently insecure. That's enough of a reason to have everything in Wayland ASAP.
      - bitwize 10y ago
        There's nothing inherently insecure about the X protocol. Sandboxing X would involve simply not providing information about drawables not created by the client. That means filtering out input events destined for those drawables and returning blank pixmaps when their contents are asked for. That the X server doesn't do this, and provide knobs to control who is trusted and who isn't, is a shame. But again, we don't have to burn the entire graphics stack because security.
    - scrollaway 10y ago
      None of that is relevant to parent's comment about "churn". I guess they're assuming the X11 ecosystem is literally the same as the Javascript one, or something. I'm honestly astonished at how quickly people jump on to wayland to complain about it, about how things are changing, about how it's not perfect etc. Wayland is an ongoing answer to a plethora of long term problems that Linux is facing. Display-level app sandboxing, screenlock security, high DPI (scaling) support, etc. Dropping support for 30 years of legacy that is no longer relevant is just a bonus. In the real world, things like multi pointer never worked (neither GTK nor Qt really supports it). High DPI monitors on the other hand are getting more and more common. So yeah, priorities. And the wayland devs aren't some cabal out to prevent people from implementing those things you mention; or creating a solid plugin interface. They're just lacking in manpower because 1. it's hard and 2. few are seriously paying for that development to happen. So when a company like Canonical decides to do their own version of wayland, not only are they actively removing potential users from the display server, and duplicating the migration effort, but they're also impeding development on wayland itself. So if you're annoyed multipointer isn't supported in Wayland, I can point you towards whose fault it is.
      - cookiecaper 10y ago
        I think the general frustration is not that X is being replaced, rather that practically anything the OSS world does quickly fragments over minor differences, resulting in a very inefficient division of already-scarce labor. I believe this happens because there is no real unifying force other than good feelings. In a company, people are forced to make reasonable efforts to work together or they imperil their paycheck. In the open-source world, people won't volunteer their time to work on your young project if it doesn't fit their taste profile quite exactly. Since it's rare for that to happen, lots of people spend lots of time re-inventing the same basic stuff and very few people spend time working on the difficult 20% of problems that would yield an 80% improvement in overall experience. We see this over and over in the open-source world, and it's not without its benefits, but particularly in core underlying components like display servers, it can be very frustrating because you just want everyone to adopt something and move forward. The delays caused by the fragmentation can impair things for years as driver vendors play a "wait and see" game and talented developers look at it and say "Wow, that looks like a mess, I'll stick with Windows for now". Personally I think Mir is straight up power grab. Canonical said "Why should we be bound by what these Wayland dweebs say? Even if their stuff is great, we are the biggest desktop Ubuntu distribution and we want to be in control. We will make our own display server." It is frustrating on the outside, but I guess you can't argue that it's not in Canonical's interests, and they may indeed end up winning the war (though it didn't work that way with Upstart).
    - lvillani 10y ago
      "X isn't network transparent anymore" according to Daniel Stone (longtime X.org and Wayland developer): https://youtu.be/RIctzAQOe44?t=18m31s https://youtu.be/RIctzAQOe44?t=18m31s If you use X11 forwarding with any application that uses a modern toolkit (Gtk+ 3, Qt 5, maybe also Gtk+ 2 and Qt 4) you are just pushing uncompressed pixmaps over the wire, as a bad substitute for VNC/RDP/etc. Xpra adds image compression on top, AFAIK, so it should be slightly better. The entire video (https://youtu.be/RIctzAQOe44 https://youtu.be/RIctzAQOe44) provides a good overview as to why people that have been working on X11 for many many years decided to start Wayland.
      - bitwize 10y ago
        Whose fault is that? The toolkit's? Or the protocol's? Expecting Wayland to sop up the slop because by definition it communicates at RAM-bandwidth speeds does not remove the fact that you have slop, and eventually it will bite you. Most GUIs are relatively static. They are not Crysis. Even if you hate X's drawing primitives and believe absolutely in the power of client-side rendering, there are huge wins to be had simply by pre-rendering stuff and storing it server-side as pixmaps, then using XCopyArea calls to show them on the screen. Sheesh, I was doing that since I was 18 years old, and I figured it out using just the man pages. It's not hard. It's not even particularly burdensome. It's just a case of "herp, derp, we don't want to think about our rendering code" from the toolkit crowd. Do we have to burn the entire display stack to conform to toolkits written the stupid way around?
        kefka 10y ago
        Well, I'd be all for a rewrite. But doing so, we're throwing all existing Xwindows code down a drain. I'm not liking that, at all. I also want network transparency. Right now, I can run a Windows program remotely, via X and WINE. I can't do that on Windows proper without a whole lot of setup on a Windows Server (I've done it). Yeah, X may be slow. It may have crappy security model. But in the end, it's better than what MS has and better than what Mac has. I could imagine something different. Go back to core principles, and write a server using current design paradigm and knowledge of hardware. Get the server side running, and well. Write an emulation layer that will allow existing X apps to use it. And then start porting from X to.. say, Ywindows. :) (Then again, I wished that DRM existed for Linux, so the graphical subsystem could have its own top, memory manager, process scheduler, and such. Then that would have set up Linux to be the dominant force in computation. Alas, it never happened that way.)
    - Redoubts 10y ago
      > They got rid of the idea of the X protocol and network transparency. > I like being able to log in to remove Linux machines, and run programs that show up locally on my desktop. I sure don't. I've had terrible experiences with this and end up going with VNC for any sufficiently complicated program (Firefox, Matlab, Cadence).
  - bitwize 10y ago
    Three if you count Mir. And you forget the constant churn of protocols, APIs, services, and whatsits in other domains not related to the display server. init to upstart to systemd is one example. It'd be one thing if there were a more robust rearchitecting in the spirit of the original (like runit in the init space), but nope -- it's always "that which exists is all legacy cruft, and must all be burned to the ground". And once problems come up, the new stuff too must be completely razed before starting afresh. The current push to wipe X from the pages of history and pave the way for a Brave New Wayland World reminds me more of GNOME's troubled development cycle, marked by a complete churn of APIs, components, and UI standards every few years, than it does of Unix tradition which has kept knowledge alive and broadly transferrable from platform to platform for 40 years.
    - scrollaway 10y ago
      > Three if you count Mir. Canonical's attempt to powergrab over wayland, like someone else said below. > init to upstart to systemd is one example Upstart, another canonical brainchild. As for initd, it's a similarly old system with a lot of cruft. Systemd brought the linux desktop and server an insane amount of QOL that it was sorely lacking. Honestly, there's no nice way to put it: It's incredibly arrogant of you to claim that various systems are useless simply because you can't see why they'd be useful. That OSS community that "loves churn", the people who are working on Wayland and such, it's a talented full bunch that is, in the majority of cases, giving its talent and time away for the good of the community. They're certainly not forcing you to use what they're making (like you seem to think they are), so it's incredibly thoughtless of you to shit on their work like that.
      - bitwize 10y ago
        I hate sysvinit, but the init binary itself is quite small and cruft-free. It's the /etc/rcN.d stuff that has all the cruft. This boggled my mind (and got me hacked) when I came off Slackware, where I'm used to fine-tuning service access by tweaking a shell script or two. Had systemd been a framework like runit, which nicely combines Unix primitives into an easy-to-use and featureful framework, I wouldn't whinge so much about it. But its design is monolithic (despite having 60-odd binaries, they all mutually and tightly depend on one another), its code is not that great and it's basically an inner platform in its own right. And all that isn't necessary to achieve the goals of dependency-based startup, process isolation, etc. Sendmail belongs in the dustbin of history. But its replacements, like qmail and exim, preserved its spirit while fixing its deficiencies. Thus it is with init and runit. The current environment does not favor keeping the spirit of the past alive, but burning it to the ground and erasing it from memory. And when serious deficiencies are found in the new hotness, the answer is to burn that to the ground too. I blame the GNOME project, whose manifesto was called "Let's Make Unix Not Suck"; Unix not sucking involved writing a Windows-like inner platform and encouraging or coercing developers to target that instead. Famously, GNOME has undergone at least two slash-and-burn cycles and its latest installation is known for its instability.
Lintaris 10y ago
In a world of 450+ active Linux distros, we got just two new ones here!

I get the feeling that as soon as Wayland gets significant uptake and starts being less than broken for most users, it will instantly be replaced with something even more bizarre and inexplicable. The OSS community seems to view constant change -- and churn -- as an inherent good.

scrollaway 10y ago
Right, because two protocols in 32 years is "constant change".
- kefka 10y ago
  Nahh, that's not why. They got rid of the idea of the X protocol and network transparency. I like being able to log in to remove Linux machines, and run programs that show up locally on my desktop. And since it's not some framebuffer, I know the X commands are being send and then rendering on my side. That's loads better than some dumb pixel maps. And X is extensible. Plugins aren't easy to write, but you can do it. We have Screen for X (Xpra), mpX (multiple pointer/keyboard), OpenGL, and loads more. Yeah, some could be considered cruft, or multiple ways to do the same thing, but that's the Unix Way.
  - tornadoboy55 10y ago
    X is inherently insecure. That's enough of a reason to have everything in Wayland ASAP.
    - bitwize 10y ago
      There's nothing inherently insecure about the X protocol. Sandboxing X would involve simply not providing information about drawables not created by the client. That means filtering out input events destined for those drawables and returning blank pixmaps when their contents are asked for. That the X server doesn't do this, and provide knobs to control who is trusted and who isn't, is a shame. But again, we don't have to burn the entire graphics stack because security.
  - scrollaway 10y ago
    None of that is relevant to parent's comment about "churn". I guess they're assuming the X11 ecosystem is literally the same as the Javascript one, or something. I'm honestly astonished at how quickly people jump on to wayland to complain about it, about how things are changing, about how it's not perfect etc. Wayland is an ongoing answer to a plethora of long term problems that Linux is facing. Display-level app sandboxing, screenlock security, high DPI (scaling) support, etc. Dropping support for 30 years of legacy that is no longer relevant is just a bonus. In the real world, things like multi pointer never worked (neither GTK nor Qt really supports it). High DPI monitors on the other hand are getting more and more common. So yeah, priorities. And the wayland devs aren't some cabal out to prevent people from implementing those things you mention; or creating a solid plugin interface. They're just lacking in manpower because 1. it's hard and 2. few are seriously paying for that development to happen. So when a company like Canonical decides to do their own version of wayland, not only are they actively removing potential users from the display server, and duplicating the migration effort, but they're also impeding development on wayland itself. So if you're annoyed multipointer isn't supported in Wayland, I can point you towards whose fault it is.
    - cookiecaper 10y ago
      I think the general frustration is not that X is being replaced, rather that practically anything the OSS world does quickly fragments over minor differences, resulting in a very inefficient division of already-scarce labor. I believe this happens because there is no real unifying force other than good feelings. In a company, people are forced to make reasonable efforts to work together or they imperil their paycheck. In the open-source world, people won't volunteer their time to work on your young project if it doesn't fit their taste profile quite exactly. Since it's rare for that to happen, lots of people spend lots of time re-inventing the same basic stuff and very few people spend time working on the difficult 20% of problems that would yield an 80% improvement in overall experience. We see this over and over in the open-source world, and it's not without its benefits, but particularly in core underlying components like display servers, it can be very frustrating because you just want everyone to adopt something and move forward. The delays caused by the fragmentation can impair things for years as driver vendors play a "wait and see" game and talented developers look at it and say "Wow, that looks like a mess, I'll stick with Windows for now". Personally I think Mir is straight up power grab. Canonical said "Why should we be bound by what these Wayland dweebs say? Even if their stuff is great, we are the biggest desktop Ubuntu distribution and we want to be in control. We will make our own display server." It is frustrating on the outside, but I guess you can't argue that it's not in Canonical's interests, and they may indeed end up winning the war (though it didn't work that way with Upstart).
  - lvillani 10y ago
    "X isn't network transparent anymore" according to Daniel Stone (longtime X.org and Wayland developer): https://youtu.be/RIctzAQOe44?t=18m31s https://youtu.be/RIctzAQOe44?t=18m31s If you use X11 forwarding with any application that uses a modern toolkit (Gtk+ 3, Qt 5, maybe also Gtk+ 2 and Qt 4) you are just pushing uncompressed pixmaps over the wire, as a bad substitute for VNC/RDP/etc. Xpra adds image compression on top, AFAIK, so it should be slightly better. The entire video (https://youtu.be/RIctzAQOe44 https://youtu.be/RIctzAQOe44) provides a good overview as to why people that have been working on X11 for many many years decided to start Wayland.
    - bitwize 10y ago
      Whose fault is that? The toolkit's? Or the protocol's? Expecting Wayland to sop up the slop because by definition it communicates at RAM-bandwidth speeds does not remove the fact that you have slop, and eventually it will bite you. Most GUIs are relatively static. They are not Crysis. Even if you hate X's drawing primitives and believe absolutely in the power of client-side rendering, there are huge wins to be had simply by pre-rendering stuff and storing it server-side as pixmaps, then using XCopyArea calls to show them on the screen. Sheesh, I was doing that since I was 18 years old, and I figured it out using just the man pages. It's not hard. It's not even particularly burdensome. It's just a case of "herp, derp, we don't want to think about our rendering code" from the toolkit crowd. Do we have to burn the entire display stack to conform to toolkits written the stupid way around?
      - kefka 10y ago
        Well, I'd be all for a rewrite. But doing so, we're throwing all existing Xwindows code down a drain. I'm not liking that, at all. I also want network transparency. Right now, I can run a Windows program remotely, via X and WINE. I can't do that on Windows proper without a whole lot of setup on a Windows Server (I've done it). Yeah, X may be slow. It may have crappy security model. But in the end, it's better than what MS has and better than what Mac has. I could imagine something different. Go back to core principles, and write a server using current design paradigm and knowledge of hardware. Get the server side running, and well. Write an emulation layer that will allow existing X apps to use it. And then start porting from X to.. say, Ywindows. :) (Then again, I wished that DRM existed for Linux, so the graphical subsystem could have its own top, memory manager, process scheduler, and such. Then that would have set up Linux to be the dominant force in computation. Alas, it never happened that way.)
  - Redoubts 10y ago
    > They got rid of the idea of the X protocol and network transparency. > I like being able to log in to remove Linux machines, and run programs that show up locally on my desktop. I sure don't. I've had terrible experiences with this and end up going with VNC for any sufficiently complicated program (Firefox, Matlab, Cadence).
- bitwize 10y ago
  Three if you count Mir. And you forget the constant churn of protocols, APIs, services, and whatsits in other domains not related to the display server. init to upstart to systemd is one example. It'd be one thing if there were a more robust rearchitecting in the spirit of the original (like runit in the init space), but nope -- it's always "that which exists is all legacy cruft, and must all be burned to the ground". And once problems come up, the new stuff too must be completely razed before starting afresh. The current push to wipe X from the pages of history and pave the way for a Brave New Wayland World reminds me more of GNOME's troubled development cycle, marked by a complete churn of APIs, components, and UI standards every few years, than it does of Unix tradition which has kept knowledge alive and broadly transferrable from platform to platform for 40 years.
  - scrollaway 10y ago
    > Three if you count Mir. Canonical's attempt to powergrab over wayland, like someone else said below. > init to upstart to systemd is one example Upstart, another canonical brainchild. As for initd, it's a similarly old system with a lot of cruft. Systemd brought the linux desktop and server an insane amount of QOL that it was sorely lacking. Honestly, there's no nice way to put it: It's incredibly arrogant of you to claim that various systems are useless simply because you can't see why they'd be useful. That OSS community that "loves churn", the people who are working on Wayland and such, it's a talented full bunch that is, in the majority of cases, giving its talent and time away for the good of the community. They're certainly not forcing you to use what they're making (like you seem to think they are), so it's incredibly thoughtless of you to shit on their work like that.
    - bitwize 10y ago
      I hate sysvinit, but the init binary itself is quite small and cruft-free. It's the /etc/rcN.d stuff that has all the cruft. This boggled my mind (and got me hacked) when I came off Slackware, where I'm used to fine-tuning service access by tweaking a shell script or two. Had systemd been a framework like runit, which nicely combines Unix primitives into an easy-to-use and featureful framework, I wouldn't whinge so much about it. But its design is monolithic (despite having 60-odd binaries, they all mutually and tightly depend on one another), its code is not that great and it's basically an inner platform in its own right. And all that isn't necessary to achieve the goals of dependency-based startup, process isolation, etc. Sendmail belongs in the dustbin of history. But its replacements, like qmail and exim, preserved its spirit while fixing its deficiencies. Thus it is with init and runit. The current environment does not favor keeping the spirit of the past alive, but burning it to the ground and erasing it from memory. And when serious deficiencies are found in the new hotness, the answer is to burn that to the ground too. I blame the GNOME project, whose manifesto was called "Let's Make Unix Not Suck"; Unix not sucking involved writing a Windows-like inner platform and encouraging or coercing developers to target that instead. Famously, GNOME has undergone at least two slash-and-burn cycles and its latest installation is known for its instability.

Lintaris 10y ago

In a world of 450+ active Linux distros, we got just two new ones here!