Linked by Thom Holwerda on Mon 8th Aug 2011 22:09 UTC
KDE KDE is working on some interesting stuff. Wayland support for one, but they're also going to work on the frameworks for... KDE 5.0. Yes, I'd say KDE 4 still is far, far from done, but 5.0 is already on the horizon. This time around though, they're not going to pull a KDE 4.0, since this is mostly going to be about lower-level changes.
Order by: Score:
Tech Journalist translation:
by Bill Shooter of Bul on Mon 8th Aug 2011 22:34 UTC
Bill Shooter of Bul
Member since:
2006-07-14

Min-Kwin the core of KDE 5.0?

According to a new report, there are as many as 6,000 references to Min-KWin in an internal KDE 5.0 repo. This may provide more clues and validation of KDE's Wayland plans for the coming K Desktop Environment release."

Reply Score: 5

...
by Hiev on Tue 9th Aug 2011 00:00 UTC
Hiev
Member since:
2005-09-27

Dear KDE developers.

Please make KDE 5 reliable, I wasn't able to use any version of KDE 4.x, because even 4.7 has memory leaks and consumes 100% of one of my cores.

Take your time, do what you have to do but please, don't let users down, I know you can and I trusth you.

Reply Score: 1

RE: ...
by Elv13 on Tue 9th Aug 2011 01:51 UTC in reply to "..."
Elv13 Member since:
2006-06-12

Please install valgrind and the faulty application debug symbol (and those of glibc, kdelibs and qt). Then run a leak check and report the result. This should be quite straightforward to fix with a proper bug report. You can also use callgrind, part of valgring, to produce the equivalent for the 100% CPU problem.

Bugs with that kind of information usually get fixed quite fast. I submitted a bug to Xorg a few week ago and it was fixed within 24 hour. These bug happen, your probably not the only one, but it does not happen to everybody, so if none of the dev can reproduce it, none of the dev can fix it. But with a complete valgrind memory leak and callgrind output, the problem will be easy to spot.

I know generating that kind of data for a normal user is quite challenging (but quite rewarding too), but you know, it's open source, someone have to do it.

*some application need to be called with --nofork to prevent them from going in the background, this is needed to produce a good valgrind output.

**the valgrind manpage is quite interesting, but to make a long story short --leak-check=yes --track-origins=yes --leak-check=full --show-reachable=yes

***for callgrind --tool=callgrind

Reply Score: 13

RE[2]: ...
by lemur2 on Tue 9th Aug 2011 06:19 UTC in reply to "RE: ..."
lemur2 Member since:
2007-02-17

Please install valgrind and the faulty application debug symbol (and those of glibc, kdelibs and qt). Then run a leak check and report the result. This should be quite straightforward to fix with a proper bug report. You can also use callgrind, part of valgring, to produce the equivalent for the 100% CPU problem. Bugs with that kind of information usually get fixed quite fast.


In order for the OP to do his, there would actually have to be a real bug.

Reply Score: 9

v RE[3]: ...
by sorpigal on Tue 9th Aug 2011 11:40 UTC in reply to "RE[2]: ..."
RE[4]: ...
by Laurence on Tue 9th Aug 2011 11:57 UTC in reply to "RE[3]: ..."
Laurence Member since:
2007-03-26

My anecdotal evidence differs from yours and I use KDE heavily.

I guess the lesson here is no software is perfect (which is obvious to anyone who the slightest idea about IT) and that anecdotal evidence is usually easily contradicted.

Reply Score: 5

RE[5]: ...
by sorpigal on Tue 9th Aug 2011 12:02 UTC in reply to "RE[4]: ..."
sorpigal Member since:
2005-11-02

Anecdotal evidence doesn't contradict anecdotal evidence, that's the problem. It never proves anything.

I'm almost convinced that people who report no problems and who use KDE all the time have simply grown accustomed to deficient behavior. They probably don't experience the worst problems (input locks, computer unresponsive, one finger salute to resolve) but the "minor" annoyances where stuff is awfully slow or excessively memory hungry are shrugged off as normal.

