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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
