Hacker News new | comments | show | ask | jobs | submit login
Wayland anti-FUD (ppaalanen.blogspot.de)
67 points by VMG on May 11, 2012 | hide | past | web | favorite | 46 comments

I like the way he says "possible network layer".

It's the lack of network transparency which is the problem. No one's complaining about the overhead of it, because Wayland lacks this crucial feature.

Edit: Other features lacking in Wayland: A close button which works, consistent decoration across apps, efficient cut and paste, ... And things which Wayland has that are basically bugs: windows which are rotated at non-90 degree angles.

Remember the Unix philosophy? Something about small, well defined components doing a single thing well?

X violates it in every way possible. It has probably found a few ways of violating it that are not possible, and done it anyway. Wayland is a part of moving back to the roots. It will lack at least 95% of all the features X has, because they really, really shouldn't be implemented as a part of a huge, monolithic system that has to run as root. Instead, all those features should be their own libraries/daemons.

As such, Wayland will never understand networks the way X does. Which is good, because it shouldn't. Wayland will never do anything put pass OGL handles between processes, and do the last few stages of compositing, and forward input. It actually has a well defined scope, unlike the amorphous blob that is X.

Nothing stops you from implementing a network transport layer above Wayland. And somebody will. And since there is room for competing implementations, in less than two years, there will be better network display protocols than what X does. When you split huge, monolithic things into smaller parts with clearly defined interfaces between them, the parts themselves become easier to make.

> Other features lacking in Wayland:

- A close button which works

This is trivial. Just don't draw the close button with the application. Personally, I want my "close program" in a static place on the screen, so that's not a problem at all. If you want close buttons above windows, make the window manager put a small box it owns in the upper corner.

- consistent decoration across apps

When is the last time you tried to run apps from different toolkits on the same desktop? Notice that they look the same because it's implemented in the toolkit? X doesn't have consistent decorations across apps, and hasn't had them for a decade.

- efficient cut and paste

Why, oh why should that be part of the display server? Just why? Do you just want to pile all the features in the system into one big ball? And as for efficient, just how often do you cut and paste anyway?

Wayland lacks feature X is not a valid criticism against Wayland. Because that does not mean that a system using Wayland lacks feature X. And the primary feature of Wayland is that it implements as few features as possible.

Have there ever been any successful cases of a UNIX philosophy window system which could be used to back up the "really shouldn't be implemented as a part of a huge, monolithic system" thing?

In most circumstances I'm totally cool with accepting the superiority of the UNIX philosophy as an axiom, but I don't think I am in this particular case.

plan9's rio is very unixy, and quite "successful" at what it does.

I was thinking more along the lines of: do Windows or Mac OSX do it in a more unix-y way than X?

When it comes to "GUI stuff" I am a consumer. I don't care about better software engineering practices in my windowing system unless that means the experience will be better for me. So far I am not seeing that offered by Wayland, nor am I seeing any real evidence that better engineering would or could offer me a better experience. If this were still 1995 and battling X was still something I did then I'd be less inclined to ask for evidence, but these days X is simply something I only know that I use because it used to be a hassle. I haven't had to know about it for years, which I think is the way Windows and OSX work for their users.

The advantages of a more unixy display system are all indirect. Right now, working on that side is pretty arcane. Wayland will make it much simpler, so that cool ideas and new innovations will get turned into reality faster.

The only direct advantage Wayland will bring is a flicker-free and tear-free desktop.

I'm under the impression that flicker-free/tear-free are features that KVM brings to Wayland and that X already has if you use KVM drivers. Is that not the case?

Do you really mean Kernel Virtual Machine or did you mean Kernel Mode Setting?

Ah sorry, KMS. Been working with KVM too much recently ;)

"tear free" and "flicker free" constantly come up in discussion of Wayland. My X desktop does not tear or flicker. I've in fact not seen an X desktop doing either of these things.

Right. And if your X desktop did do it, then so would Wayland. Both use more or less the same acceleration infrastructure.

Your argument would be a bit stronger if Wayland was actually modular. Instead is does (or at least, attempts to do) all of the above, except networking.