I'm still open to the idea that it depends on your distribution. What distribution are you using? I base 100% of my experience off of the Debian packaged version of KDE.

Reply Score: 1

RE[6]: ...
by Bill Shooter of Bul on Tue 9th Aug 2011 14:55 UTC in reply to "RE[5]: ..."
Bill Shooter of Bul Member since:
2006-07-14

I'm telling you, I've been running kde 4 series for two years at work, home, and on the go. I've experimented with Gnome, lxde, x-monad, awesomewm, xfce, fluxbox, openstep. KDE with (Kwin with graphical effects off), is as fast as any of them on my modest hardware.

Kwin's composite renderer seems to have various issues with *one* of my graphics cards that has caused it to crash and run slow as dirt, but I'm hoping 4.7 will fix that. Ironically, it happens with my most powerful graphics card that works great under gnome3 and/or compiz.

Reply Score: 3

RE[7]: ...
by Hiev on Tue 9th Aug 2011 15:20 UTC in reply to "RE[6]: ..."
Hiev Member since:
2005-09-27

I've installed different distros in 3 kind of laptops and one desktop computer with the same bad luck with different video cards, with open and propietary drivers, KWin slowdowns, KNotify using 100% CPU, and other glitches, and I know im not alone here, that's why I'd like to se a reliable version of KDE.

Give me your recommendation, what distro should I try?

Edited 2011-08-09 15:22 UTC

Reply Score: 1

RE[7]: ...
by sorpigal on Tue 9th Aug 2011 16:11 UTC in reply to "RE[6]: ..."
sorpigal Member since:
2005-11-02

And I can tell you that what's kept me from being a KDE user is that I can't keep the system up and responsive for more than a couple of days at a time. This has been true for every release of KDE4 since 4.1, which is when I started experimenting with switching. I can say for sure that just using KDE applications is enough to bog my system down enormously.

I'm glad KDE works so satisfactorily for you, but it certainly is not the smooth and trouble-free experience you describe.

Reply Score: 2

v RE[7]: ...
by pepper on Tue 9th Aug 2011 21:14 UTC in reply to "RE[6]: ..."
RE[6]: ...
by lemur2 on Tue 9th Aug 2011 23:56 UTC in reply to "RE[5]: ..."
lemur2 Member since:
2007-02-17

Anecdotal evidence doesn't contradict anecdotal evidence, that's the problem. It never proves anything. I'm almost convinced that people who report no problems and who use KDE all the time have simply grown accustomed to deficient behavior. They probably don't experience the worst problems (input locks, computer unresponsive, one finger salute to resolve) but the "minor" annoyances where stuff is awfully slow or excessively memory hungry are shrugged off as normal. I'm still open to the idea that it depends on your distribution. What distribution are you using? I base 100% of my experience off of the Debian packaged version of KDE.


I have to date been extremely disappointed with Debian versions of KDE. It seems to me to be one of the most problematical.

PCLinuxOS ... rolling release, well tested before it is released, fairly large selection of packages, 32-bit only.

OpenSuse ... reportedly a great KDE distribution, but not a rolling release. This one probably gets the most recommendations.

Mandriva ... a very good solution normally, vastly under-rated. Also not a rolling release.

MEPIS ... based on Debian, but fixed somehow. A very stable distribution, but don't expect the most recent levels of performance or function.

Arch ... a cutting-edge rolling release which still manages somehow to be pretty stable and reliable. Not recommended for newbies, it doesn't do any hand-holding. No GUI package management solution for KDE.

Chakra ... Based on Arch, also rolling-release, but with more GUI help, perhaps a better option for newbies than Arch itself. Repositories are far fewer.

Slackware ... I haven't used it, but reportedly it is a good option for KDE. Not cutting edge. Package management would be the weak point.

