Slashdot Mirror

No, they have no rights that are not moral rights. Since it is far from clear that there is such a moral right... is also follows that they may or may not have such a right. [...]If there is no need to loan a copy, they how can the authors be so upset over "piracy" ? Clearly, it's not theft at all.

I'm going to presume you're not just trolling, although it's hard to tell. Here's the scoop:

They put the software out there and say "If you're going to use this, pay us; if you don't think it's worth paying for, don't use it." If you take their software, use it, and don't pay, from their perspective it's hard to interpret that as other than a big "fuck you".

Do they lose anything? For an individual case, it's hard to say, but statistically, it's certain: at any given price, some of those people would have paid, and all of them would have paid at some price. $50 too much? How about $5? $0.50? $0.000005?

Do you gain something? Assuming you're not a moron, sure, or you wouldn't have bothered to invest the time to take their work.

So you get something for nothing, and they get nothing for something. Great deal, eh? Maybe it's unclear whether they have a "moral right", but it's pretty clear that you have no right, moral or legal, to boost their work and then step up on a soapbox and wag your finger at them.

So if you aren't going to bust open your piggy bank and send them a little dough, howzabout you stick to the tens of thousands of packages that were given away freely? Or better, maybe go out and write something?

So, of course, can X11 users thanks to xodo (link to archive on ibiblio, couldn't find an official home page. There are RPM and DEB varities, too, plus a special version for KDE. So, if you're into this sort of thing, there's no need to switch to The Other OS just to get your dose. ;^)

RPMs should be released as soon as someone builds them, follow what the other comment said (use `up2date` and check RedHats errata page) or just go to RPMFind and refresh repeatedly until a new RPM is posted. :)

There's a source rpm here:
http://enigma.freshrpms.net/rpm.html?id=615

Or, just search RPMFind.

The main FTP site seems to be down, but at ftp://ftp.gnome.org/pub/GNOME/MIRRORS.html you can find a list of mirrors.

A few of them are:

ftp://ftp.cse.buffalo.edu/pub/Gnome
ftp://ftp.rpmfind.net/linux/gnome.org/
ftp://ftp.sourceforge.net/pub/mirrors/gnome/
ftp://ftp.twoguys.org/GNOME

RPMFind also seems to still have the RPMs for bnetd.

RPMFind also seems to still have the RPMs for bnetd.

or "rf:gaim" to search freshmeat?

I just thought I'd make a correction for people who are not familiar with this (totally freakin' awesome) feature.

rf:gaim - The "rf" is for searching RPMFind.net
fm:gaim - The "fm" is for searching FreshMeat

You can see many more things available to you by going to:

Control Center --> Web Browsing --> Enhanced Browsing

Very cool stuff...

what's the difference between this kind of subscription and Microsoft's ?

If you don't pay Red Hat, you can still use the software you have, and you can get new software off rpmfind. If you don't pay Microsoft, on the other hand, you lose your right to use the software because under a rental agreement, you are not the owner of a copy, and in the United States, 17 USC 117 states that the owner of a copy can dictate terms of use.

Its really easy to fix: webfonts-1-3.noarch.rpm

Make sure to read the MS Eula included.

try this: corefonts

and this:
webfonts

Because you're supposed go to rpmfind and install the rpm instead?

FYI, the MS eula is in the rpm.

Because you're supposed go to rpmfind and install the rpm instead?

FYI, the MS eula is in the rpm.

I love LyX. The xforms user interface is very clunky, but the printed output is always very professional looking.

You may want to have a look at LyX with KDE user interface (KLyX) then (no binaries there; try this klyx page on rpmfind.net).

The LyX people write that it is currently unmaintained, but the last version I tried worked quite stable.

I was browsing rpmfind.net a few days ago, and I found a bunch of packages in Mandrake Cooker which were modified for LSB compatibility. That's probably a good sign.

Where to Get Packages
You'll find a lot of this stuff is included on the installation cd's of most distro's, or you can follow the links. Wherever possible, these point to the project's homepage, or else to rpmfind's download site. If you're using something other than a RedHat style distro, you may have to backtrack a bit from the rpmfind sites to get the right version.

