It seeks to apply itself to your work Uh, no, it doesn't. Aside from the fact that this is explicitly stated in the GPL itself (since I have a sudden insight that you'll call it "FSF propaganda") what it does is to say that you cannot distribute a combination of your work and mine unless the aggregate is under a GPL-compatible license, because I will revoke your right to distribute my code in that case. Unless I'm mistaken, you could license your code under a "more free" license such as X, and it'd all be ok.
It makes demands and restrictions on how you use the original, and what you do with your own work product. It only restricts how you can distribute the original; you cannot link it with software with an incompatible license (which, unfortunately, includes some free software:( ) and then redistribute it.
It forbids you from using GPL'd software in conjunction with commercial software like Oracle libraries. Your other points are arguable, but this is totally false. The GPL only covers redistribution; in fact, the license text says so explicitly. You can link it to as many non-free libraries as you want, although free (non-profit or commercial) ones are preferred.
And it certainly shouldn't come as a great surprise to you that some people prefer to instead use a free licence, charitably giving their work away to the improve the lot of programmers everywhere without passing moral judgment on those programmers' lifestyle choices. Uhh, which part of the GPL attempts to control lifestyle choices? Or is RMS going to add a requirement in that next version that the user abstain from alcohol..?
Actually, Microsoft can make proprietary extensions to Linux. The Linux license is an implicitly or explicitly modified version of the GPL, which permits you to link binary-only kernel modules to it. So all Microsoft has to do is to implement their special APIs as a kernel module, slap a license on it saying that it must be used with MS Linux, make their programs depend on it, and start selling MS Linux. Probably just about every commercial Linux distro would fold within a few years, as the pragmatists jumped ship for the distribution with lots of familiar apps.. I suspect that the only thing stopping this is (a) their pride, and (b) the DOJ's scrutiny of them.
Yes, of course. Markdowns of anti-GPL posts such as this one as "Flamebait" or "Troll" are totally a product of the Evil GNU Conspiracy and nothing at all to do with the post itself.
Pull the other one, it has got bells on.. Daniel PS - if you still don't get the point, go to the top of the page, to where Tom Christansen got a 5, consider the difference between your post and his, and try to work out why he got marked up and you didn't.
and now before you say "how do you know that's the intent - I wrote it, and you can find it on some of the programs I made available." Then I suggest you rewrite it, because, in the words of Indigo Montoya, I do not think it means what you think it means. "do not prevent anyone from doing the same" is quite easily misinterpreted as "do not deny these rights to other people", which is the spirit of the GPL. In your case, though, I'm not quite sure what the point of that clause is; there's no way anyone can stop other people from getting the same code they got. I'm not a lawyer, but I think the license would be the same, and less confusing, with that clause removed.
I was in the same situation, with the additional contraint that I didn't have any money to buy the shares with anyway. Remember, though: although the numbers are impressive, it's just paper wealth, fueled by the reality distortion field that is Wall Street. As soon as the bubble pops -- and pop it will -- I expect that most of these companies will drop back to a reasonable level, with some of them falling harder than others. I do expect VA to have a better chance than the rest of doing well in the long term (which is what counts), since they actually sell something (as opposed to Red Hat et al, who mainly sell warm fuzzies) But who knows? If I had to peg a high limit for a reasonable jump for VA, I think I'd say double the initial price. Disclaimer: I'm not well-versed in the stock market at all, so the above is just conclusions drawn from general knowledge and could be totally wrong; in fact, the probability that they are is rather high.
Something odd struck me in your post. As an example of an 'acceptable' free software license, you give:
You may use, modify, distribute, and sell this program in any way you wish, provided you do not restrict others from doing the same. I find it amazing that after all the anger and hostility you've shown towards GNU and the Free Software Foundation, you have summed up the GPL and blessed it with your stamp of approval as a 'true free software license'. Daniel
Hmmm. Two post-apocalyptic book reviews on top of one another, just before the end of the milennium. Is/. subtly trying to prepare us for Y2K? Does CmdrTaco Know Something We Don't?:-) Be afraid. Be very afriad..
For instance, I'm biased against Debian because I was stranded on Debian 1.3, with no upgrade method to 2.0. Not to pick on this or anything, but your comment confuses me. My first Debian installation -- in fact, my first Linux installation (besides a Slackware install that I didn't understand and totally messed up) -- was 1.3 . About a week after I installed it, 2.0 was released and I upgraded over a modem by following the very clear instructions which were posted on the Web page. I believe there were two or three different options, including my method (download an early apt incarnation and use it) Which might just prove your point;-) Daniel
Not to complain or anything, but how does that post qualify as "Redundant"? I just looked through every other post in the forum and failed to find *anything* which made the same point that I did (admittedly, rather..um..concisely). Yes, there wasn't an incredible amount of rhetoric or analysis, but there isn't a "Shallow" button in the moderator widgets.
To repeat myself (now I guess I am Redundant;-) ): 90% of the people who are screaming bloody murder because Freemware is "ripping off" the VMWare folks are apparently running Linux. Linux is a free clone of the Unix[tm] operating system which at the time was being sold by various commercial companies. Linux has no particularly innovative features; in fact, it's still catching up with Solaris in many areas and its feature list is essentially borrowed from other operating systems. Its distinguishing characteristic is that (drum roll) it's free! In fact, it was originally written because Linus Torvalds wanted to use Unix on his PC but didn't want to pay for the commercial Unix systems. Does this sound familiar yet? In other words: the same people who are up in arms about Freemware ought logically to be up in arms about the very operating system they are running it on! Anything less is inconsistent at best and hypocritical at worst.
You have to understand that Linux has gone mainstream already. This means that free software developers are no longer the majority of its user base.
I fail to see how this is relevant to your point. The people who are, as you imply, diluting the number of programmers would never have looked at this project anyway! The only difference is that now they're ignoring it while running a free operating system, instead of ignoring it while running a proprietary one.
*But* Linux still has many more years of development behind it than HURD.
Actually, that's not quite true. In fact, I think that the Hurd has been around longer than Linux. The problem as I understand it is that it's an experimental design, and they keep deciding to throw out or rewrite parts of the system, whereas Linux is based on the well-known Unix kernels. Recently there seems to be a significant amount of forward progress, and I wouldn't be surprised if things get a lot better over the next year. Or they might not;-) Time will tell..
Periodically, someone comments that warnings should be sent to admins of systems whose systems are linked to from here, just in case the load is too much. But linking to a system running an experimental operating system should probably fall somewhere under premeditated assault..;-)
Jason, I apologize for the negative and critical tone of the earlier post. libapt is truly wonderful; I was just attempting to point out a few things that could be improved. I'm still not convinced about point #1, and I don't remember getting an answer to #3. I'll go check my mail archives. I actually queried the mailing list on #2, but I haven't gotten an answer. I think this is an important ability, mainly because it's required for a really nice (IMO) UI feature I have in mind:) I believe my message to debian-deity has more information. Could you explain at length why this is not a good idea, and what (if anything) could be done to make it a good idea?
And finally, I'm sorry but I still don't agree on the documentation issue. I have several times run into stuff that the files in/usr/doc claim exists but has turned out to not be useful (I believe I actually asked you about InstallVersion and xstatus, and was told that they were experiments that weren't relevant anymore), and it's difficult to find out what any given function does in full. Usually I just end up tracing through the source code to find out; a brief collection of documentation that gives a more high-level overview of Workers, CacheFiles, Acquire queues, and all the other stuff would make it a lot easier to get up to speed; while you can guess in general what these do, the specific relationships between them are not always clear and the documentation in the headers is somewhat spotty. If you want, I could actually probably write up some general libapt documentation -- but I have to admit that I'm also guilty of "I'd rather code":-\. How the system works can be pieced together from the source and headers, but that doesn't necessarily mean that the documentation can't be improved.
In general: it's no secret that libapt, like any piece of software, has missing functionality and is constantly changing. But I think that it still has a little ways to go before it does 'anything you want'. It might never be there, since everyone (as I've just demonstrated) defines 'anything' differently. So maybe my complaining is totally pointless. Or something...:-/
Thanks, Daniel
I'm really starting to think that that post was a mistake. Chewed out by you and Wichert in the same day..it has to be some sort of record..
I'll see whether that works -- but I believe that apt locks the dpkg status file when told to lock anything (with good reason!), so I doubt that the dpkg call will work. libdpkg might.
Which is as it should be. If a user want to keep logs, she can use shell redirection. No, you misunderstand totally (I think Wichert did too, I may not have expressed myself clearly). I don't mean keeping track of what *was* installed, but rather keeping track of what's *going to be* installed. That is: I decide to install package foo, so I tell the frontend to mark foo for installation. The frontend does, and happily marks bar, baz, and frobozz as well. I have no direct way of finding this out via libapt; moreoever, the *frontend* doesn't know. The latter problem prevents the implementation of an undo command.
There's a workaround for this, but I personally think it's ugly. This isn't really the worst problem, though, and libapt is arguably correct in its behavior here.
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs) Again, this is exactly the kind of thing which should be handled by a front-end. In any case, a user can always hit Ctrl-C during a download, edit the command line, and apt-get will recover quite nicely. Perhaps you didn't read what I wrote? There is *no* *exposed* *way* in the libapt API (at least, none that I can find, and I've looked for a while) to terminate a single download process. That is, if the user starts a large download and then decides that everything's ok, but that one Netscape package shouldn't be installed, the *whole* download has to be stopped and restarted.
The Acquire system is also not very well suited for background downloading (ie, in a separate thread).
-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
You can put packages on hold using dselect (an annoying program, IMO, but functional), though admitedly I've had apt loudly proclaim it was going to over-ride my hold on a package, and then proceed to enthusiasticly upgrade it without even prompting me. I should probably submit a bug report on this, I suppose, but at least it acknowledged the hold was there.
Yes, and my frontend automatically inherits dselect's selections when it starts (err..the CVS version does, got to upload the tree to Sourceforge one of these days..) but there is no way to modify the saved state from apt (unless I'm mistaken, Wichert said he thinks I am, so I may very well be), which makes it useless as a replacement for dselect at the moment.
I expect that some of these will eventually be fixed, or that people will yell at me to be more creative in working around them;), but my point was that libapt is very far from supplying 'everything you could want' to build a frontend.
I didn't notice that you mentioned it. Thanks! I haven't announced it in any official way yet, simply because I want to get a reasonable amount of functionality (ie, downloading and installing packages) first -- I don't want to announce total vapor on the mailing lists; I feel comfortable doing it on Slashdot, I guess. I'm not sure what that says about me..:-\
It has been possible to put a package on hold for ages though, perhaps you missed something? Can you actually put a package on hold from/libapt/? I've been thinking that I'll have to write my own routines to handle the dpkg status file if I want to do that.
Because this isn't FreeBSD, it's *Debian* BSD. The Debian system is based on glibc, and using a single library across all Debian systems would theoretically make it a lot easier to debug problems and so on. Also, you'd get some level of binary compatibility if all programs were ELF and dynamically linked against libc -- only direct syscalls would have to be fixed up, and I don't think there are many of those..I've heard that even syscalls (from C) can go through libc, so mainly you'd need to worry about assembly code.
The apt library is really powerful and does everything you want it to do,
In fact, the poor and out of date libapt documentation aside, this isn't true. Among other things, libapt isn't good at:
-> keeping track of automatically performed selections and removals; each frontend has to do this itself -> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs) -> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
Not that it isn't a wonderful tool, but it's not perfect -- not by a long shot.
Daniel
Shameless plug: I have a very early prototype of an alternative apt frontend at aptitude.sourceforge.net
. Please download it and send me comments so I can fix problems in the next version!
libapt-pkg takes care of the protocols, pulling data off the servers and so on, but I still have to call functions to start the download and do something sensible in terms of display while it's progressing (the display being the sticking point). I'm currently investigating just how far I can push libapt -- I have some extremely nifty interface ideas for the download screen, but they may not be possible with the current API.
Slashdot Mirror
It seeks to apply itself to your work
:( ) and then redistribute it.
Uh, no, it doesn't. Aside from the fact that this is explicitly stated in the GPL itself (since I have a sudden insight that you'll call it "FSF propaganda") what it does is to say that you cannot distribute a combination of your work and mine unless the aggregate is under a GPL-compatible license, because I will revoke your right to distribute my code in that case. Unless I'm mistaken, you could license your code under a "more free" license such as X, and it'd all be ok.
It makes demands and restrictions on how you use the original, and what you do with your own work product.
It only restricts how you can distribute the original; you cannot link it with software with an incompatible license (which, unfortunately, includes some free software
It forbids you from using GPL'd software in conjunction with commercial software like Oracle libraries.
Your other points are arguable, but this is totally false. The GPL only covers redistribution; in fact, the license text says so explicitly. You can link it to as many non-free libraries as you want, although free (non-profit or commercial) ones are preferred.
And it certainly shouldn't come as a great surprise to you that some people prefer to instead use a free licence, charitably giving their work away to the improve the lot of programmers everywhere without passing moral judgment on those programmers' lifestyle choices.
Uhh, which part of the GPL attempts to control lifestyle choices? Or is RMS going to add a requirement in that next version that the user abstain from alcohol..?
Daniel
Uh, I forgot that they can't sell a UNIX variant (because, apparently, of an agreement with SCO) That might also have something to do with it.
Daniel
Actually, Microsoft can make proprietary extensions to Linux. The Linux license is an implicitly or explicitly modified version of the GPL, which permits you to link binary-only kernel modules to it. So all Microsoft has to do is to implement their special APIs as a kernel module, slap a license on it saying that it must be used with MS Linux, make their programs depend on it, and start selling MS Linux. Probably just about every commercial Linux distro would fold within a few years, as the pragmatists jumped ship for the distribution with lots of familiar apps..
I suspect that the only thing stopping this is (a) their pride, and (b) the DOJ's scrutiny of them.
Daniel
Yes, of course. Markdowns of anti-GPL posts such as this one as "Flamebait" or "Troll" are totally a product of the Evil GNU Conspiracy and nothing at all to do with the post itself.
Pull the other one, it has got bells on..
Daniel
PS - if you still don't get the point, go to the top of the page, to where Tom Christansen got a 5, consider the difference between your post and his, and try to work out why he got marked up and you didn't.
and now before you say "how do you know that's the intent - I wrote it, and
you can find it on some of the programs I made available."
Then I suggest you rewrite it, because, in the words of Indigo Montoya, I do not think it means what you think it means. "do not prevent anyone from doing the same" is quite easily misinterpreted as "do not deny these rights to other people", which is the spirit of the GPL.
In your case, though, I'm not quite sure what the point of that clause is; there's no way anyone can stop other people from getting the same code they got. I'm not a lawyer, but I think the license would be the same, and less confusing, with that clause removed.
Daniel
I was in the same situation, with the additional contraint that I didn't have any money to buy the shares with anyway.
Remember, though: although the numbers are impressive, it's just paper wealth, fueled by the reality distortion field that is Wall Street. As soon as the bubble pops -- and pop it will -- I expect that most of these companies will drop back to a reasonable level, with some of them falling harder than others.
I do expect VA to have a better chance than the rest of doing well in the long term (which is what counts), since they actually sell something (as opposed to Red Hat et al, who mainly sell warm fuzzies) But who knows? If I had to peg a high limit for a reasonable jump for VA, I think I'd say double the initial price.
Disclaimer: I'm not well-versed in the stock market at all, so the above is just conclusions drawn from general knowledge and could be totally wrong; in fact, the probability that they are is rather high.
Daniel
Well, they sent it to everyone on Sourceforge. (Un)fortunately I don't have the kind of money necessary to even consider it.
Daniel
Something odd struck me in your post.
As an example of an 'acceptable' free software license, you give:
You may use, modify, distribute, and sell this program in any way you wish, provided you do not restrict others from doing the same.
I find it amazing that after all the anger and hostility you've shown towards GNU and the Free Software Foundation, you have summed up the GPL and blessed it with your stamp of approval as a 'true free software license'.
Daniel
Hmmm. Two post-apocalyptic book reviews on top of one another, just before the end of the milennium. Is /. subtly trying to prepare us for Y2K? Does CmdrTaco Know Something We Don't? :-)
Be afraid. Be very afriad..
Your local conspiracy theorist,
Daniel
For instance, I'm biased against Debian because I was stranded on Debian 1.3, with no upgrade method to 2.0. ;-)
Not to pick on this or anything, but your comment confuses me. My first Debian installation -- in fact, my first Linux installation (besides a Slackware install that I didn't understand and totally messed up) -- was 1.3 . About a week after I installed it, 2.0 was released and I upgraded over a modem by following the very clear instructions which were posted on the Web page. I believe there were two or three different options, including my method (download an early apt incarnation and use it)
Which might just prove your point
Daniel
Ok, I gotta ask, who would bet $25k in online gambling?
People who buy into overpriced IPOs on Internet stock trading sites?
Daniel
Not to complain or anything, but how does that post qualify as "Redundant"? I just looked through every other post in the forum and failed to find *anything* which made the same point that I did (admittedly, rather..um..concisely). Yes, there wasn't an incredible amount of rhetoric or analysis, but there isn't a "Shallow" button in the moderator widgets.
;-) ): 90% of the people who are screaming bloody murder because Freemware is "ripping off" the VMWare folks are apparently running Linux. Linux is a free clone of the Unix[tm] operating system which at the time was being sold by various commercial companies. Linux has no particularly innovative features; in fact, it's still catching up with Solaris in many areas and its feature list is essentially borrowed from other operating systems. Its distinguishing characteristic is that (drum roll) it's free! In fact, it was originally written because Linus Torvalds wanted to use Unix on his PC but didn't want to pay for the commercial Unix systems. Does this sound familiar yet?
To repeat myself (now I guess I am Redundant
In other words: the same people who are up in arms about Freemware ought logically to be up in arms about the very operating system they are running it on! Anything less is inconsistent at best and hypocritical at worst.
Hope this makes my point clearer,
Daniel
I have a request: please stop ripping off AT&T by running that UNIX[tm] wannabe!
Thanks,
Daniel
You have to understand that Linux has gone mainstream already. This means that free software developers are no longer the majority of its user base.
I fail to see how this is relevant to your point. The people who are, as you imply, diluting the number of programmers would never have looked at this project anyway! The only difference is that now they're ignoring it while running a free operating system, instead of ignoring it while running a proprietary one.
Daniel
*But* Linux still has many more years of development behind it than HURD.
Actually, that's not quite true. In fact, I think that the Hurd has been around longer than Linux. The problem as I understand it is that it's an experimental design, and they keep deciding to throw out or rewrite parts of the system, whereas Linux is based on the well-known Unix kernels. Recently there seems to be a significant amount of forward progress, and I wouldn't be surprised if things get a lot better over the next year. Or they might not
Daniel
DOS and Linux were very different, while Hurd and Linux are very similar.
;-)
I think you need to learn a little more about the Hurd before making a statement like that. Start by reading some of the other posts on this thread
Daniel
Periodically, someone comments that warnings should be sent to admins of systems whose systems are linked to from here, just in case the load is too much. But linking to a system running an experimental operating system should probably fall somewhere under premeditated assault.. ;-)
Daniel
Jason, I apologize for the negative and critical tone of the earlier post. libapt is truly wonderful; I was just attempting to point out a few things that could be improved. I'm still not convinced about point #1, and I don't remember getting an answer to #3. I'll go check my mail archives. :) I believe my message to debian-deity has more information. Could you explain at length why this is not a good idea, and what (if anything) could be done to make it a good idea?
/usr/doc claim exists but has turned out to not be useful (I believe I actually asked you about InstallVersion and xstatus, and was told that they were experiments that weren't relevant anymore), and it's difficult to find out what any given function does in full. :-\.
:-/
I actually queried the mailing list on #2, but I haven't gotten an answer. I think this is an important ability, mainly because it's required for a really nice (IMO) UI feature I have in mind
And finally, I'm sorry but I still don't agree on the documentation issue. I have several times run into stuff that the files in
Usually I just end up tracing through the source code to find out; a brief collection of documentation that gives a more high-level overview of Workers, CacheFiles, Acquire queues, and all the other stuff would make it a lot easier to get up to speed; while you can guess in general what these do, the specific relationships between them are not always clear and the documentation in the headers is somewhat spotty. If you want, I could actually probably write up some general libapt documentation -- but I have to admit that I'm also guilty of "I'd rather code"
How the system works can be pieced together from the source and headers, but that doesn't necessarily mean that the documentation can't be improved.
In general: it's no secret that libapt, like any piece of software, has missing functionality and is constantly changing. But I think that it still has a little ways to go before it does 'anything you want'. It might never be there, since everyone (as I've just demonstrated) defines 'anything' differently. So maybe my complaining is totally pointless. Or something...
Thanks,
Daniel
I'm really starting to think that that post was a mistake. Chewed out by you and Wichert in the same day..it has to be some sort of record..
I'll see whether that works -- but I believe that apt locks the dpkg status file when told to lock anything (with good reason!), so I doubt that the dpkg call will work. libdpkg might.
Daniel
Which is as it should be. If a user want to keep logs, she can use shell redirection.
;), but my point was that libapt is very far from supplying 'everything you could want' to build a frontend.
No, you misunderstand totally (I think Wichert did too, I may not have expressed myself clearly). I don't mean keeping track of what *was* installed, but rather keeping track of what's *going to be* installed. That is: I decide to install package foo, so I tell the frontend to mark foo for installation. The frontend does, and happily marks bar, baz, and frobozz as well. I have no direct way of finding this out via libapt; moreoever, the *frontend* doesn't know. The latter problem prevents the implementation of an undo command.
There's a workaround for this, but I personally think it's ugly. This isn't really the worst problem, though, and libapt is arguably correct in its behavior here.
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
Again, this is exactly the kind of thing which should be handled by a front-end. In any case, a user can always hit Ctrl-C during a download, edit the command line, and apt-get will recover quite nicely.
Perhaps you didn't read what I wrote? There is *no* *exposed* *way* in the libapt API (at least, none that I can find, and I've looked for a while) to terminate a single download process. That is, if the user starts a large download and then decides that everything's ok, but that one Netscape package shouldn't be installed, the *whole* download has to be stopped and restarted.
The Acquire system is also not very well suited for background downloading (ie, in a separate thread).
-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
You can put packages on hold using dselect (an annoying program, IMO, but functional), though admitedly I've had apt loudly proclaim it was going to over-ride my hold on a package, and then proceed to enthusiasticly upgrade it without even prompting me. I should probably submit a bug report on this, I suppose, but at least it acknowledged the hold was there.
Yes, and my frontend automatically inherits dselect's selections when it starts (err..the CVS version does, got to upload the tree to Sourceforge one of these days..) but there is no way to modify the saved state from apt (unless I'm mistaken, Wichert said he thinks I am, so I may very well be), which makes it useless as a replacement for dselect at the moment.
I expect that some of these will eventually be fixed, or that people will yell at me to be more creative in working around them
Daniel
I didn't notice that you mentioned it. Thanks! :-\
/libapt/? I've been thinking that I'll have to write my own routines to handle the dpkg status file if I want to do that.
I haven't announced it in any official way yet, simply because I want to get a reasonable amount of functionality (ie, downloading and installing packages) first -- I don't want to announce total vapor on the mailing lists; I feel comfortable doing it on Slashdot, I guess. I'm not sure what that says about me..
It has been possible to put a package on hold for ages though, perhaps you missed something?
Can you actually put a package on hold from
Thanks,
Daniel
Because this isn't FreeBSD, it's *Debian* BSD. The Debian system is based on glibc, and using a single library across all Debian systems would theoretically make it a lot easier to debug problems and so on.
Also, you'd get some level of binary compatibility if all programs were ELF and dynamically linked against libc -- only direct syscalls would have to be fixed up, and I don't think there are many of those..I've heard that even syscalls (from C) can go through libc, so mainly you'd need to worry about assembly code.
Daniel
The apt library is really powerful and does everything you want it to do,
In fact, the poor and out of date libapt documentation aside, this isn't true. Among other things, libapt isn't good at:
-> keeping track of automatically performed selections and removals; each frontend has to do this itself
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
Not that it isn't a wonderful tool, but it's not perfect -- not by a long shot.
Daniel
Shameless plug: I have a very early prototype of an alternative apt frontend at
aptitude.sourceforge.net
. Please download it and send me comments so I can fix problems in the next version!
Given that people get into..um..heated arguments on debian-devel about exactly this question, I don't think it's quite as silly as you think ;-)
Daniel
libapt-pkg takes care of the protocols, pulling data off the servers and so on, but I still have to call functions to start the download and do something sensible in terms of display while it's progressing (the display being the sticking point). I'm currently investigating just how far I can push libapt -- I have some extremely nifty interface ideas for the download screen, but they may not be possible with the current API.
Daniel