Kubuntu ... it seems to attract a lot of heat, but I haven't had too much trouble with it. Avoid version 10.10 (KDE 4.5), disable strigi and nepomuk.

All I can say is that I keep hearing many stories of KDE problems that I have never encountered myself. KDE is never slow or lacking in performance for me.

My recommendation: avoid proprietary graphics binary blob drivers, or ones based on reverse engineering, or running Linux at all on systems using the Intel GMA500.

Edited 2011-08-10 00:05 UTC

Reply Score: 3

RE[6]: ...
by Laurence on Wed 10th Aug 2011 07:44 UTC in reply to "RE[5]: ..."
Laurence Member since:
2007-03-26


I'm almost convinced that people who report no problems and who use KDE all the time have simply grown accustomed to deficient behavior. They probably don't experience the worst problems (input locks, computer unresponsive, one finger salute to resolve) but the "minor" annoyances where stuff is awfully slow or excessively memory hungry are shrugged off as normal.

I promise you I don't suffer from those.
I wont deny there are occasional bugs (usually momentary rendering glitches that most compositing WMs can suffer from).

I will also admit that KDE4 is one of the most memory hungry DEs, but then you get a lot more bang for your buck. Some might call that bloated, however as I use much of those features so it's not bloat for me. But then if you really want a low-resource DE then KDE isn't designed for you in the 1st place, thus you're expectations are unreasonable (there's LXDE, XFCE and a whole host of other DEs and tiling WMs that better suit those needs).


I'm still open to the idea that it depends on your distribution. What distribution are you using? I base 100% of my experience off of the Debian packaged version of KDE.

I'm using ArchLinux 64bit.
I've tried Ubuntu's KDE4 distro (albeit quite a while ago now) and that was awful. I've heard Kubuntu has progressed significantly since but if my experiences of the two are any gauge, then I'd suggest maybe the you're right in regards to how KDE might perform differently on different distributions.

If ArchLinux's install is too labored for you to test KDE4 (which I could understand), then perhaps give Chakra a go ( http://chakra-project.org/ ) as that's a live distribution based around KDEmod on ArchLinux.

Reply Score: 4

RE[3]: ...
by Elv13 on Tue 9th Aug 2011 19:41 UTC in reply to "RE[2]: ..."
Elv13 Member since:
2006-06-12

(replay for both side)

Please don't troll, I am a dev (not a kdebase dev, I spend my time on "extragear" apps and some KDE SC apps) and I see those happening too, they exist.

There is many possible explanation why do these bug happen:
-Linux: Some of the Linux Kernel component have huge performance penality for I/O intensive application. Linus Torvald himself have one of these computer. We are not talking about niche here, but EMT64 and AMD64 computer with a bunch of chipset combinations. Apparently, it's not even driver bug. It slow down under certain workflow (mostly i/o), and nobody know why.

-packaging: This is a bad issues. Kubuntu already made us a bad reputation with KDE4.0. About half of the crash were due to mispackaged libraries. If a symbol is not found, the application will crash. If a two packages are not at the same version compile in the same circumstances, they may behave somehow differently (infinite loop, 100% CPU). If package A is compiled against library C and then used with library B instead of C because C was not packaged while B was, it may not work. Note that in this example, B and C are the -same- libraries, but compiled in different circumstances.

-dodgy patching: Remember the distribution have the final say when it come to the code that get compiled. If they apply a patch on code that do many things to fix one of these thing, who know the side effect it will have on the other use case. Even in good will, adding patch without having the complete understanding of the side effect it will have can be very damaging to to the well behaving of the application.

