this is such a nebulous question. you want your dev/qa/pre-prod to emulate your production environment as much as possible. this subject in itself could fill a book on best practices, techniques, and the like. Easiest said by saying: keep all developed code separate from 3rd party application code. packages/versioning/repositories are a good start. make things relocatable, have one installer, and have it take multiple environmental variables. ie - make environment variables 'run time', don't make the same mistake everyone makes - and make them 'build-time'.

Best of Luck.

the skillz market for hacking phones just went up again. when will these music industries/RIAJ/RIAA/etc ever learn from Amazon/Ebay/etc? Its all about customer experience. This may be the same reason why top100 music generally licks balls.
my 2 cents.

likely responded to this, and so shall I.

as part of the scm world -- i like to be true to a real dotted quad notation when referring to build versions. i've never really built code that is deployed to the public world .. only code used on company production servers for public consumption (mostly java based web sites, and middleware)

1.2.3.4 = Major level 1, Minor level 2, Patch 3, Build 4.

Major = major release. no longer compatible with previous versions.
Minor = minor release, still compatible with previous versions (with same Major)
Patch = the number of patch builds required to get to latest production patched code
Build = the daily build number. increments by 1 until dev/qa is complete, and code is released to Staging servers.

build numbers stop, once patching starts. the patching denotes the patch to last known good build.

ie -- dev/qa releases should always be num.num.zero,buildnum. (1.2.0.40)
once released to staging - and if a patch is required -- the rev increments as such for the first patch - 1.2.1.40. second patch 1.2.2.40, and so on.
once in production -- wait until next release.

if code is released to the public, and not running on a company's servers -- always drop the build number. so, if you're delivering 1.2.2.40 binaries to the public, cut it down to 1.2.2 and deliver your rpm/pkg/deb, etc to the world.

if this confuses you, im available for hire at your location. references available upon request. :p

yep, and mod this parent up, as 'correct' (while modding this post down as uninformative .. hehe)

sorry dude -- and not to downplay what the original post is about...but i played JK2, and the rest of the game sucked ass. The only decent part *was* the sabering .. so, playing on a server where getting into duels was pretty much the best part. If you honestly wanted to shoot a guy (who happened to be running around with a saber) with a pistol .. it turned into the proverbial 'knife to a gun fight'. saberists didnt stand a chance .. and it ruined the game so to speak. infact, it just turned the coolness of having a saber into unreal tournament without the headshots.

and who wanted that?

i'd have to say, however, that comparing two SANs like you've done, doesnt necessarily mean that 15k is better. i would presume that if your SAN has 20TB more space, it likely has more disk. If it has more disk space, it has likely been partitioned out for more IOPS, by "virtue" of having more disks. More disks = more IOPS, especially in a RAID 1+ 0 configuration.

Not that I'm disagreeing with you -- 15k drives are definitely faster, its just the logic. I guarantee I could build a faster SAN with 10k rpm disks (with more disks), than with a nominal amount of large sized 15k disks.

believe so. A large chunk of the 407 ETR in northern toronto is made up of concrete, atleast when it was provincially owned. in recent years, the consortium that runs/leases the road has been slapping down asphalt as it is cheaper (for certain widening, etc). that concrete has lasted far longer than any asphalt i've seen.

but said company (by slashdot rules) is not allowed to give out any information on any internet user for fear of rapproach via uploading/bittorrent/music/movies etc -- but should be willing to bend to law enforcement in any other case? seems odd.

woot!! cept maybe this might give me multi OS capabillity too.

honestly, its about time i can get OBP functionality (or newly improved version of it) from an x86_64 pc. all this time .. we've been deprived this privilege ..

i'll add, however, that this actually is a possibility. Many of the larger equipment pieces (read 80-150ppm) use Windows based RIPs for data being sent to them. The RIP is usually attached to the digital copier/printer (either on the floor beside the device, or builtin), and is fairly easily cracked. You can install just about any piece of software on it you like, as long as it works on the windows platform that the printer uses. if that means kazaa, or some other windows app, it will work. RIPs typically house large print docs too, which means a good chunk of available space...

not trying to give credence to MediaSentry (as I have no idea what it is), just to say that this sort of thing is 'possible'. those corporations that you think are locking things down in their products, are just as lazy/busy as everyone else.