Slashdot Mirror

And! Again! With the ad hominem insults about OCD! If there was any substance to your claims you wouldn't need to try personal attacks. Windows one-size-will-fit-everyone approach does not mean that Windows package management is any good. Have a look at this for a real package manager, and that's from 1997.

RPM does this. http://www.rpm.org/max-rpm/ch-rpm-verify.html - Chapter 6. Using RPM to Verify Installed Packages.

http://www.rpm.org/software/gui/

What, like RPM?

For those not in the know:
http://www.rpm5.org/
http://www.rpm.org/
http://en.wikipedia.org/wiki/RPM_Package_Manager#controversy

Sure it shouldn't corrupt itself, hopefully the code cleanup will help with issues like that.

However, you can rebuild the database (it's not like it's gone forever...):
http://www.rpm.org/hintskinks/repairdb/

Just now I am writing this from my university PC with Fedora, I do not have root access hence I can not install and run any new software. If I want to run something new I need to download the tarball and compile it, provided that the required libraries (with the required version) are isntalled, otherwise I am screwed. That is a flaw!

Not a flaw, basic sysadmin'ing... don't want to users fucking things up.

With the --prefix and --root switches for rpm, you can install software&libraries in your home directory.

Chapter 2. Using RPM to Install Packages

Please someone provide a repository of statically linked open source software.

The downside with statically link executables is if there is a flaw(e.g. buffer overflow) with a library, you need to recompile&reinstall all the executables that have that library statically linked. Dynamically linked means just need to re-compile the offending library and restart the executable.

If you ever start to care for & feed a machine or three, you'll start to see there is a method to the madness.

As another poster pointed out, the archive must have a .spec file in it and you may need some -devel packages for the build. Many tar.gz's unfortunately lack the .spec file, although an increasing number of projects seem to have them. You could also do something like ./configure --prefix=/somewhere/else, run make install to that location, and then cook up a .spec file to pick out the files. (I did something similar with a bunch of fonts I used in LaTeX.) Visit Maximum RPM for more information.

Regarding format, though, I still believe DEB's win for flexibility, accessibility, and a simple, straight-forward design. Baroque is hardly the word to describe the "./debian" maintainer scripts directory. What does one find in "./debian"? control, changelog, copyright, README.Debian, rules (the build Makefile), and optionally the prerm, postrm, preinst, postinst scripts. Whatever else a maintainer puts in that directory that is useful for the build process is entirely subjective to the helper tools they might use (like debhelper).

DEB's are simply two tarballs archived together, data.tar.gz, which contains the package files themselves, and control.tar.gz, which contains the maintainer scripts. If you did not have dpkg installed on your system, but wished to extract the files and information from a DEB, you would simply use the tools ar and tar. To do the same with an RPM is to open up a hex editor to find the end of the RPM header, then use dd to cut it off and output the remaining tarball. (RPM format) How many people know or want to know how to do that?

The other flexiblity that DEB's have that RPM's don't (didn't?) is that maintainer scripts can be written in any language the maintainer wishes, as long as the interpretor is installed at the time the script runs. If you're maintaining a Perl package, it's reasonable to assume that Perl can be installed as a (pre-)dependency and used to run the maintainer scripts.

Debconf, for example, is one of those optional helper tools the maintainer is encouraged to use when questions must be asked of the user/administrator at installation time. Gone are the days when DEB's could not be installed unattended. Using Debconf allows the maintainer to provide those questions, and allows the user to view them using one of multiple interfaces, or to ignore them completely. Additionally, po-debconf makes it trivial to add multilingual support for those questions.

There is plenty of documentation, utilities, and helper tools to create a Debian package, and on-line resources such as IRC, email lists, and forums. An interesting thread to read dates back from 1996, titled "Why the .deb format?". Also, take a gander at this FAQ.

Really, comparing RPM's to DEB's is like comparing apples to oranges. RPM maintainers may baulk at the "debian/" directory and maintainer scripts, but I personally baulk at having to learn yet another spec file format for RPM's and being restricted to using librpm or a hex editor to access the data contained within the package.

