Slashdot Mirror

This is hard with Gentoo.

I have tried it only once, but it was recommended to me as "server distro".

The guy who introduced me to Gentoo, used it in his company on several servers. He had two configurations (think two types of servers) and software was compiled correspondently on two of the servers and then replicated to other servers. Strictly speaking, he had Gentoo only on two servers - while other servers used some kind of compiled/bundled internal versions produced by the two Gentoos. He didn't seem to experience any kind of problems.

P.S. The same guy actually recommended me also more accessible option for servers: OpenPKG. Gentoo is Linux, but if you need stable services running variety of Unices, OpenPKG is strongly advised. I believe he had used some parts of OpenPKG along with Gentoo.

The only thing funnier than jokes about Lynx vulnerabilities is that there have been real ones. Remote shell access in Lynx, Lynx command injection, Lynx NNTP buffer overflow.

Maybe the thing to do is to telnet to port 80 and parse the HTML in your head, but then someone will probably find an HTML trick that will drive everyone who reads it insane.

OpenPKG seems like an interesting portable packaging framework. I would be interested to hear from people that have had any exeprience with this.

PkgWrite is a perl tool that builds debian and rpm packages from a single spec file. GNU/LGLP with liberal relicensing. I suppose it will not save any dependancy issues for you.

EMP is a commercial solution, offering native packages (debian, redhat, solaris, HPUX etc.) and script-based installs. It costs $99, has a stale web site and I never tried it. But for commercial software, perhaps it can help you.

STOW is a free perl-based fancy package manager that was pushed by IBM at one time.

But at the end of the day, it is not very difficult to prepare debian and rpm package specs, build chrooted building environemnts and support several distros. Users are really happy when they can apt-get install your software, even if it is binary-only and from your own server. If you don't have nasty kernel dependencies, chrooted building environment might be easier than it seems. And you will only ever be sure in the case of binary distribution if you can build and test your package yourself. And if you have users who want graphical installers, you can always trick Loki to install a standard package. Which should be its default behaivour anywyay, IMHO.

"stuff like Gallery and SpamAssassin which I don't consider critical for security updates."

Um. Perhaps you should.

Any internet facing aplication should be conisdered critical when it comes to security updates.

> As I HATE upgrading Linux boxes for fear of messing them up, and ive laready gotten the 2.6 kernal on my RHEL 3 machine, what benefit does this have?

Speaking as someone forced to admin RHEL 3 without provisioning credits (it's politics and bureacracy, not money), what did you have to do to get kernel 2.6 on it, did you have any problems with it, and could I bum the RPMs off of you? I have a SuSE 9 box right next to it on identical hardware, and it's blowing the doors off the RH box (some of it has to do with them installing ext3 on the RH box instead of xfs, but that's not the whole story).

I'm relying on openpkg to run non-core packages, but it's hardly a great solution.

without a doubt, solaris has been the biggest pain to set up out of ANY unix i've installed

I agree. I spent a week fighting with Solaris 10 preview for all the wrong reasons. It was basically an experiment to see how much GNU software I could pack into it. To my horror, once I finally got the thing installed I learned that it doesn't even come with a compiler. Sure you can add GCC to it, but there must be some art to making GNU's tools work properly with Sun's libc that is beyond me. The biggest problem I had was libtool seems to be completely broken with respect to shared libraries on Solaris.

The good news is there are lots of repositories for Solaris binaries:

Sun Freeware (Sun sponsored - mostly GNU in Solaris package manager form, can be installed with pkgadd)
OpenPKG RPM OpenPKG Solaris 10 RPM's (Lots missing from here and needs to be compiled via the SRPMS)
OpenPKG SRPMSAlmost everything I use, I found here and compiled without problems
IbiblioThere's a bunch of binary packages here for x86 and SPARC Solaris, I didn't use any of them


Anyone else looking to venture down this road, you should be warned that Solaris is really no fun to try to use as a desktop. Out of the box, Gnome is at version 2.2 or something, and has many many bugs (like Nautilus crashes when you try to drag desktop icons for example).

Summary: Solaris is not ready for the desktop.

/me ducks

without a doubt, solaris has been the biggest pain to set up out of ANY unix i've installed

I agree. I spent a week fighting with Solaris 10 preview for all the wrong reasons. It was basically an experiment to see how much GNU software I could pack into it. To my horror, once I finally got the thing installed I learned that it doesn't even come with a compiler. Sure you can add GCC to it, but there must be some art to making GNU's tools work properly with Sun's libc that is beyond me. The biggest problem I had was libtool seems to be completely broken with respect to shared libraries on Solaris.

The good news is there are lots of repositories for Solaris binaries:

Sun Freeware (Sun sponsored - mostly GNU in Solaris package manager form, can be installed with pkgadd)
OpenPKG RPM OpenPKG Solaris 10 RPM's (Lots missing from here and needs to be compiled via the SRPMS)
OpenPKG SRPMSAlmost everything I use, I found here and compiled without problems
IbiblioThere's a bunch of binary packages here for x86 and SPARC Solaris, I didn't use any of them


Anyone else looking to venture down this road, you should be warned that Solaris is really no fun to try to use as a desktop. Out of the box, Gnome is at version 2.2 or something, and has many many bugs (like Nautilus crashes when you try to drag desktop icons for example).

Summary: Solaris is not ready for the desktop.

/me ducks

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.

http://www.openpkg.org/

Since even BSD is moving to RPM and RPM is the mandated package system for Linux Standard Base, this would be a good project for Debian to test the waters of current technology. It would allow Debian to transition to RPM on this hybrid testbed, working the kinks out in the process. This would allow the work to go forth without disturbing the current main Debian branch. Then when the time was right, the overall switch could be made smoothly to RPM. Now's the time to act!

Nice try guys, but no. Unix is already too segmented and this packaging system will not change things one bit. This is a non-NLS supporting, non-GPL'd implementation of an uninspiring packaging system which may or may not support other versions of Unix besides Solaris, BSD, and Linux. Their FAQ even contains the question "OpenPKG breaks with a few things from the good old Unix days. Why?" Thanks, but no thanks.