Linked by Thom Holwerda on Sun 12th Feb 2012 23:23 UTC
Gnome "One of the things that the GNOME design crew have been focusing on recently is creating a new approach to application design for GNOME 3. We want GNOME applications to be thoroughly modern, and we want them to be attractive and a delight to use. That means that we have to do application design differently to how we've done it in the past."
Thread beginning with comment 506909
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: All this Re-engineering sucks
by tuma324 on Mon 13th Feb 2012 09:27 UTC in reply to "All this Re-engineering sucks"
tuma324
Member since:
2010-04-09

Software devs like to re-engineer. More so in OSS world.
Gnome ditched the rock stable 2.x when it was the most usable. KDE ditched 3.5.x when it was the most stable. If KDE ditches KDE4 tomorrow and goes for an all new set of structure before the currently stable platform becomes rock solid, I would be the least surprised.
Focus on stability seems to be no one's top priority.
A longer commitment to a platform could do a lot better for Linux users than fiddling with half-baked technology for the fancy of the devs.
We have seen examples of Pulse, Plasma, Beagle, Tracker store, Strigi, Nepomuk etc. and yet to see Wayland(I presume no remote X).
This Re-engineering really sucks.


New technology and re-engineering doesn't always means that the end result will be less stable, or that the system will be "unstable". Quite the contrary, specially when it comes to software development and new developments.

It depends quite a lot in the skills of the programmers, and if the new code base is already relying on solid and stable technologies, libraries, backends. etc.

In the case of Wayland, they're not rewriting things from scratch. Read their FAQ before spreading FUD:

http://wayland.freedesktop.org/faq.html


Why duplicate all this work?

Wayland is not really duplicating much work. Where possible, Wayland reuses existing drivers and infrastructure. One of the reasons this project is feasible at all, is that Wayland reuses the DRI drivers, the kernel side GEM scheduler and kernel mode setting. Wayland doesn't have to compete with other projects for drivers and driver developers, it lives within the X.org, mesa and drm community and benefits from all the hardware enablement and driver development happening there.


Basically, they're throwing away things that doesn't work and keeping things that work. They're building on top of things that worked for years: GEM, TTM, KMS, Linux, etc. And they're starting with a new fresh protocol that is simple and to the point. This is great engineering.

There are cases with projects when the old code base have bugs and leaks, and replacing those parts with new code often can result in a more stable system and better performance.

Heck, how many times have we seen projects that replace other projects with new code and they end up being a lot more stable? Git vs Subversion, anyone?

Wayland developers are even talking about adding reconnection to applications when the compositors go away or crash. This will improve stability a lot.

Please let's not be so negative, I know how you feel but things are improving and changing, and this is needed for the Linux desktop to grow.

Edited 2012-02-13 09:47 UTC

Reply Parent Score: 4

Gullible Jones Member since:
2006-05-23

Wait, KMS has worked for years? There are *still* machines that it crashes every time.

Reply Parent Score: 3

tuma324 Member since:
2010-04-09

Wait, KMS has worked for years? There are *still* machines that it crashes every time.


Do you file bug reports about that? Please do.

Reply Parent Score: 2

toast88 Member since:
2009-09-23

Wait, KMS has worked for years? There are *still* machines that it crashes every time.


Yes, it does perfectly. Tested on various graphics chipsets from Intel, nVidia and ATI.

If it doesn't work for you, it means that either your hardware is buggy or you're using a deprecated kernel version (< 2.6.32).

Seriously, KMS is absolutely mature. If you spot a bug, please be so kind and report it!

Adrian

Reply Parent Score: 1

mcpatnaik Member since:
2011-09-02

I really don't dislike Wayland. It skips one of my use-cases, That is remote desktop. I have been using remote rendering of X since long and with satisfaction. If tomorrow OpenSUSE defaults exclusively to Wayland (That's our pet distro) or KDE switches to it, I am in serious trouble if remoting code does not come to Wayland before the switch.
See Wayland faq http://wayland.freedesktop.org/faq.html

Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland.

My point of view is that every software project repeats a design cycle. But to adopt a new strategy even before you finish the previous goal is not professional. Goals for an iteration should be complete before you switch on to a new structure. Just don't leave users midway because you got a fancy for a new architecture.
Porting is really painful. Many good apps get lost in the switch. We don't have an army of developers fed by big money and directed by corporate vision. In OSS world we create software for ourselves. The end user is just like a family member. Let's think from his point of view. Backward compatibility is a necessary evil. If devs switch to every new and promising architecture and the old falls out of the ecosystem eventually, the community is at a loss. It is a social responsibility.

New technology and re-engineering doesn't always means that the end result will be less stable, or that the system will be "unstable". Quite the contrary, specially when it comes to software development and new developments.

Not every new architecture brings robustness immediately. Search tracker-store and nepomuk using 100% cpu in google. Let's also see the bug status of popular projects (Libreoffice, KDE, Gnome). It needs a lot of time and testing to build robustness. What happens to the user till such time? he is left with a plethora of half baked software in the name of choice. will anyone care?

Reply Parent Score: 3

tuma324 Member since:
2010-04-09

I really don't dislike Wayland. It skips one of my use-cases, That is remote desktop. I have been using remote rendering of X since long and with satisfaction. If tomorrow OpenSUSE defaults exclusively to Wayland (That's our pet distro) or KDE switches to it, I am in serious trouble if remoting code does not come to Wayland before the switch.
See Wayland faq http://wayland.freedesktop.org/faq.html
"Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland.

My point of view is that every software project repeats a design cycle. But to adopt a new strategy even before you finish the previous goal is not professional. Goals for an iteration should be complete before you switch on to a new structure. Just don't leave users midway because you got a fancy for a new architecture.
Porting is really painful. Many good apps get lost in the switch. We don't have an army of developers fed by big money and directed by corporate vision. In OSS world we create software for ourselves. The end user is just like a family member. Let's think from his point of view. Backward compatibility is a necessary evil. If devs switch to every new and promising architecture and the old falls out of the ecosystem eventually, the community is at a loss. It is a social responsibility.

New technology and re-engineering doesn't always means that the end result will be less stable, or that the system will be "unstable". Quite the contrary, specially when it comes to software development and new developments.

Not every new architecture brings robustness immediately. Search tracker-store and nepomuk using 100% cpu in google. Let's also see the bug status of popular projects (Libreoffice, KDE, Gnome). It needs a lot of time and testing to build robustness. What happens to the user till such time? he is left with a plethora of half baked software in the name of choice. will anyone care?
"

Wayland is just a protocol, why add networking to such a good protocol that is trying to keep itself simple, why make the protocol bloated and an unmaintainable mess like X11?

Wayland is trying to follow the UNIX philosophy of "Write programs that do one thing and do it well. Write programs to work together.".

But that doesn't mean that Wayland will kill network transparency, network transparency will be part of another layer, it will be part of the compositors, toolkits, or we can just use X11 on top of Wayland.

Having network transparency as another layer also benefits the users and developers. It benefits the user because if you don't want network transparency you can just choose to disable that layer on your system. And if you want it, enable it. This is also very good for security.

It also benefits the community and developers because it will result on a system that is easier to maintain, it will give us modularity, competition, elegance, KISS/UNIX philosophy, among other things.

Don't worry about it. Nobody will remove any functionality, things are just improving.

From the Wayland FAQ:


Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.

This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier.

It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share a window on the fly with a remote wayland compositor, for example, a friend's desktop.


http://wayland.freedesktop.org/faq.html

Edited 2012-02-13 21:44 UTC

Reply Parent Score: 3