| |||||||||||||
Fifteen years of KDEFifteen years of KDEPosted Oct 19, 2011 13:24 UTC (Wed) by anselm (subscriber, #2796)In reply to: Fifteen years of KDE by boudewijn Parent article: Fifteen years of KDE
I use KDE to get my work done, and my KDE4 desktop allows me to do that in exactly the same way I used my KDE 1, 2 and 3 desktops. Good for you. The only way I manage to do large parts of my work on KDE 4 is by using non-KDE applications. This used to be different in KDE 3.5, which in its time at least came with a reasonable web browser.
(Log in to post comments)
Fifteen years of KDE Posted Oct 19, 2011 14:19 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
Konqueror is exactly as capable as it was in the KDE 3.x days. And that's the problem -- it's the web that has changed.
So instead of using konqueror with khtml, try using rekonq, which is also a KDE application and works fine with today's websites.
Fifteen years of KDE Posted Oct 19, 2011 15:17 UTC (Wed) by anselm (subscriber, #2796) [Link] That's not the issue at all. My problem is that our company web site requires X.509 client certificates. Up until KDE 3.5, Konqueror had very good support for X.509 client certificates. In KDE 4, for no apparent reason, this support is no longer available, which is a definite step backwards as far as I am concerned. (And incidentally, Rekonq doesn't even seem to touch this with a 10' pole.)
Fifteen years of KDE Posted Oct 30, 2011 18:02 UTC (Sun) by walex (subscriber, #69836) [Link]
The reason why KDE SC 4 has little X509 support is simple: nobody has volunteered to write it. The KDE project runs on "scratch your itch" (and sometimes "scratch your employer's itch") lines like other freedom sw projects.
Fifteen years of KDE Posted Nov 2, 2011 0:51 UTC (Wed) by anselm (subscriber, #2796) [Link] The X.509 support was there and working well in KDE 3.5. If it was possible to port the rest of Konqueror over to KDE 4 it ought to have been possible to port that part, too. As far as »scratch your own itch« is concerned, no. This is »platform vs. playground« again. If you want to be taken seriously as a reliable platform for others to use, removing perfectly-working features just because nobody within the project can be bothered to maintain them is a big no-no. That this happens all the time in KDE is a sign that KDE is basically a project whose purpose is keeping hobbyist programmers within the project amused, rather than creating a basis for serious work by people outside the project. Which is fine in itself, of course, but then trying to pass KDE off as something that others can rely on is not. Most other free-software projects manage to avoid feature regressions of this type, so why not KDE?
Fifteen years of KDE Posted Nov 2, 2011 17:36 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> If you want to be taken seriously as a reliable platform for others to use, removing perfectly-working features just because nobody within the project can be bothered to maintain them is a big no-no.
Leaving unmaintained features in, especially ones with security implications, is also "a big no-no". If someone outside the project needs a certain feature, one which is apparently specific enough to their needs that no one else has bothered to work on it, why don't they just sponsor someone to port it to the new platform rather than expecting others to implement it for free?
Fifteen years of KDE Posted Nov 2, 2011 18:24 UTC (Wed) by anselm (subscriber, #2796) [Link] This is a typical playground answer. »We would much rather implement cool plasmoid eye-candy than work on porting forward something boring and crucial such as X.509 certificate support, so if you want the boring stuff done you will have to do it yourself.« As I said, the KDE people are perfectly free to do whatever they like. If they don't mind gratuitous feature regressions that is absolutely OK. However they don't get to do this and at the same time get to claim believably that their project is providing a reliable platform (rather than entertainment for hobbyist programmers). In this particular instance, it isn't that big a deal since people who actually need workable X.509 support will just use a different browser, such as Firefox. However, Konqueror used to be a pretty good browser in its day, and it is sad to see the KDE project basically give up the idea of providing a state-of-the-art browser that (unlike Firefox) integrates well with the rest of KDE.
Fifteen years of KDE Posted Nov 3, 2011 0:10 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
You can call it a "typical playground answer" if you want, but that doesn't change the fact that it's the *correct* answer. The project has a limited budget to work with, and paying someone to port and maintain X.509 certificate support simply didn't make the list. If a feature isn't being used by the vast majority of users, why divert effort from other areas?
Minor features get dropped all the time, especially when a project undergoes a large-scale rewrite. It's not "gratuitous", just matter of setting rational priorities. Conserving maintenance efforts by pruning disused features is a good software development practice, and, rose-tinted memories aside, it's not like Konqueror was ever a killer app for KDE in the first place. With most KDE users running Firefox or Chrom(ium) anyway, they would be foolish to waste scarce paid-developer resources on Konqueror. You can probably count the number of affected users on one hand--and like you, none of them are offering to do the necessary work.
Fifteen years of KDE Posted Nov 3, 2011 0:54 UTC (Thu) by sfeam (subscriber, #2841) [Link]
"none of them are offering to do the necessary work"? How can a user do the work of not breaking something! Only the developers can do that.
Your answer drips with disdain. If the development effort breaks a feature, then of course you will find few users of that feature when you look around for them later. If you allow konqueror to rot, then of course by the time chrome comes around people will switch out of necessity.
Me, I thought that konqueror was indeed one of the killer features of KDE back in the day. I switched to chrome, recently, only because the web itself has changed and konqueror didn't keep pace with it.
You suggest that users should sponsor developer time to keep a feature from being broken in the next release ... how would one even know this was necessary? Before it breaks, how are the users to know it will break? And even after something breaks, unless you publicize that developer resources are the limiting factor in that particular breakage, how would we know to offer, or lobby for, support? For instance, will we ever see Kprinter again? It was promised real soon now through the early versions of 4.x; now it seems to have dropped off the TODO list altogether. Would offers of developer support bring it back? Where can I sign up? If sufficient user-generated underwriting is promised, is there a promise of a working and supported KDE print interface in return?
Bitter? Me? Not really - I still prefer KDE to the alternatives. In fact version 4.recent is very nice, barring the lack of a print tool. But I sure wish the the developers in both the gnome and KDE camps would get a clue about the importance of not breaking things. There is a substantial group of users who would restate your prioritization to read: if the project has a limited budget to work with, paying someone to develop eye candy rather than to keep the core components working is a waste of scarce resources.
So here's to KDE - a toast to 15 years. May it continue to thrive. Like many teen-agers, it's family suffered a bit during a period of adolescent trauma, but we hope that's now behind us.
Fifteen years of KDE Posted Nov 3, 2011 1:36 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> How can a user do the work of not breaking something! Only the developers can do that.
You do realize that KDE4 is a completely new platform, right? New ideas, new architecture, new APIs. It's not just some random modifications to KDE3.5. Everything in KDE4 was written for KDE4, either from scratch or as a port from KDE3.5. None of that happens by itself. They didn't "break" the X.509 certificate support; they wrote a new browser which happens to resemble the KDE3.5 browser superficially, and haven't gotten around to implementing that feature (since very few people need it).
> Me, I thought that konqueror was indeed one of the killer features of KDE back in the day.
Perhaps it was, once, but it's been declining ever since Firefox became popular as a free, cross-platform alternative, long before it was reimplemented for KDE4. It was never much more than a thin front-end for KHTML, compatible with the rare minority of pages which are actually standards-compliant, written in the days when it was considered cool to merge web browsers and file managers into the same package. Nowadays KHTML is called WebKit, and the primary open-source front-end is Chromium. Why bother maintaining a second one?
You're welcome to continue using KDE3.5. There's even a fork already started to continue development on the KDE3.5 desktop: Trinity Desktop <http://trinitydesktop.org/about.php>.
Fifteen years of KDE Posted Nov 3, 2011 2:24 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if you are going to take the tack of "KDE 4.0 is not an upgrade to KDE 3.x, it's a completely different product" then you should not call it KDE 4.0, you should call it something completely different.
For the same reason, Perl 6 should be called something else as it is not an upgrade of Perl 5
if you give it the same name, but with a higher version number, people are going to expect that the capabilities they had before would still be there, along with the new stuff. If you don't intend to provide a feature, you need to list is as a feature that's specifically being removed (and if you have a very long list of such things, expect to loose a lot of people, each one of these 'removed' or 'unimplemented in the new version' features is a regression)
Fifteen years of KDE Posted Nov 3, 2011 3:41 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
And the rewritten successor to Windows 3.11 shouldn't have been Windows 95 (and then Windows XP, Windows Vista/7, etc.). And the successor to Mac OS 9 shouldn't have been called Mac OS X. And so on.
Face it--this sort of thing happens all the time. The name is just a brand, not a reference to a specific codebase. KDE4 is not even the first all-up rewrite of KDE. KDE 2.0 was "almost completely re-engineered"[1] from KDE 1. This happens to most projects eventually; some things can be fixed as you go, but others are more integral and require a change in the fundamental design. Either you fix the design (and port/rewrite) or the project stagnates and is eventually replaced.
Fifteen years of KDE Posted Nov 3, 2011 4:41 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
And what functionality did microsoft drop between windows 3.11 and windows 95?
The issue isn't if they are modified or if the new version is written from scratch, the issue is what things that worked on the old version break on the new version.
If few things break (Windows 3.11 to Windows 95) you get nearly everyone to upgrade (unless the hardware can't run the new version at all, mearly running it poorly didn't stop a LOT of people from upgrading)
where it breaks things, including the user interface (Windows XP to Windows Vista for example) the uptake of the new version is much lower
the fact that KDE4 is a re-write vs KDE3 is a good thing, right up until you state that a feature is lost because the developers didn't care enough to make it part of the re-write, and that it's up to the users to fix this (if it was merely missed because nobody cared enough to notice during the re-write, then reports from users that they cared about the feature should get it on the list of things to fix, it may take a bit of time, but KDE 4.x has had time now)
Fifteen years of KDE Posted Nov 3, 2011 9:42 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] And what functionality did microsoft drop between windows 3.11 and windows 95?Funny you should ask. One of the features they dropped (I'm sure there are more) was Windows Recorder, which allowed you to record and play back macros. A lot of people complained.
Fifteen years of KDE Posted Nov 6, 2011 1:52 UTC (Sun) by vonbrand (subscriber, #4458) [Link] It's not the same, but not even MSFT written software worked on Win95/98/Millenium and WinNT 4 (a game, in my case, "certified" to work in that environment, didn't even make it past the splash screen before hanging the machine). Ditto MSIE on the first x86_64 versions of Windows, they crashed the machine with utter reliability.
Fifteen years of KDE Posted Nov 3, 2011 1:27 UTC (Thu) by anselm (subscriber, #2796) [Link] The project has a limited budget to work with, and paying someone to port and maintain X.509 certificate support simply didn't make the list. I don't think this is actually how these decisions were made. It is not as if prior to the implementation of KDE 4 there had been a formal committee going through a long list of KDE 3.5 features in order to decide which ones to carry forward and which ones to drop, based on estimates of the cost of porting each feature, and assigning developers to them. AFAIK very few people actually get paid for working on KDE, so »budget« doesn't really enter into it the way it would drive decisions in a commercial software project. It's more likely that at some point during the Konqueror port the (hobbyist) person thought »to hell with this, I'm not using this stuff, I'd rather develop more new cool eye candy«. This is of course their privilege (being hobbyists), but it doesn't make for a reliable platform. Minor features get dropped all the time, especially when a project undergoes a large-scale rewrite. The desktop environments like KDE or GNOME seem to like to do this. Many if not most other infrastructure-type free software projects appear to take a more conservative stance towards backward compatibility, which is generally a good thing. For example, the Linux kernel gets all sorts of rewrites all the time, but there, user-visible features seldom if ever disappear at short notice they get carried along for a very long time even if the developers would much rather remove them for good. If you really want to get rid of a feature what you do is that you deprecate it over a certain period of time before it is actually removed, to give users the chance to come up with alternatives if you don't provide alternatives yourself. At least this is how serious projects usually handle this; the fact that KDE can't be bothered is an indication that the KDE project doesn't really care that much about its users. (Keeping the hobbyist programmers amused with cool new stuff seems to have a higher priority.) it's not like Konqueror was ever a killer app for KDE in the first place. That's not what I remember. There used to be a time when the KDE project basically touted Konqueror as the best thing ever, the greatest innovation since sliced bread. It brought together file manager and web browser functionality with good integration with the rest of KDE (ioslaves etc.), and if that didn't actually make it a »killer app«, then at least it brought it dangerously close to »killer app« territory. (Remember that Konqueror was enough of a state-of-the-art browser in its day that Apple saw fit to adopt large parts of it for their own web stuff.) In the light of this, retroactively claiming that Konqueror was never actually all that important to KDE is clearly inappropriate.
|
|||||||||||||