Umm, no?

Wayland does giving out pointers to buffers, compositing, and input redirection. These all strongly depend on each other -- you cannot correctly redirect input without knowing the exact location of everything on the screen, you cannot composite without having access to the buffers. Any attempt to modularize the parts further would only lead to false independence -- no matter how you organize them, the parts are going to have to intimately know of each other to work.

A minimal Wayland implementation is "less than 1000 lines." I really cannot imagine what else could be cut from it.

Wayland does not do clipboards, rendering, fonts, networking, drivers, or anything else that makes the X server source tree be hundreds of megabytes.

> Wayland does not do clipboards, rendering, fonts, networking, drivers, or anything else that makes the X server source tree be hundreds of megabytes.

X doesn't do clipboards, drivers, or fonts. Network transparency does not affect the code size. And the source tree is approximately 25 to 30 megabytes. It contains 7 different X servers (Xdmx, Xvfb, Xnest, Xquartz, Xwin, Kdrive and Xorg). The server you're talking about contains 6 megabytes of machine dependent code.

In fact, all the infrastructure that Wayland depends on is the infrastructure that X uses.

Wayland lacks feature X is not a valid criticism against Wayland. Because that does not mean that a system using Wayland lacks feature X. And the primary feature of Wayland is that it implements as few features as possible.

1st Bob: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers? Tom: Yes, yes that's right.

2nd Bob: Well then I just have to ask why can't the customers take them directly to the software people?

Tom: Well, I'll tell you why... because... engineers are not good at dealing with customers...

1st Bob: So you physically take the specs from the customer?

Tom: Well... No. My secretary does that... or they're faxed.

2nd Bob: So then you must physically bring them to the software people?

Tom: Well... No. ah sometimes.

1st Bob: What would you say you do here?

Tom: Look I already told you, I deal with the @#$% customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!

What's wrong with delegating all of these features into modular applications maintained separately, where they belong?

We already tried the monolithic "everything you might want to make a GUI plus a few kitchen sinks transported over a network" approach to display servers. It didn't work out very well - it created a gigantic, bloated mess, with forward-looking extensions bolted on (composite) and deprecated ideas from the early 1990s clinging on for dear life (everything related to fonts).

There's no reason a networked layer can't be implemented on top of Wayland. Plus, because Wayland is simply a "dumb pipe"-style compositor, several network abstractions can be implemented and duke it out for supremacy: with Wayland, one could write a server which ships GL commands to the client (enabling leveraging the fast render path of the client's video hardware), a server which ships rasterized video (a la VNC), or even a server which implements drawing primitives a la X (or X itself)!

Wayland does not preclude the idea of network transparency. It simply builds the base level of abstraction on which network transparency can be built.

Network transparency is been touted as X's killer feature for decades at this point. I've been using linux as my primary os for a very long time, and have NEVER used it. I find it amusing that the default way to do desktop share in ubuntu (and most of the other distros) is vnc not X.

More to the point, I find that VNC has one huge advantage over X sharing. When I move my computer, all my programs don't get closed.

I'm never sure why something like 'screen' for X applications isn't standard (I suppose that is what VNC is..)

http://xpra.org/ might interest you

I have used it, for a few days, but easily could have used VNC or some like it instead.

How did you determine that network transparency is a crucial feature? All other GUI environments I use (Windows, Mac OS, Android, iPhone) appear to get along pretty well without it. It seems like a pretty complicated requirement that may be blocking desktop Linux progress.

So if other systems don't have a feature, Linux shouldn't have it? Shouldn't Linux strive to be better than other systems? The attitude of "Windows gets along fine without it" just leads to a race to the bottom.

That's a straw man. All features should be weighed against each other. Priorities and engineering choices should consider all potential Linux users, not just the current most vocal-crustiest.

For instance, I personally prefer lower latency and ease of programming over network transparency. Your bottom might be my top ;)

