OSNews

"Wow, I'm extremely surprised someone said it.
PC-BSD is the ONLY *NIX distribution that got it right. Having bottled applications is the way to go."

For average users, I completely agree, as long as stable and tested versions are botteled. For developers or professional users this may differ, because they may have the requirement to use and test bleeding edge software, along with the ability of updating underlying libraries without having to reinstall applications that are based on these libraries.

"PBIs make it easier to develop, deploy, use and maintain software."

I'm not sure if a command line driven PBI installer exists. The way of downloading and clicking makes it more complicated to automate software installation.

How much does the use of PBIs make it easier to develop software, or to maintain it? I don't understand, please elaborate on this.

"Everything is in one place, no dependency hell at all, both the developer and the user don't even have to care about what's already installed on the system and what's not."

That's correct and, by the way, a very comfortable thing. But finally, you sometimes "pay" for it with having to download bigger packages or getting more disk space occupied. But we do have enough of both, don't we? :-)

"Windows got it right: there's no central "repository", except for maybe updates and security patches. The software market is free and sky is the limit."

I don't think so. Requiring the user to google around for drivers and applications is annoying. In PC-BSD, you can simply advice a user to search for, let's say, "digikam", let him download and install it. Or you can tell him to simply enter "pkg_add -r xmms" inside a terminal. Can you do on "Windows"? No, of course not.

FreeBSD's classic ports are free, too. Every developer may contribute to it, let his piece of software enter the repository, and benefit from the already existing automations inside the ports system. Using this way, even precompiled packages are made available by the FreeBSD ports team.

To find out more, feel free to read here:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.htm...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

"Whereas in Debian, Fedora or Ubuntu one has to upgrade the whole operating system just to get the latest version of Firefox or other basic piece of software."

Pardon my question, but why do you think so? Allthough I'm not a regular Linux users, this sounds stupid to me and I never had to do a system update in order to get Firefox or any other piece of basic software running...

"Of course, changing this paradigm in a Linux distro nowadays is almost impossible: the sheer number of libraries needed for various software could easily bring a modern HDD to its knees, not to mention the amounts of RAM required."

That's the same way MICROS~1 OSes and applications develop. But for the average user, it does not matter, because he usually has a high-end PC at home. Users with limited ressources and basic UNIX knowledge surely would prefer to build an own system based on FreeBSD rather than using PC-BSD.

"But who am I to argue, when we all know "choice is good". Look where aimless development has brought the Linux world: in chaos. I am not arguing for voluntary boycott of toolkits, libraries or programming languages, but for more responsibility on behalf of developers and less ego."

Choice is what makes me able to get a full-featured UNIX system running on a 150 MHz Pentium with 128 MB RAM, because I can still use light-weight applications. I am not forced to use KDE or Gnome. This choice is available in Linux, as it is in PC-BSD.

But "aimless" development? I think the term development implies an aim...

"Security issues are indeed more easier to fix when using a centralized package management system, however, that does not mean it's impossible or even hard to fix them when we use the decentralized approach. Staying current with the latest vulnerabilities should be the developer's job. Installing the security updates from upstream should be the user's job."

I'd say, it could (!) be the OSes job, as long as the issue is system related, and the package subsystem's job, as long as the issue is related to an application or library that is installed. But let's assume applications A, B, C, D and E use library K. In K, a security problem has just occured. The developers of A up to E would need to be up to date here, and provide a new botteled update from A(K) to A'(K') etc., and the user would need to reinstall A .. E or install a binary fix from his A .. E to A' .. E'. He cannot simply update K to K'.

"Since we're discussing package management, lame excuses like "you can always compile the software you want" are just that: lame. Compiled software is software the package manager is NOT aware of."

FreeBSD provides a solution here: You can install portinstall / portupgrade with provides a package database to be used with pkgdb. Now ports and packages easily know about each other, and you can use frontends to the ports and the packages. Of course, you get warnings if you try to overwrite libraries. This way, "dependency hell" is avoidable.

Example:

# cd /usr/ports
# make update
# pkgdb -aF
# portinstall -P audio/xmms
# portupgrade audio/xmms

This example shows how to install xmms via package (equ. pkg_add -r xmms), and then update via ports. Of course, installation from source would have the same effect. One uses packages, one uses the ports. portinstall and portupgrade update the pkgdb before and after installation and check for the existance and version numbering of dependencies. So you cannot "smash" other applications that rely on a certain version of a library, for example. Furthermore, you can use the classical ports and packages together with pkgdb.

# pkg_add -r xmms
# pkgdb -aF

# cd /usr/ports/audio/xmms
# make install
# pkgdb -aF