Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.
You got it the wrong way around. It was Google who refused to develop a multi-process architecture within WebKit, just as they refused to improve JavaScriptCore and instead created V8 as stand-alone project under Google-exclusive control.
Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit?
Actually Apple at that time was a pretty bad FOSS citizen. People campaigned to Apple to rethink the way it does development and that resulted in a vendor-neutral development home for WebKit. These days KDE is a happy user of WebKit.
Google now repeating Apple's past mistakes is not so great. 2 wrongs don't make 1 right, as they say.
Nobody is removing anyone's code from WebCore itself. They are only talking about now unmaintained platform adaptions. Unmaintained adaptions have always been removed. Nobody within the public even noticed when the Symbian S60 adaptations were deleted.
The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.
Please explain to me: What negative impact do cleanly separated platform adaptions have? So WebKit devs will delete the chromium directory in https://trac.webkit.org/browser/trunk/Source/WebCore/platform and Google will delete all directories except chromium (and probably android) but I don't see why a buggy BlackBerry adaptation would have any negative impact on the Chromium adaptation and vice versa.
I don't know about your stupid Kubuntu (everybody in his right mind knows that it's the worst KDE distribution) and I don't care about ancient KDE SC releases you use (4.10.1 is the current one!). As I already wrote, and you should finally learn to read, I use openSUSE and disabling Nepomuk is a single checkbox and completely removing Akonadi is achieved under openSUSE by uninstalling akonadi-runtime, kdepimlibs4, libkdepim4, and their dependencies.
If you are incapable of clicking a single checkbox and removing a few packages, Slashdot is not the place for you!
it is sufficient to put akonadi nepomuk into Google, and then the first 10 hits are either on what they ought to do (minority of hits) or how to disable them due to simply not working (majority of hits). And when you click on any of the minority hits, you'll find that all of those have a majority of people pointing out that these programs don't work.
SC 4.10's Nepomuk is, and I repeat myself, completely rewritten. Complains about Nepomuk 1.x with its strigi indexer simply don't apply any more. It's like bitching about the Win9x kernel after NT-based WinXP became mainstream.
Now don't come and tell me that I am just the unlucky one.
The unlucky ones are usually the loudest.
This debacle has cost KDE a good number of its userbase.
The conclusion I draw from this poll's results: The majority of people don't bitch about optional components. Possibly because the majority don't use local mail clients anyway and therefore never get in touch with Akonadi which may or may not work well for them. What obviously deteriorated is GNOME's user base. Some stayed with GNOME through its 3.x transition, some use Unity, and others migrated to the GNOME 2.x lookalike Xfce.
Where is the accountability?
There is none. You should read the license of software you use:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Where is the procedure in place, to kick out those applications as long as they are a pain in the lower back to > 90% of the users from the default settings?
Defaults for users are picked by distributors. KDE only releases source code for distributors to compile and package.
Where, and that's the most obvious one, is the one button to disable all of those? No, one needs to fiddle with/usr/share/autostart/nepomukserver.desktop; with akonadiserverrc, and so forth.
System Settings -> Desktop Search. You should open System Settings before claiming that there is no easy way to disable Nepomuk. Akonadi is disabled by default because it only performs tasks after accounts have been set up. As long as you don't set up any mail accounts in Akonadi, its mail service doesn't start. As long as you don't create address book entries, the Akonadi address service does not start. As song as you don't add any dates into KOrganizer, the Akondai calendar service does not start. Remove all entries again via Akonadi's tray icon and Akonadi is disabled. Easy shmeasy. Or you can uninstall akonadi-runtime, kdepimlibs4, libkdepim4 incl. all dependencies (package names as found in openSUSE) and don't even have Akonadi installed any longer.
Also, KDE wants their software to be portable to other operating systems. X11 is the targeted platform - Wayland is extra. KDE is used on a lot more then just Linux. (Also, did GNOME 3 ever get running on BSD?)
OpenBSD ships GNOME 3 with Fallback Mode (no idea if GNOME Shell is even packaged). KDE is still on 3.5.10 there, last I checked...
Does that mean that we will finally be able to install KDE without akonadi, nepomuk and such, and they will become optional modules instead of requirements?
They've been all optional since the beginning. If you use a distribution that has the packages marked mandatory, it's a packaging bug. What you'll miss is birthday and holiday display in the Plasma clock's calendar, file tagging in Dolphin, and so on but the overwhelming majority of features will still work. Dolphin even performs non-indexed searches if Nepomuk's indexer is off or not installed.
In case of Akonadi under openSUSE uninstall the packages akonadi-runtime, kdepimlibs4, and libkdepim4 and let it also remove all dependencies. Disabling Nepomuk altogether or only the file and mail indexers individually is possible via System Settings.
I'm a great fan of KDE 3.x also. For what it is worth, I find that KDE4.9+ to be as stable as 3.x ever was, and as feature-full... as a DESKTOP.
I also switched away from KDE 4 to gnome in the early days of KDE4
Why is it all or nothing with so many of you people? My migration from KDE 3.5.x to Plasma Desktop was step by step. E.g. I used a classic KDesktop/Kicker-based desktop with the 4.0 versions of KWin, Kopete, Okular, and Dolphin. Later I switched to the new Kontact Suite -- 4.1's KMail (backported by SUSE to run under KDE 4.0) at least did not crash then tagging many mails as spam unlike the 3.5 version.
I completely switched with 4.1 and didn't look back after 4.2.
This is stuff that is thrown at the user the first time they log in to KDE.
No, a vanilla Plasma Desktop has zero widgets on the desktop. Distributors may apply different defaults but the upstream default is a completely blank desktop and only the taskbar on the bottom.
KDE4 is very good on the desktop, solid for me since 4.2, but this bug locks up my netbook so I use XFCE4 on that.
"Philip Mukovac (yofel) wrote on 2012-10-19: This is the fault of the opendesktop plugin, once you remove it from the config files page one can be opened fine"
Because the Akonadi-Nepomuk disaster is well known, and has seen plenty of bug reports over the years.Alas, the KDE-PIM people are block-headed enough to simply ignore them ("works for me").
Akonadi and Nepomuk are not the same thing and not even written by the same people. Nepomuk is a local file search cache, Akonadi is a web service cache.
It's also simply untrue that the devs ignore bug reports. If they can't reproduce a bug, they can't fix it. Are they supposed to simply guess bug fixes? SC 4.10 ships Nepomuk 2.0 which features a repair utility (and a new indexer replacing strigi). Malfunctions caused by a broken database (possibly caused by an ancient strigi indexer if one simply upgraded existing installations over the years) can be repaired with it. Running it once should be enough.
Lord, how I miss KDE3. It worked, simply worked. It didn't lock up. When my Linux box was running KDE3, I don't recall ever having to telnet in to restart a frozen machine. It happens all too often with KDE4. And KDE4 ruined, utterly ruined, KMail, once the best email program I ever used.
At least openSUSE still provides both. Using KMail 3.5.10 under Plasma Desktop 4.x is perfectly possible there. Personally I'm very happy with KMail 4.10. For me it works more reliable than KDE3-based KMail 1.x. Nepomuk Desktop Search is also a smooth ride here after its initial indexing.
My personal workstation has been Linux since 2000, but it looks like you've driven me back to my first love, the Macintosh.
OS X's Spotlight search also requires files to be indexed and the initial index also takes its time and hogs the hardware a bit, just as Nepomuk or any other indexed search, including classic GNU findutils.
KDE has always been about configurability, just google around, there are people who have made KDE look very much like other systems, Mac OS X included albeit that does require some non-vanilla stuff to pull off the global top menu.
Since 4.10 even a global menu option is back by default.
Sort of. Gnome developers tend to think that all applications can be reduced to a single button. They believe that not only is every user too stupid to use any GUI more complex than a single button but that they're so much smarter than the user that they can fit every use case behind that one button.
As long as GNOME is just one option among many, their attitude is perfectly fine, IMHO.
Tried Plasma on Mint 13, it's quite pretty. Much prettier than Gnome based desktop for sure. Hopefully it just ends up with incremental improvements rather than complete redesigns and moving from one paradigm to another.
New UI paradigms are added as separate Workspace projects. Currently there are Plasma Desktop (traditional), Plasma Netbook (for notebooks with small screens), Plasma Active (for tablets), and -- since today -- Plasma Media Center. There is no desire to cramp all possible formfactor use cases into one DE, as GNOME Shell seems to do by default (unless you use extensions to modify the default).
Plasma Workspaces 2 is mainly a port to newer technology. I'm not aware of any giant usability changes, except refinement. The biggest planned usability change I remember is seamless transition between the workspaces, i.e. a docked tablet will switch from Plasma Active to Plasma Desktop/Netbook. Currently logging out and switching sessions is required...
As an aside, given that the general consensus let's-all-pretend-to-get-along ego-fest that is FOSS, I can't blame Canonical for increasingly going its own way, given it wants to succeed on the consumer desktop (not business/corporation like the other guys), so I give them props for at least being (if arrogantly) gutsy about hoping to develop all this hyper-complex stuff on their own.
Mir uses Android GPU drivers and does *not* work with stock Mesa drivers. How is that supposed to be beneficiary to consumer desktops? Wayland is backed (among others) by Intel who are the market leader in desktop GPUs. Wayland works with stock Mesa drivers which include Intel's GPU drivers.
Another Wayland backer (Collabora) ported Wayland to Android which means that even on mobile platforms, where Android driver compatibility is a benefit, so even on mobile platforms I see no rational argument in favor of Mir.
KDE Applications will likely run natively under Mir via QMir, a platform plugin/back-end for Qt. KWin will probably run under Mir via a nested X session. However native support for all Plasma Workspaces components (esp. KWin) won't happen as long as Mir is only adopted by Ubuntu and its derivatives. Martin Graesslin, the KWin maintainer, made it very clear that KWin in general does not accept any distribution-specific patches and will not make an exception for Mir.
IIRC Canonical announced to write a component to nest X session within Mir which is why they constantly claim that all the other DEs will run under Mir. As part of Ubuntu's Debian merge they say that even Wayland will be part of the distribution, just not officially supported.
This story is about Plasma Workspaces, not KDE Applications. KDE Applications mostly work on Mac, while Plasma Workspaces were never intended to run on OSX.
Slashdot Mirror
Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.
You got it the wrong way around. It was Google who refused to develop a multi-process architecture within WebKit, just as they refused to improve JavaScriptCore and instead created V8 as stand-alone project under Google-exclusive control.
Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit?
Actually Apple at that time was a pretty bad FOSS citizen. People campaigned to Apple to rethink the way it does development and that resulted in a vendor-neutral development home for WebKit. These days KDE is a happy user of WebKit.
Google now repeating Apple's past mistakes is not so great. 2 wrongs don't make 1 right, as they say.
Nobody is removing anyone's code from WebCore itself. They are only talking about now unmaintained platform adaptions. Unmaintained adaptions have always been removed. Nobody within the public even noticed when the Symbian S60 adaptations were deleted.
The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.
Please explain to me: What negative impact do cleanly separated platform adaptions have? So WebKit devs will delete the chromium directory in https://trac.webkit.org/browser/trunk/Source/WebCore/platform and Google will delete all directories except chromium (and probably android) but I don't see why a buggy BlackBerry adaptation would have any negative impact on the Chromium adaptation and vice versa.
I don't know about your stupid Kubuntu (everybody in his right mind knows that it's the worst KDE distribution) and I don't care about ancient KDE SC releases you use (4.10.1 is the current one!). As I already wrote, and you should finally learn to read, I use openSUSE and disabling Nepomuk is a single checkbox and completely removing Akonadi is achieved under openSUSE by uninstalling akonadi-runtime, kdepimlibs4, libkdepim4, and their dependencies.
If you are incapable of clicking a single checkbox and removing a few packages, Slashdot is not the place for you!
it is sufficient to put akonadi nepomuk into Google, and then the first 10 hits are either on what they ought to do (minority of hits) or how to disable them due to simply not working (majority of hits). And when you click on any of the minority hits, you'll find that all of those have a majority of people pointing out that these programs don't work.
SC 4.10's Nepomuk is, and I repeat myself, completely rewritten.
Complains about Nepomuk 1.x with its strigi indexer simply don't apply any more. It's like bitching about the Win9x kernel after NT-based WinXP became mainstream.
Now don't come and tell me that I am just the unlucky one.
The unlucky ones are usually the loudest.
This debacle has cost KDE a good number of its userbase.
I recent poll, linked throughout the most diverse Linux communities, clearly shows that the Plasma Workspaces are the clear favorite among Linux users these days: http://pollator.com/polls/which-linux-desktop-environment-are-you-using
The conclusion I draw from this poll's results: The majority of people don't bitch about optional components. Possibly because the majority don't use local mail clients anyway and therefore never get in touch with Akonadi which may or may not work well for them.
What obviously deteriorated is GNOME's user base. Some stayed with GNOME through its 3.x transition, some use Unity, and others migrated to the GNOME 2.x lookalike Xfce.
Where is the accountability?
There is none. You should read the license of software you use:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Where is the procedure in place, to kick out those applications as long as they are a pain in the lower back to > 90% of the users from the default settings?
Defaults for users are picked by distributors. KDE only releases source code for distributors to compile and package.
Where, and that's the most obvious one, is the one button to disable all of those? No, one needs to fiddle with /usr/share/autostart/nepomukserver.desktop; with akonadiserverrc, and so forth.
System Settings -> Desktop Search.
You should open System Settings before claiming that there is no easy way to disable Nepomuk.
Akonadi is disabled by default because it only performs tasks after accounts have been set up. As long as you don't set up any mail accounts in Akonadi, its mail service doesn't start. As long as you don't create address book entries, the Akonadi address service does not start. As song as you don't add any dates into KOrganizer, the Akondai calendar service does not start.
Remove all entries again via Akonadi's tray icon and Akonadi is disabled. Easy shmeasy.
Or you can uninstall akonadi-runtime, kdepimlibs4, libkdepim4 incl. all dependencies (package names as found in openSUSE) and don't even have Akonadi installed any longer.
Also, KDE wants their software to be portable to other operating systems. X11 is the targeted platform - Wayland is extra. KDE is used on a lot more then just Linux. (Also, did GNOME 3 ever get running on BSD?)
OpenBSD ships GNOME 3 with Fallback Mode (no idea if GNOME Shell is even packaged). KDE is still on 3.5.10 there, last I checked...
Does that mean that we will finally be able to install KDE without akonadi, nepomuk and such, and they will become optional modules instead of requirements?
They've been all optional since the beginning. If you use a distribution that has the packages marked mandatory, it's a packaging bug. What you'll miss is birthday and holiday display in the Plasma clock's calendar, file tagging in Dolphin, and so on but the overwhelming majority of features will still work. Dolphin even performs non-indexed searches if Nepomuk's indexer is off or not installed.
In case of Akonadi under openSUSE uninstall the packages akonadi-runtime, kdepimlibs4, and libkdepim4 and let it also remove all dependencies. Disabling Nepomuk altogether or only the file and mail indexers individually is possible via System Settings.
I'm a great fan of KDE 3.x also. For what it is worth, I find that KDE4.9+ to be as stable as 3.x ever was, and as feature-full... as a DESKTOP.
I also switched away from KDE 4 to gnome in the early days of KDE4
Why is it all or nothing with so many of you people? My migration from KDE 3.5.x to Plasma Desktop was step by step. E.g. I used a classic KDesktop/Kicker-based desktop with the 4.0 versions of KWin, Kopete, Okular, and Dolphin. Later I switched to the new Kontact Suite -- 4.1's KMail (backported by SUSE to run under KDE 4.0) at least did not crash then tagging many mails as spam unlike the 3.5 version.
I completely switched with 4.1 and didn't look back after 4.2.
This is stuff that is thrown at the user the first time they log in to KDE.
No, a vanilla Plasma Desktop has zero widgets on the desktop. Distributors may apply different defaults but the upstream default is a completely blank desktop and only the taskbar on the bottom.
KDE4 is very good on the desktop, solid for me since 4.2, but this bug locks up my netbook so I use XFCE4 on that.
"Philip Mukovac (yofel) wrote on 2012-10-19:
This is the fault of the opendesktop plugin, once you remove it from the config files page one can be opened fine"
Because the Akonadi-Nepomuk disaster is well known, and has seen plenty of bug reports over the years.Alas, the KDE-PIM people are block-headed enough to simply ignore them ("works for me").
Akonadi and Nepomuk are not the same thing and not even written by the same people. Nepomuk is a local file search cache, Akonadi is a web service cache.
It's also simply untrue that the devs ignore bug reports. If they can't reproduce a bug, they can't fix it. Are they supposed to simply guess bug fixes?
SC 4.10 ships Nepomuk 2.0 which features a repair utility (and a new indexer replacing strigi). Malfunctions caused by a broken database (possibly caused by an ancient strigi indexer if one simply upgraded existing installations over the years) can be repaired with it. Running it once should be enough.
Lord, how I miss KDE3. It worked, simply worked. It didn't lock up. When my Linux box was running KDE3, I don't recall ever having to telnet in to restart a frozen machine. It happens all too often with KDE4. And KDE4 ruined, utterly ruined, KMail, once the best email program I ever used.
At least openSUSE still provides both. Using KMail 3.5.10 under Plasma Desktop 4.x is perfectly possible there.
Personally I'm very happy with KMail 4.10. For me it works more reliable than KDE3-based KMail 1.x.
Nepomuk Desktop Search is also a smooth ride here after its initial indexing.
My personal workstation has been Linux since 2000, but it looks like you've driven me back to my first love, the Macintosh.
OS X's Spotlight search also requires files to be indexed and the initial index also takes its time and hogs the hardware a bit, just as Nepomuk or any other indexed search, including classic GNU findutils.
KDE has always been about configurability, just google around, there are people who have made KDE look very much like other systems, Mac OS X included albeit that does require some non-vanilla stuff to pull off the global top menu.
Since 4.10 even a global menu option is back by default.
Sort of. Gnome developers tend to think that all applications can be reduced to a single button. They believe that not only is every user too stupid to use any GUI more complex than a single button but that they're so much smarter than the user that they can fit every use case behind that one button.
As long as GNOME is just one option among many, their attitude is perfectly fine, IMHO.
Tried Plasma on Mint 13, it's quite pretty. Much prettier than Gnome based desktop for sure. Hopefully it just ends up with incremental improvements rather than complete redesigns and moving from one paradigm to another.
New UI paradigms are added as separate Workspace projects. Currently there are Plasma Desktop (traditional), Plasma Netbook (for notebooks with small screens), Plasma Active (for tablets), and -- since today -- Plasma Media Center.
There is no desire to cramp all possible formfactor use cases into one DE, as GNOME Shell seems to do by default (unless you use extensions to modify the default).
Plasma Workspaces 2 is mainly a port to newer technology. I'm not aware of any giant usability changes, except refinement. The biggest planned usability change I remember is seamless transition between the workspaces, i.e. a docked tablet will switch from Plasma Active to Plasma Desktop/Netbook. Currently logging out and switching sessions is required...
As an aside, given that the general consensus let's-all-pretend-to-get-along ego-fest that is FOSS, I can't blame Canonical for increasingly going its own way, given it wants to succeed on the consumer desktop (not business/corporation like the other guys), so I give them props for at least being (if arrogantly) gutsy about hoping to develop all this hyper-complex stuff on their own.
Mir uses Android GPU drivers and does *not* work with stock Mesa drivers. How is that supposed to be beneficiary to consumer desktops?
Wayland is backed (among others) by Intel who are the market leader in desktop GPUs. Wayland works with stock Mesa drivers which include Intel's GPU drivers.
Another Wayland backer (Collabora) ported Wayland to Android which means that even on mobile platforms, where Android driver compatibility is a benefit, so even on mobile platforms I see no rational argument in favor of Mir.
KDE Applications will likely run natively under Mir via QMir, a platform plugin/back-end for Qt.
KWin will probably run under Mir via a nested X session.
However native support for all Plasma Workspaces components (esp. KWin) won't happen as long as Mir is only adopted by Ubuntu and its derivatives. Martin Graesslin, the KWin maintainer, made it very clear that KWin in general does not accept any distribution-specific patches and will not make an exception for Mir.
IIRC Canonical announced to write a component to nest X session within Mir which is why they constantly claim that all the other DEs will run under Mir.
As part of Ubuntu's Debian merge they say that even Wayland will be part of the distribution, just not officially supported.
Responding to this part of the GP's assertion, wouldn't any Qt5 based KDE be numbered KDE 5.x?
Plasma Workspaces 2 will be based on Qt5-based libraries called KDE Frameworks 5.
Seriously, can't you guys even read the summary?
Nobody within the core KDE development community ever confirmed that there will ever be a Software Compilation 5. http://aseigo.blogspot.de/2013/03/the-case-brand.html suggests that maybe it won't.
This story is about Plasma Workspaces, not KDE Applications. KDE Applications mostly work on Mac, while Plasma Workspaces were never intended to run on OSX.
To disable an effect, it has to be on by default first. No wobble effect has ever been on by default in KDE land.
Will KDE 5 be ported to Wayland?
There will be no "KDE 5". Never ever.
Also, on the Kubuntu side of things, will the Blue Systems folks port KDE to Mir?
No.
How much of Qt5 supports Wayland already?
Plenty.
What would it take to support Mir?
A revolution because no one within the KDE community is even remotely interested in supporting Mir.
It's the kind of thing that doesn't make me interested in any form of desktop or GUI open source development and hasn't for years.
Obviously wrong because if you weren't interested, you'd not even read such stories, let alone comment on them.