-driver and X: When talking about KWin, this is a big issue. Many drivers are in a terrible state and "provide" feature they don't actually have. While in some case, the code path is just so terribly unoptimized it will molasses the whole thing. The KWin developers are aware of this and trying hard to fix it, even if they need to troll upstream. KDE 4.0 was not working on NVIDIA, you could not move a plasmoid without X crashing or freezing for an extensive period of time. That was because one of the compositing extension was software emulated. It eventually got fixed because NVIDIA took the time to make KDE4 work fine. To this day, it still the best driver for KDE because it was actually TESTED with the OpenGL feature KDE use. We have not created OpenGL, driver claim to support it (2.* for Mesa and 3.3-4.1 for prop drivers). So complaining that KDE is slow because the driver do not work is frustrating. That said, writing a driver, especially from video dump is incredibly hard.

-options: As everybody know, KDE have a lot of options. Nothing new there. There is even more than in KDE3. So if every option is a boolean one (on or off), and KDE have, let say, 500 000 options that can randomly be set in any possible combination. That would make 2^(500k) possibilities. So 2^(500k) different code path. Having flexibility have a cost, and this is it. There is no way more than 95% of these combination can work flawlessly. There will be some issues, bug report are welcome.

-cosmic ray, dark magic, unicorns, -assumptions-: Those and many more

_____

Saying that KDE4 is perfect is wrong. Blaming the dev for every bugs is also wrong. I can understand that, as users, you need to blame someone and the devs are the most obvious targets. After all, even I can't tell if I face a real bug or if my build system / Gentoo is just misconfigured/outdated. But trolling for the sake of trolling hurt more. Do you really thing anyone love to be blamed for something he is not responsible for? How do you expect you will always have a nice, clean and gentle reply from him/her, everybody is not aseigo ;) .

Reply Score: 5

RE[2]: ...
by saynte on Tue 9th Aug 2011 08:11 UTC in reply to "RE: ..."
saynte Member since:
2007-12-10

This is a great little rundown on how to help the devs, thanks for posting it!

I would also note though, if the bug is intermittent/hard to replicate, the valgrind route is pretty tough, due to the performance hit it requires on the running application. A bit like treading through molasses to find that need in a haystack ;) .

Reply Score: 2

RE: ...
by kolmyo on Tue 9th Aug 2011 09:58 UTC in reply to "..."
kolmyo Member since:
2005-07-11

Dear KDE developers.

Please make KDE 5 reliable, I wasn't able to use any version of KDE 4.x, because even 4.7 has memory leaks and consumes 100% of one of my cores.

Take your time, do what you have to do but please, don't let users down, I know you can and I trusth you.


Dear Hiev.

Please buy a working computer and stop flaming every single KDE news item.

Reply Score: 10

RE[2]: ...
by Hiev on Tue 9th Aug 2011 13:57 UTC in reply to "RE: ..."
Hiev Member since:
2005-09-27

I did that, same results.

Reply Score: 1

RE[3]: ...
by turrini on Tue 9th Aug 2011 22:46 UTC in reply to "RE[2]: ..."
turrini Member since:
2006-10-31

Maybe you should turn your computer upside down.

Reply Score: 1

Wayland.
by spiderman on Tue 9th Aug 2011 06:42 UTC
spiderman
Member since:
2008-10-23

Can someone please explain to me what is the advantage of Wayland?

Reply Score: 2

RE: Wayland.
by tuma324 on Tue 9th Aug 2011 07:18 UTC in reply to "Wayland."
tuma324 Member since:
2010-04-09

Can someone please explain to me what is the advantage of Wayland?


A clean code base and API for one thing. Also, Wayland allows clients to control the rendering themselves that we'll never see tearing, lag, redrawing or flicker.

It will feel a lot faster than X, since all the X overhead and cruft will be gone. Think of it like a small, next-generation and very slick graphics stack.

Edited 2011-08-09 07:28 UTC

Reply Score: 1

RE[2]: Wayland.
by spiderman on Tue 9th Aug 2011 11:04 UTC in reply to "RE: Wayland."
spiderman Member since:
2008-10-23

Thank you, that was the information I was looking for.

Reply Score: 2

RE[3]: Wayland.
by Neolander on Tue 9th Aug 2011 11:14 UTC in reply to "RE[2]: Wayland."
Neolander Member since:
2010-03-08

