I found this interesting blog about how a long tradition of multy processes and memory protection in Linux is coming to an end. I'm not technically qualified to say “he is right”, but well... he sounds right.
Wonders from a KDE fan and developer about some KDE design choices
Any thought?

There's the response from Aaron Seigo:

Aaron Seigo wrote:if you don’t like it that plasmoids run in-process: please solve in a reasonable fashion the need to paint several individual components on the same canvas with reasonable performance and in a way doesn't compromise the interaction capabilities we have. post your patch to plasma-devel and we’ll all be overjoyed to receive it.

that just points out a design error in plasma.

samhain wrote:that just points out a design error in plasma.

Let me quote Artur Souza:

It's not easy (and feasible at all) to write a canvas based software that is multi-process without having a *lot* of problems. As Jason also pointed it out, scripted plasmoids are the way to go in the near features, so we can sandbox all the plasmoids and just have the 'safe' ones as c++ ones. This would enable us to save plasma from this crashes.

So if you don't want things to crash, don't use 3rd-party C++ plasmoids.

I don't use plasmoids at all. I was not able to get even folderview working reliable on all test maschines. I use 1:1 disk images on different hardware.

Is it me, or does this sound comparable with having every button in every toolbar in an application run as a separate process, just in case clicking one causes a crash?

Well, to be fair not only kde is following the "one process" road: OOo is one process also, and firefox and... seems that this "problem" is in fact a "tendency", maybe because the problems generated by using different processes are many/worst than the "one process problem".
I use few plasmoids, and since January I had only one plasma crash... when I was testing a non standard binary plasmoid (one of those new taskbar... cannot remember which one).
Oh well.

I told in other post about this plasma, for me, a better solution was implement all plasmoids in ruby, python, jscript, etc.., because with that languages are more difficult to achive a crash. In my tests, the crash are always related to bindings but, if you take care creating bindings, you obtain a more stable system. No problem if in the first versions of Plasma only Javascript was available and results are limited, with time, other languages could be added.

Amarok developers take the decision to remove ruby an python and support only Javascript. People was not happy but, at long term, I think that they was right.

I don't see the reason to use C++ to develop a plasmoid because, generally, if you need a high performance plasmoid, then you really don't must create an application that was running permanently in your desktop eating a buch of your resources.

I don't know anything about X but, at high level, Plasma was a specialized case of X so, why developers don't use similar technology? If and X application crash the other applications don't. There are much talk about plasmoids relation but, I don't seen any relation except the "smart" postioning system, an with smart I was trying to be ironic .

Is a question discusses many times in this forums but Aaron, and the other plasma develepers, seems to think only in performance terms and not in stabilty terms. Performance is a point that a developer allways must watch but, stability, is the first priority. Well, that's my point of view obviously .

With stability plasma developers are in the same place situation as encoding system developers with legacy encoding. Both need to redesing totally his code because they are now in a impasse.

What I don't get about plasmoids is that clumpsy user interface for move/size. why can't they have disappearing active borders? I usually end up in a situation where that "toolbar" is neetly visible but hidden from interaction behind a panel (my panels are vertical)

Madman wrote:Is it me, or does this sound comparable with having every button in every toolbar in an application run as a separate process, just in case clicking one causes a crash?

It's you and it's not comparable.

You can test chrome developers works and design. All tab was and independent process so, if one crash the other survive. With konqueror, when flas player crash konqueror goes to hell but, with Chrome, not only chrome survives, the page survives too and only the flash container is broken.

This is a good job and a good design and the reason why an alpha version is more stable that any version of Konqueror 4 or Plasma released and that will be released.

Ignacio Serantes wrote:

Madman wrote:Is it me, or does this sound comparable with having every button in every toolbar in an application run as a separate process, just in case clicking one causes a crash?

It's you and it's not comparable.

You can test chrome developers works and design. All tab was and independent process so, if one crash the other survive. With konqueror, when flas player crash konqueror goes to hell but, with Chrome, not only chrome survives, the page survives too and only the flash container is broken.

It's worth noting that a web-browser takes far, far less development effort then an entire desktop shell, especially one as feature-full as Plasma. I don't know about you, but sending signals through D-Bus whenever I add a plasmoid to my desktop doesn't sound appealing, neither does implementing the entire desktop via Javascript or developing a new inter-process communication platform specifically for Plasma. The solution is simple: make base widgets C++ and rock-solid stable and have non-base widgets implementable through run-time languages like Python, Javascript etc.

Ignacio Serantes wrote:This is a good job and a good design and the reason why an alpha version is more stable that any version of Konqueror 4 or Plasma released and that will be released

Madman wrote:... I don't know about you, but sending signals through D-Bus whenever I add a plasmoid to my desktop doesn't sound appealing...

No, you're way understating that! You'll be sending the whole pixmap of the plasmoid every single time it repaints. Imagine what the performance will be...

Obviously I'm not a C++ neither has a big knowledge about Plasma or Konqueror but, in an application like Chrome you have elements, like a flash container, image containers, text, animated gifs and even video. All these element can be viewed as a kind of "plasmoids" because they are independent but inside Chrome, some elements can be resized, and change it's relative position if browser is resized but, if one of this elements crash, Chrome survives.

On the other side, you have Firefox or Amarok. In both cases, you can find a lot of applications developed to increase Firefox and Amarok power that don't crash the host application, at least I never have this kind of crash.

If for one side was Chrome and for the other side there are a very powerful but stable plugin able programs like Amarok and Firefox, what was the big problem with Plasma and Konqueror to achieve the same. Konqueror 3 was powerful and stable but Konqueror 4 is really far of the same stability.

Finally, we have Xorg. In Xorg many programs are working and sending signals about window positions and, when a running program crash, konqueror 4 and plasma are good examples, not all my Xorg session crashed.

My question is simple, if programs like Xorg, Amarok, Firefox and Chrome exists it's perfectly clear that stability and powerful can be achieved so, why Konqueror 4 and Plasma was so unstable? What is the big advantage that Konqueror 4 and Plasma offer to us at cost of unstability?

My guess is that the whole of kde4 was really designed for embedded devices and netbooks, ie sytems with very limited mem and cpu and a very small (touch)screen, all the downsides for normal desktops in usability and stability are taken for granted

If it were so then it would have a long way to get there.