Will Wayland Become A New Desktop Standard?

[zester]

Sorry, that disqualifies it then. XML is too slow for fast IPC (it's fine for service descriptions, but too heavy for IPC payloads).

DBUS uses XML all over the place. Besides Vortex uses libaxl for XML it's 14% faster that libxml

It has XML-IPC (An inter-process communication protocol built upon file pipes and
the methodCall and methodResponse encodings of XML-RPC.)

Not to mention non-blocking parallel communication

And for the IDL to XDL it uses a protocol compiler.

Stop acting like you know what your talking about.

[zester]

Maybe I should have refrazed those responses.

1. You wouldn't want an IPC framework in Wayland because Wayland was mean't to be as abstract as
possible. So that it will scale properly in the future. And you wouldn't wan't to tie all toolkits to a dbus
dependence. They might wan't to implement there own IPC framework.

2. Rootkit's on Linux are possible but not all that common. You see them mostly on servers that are using outdated software.

The Linux kernel actually has mechanisms to protect against rootkit's.
And if a Linux user implements proper security (Read only Partitions, ACL, Real-time Disk Encryption, Strong Passwords, Proper Network Port Management ,Keeping your System Updated with the latest Security Fixes) Then yes chances that your Linux box will be rooted are unlikely.

Note: That is considered entry level security there are much more advanced bare-metal ways to protect a Linux box but there considered out of scope for your average Linux user.

[zester]

I'd do this to have only one IPC protocol, which already has nice features for access control.
BEEP looks nice, but as far as I understand it doesn't specify marshaling formats.

XML, XDL and (IDL - Vortex will detects and coverts IDL to XDL) marshalling all data, and unmarshall all replies received.

If your system is available over the network then it can be rooted (even if in theory).

Sure in theory. Any type of security measure can be broken, but that doesn't mean it has or is common like the OP made it out to be.

[Cyberax]

XML, XDL and (IDL - Vortex will detects and coverts IDL to XDL) marshalling all data, and unmarshall all replies received.

Sorry, that disqualifies it then. XML is too slow for fast IPC (it's fine for service descriptions, but too heavy for IPC payloads).

Sure in theory. AES-256 can be cracked in theory doesn't mean we will ever see it happen in our life time.

There were remote exploits in the TCP stack. Are you sure that there aren't any still present? Or had you turned off TCP as well?

[zester]

I'd do this to have only one IPC protocol, which already has nice features for access control.
BEEP looks nice, but as far as I understand it doesn't specify marshaling formats.

XML, XDL and (IDL - Vortex will detects and coverts IDL to XDL) marshalling all data, and unmarshall all replies received.

If your system is available over the network then it can be rooted (even if in theory).

Sure in theory. AES-256 can be cracked in theory doesn't mean we will ever see it happen in our life time. And AES isn't
even the strongest there are others that are stronger and in the public domain.

[Cyberax]

Someone should pimp slap you for that dumb a*& comment, why the hell would you wan't to do that??? Wayland was designed to be as abstract as possible. Besides Dbus is crap, the future is BEEP: Blocks Extensible Exchange Protocol for IPC

I'd do this to have only one IPC protocol, which already has nice features for access control.

BEEP looks nice, but as far as I understand it doesn't specify marshaling formats.

My core system is on it's own primary partition that is read only and only accessible locally. And if that isn't enough I have a 12 gauge and a Rottweiler and I live in Pennsylvania. There isn't a hacker on this planet that is going to root my box. So yahh linux can be immune to root kits.

If your system is available over the network then it can be rooted (even if in theory).

[zester]

X definitely needs some work as far as compositing goes, but mend it, don't end it please!

Yahhh IBM, Intel, AMD, Google, Novell, RedHat, Oracle, Plus the countless others have been trying to
do that for years. The flaw is in its design. Wayland was created because it was faster to just start over than to try and fix X. Besides Wayland is almost complete.

I wouldn't mind betting that the big distros will be shipping X for many many years to come on their default install.

Wrong the big guys already have plans to jump the X ship as soon as the Gtk and Qt compositors are considered stable. Qt's compositor will be shipping with Qt5 and Lighthouse. And both Gtk and Qt's compositors are almost complete.

The LSB should ask for some improvements on the graphics side through use of EGL+OpenWF.

The Linux Standard Base is garbage.

Even if the only benefit of wayland was a "cleaner" codebase the benefits would be big

If your saying that the Wayland code base is messy then you haven't even looked at it. The only problem I see is the lack of proper documentation.

So basically they will be totaly and completely bundled.

Nope they only applications that are going to have to be ported are the ones that are
using xlib or it's friends directly.

I wonder, can DBUS be used for Wayland instead of a custom socket protocol?

Someone should pimp slap you for that dumb a*& comment, why the hell would you wan't to do that??? Wayland was designed to be as abstract as possible. Besides Dbus is crap, the future is BEEP: Blocks Extensible Exchange Protocol for IPC

It served its purpose well for many years, but now it's just preventing us from going further.

That and not having proper opensource hardware accelerated Ati/Nvidia/PowerVR drivers.

"Each Wayland Server implementation can provide its own distinct set of interfaces..." This is a joke, right? We're doomed.

Lol he doesn't even know what that means

Oh, and adding another layer of indirection seems like a stupid idea.

Layer of indirection it works directly with the FBO!!!

Because the graphics developers are not amateurs and realize that reinventing the wheel is a *lot* harder than just adding bells and whistles to an already-working wheel.

Dude it's GL that works on the Frame Buffer. The protocol is almost complete, Gtk and Qt4 already
work on it. And if you have even looked at Wayland source you would see that its only a couple thousand lines of code.

So Wayland will be bundled with both compositor and window manager..

No each toolkit builds there own client compositors and anyone can build a window manager with it.
Everyone and there mother will have there own Wayland window manager that they wrote. Qt5 will
have classes just to build a window manager.

They are specifically X11 window managers and won't work. Actually, window management is done by wayland and window decoration by the clients

Your kinda right. I like to think of it as a scenemanager.

And one last one.

Wut? lol, sorry but linux is far from immune to rootkits.

My core system is on it's own primary partition that is read only and only accessible locally. And if that isn't enough I have a 12 gauge and a Rottweiler and I live in Pennsylvania. There isn't a hacker on this planet that is going to root my box. So yahh linux can be immune to root kits.

[Wyatt]

Via Greg K-H with the comment, "See, no stable api for Linux was the right thing to do" :

http://www.h-online.com/open/features/Kernel-comment-Perseverance-pays-off-1232036.html

I'm sort of amazed that after all this time people are still arguing for a stable kernel API.

[AlbertP]

But sometimes you need an API, to be able to use external modules like binary drivers.

[runeks]

That's nice but there should be a general system for all kinds of hardware physically possible.

Isn't the point that APIs are hard to design, and good APIs are extremely hard to design?

Someone could sit down and design an API, and then at a later point, some hardware would come along that requires things that this API doesn't make possible. Then the API needs to be redesigned, or a new version created, and we have the same compatibility issues that we had when we had no API.

I mean, this could probably work if Linux had 10-100 times the number of full time developers working on it.

Another thing, as I see it, is that, yes, APIs make it easier for user-space and outside kernel driver developers, but they make it harder for kernel developers who constrain themselves with these APIs. And since Linux is, in part at least, made for developers by developers, I think a lot of people would not be happy with these constraints.