The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: how about making upgrades easier
by Michael O'Henly on Tuesday 10/Apr/2001, @19:58
|
> If this continues, we might just end up with
> the developers and enthusiasts (with a good
> connection) remaining up2date with KDE and
> others using an ages-old KDE!
Gotta agree with this. Complaining about users not understanding that vendors are responsible for binary packages may be justified but it's also missing the point.
Are you (KDE developers) not concerned that your hard work is lost on many who could benefit from it the most? The promise of KDE is ease of use -- and the pain of updating is an "ease of use" issue!
I use Linux-Mandrake, a distro that has contributed a great deal to KDE. But even Mandrake can't seem to get it right when it comes to updates. They post the binaries with little or no documentation -- 2.1.1 appeared without even a README explaining how to uninstall older versions and replace with newer, how to deal with dependencies, etc. The Mandrake mailing lists are full of posts from frustrated users, many of whom end up reinstalling the whole OS because their KDE update went off the rails.
KDE is frankly rocking the *nix world right now with its development schedule. It would be great if a mechanism could be developed that would make it easier for average users to actually use these frequent updates.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by rsv on Tuesday 10/Apr/2001, @21:46
|
Very true! I am using SuSE linux 7.0 (previously used RH6.2, so had to get used to SuSE first). I always end up downloading a version of kde just when the next version is released. It takes nearly 2 nights and a fat phone bill (coupled with angry relatives complaining that the phone is engaged) to download kde fully. Couldn't get the sources to compile (I saw the solution in the compilation faq tho'), so I used the SuSE rpms. These weren't very friendly either. I finished downloading kde2.1 just when 2.1.1 was released. Then I see reviews of the next kde and curse myself. *damn*
I am mostly using konqueror now (works even better than IE bundled with Windows ME, particularly with ftp). Konqueror is great for everyday use, but lacks the one feature I would like, ie a good download manager. I have to switch to windows to use Flashget, which seems to make the best use of the bandwidth available to me. Is there a download manager for kde2.1? I used Caitoo from kde1.2 but did not like it much.
My first post to the dot using konqueror.
|
[
Reply To This | View ]
|
download manager
by Louis on Wednesday 11/Apr/2001, @01:01
|
Hi,
there are several good download managers (with stop/restart in case connection breaks) on Linux.
a text based is wget which is very reliable. I believe there are front-ends for it, go take a look at apps.kde.org.
The one I use is 'Downloader for X' (nt) which is not kde and not wget but easy to use:
http://www.krasu.ru/soft/chuchelo/
don't use Win for theese tasks because it is no good staying 2 nights online whith that OS, unless you like getting in trouble ;-)
have fun,
Louis
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Amibug on Wednesday 11/Apr/2001, @03:44
|
I think some of us are missing the point that you dont _have_ to update KDE if you dont want to. Just because 2.1.1 comes out 2 months after 2.1 it dosent mean you _have_ to download it.
You can adopt a policy of downloading every second or third release. Sure updates could be compiled for older versions of KDE but that would create quite a bit more work, and at any rate its up to the Distributions to do that, not KDE
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Johan Veenstra on Wednesday 11/Apr/2001, @04:01
|
You may want to look into compiling KDE from source. Once you've downloaded the source, cvsup only gets the changes (and these are compressed as well).
About the download manager: wget should be all you need, but I suspect your ISP is a complete crap, so a download manager could bbe usefull.
Johan V.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Aaron J. Seigo on Tuesday 10/Apr/2001, @22:25
|
Well, I obviously don't speak for the KDE developers, but here is my take on it....
The KDE developers are just that: developers. Their _self appointed_ (e.g. voluntary) task is to create this tremendous architecture which all of humanity is free to benefit from.
So, why don't they extend this just a bit further and provide actual binaries? Here are three reasons that I can think of:
1) TIME. They are already extraordinarily busy creating the technology. Would you prefer development slowed down significantly, or that people would do what they do not enjoy doing thereby stripping them of the joy they find in this pursuit (and increasing the odds that they will stop)?
2) EXPERTISE. The organizations behind each Linux distribution, BSD variant and commercial Unix all create their own environments. For the KDE developers to take on the task of supporting these operating systems with binaries is not only doing the job of these distributors, but means that the KDE people would have to work with all the iodiosyncracies of each OS. Every OS has its own way of doing things and therefore the different sets of packages will and do vary. Who knows the OS best and is therefore in the best position to create binary distributions for it? Why, the companies who make them in first place.
3) FAIRNESS. To officially provide binaries for any given OS, but not for others, would imply a favoritism that is not a part of the KDE project. Within KDE all *nix, *BSD and Linux systems are treated with interest (assuming that there are KDE'ers on that given system). The amount of work that goes into making sure KDE builds on a wide variety of platforms is very impressive. Therefore, if the KDE team themselves can not provide quality binaries for each and every supported system themselves, I think it is a good idea to treat all of them equally and request that either the OS manufacturers themselves or interested users create the binary packages.
Finally... remember. There is no body stopping you as a loyal user of your operating system from stepping up to the plate and creating wonderful binary distributions of KDE. In fact, this would probably be more than welcomed by your fellow users if your OS provider isn't doing their job well. This is how debian, HP/UX, Solaris and (to my knowledge) FreeBSD get their binaries: users stepping up to the challenge.
Around and within the KDE project there are programmers, artists, documenters, translators, testers..... and there are packagers. I think this only makes sense. I also think that with enough encouragement from that other group of KDE people, the USERS, the OS manufacturers can and will step up to the plate and offer quality KDE binary packages. Vote with your voice and with your dollars, and perhaps even some of your own energy. That is how this world of Open Source Software works....
|
[
Reply To This | View ]
|
|
Re: how about making upgrades easier
by not me on Tuesday 10/Apr/2001, @21:10
|
I don't think an IOSlave installer would be hard to make. Just a shell script could do it, I think. That's pretty easy to install - just type the script's name at the bash prompt and you're done. A GUI would be nice, but KControl already has too many panels (or maybe they're just badly organized), and a shell script would do the job nicely.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by greg on Tuesday 10/Apr/2001, @22:23
|
I seriously hope linux (as in everything GNU/Linux) is as easy to update as clicking "Linux-Update."
But seriously, when I look at things like Loki's demo installer/updater, it only makes me feal like everything could be that easy...
But maybe we need a stronger Linux Standards Base first... and some more general standardization...
tired.gif
44KB (45873 bytes)
|
[
Reply To This | View ]
|
|
Re: how about making upgrades easier
by Eric Laffoon on Tuesday 10/Apr/2001, @23:01
|
> I always wonder.. why do I have to upgrade the _entire_ KDE just to get that ripper module inside konqueror working, or to get the latest bug-fixes in KMail, or to get latest Konqueror for that matter!
It depends on whether a fix is back ported or if a program is built to a base specification. It's possible to build to KDE 2.0 spces or to KDE 2.1.1 or even 2.2 pre specification. It is all up to what the author wanted to accomplish. If you wish to take advantage of a new feature then it's libs are required.
Here is all you need to upgrade. kdesupport, kdelibs and kdebase in that order. That also gives you konqueror. Kmail is in kdenetwork. That's far from all the packages.
> The way things are right now, the whole modularity is of no use to a normal user coz he/she cannot upgrade just kmail or just konqueror or add that new cool IOSlave!
Again I repeat... that is arbitrary. If the io slave is built to your specification (and to my knowlege there has been no substantial change to the base architecture there for a while) then you DON"'T need to upgrade to make it work.
> does anybody have any solutions for this problem? If this continues, we might just end up with the developers and enthusiasts (with a good connection) remaining up2date with KDE and others using an ages-old KDE!
Yes! There is an incredibly simple bandwidth sensitive solution! First let me say this.
KDE 2x took a long time to come out. People complained. When I looked at it and realized that it meant that KDE would be able to produce faster releases I got excited. Somehow I failed to imagine that people would begin bitching about it releasing too fast. Here's a clue... it will always take distros time to catch up no matter how fast or slow a program releases. (duh?) However you don't have to upgrade, or you can. For the most part KDE 2.x programs are compatible unless a developer writes to newer or enhanced libs.
Pay attention. This will get you the latest bleeding edge KDE with the least bandwidth requirements. It will also work on any system. Grab a copy of Cervisia and compile it. Now this is difficult so pay attention. Extract it using the graphical archiver tool Ark. Go to the directory in konq and use the tools menu to open a console. It will open in your directory. Now type
$ ./configure && make
$ su
[enter root password]
# make install
Now go to kde.org and get the information for cvs and enter it into Cervisa. You can now get only the updated files at any time. With RPMs and tar files you have to get them all. After your first build you will only recompile what is affected by the updates. This is fast and clean. You can use Cervisia to update to a tag level for fixes or let 'er rip for bleeding edge.
Oh, one more command for cvs. on the first build or when directories are added you have one additional command.
$ make -f Makefile.cvs
I have also seen shell scripts to handle this and they are easy to write.
I do recommend you build your KDE in a seperate directory and kde.org has files explaining how to run two KDEs. Once you get it started you can update at any time using graphical tools and it is bandwidth sensitive and quick.
As a side note, I came to Linux from OS/2 at the end of 1999 and had been mostly working with languages like REXX and Basic. So compiling programs in Linux was a foreign thing to me... but it is not hard and to my experience has far less problems than running RPMs.
Enjoy Extreme KDE... build it from CVS. ;-)
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by sarang on Wednesday 11/Apr/2001, @00:10
|
>It is all up to what the author wanted to accomplish. If you wish to take advantage of a new feature then it's libs are required.
and the problem is that every developer has updated his/her machine to the latest and greatest KDE (even CVS probably as you suggest in the end). What about the users of the application? In simple english "you won't get next version of KMail unless you upgrade to KDE 2.2". Now suppose next version of KMail has "IMAP" as the new feature.. does it have anything to do with KDE 2.2? There could be millions of KDE 2.0.1 users our there.. and they'll never get KMail with IMAP unless they go through the pain of upgrading the entire KDE. Similarly with konqueror.. A lot of my friends still are on default LM7.2 which has KDE 2.0.1.. they keep complaining about Konqueror bugs which are fixed long time back.. but the problem is, konqueror is not released outside of KDE base packages.. hence to get latest konqi, full upgrade is needed!
>Here is all you need to upgrade. kdesupport, kdelibs and kdebase in that order. That also gives you konqueror. Kmail is in kdenetwork. That's far from all the packages.
why isn't konqueror seperate and developed individually? As I understand konqueror uses KParts (khtml etc.) to show the contents.. then why does teh konqueror code itself needs to be in the base libaries? Also, why isn't konqueror released periodically with latest and greatest khtml (since browsing is the main use of konqueror) which will upgrade the khtml the user installed with the KDE he/she has. Similarly, its clear that KMail is outside of KDE's base.. then why can't we have KMail released seperately just like Quanta, Aethera etc? On the other hand, the release schedules of konqueror, kmail etc. can be synchronized with those of KDE-base and we'll get the same effect as we get now.. i.e. KDE2.2 will come with KMail 1.4, konqueror 2.2 etc.. but people preferring to only upgrade KMail can do so too..
Now the question arises of new features.. to tackle that, KDE people definitely need to find a solution so that applications can automagically use the new feature of a newer KDE-base if it exists, else switch to old one. For eg., KDE 2.2 comes out with new printing.. there has to be some way so that KMail will automatically use this new printing scheme (read classes) instead of the old QPrinter if and when it finds teh new libraries installed. KDE has a lot of talended people and I am sure someone out there will be able to find a solution!
>If the io slave is built to your specification (and to my knowlege there has been no substantial change to the base architecture there for a while) then you DON"'T need to upgrade to make it work.
then why don't we get the latest and greatest cd ripping io-slave? why don't we have it for KDE 2.0.1 users?
>Pay attention. This will get you the la [snip]
You didn't get my point Eric. Let me first tell you that I am using KDE 2.1.1 on my LM 7.2.. I am pro in CS and have been using linux/unix for 4-5 years. I can very well download RPMS, install then and figure out problems myself. However, here, I am trying to solve the problem for newbies and even normal users or expert users who want to use linux for production purposes and not for playing with it. You cannot expect a corporation to upgarde KDE on all of its 1000s of machines every 2 months!
The solution of getting latest CVS and compiling is perfect for KDE developers themseleves.. but do you think of users?? Anybody who is doing productive work on his/her machine dosn't want to be on the CVS bleeding edge to have an unstable desktop!
> has far less problems than running RPMs.
this is plaing wrong. I have been using RPMs and never had any problems with them. The reason being I always use RPMs provided by Mandrake. Everything is perfect then.
Also, the whole point of KDE being user-friendly goes away when u ask u're users to compile!! its easy for devlopers and pros like us, but put u'reself in u're grandma's shoes and then think of it.. and if u dono't want to do that, then our motives are totally different!
Ok back to the main point.. some possible solutions:
-one solution to this seems to be major API changes be allowed only in distant releases. For eg. any application written for 2.0 - 2.1.1 should run w/o problems on 2.x.. this will ensure that atleast for 9 months u can afford to not upgrade ;)
-another is to provide backward compatible code.. for eg. provide KPrinter library for KDE 2.0 so that applications written for KDE 2.2 work with 2.0
-segregating base and apps can reduce this problem to a certain extent. Major KDE releases should be once a year with dates synchronized such that all applications that form KDE are released with these major upgrades. Minor upgrades could be frequent and should only include base library package upgrades. The application developers should make sure that applications run across the minor KDE revision. One advantage would be that it'll be easier for people to upgrade as they'll have to deal with fewer RPMs. Consider this: I have KDE 2.0.. new kmail comes out.. but they say I need to upgrade KDE-base packages coz it has new printing functionality.. so I go out and download 2-3 RPMs and upgrade my KDE base to 2.2.. then kmail installs peacefully and works perfectly. All other apps continue working as before since base libaries are always backward compatible (or rather should always be!!)
>I failed to imagine that people would begin bitching about it releasing too fast
I am not bitching.. I love the pace at which KDE is developing.. but that pace shouldn't kill it either right? If the user base decreases because of the tremendous confusion between releases and the pain to upgrade, then KDE will loose its following... which means Linux will loose its following.. and that shouldn't happen. Hence I am raising this issue here. Some how this entire development needs to be synchronized and some new solution has to come out to maximise the time between full upgrdes for people. One year life-cycle would be a good thing IMHO. You can expect people using linux to upgrade once a year.
Please guys, think of somethign cool to solve this issue.
I request someone who is on KDE lists to post on the lists so that KDE developers read this discussion and contribute. I am not subscribed so can't do that.
thanks!
sarang
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Guillaume Laurent on Wednesday 11/Apr/2001, @00:51
|
> Now suppose next version of KMail has "IMAP" as the new feature.. does it have anything to do with KDE 2.2?
Yes. It could use new stuff from the base.
Look, what you suggest is completely unrealistic and would lead to total chaos in no time. Right now, upgrading KDE is very simple : download everything, recompile/install everything. That may take a long time, but it's still very simple. And most importantly it's simple to manage both from the developper and the user's point of view.
Compare this with schemes like "upgrade this package to this version and that package to that version if you need feature X in package Y" etc... By the time you figure out all the dependencies (which most of the time will end up being pretty close to "the whole shebang", you'd have downloaded everything already. Plus it would be a total nightmare for developpers and package builders.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Nathan on Wednesday 11/Apr/2001, @13:04
|
You're right, this is totally unrealistic. You can't expect to upgrade an application without upgrading all of its dependencies! This is why you can't upgrade Adobe Acrobat without buying a new copy of Windows, right? This is why you have to recompile all of Red Hat from source entirely every time you upgrade to a new version of KBiff, right?
Of course not! There is a huge time savings from only upgrading packages X,Y, and Z instead of the whole desktop. If I want a new KMail feature I shouldn't have to upgrade my entire desktop, possible breaking the configuration files for konqueror, knode, etc.
And "just" downloading everything and recompiling everything is a huge pain in the ass IMHO. I have yet to successfully compile KDE from start to finish without hitting all kinds of strange problems. This is *not* the solution if you really expect to be the "user-friendly" desktop that brings Linux to the masses.
It would be nice of the developers to at *least* document which config files are broken by new releases, letting the user know what kind of bumps to expect in the upgrade.
Sorry if I'm ranting, but I've spent *far* more time nursing KDE upgrades along than I ever spent rebooting my Windows machine. It's getting *very* frustrating.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by not me on Wednesday 11/Apr/2001, @13:59
|
>And "just" downloading everything and recompiling everything is a huge pain in the ass IMHO. I have yet to successfully compile KDE from start to finish without hitting all kinds of strange problems.
I hear you! I've never been able to get KDE to compile.
>Sorry if I'm ranting, but I've spent *far* more time nursing KDE upgrades along than I ever spent rebooting my Windows machine.
Yeah, you sound like me, before I switched to Debian. Then suddenly, all my KDE problems magically went away. Now I get KDE upgrades *before* they've been announced on Slashdot, and they always install over the previous version perfectly, keeping all of my settings. I even have anti-aliased text in KDE, with _NO_ effort whatsoever! A simple command (apt-get install task-kde) finds, downloads, installs, and configures KDE _and_ all its dependencies, in one gigantic automated step! apt-get and kde.debian.net are the greatest!
Sorry if I sound like a broken record here, but I just can't get over the incredible coolness of apt-get. I recommend that you try Debian out (or for an easier graphical install, try that Progeny Debian that was just released).
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Guillaume Laurent on Thursday 12/Apr/2001, @01:08
|
Something like you describe will probably happen in the near future, but right now it's perfectly understandable that "everything" is just moving forward, from base to apps.
The base libs are bound to stabilize (API-wise, e.g. no new features) while the apps will keep on evolving. Right now it's just not the case, and maintaining two version of each app is a nightmare in the long range. They already do it between each minor releases (2.1 vs 2.2), but fortunately they try to keep it as short as possible, and limit the changes in the "old" branch to critical big fixes only. They don't backport new features and IMHO they are right in not doing so.
As for compiling KDE, for me it has always been "tar -xvf ; ./configure; make; make install". The only problems I've had are when I try to use --enable-final, which doesn't work for every packages. It's right though that config file are a serious problem. I had to clean up my ~/.kde several times after a new install.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Ingo Klöcker on Thursday 12/Apr/2001, @07:48
|
>You're right, this is totally unrealistic. You can't expect to upgrade an application without upgrading all of its dependencies! This is why you can't upgrade Adobe Acrobat without buying a new copy of Windows, right?
Wrong example ;-) The right example would have been: You can't upgrade M$IE without upgrading a whole lot of the libraries which come with Windows. The only difference is that all new libraries you need are included in the installation package of the new IE whereas with KMail you also have to update kdelibs (because AFAIK some KMail related bugs have been fixed in some kio_slaves which are part of the libs) and maybe kdebase. But I think updating kdelibs could suffice.
If OTOH you use the packages provided by some distrubution you maybe have also to install the latest version of QT and some other libs this particular KDE build depends on. But for this the packager is too blame (was it really necessary to use the latest version of QT for this build?) and not the developers.
Regards,
Ingo
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Michael Häckel on Wednesday 11/Apr/2001, @04:53
|
Hi,
At least for KMail I can explain you why that is not possible. I even though about releasing a separarate version of KMail independant of the KDE release schedule when IMAP is ready for use, but that is no longer possible. Exactely because of IMAP there have been made a few additions to kdelibs to make implementing it much easier and now KMail of course depends on that changes. That is one of the advantages of keeping everything together. If an application needs a new feature in kdelibs this feature can be added and the application is immediately able to use it. Otherwise it would be every time necessary to wait for the next stable release and that would slow down development very much.
Regards,
Michael Häckel
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Naasking on Wednesday 11/Apr/2001, @12:16
|
Isn't this supposed to be the benefit of components though? You write components that can operate independently(and can co-operate) so you don't have to upgrade EVERYTHING to add one feature to your suite/app/whatever. You just have to upgrade the component which is dynamically loaded when needed. If the component wasn't there to begin with, it should be just a matter of installing it and having it registered with whatever service links the components with the services they provide.
Sure reuse, protection, network transparency are all cool component features too, but the main benefit of componentization is supposed to be complete separation of implementation from interface. If this isn't currently the case, then I'd say it's time to rethink the strategy behind the current component framework.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Alexander Kuit on Thursday 12/Apr/2001, @01:41
|
Wouldn't it be possible to create a statically linked version of KMail?
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Jason Hanford-Smith on Wednesday 11/Apr/2001, @16:05
|
This whole things helps back up the Minnows(*) argument that GNU/Linux is nothing but a geek toy. The arguments put forward regarding upgrading everything en masse are untenable. To expect your average user to upgrade through successive version (4 in the matter of a few months), is asking too much.
If you examine the Windows release schedules, you'll see that although major functionality is brought in on every major release, it doesn't stop major application upgrades in the mean time. And these certainly do not require a complete low-level upgrade.
Regarding binary distribution vs. source compilation, let me just say, if you ever seen a genuine newbie (or even a casual computer user) get to grips with Windows Update you'll know that most people are too afraid of "messing around" with what they perceive as a working system. They may need the upgrade, but if something were to go wrong, they wouldn't know how to fix it.
Telling these same people to download and compile source code (and try to unravel the compilation error messages !) is ridiculous.
Even RPMs should be considered too difficult. There should be no reason why the whole upgrade process can not be handled behind the scenes. The compilation process (if it's to be done) should be hidden behind a GUI. The RPM installation should be hidden behind a GUI. There should be no reason why anyone has to open a command line to upgrade KDE.
If this means that a generic installer is created for each binary distribution, this should be a small price to pay for increased ease of use.
Just my tuppence worth.
--Jason
-------------------------------------------
(*)min·now (mn)
n., pl. minnow or min·nows.
1. Any of a large group of small, freshwater fishes of the family Cyprinidae, widely used as live bait.
2. Any of a large group of Microsoft Windows users, widely used as live beta testers.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Ingo Klöcker on Thursday 12/Apr/2001, @08:11
|
>If you examine the Windows release schedules, you'll see that although major functionality is brought in on every major release, it doesn't stop major application upgrades in the mean time. And these certainly do not require a complete low-level upgrade.
Every new version of M$Office or M$IE installs a lot of new libraries. And you have to reboot several times. If this isn't a low-level upgrade why has Windows to be rebooted?
OTOH if you upgrade KDE you don't have to upgrade the kernel or X. Only some libraries and the KDE packages. So upgrading KDE is certainly not low-level. You don't even have to reboot after upgrading. ;-)
Regards,
Ingo
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
