Linked by Thom Holwerda on Tue 14th Feb 2006 22:25 UTC
PC-BSD "After using PC-BSD several days, I was impressed with how easy it is to use. It's a good desktop OS, and a great way to introduce BSD to new users. The 1.0 release has a few rough edges, but nothing that should scare off prospective users. For the future, I'd like to see something like Synaptic to manage PBI packages and allow users to browse for software without having to visit the PC-BSD Web site, and it would be nice if the site had a little more documentation, but I expect such things will come along in due time as the project matures."
Thread beginning with comment 95799
To read all comments associated with this story, please click here.
by bsdusr on Wed 15th Feb 2006 09:06 UTC
Member since:

For those who dislike PC-BSD because of disagreeing with the PBI technology, there is DesktopBSD.

DesktopBSD uses ports through a GUI frontend and has an easy installer as well.

Why is the PBI system not an option Kernelpanic? Have you even tested is to see what it does/can do?

Just because you dislike it, doesn't mean it can't be a great idea (although, i'd agree, it has a lot to rogress).

Reply Score: 3

RE: DesktopBSD
by Almindor on Wed 15th Feb 2006 09:24 in reply to "DesktopBSD"
Almindor Member since:

I agree with him on the .PBI problem. Their solution to "library hell" is to bring all libraries with you in the .PBI and put them in local-per-program subdirectory for each program. This has 2 consequences:

1. Programs which PRODUCE other programs (compilers/IDE combos etc.) will work but their "product" won't because it won't find the required libraries.

2. Memory usage will grow as there will be many instances of the same (or slightly version different) library per each program. This is actualy braking the usefulness of .so altogether.

This is not just some random rant, I am writing this from PCBSD and I also contributed one .PBI myself (Lazarus)

I think however that the .PBI concept is nice for "end-user" apps which don't "provide" (typical is openoffice or firefox) but not for programs which "produce" something which needs a framework. I think that putting all possible(or most atleast) frameworks through ports and then using end apps via .PBI might be the best solution with possibility of combined checking or atleast one way (so a PBI can see if it has the libs and if not, will install a pkg which it has with itself)

Reply Parent Score: 4

RE[2]: DesktopBSD
by molnarcs on Thu 16th Feb 2006 00:42 in reply to "RE: DesktopBSD"
molnarcs Member since:

Actually, I think we can have best of both worlds here. What needs to be done is to clarify what belongs to the "base system" (in good FreeBSD tradition) - and make PBI creator skip those libraries that we can expect to be present on all PC-BSD installs.

Ring 0 would be FreeBSD base system + xorg and all their dependencies. Kdelibs, qt, and kdebase might go there as well, with all its dependencies. If you think in an integrated solution (KDE part as the OS for instance) - users will have at least that on each PC-BSD install. And if you come to think of it: FreeBSD + xorg (server, libs, fonts, etc.) + kdebase + qt + kdelibs = that pretty much covers the majority (wild speculation: 70-90%) of all shared libraries you'll ever need for your PBIs. Which means the "overhead" (in memory for instance) is either minimal or non existent (pretty much all "independent" kde apps - scribus, kdissert, tellico, k3b - these are just the ones I use - will be satisfied without any additional libs in the PBI ;)

Reply Parent Score: 1

RE[2]: DesktopBSD
by quique on Thu 16th Feb 2006 06:57 in reply to "RE: DesktopBSD"
quique Member since:

Their solution to "library hell" is to bring all libraries with you in the .PBI and put them in local-per-program subdirectory for each program. This has 2 consequences:

Doesn't Mac OS X work that way?

Reply Parent Score: 1