a few issues

ok, first off, do I remember rightly that .pbi packages include all their libaries (except presumeably X/KDE stuff) within the same folder, to reduce incompatibility?

If I'm wrong, please skip this paragraph, but if I'm right, that's quite braindead...
There was a thing recently about a security flaw in zlib; to fix this flaw on most systems, all you have to do is replace a single file in the library path (whatever that may be). To fix this under a static linking/pbi system, you need to reinstall every package that uses zlib, and that's a LOT of stuff.
Also, I believe your justification was people have lots of space to put stuff nowadays. Did you consider people who may want to use PC-BSD on dial-up? I've got 1mb broadband, so it's not my problem, but still, dependancy-heavy things could take hours on dial up.
I think a better solution would be to, whenever a library wants to be updated, keep a backup of the previous version (call it foo.1.6.7.so or whatever), and make sure that anything that's installation specifies a version number gets the one it needs (I don't know how to do this, as I've not looked in detail at how runtime linking works, BSD or otherwise, but it seems logically simple enough).
in my opinion, the pbi pipeline should be:
click on pbi->
go through installation guff (license, options, etc)->
check all dependancies are present->if not, find them in ports/pbi repository. If the program uses wierd libraries, then it should contain links to the page they can be obtained from.->
install libraries + package->
Done!
As long as the packages know what version of library they need, or specify they don't care, it should work fine. I've actually not had any library problems with my FreeBSD installation.

Anyway, now I've ranted on that a bit too long, onto kamel ^_^
First, very nice idea, that's the main thing I want out of PC-BSD besides a fluffy installation, hardware detection, and a less 'dump it all in /usr/local/bin' approach, is graphical configuration. But I noticed in all the designs it had a device tree with windows style device names (a:, c:, etc). I hope that's just an example from a convenient windows thing, and not how you plan on designing it, because windows-style namings just a bad idea when part of your slogan is 'BSD style'.
And it's a bad idea to try make kamel into a replacement to konqueror, as it seems like you want. Just keep it focused on being a thing for all the system-specific administration KDE control centre can't realistically do (with a few control centre modules stuck in where appropriate :p)

Aside from that, set up a nice, non-confusing file system (why does BSD have a half a dozen bin paths with no real distinction?), and PC-BSD is a very promising project, maybe capable of surpassing linux if you can keep BSDs speed and stability, and make it more desktop-friendly.

Oh, sorry about the rant for my first post, I got a bit carried away ^_^

[satanman]

Ack; that post was me; I guess I forgot to log on after registering....

oops ^_^

[sblevin]

One of the reasons for all the bin paths is that FreeBSD got it's act together WAY before that other more popular thing with a penguin in it. The penguin thing has started getting it together with LSB. Mandrake jumped straight onto that and proved what a good idea it is to put things in a predictable location.

FreeBSD (and the others I presume) took a sensible approach from almost the start (I think : )

There are three dir structures that look very similar on FreeBSD but their job is a very sensible one, and one that makes instant sense when you realise what they were doing.

Right off the root you will see /bin. Stuff directly in the root is fundamentally critical to the single or multiuser mode. These are absolutely THE ones to have for your system even function at all.

Then there is /usr/bin. Stuff in the /usr folders are where commonly used user stuff goes - This stuff if REALLY important as well, but is kept away from the root /bin to stop stuffing with the lowest core level of system functionality.

The there is /usr/local/bin. The usr/local/blah is messy-land, for local executables and user stuff (us)- this is where the ports will dump their contents. It's the users install vomit bucket (generally) - once again stil important stuff, but if it vanished your system should still come up.

Here is a brief list of the FreeBSD directory hierarchy from http://www.freebsd.org/doc/en_US.ISO885 ... cture.html (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dirstructure.html)


Directory Description
/ Root directory of the file system.
/bin/ User utilities fundamental to both single-user and multi-user environments.
/boot/ Programs and configuration files used during operating system bootstrap.
/boot/defaults/ Default bootstrapping configuration files; see loader.conf(5).
/dev/ Device nodes; see intro(4).
/etc/ System configuration files and scripts.
/etc/defaults/ Default system configuration files; see rc(8).
/etc/mail/ Configuration files for mail transport agents such as sendmail(8).
/etc/namedb/ named configuration files; see named(8).
/etc/periodic/ Scripts that are run daily, weekly, and monthly, via cron(8); see periodic(8).
/etc/ppp/ ppp configuration files; see ppp(8).
/mnt/ Empty directory commonly used by system administrators as a temporary mount point.
/proc/ Process file system; see procfs(5), mount_procfs(8).
/rescue/ Statically linked programs for emergency recovery; see rescue(8).
/root/ Home directory for the root account.
/sbin/ System programs and administration utilities fundamental to both single-user and multi-user environments.
/stand/ Programs used in a standalone environment.
/tmp/ Temporary files, usually a mfs(8) memory-based file system (the contents of /tmp are usually NOT preserved across a system reboot).
/usr/ The majority of user utilities and applications.
/usr/bin/ Common utilities, programming tools, and applications.
/usr/include/ Standard C include files.
/usr/lib/ Archive libraries.
/usr/libdata/ Miscellaneous utility data files.
/usr/libexec/ System daemons & system utilities (executed by other programs).
/usr/local/ Local executables, libraries, etc. Also used as the default destination for the FreeBSD ports framework. Within /usr/local, the general layout sketched out by hier(7) for /usr should be used. Exceptions are the man directory, which is directly under /usr/local rather than under /usr/local/share, and the ports documentation is in share/doc/port.
/usr/obj/ Architecture-specific target tree produced by building the /usr/src tree.
/usr/ports The FreeBSD Ports Collection (optional).
/usr/sbin/ System daemons & system utilities (executed by users).
/usr/share/ Architecture-independent files.
/usr/src/ BSD and/or local source files.
/usr/X11R6/ X11R6 distribution executables, libraries, etc (optional).
/var/ Multi-purpose log, temporary, transient, and spool files.
/var/log/ Miscellaneous system log files.
/var/mail/ User mailbox files.
/var/spool/ Miscellaneous printer and mail system spooling directories.
/var/tmp/ Temporary files that are kept between system reboots.
/var/yp NIS maps.



You add ANOTHER set in there when you add linux binary compatability. That creates another round of /bin and /usr/bin inside the /usr/compat/linux structure linked off root as /compat/linux.

So there you go!

Perhaps the greatest achievment PC-BSD could arrange is to HIDE everything outside /usr/local and /usr/home and perhaps /user/X11R6. Perhaps only configuration programs could write beneath that stucture, unless you actually logged in as root. I dont know about the practicallity, but it sounds like a nice dream to have.

That would be a challenge, but a nice one : )

I personally would like nothing more than to see the PBI builder run as a user that ONLY has write permissions to /usr/local/MyPrograms and /Home/Sub-Dir, and have it invoke pkg_add if it needed to play beneath that. But thats another story for another time .......