KDE Does Its Second 4.7 Release Candidate

[mugginz]

TB contains hacks to be compatible with ?GMail IMAP?.

Then that would demonstrate that the Thunderbird team is prepared to code programs for they way the world is, and not for the way they wish the world was. That my friend is the mark of a pragmatic, and professional team.

[mugginz]

Could you please get your arguments straight? Your drivers cause performance regressions, so the argument you're forced to use the buggy binary drivers for performance reasons is bogus.

I might just respond to this with a bit more clarity.

You firstly edited my statement to look like this.

And when KWin performs badly with the drivers I have
(...)
And for those who don't need the most OpenGL performance available, the FLOSS drivers are a good bet.

The following more accurately depicts the context of my statements.

KWin's composite back-ends are all newer than Compiz and for that very reason they are written using more modern OpenGL features.

And when KWin performs badly with the drivers I have, as apposed to the drivers I want, I switch to Compiz.

That is to say that if I'm running on a platform upon which KWin isn't happy from a performance standpoint, I'm prepared to switch to an alternative and better performing compositor.


Further, my statement " with the drivers I have, as apposed to the drivers I want" reflects that I can only use the software that's available to me. I can't cast a magical incantation along the lines of "abra cadabra, make these drivers work." and be bestowed with next years better working drivers, I have to use the ones that are available for use.

I regularly use two systems: A laptop with GeForce 9200M and a desktop PC with a really low-end Radeon HD card.
I forgot tomention one thing: On the laptop I have to disable the KWin blur effect because the driver misbehaves and causes Xorg to eat away all CPU.
On the desktop PC I simply use the FOSS drivers. They work fine. Even blur.

And for those who don't need the most OpenGL performance available, the FLOSS drivers are a good bet. Not everyone has that option. Also, last time I checked the FLOSS drivers didn't support triple head on an AMD card but that may of changed recently.

I was responding to a comment that if I was having issues with KDE's KWin and a binary blob, why not just switch to a FLOSS driver. For various reasons I can't.

So...

When faced with the choice of dumping a desktop environment completely, dumping the hardware under the environment, or dumping just one part of the environment (the compositor) I have in the past simply dumped the compositor.

[kayosiii]

So if I deliver a desktop environment, and in testing I notice issues that I want to blame on a sub system, shouldn't I code around those? When other environments demonstrate that it's possible to deliver an operational result on a given platform there are valid questions to be directed to the KDE team.

That is the question at the core of this and there isn't really an easy answer to this. Many of these are bugs that really should be fixed at the driver level you can code around them but....
You may get regressions when the problems are fixed or worse problems may not get fixed for fear of breaking downstream workarounds. You make your codebase considerably more complex and less understandable and less maintainable. Not working around puts pressure on downstream projects to fix their issues.
One approach is clearly better in the short term one is clearly better in the long term. Which one do you choose.

Part of the problem is that both the kwin and mesa teams suffer lack of manpower and there are enough truly shit pieces of hardware out there. Part of the problem is that these teams may not actually have access to your hardware to test on.

[mugginz]

That is the question at the core of this and there isn't really an easy answer to this. Many of these are bugs that really should be fixed at the driver level you can code around them but....
You may get regressions when the problems are fixed or worse problems may not get fixed for fear of breaking downstream workarounds. You make your codebase considerably more complex and less understandable and less maintainable. Not working around puts pressure on downstream projects to fix their issues.
One approach is clearly better in the short term one is clearly better in the long term. Which one do you choose.

Indeed.

When there's an alternative desktop for the underlying platform, it can provide an option for some who don't wish to jump shit all together onto another OS altogether, but who simply want respite from bugs that make the day to day experience too much to bear. In this situation, instead of my going Windows, I switched to Gnome.

However, Microsoft took the messy road that you describe above. Creating a mess of compatibility shims in an effort to maintain a usable desktop for their customers. But that approach has provided many with a dependable desktop for prolonged periods of time. It may not be great from a purity standpoint, but it provides the users an environment on which they can depend.

When using Linux as a desktop in a home environment, perhaps say as an experiment, or as a full time desktop but with a use case that doesn't have demanding time lines for the finishing of tasks, it can be an option to deal with periods of instability.

