PBI as the Universal Linux/Unix Package System

[jamiefoxer]

Guys,

The more I play with PBI, the more I realize how revolutionary it is. Does anyone know what happened of Security Enhanced Linux? It got adopted as a component of a lot of distros out there.

I highly suggest that the PCBSD team make a totally seperate website to promote PBI files as the Universal Unix/Linux package system. The superiority of it in terms of effectively killing dependency hell, not modifying the base system, and making Unix installing of software finally as easy as double-clicking is unmatched. And we don't have to think of it in the abstract, it's already here. We already have the tools to do it.

I think that, beyond PCBSD, we should strongly advocate PBI as the .EXE of the Unix world. But, in order to do that, we really have to have a professional website dedicated to promoting PBI as an integral part of the open-source world. We could make it the standard, if we promote it more. Who will protest double-click install vs. shell console commands, messups in compiling, and dependency hell?

[Charles]

I think PBI is revolutionary indeed.

But I think .pbi should remain at least to PC-BSD because if it is the Unix standard, a pbi for linux won't work on PC-BSD and vice-versa...

This would create confusion.

[jamiefoxer]

I'm sure there are ways to establish seperate repositories for Linux and seperate repositories for Unix, just as there are seperate versions of programs like KDE for both platforms. The point is that there must be a way to port the source code of the package creator to Linux systems so as the expedite the creation of Linux-based PBI install systems that can become part of the common platform of Linux.

A major complaint against Linux has been the lack of a standard, especially in program management. PBI effectively brings Windows/Macintosh style ease of installation and program management, and I think it's better than Windows, because it doesn't bloat the system with "registry file entries".

[kmoore134]

Besides, you can't have PBI's on linux, because it stands for "PcBsd Installer" :)

Seriously though, i'm glad to hear that people are starting to realize the vision i've been wanting to bring with PBI's. Its such a simple idea, Windows and Mac use it, but on Linux / Unix we have all this complicated garbage just to install a simple piece of software. I mean, sure, its nice to "share libs" and save a little space, but when it brings all these problems such as dependancy issues, and breaking things on the system, then is it worth it anymore? To this date the answer for it has always been "Lets make it more *powerful* (Gentoo) or use a nicer GUI" (RedHat, Suse, RPM's), which sounds nice, but when the basic premise is flawed, then its only going to work so well. Besides, normal users aren't going to move from something simple to something way more complicated. It just isn't going to happen.

Now on the other hand, running a repository of apps might be easier for the devs then making seperate PBI's of everything, but "que bono", who benefits? In otherwords, if its easier for the devs, is it easier for the end users? I would rather have a system that takes a bit more work for the developers to package and prep their apps, because we have the knowledge to do it. End users just want something that works. Period.

When I go to the store to buy a game, like World of Warcraft for example. I look at the requirements to see if I have a good enough system. Now imagine if I had to do that, and THEN look at the OTHER requirements to see if I have "GTK 2.2.0, libc++.0.6.so, QT 3.3.4, glibc 2.0, libgnome 1.2, xorg 0.8.2, etc. You get the idea. This is what you have to do with current *nixes. Imagine the tech support trying to help end users with that mess :)

[Charles]

Sir, yes, Sir! :lol:

I think you've summed up PC-BSD pretty much, this is also the reason why this board has gained almost a thousand subscribed users in only 4 months, and why PC-BSD has around 12,500 users already 8)

Kudos to Kris :D

[sblevin]

I like the PBI file idea. So do companies (like real ones - that earn money). I've noticed quite a few larger commercial apps that just "have" to work, doing a similar thing anyway - packaging all the dependencies up in static binaries. It makes the difference between a supportable product and hack fest horror story IMO.

I thought that Apple invented their packaging system, only to find out that the Union file system was already in BSD before they chose it. I wonder if there is a great advantage using Union FS over PBI packages?

[gnutux]

I don't agree with having it universal for Linux too. Maybe with FreeBSD/PCBSD and UNIX but not Linux.

RPM already suits Linux's needs. Although some criticism has been said about RPM. I still think that RPM works on Linux nicely.

I don't know much about PBI as I'm going to install PCBSD later, but I don't think PBI can work with Linux.

gnutux

[scottro]

Y'know, I keep meaning to try this. Has anyone tried pbi's on a native FreeBSD install that doesn't have KDE. For instance, installing firefox from the pbi on FreeBSD that has, for example, only twm and fluxbox?



One of these days I'll do that.

Shoot, I should ask Dru as her next onlamp article is about pbis.

I bet she has..

[scottro]

