[Pcbsd-pbi-dev] The pbi format

[Richy T <bio...@gm...>]

Hello pbi developers!
I have been doing some reading on our pcbsd forums.
There is some really good information there about our format.
I really think all PBI developers should read this.
The information posted on the forum might really help make
.PBI truly a great binary format for pcbsd and maybe freebsd!
Here is the post. -->

From: Almindor
> ---------------
> I'm a programmer so I'll post my view on PBIs and other packaging here.
>
> PBI is a .app style packaging system with "all in one" even basic
> dependencies. The good of this is that it's simple, easy and has
> (theoreticly, in practice this isn't true) no conflicts.
>
> Packaging ala Ports/Debs/RPMs is a complicated (altho not always for the
> end user especialy if they have good net connection, debs are real good
> here) process which required dependency checks etc.
>
> Now for the pros and cons from my perspective:
>
> PBIs are great for programmers/developers since they make it easy for the=
m
> to distribute their apps without much fuzz.
> PBIs however have 2 major problems as-is, one is directly tied to the
> FreeBSD system underneath:
>
> 1. It conflicts with ports/packages
> 2. It copies all libs for all apps and makes ALOT of duality with .so
> files.
>
> Now #2 seems like no problem to most of you guys but let me elaborate.
>
> Dynamic libraries, or shared objects as Unix world calls them are pieces
> of code (and sometimes data too) which are saved in a special way so that
> programs(apps) can "link" themselves to the code and use it.
>
> The whole concept of shared objects is, sharing memory Smile (how
> unexpected)
>
> What's wrong with per-program copy of .so files then?
>
> Memory usage. Start up KDE and a few apps, then look at your memory usage
> via some monitor program. Notice that most apps (visual kde etc) take
> 10+megs of RAM. This ISNT REAL MEMORY.
>
> Because all of these programs use more or less the same .so files, all
> this memory is shared.
>
> Now imagine a system where virtualy everything comes from PBI. Every
> program would really hog ram with it's own copies of .so files (and hence
> their existance is a hindrance, since smart-static linking would produce
> much smaller footprint, less conflicts etc.)
>
> Conclusion? It's a good idea on a bad system. I've nothing agains Unix in
> general but Unix world (and windows too to an extent) decided to go the
> "shared object" path. Every unix binary today links dynamicly etc.
>
> Is there a different approach?
>
> Well there is, but if it's better is a nice question. Now before I start
> this please note that I AM biased Smile
>
> Free Pascal compiler can produce "smart linked" binaries. These binaries
> are static but contrary to popular belief take very little space on disk =
and
> in memory. (Hello world app in C static linked is ~800kb!! in FPC
> smartlinked it's ~20kb on disk, I'll explain why)
>
> Smart linking is a technique which "links in" only used code from a
> library.
>
> So let's say libC is smartlinkable (it's not btw).
>
> If you only used printf() your binary would only grow "so" much.
>
> If you use dynamic .so, your binary will remain small on disk, but will
> load the whole libC into memory because of printf(). Now imagine all
> programs loading whole libC into memory per-copy. This is what is done wi=
th
> PBIs and that's the bad idea. PBIs would work wonders on a "smartlink" ba=
sed
> system where only real basic system libs would be dynamic, and all other =
dev
> libs would be smartlinkable. This way programs would have minimal footpri=
nts
> and no conflicts would happen (they would also have a tendency to work
> longer since ABI is of no concern).
>
> Hope this all makes a bit of sense Smile
>
> Ales


   POST REPLY:

From: pcbsdusr
> ----------------
> I have been thinking of this as well and i am in the process of writing a
> hibrid concept which uses programs in their own folders but shares
> dependencies while maintaining the ability to use multiple versions of an=
y
> given library side by side.
>
> no multiplication of libraries =3D No wasted disk space and no memory was=
te
> while multitasking with apps using common dependencies.
>
> of course, i am writing this for apps only... There will be always
> duplication until we maintain freebsd intact under pcbsd...


I really hope you guys can update the format to work this way.
It would make the .pbi format truly one of, if not the best format for
pcbsd/freebsd/UNIX systems.
Hope this gives you guys some insight and inspiration on how to update the
.pbi format.

- Richy