For more information, you might want to have a look at this : http://www.phoronix.com/scan.php?page=article&item=linuxtag_2011_wa...

Reply Score: 1

RE: Wayland.
by renox on Tue 9th Aug 2011 08:53 UTC in reply to "Wayland."
renox Member since:
2005-07-06

Can someone please explain to me what is the advantage of Wayland?


Well,
1) you will loose the network transparency by default of X, there will probably be replacementS but they will be incompatible and buggy at the beginning.
2) New code --> new bugs
3) currently Wayland developers seems to prefer that a program manage totally how it displays itself, so if you have a stuck application, you won't be able to killl/iconify the window.

So as you can see Wayland is much better than an evolution of X which would remove unused features and add an option to share GPU's memory!

Reply Score: 7

RE[2]: Wayland.
by _txf_ on Tue 9th Aug 2011 08:59 UTC in reply to "RE: Wayland."
_txf_ Member since:
2008-03-17

3) currently Wayland developers seems to prefer that a program manage totally how it displays itself, so if you have a stuck application, you won't be able to killl/iconify the window.


Isn't that the job of the window manager and compositor under waylaid?

Edited 2011-08-09 09:00 UTC

Reply Score: 2

RE[3]: Wayland.
by terrakotta on Tue 9th Aug 2011 10:54 UTC in reply to "RE[2]: Wayland."
terrakotta Member since:
2010-04-21

Wayland devs have already indicated that they prefer client side decorations, something the kwin devs do not like at all and hope to counter. Nevertheless it seems to be the only objection the kwin devs have against Wayland. Network transparancy can still be achieved if necessary, but the future will show if the X-type-of-network-transparancy is required to have a good functional system.

Reply Score: 1

RE[2]: Wayland.
by spiderman on Tue 9th Aug 2011 11:36 UTC in reply to "RE: Wayland."
spiderman Member since:
2008-10-23

Indeed, those are valid concerns.
I have my own worries too.
I understand now why they are doing Wayland. There are some problems with Xorg. I was always frustrated by the lack of vsync to vblank for one thing. I understand that they want to do something about that.
My fear is that they may through the baby with the water.
Xorg is already dumping a lot of useful things by trying to improve. They dropped XEVIE because xtst and xrecord provided similar functions. Then they broke xrecord. I understand it's hard to maintain such a big project and shit happens but it's frustrating. My project depended on xevie and then xrecord. It makes my project harder to maintain and I spend more time trying to keep up with the deprecation of the underlying technologies than improving the project with new functions.
In an ideal world, people using bleeding edge software would expect the shit and don't complain while the mass would use stable and working software. The bleeding edge users would help us while the software matures. In reality, the mass uses bleeding edge software and they complain that it sucks.
My fear is that wayland will be pushed to soon to the hand of clueless users. Wayland should be an experiment first for tinkerers to play with and see if it is worth to drop xorg for it.
I hope they will give it time. I will certainly look at it and see what can be done for my software to work with it once I'm done fixing it for GNOME 3 and the new at-spi over dbus.

Reply Score: 2

RE[2]: Wayland.
by oiaohm on Tue 9th Aug 2011 13:01 UTC in reply to "RE: Wayland."
oiaohm Member since:
2009-05-30

"Can someone please explain to me what is the advantage of Wayland?


Well,
1) you will loose the network transparency by default of X, there will probably be replacementS but they will be incompatible and buggy at the beginning.
"
This does not work with X11 currently when using heavy Opengl applications anyhow.

Other methods like VNC still work with Wayland.
2) New code --> new bugs

In fact newer X11 servers have more new code than Wayland. So odds of bad new bugs are on the X11 side.
3) currently Wayland developers seems to prefer that a program manage totally how it displays itself, so if you have a stuck application, you won't be able to killl/iconify the window.