it's not like the windows users can run your .rpm packages either.

I think cygwin has an rpm2cpio compile. If not it should be straight forward.

Is msi a format or an executable? If it's a format, there ought to be an msi2cpio, or at least it should be possible. I mean, we have tnef tools on linux. Google shows no hits for it by that name though there might be code to borrow in here.

Actually, according to http://www.rpm.org/ RPM stands for RPM Package Manager (sort of like GNU stands for GNU's Not Unix).

Why limit the discussion to tar--about using CPIO or ar instead of tar?

Oh, wait.

Nevermind.

Rather than "Starter Edition," here's some suggestions, if anyone from Redmond just happens to read this. (I know they won't do it - it's more a mental exercise while I eat)

1. Go download this, and make it natively multi-user if it isn't already. Give it a strong native security model, too...you can get some ideas here, and the best part is, they won't mind you doing that if you don't try and patent said ideas. Also, modularise your GUI, and don't prevent users from accessing the CLI when they want to.

2. Have the CLI composed of this and this for us CLI types.

3. Make the Add/Remove Programs panel essentially a net-aware frontend for either this or this.

4. Use this for hardware detection. Also re drivers, get rid of the suicidal policy of seeing third-party hardware vendors as the enemy, and actually support them...via tools, docs, etc. These people are your friends...they'll help you stay relevant.

5. Download this and use it as your default FS, and then get this and this, (although you already seem to know about this last one) and incorporate both of those into your stock UI. You've essentially got WinFS right there, without all the added complexity you'd no doubt throw into it if you tried to code it from scratch.

6. For the Agent angle, incorporate the last point, as well as putting help/docs in a non-binary format, making them searchable with this, converting said search results for use with this, and then use the AIML output as input for something like this. Also, instead of making the agent a tightly anthropomorphic personality, make it more generic, and more as though it's simply "the operating system" communicating with a user, rather than that dog or Clippit instead.

7. Give Outlook a major overhaul. This and this are examples of directions it IMHO should go in.

Just some random ideas, anywayz. Dreaming's fun. ;) I'll probably get modded Offtopic, but it was worth it.

It says that to build a RPM you run the following command: "rpm -ba foobar-1.0.spec" which hasn't worked for years. Look for yourself here

If you want people to help out you should update the doc! There are so many edge cases and hidden options it is insane and any new developers will pull there hair out. Not only that, but put the documentation in the cvs so everyone can help update it.

For something as critical as RPM Red Hat should be ashamed that their developer documentation is so bad.

-Benjamin Meyer

P.S. NetBSD's pkgsrc is only thing that comes close to a truly cross platform package management/build system.

Really?

It supports Irix, Solaris, NetBSD, Linux, OpenBSD, FreeBSD, OS X, and (to a lesser degree) AIX. I'm sure I'm leaving out a few.

You might want to take a look at http://www.rpm.org/platforms/.

--Bruce Fields

RPM has had the feature you are talking about for a long time. They are called Relocatable Packages. Most RPM's are not relocatable because many people think installing programs in an organized manner is a good thing. So most apps go to /usr or /usr/local, just like most apps under MS Windows goes under C:\Program Files.

There are just as many hardcoded paths in MS windows. Can I change where all my system DLL's are kept? Why do I have to put DLL's in the the Windows, System32 or application directory for an application to find them? Under Linux, I can put them anywhere and just update the LD_LIBRARY_PATH.

Linux and MS Windows both have hardcoded paths for different things. They are both due to design choices and neither are bad or good.

> RPM is a package. Just like DEB.
> Apt is a package manager, just like Yum.
> Please do not confuse them.

You are the one that is confused: RPM is a recursive acronym for "RPM Package Manager." Yum is just an alternative that uses the same format. Observe:

# whatis rpm
rpm (8) - RPM Package Manager

Hmmmmm, let's see...

1. RPM. Read the Linux Standards Base documents?
2. Anaconda, the install/setup program.
3. Kudzu, the hardware detection system used by Knoppix and others.

