If its not to much trouble

[TerryP]

Could yall make up your freaking minds and stick to it?

SAL1600# file /Programs
/Programs: symbolic link to `/usr/Programs'
SAL1600# file /usr/local/MyPrograms
/usr/local/MyPrograms: symbolic link to `/Programs'
SAL1600# file /usr/Programs
/usr/Programs: directory
SAL1600# ls /usr/Programs/
.bin                    .sbin                   FlashPlugin7
.config                 .tmp                    SeaMonkey1.0.7
.libs                   AllCodecs20061022       emu10kx20051021
SAL1600# uname -a
FreeBSD SAL1600 6.1-RELEASE-p11 FreeBSD 6.1-RELEASE-p11 #5: Wed Dec 20 18:29:42 PST 2006     root@PCBSD.localhost:/usr/obj/usr/src/sys/PCBSDv1.3-SMP  i386
SAL1600#

I understand the concept of backwards compatibility and here Microsoft might finally drop MS-DOS compatiblity :-) But please, will you stop moving this freaking directory ! Just write a single place into the hier(7) manual page, then let PBI Developers know about it in advance and stop moving the bloody thing around every six months. Thank you kindly.


PS: I'm glad my PBI are not installed on a seperate partition from root or usr, at one point I often would use some thing like 384mb /var, 4096mb swap, 8192mb /, 20480 /Programs, and 48768mb /usr in one slice.

[Charles]

Wow, 4 gigs for SWAP... Is this a dev box? 8)

I agree, /Programs should stay that way.

[TerryP]

Actually theres only 4 GB of swap because I have 2GB of RAM with a max capacity of 4GB, if I ever max it out some day I'll have equal swap / memory without adding another swap partition or two.

[Charles]

Yeah, actually the fact that one should have twice more swap than RAM stands true only if you have few RAM (256, 512 megs). When you have 1GB+ you can have less than 2GB swap if you don't think you'll use swap that much.

[TerryP]

I don't think I've ever used a lot of swap, but who knows in the future.

Also this is some thing I was thinking about. I'd expect ti would take some recompiling, source editing, and potentially remaking PBIs depending on how PC-BSD implements the PBI installation systems but here it goes.

Why not use a modular path instead of some thing pre-set? Right now it seems depending on what version of PBC it was made in. You ether get a PBI in /usr/local/MyPrograms, /usr/Programs, or /Programs. Ok so you can install a PBI made from before PC-BSD 0.8 BETA on a PC-BSD 1.3 system if it was very well made. Whats the odds of that m8? No offense.

So now, what if the installation wizard looked for an env. Variable to tell it where to install to. For example if one was to put in the .*shrc files with the right syntaxes (about 3minutes work). Some thing like

PBIROOT=/usr/Programs; export PBIROOT

So what ever $PBIROOT was set to the system would check if it exsists and install into that. That way some one could actually make /Programs/* any where they want, set the path and move/copy the files manually.; Heck if this don't link into the file system so you can install a PBI and a pkg side by side theory stuck to. You could install PBI.1.0.3 in /Programs, PBI.1.0.4 in /usr/Programs and App1.0.5 from ports all on the same system.

Of course the /usr/local/share/<config> directories and any linked man pages e.t.c. would get in the way just as much as installing a well made PBI along side a package would this very day.


Rat bollocking **A*(Y!@ !*($!, I wish I knew C++ in more depth and how to work with QT.