To answer my own question--I had a free partition where I threw on a quick FreeBSD-6.0 install.

Nope, pbi's don't work on it out of the box. It was looking for a command .startpbi or something similar.

I suspect it could be made to work, but this was an idle curiosity type thing.

[volur.net]

Why FreeBSD and PCBSD is better then Linux distros?

[gnutux]

actually, you have to see that there are major differences. Both FreeBSD and Linux are built differently. Some Linux distributions modify Linux differently too. So you much state which ones. I say that SuSE Linux still out performs FreeBSD/PCBSD/DesktopBSD. Yet, things can change.

gnutux

[Majorlag]

Such a solution will not work for Linux until Linux is more standardized.

I think a better goal would be to promote PBIs as the FreeBSD desktop installer of choice. Step one would be to standardize what minimum requirements need to be available for PBIs to work, then create a self installing PBI-support package to add PBI support to any given KDE-based FreeBSD desktop meeting those minimum requirements. Application packagers could then just add any dependancies not in the spec into the PBI. Right now that spec seems to be "whatever is in the default PC-BSD install", which is kind of alot of stuff.

As part of a larger effort to create a personalized FreeBSD desktop, I've been busy with several concurrent projects (when freetime allows). Now that I'm done with the first part (creating a system for integrating the additon and removal of disks with media:/), I'm moving on to trying to shoehorn the DesktopBSD utilities (specifically the Network Config tool, which is pure awesome) into PC-BSD (and later into my own FreeBSD desktop). After that, I was going to work on adding PBI support to DesktopBSD (and later into my own FreeBSD desktop). If either of those two projects bear fruit, I'll let you know.

[Charles]

I have ported several applications to PC-BSD, and I can confirm it can't work on other systems most of the time because:

1. These applications use KDE variables
2. Most of them use native code for FreeBSD
3. Some of them use KDE system calls such as displaying an alert to the user, etc...
4. When you double-click the application icon, it asks KDE if it has the .pbi extension registered, and if so, which application should be launched to execute this type of file. Only KDE on PC-BSD has all this information.
5. The startpbi.sh, runpbi.sh and so forth are found only on PC-BSD

Good news is that PC-BSD is an excellent system, so there's no need to worry :)

[nhat]

Besides, you can't have PBI's on linux, because it stands for "PcBsd Installer" :)



RPM (Red Hat Package Manager) is not only used in Red Hat :wink:

Seriously, I think the PBI concept should be adopted by linux and the *BSD world as the standard

[Charles]

It's not technically possible. It's like trying to use .exe as a single common executable file for Windows and Linux. It would work on either Windows or Linux but not both of them at the same time.

[antik]

It's not technically possible. It's like trying to use .exe as a single common executable file for Windows and Linux. It would work on either Windows or Linux but not both of them at the same time.

Why not? I heard that gentoo hackers already ported .PBI successfully. There is no big difference in Linux and FreeBSD actually.

[Charles]

Please give me your sources. The only way would we to create a BSD Compat for Linux, which I haven't heard of. I'll be curious to see your sources... :)

[antik]

Please give me your sources. The only way would we to create a BSD Compat for Linux, which I haven't heard of. I'll be curious to see your sources... :)

Strange that I can't find this information anymore- I read that someone ported pbi to linux.... :?

[Majorlag]

It would not be significantly difficult to port the PBI installer, creator, or manager to Linux. Of course, the actual PBIs created for PCBSD will not work on Linux, but using a linux port of the PBI Creator/Installer will make a linux installable PBI.

It would be really confusing to end users "Why doesn't this PBI work on my Linux?" "Because its a PCBSD PBI, not a Linux one!". The only reasonable way to avoid this would be to create a different name for the packages on Linux, something like LPI (Linux Package Installer) for instance.

[Charles]

Strange that I can't find this information anymore- I read that someone ported pbi to linux.... :?

Yes, very strange indeed :lol:

The only reasonable way to avoid this would be to create a different name for the packages on Linux, something like LPI (Linux Package Installer) for instance.

Don't speak too loud they might do just that. No, I'm just kidding, they won't do that, don't worry. They prefer the terminal :)

[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 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 :) (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 :)

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 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 other dev libs would be smartlinkable. This way programs would have minimal footprints 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 :)

Ales

