[kde-linux] Kget "My Downloads" [Is this MS Windows?]

[Duncan]

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 
others.

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 
modular.

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 
4.10.49.9999 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.)

Anyway...

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 
other.

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 
optimistic.

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 
this modularity.

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 
releases.


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.

Agreed.

>> 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