I could continue, but I think those three on their own more than justify the company's existence, if nothing else.
While I will admit that as an overall distribution I was not overly enamoured of Red Hat 9, RH have contributed solutions to a number of vexing problems for us, and also carry on a very active development effort at sources.redhat.com.
I'm also detecting some of the usual commie whining (No, I don't think OSS is communist, but this is) about a company that's daring to actually make a large profit here...as if every company purely by virtue of its existence had to inevitably emulate Microsoft's bad behaviour. However, it might behoove you next time to be a little more sure of your facts before you start bitching.

You mean just like you don't have to on Linux, either? Thanks for re-affirming the fact that difficult application installation on Linux is a myth.

Roll your own RPMs or debian packages. This give you the benefit of customization plus the benefits of a package manager. Using a package manager really reduces the headaches of documenting what is installed where and what version. If you add sudo to the mix, then you have a good idea of who to ask about the changes as well.

Scribus is a desktop publishing program for Unix and Linux which has been gathering momentum recently. SuSe now proudly proclaim that with SuSe 9.1, Professional layouts can be prepared with the desktop publishing application Scribus. Scribus is also recieving critical acclaim from other big open source quarters such as Newsforge who recently proclaimed Scribus to be one of Free Software's Killer Applications.

ut what is Scribus really like? Can anyone just pick it up and use it? Is it really as powerful as they say it is? And does it live up to the hype surrounding it?

About ScribusScribus is a desktop publishing program for Unix and Linux. It is built with the Qt libraries and is run natively in the KDE desktop environment. Scribus is published under the Gpl and is similar to similar to Adobe PageMaker, QuarkXPress or Adobe InDesign. Scribus has an unusually small development team and is mostly the work of a German programmer called Franz Schmid. The Scribus team are positioning the program as an easy to use DTP publishing program for the Linux and Unix operating systems with support available for professional publishing features. These professional publishing features include:

• CMYK Colour

• Press Ready PDF Creation
  • Further advanced PDF features for making interactive PDFs exist together with a large amount of support for the PDF 1.4 specification including:
  • Transparency
  • Encryption
  • Form Field
  • Annotations
  • Bookmarks

EPS and PDF import/export

Complete ICC colour management

Font embedding and sub-setting in both postscript and PDF exportIn addition to this Scribus also provides:

• A WYSIWYG viewpoint for document creation
• An XML based file format allowing for easier file recovery if corruption occurs
• Drawing tools for custom shapes including: lines, curves, ellipses, bezier curves, polygons, etc.
• Drag'n'drop with KDE 3, including a Drag'n'drop scrapbook for frequently used items such as text blocks, logo images, backgrounds etc

As can be seen Scribus certainly isn't devoid of features, and there are many others in the program which I haven't described above. All in all, Scribus is a fairly feature rich program and more features such as importing from Microsoft Office and OO.org are expected in future releases. Installation of Scribus

I installed Scribus by going to the download section of the Scribus homepage in order to obtain the latest version which at this moment in time is 1.1.6. There are several different methods of installation available, including source and prepackaged files. Prepackaged files are available in the form of RPMs for Red Hat 9, Fedora Core 1 and SuSe 9, Deb files are also available for Debian users.

Since I'm using Fedora Core 1 I downloaded the RPM from the site and installed it. I used the Scribus website instead of a Fedora Yum repository as I have only been able to find out of date versions of Scribus on them. When installing the RPM I did encounter a dependency issue in which I needed to install a program called

I didn't know Red Hat had that many RPMs, much less that you could fit them all on one drive.

I've been debating this with a couple of friends myself, and there's no super-clear answer we've come up with that meets all of the goals. Those are:

o Ease of use/deployment (think server farm)
o Tracking (what was built where and when it was installed)
o Performance
o Reliability
o Maintainability
o Longevity