When using Linux in an environment where there are time pressures for the accomplishment of tasks, having an environment that you can rely on is critical. I get the feeling that the Gnome team has perhaps focused on providing a reliable and dependable environment in which to get work done, and the KDE team have been prepared to be more experimental. Pushing for more fancy features at the expense of spending time on the more mundane stability work.

There are those who dismiss the Linux desktop as a viable platform because of a reputation for things that are working for a moment to be broken by a software update. This can happen at the kernel level, infrastructure level, and higher levels in the desktop environment and application layer.

The trouble is some people just can't have their machine working one day and not the next. Of course no OS is completely immune from the effects of an update breaking some functionality. Some OSes are more prone to this than others. But more that just a simple breakage due to one time update, I found that the KDE desktop suffered from issues for a prolonged period of time.

Functionality should only be pushed into the release product when ready. The KDE guys seems far too prepared to replace old functionality with new and in the process introduce breakage.

Ultimately, when breakage is introduced, or a level of breakages seems to be maintained over a prolonged period of time, it can then become time to look at the alternatives.

Part of the problem is that both the kwin and mesa teams suffer lack of manpower and there are enough truly shit pieces of hardware out there. Part of the problem is that these teams may not actually have access to your hardware to test on.

And while that may explain the reasons for some of the system behavior, ultimately a user of that system is left to deal with the results of the design decisions made by the various teams. If there are more reliable places to go, people will look to go there. Of course I don't support mean spirited demands of the various projects. After all, there's an awful lot of volunteer work going on there. If you pay Microsoft for Windows and it has breakage, I can support those who scream at Microsoft. If there's breakage on the Linux desktop, I think it's fair to discuss from a user point of view the suitability of a software project for a given task, but I wouldn't make demands though.

I found KDE to have too much breakage for me, so I moved to an alternative desktop while staying with Linux. I'm very glad I didn't need to go with Windows. Though I will say Windows 7 has addressed a range of issues I've had with the Windows platform in general, so if I had to use it it'd be less painful for me than it would've been years ago.

The reasons for breakage is an interesting conversation to have, but it's also valid to have one about what one does when they're faced with that breakage. ie: Moving to greener pastures.

[kayosiii]

I use KDE in a work situation with deadlines. I use it because it has the best feature set of any desktop I have used (unless you concider third party software in which case both Windows and MacOS beat it). I can't really afford to have my work computer not working.

There are two things I do to ensure I have a reliable system.
1) I buy hardware that is known to work well with KDE/Linux where-ever possible. If hardware gives me troubles I sell it/Replace it. I have lost some money doing things this way but less than I would have in lost wages.
2) I always have two OS installs at any one time. When It comes time to upgrade I wipe the older of my two systems and do a fresh install. This leaves me at my leisure to set things up as I need them and should anything really bad happen I just revert to my known good system.

The issues I have had in the last few years had include.

KDE 4.5 had issues with Dolphin,nVidia and the Oxygen Style I temporarily switched to QtCurve to get around that one.

My graphics card overheated seriously killing my mainboard (16 hour day, large Scene, Unigine, Deadline). After determining that the Mainboard was cooked, I transfered the hdd to another workstations and after updating the graphics drivers was good to go.

A Qt Bug caused KDevelop to crash all the time. This forced me to revert to my old system (from maverick back to lucid until natty was released).
(that's all I can think of).

I would like to see a lot more people having a good experience with KDE. I find it better for getting work done than anything else I have used. I also like Gnome2 (haven't tried Gnome3, Unity) and enlightenment.

[mugginz]

I use KDE in a work situation with deadlines. I use it because it has the best feature set of any desktop I have used (unless you concider third party software in which case both Windows and MacOS beat it). I can't really afford to have my work computer not working.

I'd agree with you that KDE has the feature set that I most prefer out of the available choices.

There are two things I do to ensure I have a reliable system.
1) I buy hardware that is known to work well with KDE/Linux where-ever possible. If hardware gives me troubles I sell it/Replace it. I have lost some money doing things this way but less than I would have in lost wages.

2) I always have two OS installs at any one time. When It comes time to upgrade I wipe the older of my two systems and do a fresh install. This leaves me at my leisure to set things up as I need them and should anything really bad happen I just revert to my known good system.

The issues I have had in the last few years had include.

KDE 4.5 had issues with Dolphin,nVidia and the Oxygen Style I temporarily switched to QtCurve to get around that one.

My graphics card overheated seriously killing my mainboard (16 hour day, large Scene, Unigine, Deadline). After determining that the Mainboard was cooked, I transfered the hdd to another workstations and after updating the graphics drivers was good to go.

A Qt Bug caused KDevelop to crash all the time. This forced me to revert to my old system (from maverick back to lucid until natty was released).
(that's all I can think of).

I would like to see a lot more people having a good experience with KDE. I find it better for getting work done than anything else I have used. I also like Gnome2 (haven't tried Gnome3, Unity) and enlightenment.

You mention Maverick, Lucid and Natty so I assume you're running Kubuntu. If that's the case don't be surprised if someone pipes up here and tells you you're running the wrong distro

I had issues with printing, I found the bluetooth subsystem to be buggy for a while, KDE's Network Manager GUI was problematic for me at times, various issues with viewing some PDF's using the native tools but it was straight forward to install alternatives, Dolphin could be a bit crashy early on, had various quirky behavior with regards to the KDE main tool bars positioning at various stages, Plamsa suffered from varying levels of stability, but at least when it'd crash it'd also autostart but leave my apps open, Kmail was less than perfect, Kontacts scheduler was good except for when using meeting times setup from a different time zone than the one I was in, it'd mis-convert the times when trying to display the meeting relative to my time zone.

Some of the rendering glitches I put down to driver/X.org, some of the issues didn't feel like sub-system fail but others have suggested they were. Regardless, I had one crash too often during a moment while under time pressure so switched. I always have standby gear available if required, so if a system update toasted an install I could jump to a different machine, but that's not a great work around for when you're operating on a dataset local to a particular machine, perhaps with various packages in varying levels of context for the job at hand at the moment and an issue arises. It's a bit inconvenient to say the least. I'd certainly not perform updates during a time of time pressure or when I've got some "balls in the air" so update breakage would be something a second machine would mitigate for, at least to some degree.

[Awesomeness]

So if I deliver a desktop environment, and in testing I notice issues that I want to blame on a sub system, shouldn't I code around those?

No, never. The foundation needs to be fixed, especially if (like in this case) the foundation is developed by multi-billion dollar companies that have the resources to fix whatever they want. They just don't want to.
We pay them. They are obligated to us to properly support their products.

Then that would demonstrate that the Thunderbird team is prepared to code programs for they way the world is, and not for the way they wish the world was. That my friend is the mark of a pragmatic, and professional team.

Haha. Whenever someone has no proper arguments, he plays the ?pragmatism? card. By your definition of ?pragmatism? we all should just use Windows and Internet Explorer because the world is that it targets those.
GMail is the Internet Explorer 6 of mail services. It's broken by design.
And no, GMail has no >50% market share. In your dreams maybe but not in reality. The majority of the e-mail world is compliant to IMAP. KMail works with the actual IMAP standard just fine.

[mugginz]

No, never. The foundation needs to be fixed, especially if (like in this case) the foundation is developed by multi-billion dollar companies that have the resources to fix whatever they want. They just don't want to.
We pay them. They are obligated to us to properly support their products.

When the alternative (Gnome) desktop can run happily on the same infrastructure it calls into question KDE's ability to craft a platform on top that is robust.

Also, to categorically state that it's never appropriate to code around lower levels is a nice position to take from a puritan perspective, but it also ignores some realities.

Additionally, I don't accept that all of the problems presented to me by the KDE desktop were all due to infrastructure.

Haha. Whenever someone has no proper arguments, he plays the “pragmatism” card.

That's absolutely rubbish.

Only when you live in a fantasy world can you be free to ignore the real world as it is, and pretend to live in a perfect world which of course we don't.

By your definition of “pragmatism” we all should just use Windows and Internet Explorer because the world is that it targets those.

Well actually that statement you make there has some merit. If the only truely reliable platform available is the Microsoft Windows one, it would make a lot of sense to switch to it when reliability is a priority. Luckily I found Gnome to be reliable so I didn't need to switch to Windows. If I couldn't find a Linux desktop that was reliable, I'd of indeed switched to Windows.

GMail is the Internet Explorer 6 of mail services. It's broken by design.

Yet I find it to be most reliable both via a web interface, and also via good old Thunderbird. Thunderbird does run happily on a KDE desktop luckily, though you do miss out on the integration that Kmail promises the user.

And no, GMail has no >50% market share. In your dreams maybe but not in reality. The majority of the e-mail world is compliant to IMAP. KMail works with the actual IMAP standard just fine.

I didn't mention anything about the market penetration of Gmail. I'm not sure why you seem to be attributing that issue to anything I've said. I find it useful and functional, and any mail client I use on a day to day basis needs to be able to interoperate with it.

And Gmail provides an IMAP interface.

Also your view of Kmail's interoperability with IMAP and mine are obviously different.

[kayosiii]

I'd agree with you that KDE has the feature set that I most prefer out of the available choices.

You mention Maverick, Lucid and Natty so I assume you're running Kubuntu. If that's the case don't be surprised if someone pipes up here and tells you you're running the wrong distro

Yeah I am sure if I did have some problems an Arch Nut or similiar would say just that.

I did try Arch at one point out of curiousity but I found that Kubuntu despite what everybody else says worked best for me. I however reconise that parts of kubuntu which aren't parts of kde proper do tend to suck (package manager, formerly network manager) and they do tend a bit too much towards the bleeding edge for many peoples taste.

I had issues with printing, I found the bluetooth subsystem to be buggy for a while, KDE's Network Manager GUI was problematic for me at times, various issues with viewing some PDF's using the native tools but it was straight forward to install alternatives, Dolphin could be a bit crashy early on, had various quirky behavior with regards to the KDE main tool bars positioning at various stages, Plamsa suffered from varying levels of stability, but at least when it'd crash it'd also autostart but leave my apps open, Kmail was less than perfect, Kontacts scheduler was good except for when using meeting times setup from a different time zone than the one I was in, it'd mis-convert the times when trying to display the meeting relative to my time zone.

I see it seems that I have dodged quite a few bullets. That's quite a list. I do remember some of those issues but a long time ago. I don't own a printer - I go to a printer as I don't really like the longetivity of inkjet prints and it's not that much more expensive. I only got a bluetooth device a few months ago.

Some of the rendering glitches I put down to driver/X.org, some of the issues didn't feel like sub-system fail but others have suggested they were. Regardless, I had one crash too often during a moment while under time pressure so switched. I always have standby gear available if required, so if a system update toasted an install I could jump to a different machine, but that's not a great work around for when you're operating on a dataset local to a particular machine

I run most of my systems with external hdds and esata so I can move data quickly between machines if I need to. I also put my home and system folders on seperate drives so if really necessary I can mount my home folder on a known good system and have my data accessible. I sometimes use this to transport my system between home and work.

perhaps with various packages in varying levels of context for the job at hand at the moment and an issue arises. It's a bit inconvenient to say the least. I'd certainly not perform updates during a time of time pressure or when I've got some "balls in the air" so update breakage would be something a second machine would mitigate for, at least to some degree.

Yeah I tend to not do big updates the same week I have a deadline as a general rule. I think Kubuntu can be configured to only check for critical bugfixes, security updates. One of the unfortunate things about Ubuntu is they are sometimes quite happy to push through an update that breaks KDE without checking first.

[mugginz]

I run most of my systems with external hdds and esata so I can move data quickly between machines if I need to. I also put my home and system folders on seperate drives so if really necessary I can mount my home folder on a known good system and have my data accessible. I sometimes use this to transport my system between home and work.

I think there's quite a bit of value there with the esata connected drive so as to be able to be more fleet of foot when the need arises.

I'm considering a hot swap bay for this machine which would essentially achive a way of quickly moving my root volume to where ever I may need to take it. I also run a raid 0 array for my bulk storage and I like the thought of being able to perform drive replacement of the fly.