Basket is an interesting case. I'm not sure it was ever an official KDE app or even developed within the KDE community. The old website is still hosted on KDE, but the code now seems to be over at Github and untouched for a few years. They do seem to have a working Qt4 port though, they even had beta releases, but I guess the devs ran out of motivation. That's one big reason to develop apps *within* the KDE community, anyone with a KDE developer account could then offer to take over maintaining the project to move it forward. Perhaps someone will get motivated to contact the last author and offer to take over and move it into the KDE infrastructure.
This isn't the new desktop shell (Plasma2? PlasmaNext?), its basically the libs behind it, so there are no screen shots per se.
I must admit I find the new branding/naming conventions very confusing.
Plasma Next is the internal codename for whatever is the next version of Plasma being worked on, you won't see it used in general publicity. After some discussion we decided to use 5 as the technical version number, but we will not emphasise it in the publicity.
As someone already posted, this http://i.imgur.com/usfgJSF.png sort-of explains it. It's simple really:
* KDE = Entity that produces Free Software, like Mozilla or Microsoft or Google or Adobe
* Frameworks / Plasma / Applications = Software 'products' that KDE produces, like Microsoft produces
* 4 / 5 = Version number, sometimes a little mixed up, like Windows Vista and 7 (which is really version 9 or something) and Office 2013 which is for Windows 7, etc.
So the KDE Community produces KDE Software, currently consisting of:
* KDE Development Platform 4, a monolithic set of development libraries for use with Qt4
* KDE Plasma Workspaces 4, a set of desktop, netbook and tablet shells for Linux/BSD systems
* KDE Applications 4, various applications that can run under any Linux/BSD shell, and on Windows and Mac, but work best under Plasma on Linux.
These were all released in monolithic lock-step, so were conflated in people's minds as "KDE 4".
With the migration to Qt5 underway, we will eventually have:
* KDE Frameworks 5 (replacing Development Platform 4), a modularized set of development libraries for use with Qt5
* KDE Plasma Workspace 5, a shell for Linux/BSD systems that can dynamically adapt to desktop, netbook and tablet form factors
* KDE Applications, as above, but probably a mixture of Qt4 and Qt5 based in every release as they slowly migrate
These will all be on different release cycles as best suited to their target audience, so will see their individual identities emphasised more. Most users only need to know about "KDE Plasma" or "Plasma Desktop" and/or the specific KDE Applications that they use, everything else including version numbers will most likely be played down in the publicity.
Sure, using mature, well-tested, well-supported, widely-deployed libraries from a reputable source is always going to be less secure than writing your own code...
Link to Original Source
Lucas has publicly acknowledged his debt to Kurosawa's samurai movies, primarily http://en.wikipedia.org/wiki/T....
No, as a member of the governing body of one of the orgs that has given money to Gnome for OPW, I can assure you that we did give them money for this purpose, as did all the other orgs like Mozilla and The Linux Foundation and Wikimedia. The problem is the Gnome Foundation accounts treat the sponsorship money as income from donations and lump it into the total instead of treating it as a separate item.
It wasn't Gnome's money, other orgs paid Gnome to run the program for them, e.g. Mozilla and Fedora and KDE. In the last round 8 orgs paid for 30 interns, only 3 interns were for Gnome, that's US$148,500 passing through Gnome books as income and expense in 2013 that isn't actually Gnomes money, only US$16,500 was and that was probably sponsored through other direct donations for that purpose. The other orgs even paid Gnome a fee to do this for them, so they didn't lose money on it.
So not your money.
Context: the Gnome Foundation administers OPW on behalf of the other orgs, passing all the money through their own books. The other orgs pay the Gnome Foundation to pay their interns for them. For example in the last round 8 orgs paid for 30 interns, only 3 interns being from Gnome itself. So Gnome received US$5,500 per intern for 27 interns from the other orgs, so that's US$148,500 in income and expense passing through the Gnome Foundation books in 2013 that has nothing to do with Gnome, only US$16,500 was Gnome's own money. The Gnome Foundation charges a US$250 fee to each org per intern. This is just a cash-flow crisis and a lesson to keep separate accounts and ask for the money up-front.
KDE will be well aware of systemd and take advantage of its facilities where it is installed, but it won't be a hard dependency as that would kill our cross-platform aspirations, we will always have alternative code paths for *BSD, Windows, OSX, and Android.
it wasn't the Gnome Foundation's money, they were just paying it out on behalf of the other participating orgs. It was the slowness of the other org in paying (or the Gnome Foundation's slowness in collecting) that has caused the cash-flow problem. Last round there were 30 interns for 8 orgs, only 3 interns from Gnome. At US$5,500 per intern you do the maths.
Sigh. Standard ignorant Slashdot commenting, perhaps you should read up about OPW before making stuff up.
Here's how it works. An organisation such as KDE decides to participate in OPW and so finds some sponsors to pay the US$5,500 stipend for each intern. In KDE's case we found one of our corporate sponsors who was willing to pay. The participating organisation collects the sponsorship money and pays this to the Gnome Foundation who then pays the interns. The Gnome Foundation also charges the participating organisation an admin fee to cover their expenses in running the program. There are at least 18 organisations who have participated in OPW in this way, including Mozilla, VideoLAN, Fedora, and the Linux Foundation. In the last round there were 30 interns from 8 organisations, only 3 interns were from Gnome.
There's two problems with this:
1) All the money passes through the Gnome Foundation accounts, making it appear they have spent 25% of their income on OPW, when in fact it isn't really an income or an expense to the Gnome Foundation, e.g. last round they paid out US$165,000 of which only US$16,500 was their own money, the rest was paid on behalf of the other orgs.
2) The program got so successful so fast that the Gnome Foundation's internal financial processes couldn't cope, they had to pay the interns before they had received all the sponsorship money from the participating organisations, and they used their own cash reserves to cover the gap. Once the participating orgs pay up, the Gnome Foundation will be back to normal again.
Anyone who's ever run a small business will recognise this as a classic cash-flow crisis from growing too big too fast before your admin has a chance to catch up. The lesson here is that the Gnome Foundation needs to set up a separate set of books for OPW and work harder to get the other orgs to pay the sponsors money up front.
So those of you slandering Karen Sandler claiming she's "stolen" money from Gnome for her own personal agenda really have some apologizing to do.
One other point to make is that the Gnome Foundation, just like the KDE eV, has absolutely no say over the direction of development of Gnome, they are just there to provide financial support to the direction the developers choose to take.
John Layt, KDE eV member.
Ah, if that wasn't so funny, I wouldn't bother replying
The guy who raised the issue was told we don't view it as a security issue, and he agreed that it only affects apps running under setuid which we don't support. We asked him to open a bug report so we could deal with it through normal processes. He didn't. If he can't even be bothered to log a bug with Qt or KDE then why should we accord him the same respect as researchers who follow protocol and work with us to resolve real issues?
Since moving to Open Governance, we're very open to external input: we're just very demanding, that's all. You can't expect us to just blindly accept any drive-by patch submission, or any security report from a self-proclaimed security expert. There's a process to follow, standards to reach, and it takes time to convince Qt maintainers that your patch or security concern is correct, let alone meets the quality standard required. If you're not prepared to stick around and defend your patch/security issue/bug report from robust questioning then why should we trust you? I'm a Qt maintainer, one of the first to be appointed under Open Governance from outside Nokia/Digia, and it still takes me several revisions before my patches get approved! It's hard work, simply because quality matters in a toolkit like Qt, especially with security issues.
As for the original article, well the issues were discussed with Qt in March last year, and our security expert at the time said we don't support running a Qt binary as setuid, nor does any gui toolkit, so the issue is not really our problem, the problem is with the fool who runs with setuid. However, in response to the publicity, he has now posted a patch to make this very explicit https://codereview.qt-project.org/#change,74531
"Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out."
Ummm, so does wx, that's the only way to have sensible cross-platform support. Once wx is in your code, you ain't getting it out...
In NZ the Commerce Commission has long held that region encoding is illegal under NZ law. What that effectively means is that when you buy a DVD player in NZ it is already chipped by the manufacturer to play any region, and you can buy DVD's from any region and play them completely legally. Basically it's a necessary move by a country so small that we have to ride the coat-tails of other countries for content distribution.