That last one is what bugs me. I came to Linux via RedHat 5.3, and I've learned how to set up a firewall, a LDAP server (for addresses mainly), Samba, Apache, etc. over the last few years. I'm no guru, but I can install the software and make it work pretty well. I like packaging like RPM except when the RPM database gets hosed, which has happened to me at least twice. No idea why, and it "sucked more than anything has ever sucked before" (okay, not THAT bad, but you know). That speaks directly to the "reliability" aspect. There was a lot of helpful info about rebuilding a RPM db at rpm.org that I found especially helpful then.

But what I run into with an older system such as my personal (behind firewall) mail & web server that's running Mandrake 8.1 is that keeping up-to-date with security fixes and upgrades is that the Mandrake spec files are full of Mandrake-specific stuff that doesn't apply to newer versions. I can usually get updated tarballs and do my own builds, but eventually the spec files need more major overhauls or newer glibc is needed or something of the sort. I haven't found a good solution for keeping the system up-to-date, and I don't want to re-install newer versions every year or so. But that's what I do...

That's an attraction of using the source-code build strategy, but my buddy is really against this in a server farm environment because of deployment issues (not to mention requirements of specific versions of Linux for many of our apps). It seems more suited to individual users than to that sort of environment, anyway.

I installed Gentoo one time, and I liked how much less bloat it seemed to have. I am not aware how well its ports collections are maintained; if a system I install today can be gracefully updated with stable versions of updated packages over a 2 to 3 year period, I'd be interested in trying it again. I do want to install from a CD, tho (did that the first time) as I want a baseline build so I don't have to download and build quite so much.

There was an interesting program used to manage .tar installations on package-based systems at developerWorks called Stow which was also discussed on Slashdot awhile back. Like so many other things, I'm interested but haven't looked into it...

Also an article with tips for rebuilding from source code that was basic but still useful.

Anyway, kind of a ramble, but there is it just the same.

- Leo

It's still a smart move if you're building from source. Just package your source. Then you can build the sources under the control of a package manager (like RPM), and install the resulting packages. You get the full benefits of build-from-scratch and the full benefits of using packages.

This is exactly the approach I use. In fact, I'm a bit more strict about it: My policy is that I don't install any software that isn't packaged. If I need to install something that isn't packaged, I'll package it first. If I don't like the way a packager built an already existing package, I'll repackage it.