No offence, but fuck backtracking :). There's been a billion tools to download apps and their dependencies, and Ximian's Red Carpet and APT are two of the best - between the two there's very little software which isn't available packaged to work on a Red Hat box.

Best of all, freshrpms.net is now available via APT. Freshrpms is an invaluable source of this kind of stuff - eg, if you're into DVD, its always up to date with the latest Ogle, Xine, Transcoder and Drip packages. Furthermore, Matthias from Freshrpms does requests: just name the software and he'll package it. He's also a bloody nice guy and writes tutorials on how to package properly too, asking for very little in return. Freshrpms is easily the best Red Hat package source out there.

Anyway, get APT here. Install it, then stick the following in your /etc/apt/sources.list

rpm http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os
rpm http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os
rpm http://apt-rpm.tuxfamily.org/apt redhat-extra-7.2/redhat extra
rpm http://apt.freshrpms.net freshrpms/7.2 main

rpm-src http://apt.freshrpms.net freshrpms/7.2 main
rpm-src http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os
rpm-src http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os
rpm-src http://apt-rpm.tuxfamily.org/apt redhat-extra-7.2/redhat extra

As you probably know, Ximian Gnome including Red Carpet is available from ximian.com. Combined with APT they provide a way to run up to date software on a stable distribution using standard packages, which as far as I know isn't available from anyone but Connectiva, Red Hat, and Polished Linux Distribution.

With the latest versions of Mandrake, you can use a tool called drakfont that will import your windows truetype fonts. It's a nice GUI application and you just press a button. May I suggest that if you want to do everything the very easiest way, that you choose a distribution that is renowned for making things much easier.

People often become upset because you start blaming them for not fixing something when they have gone to the trouble of finding workarounds (or sometimes outright solutions) and written them down the best they can. Then you say you say you can't be bothered to read the workaround? Are the guides not clear but you can still understand the process? Please give back and rewrite the guide in a clearer simpler form.

It's one thing to say my distribution ships with fonts that make Netscape suck. But maybe there's a reason for that - making them not suck in all circumstances might not currently be possible out of the box...

[ rpmfind.net HTTP mirror here ]

[ rpmfind.net FTP mirror here ]

(Just downloaded two ISOs from there, it's pretty fast.)

[ rpmfind.net HTTP mirror here ]

[ rpmfind.net FTP mirror here ]

(Just downloaded two ISOs from there, it's pretty fast.)

Ummm...

The apt package was ported to RPM distribs months ago...

Next?

FOR IMMEDIATE RELEASE

KDE Ships Alpha of Third Generation of the Leading Linux Desktop for Developers

October 5, 2001 (The INTERNET). The KDE Project today announced the immediate release of KDE 3.0alpha1, the third generation of KDE's free, powerful and easy-to-use free Internet-enabled desktop for Linux and other UNIXes. KDE 3.0 is scheduled for its first beta release this December and for final release in late February 2001.

This inaugural release of the KDE 3, which follows two weeks after the stable release of KDE 2.2.1 series, is based on TrollTech's Qt 3.0.0beta6. It ships with the core KDE libraries, the core desktop environment, and over 100 applications from the other base KDE packages (administration, multimedia, network, PIM, utilities, etc.).

The primary goal of the 3.0alpha1 release is to provide a framework for developers to start porting their KDE 2 applications to KDE 3 and to solicit developer feature contributions and feature requests before the KDE 3 API is frozen for binary compatibility. In addition, experimental KDE users who would like to try this release can set up a KDE 3 system side-by-site with a KDE 2 system. Instructions for doing so are available here.

Additional information about KDE 3 is available at the KDE website, including a tentative release plan, a KDE 3 info page, and a list of planned features.

For both developers and users, KDE 3 offers substantial improvements and additions compared to KDE 2 (the great bulk of which are, at this juncture, due to the switch to Qt 3):

For the developer:

For everyone:

Most of these improvements result directly from the switch to Qt 3, which has been the focus of KDE 3 code development so far. Improvements to the KDE libraries and applications themselves are planned for the successive beta releases leading to the first stable KDE 3. A list of these planned features is available here.

Since KDE 3 is mostly source compatible with KDE 2, porting applications from KDE 2 to KDE 3 can usually be done surprisingly quickly. The process is substantially easier than it was for porting from KDE 1 to KDE 2, and even very complicated applications can be ported in a matter of a few hours.

Instructions for porting KDE 2 applications to KDE 3 are available separately for the KDE libraries and the Qt libraries. Most of the changes required for the port applications pertain to changes in the Qt API. Although neither the KDE 3 nor the Qt 3 APIs are frozen, few changes are anticipated for the final releases of KDE 3.0 and Qt 3.0.0, respectively.

KDE and all its components (including KDevelop and KOffice) are available for free under Open Source licenses from the KDE ftp server and its mirrors and can also be obtained on CD-ROM.

Library Requirements. KDE 3.0alpha1 requires qt-3.0.0beta6, which is available in source code from Trolltech as qt-x11-3.0.0-beta6.tar.gz, as well as libxml2 >= 2.3.13, available here.

Compiler Requirements. Please note that some components of KDE 3.0alpha1 will not compile with older versions of gcc/egcs, such as egcs-1.1.2 or gcc-2.7.2. At a minimum gcc-2.95-* is required. In addition, some components of KDE 3.0alpha1 (such as the multimedia backbone of KDE, aRts) will not compile with gcc 3.0 or 3.0.1, though the forthcoming gcc 3.0.2 release will most likely work.

Source Code. The complete source code for KDE 3.0alpha1 is available for free download at http://ftp.kde.org/pub/kde/unstable/kde-3.0-alpha1 /src/ http://master.kde.org/pub/kde/unstable/kde-3.0-alp ha1/src/ or in the equivalent directory at one of the many KDE ftp server mirrors.

Further Information. For further instructions on compiling and installing KDE 3.0alpha1, please consult the installation instructions and, if you should encounter problems, the compilation FAQ.

KDE is an independent, collaborative project by hundreds of developers worldwide working over the Internet to create a sophisticated, customizable and stable desktop environment employing a component-based, network-transparent architecture. KDE provides a stable, mature desktop, an office suite (KOffice), a large set of networking and administration tools, and an efficient and intuitive development environment, including an excellent IDE (KDevelop). KDE is working proof of the power of the Open Source "Bazaar-style" software development model to create first-rate technologies on par with and superior to even the most complex commercial software.

Please visit the KDE family of web sites for the KDE FAQ, screenshots, KOffice information and developer information. Much more information about KDE is available from KDE's family of web sites.

Besides the valuable and excellent efforts by the KDE developers themselves, significant support for KDE development has been provided by MandrakeSoft and SuSE. Thanks!

Go Mandrake. Pure and simple.

Mandrake has two wonderful package managers:
1) rpmdrake - full GUI-based package management
2) urpmi - a command-line rival to apt-get

Both of these, like the apt system, allow you to add extra media - CDs, directories and http/ftp URLs. In addition, their dependency checking and auto-resolution is excellent. Also, the search facilities are really good.

In contrast, I found Redhat's package management confusing to say the least.

To get even more 'oomph' in package management, you can install the rpmfind utility, which (in a way) is like apt on steroids

As for which installs more stuff, I'm not totally sure, but I know that Mandrake makes it easier to control what gets installed, so by spending a little time during setup (easy!), you can end up with something quite compact.

In conclusion, I feel Mandrake well deserves to be seen as the reference Linux distro, and one I'd recommend to any Windows emigrant.

If you go here and search for any particular RPM, you can see what it needs before downloading it.

http://rpmfind.net//linux/RPM/sourceforge/heroines /bcast-2000b_va-1.i386.html

One thing both debian and mandrake have in common is a convenient way to get security updates.

Indeed, if you're tied to a GUI. Don't get me wrong. I love Mandrake (and am typing this with it now), and have been using it for a few years (or so) now. The biggest thing I hate about any RPM based distro is the dependency hell that is easy to fall into.
Debian-based distribs have this super-easy-to-use-and-love-app called: apt. "apt-get install upgrade". What can be easier than that to get the latest updates? Well, guess what: Conectiva Linux (from Brazil) reworked apt-get to work with RPM. This is SO wonderfull. Not all distribs have caught on, but MDK was the first (that I noticed) to notice Conectiva's work.

Enjoy!

P.S.
Read the man page for use... (man apt-get)

(Linux is a great way to put older Mac Hardware to use!) Mandrake offer's great online installation instructions, too! Also, check out the Mandrake Linux PPC 8.0 FAQ (it says "beta", but applies to the more recent releases, as well.)

Curious George

Sudo is in the ports collection for FreeBSD, no idea about linux though

sudo pacakges at RPM Find.

I went through this phase of trying to fix up the memory of all the code I'd ever written. I found ccmalloc to be the best. Its the easiest, instead of gcc -o prog prog.o you just prefix with ccmalloc eg. ccmalloc gcc -o prog prog.o. It provides a nicely formatted output log file, with configurable filtering, showing the stack trace of each unfreed leak, and also catches over/underflows, and lots of other stuff. hint: if you are using the c++ std library get g++-3 (with libstdc++-3) and #define __USE_MALLOC to disable malloc pooling. RPMs here

Side note: gv works just as well as Acrobat to view PDF files from netscape as a helper app (and PS too, of course). Just add "gv %s" in as the application to handle the file types for PostScript and PDF(edit->preferences->helperapps or something like that). Personally I like gv's navigational structure better anyway.

(Well, /path/to/gv if it isn't in your path, naturally.)

Very rarely I will run across a document that gv just doesn't like but that Acrobat displays fine. This happens maybe once a month, if I'm looking at a fair amount of pdf's.

I think the software dependencies for gv are ghostscript and whatever dependencies it has but I'm not sure. apt-get or rpmfind.net or your ports tree are your friends in that regard.

You mean an ASCII version of Tux like this? I believe it's done using kernel source for the text. There are numerous RPMs for it found by searching on Google, including this list. If you're in to alternative Tux logos, look here, referenced by the earlier Slashdot article. Not sure about the more general "images into Tux" software, though.

I like the idea of there being many repositories for third-party or special packages. There are lots of these for both .deb and .rpm packages. For RPM there is even the rpmfind.net system for searching repositories of RPM by various criteria.

What is lacking is some way to identify which packages can be trusted and which can't. For instance if you go to the rpmfind.net homepage you'll find out they their DNS was hacked and that any RPM's downloaded recently should be suspect. There is no way to verify RPM or DEB packages other than a PGP signature. Most thired party packages don't include a PGP signature, and even when they do there is no way to verify it, and even when there is little way to use that as a basis for establish trust. Even if you know the package was signed by "Joe Smith" and "Jim White" has also signed Joe's signature, you don't know why you should trust either of them.

Both DEB and RPM could benefit from a system for identifying what a package should and shouldn't do if it is to be "trusted" and what information about the package and packager should be verifiable, and how it can be verified.

http://rpmfind.net/linux/RPM/cooker/cooker/contrib /RPMS/wedit-0.9.8-1mdk.i586.html

--

Both DEB and RPM support signed packages, but at least most software installed on a Debian system over the Net is by apt-get, which uses specific sites to fetch most of the packages you'd ever want. On RPM based systems, I'm always resorting to a hunt for packages on rpmfind, where their origin is less clear.

will this grow into RPM's for Redhat systems becoming "SPECIAL"? Won't I be able to go to rpmfind.net and locate updated RPM's by platform because they won't have REDHAT RPM's? I can't see RedHat placing restrictions on redistributing the updates, it just wouldn't be 'Linuxish' of them.
If there isn't one now, somebody will code us a tool that uses rpmfind.net to inventory system packages and check for updates automatically. There's nothing that will slow down the Linux Movement, I doubt a major distributor charging for updates will make much difference.

Microsoft has released a set of high quality TrueType web fonts: Times, Courier, Arial, Comic, Impact under a license that allows free use and redistribution.

Get it Here.

The extension is .exe but it's a self-extracting zipfile. You can open it with unzip.

Someone has also packaged it as an RPM

-

Debian has a semi-usable distribution for Ultra Sparc. I beleive they have Xfree working, among other things, along with the trivial ports that just require a linux kernel

dont forget mandrake. they also have a version for sparc: ftp://fr.rpmfind.net/linux/Mandrake-iso/sparc/

although it is beta. i must confess that i have never used it, but i would think it's at least semi-useable.

use LaTeX? want an online reference manager that

-----
"You owe me a case of beer. Sucka'."

The first problem you describe essentially requires that you have an RPM or dpkg database that is prepopulated with all the information from all packages out there in "packageland."

It might be a reasonable thing to try to extract such information from some place like RPMFind.net ; but the essence of the matter is that you need to have all the packages available for query, which is not likely to be the case on your PC at home if you're using APT to get at packages remotely.

As for the second problem, of "recursiveness," there's both a touch of inherent danger, and an answer with APT.

• The danger part is that a recursive install probably isn't what you want. Two packages might depend on one another, and this would naturally lead to a loop where neither dependancy could be satisfied.
• The flip side is that apt does do pretty much the "right thing." It recursively looks up the dependancies in order to generate a full list of packages to install, and then essentially tries to install in parallel.

  The parallel aspect of this resolves most of the problems you suggest.

In effect, the problem is that RPM could use a "helper" rather like APT in order to cleanly satisfy dependancies for a clean install of software.

It's not that RPM is "broken;" it's that it really needs that "soul mate/life partner." :-)

