Linked by Thom Holwerda on Tue 10th Oct 2006 15:14 UTC, submitted by Charles A Landemaine
PC-BSD "iXsystems, an enterprise-class hardware solution provider, announced today its acquisition of PC-BSD, a rock solid UNIX operating system based on FreeBSD. PC-BSD is a fully functional desktop operating system running FreeBSD version 6, with a KDE desktop interface and graphical system installer. Its PBI system, developed exclusively for PC-BSD, lets users download and install their applications in a self-extracting and installing format. iXsystems' acquisition of PC-BSD will provide funding to the PC-BSD project to increase distribution of PC-BSD and develop future versions of PC-BSD. Development is currently underway for a version of PC-BSD that will allow for easy installation and operation on servers, workstations, and laptops."
Thread beginning with comment 170493
To read all comments associated with this story, please click here.
PBI just isn't right
by Almindor on Tue 10th Oct 2006 19:39 UTC
Almindor
Member since:
2006-01-16

Well this acquisition still doesn't change the fact that the PBI package system is inheritedly flawed.

a) PBI programs have their own lib dirs, so if THEY produce a program which requires those libs, it will fail to link/start
b) PBI programs have each got a copy of their own lib which is a wastage of space AND RAM. Not to mention the fact that it's simply plain wrong. Shared objects (libraries) were ment to be SHARED.. as the name implies

The whole idea to fight DLL hell by not using DLLs how they were ment to be used is rather bad. I'm really not happy about the rather idiotic UNIX ABI situations in most/all unix flavors out there, but this PBI packaging doesn't fix it.

Not to mention security implications of using old libs...

Reply Score: 5

RE: PBI just isn't right
by Thom_Holwerda on Tue 10th Oct 2006 19:47 in reply to "PBI just isn't right"
Thom_Holwerda Member since:
2005-06-29

a) PBI programs have their own lib dirs, so if THEY produce a program which requires those libs, it will fail to link/start

What?

b) PBI programs have each got a copy of their own lib which is a wastage of space AND RAM. Not to mention the fact that it's simply plain wrong. Shared objects (libraries) were ment to be SHARED.. as the name implies

It is actually a trade-off for userfriendlyness. I'd much rather have applications be (un)installable by removing its directory, than having to load up a package manager or a terminal EACH time I want to delete an application. I don't have the time to remember each apps package name.

BeOS does it right (application dirs can be moved/removed at will) and OSX does it almost right (OSX kind of sucks since removign a .app directory leaves a trail of files of that .app dir all over the place).

Not to mention security implications of using old libs...

Well, ANYthing is better than having somelib v2.3.12b2 kill applications because they require v.2.3.12b1.

Reply Parent Score: 1

RE[2]: PBI just isn't right
by Almindor on Tue 10th Oct 2006 20:15 in reply to "RE: PBI just isn't right"
Almindor Member since:
2006-01-16

"What?"

That! It means that eg: if you put an RAD IDE into a PBI and that IDE uses a compiler to make visual (let's say gtk) programs which require gtk libs and few others, the resulting programs won't link, because those lib are only in the local program lib dir visible only to your program.

Even if you instruct the linker to look at that lib dir your resulting app won't start because it doesn't know that lib dir. You can ofcourse then tweak the ld configs to make that lib dir visible.. but then again.. is this userfriendly??

There are many other problem implications, usage of RAM is just one of them.

Reply Parent Score: 4

RE: PBI just isn't right
by codehead78 on Tue 10th Oct 2006 20:28 in reply to "PBI just isn't right"
codehead78 Member since:
2006-08-04

But doesn't that make the program more stable? If you do all your testing with a set for libs, if just one of those libs pushes an update that introduces a bug...
It just seems like a good idea assuming the package can also make use of common system libs and bundle up "volatile" libs.

Reply Parent Score: 2

RE[2]: PBI just isn't right
by Almindor on Tue 10th Oct 2006 21:18 in reply to "RE: PBI just isn't right"
Almindor Member since:
2006-01-16

Problem is that FreeBSD has very few system level libs you can depend on that ARE there. Ofcourse PCBSD "fixed" this by adding a few common desktop ones. But they don't include eg: libgtk1.2 (xmms anyone?) so a RAD IDE which uses it for example won't be able to make proper working binaries on PC-BSD unless you bundle them in a PBI and install first...

and the problem is not in the IDE, it's a design issue.

As for stability, that's not exactly true. It's more stable in that it won't eg: stop working altogether if you use old libs all the time. But it's less secure and less "stable" if the old libs have bugs and newer ones have them fixed.

Double sided sword.

Reply Parent Score: 1

RE: PBI just isn't right
by bubbayank on Tue 10th Oct 2006 21:00 in reply to "PBI just isn't right"
bubbayank Member since:
2005-07-15

b) PBI programs have each got a copy of their own lib which is a wastage of space AND RAM. Not to mention the fact that it's simply plain wrong. Shared objects (libraries) were ment to be SHARED.. as the name implies

This is not 1995. RAM and drives are cheap. PBI is a simple solution to a problem that leverages the economy of cheap hardware.

Please, tell us what your real-world user-friendly solution to the dependency problem is.

Reply Parent Score: 1

RE[2]: PBI just isn't right
by Almindor on Tue 10th Oct 2006 21:15 in reply to "RE: PBI just isn't right"
Almindor Member since:
2006-01-16

a complete rework of the unix concept in the first place.

And smartlinking, that means static-linking only of those functions/objects you actualy use, into the binary. (I know of only one compiler capable of this and that one is not compiling C or part of gcc) {ld "supports" smartlinking to an extent, very slow extent tho}

Dynamic linking should only be used for basic OS libs (which should be language agnostic, not libc) and security libc (crypt, hash ssl and such).

The problem with PCBSD is that the base OS which it's based on is build to use dynlibs, or atleast designed to since long ago. see eg: my problem with a RAD IDE.

Reply Parent Score: 1

RE[2]: PBI just isn't right
by sbergman27 on Tue 10th Oct 2006 21:29 in reply to "RE: PBI just isn't right"
sbergman27 Member since:
2005-07-24

"""Please, tell us what your real-world user-friendly solution to the dependency problem is."""

A real binary package manager with an easy to use gui like gnome-app-install, which defaults to basic mode, but has an "Advanced" button that brings up Synaptic?

Plus something like gdebi, which allows the user to install a 3rd party package by clicking on it in the browser or filemanager?

Edited 2006-10-10 21:32

Reply Parent Score: 3