[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 = 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...

[richard-a]

An interesting thread, Charles, Kris, and others.

I have come here from being involved with the Lindows/Linspire fork of Debian Linux over several years. I also run SuSE and Sun Java Desktop System 2 (based on Gnome/SuSE 8.2 heavily customised).

The RPM mess with installs failing because of a dependency someone has missed, or you didn't have on your base system, or whatever, is so painful.

Michael Robertson, whose brainchild Lindows (as it was then) was looking to build a non-geek's downloader-installer which they called "Click-N-Run". This works similarly to PBI in many ways.

The main difference in MO appears to be that if you try to use a regular .deb repository, you can break the Lindows/Linspire installation and its association with CNR. Being a newbie here I'm hesitant to say much more, because although I have tried PBI double click downloads, it's only been in a limited way; however all appear to have worked.

Although I am a technical person I choose not to want to spend time tinkering, preferring to use stuff that works out of the box. When I get my user login here resolved, I can maybe make some posts asking for help in resolving a couple of issues. But I can personally see what a marvellous thjing you have going with PBI.

Even if it isn't copied by other distributions, it is probably the best thing since sliced bread (imho). Certainly it is worth keeping improving it. If Linspire can set up multiple repositories for CNR, you may find that could be workable. But the problem with the CNR system is that it relies heavily on server side stuff which prevents anyone from creating their own CNR file for others to try. Maybe I'm not well enough briefed on how it works, but it seems to me that the PBI concept is more "universal" a way of doing it.

Concluding, does it really matter if some PBIs can't work on some installed OS's? After all not all RPMs will work on all OS's that employ them.

Hope that makes sense.

Best regards,

Richard in Australia

[Verson]

Seriously though, i'm glad to hear that people are starting to realize the vision i've been wanting to bring with PBI's. Its such a simple idea, Windows and Mac use it, but on Linux / Unix we have all this complicated garbage just to install a simple piece of software. I mean, sure, its nice to "share libs" and save a little space, but when it brings all these problems such as dependancy issues, and breaking things on the system, then is it worth it anymore? To this date the answer for it has always been "Lets make it more *powerful* (Gentoo) or use a nicer GUI" (RedHat, Suse, RPM's), which sounds nice, but when the basic premise is flawed, then its only going to work so well. Besides, normal users aren't going to move from something simple to something way more complicated. It just isn't going to happen.

Now on the other hand, running a repository of apps might be easier for the devs then making seperate PBI's of everything, but "que bono", who benefits? In otherwords, if its easier for the devs, is it easier for the end users? I would rather have a system that takes a bit more work for the developers to package and prep their apps, because we have the knowledge to do it. End users just want something that works. Period.

When I go to the store to buy a game, like World of Warcraft for example. I look at the requirements to see if I have a good enough system. Now imagine if I had to do that, and THEN look at the OTHER requirements to see if I have "GTK 2.2.0, libc++.0.6.so, QT 3.3.4, glibc 2.0, libgnome 1.2, xorg 0.8.2, etc. You get the idea. This is what you have to do with current *nixes. Imagine the tech support trying to help end users with that mess :)


Finally the dream has become a reality.
Since first delving into alternative (to M$) operating systems starting with
FreeBSD 4.x, I allways wondered why the dependancy model was chosen for both *nix & Linux. It always seemed more trouble than it was worth. No source software installations were a step in the right direction, however, the nightmare still remained. It was a matter of waiting for someone to implement an idea such as PBI, because I dont' have the necessary programming skills. However, after reading http://www.onlamp.com/pub/a/bsd/2006/01 ... tml?page=1 (http://www.onlamp.com/pub/a/bsd/2006/01/05/FreeBSD_Basics.html?page=1)
"Building Binary PC-BSD Packages" , I find that I do have the necessary skills to build PBIs.
Finally a project worth investing my (limited) time and effort into.
Thanks to all for the good work that has made this project possible

So to all out there who think they are capable of building PBIs, or want to learn, click on the link and read up. Lets make this BIG

[r21vo]

Hello everyone!

I would like to add that I like this PBI idea very much, because since I've been dealing with BSDs, I've always have had problems with dependencies.
It would be very cool to create a seperate PBI system you can install also on other BSDs, for example on FreeBSD.

[mario_net]

I don't agree with having it universal for Linux too. Maybe with FreeBSD/PCBSD and UNIX but not Linux.

RPM already suits Linux's needs. Although some criticism has been said about RPM. I still think that RPM works on Linux nicely.

I don't know much about PBI as I'm going to install PCBSD later, but I don't think PBI can work with Linux.

gnutux

I still have to read on the next part of this thread, but it seems you are in confusion :-D

RPM are known to cause most DEPENDENCY HELLS problems EVER.

[Majorlag]

RPM are known to cause most DEPENDENCY HELLS problems EVER.

Indeed. RPM is so bad it makes even the most time consuming or tedious of the other package managers out there look like the best thing since sliced bread.