Complaining about a free service. sheesh!

modutils might cause a bit of a problem, since http://rpmfind.net/linux/rpm2html/search.php?query =modutils doesn't list any 2.4.0 RPMS. Latest seems to be 2.3.24.

Mandrake Cooker (rpmfind link here) tends to be right on top of all the latest software releases. They usually have an RPM within a week of a new release.

As you point out yourself, "standard" DLLs pretty much destroy this point of your argument. For instance, lots of programs share the Microsoft Visual C++ runtime libraries on my computer. If Microsoft discovered a catastrophic bug in msvcrt40.dll or mfc40.dll or any other DLL, I would only have to replace one file. Have you ever installed a program and seen an alert that asks you to confirm the replacement of a DLL with a more recent version?

Ofcourse, using a standard DLL in Windows to perform certain tasks doesn't require it to be part of the Operating System, but in what other way can you be certain that all your potential customers have it installed?

Ah, now this point provides ripe fodder for a rant. The quick answer is, they don't know if their customers have it installed. So they bundle all necessary DLLs with their installer. This is a pretty fucked up part of the Windows software distribution world, that people are constantly and unknowingly downloading msvcrt DLLs and other DLLs that they already have on their computers.

If I'm installing Enlightenment on my Linux box, I need imlib (amongst other things). How do the Enlightenment folks know that I have the proper version of imlib on my computer? They don't. They don't care. Having imlib is a precondition to being able to run Enlightenment, and the onus is on me to install it. In fact, if you go to Rpmfind.net, you'll find that pretty much every RPM they have requires that you have some other stuff installed.

Does it suck that I have to install these libraries and ancillary programs? Is it inconvenient? No. The reason is that there are nice graphical applications that install my Linux software for me (some better than others), and they can automatically check dependencies for me and download and install the required shared libraries. Even in the absence of such a handy application, I'm a big boy and can cope with following links to download required libraries if I don't already have them.

Now, many Windows users aren't big boys. I remember downloading a few programs over the years from sites that offered different versions of their installer depending on which libraries you already had installed. I liked this a lot, but many Windows users wouldn't know what the hell they were talking about. I'm sure most people could learn to download libraries on their own if they had to (although these libraries would probably get left behind when they uninstalled), but they shouldn't have to. There should be a nice installer mechanism that downloads, installs, and keeps track of all required libraries for you. If Microsoft wanted to bundle a useful program with their operating systems that scored mad points in the battle of modularity and code reuse, this strikes me as a nicer choice than foisting IE on people.

It would be nice if the system were such that if a company decided that Mozilla's HTML rendering engine was superior to Microsoft's and chose to use it in their product, they could do so without having to worry too much about the bloat it would introduce in their installer download.