That's fair and I agree with you that features need to be weighed against each other. But I really don't think a feature's presence or absence in another operating system should have much weight in a discussion about Linux. Nor would I assume that because another system made a feature tradeoff it's the right tradeoff, either in general or for Linux specifically.

For example I wish Windows exposed it's fork()-ing mechanism in the Win32 API. Not sure why they didn't.

It makes things much simpler.

There are billions of ways Linux could be better than Windows suggesting one of them is not worth the cost does not mean your in a race to the bottom.

I don't care about network transparency, but the fact that wayland doesn't have a window manager in the traditional sense really bugs me. Plus, nvidia have said that they won't be supporting wayland at all. This leads me to believe that in the end we'll end up running everything in X as usual, and X will be a thin enhancement layer over wayland. There's way too much infrastructure in X to just brush it all off client-side.

The wayland compositor is the traditional window manager, takes a similar amount of code to write, and has the same scope and usage.

Additionally, Nvidia doesn't need to support Wayland, that is why Wayland isn't using GLX by default.

How does Wayland draw things on the screen if it doesn't support the video card?

I meant to imply that Nvidia the company doesn't need to support Wayland specifically, rather that Wayland has multiple ways to support the GPU without the company's involvement.

Network transparency is not a "crucial" feature. 90% of Linux desktop users do not use network transparency. The other 10% can (assuming Wayland is successful) use Xorg, do without, or use VNC (yes, I know it is not the same thing).

You can use the "only 10% of users use it" argument on so many features. That doesn't mean Linux shouldn't have it. That argument might fly with a commercial OS like Windows or Mac OS X, but some OS needs to provide a long tail of useful features for power users.

You also have to weigh the utility of features. It may be that 90% of Linux desktop users would rather have fancy composting and a "cube effect" when doing fast user switching[1], but shouldn't network transparency win because it actually does something useful?

[1] See "Is Wayland replacing the X Server?" on http://wayland.freedesktop.org/faq.html#heading_toc_j_4

Much as you can run X within Wayland there's absolutely no reason why it's shouldn't be possible to build networking above Wayland. Even better, there's room for competing implementations - one could implement a framework which ships some sort of serialized OpenGL commands (client-side hardware rendering), fully rasterized windows (relying on the server's video hardware), or abstract primitives (like X).

By providing a level of abstraction lower than that of X, Wayland provides a more flexible framework over which to implement whatever "long tail" of useful features the Linux community desires.

> The other 10% can (assuming Wayland is successful) use Xorg...

That's not very convincing. Assuming Wayland is successful, Xorg may vanish; that certainly seems to be what a lot of people are hoping.

For Xorg to vanish every application that relies on it would have to be ported to Wayland, and I don't see that happening anytime soon.

if Emacs and either Google Chrome or Firefox get ported to Wayland and Wayland fixes some of the problems with X, then Wayland will have made my life better even if I still need X to run other applications.

I think 10% is pretty generous. More like 0.005%, maybe.

Whoa wait, we are really supposed to replace X with something that only works on Linux? Way to give BSD guys the middle finger.

Or the BSD guys can implement the required infrastructure and bring their kernels to the modern era, instead of requiring userspace programs to hack around their lack of features. The only people giving the BSD guys the finger is themselves.

The problem is that the only documentation for the "required infrastructure" is the Linux source itself which is constantly changing.

I doubt that the BSD infrastructure has to match the Linux infrastructure exactly for the Wayland protocol to work on it. Mostly what it has to do is mode-setting in the kernel, enable sharing of graphics buffers between processes, and allowing libkms and mesa to work on top of it. The exact kernel api shouldn't matter for most applications.

X is rapidly becoming a system that only works well on Linux.

No, X works just fine on other platforms thank you very much.

Now GNOME and other things are a different story.

AIUI X on FreeBSD depends on HAL, X support for which is now deprecated? I haven't had any trouble yet, but I'm worried.

Try using a recent model AMD graphics card, you will only get hardware acceleration when running X on Linux.

That's a driver; has nothing to do with X itself.

Consider that the nVidia driver works on Solaris, FreeBSD, and Linux. Therefore accelerated X works there as well.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact