Trinity Desktop Environment R14.0.0 Released

[Posted December 16, 2014 by ris]

The Trinity Desktop Environment (TDE) development team has announced the release of TDE R14.0.0. "Unlike previous releases TDE R14.0.0 has been in development for over two years. This extended development period has allowed us to create a better, more stable and more feature-rich product than previous TDE releases. R14 is brimming with new features, such as a new hardware manager based on udev (HAL is no longer required), full network-manager 0.9 support, a brand new compositor (compton), built-in threading support, and much more!"

(Log in to post comments)

Posted Dec 17, 2014 3:51 UTC (Wed) by aryonoco (guest, #55563) [Link]

Are they still using Qt 3?

If yes, since Digia doesn't support Qt 3 anymore, are they patching it themselves? Or is it just unmaintained with security holes and whatnot?

There is a part of me that likes this project to succeed... I loved KDE 3 and never managed to switch to KDE 4... but I can't in good conscience endorse something using Qt 3 in 2014.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 17, 2014 5:31 UTC (Wed) by eru (subscriber, #2753) [Link]

>Are they still using Qt 3?

The linked to release note says:

Upgrades to TQt3 (TDE's fork of Qt 3.3.8). TQt3 upgrades include a new, modern style engine, multi-threading support, and improved speed and stability.

Probably converting KDE3 to later Qt versions would have required too many chances to be feasible for a small project.

(Got to check out Trinity sometime. I too liked KDE3 a lot).

Trinity Desktop Environment R14.0.0 Released

Posted Dec 17, 2014 14:05 UTC (Wed) by krake (subscriber, #55996) [Link]

I wonder what they mean with multi-threading support.

Qt3 had threading classes, I worked on case bases back then which did heavy multithreading in network I/O and data processing domains.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 17, 2014 18:07 UTC (Wed) by madscientist159 (guest, #100273) [Link]

While Qt3 did have limited threading support it did not work well with the rest of Qt3's notable features such as the signal/slot mechanism. This led to a.) threading not being used where it should have been due to implementation complexity and b.) several complex application-specific threading classes (such as the one in Amarok).

Our Qt3 version now has threading support comparable to that present in Qt4+. This has made it easy to communicate between threads via the signal/slot mechanism and this, in turn, has allowed the TDE team to repair several applications that were either crashing due to races in the old code or performing suboptimally due to non-use of threading (e.g. using processEvents() during tight loops instead of launching and using a worker thread).

For those who are curious the initial commit adding support is here:
https://git.trinitydesktop.org/cgit/qt3/commit/?id=78125e...

Hope this helps!

Timothy Pearson
Trinity Desktop Project

Trinity Desktop Environment R14.0.0 Released

Posted Dec 17, 2014 21:56 UTC (Wed) by krake (subscriber, #55996) [Link]

> While Qt3 did have limited threading support

I wouldn't call it limited, it worked like threading in other frameworks, e.g. Java

>Our Qt3 version now has threading support comparable to that present in Qt4+.

Nice!
I see per-thread event loop and moveToThread but at least a quick find doesn't seem to hit any ConnectionType (Auto/Queued/Direct/BlockingQueued?

Trinity Desktop Environment R14.0.0 Released

Posted Dec 17, 2014 23:37 UTC (Wed) by madscientist159 (guest, #100273) [Link]

>> While Qt3 did have limited threading support

>I wouldn't call it limited, it worked like threading in other frameworks, e.g. Java

I'll give you that; however it was demonstrably harder to use than many other core Qt functions and just felt limited overall.

>>Our Qt3 version now has threading support comparable to that present in Qt4+.

>Nice!
>I see per-thread event loop and moveToThread but at least a quick find >doesn't seem to hit any ConnectionType (Auto/Queued/Direct/BlockingQueued?

You're right; the support in Qt3 automatically detects the needed connection type (at runtime) but does not currently provide a mechanism to manually set the connection type as it was not needed elsewhere in TDE. If this functionality ends up being needed by a TDE application (or if it's specifically requested by a developer) it would be trivial to add.

Tim

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 8:01 UTC (Thu) by krake (subscriber, #55996) [Link]

> I'll give you that; however it was demonstrably harder to use than many other core Qt functions and just felt limited overall.

I guess it depends on what one is used to.
Having had used different multithreading APIs before it felt just like what I expected.

> the support in Qt3 automatically detects the needed connection type (at runtime)

So the equivalent of AutoConnection, which is also the default in Qt4

> but does not currently provide a mechanism to manually set the connection type

I see two problems:
- sometimes it is necessary to make a direct connection, e.g. when you don't want to "lose" the thread.

- direct was the default behavior in Qt3. Changing a default is a massive behavioral change and you don't have the "benefit" of doing that during a porting phase (like Qt3 -> Qt4 had).

Trinity Desktop Environment R14.0.0 Released

Posted Dec 19, 2014 3:37 UTC (Fri) by madscientist159 (guest, #100273) [Link]

>> I'll give you that; however it was demonstrably harder to use than many other core Qt functions and just felt limited overall.

>I guess it depends on what one is used to.
>Having had used different multithreading APIs before it felt just like what I expected.

Fair enough. I've used some low level threading stuff before too, but it always felt out of place in the Qt/TDE environment.

>> the support in Qt3 automatically detects the needed connection type (at runtime)

> So the equivalent of AutoConnection, which is also the default in Qt4

>> but does not currently provide a mechanism to manually set the connection type

> I see two problems:
> - sometimes it is necessary to make a direct connection, e.g. when you don't want to "lose" the thread.

Now that you mention it IIRC Amarok required this due to the way its threading class was designed. As a result there's a method that can be called to restore the direct behaviour, but this should be cleaned up and made more flexible for the next Qt3 release.

> - direct was the default behavior in Qt3. Changing a default is a massive behavioral change and you don't have the "benefit" of doing that during a porting phase (like Qt3 -> Qt4 had).

This is one of the reasons R14 was delayed as long as it was. The threading changes went in late 2012, I did an audit on the TDE codebase (thankfully very few TDE applications actually used threading!), and we tested the changes over the next year and a half before releasing.

Tim

Trinity Desktop Environment R14.0.0 Released

Posted Dec 19, 2014 15:33 UTC (Fri) by Wol (guest, #4433) [Link]

> Now that you mention it IIRC Amarok required this due to the way its threading class was designed.

Interesting... so Amarok should work better on KDE4 than KDE3. Yet I switched to Clementine because Amarok just didn't work for me on KDE4 :-)

Cheers,
Wol

Trinity Desktop Environment R14.0.0 Released

Posted Dec 19, 2014 16:16 UTC (Fri) by pboddie (guest, #50784) [Link]

I switched to Minirok because I don't need album artwork, streaming services, lyrics, visualisations, in-app purchases... But most importantly, I didn't need Amarok to just give up half way through a track on a regular basis for no good reason, needing a restart of the application only for it to do the same thing again not so long afterwards.

Although Amarok provided a somewhat nicer navigation interface, it's a good example of how the basics were neglected (playing music from files) in the pursuit of fancy functionality, even if I should really be blaming Phonon, ALSA or the Linux kernel for my problems. I'd say the same about some other KDE 4 variants of KDE 3 applications, too.

Still, it's nice to see Trinity plot its own course, and Qt 3 worries aside, it's not exactly in the same category as CDE which is also freely available now and really does require some effort to dust it off and make it a competitor. :-)

Trinity Desktop Environment R14.0.0 Released

Posted Dec 17, 2014 18:39 UTC (Wed) by madscientist159 (guest, #100273) [Link]

We fully maintain Qt3, including patching security holes. Work is (slowly) underway to modernize the graphics backend as well.

Several years back (around the time of Qt 4.6 IIRC) there was an internal TDE version that sort of supported Qt4 via our tqtinterface layer (a thin shim between the Qt3 and Qt4 APIs). Unfortunately the real-world performance was horrible compared to Qt3; furthermore the loss was measured in Qt4 itself not in the interface layer. This test result largely stalled porting efforts, and when Qt4.8 introduced new drawing bugs (QTBUG-25896 and QTBUG-26013) that are *still* unfixed it became glaringly obvious that Qt4+ was not going to work for our needs in its current form.

The biggest issue with Qt3 right now is that it is only GPL licensed. I have been attempting to get Digia to relicense it under the LGPL but haven't been able to reach a decision maker yet. If this is done Qt3 could become a perfectly viable lightweight toolkit in its own right; at minimum I would have more incentive to add in Wayland support.

I'm glad to hear there's still interest in KDE3/TDE from the general community!

Timothy Pearson
Trinity Desktop Project

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 10:43 UTC (Thu) by mgraesslin (subscriber, #78959) [Link]

> We fully maintain Qt3, including patching security holes.

According to openhub.net TDE maintains a code base of 10 million lines of code with just 14 contributors over the last year (I assume that the project is set up correctly as you are the manager). That makes about 700,000 lines of code per developer. This sounds to me like a too large piece of cake to eat and impossible to provide security updates. In comparison the Qt5 project shows 445 developers on a code base of 6.8 million lines of code.

I'm wondering how you can provide those security fixes? Are you monitoring Qt and KDE security advisories to check whether they still apply to KDE 3.5 and Qt 3 (at least I do not check whether a found vulnerability would apply to KDE 3.5)? Not to mention code which got rewritten during the Qt 4 and Qt 5 transitions and by that just eliminating insecure areas which might never have seen a CVE as nobody looked at the old code. Personally I would be extremely concerned to ship such an outdated KHTML - it just must be full of security issues, similarly the network stack of Qt, etc. etc.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 12:53 UTC (Thu) by efitton (guest, #93063) [Link]

Why do you spread FUD consistently about TDE?

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 13:10 UTC (Thu) by mgraesslin (subscriber, #78959) [Link]

If what I wrote there is spreading FUD, then it should be easy to point out that my doubts are invalid. That's certainly the better reaction than claiming that people are spreading FUD.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 13:48 UTC (Thu) by Ignatius (guest, #100286) [Link]

You found security-vulnerabilities? Don't be shy and report them!

There must be plenty of vulnerabilities in KWin, couse the maintainer does waste his time with spreading FUD here.

Please point to vulnerable code parts, if you have any doubts.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 14:30 UTC (Thu) by mgraesslin (subscriber, #78959) [Link]

Very well. I did a search for "Qt security advisory", picked the first one, which is http://blog.qt.digia.com/blog/2011/03/29/security-advisor... and started to look at it. It's about black listing some fraudulent certificates. The patched class QSslCertificate got introduced in Qt 4.3, so TQt is obviously not affected, but(!) there is obviously related code in KIO, or now tdeio and there is no change listed in TDE's git web interface.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 14:24 UTC (Thu) by efitton (guest, #93063) [Link]

Your statement seems like it would have been supporting Microsofts FUD from a decade ago. Why did we call it FUD instead of refuting it? Because it was still out there. Because it was a time suck. Because it could becoming self fulfilling. How many potential TDE developers have you driven away from TDE? Maybe if you had stayed quiet they would have a team you think is adequate.

How about giving actual examples of a security holes that exist because of the size of the development team. Has anyone actually seen an exploit in the wild? You have a conjecture about a possible problem, no evidence of a problem. The onus should not be on TDE to show that they are large enough; it should be on you to show how they are failing users. And keep in mind, the projects you dislike are the only reason I am back on Linux after a long hiatus. If my choices are GNOME 3 and KDE 4, I'll go back to Windows.

What I am pointing out is that you have consistently gone after TDE.

http://blog.martin-graesslin.com/blog/2012/02/having-a-lo...

http://blog.martin-graesslin.com/blog/2012/10/maintaining...

http://blog.martin-graesslin.com/blog/2013/01/about-netwo... At the [2]

You say things like: "I think one should warn potential users." Personally I think it is beyond the pale to repeatedly attack a different free software project / community. And as this developer points out, https://plus.google.com/115606635748721265446/posts/DFaNh..., it can be emotionally draining to be attacked.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 19, 2014 17:09 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Martin's criticism was always well-grounded and respectful. If you can't deal with that, well, tough.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 15:49 UTC (Sat) by efitton (guest, #93063) [Link]

You mean the analysis that pretty much said:

"There are fewer applications available for [insert Trinity here], there's no long-term development roadmap, and there's a higher technical risk in using it."

Because that is exactly what Microsoft said about Linux as part of its FUD campaign. http://www.cnn.com/TECH/computing/9903/24/mslinux.html/. And who called that statement FUD? Linux Developers, advocates and the community. Along with the press and Microsoft themselves.

Matt, as the leader of Fedora you are saying you agree with his analysis that developers on MATE, Cinnamon and Trinity are not competent enough to write and maintain and window manager? Because that is Martin's well-grounded and respectful analysis.

Matt, as a Redhat employee are you ok with the enterprise version of Redhat shipping KHTML? Martin's analysis is that it is an inherent security risk to support such old code.

Now will you or Martin actually read this? Maybe not, the threads have died down. Will Martin or his motivation of killing Trinity change "The motiviation of this post is mostly the fact that I tried several times to get the project to stop their fork." I doubt it. I was surprised it took him this long to show up and start spewing FUD. However, at least I have a nice thread to point to for the next Trinity article shows up and Martin comes to bash it again.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 16:11 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

>Matt, as the leader of Fedora

Hold on. You are not replying to Matthew Miller who is the Fedora Project leader and goes by the nick mattdm in LWN and elsewhere. Afaik, "HelloWorld" has no affiliation to Fedora or Red Hat.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 16:17 UTC (Sat) by efitton (guest, #93063) [Link]

Then I apologize. I believed, apparently incorrectly, that Matt Miller's handle on lwn was HelloWorld.

Please disregard that portion; however, I do believe it is fair to claim that Martin has been posting FUD for years with regards to TDE and Martin has an ax to grind with regards to TDE.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 16:18 UTC (Sat) by efitton (guest, #93063) [Link]

http://lwn.net/Articles/591499/ apparently threw me off.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 16:41 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

"I do believe it is fair to claim that Martin has been posting FUD for years with regards to TDE and Martin has an ax to grind with regards to TDE."

I am not sure that is a fair characterization and I think it misses the bigger picture reflected partly in Martin's first blog you referred to.

When GNOME 3 and KDE 4 was introduced, several people expected that the unrest would be mostly short lived and projects like MATE and TDE would probably have a short shelf life and while GNOME 3.14 and the latest KDE releases have turned to be much much better the initial .0 releases, there appears to be enough users of MATE, Cinnamon and perhaps TDE as well that upstream developers of these projects and other apps that use components developed by these projects have to take into account.

Some good things to ease the transition including things GNOME classic mode and re-additions of features missing in the earlier releases of KDE have come out of the recognition that a major change like this is not something one can do quickly but it also means we are a dealing with a lot more diverse base and someone who tries to support user communities, I see the flipside of it pretty regularly.

Both GNOME and KDE developers have independently pointed out that the mass renaming and forking wasn't necessarily the best approach to continue with the older branches and in the case of MATE, perhaps taking over maintenance of the older components or becoming co-maintainers for just the older branches directly may have been a better way. It seems MATE developers have done some of that. I can't comment on the TDE relationship to KDE specifically but if there is some amount of effort to do similar things already happening or planned, that would be good to know.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 18:42 UTC (Sat) by pboddie (guest, #50784) [Link]

Both GNOME and KDE developers have independently pointed out that the mass renaming and forking wasn't necessarily the best approach to continue with the older branches

Good luck "continuing" (never mind "forking") projects and not renaming them! Maybe you can get away with not having to rename all the files to use "tde" instead of "kde" (in this case), but I can't see the custodians of the trademarks being very happy about the project name being kept in place, particularly when they have declared an end to the software in question. It reminds me of the Python/Stackless 2.8 controversy: another example of trademarks combined with a development community wanting to draw a line under stuff they consider to be very much in the past.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 19:53 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

I don't think trademark is stopping them at all if they do it with the cooperation of the projects they are continuing on. C.f. Current GNOME panel maintenance, openSUSE Evergreen etc.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 21:58 UTC (Sat) by boudewijn (subscriber, #14185) [Link]

The Trinity people have been very nice when I asked them to rename their fork of Krita 1.6 -- it's weird, though... This release apparently also includes their KOffice fork, with their Krita fork. And, well, Krita has come such a long way since 1.6. But I might just setup a vm and install it to have a bit of a nostalgic trip back to 2005, when my kids were in primary school and I hadn't got any grey in my beard yet.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 2:46 UTC (Mon) by efitton (guest, #93063) [Link]

I think it is usually more useful to look at the big picture. However, here I think it is perfectly appropriate to look at the tree instead of the forest. In my opinion, trying to run users and developers away from a different FOSS project is never ok. And even if we take the context of 2011 and early 2012; it is now the eve of 2015 and Martin is still having a go at TDE.

If you want we can start a new thread about the state of fragmentation in the community and how we got here; not that it will accomplish anything but we that rarely stops us.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 20:32 UTC (Sat) by flussence (subscriber, #85566) [Link]

> Will Martin or his motivation of killing Trinity change "The motiviation of this post is mostly the fact that I tried several times to get the project to stop their fork." I doubt it.

Has he actually said this? And can you provide a link, so I can see it with my own eyes?

Not that I don't believe you, it's more a sense of disbelief in general that someone so blatantly against user freedom is allowed to hold any stake in a high-profile FOSS project. Even GNOME has the decency to keep verbal abuse quarantined to their own userbase.

I also note he remains silent to anyone challenging the technical assertions in his FUD but seems readily able to engage in worthless political flamefests. Let's see if we can get some answers by levelling the playing field a bit:

Is KDE 5 a ticking time bomb full of twisty, neglected codepaths? No official denial yet, stay tuned for more! News at 11.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 20, 2014 20:57 UTC (Sat) by efitton (guest, #93063) [Link]

http://blog.martin-graesslin.com/blog/2012/10/maintaining... second sentence.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 21, 2014 9:57 UTC (Sun) by mgraesslin (subscriber, #78959) [Link]

> Has he actually said this? And can you provide a link, so I can see it with my own eyes?

it's taken out of context. What I meant is the fork of KWin, not the complete Trinity project. I think it's unfortunate that Trinity forked all of KDE 3.5 and Qt 3. In my opinion they should not have forked applications which got stronly improved in KDE 4 times - e.g. KWin, Kate, Krita, Okular, etc. etc. In the past I contacted the Trinity team with a proposal to get them using our version of KWin instead of a fork in a similar way how KWin is nowadays used by LXDE/LXQt. So yes, I wanted to stop the fork of KWin.

In Context

Posted Dec 22, 2014 2:35 UTC (Mon) by efitton (guest, #93063) [Link]

How was that taken out of context? It was the thesis of the blog post. You linked to it from Google Plus talking about warning users away. Your conclusion calls Trinity junk and celebrates them severing the connection to KDE. However, as I linked to the actual blog post, not once, but twice, people can read it and see if it is out of context.

However, even if it was out of context, when would it ever be ok to try and destroy a free software project that you don't even work on?

I find it ironic that you repeatedly talk about the hostility in the free software community. You say that you considered leaving FOSS because it can be negative. However, it doesn't seem to keep you from running down other developers and other projects. And when I say ironic I mean hypocritical and disgusting.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 21, 2014 9:59 UTC (Sun) by mgraesslin (subscriber, #78959) [Link]

> Is KDE 5 a ticking time bomb full of twisty, neglected codepaths?

What do you mean with "KDE 5"? We have never released a product called KDE 5, so I do not know what you refer to.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 21, 2014 23:07 UTC (Sun) by Wol (guest, #4433) [Link]

Well, what's the v5 that's out there? iirc Qt5 is out, and presumably (as I think has always been the case) KDE has always used the same major version as Qt.

So if there's no such thing as KDE5 in development, I would be surprised.

But, at the end of the day, it is NOT your prerogative to tell other people what to do with their time. And given the DISASTER that was the early versions of KDE4 - I personally was FORCED to switch away from KDE - if people were pissed off enough to fork KDE3 and you are a KDE4 developer, then you've only got yourself to blame!

(Put bluntly, KDE4 *BRICKED* my development system, and as you ought to know, I wasn't alone. *24* *hours* after boot, KDE4 still hadn't got past the login screen ...)

I'm back on KDE4 - I like KDE too much, but complaining about people who you yourself (or your colleagues) were responsible for driving away doesn't paint you in a good light ...

Cheers,
Wol

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 20:25 UTC (Mon) by flussence (subscriber, #85566) [Link]

> I do not know what you refer to.

Then I'd be wasting my time trying to continue any of this thread; your position is clearly based on on deliberately refusing to understand something a child could figure out.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 23:08 UTC (Mon) by HelloWorld (guest, #56129) [Link]

What a load of crap. mgraesslin is merely pointing out facts: there is no such thing as "KDE 5". There's the Plasma 5 Desktop, there's Qt 5, there's KDE Frameworks 5 and there are the individual KDE applications. It's not clear what the hell you're talking about, not by any stretch of imagination.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 23:11 UTC (Mon) by HelloWorld (guest, #56129) [Link]

I mean the analysis that said that 1 developer per 700k lines of code is simply not enough to properly maintain this stuff.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 11:02 UTC (Tue) by davidgerard (guest, #100304) [Link]

Which is why LibreOffice never got started.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 17:54 UTC (Tue) by HelloWorld (guest, #56129) [Link]

LibreOffice has 290 contributors these days according to OpenHub. Trinity is never going to get anywhere close to that simply because most potential developers will choose to contribute to the current KDE offerings.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 19:02 UTC (Tue) by mgb (guest, #3226) [Link]

If it ain't broke don't fix it. Xerox PARC created the desktop in the 70's. Berners-Lee added the web browser in the 90's. Almost everything on the desktop since then has been either reimplementation or annoyance.

Trinity works well, it doesn't need four cores to run, and its developers don't keep experimenting on their userbase.

My users are very happy with it, and so am I.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 16:32 UTC (Thu) by mgb (guest, #3226) [Link]

You seem to dislike Trinity. Very well, don't use it. Problem solved.

KMail has been the most important tool in my GUI toolbox for many many years and I thank the Trinity folks for maintaining and improving the wonderful KDE 3.5 and not experimenting on me with every passing UI fad.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 12:43 UTC (Mon) by sebas (subscriber, #51660) [Link]

KMail's UI today is very close to its KDE3 version though.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 1:34 UTC (Tue) by anselm (subscriber, #2796) [Link]

Yes, but the KDE 3 version actually worked.

It seems to me that most of the KDE 4 cycle was spent on getting the KDE 4 version of KMail to work as well as the KDE 3 version used to, but by the time I gave up on it (three months ago or so) it was still nowhere near the original as far as I was concerned.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 7:46 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

That's not quite correct. Kmail 1 was ported to kde4 and worked just as well as the KDE 3's kmail 1. I kept building that kde4-based version for my own use for quite a long time, since I'm a really heavy mail user. No other email application could handle the amount of email I gave kmail 1 to handle.

At one point, building kmail 1 for kde4 became really tough and I tried to migrate to kmail 2. That never really worked out, for all kinds of reasons, though I still don't have any other choice than to use kmail2 given how hard it is to migrate gigabytes of mail and hundreds of filters to another client.

I never was deep inside what was going on with kmail2, but there've been some quite promising noises recently, with work started on fixing the user interface issues, the backend issues, new people getting into the action.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 18, 2014 22:59 UTC (Thu) by flussence (subscriber, #85566) [Link]

> Personally I would be extremely concerned to ship such an outdated KHTML - it just must be full of security issues, similarly the network stack of Qt, etc. etc.

How does it compare to KHTML 5? The browser was completely stagnant throughout the entire 4.x lifecycle, was its security upkeep any better?

Trinity Desktop Environment R14.0.0 Released

Posted Dec 21, 2014 23:17 UTC (Sun) by Wol (guest, #4433) [Link]

You know what? This story reminds me of the systemd fracas. With one big difference. The characters are pretty much the same - the people who don't like systemd are still stuck in the past, and prefer Mate/Trinity.

BUT the systemd guys are not trying to destroy sysvinit - it's just that what they think is best for systemd just happens to be bad for sysvinit. However it seems there is a bit of a campaign to destroy Mate/Trinity by the new guard.

News at ten - just because it's old doesn't mean it's bad - all too often "new" == "The Emperor's new clothes". (Don't get me started on relational :-)

Cheers,
Wol

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 16:22 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

Aren't you (and the trinity folks) exaggerating a little? "campaign" is a big word for a few blogs by one guy over two years ago pointing out the risk of a fork by 1 or 2 people of +10 million lines of code. Now they have proven at least to not give up on it and there have been no negative blog posts, have there? Although those risks are no smaller. The security question seems legitimate to me... Honestly I don't care as much for security as I consider myself not much of a target and using too obscure software to be hacked by indiscriminate means but I'd never recommend Trinity to anybody who does care about security - did you notice how the question went unanswered? That seems answer enough.

About the ' KDE 5' point - you might have noticed releases of Plasma 5.0 and 5.1 while Frameworks 5.4 is out, and so is Applications 14.12. Feel free to call any, none or all of them ' KDE 5', just be aware that it is not a 1-on-1 mapping of KDE3. Or, alternatively, say what you mean - the desktop has been named Plasma for over about a decade now so that shouldn't be too confusing and it is probably what you were talking about. Equivalents of KDE Plasma 5.1 include GNOME Shell 3.6, Microsoft Windows 8.1, Apple OS X 10.4 and so on. Brands create products.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 17:32 UTC (Mon) by edgewood (subscriber, #1123) [Link]

Or, alternatively, say what you mean - the desktop has been named Plasma for over about a decade now so that shouldn't be too confusing and it is probably what you were talking about. Equivalents of KDE Plasma 5.1 include GNOME Shell 3.6, Microsoft Windows 8.1, Apple OS X 10.4 and so on. Brands create products.

I'd respectfully submit that if you're still explaining what it means after a decade, perhaps the brand isn't very successful.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 8:41 UTC (Tue) by krake (subscriber, #55996) [Link]

> I'd respectfully submit that if you're still explaining what it means after a decade, perhaps the brand isn't very successful.

In the Linux space it is usually just trolling.

In the much wider audience of Windows it can indeed happen that people do not know or recognize the difference between a product and a vendor or between different products of a vendor.

E.g. it is not impossible to encounter persons who think that say "Windows Office" instead of "Microsoft Office" and I think we've all heard about those who "run Word" as their operating system :)

Interestingly it is probably the Windows and OSX users of KDE products who have the least "difficulties" with product naming.

Which makes me believe that the "difficulties" by users on Linux are hugely exaggerated, since people running Linux are more often than not more aware of software they are using than users of proprietary platforms.

Trinity Desktop Environment R14.0.0 Released

Posted Dec 23, 2014 9:06 UTC (Tue) by renox (subscriber, #23785) [Link]

I fully agree with your point!
Renaming things is a very, very bad idea..

KDE should have stayed the 'desktop environment' and new names used for the other parts..

Trinity Desktop Environment R14.0.0 Released

Posted Dec 22, 2014 22:45 UTC (Mon) by Wol (guest, #4433) [Link]

> I'd never recommend Trinity to anybody who does care about security - did you notice how the question went unanswered? That seems answer enough.

I got the impression they'd just tuned the question and the questioner out. I did also notice that - when the questioner actually did what he said the Trinity people should do - he hit a blank!

If you think Trinity is bad, surely KDE4 would be worse? Full of new code, new features, new bugs, Emperor's new clothes ... unless someone actively does a security audit, I wouldn't trust ANY code. You only have to look at some of the stuff that's been crawling out of the ancient woodshed recently ...

I don't know what the aims of the Trinity developers are, but if they are simply modernising KDE3 (as seems possible from the comments that "you don't need HAL any more"), then they don't need as many developers. Cleaning up, bug-fixing, and updating takes a lot less effort than trail-blazing.

At the end of the day, if you don't like Trinity and use your feelings to tell other people not to use it, then it's FUD. If you have hard evidence that it's insecure, then it's okay to tell people. At the end of the day, there is hard evidence out there - it's called bug reports and security (CVE?) reports. But as far as this article goes, I make it 1-0 to Trinity at the moment ...

Cheers,
Wol

Trinity Desktop Environment R14.0.0 Released

Posted Dec 24, 2014 11:05 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]

I get what you mean but really, you say there is no reason to think three people would be able to keep 10 million lines of code possibly less than equally well maintained and secure as 500 working on 6 million? I am no security expert but in my common ears this seems not to be a stretch...

Trinity Desktop Environment R14.0.0 Released

Posted Apr 23, 2015 22:26 UTC (Thu) by lysse (guest, #3190) [Link]

Not only is there no reason to think so, there are good reasons to think they will have an *easier* time of doing so.

Firstly, you're focusing on the line count as the key metric, without considering how many of those lines change every time around - the principal source of newly-introduced security issues. In a static codebase, the number of security issues can only go down; in a codebase that's still evolving, it's likely to go up.

Secondly, I would argue that the line count is the wrong metric to be considering at all. In fact, it's likely that the key metric will be precisely the one that's frightening you - the inverse of the size of the development team. Why? Because another rather important source of bugs is miscommunication between team members regarding their intentions - in that respect, code is a lossy language. And of course, the number of lines of communication between N team members is N!, and the number of miscommunications is directly proportional to the number of communications on each line of communication.

And then there's the question of developer quality and commitment. You don't think a small, committed team can keep a sprawling software base secure? Good thing nobody told the OpenBSD team. Now consider the relative status of the Trinity project - legacy code, worked on by people dedicated to keeping it alive *because they depend on it* - and KDE - shiny, up-to-the-minute, and because of that inevitable to attract developers who are more interested in status... and perhaps less keen to put in the hard slog of keeping something useful. Even with robust filtering in place, there are likely to be a broader range of abilities amongst 500 developers than amongst 3 - which will exacerbate the communications difficulties I've alluded to above.

So - in short: yes, there's every reason to think a 10m-line legacy codebase maintained by 14 people is going to be more secure than a 6.8m-line frontline codebase under active development by 440-odd. Probably MUCH more secure. The reason you think otherwise: you've divided where you should have multiplied.

Trinity Desktop Environment R14.0.0 Released

Posted Apr 23, 2015 22:43 UTC (Thu) by lysse (guest, #3190) [Link]

*sigh* You know what I did? I looked up Trinity straight after reading this week's LWN, then found this thread, then forgot I wasn't replying to something IN this week's LWN. And forgot to look at the date.

Bugger.

Sorry. Don't mind me, I'll get my coat...

Trinity Desktop Environment R14.0.0 Released

Posted Apr 24, 2015 4:23 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> In a static codebase, the number of security issues can only go down; in a codebase that's still evolving, it's likely to go up.

Amd just how are they not going to need to change large parts of it? Has Trinity ported off of DCOP? Upgraded to libpng 1.6's API? How are they going to handle Qt3 forcing folks to keep using X rather than Wayland once that is "standard"? New OpenGL stuff such as EGL? Qt4 doesn't support Wayland and *it* is almost EOL. Xrandr? How about talking to udisks for mounting USB keys? Or systemd/logind for shutting down the machine? HAL is dead, and so is ConsoleKit. I suppose you could stick with Slackware, but are all Trinity users really only on Slackware?

You need to keep up with the treadmill of updated dependencies because security fixes only get back ported so far (and almost certainly not over project migration boundaries). And users might want to run newer software at some point.

Code that doesn't need changing in the long run is either perfect or dying. And one of those is much less likely than the other.

Trinity Desktop Environment R14.0.0 Released

Posted Apr 25, 2015 4:11 UTC (Sat) by flussence (subscriber, #85566) [Link]

> How are they going to handle Qt3 forcing folks to keep using X rather than Wayland once that is "standard"?

I don't think TDE need worry.

Qt3 is small beans compared to the riots that will ensue if Wayland attempts to render entire collections of purchased games/proprietary apps worthless by not supporting X11 as a first class citizen.

Trinity Desktop Environment R14.0.0 Released

Posted Apr 25, 2015 4:31 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

That's fine for applications, but running the base DE system through XWayland? What do you do for a window manager?

Trinity Desktop Environment R14.0.0 Released

Posted Apr 25, 2015 20:08 UTC (Sat) by flussence (subscriber, #85566) [Link]

I would expect TDE's window manager on Xwayland would be as usable Compiz was on Xgl in 2005.

Trinity Desktop Environment R14.0.0 Released

Posted Apr 27, 2015 15:37 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I don't see any universe where Wayland ships anywhere without solid support for X applications, indefinitely. The X window manager is a pretty special class of program though, while I expect it to be possible to run Xwayland with a single full-screen window which has a complete desktop in it, there may be some advantages in program isolation or performance with GPU buffers to work on porting just the window manager to Wayland so that it can manage the Xwayland application frame buffers more simply. Maybe this causes more bugs than it fixes but it would be an interesting pilot project along side shipping the standard full-screen Xwayland desktop.

Trinity Desktop Environment R14.0.0 Released

Posted May 9, 2015 18:14 UTC (Sat) by nix (subscriber, #2304) [Link]

Well, the libpng and udisks things are already done. Much of what you discuss is extremely optional and would count as new features, but supporting new versions of crucial dependencies is Trinity's entire raison d'etre, so using them as an argument against it is... strange.