The bottom line is that creating your own packages (or fixing packages you don't like) is much easier than maintaining a from-scratch, unpackaged installation. Or ten of them.

To get you started, here a couple of RPM-building references:

• The fight, my first attempt to make a readable rpm package building introduction.
• Fedora's RPM Building Guidelines

Don't give up the benefits of source. Don't give up the benefits of packaging. Have them both.

The DLLs get large because Microsoft dictates that they must remain backwards compatible, so that an application coded for dllhell.dll version 1 will still work for dllhell.dll version 6 without recompiling. This is one thing Windows does have that Linux doesn't. [Emphasis added.]

I'm going to have to respectfully disagree on this one. The typical approach here is to use a packaging system (like rpm, dpkg, BSD ports, or even OpenPKG). These packaging systems manage dependencies (including old versions of shared libraries).

For example, on some RPM-based distros, KDE 3.1.something required an older version of OpenSSL, so the new and old shared libraries were included:

$ rpm -qa | grep -i openssl | sort
...
openssl096-0.9.6-something
openssl096b-0.9.6b-something
openssl-0.9.7a-something
...

Instead of including all of the backward-compatible symbols, etc. in one DLL, it's split up among several different shared objects. That way, only the required objects are included instead of the kitchen sink approach.

$ rpm -ql openssl096 openssl096b openssl | grep /lib/
/usr/lib/libcrypto.so.0.9.6
/usr/lib/libssl.so.0.9.6
/lib/libcrypto.so.0.9.6b
/lib/libssl.so.0.9.6b
/lib/libcrypto.so.0.9.7a
/lib/libssl.so.0.9.7a

However, you are correct that the packager does need to take more care in setting up the dependences, since one can't just assume that the necessary libraries (old or new) are installed on the system. One could argue that with cheap disk space, why not include everything? Purists would tend to site clutter, security problems, the tendency for increasing complexity to result in erratic behavior, and other inconveniences as reasons to avoid this approach, however.

My two biggest complaints with it are:

1. RH, in its current state of transition and confusion, is aiming Fedora at the non-existent "bleeding-edge corporate desktop" market and thus continuing the RH8 and 9 trend of dumbing it down. Returning to techie roots should involve returning to the more sensible and *more usable* kind of interface we saw in earlier series before people got into the "usability" kicks.

2. Package management. Good grief. It starts with the install: there is no way to select individual packages for installation. After installation, the graphical "install packages" program, which has all sorts of problems up to and including frequent segfaults for many users, still doesn't allow individual package selection either (and hasn't since RH8). Its segfaults and the increasingly common RPM hangs result in locking problems and rpm db corruptions which require, at best, a rpm db rebuild, and at worst enough repair that a total reinstall is recommended instead. Ah, for the days of rpm 3.x and gnorpm! (Man, I miss that program- I've felt for some time that RH failing to put resources into it to keep gnorpm up with the move to gtk2 and later rpm versions was their worst move at least since GCC "2.96".)

It seems to be a common misconception that you have to compile open source software manually, and that you have to be a skilled 1337 programmer to do it.

Ever heard of rpm? apt-get? swup?

RedHat offers a complete server, just burn the ISOs and install. If you think that's too difficult, then fine. It's your money.

While I am sure up2date, urpmi, and apt-get can be ported to *BSD, and various flavors of UNIX they usually aren't.

Well, you found it, sort of. I was looking in the 4.2.x directory. 4.1 isn't the latest version, but close enough I guess. At least it's only a two package process to installing it on a non-rpm system.

Just about every project insists upon using the latest version of rpm to package Linux binaries, so one has to somehow install RedHat's latest package manager which, of course, the binaries are "conveniently" stored in the latest rpm format, so you can't install the thing until after you've installed it! It'd be easier to just install Red Hat's distro on your machine than try to get the newest version of their package manager on your system.

Go to the rpm.org website where, on the front page, there's a link to the ftp site. At the ftp site, you can find all of the current source and binaries in both rpm and .tar.gz formats.

This took me all of 2 minutes to locate.

Just about every project insists upon using the latest version of rpm to package Linux binaries, so one has to somehow install RedHat's latest package manager which, of course, the binaries are "conveniently" stored in the latest rpm format, so you can't install the thing until after you've installed it! It'd be easier to just install Red Hat's distro on your machine than try to get the newest version of their package manager on your system.

Go to the rpm.org website where, on the front page, there's a link to the ftp site. At the ftp site, you can find all of the current source and binaries in both rpm and .tar.gz formats.

This took me all of 2 minutes to locate.

Show me where they distribute the source for the RedHat Package Manager in a format I can read without installing RedHat's distro or somehow having the program already installed.

Maybe, but your response raises the question: how is Red Hat not a proprietary software company? Don't they keep some of their projects closed? I don't use their crap, but I'm certain I've heard people say some of their higher end programs are closed source. They're also the ones who forced the god awful rpm format on the Linux community. The M$ wannabes really snarfed that one up.

Just about every project insists upon using the latest version of rpm to package Linux binaries, so one has to somehow install RedHat's latest package manager which, of course, the binaries are "conveniently" stored in the latest rpm format, so you can't install the thing until after you've installed it! It'd be easier to just install Red Hat's distro on your machine than try to get the newest version of their package manager on your system.

"The best way to get RPM is to install Red Hat Linux." From their own rpm Howto. Note the alternative link to get the program (probably source) doesn't work anymore! Sounds like a proprietary software company to me.

Yes: anaconda source rpms

How about their build and dependency system ... ?

The build and dependency system is all inside the rpm program and associated libraries. Here are the source rpms for rpm. If you are worried about chicken and egg installation issues, an rpm tarball is available here.

How about their build and dependency ... database?

The actual (complete) package database for redhat 9 is available in this little known gem of a package which is included in redhat but not installed by default (and IMO should be). The spec file for rebuilding the package database can be obtained from the corresponding source rpm, provided you have a copy of all of the redhat rpms for a particular version.

In general, almost everything in redhat includes source code. If you have to ask, the source is probably available. There are a few rare instances where redhat does not provide the source code, but these are pretty obscure and you have to know redhat fairly well to run into these programs -- so well that you wouldn't need to be asking in the first place!

From the RPM site:

"With RPM, you have the pristine sources along with patches that we used to compile from."

He states that rpm is not unpackable by standard tools.
Can an experienced user, when presented with a package in this format, extract its payload using only tools that will be on any linux system? They can remember a few facts to help them deal with the format, but remembering file offsets and stuff like that is too hard.

First problem I have is with the "any linux system" Ummmm I've a Linksys router running Linux that can't do jack with any of these. Next an RPM is actually a cpio archive rpm2cpio is actually just a tool to shortcut what is doable with cpio. This applies as well to all of the "standard tools" statements. I also would like to point out that standard depends on which standard you use. Posix, LSB etc. In that rpm is a standard of LSB but not of Posix.

His statement that binary programs are not allowed.
Must these programs be scripts, or can compiled binaries be used as well?

This is very, unclear. Can I execute a binary from within rpm. The answer is yes. I do it all the time. Can RPM be made directly from binaries (skiping all of the build etc.) Yes it can. Can I embed the binary in the RPM and not have it ever get installed... no. But I can run it then remove it before RPM finishes.

Suggestions ... he states that RPM doesn't have them.
A suggestion says a package may sometimes work better if another package is installed. The user can just be informed of this as a FYI

This is really the fault of the packager not of the product. There are two areas for comments which can give you this kind of data ... but it's up to the packager to use the tool. Second the author needed to get a little deeper into rpm's queryformat (info here) He would have found much of what he needed.

Statement that RPM can't do Boolean Relationships.
This means that a package can depend, conflict, etc on a package AND (another package OR a third package). Any boolean expression must be representable, no matter how complex.

RPM does have the conflicts and the depends paramaters that can be set. Once set you can't install a without b and c, plus removing y and x.
HOWEVER he is very right about the boolean "or" being missing... I've been championing this one for a while (I've talked with some of the developers.) but it seems it hasn't up till now been high enough on the horizon to have someone take a shot at it. (Sorry but it's beyond my ken to work on this personally) So I will keep politely advocating this until it does break the plane of need.