In fact this is a full lie.
Wayland applications render to a buffer Wayland compositor decides if that ever sees the light of day. Yes application in wayland make be completely in the dark if it displayed at all.

Wayland gets rid of the divide between windows manager and compositor.

So as you can see Wayland is much better than an evolution of X which would remove unused features and add an option to share GPU's memory!

In fact what you have just stated is what the Wayland project is. X11 stripped of all old features with GPU memory sharing. That is wayland.

Reply Score: 3

RE[3]: Wayland.
by renox on Tue 9th Aug 2011 13:59 UTC in reply to "RE[2]: Wayland."
renox Member since:
2005-07-06

[Network transparency]This does not work with X11 currently when using heavy Opengl applications anyhow
So? Network transparency doesn't work for 1% of applications (mostly games) then this means that network transparency is useless?

Other methods like VNC still work with Wayland.
Eventually yes, but it's quite likely that at the beginning it won't work as well as what we have currently with X: note that this "stabilisation" time can be *very* long.

In fact newer X11 servers have more new code than Wayland. So odds of bad new bugs are on the X11 side.
Uh? Wayland + the toolkits adaptations are both new and they will do exactly the same thing as the Xserver + the toolkits do currently so I find that difficult to believe.

"3) currently Wayland developers seems to prefer that a program manage totally how it displays itself, so if you have a stuck application, you won't be able to killl/iconify the window.

In fact this is a full lie.
"Instead of calling me a liar, you should better read the Wayland mailing list, see http://lists.freedesktop.org/archives/wayland-devel/2011-May/000988... for example.

Kristian Høgsberg is "only" the *main* Wayland developer, and he is pushing for client-side decorations in Wayland, which means that when you click on a 'close' decoration, it is up to the application to treat the close request, so if the application is stuck, you need a workaround "a la Windows".
Of course this is only what Wayland would provide by default, KDE on Wayland could change this (by implementing their own window manager).

In fact what you have just stated is what the Wayland project is. X11 stripped of all old features with GPU memory sharing. That is wayland.
These "old" features includes: network transparency, server side window management and compatibility with the existing software: all these "old" features must be added on top of Wayland (and each toolkit will do it differently), which makes nearly sure that these "old" features will be quite fragile, that's what I don't like in Wayland.

Reply Score: 4

RE[4]: Wayland.
by _txf_ on Tue 9th Aug 2011 14:22 UTC in reply to "RE[3]: Wayland."
_txf_ Member since:
2008-03-17

These "old" features includes: network transparency, server side window management and compatibility with the existing software: all these "old" features must be added on top of Wayland (and each toolkit will do it differently), which makes nearly sure that these "old" features will be quite fragile, that's what I don't like in Wayland.


Certainly features such as network transparency are useful. But X is getting far too crufty and incapable in the modern world. You cannot get dynamic gpu switching because of X and it is notoriously hard to maintain and its codebase is supposedly utterly hostile to newcomers.

Personally I don't really mind if X stuck around, but in modernizing it would take the same or more effort than starting from scratch.

Reply Score: 5

RE[5]: Wayland.
by renox on Tue 9th Aug 2011 14:41 UTC in reply to "RE[4]: Wayland."
renox Member since:
2005-07-06

You cannot get dynamic gpu switching because of X
Because of X specification or because of current X's implementation?
That's a big difference..

and it is notoriously hard to maintain and its codebase is supposedly utterly hostile to newcomers.
I'm not sure that Wayland will be much more simple here, for example input management must still be done and I don't see why it would be simpler in Wayland than in X.

Personally I don't really mind if X stuck around, but in modernizing it would take the same or more effort than starting from scratch.
I don't know.. One puzzling thing is that there were already some modernization of X done such as XCB but the toolkits are still using XLib??

Reply Score: 3

RE[6]: Wayland.
by _txf_ on Tue 9th Aug 2011 19:03 UTC in reply to "RE[5]: Wayland."
_txf_ Member since:
2008-03-17