Who made you the authority in determining the requirements for a "package management system"?

Nothing does, and I'm not. As said in the original post, what most people [IMHO] define as packaging systems contains those criteria. And [for a something more concrete than opinion] that every other software installation method apart from Slackwares that describes itself as a packaging system contains these features.

Draw your own conclusions from the latter, but mine is that the popular definition of a package management system includes dependencies as a base feature.

There are conventions for RPM naming. They're usually stuck to, apart from the odd CVS extracted package, where there doesn't seem to be much of a standard [CVS packages are very rare though].

To use your example, seach for libglade on RPMFind. And see, out of the hundreds of results, which packages are misnamed.

From what I've seen, Moonlight 3D seems to create some very nice images. Does anyone have recommendations for 3D modeling/rendering programs that will produce images of a quality that's at least as good as Moonlight 3D?

No argument there. rpmfind is a great site, and a fantastic resource.

I have to say I have never broken my system by installing an RPM in Redhat.

Neither did I when I was running it. Had some very hard times with some .rpm's, and gave up eventually, but never broke the system (to the best of my memory) with .rpm's. The point I was getting at was that I never felt I could trust the upgrade cd path. I've never had such an issue of trust with Debian's package manegement system.

Oh, and I don't recall even an update of any sort doing any weird things. Maybe I'm just lucky, but no upgrade has done weird things for me.

If RPM is so bad why don't SuSE and Mandrake use dpackage/dselect? (Debian still uses those right?)

And if Windows is so bad why do corporations use it and rely on it? That's the same sort of logic being employed in your statement. That being said, though, I should state a couple of things I didn't state before. 1) RedHat, as a corporation, has my approval. They seem to be staying true to the Open Source ideals on which they were founded. I applaud them for this, and wish them success. 2) RedHat Linux is an okay distribution of Linux. It does some things I don't like, but then again, Debian's installer is the installer from hell. The 2.2 installer is finally where Slackware was 5 years ago with the 1.2 kernels. 3) You're right, each distro has its good points and its bad points. I personally find (for me) that Debian's good points outweigh RedHat's good points. I also feel the Debian has fewer negative points than does RedHat. However, that's my opinion, and I want to restate this one piece of it:

RedHat is doing a great job, and I wish them well.

I'll give you even odds that it will also exist in .deb format. Debian has a collection of packages like you would not believe. Well over 90% of the time, I go to install a package, and find it ready to five minutes later (by typing in 'apt-get install package). Of the remaining times, I can still, more often than not, go to the next rev of Debian (unstable), find the package, and install it, without breaking my system. Ever.

www.rpmfind.net has got to be the best resource for finding packages for any RPM based distro. Occasionally when I try to install an RPM and I get that pesky "missing libObscureAsHellLibrary.so", I can go there and search the available RPMs by filename. Very nice.

I have to say I have never broken my system by installing an RPM in Redhat. I imaging if someone has they were trying to install something with a --force or --nodeps switch, which means you better know what you're doing in the first place.

Let me repeat that: In the year and a half I've been using Debian, I have never broken my system due to installing a package of any sort, and I've done very regular upgrades of the software. And it stays running.

I can't remember ever breaking a Redhat system by simply upgrading packages. I admit that upgrading to a .x release did some wierd things, but that's expected whenever upgrading just about any OS. Perhaps Debian is an exception, but that doesn't make Redhat less than average in that department.

With RedHat, I've never been willing to even attempt system wide upgrades, and so have always wiped out previous installs and re-installed with a new rev of RedHat. No such fear with Debian. As I said before, I must disagree: RedHat, for me, is not the way to go. Debian is.

The nice thing about Debian is they are way more conservative with their OS revisions. The nice thing about Redhat is they have more up-to-date packages, b/c they release more often than Debian. With a more rapid release schedule, you can expect to have more problems than a distro with a not-so-rapid release schedule.
I use Redhat 6.2 at work for users Linux workstations and on servers, and I have to say that it's a great all around distro.