New Section

Sorry but this stament is just too nebulous. It's been coping with the unforseen for years. Just as debian has. That's why it get's upgraded. That's in fact a lot of the reason for the new version coming out now. To make the format more modular. and easier to mutate as times change.

All and all the article seems well done. However I'd say the chances are pretty strong that the author is a Debian fan. My personal recommendations would be. One lose the subjective nature of a number of statements. Next, when doing research be careful how you ask a question. Often times asking "Can this product do X" will yeild a no. But if you ask .. On a system that uses this product how do you do X" will yeild a completely different answer.

I'd give this article all in all a 6 on a 1 to 10 scale for research. a 3 for new info. and a 7 for layout and style.

1. SCO confirms in this letter that SCO is selling Linux.
2. The GPL sections 6 and 7 seem to restrict use of the GPL if they are affected by (their own) restrictions on GPL-protected tools.
3. The IBM Public License terminates the license if patent litigation takes place.
4. Item #2 in the letter says SCO is suspending sales of Linux.

Well, what SCO Products might be affected by the GPL and IPL?

• SCO OpenServer 5.07 - there are some GNU tools there. (GNU coding standards!)
• Postfix Horde, IMP (SCO doc server down: IMP GPL), in SCOoffice Mail Server [Several SCO Documentation pages have bad LICENSE or COPYRIGHT links].
• (Can't check more products - the SCO documentation server stopped responding to me.)
• RPM is under the GPL.

LRP is the grand daddy of many "embedded" linux projects. LRP proved two concepts, 1) the need for GPL appliances that run from ram and essentially read-only media, and 2) a clever compressed read-only package system (.lrp instead of .rpm or .deb) for conserving boot media storage space. These ideas spawned LEAF, CoyoteLinux, and forshaddowed Knoppix, which all boot from floppy or CD-R media with compressed files to improve storage.