Because of X specification or because of current X's implementation?
That's a big difference..


At this point I think that changing the implementation would require major surgery inside X

I'm not sure that Wayland will be much more simple here, for example input management must still be done and I don't see why it would be simpler in Wayland than in X.

I'm sure that even to develop for waylaid will require a rather specific skill set. However, so many parts of X are so ancient that modifying them requires being able to understand something that has been around for decades.

TBH X protocol isn't the best solution these days. I find RDP more usable (especially under high latency connections) than running remote X. Also Due to the nature of some toolkits running remote X programs is really slow.

Reply Score: 2

RE[7]: Wayland.
by spiderman on Tue 9th Aug 2011 21:38 UTC in reply to "RE[6]: Wayland."
spiderman Member since:
2008-10-23

You should try FreeNX. It's really fast. RDP is nice but there are some limitations that does not make it a replacement for X. It only runs a full desktop. You can't run an app over RDP. Citrix is the only option for remote apps on Windows and it costs money. I hope the Wayland devs don't forget that some of X features are really used, even if they don't use it themselves. Accessibility comes to mind when thinking about things that are easily dismissed and forgotten on new systems.

Reply Score: 3

RE[7]: Wayland.
by renox on Wed 10th Aug 2011 07:54 UTC in reply to "RE[6]: Wayland."
renox Member since:
2005-07-06

At this point I think that changing the implementation would require major surgery inside X

So? That's just because "dynamic gpu switching" is a feature *much more recent* than current X implementation, I don't understand why this is a criticism against X: if Wayland had been implemented before the "dynamic gpu switching" feature, it's quite likely that it would have required major surgery too!

TBH X protocol isn't the best solution these days. I find RDP more usable (especially under high latency connections)
X is for LAN not high latency connections, there are some "add-on" such as NX which are better for high latency connections, I agree with you that this isn't a good situation: NX should be merged in X so that by default you can have a good remote connection both for LAN and WAN.

Also Due to the nature of some toolkits running remote X programs is really slow.
Well, given that Wayland don't provide network transparency, it will be up to the toolkit to implement it, and as you say some toolkits don't work well with X for remote display, so I'm not optimistic that the situation will be better when the toolkit itself will implement the remoting!

Reply Score: 2

Comment by fran
by fran on Tue 9th Aug 2011 12:25 UTC
fran
Member since:
2010-08-06

They have a very vibrant community

Reply Score: 3

...
by Hiev on Tue 9th Aug 2011 17:06 UTC
Hiev
Member since:
2005-09-27

No, No, I like to use it as it come as default, I don't tweak anything at all, I'll try with Mandriva.

Edit:
I see Mandriva 2011 will be released in 19 days, I'll waith.

Edited 2011-08-09 17:15 UTC

Reply Score: 2

RE: ...
by spiderman on Tue 9th Aug 2011 18:52 UTC in reply to "..."
spiderman Member since:
2008-10-23

I suggested Mandriva because they have developers working on KDE, their primary desktop is KDE and I have first hand experience with it. Their KDE implementation is better than on Debian based distros (whose primary desktop is GNOME)
However, I can not recommend Mandriva 2011 because I did not try it, because it's not released yet. I can only guess they will have a good KDE implementation based on their previous releases but it's only a guess.

Reply Score: 2

Remoting
by vivainio on Wed 10th Aug 2011 21:43 UTC
vivainio
Member since:
2008-12-26

For those missing remote X sessions: you can get the same thing by running X server as client on wayland, problem solved. No need to discuss the issue of network transparency.

Reply Score: 3

RE: Remoting
by _txf_ on Thu 11th Aug 2011 08:29 UTC in reply to "Remoting"
_txf_ Member since:
2008-03-17

For those missing remote X sessions: you can get the same thing by running X server as client on wayland, problem solved. No need to discuss the issue of network transparency.


Pretty much the same way OSX uses X then...

P.S It works quite well

Reply Score: 3