Kevin Krammer posted on Sun, 24 Mar 2013 16:41:35 +0100 as excerpted:
> On Sunday, 2013-03-24, Duncan wrote:
>> Kevin Krammer posted on Sun, 24 Mar 2013 12:41:03 +0100 as excerpted:
>> >
>> > Well, the 3 series was actively released about one and a half year
>> > into the 4 series and continues to be available up to today.
>>
>> http://aseigo.blogspot.com/2008/01/talking-bluntly.html
>>
>> A lot of folks including me took that as the promise it was[.]
>> KDE's reneging on that very publicly made promise lost them
>> the trust of a LOT of users and admins who were depending on
>> KDE to keep its word.
>
> Well, KDE e.V. has no say of what contributors of KDE do, it was
> specifically designed that way to falling into the trap of steering by
> committee. No individual in a community of peers can make promises on
> behalf of other indivuals, unless the first individual happens to be
> the employer of the second or has some other form of contract.
I did say that I'm aware of the difficulty of steering volunteers, who
after all can simply take their donated time and donate it elsewhere.
And in fact that was what I guess kubuntu and some others were (rightly,
it turned out) predicting, the reason they didn't do an LTS at the time,
because they didn't believe the upstream support would actually be there.
In fact, I believe the above linked post was in part a direct reply and
counter to such concerns.
How then could-it/did-it so overreach, without equally public disavowal,
if indeed it was a promise he had no standing to make, so apparently
directly addressing the concerns of the community that there WOULDN'T be
such support, promising there would be, from someone apparently in a
position to make that promise?
> I would interpret such a statement as an assumption based on
> expectations of that time, e.g. that users would have switched to the
> new stack as some point or moved to products provided by other
> "vendors".
I guess so. But a lot of users including me were looking for answers at
the time, and took that as the answer they were looking for. Live and
learn, I guess. FWIW, that would appear to be why the gnome3
alternatives sprang up so quickly when it jumped the shark as well --
they too had learned from the kde3 -> kde4 debacle, and how trinity
stepped up, but too late to actually make a difference for many.
So the community appears to have learned its painful lesson from both kde
and gnome, and come away older and wiser for it. It's a much different
place now, and I don't think it could happen again -- the community would
step in a lot faster this time, as it did with the gnome3 alternatives
when they tried it, and at a rather smaller scale, as I personally did
with my switch to claws-mail from kmail when it tried it.
> I think the main problem here is lumping together different highly
> independent products into one term.
Thanks for continuing to emphasize that, Kevin. It's certainly going to
be interesting to see how the kde frameworks 5 thing plays out,
especially given that qt5 is going the much more modular route at exactly
the same time, with most components of each becoming optional, only
installed when a specific app needs them.
It sounds real good and I'm definitely looking forward to it, but there's
both the challenge of actually getting there, and probably some not yet
fully perceived down sides as well. But it'll definitely be interesting,
and I really AM looking forward to it, at this point anyway believing
it'll be a dramatic improvement on what we have at present.
> There were a couple of newly developed programs but they were almost
> always components of the workspace product.
> I am currently not aware of any application which dropped features
> during the porting, but I can obviously not know all applications and
> all their features.
For the most part it wasn't so much dropping features, as in way too
visible and important cases, dropping the SINGLE "feature", reliability,
that everybody wants and uses, while ADDING features that were nice
enough, but added bloat and weren't particularly useful without the core
reliability that got dropped somewhere amongst all those changes.
But there were a few feature drops as well. The biggest two projects I
can name here aren't part of kde-core, but they're headline kde apps and
thus very important: kaffeine, and amarok.
AFAIK kaffeine for kde4 simply took too long to mature, and in the mean
time, it simply didn't have the power features that people used it for in
the kde3 era, instead of the many other media player alternatives out
there. Features like frame-by-frame advance and incremental playback
speed. These are advanced features that simply aren't available in the
default level offerings, kde3 OR kde4, that had people using kaffeine for
kde3 instead of the lower featured alternatives in the first place.
I /think/ it actually got there by now, but I don't know, as I long since
moved on to smplayer (and am now running smplayer2) and vlc, both of
which have these missing features.
Vlc, meanwhile, is an interesting case in itself, as the real reason I
have it installed (as opposed to only smplayer/smplayer2) is due to the
phonon-vlc backend. I don't have gstreamer installed at all, due to it
simply not working all that well years ago when I last tried it (it's
probably just fine these days, but I've simply not needed it installed,
as gstreamer's a pretty heavy ecosystem and there have always been
alternatives to bringing it ALL in as a dependency, phonon-vlc vs. phonon-
streamer being a perfect example), and when it became clear that phonon-
xine simply wasn't cutting it, I needed an alternative and the two
available were phonon-vlc and phonon-gstreamer, and as I didn't have
either one installed and wasn't interested in playing the whole gstreamer
game again if I could avoid it, vlc it was, especially since I knew of
its media-player fame and this gave me the excuse I needed to try it out.
Otherwise I'd have probably not installed vlc either, as its deps are
pretty hefty too, and unlike the xine, mplayer and gstreamer ecosystems,
save for phonon-vlc, vlc doesn't seem to have much of a surrounding
ecosystem of its own. But the mediaplayer AND phonon-backend angles
combined took vlc over the threshold despite its rather heavy deps, so
it's installed now and I tend to use it and smplayer2 more or less
interchangeably. That was handy in at least one case on my netbook, as
smplayer quit working (it'd freeze the system) there at one point, I
believe due to its use of graphics accel functions that were buggy on
that generation Intel graphics driver. But vlc continued to work just
fine. =:^) But on my workstation (with its radeon graphics and the
freedomware drivers, which never had that problem), I favor smplayer (now
smplayer2), as I can't quite say why, but I just seem to be more
comfortable with it.
Which leaves amarok. Amarok's kde3 -> kde4 conversion was for me a
microcosm of the larger kde3 -> kde4 debacle. The devs tried switching
to mysql as akonadi was at the time, but in the process, they used mysql
functionality (something about a mysql library for use in other apps,
I've forgotten the details) that was completely broken on amd64/x86_64 at
the time, because as all libraries on amd64, the library in question
needed built with -fpic, but as that library was a part of the larger
mysql package and building the rest of it with -fpic would have meant
unacceptable slowdowns for the executables, nobody was actually building
it with -fpic.
So by choosing to use this mysql library amarok effectively decided they
were going to break for 100% of their amd64 users until the problem was
fixed upstream and in the distros their users were using. At minimum,
that demonstrates a seriously callous disregard for the needs of this
major and growing user segment, as I said, basically the same disregard
the entire kde4 project was demonstrating for users at the time, by
insisting kde4 was ready and dropping support for the actually working
kde3, while kde4 was still in actuality very very alpha quality.
With amd64 being my primary platform, despite the fact that I knew the
problem and being a gentooer I could have simply added -fpic to my build
flags for mysql myself, I was already unhappy with where amarok was
headed, and that was simply the last straw -- I looked elsewhere and
ended up with a FAR lighter (even with the multiple front-ends I built
for it) mpd, music player daemon. Which as a bonus brought a new feature
I could actually use with it, the fact that I could now play music at the
command line without X even running, and could continue to play music
uninterrupted thru kde/X restarts, etc, something I'd been missing with
amarok.
And the plethora of mpd frontends I installed, including two (qtmpc and
qmpdclient, the former discovered and installed later) for qt4,
originally one for qt3, which I still had installed as I worked thru the
kde3/kde4 upgrade issues, the mpc CLI frontend, and two curses-based semi-
guis (ncmpc and ncmpcpp), STILL was far FAR lighter than amarok and its
deps, including ruby, which was installed only for amarok. (FWIW there's
additional mpd frontends available for gtk2/3 and web-based access, among
others, but I didn't need those.)
Meanwhile, amarok had dropped support for the kde3 version's miniplayer
and with it the winamp skins it supported, which I definitely used, and
had dropped the mini-visualizer as well, which I also used. At the same
time, they were expanding support for their database backed interface
with the mysql integration, but I didn't need or use the database backed
interface features. And they did this cute little minibrowser thing,
which I didn't need or use (I HAVE a browser, thank-you, and prefer
opening links in it, as it's a full-featured browser). And IIRC they
improved and further integrated lyrics lookup and covers support, neither
of which I needed or used.
So it was a case of adding all sorts of features I had no use for while
at the same time killing features I definitely used, and the breakage on
amd64 was simply the last straw in an already sad situation, here.
But I really never had been comfortable with amarok even in kde3, because
of its incredibly high deps requirement, and incredibly poor even then
ratio of features I actually used to non-optional features along with the
deps they brought in, that it forced. So it was at best a "bad marriage"
to begin with, and I didn't consider it a /terrible/ loss. Certainly far
less so than the larger kde3 -> kde4 debacle, or the later akonadified
kmail thing.
I DID miss amarok's full-size projectM visualizations for awhile, but
eventually I discovered that vlc has them when I installed it for phonon-
vlc. And for me mpd's X-independence and plethora of frontends was about
an equal tradeoff, feature-wise, which made mpd the FAR superior choice
for me, given its FAR lower deps requirements. Also, it's apparently
possible to hookup projectM based visualizations to mpd's fifo output,
but I've not yet done the research to figure out how, and with vlc's
handling projectM based visualizations, it's a relatively low priority
for me now, so I might not ever get to it but that doesn't bother me too
much.
> The closest thing I can come up with is a change in feature set in
> Konqueror's file manager "personality" due to also using the engine
> developed for Dolphin.
> Given the alternative of not having the file manager "personality"
> anymore it was probably still the right choice.
>
> However, doing most of my file management on the shell makes me a bad
> judge on that matter.
You and me both. mc for the win! =:^)
I do sort of wish gwenview would implement audio file support, however,
and thus be a full media filemanager. Media files are my biggest use
case for user-side/full-GUI file management, and gwenview handles images
and video well enough that I use it almost exclusively for them, but it
totally hides everything else, including audio-only files, which are now
one of only two things I use dolphin for. The other is as a trivial-case
file browser, basically a file open dialog on steroids.
If gwenview had a checkbox for audio file support as it does for video
file support it'd cover the media angle entirely. And if it further had
a toolbar button and/or hotkey toggle to show all files, not just media
files, it'd cover the file-open-dialog-on-steroids case as well, and I
could probably uninstall dolphin as I recently uninstalled konqueror
(because it's no longer a reasonable full-use browser if it ever was, I
use firefox now, and the few cases I use a full GUI browser for are
covered by dolphin and gwenview).
And that wouldn't change gwenview's primary images use case or non-
optional deps at all, since the audio file thing would be a checkbox much
like the existing video file checkbox, and the show-all-files thing would
be a button/hotkey toggle that could remain off by default. Any
additional deps pulled in could be optional as well, but they'd certainly
be no worse than the deps for dolphin, so if it meant people could make
gwenview their default file manager (already a kcontrol option) and get
rid of dolphin entirely, it'd be a net plus.
>> Actually, that's why I jumped off of akonadified kmail so fast. I saw
>> the whole early kde4 thing happening all over again. Only this time I
>> knew there were alternatives and I make the personal executive decision
>> to take one of them!
>
> Yes, one of the things that needs to be and hopefully will be addressed
> by the split on the next version transition is the invisibility of
> project boundaries.
> There is often very little or sometimes even no overlap at all between
> the groups of people working on certain products.
Again, thanks for continuing to point this out. It's a message with
value, but it takes some time to sink in, apparently for all the reasons
you explain (which I agree with).
> This distinction of different topci groups is often assumed and
> understood for non-coding related contributions, e.g. translators for
> language A not being involved in anyway with translations of language B
> other than potentially collaborating on improving source strings or
> working on common tools and procedures.
>
> For some unknown reason this does not seem to be the case for the code
> contributors, i.e. people assuming that a set of contributors to one
> product somehow having influence or even control about any work going on
> for a different product.
>
> It is probably easier to consider for the example of translations
> because everyone is aware of their own limits when it comes to multiple
> languages, while for non-coders the work of coders will look like being
> the same thing.
Thank you very much for the translations analogy! Please put it on your
list to use again when making this point, as it REALLY EFFECTIVELY
brought home the point to me! =:^)
[On the topic of wayland porting, X mediation layer "emulation" approach.]
> The potential for that approach has been demonstrated by platforms that
> have never used X11 as their primary display system, e.g. several highly
> committed vendors producing Xservers for Windows.
>
> Another analogy could be the existence of a multitude of terminal
> emulators for all those programs that did not get an "X11 port".
Both valid analogies. Thanks.
[meta on negativity]
> If negativity ever gets out of hand I will simply switch to a news based
> reading approach and use scoring rules to only see discussions that have
> interesting participants :)
More or less what I'm doing now with my lists (including this one) via
gmane... which actually might have been why you mentioned it I guess.
Except that I'm interested in all sorts of stuff, and tend to give anyone
but direct spammers (and occasionally people who insist on repeatedly
posting in HTML, despite requests) the benefit of the doubt, even if
they're overly negative.
So I don't use scoring that much, except as I said to killfile the
spammers. But for sure I'm a big booster of the lists as newsgroups
thing, and thus of gmane. For similar reasons I now run two separate
instances of claws-mail, one for mail, the other for my rss/atom feeds,
and I don't do irc, which along with running pan for news and handling
feeds as news, means the only thing my mail client handles is mail, not
news, not feeds, not lists, not instant messaging or IRC, not
appointments or calenders or..., only (non-list) mail. =:^)
Meanwhile, I run multiple (pan) news instances as well. One for my text
groups, one for binaries, and one for temporary test group subscriptions
and general unsubscribed group browsing.
Sounds a bit like that old Unix philosophy of a dedicated tool for each
job, let each tool do one thing and do it well, but with easy
interoperation and data exchange between them, doesn't it? =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