LRP was floppy firewall distro, that did not need a harddrive. It needed only 386 PC or better, 2 Nics, floppy drive, and sometimes a keyboard and monitor. It did not do fancy things, just NAT routing, firewalling and DHCP. But you could add .lrp packages for other cool features like DNS caching. The .lrp packages were just a renamed .tar.gz with binaries compiled a certain way, but they worked and saved space. Although building an LRP floppy was not easy for a novice, the package system made floppy firewall setup MUCH easier. With developers shrinking package sizes again and again, other lrp packages could be added, or log files could be added. Very clever.

But LRP failed to inivate fast enough, (e.g. I lobbied for a bootable CDs, to no avail) or document well enough, so Linux Embedded Application Firewall [LEAF] forked off. LEAF got space on SourceForge and spawned flavors, such as Oxygen, Dachstein, Eiger, Bering and others quickly helped fill out the space, improving core technologies and documentation. LEAF added bootable CDs and tons of packages. But LEAF struggled with picking a GlibC version and development of extensions became some what Balkanized.

The size limitation of the floppy made 2.4 kernal and iptables unatainable. Chuck Stienkhuler removed this boundry with his LRP-CD, which could fit every major linux ethernet driver, and so much more.

When I saw that, I thought, "well why not a full distro on a bootable CD", and was pleasently surprised by finding Knoppix. I even was the first person to mentioned it on Slashdot. [search Knoppix in stories on slashdot and find the first entry :) ]

LRP also spawned the CoyoteLinux firewall, which added a Win32 floppy build exe and a linux floppy build bash script. It makes building a floppy firewall really easy.

Death of LRP is not a surprise with LEAF on the scene. There is much life in the "embedded" linux space beyond firewalls. LRP got thing moving and many other GPL projects have adopted the core ideas and kept up the rate of acceleration. Bootable CD distros are exploding, into Mesh Networks, MAME systems, Linux on X-box hacks, PVR systems, LAN MP3 Servers, print server, LAN DNScache/DHCP/NTP server, Honey Pots and on and on. We will se more and more bootable CD distros, that will make our lives easier, and take the strain out of admin and system upgrade. Oh look, a new ISO on line, I down load and reboot my system. If it does not work, I pop the old CD-R back in. No muss, no fuss.

LRP is dead, long live LEAF and Knoppix, and ...

-Nathaniel
Mac Refugee, Paper MCSE, Linux wanna be.

1) Unreal Tournment 2003, Enemy Territory, Quake3, Neverwinter Nights, etc. And much, much more with Wine such as Soldier of Fortune 2.

2) Grip, VERY good CD Ripping app. Will auto download CDDB, run the encoder of your choice, etc. As for raytracing Povray can do a lot too, but you just need a good modeler, such as Kpovmodeler. As for a one click installer, check out RPMs or RedHat's Package Management System, looks just like Install Shield.

3) KDE,Gnome,etc. You DO know that they can be themed to look just like the crappy Windows GUI too don't you?

See the RPM HOWTO at rpm.org for instructions on how to build your own RPM. It's really not hard. Or just use the supplied installer. Having mozilla as a non-rpm package is not the end of the world.

See the RPM HOWTO at rpm.org for instructions on how to build your own RPM. It's really not hard. Or just use the supplied installer. Having mozilla as a non-rpm package is not the end of the world.

It's a bit scary, but I've found the rpm 4.1.1 backport of 4.2 to be much more stable than the current version shipped with RH8 (and presumably RH9). It's now one of my standard upgrades.

--

ive tried pretty much all of the RH versions, and I find that RH 9 is the best. I have never had a single crash once, ive never had any trouble with any of the configuration utilities, and ive never had to mess around with hardware issues(kernel modules and so on). It might just be that RH 9 suits the hardware im using very well, but I cant say the same things about any of the previous versions. Well thats my suggestion.