I'm not knocking Debian or other distro's, they all have their ups and downs. I'm just saying that Redhat's not evil as some people here like to make them out to be, and RPM is a great packaging tool. If RPM is so bad why don't SuSE and Mandrake use dpackage/dselect? (Debian still uses those right?)

Just a note - if you've got a stock RH7 box that you're planning on installing this on, you'll want to make a trip over to http://www.rpmfind.net and pick up the RH7 rpms for zip and unzip (just do a search and look for the green highlight) as the KDE rpms complained about not having them (why they didn't install by default is beyond me - I'm just passing the info on.)

I'm going to upgrade so I can start fresh. When I first started using Linux full-time a year ago, I was a newbie, so I did a lot of stuff that, if I knew then what I know now, I sure as hell wouldn't have done. As well, I have a rather ugly mishmash of new packages and old cruft from Red Hat 7.0 that somehow works just fine, thank you very much. I just want to clean it all up in one fell swoop while taking advantage of some newer features with a bit more knowledge and wisdom under my belt than before.

Another reason is that I'm pretty sure newer RPMs from RedHat's rawhide dir are no longer compatible with older distros - they're being compiled using a new version of glibc. If I install it (and I've tried), every other program on the computer complains. I'm not sure if RH7 uses the new glibc, but better safe than sorry. (Or maybe bero-rh would like to enlighten me:)... At this point, it will be easier to upgrade to 7 and install whatever updated packages I need - despite the whinging of some (ok, most) people, RPMs aren't hell to upgrade, especially if you make liberal use of RPMfind.

Hell, maybe I should have just installed Mandrake. Or gone over to Slackware.

Ain't choice grand?:)
-------------

Unfortunately, there is still no coherent architecture for mirroring and for mirror sites to register their collections with the sites which they mirror. In fact, we lack even a common (de facto) standard for recording this replication information in a machine readable for-mat. Some progress was made on this a few years ago by the Internet Engineering Task Force s [1] working group on Internet Anonymous FTP Archives, with the creation of the so-called IAFA Templates [2]. These provided a simple machine readable format for recording per-resource or collection metadata, which could easily be created by hand or programatically. Although support for IAFA templates was integrated into some software packages, e.g. the ALIWEB search engine [3] and the ROADS resource discovery sys-tem [4] , this approach never became successful on a large scale. The World Wide Web Consortium s Resource Description Format (RDF) [5] and the Dublin Core metadata effort [6] may eventually provide a viable machine readable interchange format.

Currently, the database underlying the freshmeat.net weblog [7] is perhaps the closest thing we have to a genuine mirror registry - though it focuses almost exclusively on soft-ware packages and operating system distributions, and only offers limited mirror informa-tion. RDF is also being used in this capacity as part of rpmfind.net [8], although mirror information is very limited in this case too. The Internet Engineering Task Force s Uni-form Resource Names effort [9] is also relevant here, since it would be very useful if there were persistent and location independent names for these collections of replicated resources.

[1] http://www.ietf.org/ Internet Engineering Task Force website
[2] http://info.webcrawler.com/mak/projects/iafa/ IAFA Working Group & IAFA Templates homepage
[3] http://aliweb.emnet.co.uk/ ALIWEB website
[4] http://roads.opensource.ac.uk/ ROADS website
[5] http://www.w3.org/RDF/ World Wide Web Consortium Resource Description Format (RDF) homepage
[6] http://purl.org/dc/ Dublin Core website
[7] http://freshmeat.net/ freshmeat.net website P. Lenz & Andover Advanced Technologies, Inc.
[8] http://rpmfind.net/ rpmfind.net website
[9] RFC 1737, Functional Requirements for Uniform Resource Names K. Sollins & L. Masinter December 1994

And at the end somewhat less relevant to the topic.

This kind of metadata should be extremely valuable for implementation of the URIs and particularly for the I2C(s) (URI tp URC). Quote from the RFC 2483:

"Uniform Resource Characteristics are descriptions of resources. This request allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resource's URLs. The description might be a bibliographic citation, a digital signature, or a revision history. This memo does not specify the content of any response to a URC request. That content is expected to vary from one server to another."