Re: [kde-linux] Kget "My Downloads" [Is this MS Windows?]
- Date: Sun, 21 Apr 2013 03:20:13 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Kget "My Downloads" [Is this MS Windows?]
James Tyrer posted on Sat, 20 Apr 2013 13:14:17 -0700 as excerpted:
> On 04/19/2013 10:11 PM, Duncan wrote:
>> I think that kget may be a holdover from the dialup connection era.
> Don't see what it has to do with dial up, but rather
> file_length/connection_speed. I am out in the country and have only 150
> KiB/sec and long files still exist.
You're correct, but it's more than connection speed. It's also the shut
down (and/or turn off the network connection) when done options and etc,
that used to be commonly used with dialup, but aren't so commonly used in
the (nearly) always-on, always connected, era. To someone with a
reasonable (say megabit-ish, tho even half-megabit isn't /too/ bad) speed
always on connection that last used dialup (and such options) back before
the turn of the century, they really do seem like an anachronism, out of
another century both literally and figuratively.
But if you're getting ~150 KiB/sec, that's ~1.2 megabit speeds, which
isn't /that/ shabby! Unless you mean 1.5 kbps (kilobit, not kilobyte,
per second). I ran 608 kbps DSL for awhile and yeah, it takes a bit
longer than multi-megabit speeds, but I found that having an always-on
connection was at least as important as the speed, here, and as I said,
anything above ~ a half megabit (512kbps) isn't /that/ bad.
But if you actually mean 150 kbps, then yes, I certainly sympathize, altho
as I said if it's at least always-on, and even then, being 3-5 times
dialup speed, it's not /terrible/.
> Since Konqueror has no builtin
> download manager, KGet is necessary to see how downloads are
> progressing, although FTP downloads can be handled as copying. Long
> files are sometimes still interrupted although it is rarer. KGet does
> have more features than the download managers built into Firefox and
> Google-Chrome. It also has Torrent support built in.
I always seemed to have no problems with either konqueror's or firefox's
progress indicators. Tho you're right that kget has more features that
could be used on slower links.
However, until I got a multi-megabit connection, I always made it a point
to watch the download speed and never try to download more than one thing
at a time unless it was bottlenecking at the server, not my end. If
you're setting up a whole slew of downloads at once, then yeah, they'll
all take longer, and a download manager might well help. But I always
figured I'd rather use all the bandwidth serially, and be able to work
with the first file while I waited for the next, so even back on dialup,
I didn't end up using the download managers /that/ much. (Altho I /did/
use them on MS, still doing one file at a time but using a download
manager that opened multiple connections to different mirrors to get it,
because the MS Windows 9x connection management was so terrible that one
/had/ to do that. But while I installed a similar multi-connection
download manager in Linux early on, I soon discovered I didn't need it in
Linux, and uninstalled it.)
>> that no longer has a real maintainer, and that is simply being held
>> together by hacks from some other kde dev when something breaks, until
>> it eventually gets to be no longer worth maintaining, would explain the
>> hacks you see in the code, etc.
> This might explain why it wasn't fixed, but doesn't explain why it was
> written wrong to begin with.
Well, a lot of freedomware is originally written by "kids" in college.
When they graduate and get a family and a job... often times they quit
contributing so much as they simply don't have the time any more, and the
next generation of college kids takes their place.
Given that scenario, it's reasonably likely that any given piece of
freedomware was originally written by a first or second-year college kid,
and that it was their first real-world project, so of /course/ there's
likely to be "first year programmer" mistakes.
If it's a popular enough piece of software, someone else will take up the
mantle when the original author and first maintainer moves on, but if
it's a fringe case, not so much. kget has evidently (pure speculation
based on your comments and my general FLOSS experience, no inside kget
knowledge on my part) been popular enough to stay in kde core, but not
popular enough to have a real dedicated maintainer, so whenever it gets
too broken, someone steps up and gets it working again, piling on another
set of hacks on top of what was already there, just enough to get it
working, without actually taking time to get familiar with the code and
to rewrite it properly, killing the hacks in the process.
That it's an app mostly used by people with relatively slow connections,
in an age where most people have around megabit or better and all those
college kids that form the backbone of the volunteer force have the high-
speed college/uni connection to use...
So it's left moldering... until it breaks and someone piles on another
hack to get it working once again.
>> Meanwhile, kde5 aka kde frameworks is being designed to be far more
>> modular, and already they're gradually splitting up the formerly huge
>> monolithic tarballs into individual repos, with the core desktop
>> intended to be much smaller and all these individual apps that are
>> now part of the six-month core kde update and release cycle, will
>> probably be shipped separately and updated on their own schedule.
> Does this mean that KDE-4 is already being abandoned by the developers?
> Do you think that there is any chance that KDE-5 will ever work, or
> will it just be the same story?
Well, first of all it's worth noting that in general I'm an optimist, so
an optimistic projection on my part doesn't mean as much as it might from
But that said, the message from multiple kde-insiders is that kde5 will
**NOT** be another kde4 replay, and I do have /reason/ for my optimism.
Among other things, the base underneath kde has changed significantly.
Qt5 in particular is far *FAR* more open than qt4 was, as it's truly a
community project now. KDE, being the biggest freedomware qt user and
one of the biggest qt users period, has thus had a rather larger
influence on qt5 than it did on either qt4 or qt3 -- and the influence it
had on qt4 was already not negligible.
There's an interesting dynamic developing between qt5 and kde5/
frameworks, then. Parts of what was kdelibs because they formerly had to
stay separate, are moving down into qt5, where they have a much broader
community base of support, including a number of businesses now built
around qt, so while qt's more open than it ever was, these bits that were
kde are getting more full-time professional development and support than
they ever did, as they're now part of the broader qt5.
Meanwhile, qt5 itself is *MUCH* more modular, shipped as a collection of
mostly optional modular libraries built around a central core. So where
with qt3 and qt4, if you had qt installed, it was generally assumed that
you had it all installed, now, each of these modules (except for core)
will be optional, depended upon and installed separately.
And, it's worth noting that qt5 in general NO LONGER IMPLIES GUI! Qt5-
core is designed to be usable in and depended upon, perhaps with a few
non-gui modules (qt5-sql, say) as well, by CLI apps as well as GUI apps.
All the GUI stuff is designed to ship in the optional GUI-related modules.
It's within this framework that parts of the former kdelibs are now
migrated to various (naturally optional as dependencies) qt5 modules.
This at the same time that kde-frameworks itself is going far more
The practical effect is that in the 5th generation, the lines between kde
and qt will be blurred quite a bit, as both will be heavily modularized,
with pretty much everything being optional, individual kde and qt-only
apps and libs depending on individual kde and qt libs and modules only as
necessary, without the monolithic assumptions of the 4th generation.
That's the main reason I've not been overly concerned about the semantic-
desktop stuff getting woven even further into basic kde assumptions in
generation 5. With the extremely heavy emphasis on modularation both at
the kde and qt levels, hard requirements on semantic-desktop components,
except for the semantic-desktop-related-apps themselves, simply don't
make sense. They, along with everything else, are pretty much guaranteed
to be optional.
In the kde area, meanwhile, since before the general switch to git but
accelerating ever faster since that switch (and as the stragglers switch
to git), even kde4 is getting increasingly modular, individual packages
shipping their own sources, instead of the formerly monolithic huge
conglomeration source tarballs... as I'm sure you must be aware given
your LFS base.
At this point it's worth noting that only a few weeks ago, I personally
switched to the kde-4.10-live-branch gentoo/kde overlay ebuilds, because
I now actually could do so without having to install svn, since all the
mainline kde packages I run now (but for one) are git-based. The big
exception are the artwork based packages with their heavy binary
component, since git isn't the big win for binary-based-files (like
images, sounds, etc) that it is for text-based sources. So the artwork
packages are still generally svn based, but almost all of the rest of kde
is now git-based. While I did have several of the kdeartwork-* packages
installed, I decided the only one I really needed was oxygen-icons, so I
uninstalled the others, and for oxygen-icons I'm still running the non-
live-branch version (currently 4.10.2), while for everything else
kde-4.10.* that I have installed, I'm running 4.10-live-branch, numbered
188.8.131.5299 on gentoo.
FWIW, I'm updating about twice a week. I have about 128 live-packages,
but two of them aren't kde-related, so about 126 kde live packages. On
my 6-core AMD bulldozer-1 (fx6100) system clocked to 3.6 GHz, 16 GB ram,
with the system still on a "spinning rust" drive but with the builds
actually being done on tmpfs then copied to the live system, and with
ccache caching build results for components that haven't updated, it
takes me less than an hour to update. (I timed a rebuild at 23 minutes I
think it was, with hot cache and having just done a build, so there would
have been virtually no updates, obviously cold-cache with a few days of
updates will take a bit longer, but it's still under an hour, and of
course I can do other stuff while it runs.)
Yet another factor in the "we won't let the kde5 story be a replay of the
kde4 story" theme is that helped by the increased modularization, they're
aiming for kde4/kde5/frameworks compatibility. That is, the goal, at
least, is to allow people to choose to run either a kde4 desktop with
individual kde5/frameworks apps, or the reverse, a kde5 desktop and some
kde5 apps, with individual kde4 apps as well, if it turns out that the
kde5 versions simply aren't as good.
Of course part of that is ensuring that the various components won't
stomp on each other, like for example ksycoca (the kde system config
cache) did with kde3/kde4 -- it was very difficult to run components from
both kde3 and kde4, because the ksycocas from each stomped on the other,
and the environmental variables that might have otherwise been
configurable to keep them separate, were the same ones in both cases as
well, so one had to actually use a wrapper script to reset the one not to
conflict with the other if one wanted to run both well. At least the
goal with kde-frameworks, is to have it sufficiently separated and/or
directly compatible with kde4, that the components won't step on each
We'll see how that actually works in practice, but it's definitely a
worthwhile goal, and if they pull off the modularity thing as WELL as the
separate-or-compatible config, it could well work. We'll see, but I am
Finally, helping with all this is the fact that the kde-frameworks
upgrade /is/ supposed to be compatible, in general. Unlike the kde3/kde4
upgrade, which was a BIG technology change, the kde4/kde-frameworks
upgrade should much more resemble the incremental upgrade of kde2/kde3,
or so the argument and intention is. While I did run kde2, it was close
enough to my original switch from MS that I didn't really know a lot or
worry much about the upgrade, but I certainly don't remember it being
anything near as disruptive as the kde3/kde4 upgrade was, which means
good things if the kde4/kde-frameworks upgrade is supposed to be closer
to the kde2/kde3 upgrade level, than the kde3/kde4 level.
But of course there's yet another plot bend to throw into this story here
as well. The xorg/wayland switch may very well occur about the same time
as the kde4/kde-frameworks switch. If not at exactly the same time,
they're likely to be within a year or 18 months of each other, which will
likely mean that for at least the enterprise and multi-year-upgrade
distros like debian, they'll occur at the same time from the perspective
of the users of those distros.
And qt5 already has preliminary wayland support, with kde-frameworks
wayland support being planned as well. If you watch, there's occasional
blogs on the subject from kde's kwin and plasma folks, among others.
FWIW kde/kwin is planning on continuing the server-based-decorations of
xorg, not the client-based-decorations of weston, wayland's reference
compositor. The reasoning is covered in those blog posts I mentioned.
But wayland is designed to allow your choice of compositor, just as xorg
and xfree86 before it, as well as kde, allow(ed) your choice of window
manager, and few use the reference twm (I believe it is) that is
developed by xorg, these days. So while there's certainly going to be
some "interesting" stuff to deal with for a few years in terms of non-kde
wayland clients on a kde/wayland system as everything works itself out, I
expect it'll all work out in the end. Meanwhile, worse comes to worse,
kwin (or whatever the kde wayland compositor ends up being called) will
probably simply yield client-decorations-draw to clients that expect it,
in the mean time, while the kde/qt wayland libs will include support for
client-decorations-draw to support weston and similar compositors on
wayland, should they find themselves running under them.
Meanwhile, of course there's both an x-support-subsystem for wayland, and
a wayland-support-subsystem for xorg, in the works, so that users can run
a hybrid system for a year or two, or longer if necessary, should not all
apps they run be yet converted to wayland, or if they simply prefer xorg
to wayland for the time being.
(It should be mentioned, however, that since a lot of the same people are
working on both wayland and xorg, once wayland takes off, interest in and
commits to xorg are likely to drop off dramatically. That said, the BSDs
are having some trouble keeping up with some of the DRM, KMS, etc
assumptions of wayland, and xorg may well end up being a primarily BSD
technology in say five years' time. But it's unlikely to be entirely
going away any time soon, even if people who prefer it end up having to
switch to a BSD at some point.)
But this whole modularization theme works well from this perspective as
well. Both xorg and wayland are going to continue to be supported
probably at least thru qt5 with their respective qt modules, and kde-
frameworks, going modular as well, will almost certainly be doing
likewise, unlike the recent headlines about gnome, kde will almost
certainly continue to support the BSDs via the modularization both kde-
frameworks and qt5 are undergoing.
The same theme applies to systemd vs alternative initsystems support,
BTW. systemd is of course incredibly controversial on linux, in part
because of its borgish/gray-goo aspects, seeming to engulf and absorb
project after project as it encounters them. But be that as it may, the
systemd devs have always made a point about not hesitating to use linux-
only technology if they think it's the best way forward, even if it
leaves the bsds out of the loop, as it does, so systemd is certainly even
more of a negative story on the bsds than on linux! And the gnome folks
are apparently making systemd a required component, thus becoming linux-
only. With qt5 and kde-frameworks, meanwhile, kde is deliberately going
ever more modular, and intends to continue to support the bsds, etc, thru
Which means systemd is very deliberately going to remain optional in kde-
frameworks, as well. That's very good news for people like me, since
while I expect I'll eventually move to systemd, I'm in no hurry (gentoo
has absolutely no indication or current intent of killing its current init
solution, openrc, any time soon), and I hope to let systemd mature quite
a bit more, at least until it quits gobbling other projects and has time
to stabilize everything it has gobbled up, before I switch.
So yes indeed, I'm VERY happy to find that all this modularization is
likely to continue to support not only the no-semantic-desktop choice,
but also the no-systemd choice, as well as the xorg AND wayland choices,
at least thru the generation 5 timeframe. =:^)
Then of course there's the good architecture design which modularization
encourages, but I expect you could teach me way more about that aspect
than I could tell you. However, I do expect you'll find this whole thing
quite encouraging as well. I trust you'll post to the contrary if I'm in
any way incorrect in that expectation! =:^]
Status? Of course qt5 is out, tho I expect kde-frameworks will require
5.1 or 5.2 by the time it comes out (much as kde 4.0 required qt 4.2 or
4.3 or whatever, 4.0 wasn't enough). Meanwhile, AFAIK, the kde-
frameworks libraries are coming along quite well, but aren't frozen yet,
and work on the apps and upper level libs really hasn't seriously begun
yet, except for proof-of-concept text-cases, since they'd be building on
a still shifting API base at this point, so would either have to
continuously shift to keep up, or would at minimum have to redo it
anyway, once the API freezes.
But it's worth noting that due to the modularization, once the lower
level libraries stabilize, apps and upper level libraries (like
libkdegames) will likely push ahead and release at their own speed, as
part of the whole modularization push is breaking up the monolithic
release cycles as well.
So we might actually see the first kde5/frameworks apps out pretty
quickly after stabilization. But it's going to be WAY different than
kde4, if for no other reason, because (unlike kde 4.0 which was supposed
to be kdelibs set, but only betas of all the apps) the libs are supposed
to release as stable first, with individual apps coming out after that at
their own speed, and a much smaller emphasis on full kde releases, if
indeed they happen at all.
So it might end up much like xorg-x11 these days, they do still have
occasional xorg-x11 releases, but it's no big deal, because all the
various modules release independently on their own schedule, and the xorg-
x11 release is pretty much just a collection of what happens to be stable
at that point... plus a bit of cleanup and bump-release of the stragglers
that otherwise wouldn't get much attention at all.
If kde-frameworks does do full releases, that's probably what they'll
look like, no big deal for most apps, which will be versioned separately
and will release on their own cycle, but the full kde-frameworks release
may encourage cleanup and update to build with current tools of a few
stragglers that otherwise wouldn't see much attention at all, let alone
Of course current wayland's in a similar early state, altho they do have
a frozen initial wayland 1.0 API to work against, now, but there will
very likely be minor-level (1.1, 1.2...) level updates needed before
anything as major as gnome or kde ships on them.
Meanwhile, recent developments in the form of wayland competitors
(ubuntu's mer, and a different and rather crazy offshoot fork that seemed
to go nowhere and abort real fast) as well as gnome's apparent effort to
standardize on wayland/weston/systemd/linux, are I believe having the
effect of pushing wayland forward somewhat faster than it might have
otherwise evolved. We'll see how things turn out.
>> And kget might be one of the apps that gets dropped by the wayside in
>> the upgrade, since it's really not needed these days.
> It would be better replaced with a browser plugin or component.
>> If it does get ported, it'll probably be on a rather long release
>> cycle, with little further work put into it besides the bare minimum
>> to keep it building and running.
>> OTOH, perhaps somebody new will take an interest and either develop a
>> fresh replacement for it, or will rewrite it and kill the hacks that
>> have built up over the years...
> If the current code base is built on poor design, or hacking instead of
> design, it might be better to start from scratch with a design.
Agreed, of course.
One last caveat/disclaimer, however, just to be sure I'm not
inadvertently messaging something other than intended:
Again, I've no internal knowledge of kget or its maintainer status, nor
do I even have it installed, so am basing my viewpoint in terms of it
primarily on your comments, as well as my own experience in light of
those comments. To be specific, I've not even looked at kget's code
personally, nor am I likely to, since it's of no interest to me.
However, quite in contrast to the kget details, I do believe the above
outline of kde5/frameworks and qt5 to be very close to correct, as I've
been following developments there reasonably closely, even if I still
have no private info, just the public blog entries of those involved, the
various FLOSS community news coverage and discussion, etc. Because
that's coming from multiple sources all saying pretty much the same
thing, while I've only you as a direct source for the kget stuff, and you
yourself mentioned you'd been out of the loop for a couple six-month kde
feature cycles (as your questions on kde5/frameworks hints as well, tho
I'd probably have been following them closer even if you /had/ been in
the loop, simply because I believe I'm probably more interested in them).
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-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.