Funny, I've just finished repairing the rpm database for the nth time. I tried to install Python Base which was required for bittorrent but got a conflict from python-2.2.2-26, so i tried erasing that which gave me a stream of other conflicts and apparently did earase anyways since now up2date and half a dozen other utilities don't work because they're getting python related errors. Now neither reports being installed... well that isn't quite true, when I try to install python-base it won't install because in conflicts with files from python, and when I try to install python it conflicts with files from python-base. Oh yeah and Evolution is trying to send mail through a server belonging to an account which I tried to add but later removed because it didn't work. Also the java compiler has started giving errors about unreachable statements it didn't give before and the virtual machine now crashes before launching a gui (python related maybe?), i tried installing the 1.4.1 sdk but the installer appears to crash at the end... seems to have installed all of the files but never reports finishing, using the new javac and java the problems are unchanged. However go back a few weeks ago and I couldn't be happier with it but now I'm slightly frustrated. In short anecdotal evidence based on a single machine doesn't mean a whole lot.

I fail to see how rpm is superior to dpkg in verifying the 'compatibility' of installed programs -- that is to say, only as good as the packager

There are two answers I'd like to give to this:

(1) Red Hat have always provided better quality packages (by which I mean they are more polished, with much more accurate meta data). Additionaly, in actuality, I belive that debsum -ca is no where near as useful as rpm -Va. If your a Debian user too I don't need to point that 'stable' is wildly out of date and that 'un-stable' is, as the name implies, often wildly unstable.

2) The idea that the only difference factor is simply the quality of the package and that there is no significant differnce in the package management systems is false. Crucialy, Debian lacks anything which matches the power of rpmlib.

In summary, while Debian manages to be much easier to maintain and use for personal desktop systems, it does not have the professional level of polish and intergrity that is required by most corporate (server) environments - partly due the the package management system (and rpmlib) and partly due to the quality of Red Hat's packages. As the forcus of Debian's maintainers is primarily users and developers, rather than the servers of large corporations, I think this situation is unlikely to change in immediate future.

Damnit, stop troling. The Documentation for rpm -K clearly states that the first step is to download a PGP certificate, which means that a) it's not verisign and b) it didn't come with your install media.

Quit lying to all these people, some of them might believe you, and that's dangerous.

Its the Linux packaging method, created by Red Hat. See http://www.rpm.org.

Now if only Debian would start using it (and improving it in any area they see lacking) instead of supporting the LSB by turning packages into dumb archives with alien. ;)

As for the insults, you started the insults by correcting me. We both know that correcting somebody like you did is a form of insult. While your insults didn't hold water, I think my insults stand on their own feet.

You tell me to grow up because I made a claim and provided no proof, and look at all the proof you gave in your post! Wow!

Now, before you jump out of your chair, screaming murder, realize that I never said that RPM is currently a hack (I haven't had time to look at any recent changes), I said that it was a hack from the beginning. Now that I've proven my point by backing up my claim, I guess you're going to say, "Gee, mister, you sure are right!", right? I didn't think so.

Lastly, the fact that RPM is used by "many organizations" does not mean it is flawless. My entire point is that it was created quickly by Red Hat, and that we might be better off if we designed a new format that has all of the RPM's good stuff, and none of its bad stuff.

rpm -qlp somepackage.x.y-i386.rpm

I would also like to see "source rpms" that take a long time to install,

Package management is a wonderful thing, but it does have some drawbacks.

Package management is used to ensure that the rights libraries needed for your app (server) to work. If you think that the package you are using is bloated, does not provide the functionality that you need or even does not exist in your distribution. You should create the package yourself.

Unfortunally very fewer distributions can satisfy every kind of user, so if you knows how to create a package for your distro, you can fill the gap.

Just to note RPM has been made the official LSB packaging tool,

I could make that list even longer with many more projects that Red Hat either funds, maintains, develops or contributes to, but I think I've already proven my point.