Well, it obviously depends on the business we talk about and the likelyhood of them expanding to japan. If a country is on your definate roadmap then, by all means, get the domain early.
Ofcourse there's also no reason to buy the domains of the 10 or so most important countries, just in case.
Just keep it in proportion. My former company is literally spending tens of thousands of dollars yearly, on domains that they'll never use. Many foreign domains are fairly expensive, ranging from hundred bucks a year up to a few hundred bucks. Plus many countries require you to establish some kind of business entity which adds even more cost.
No need to reinvent the wheel here. As said we use jinja for our general templating because it provides all the django niceness plus full power and no limitations.
In the few areas that we want to give out to non-technical designers (or even untrusted users) we just use genshi. The genshi syntax is fairly ugly but has the advantage that a) it is pure XML so we can validate it to make sure it doesn't blow up the surrounding page and to protect against mailicious HTML/javascript and b) there's a toggle to completely sandbox it, just like django templates, so template designers can not execute any code that we don't like.
There's nothing stopping you from using two or even more template languages in the same app - right tool for the job.:-)
Aren't we beyond the point of "must own every tld in existence" by now?
I lived through that in my old company. They literally wanted all TLDs, not only for the primary name but also for most spelling mistakes. And for country-specific spelling mistakes (french people might make different mistakes than english people).
Consequently they had 1-2 fulltime employees doing nothing but domain registration and babysitting. Yes, domains do need babysitting when you're literally owning thousands of them from all countries of the world. Ever deciphered a russian expiry notice? Or tried to establish an office in some arabic country only so that you are allowed to buy a domain from them?
Long story short: Most sane businesses should have realized by now that they really only need the standard set (.com/.net/.org), plus the country TLDs for the countries where they're actually doing business. Everything else is wasted money. If someone squats your name on some obscure foreign TLD then so what? Ignore them or sue them into oblivion (trademark!) if they try to pull off scams in your name.
In fact, journaling is a performance breaker in pretty much every i/o intensive scenario, such as database servers. Ext2 is still the preferred choice on servers here.
Which is just a default, not a policy. Django templates are cleanly isolated from the rest of the framework, so any sensible Python template renderer can simply be plugged in. Here's an example of Cheetah templates being plugged into Django with a dozen lines of glue code. Mako looks like it would be trivial to plug in too.
True. We use jinja most of the time (which has of the best of django templates, minus the hassles), and genshi for XML composition. I picked out django because I judge it by the defaults it ships with and the recommended best practices. Yes, pretty much any web-framework can be shoehorned into something completely different but the further you depart from the intended use, the less can you benefit from the overall integration.
What's wrong with jamming in some "lorem ipsums", fiddling until it renders prettily, then building the necessary view? You can dive in even before the models are built.
As said, there's nothing fundamentally wrong with that (and often the separation is desirable), it's just a hassle during developement and should at least be optional. The fastest way to prototype a webapp is usually to throw some code into the template - django forbids that. I'm not saying that a serious amount of work should be done in the templates, but it really helps in the building phase and even in production code it doesn't hurt to have the occassional "d = new Date()" or such in a template. Sticking small snippets of logic into the template can often make the end-result *more* pluggable, by not the concerning controller with low-level view details.
An even better property is that it forces the software engineer to separate the logic from the presentation, no laziness allowed. That makes it dead simple to reuse the logic for any number of presentation formats. For example, suppose you make a web page that shows a completed e-commerce purchase. With more templates and a few lines of glue code, the logic can be trivially reused to generate an e-mail copy of the order form, a.csv for the accounting system, a WAP version, shipping labels, a packing list, a PDF RMA label, and so forth.
Force can be good for newbies (force them to do the right thing) but once you're beyond that it becomes a two-bladed sword. As I outlined above, sometimes it *is* better to move a small snippet of logic into the template, for the very purpose of pluggability. A general purpose controller for all the views that you described above will likely be quite loaded with presentation details (PDF renderer etc.). Moving these details to the actual template *can* be a better solution in the long run because it keeps controller complexity down and ideally you won't have to touch the controller when you add new views. Again, I'm not advocating that this is always the way to go (it obviously isn't when you need to have non-programmers work on the templates), I'm just saying that there it is a valid choice that shouldn't be banned for the sake of purity.
Exactly. Reminds me of the old saying: "Dogmas are wrong, always.".
Django is a good example for the drawbacks of this approach since it went to the extreme and allows almost no logic in the templates - beyond the usual iteration and conditional constructs.
The result? It's a pain to develop with this part of django. Django constantly gets in the way here because you can't scribble even the smallest thing into a template to see if it works or "feels right", you have to fiddle with the controller or a custom filter all the time - and that becomes tiresome very soon.
This separation of concerns obviously makes sense in a settled application that is deployed in, say, the publishing business, where you don't want the template guys to accidently screw with production code. But it does not scale down to the building (or "evolution") phase of said application, or to very small teams where everybody is assumed to know what they're doing, or to applications where the separation is simply not needed at all.
Generally fast feedback and short cycles are most critical during development, especially in the webapp realm which is tedious enough due to the whole browser involvement. The last thing you need is artificial barriers while trying things out and shaping up...
So, we have a profitable company here that rakes in hundreds of millions of dollars per quarter? After paying the employees? After taxes? You mean, pure profit? Why in fucking hell are they so eager to sell it then? How greedy can you even get? If this kinda attitude is the norm nowadays then I can only shake my head in disgust and say: everyone involved probably deserves what they'll get.
On a more productive note: If you're so worried that all your products are crap and that your profit *may* decline into the two-digit millions-per-quarter range (god forbid!) then here's what you do:
Fund startups.
If your inhouse staff has grown so incompetent that your products are not competitive anymore then that's what you need, fresh blood. Most startups can go a very long way with investments as low as $100k (or heck, $1mio, as if it mattered on the yahoo scale). So if you only fund the most promising ones and keep it real overall then you'll probably hit the jackpot once or twice per year.
To someone who's in the process of building a startup (and fighting for every penny) this whole discussion feels like a slap in the face.
All these things mean nothing when you're over at a someone elses computer and just want to copy a friggin' file from or to the stick. FAT will work every time. Any other filesystem will simply not work on some of the computers that you come across without installing extra drivers.
FAT is still the only option last time I checked. It's the only one that is supported out-of-the-box on every machine (and appliance) that you'll come across.
I hear you and I'm sure the filesystem developers have the same ideas in their heads. The problem is that there are some really hard problems involved with these things.
In the end everybody wants basically the same thing: A volume that we can write files to. This volume should live on a pool of physical disks to which we can add and remove disks at will and during runtime.
The unused space should always be used for redundancy, so when our volume is 50% full then we'd expect that 50% of the disks (no matter which) can safely fail at any time without data loss.
Furthermore we don't really want to care about any of these things. We just want to push physical disks into our server, or pull them, and the pool should grow/shrink automagically. And ofcourse we want to always be able to split a pool into more volumes, as long as there's free space in the pool we're splitting from. Ideally without losing redundancy in the process.
We want all these things and on top we want maximum IOPS and maximum linear read/write performance in any situation. Oh, and we won't really be happy until a pool can span multiple physical machines (that will auto re-sync after a network split and work-as-expected over really slow and unrealiable networks), too.
ZFS is a huge step forward in many of these regards and there's a whole industry built solely around these problems. Only time will tell which of these goals (and the ones that I omitted here) can really be achieved and how many of them can be addressed in a single filesystem.
A hacked client could just as well use hacked artwork but at the same time perform the hashes over a copy of the original artwork. It's just another step in the arms-race and imho not a very effective one. Once a hacker has managed to gain control over the hash-function it probably doesn't matter much to him whether he just sends stored hashes or performs partial hashes over an existing set of files...
The server needs all the game resources to compare files hashes with the hashes the client sends to be sure they're not replacing files.
That's just lazyness. Instead of storing the actual game artwork the server could just store a list of the hashes - and save a couple hundred megabytes (sometimes gigabytes) of diskspace.
It probably is some windows worm or something written by a script-kiddie. But to admit that would be to embarrassing, so they make it out to be a big deal.
It is exactly this vain "cover-my-ass" attitude that makes situations escalate, sometimes up to the point of war. I understand that a bunch of old farts in DoD feel a strong need to justify (or increase) their Cyberwarfare budgets but pointing fingers at an allied country (relations with which are not always easy) in public over a non-issue like this is, imho, going way too far.
Network security by isolation of the critical parts is possible and this whole "cyberwarfare"-bullshit is just driving tears into the eyes of anyone who knows a bit about the subject. Yes, an attacker could overload and DoS less important/perimeter networks and yes an attacker may able to overtake various individual machines or department networks, e.g. by sneaking trojans onto employee's computers, phishing etc.
If any of that worries you in a national-security kind of way then do your fucking homework and implement appropiate security layers and airgaps already! A flash trojan is a non-issue because a critical system won't run flash. In fact, a critical system won't even interface with a system that could be taken over in such a way.
Over here in germany the best ads are those ringtone ads. You know, where some crazy tweety animal advertisesthe latest tunes ("SMS 12 for Britney Spears", "SMS 13 for Aguilera") and such. These ads usually have 5-6 lines of legal text squeezed into the bottom two inch of the screen. Unless you're watching on a 60" Plasma it's absolutely impossible to only decipher the letters of the text, much less actually read all those fun facts about "entering a binding contract", "recurring bills", "minimum age" etc.
What stops me from running my notebook with third-party RAM for 3 years and swapping the original RAM back in only on the day that I return the lappy for "upgrade"?
No, I think the real kicker is this:
Customers will have to hope that the UK manages to avoid high levels of inflation, though; the value of each new notebook cannot exceed the value of the previous one, adjusted 10% for inflation.
The "value"? You mean the price? Hmm. Who sets the price? Oh, right, Fujitsu Siemens. So I suspect 3 years down the road you'll be offered an upgrade laptop that is complete crap, but at the same they'll offer you to upgrade to something worthwhile for "a small additional fee".
Re:But does it run on .... shit that does not work
on
Fedora 10 Released
·
· Score: 1
That's probably because you don't have them. You've built a workflow around the tools you have; that's what people do.
Well, I agree with your assertion ("people built workflows with what they have") but I think the workflow you describe below is not an example for how those features can be useful but rather a textbook example of how these features can lure you into shooting yourself into the foot by taking perceived "shortcuts" that turn into a big mess - sometimes only minutes later.
I'm a consultant, so I work on a lot of hosts that were set up by someone else. They aren't going to have my own personal repositories set up on them, so working with packages that aren't in a repository is essential to me. Using "provides" is non-trivial, too. Consider that if you install the Lightning extension to Thunderbird on a current (32 bit) machine, it won't work. Why? Well: $ ldd.thunderbird/*/extensions/*/components/*.so | grep 'not found'/usr/lib/libstdc++.so.5 => not found
They built against an old version of libstdc++. We'll need that: # yum install libstdc++.so.5
How else would I know that the library is provided by compat-libstdc++-33? Or that libcucul.so.0 is provided by a package named libcaca?
If you regularly need to install custom packages on remote hosts then the straightforward solution would be to setup a public package mirror. It isn't much work, you have to do it only once and it removes all these nasty dependency problems from your on-site workflow. Carrying around bare RPMs (or DEBs fwiw) on an USB-stick, unless those are completely self-contained, is a non-starter in first place.
Yum bandaids a problem for you here that you created yourself in first place. Or, to turn your initial assertion around: People build workflows with what they have and yum supports a broken workflow here that wouldn't have been feasible deb.
Furthermore, when working with a package manager you should never have to know that a file by the name 'libstdc++.so.5' even exists on your system. The moment that this information is exposed to the user the package manager has failed to do its job. It is one of its primary purposes to hide these nasty details from the user, after all.
The same is true of perl. If I download a script and it complains that it can't find Date/Format.pm, I can ask yum to get it:
# yum install 'perl(Date::Format)'
How else would I know that Date/Format.pm is in perl-TimeDate rather than perl-DateTime or perl-Date-Simple?
Different story, same problem. Ever heard of CPAN? It's generally a bad idea to install perl- (/python-/ruby-, whatever) modules from a distro repository in order to satisfy a dependency for a file that is not *also* in the distro repository. This is a bit of common sense that most people learn the hard way sooner or later. Yum doesn't do you a favor by supporting this workflow.
If you live entirely within the repository, then apt is fine. If you ever want to use something that's not there yet, yum is a much superior tool.
Now you sound a bit like Darth Vader, advertising the dark side.;-) I'm not exactly sure what you mean by living "within" or "outside" the repository (disconnected operation, custom packages?) but reality is that the two examples you provided are, again, textbook examples for how people slowly screw up their linux boxes over time by mixing repository stuff with non-repository stuff and introducing cross-dependencies between the two.
The chain breaks as soon as you attempt to install a CPAN module via yum that is not in yum. Then you go and install it via CPAN, because you need it now. Later that same module finally *does* make it into the yum repos and it gets pulled onto your machine via some tertiary dependency during the installation of something completely different. Days later you not
Most work contracts that I have seen here in germany do contain a Non-Disclosure clause ("Rule #1: You don't talk about the fight club"). I don't know how enforcable they are in reality but I guess they're primarily meant as a hook to build a lawsuit around when necessary. The company is probably better off in court when it can at least say "We told you to keep our stuff secret" (without even further defining "stuff" in the initial contract) than when the employee can claim "You never told me that I'm supposed to shut up about the inner workings of our perpetual motion machine design".
Re:But does it run on .... shit that does not work
on
Fedora 10 Released
·
· Score: 1
I'm not a debian zealot but in defense of apt I have to say that all these features that you mentioned seem pretty much useless to me. Useless as in: I have never needed anything like that in my 8 years on various linux distros (deb, rpm, gentoo), not even once.
The only feature that seems at least theoretically useful would be the last one. I could imagine using that when testing a package that I rolled myself, but in reality you just set up a local package mirror for that which you need anyways when you get serious into package building.
In summary I find overall performance of the tools *much* more important than such esoteric features. I curse every time I have to use emerge on a gentoo box ("Calculating dependencies" anyone?) and it's one of the secondary reasons why I'm slowly moving away from that distro.
The difference is: When a fuse pops in the head of a soldier then he may go on a killing rampage. When a fuse pops in the head of a General (or heck, a president) and he controls a robot army then said robot army goes on a killing rampage. Without asking questions.
Yes, there will be safeguards and multiple levels of protection in the system - just like what we have for nukes today. But even with these protections in place we've had "almost-nukes" in the past. Would you like to have "almost robot-war"'s?
Slashdot Mirror
Well, it obviously depends on the business we talk about and the likelyhood of them expanding to japan.
If a country is on your definate roadmap then, by all means, get the domain early.
Ofcourse there's also no reason to buy the domains of the 10 or so most important countries, just in case.
Just keep it in proportion. My former company is literally spending tens of thousands of dollars yearly, on domains that they'll never use.
Many foreign domains are fairly expensive, ranging from hundred bucks a year up to a few hundred bucks. Plus many countries require you to establish some kind of business entity which adds even more cost.
No need to reinvent the wheel here.
As said we use jinja for our general templating because it provides all the django niceness plus full power and no limitations.
In the few areas that we want to give out to non-technical designers (or even untrusted users) we just use genshi. The genshi syntax is fairly ugly but has the advantage that a) it is pure XML so we can validate it to make sure it doesn't blow up the surrounding page and to protect against mailicious HTML/javascript and b) there's a toggle to completely sandbox it, just like django templates, so template designers can not execute any code that we don't like.
There's nothing stopping you from using two or even more template languages in the same app - right tool for the job. :-)
Aren't we beyond the point of "must own every tld in existence" by now?
I lived through that in my old company. They literally wanted all TLDs, not only for the primary name but also for most spelling mistakes. And for country-specific spelling mistakes (french people might make different mistakes than english people).
Consequently they had 1-2 fulltime employees doing nothing but domain registration and babysitting. Yes, domains do need babysitting when you're literally owning thousands of them from all countries of the world. Ever deciphered a russian expiry notice? Or tried to establish an office in some arabic country only so that you are allowed to buy a domain from them?
Long story short: Most sane businesses should have realized by now that they really only need the standard set (.com/.net/.org), plus the country TLDs for the countries where they're actually doing business. Everything else is wasted money. If someone squats your name on some obscure foreign TLD then so what? Ignore them or sue them into oblivion (trademark!) if they try to pull off scams in your name.
In fact, journaling is a performance breaker in pretty much every i/o intensive scenario, such as database servers.
Ext2 is still the preferred choice on servers here.
True. We use jinja most of the time (which has of the best of django templates, minus the hassles), and genshi for XML composition. I picked out django because I judge it by the defaults it ships with and the recommended best practices. Yes, pretty much any web-framework can be shoehorned into something completely different but the further you depart from the intended use, the less can you benefit from the overall integration.
As said, there's nothing fundamentally wrong with that (and often the separation is desirable), it's just a hassle during developement and should at least be optional. The fastest way to prototype a webapp is usually to throw some code into the template - django forbids that. I'm not saying that a serious amount of work should be done in the templates, but it really helps in the building phase and even in production code it doesn't hurt to have the occassional "d = new Date()" or such in a template. Sticking small snippets of logic into the template can often make the end-result *more* pluggable, by not the concerning controller with low-level view details.
Force can be good for newbies (force them to do the right thing) but once you're beyond that it becomes a two-bladed sword. As I outlined above, sometimes it *is* better to move a small snippet of logic into the template, for the very purpose of pluggability. A general purpose controller for all the views that you described above will likely be quite loaded with presentation details (PDF renderer etc.). Moving these details to the actual template *can* be a better solution in the long run because it keeps controller complexity down and ideally you won't have to touch the controller when you add new views. Again, I'm not advocating that this is always the way to go (it obviously isn't when you need to have non-programmers work on the templates), I'm just saying that there it is a valid choice that shouldn't be banned for the sake of purity.
Welcome to the real world, I guess.
Exactly. Reminds me of the old saying: "Dogmas are wrong, always.".
Django is a good example for the drawbacks of this approach since it went to the extreme and allows almost no logic in the templates - beyond the usual iteration and conditional constructs.
The result? It's a pain to develop with this part of django. Django constantly gets in the way here because you can't scribble even the smallest thing into a template to see if it works or "feels right", you have to fiddle with the controller or a custom filter all the time - and that becomes tiresome very soon.
This separation of concerns obviously makes sense in a settled application that is deployed in, say, the publishing business, where you don't want the template guys to accidently screw with production code. But it does not scale down to the building (or "evolution") phase of said application, or to very small teams where everybody is assumed to know what they're doing, or to applications where the separation is simply not needed at all.
Generally fast feedback and short cycles are most critical during development, especially in the webapp realm which is tedious enough due to the whole browser involvement. The last thing you need is artificial barriers while trying things out and shaping up...
So, we have a profitable company here that rakes in hundreds of millions of dollars per quarter? After paying the employees? After taxes? You mean, pure profit?
Why in fucking hell are they so eager to sell it then? How greedy can you even get? If this kinda attitude is the norm nowadays then I can only shake my head in disgust and say: everyone involved probably deserves what they'll get.
On a more productive note: If you're so worried that all your products are crap and that your profit *may* decline into the two-digit millions-per-quarter range (god forbid!) then here's what you do:
Fund startups.
If your inhouse staff has grown so incompetent that your products are not competitive anymore then that's what you need, fresh blood.
Most startups can go a very long way with investments as low as $100k (or heck, $1mio, as if it mattered on the yahoo scale). So if you only fund the most promising ones and keep it real overall then you'll probably hit the jackpot once or twice per year.
To someone who's in the process of building a startup (and fighting for every penny) this whole discussion feels like a slap in the face.
Uh huh. Thanks for reminding us that the bible has a retarded quote for just about everything.
Isn't that just like slashdot?
Everybody's aiming for +5 Insightful but it's even better when you get +5 Funny!
We were talking about USB-sticks, right?
All these things mean nothing when you're over at a someone elses computer and just want to copy a friggin' file from or to the stick.
FAT will work every time. Any other filesystem will simply not work on some of the computers that you come across without installing extra drivers.
Only 63%? Who's the other 37%?
I would've thought more in the >90% range.
Ah, anyone can edit wikipedia. I say he's just showing off to get the chicks!
FAT is still the only option last time I checked.
It's the only one that is supported out-of-the-box on every machine (and appliance) that you'll come across.
I hear you and I'm sure the filesystem developers have the same ideas in their heads.
The problem is that there are some really hard problems involved with these things.
In the end everybody wants basically the same thing: A volume that we can write files to.
This volume should live on a pool of physical disks to which we can add and remove disks at will and during runtime.
The unused space should always be used for redundancy, so when our volume is 50% full then we'd expect that 50% of the disks (no matter which) can safely fail at any time without data loss.
Furthermore we don't really want to care about any of these things. We just want to push physical disks into our server, or pull them, and the pool should grow/shrink automagically.
And ofcourse we want to always be able to split a pool into more volumes, as long as there's free space in the pool we're splitting from. Ideally without losing redundancy in the process.
We want all these things and on top we want maximum IOPS and maximum linear read/write performance in any situation. Oh, and we won't really be happy until a pool can span multiple physical machines (that will auto re-sync after a network split and work-as-expected over really slow and unrealiable networks), too.
ZFS is a huge step forward in many of these regards and there's a whole industry built solely around these problems.
Only time will tell which of these goals (and the ones that I omitted here) can really be achieved and how many of them can be addressed in a single filesystem.
Oh, who does that?
My OS certainly doesn't care.
A hacked client could just as well use hacked artwork but at the same time perform the hashes over a copy of the original artwork. It's just another step in the arms-race and imho not a very effective one. Once a hacker has managed to gain control over the hash-function it probably doesn't matter much to him whether he just sends stored hashes or performs partial hashes over an existing set of files...
That's just lazyness. Instead of storing the actual game artwork the server could just store a list of the hashes - and save a couple hundred megabytes (sometimes gigabytes) of diskspace.
It is exactly this vain "cover-my-ass" attitude that makes situations escalate, sometimes up to the point of war. I understand that a bunch of old farts in DoD feel a strong need to justify (or increase) their Cyberwarfare budgets but pointing fingers at an allied country (relations with which are not always easy) in public over a non-issue like this is, imho, going way too far.
Network security by isolation of the critical parts is possible and this whole "cyberwarfare"-bullshit is just driving tears into the eyes of anyone who knows a bit about the subject.
Yes, an attacker could overload and DoS less important/perimeter networks and yes an attacker may able to overtake various individual machines or department networks, e.g. by sneaking trojans onto employee's computers, phishing etc.
If any of that worries you in a national-security kind of way then do your fucking homework and implement appropiate security layers and airgaps already!
A flash trojan is a non-issue because a critical system won't run flash. In fact, a critical system won't even interface with a system that could be taken over in such a way.
Over here in germany the best ads are those ringtone ads. You know, where some crazy tweety animal advertisesthe latest tunes ("SMS 12 for Britney Spears", "SMS 13 for Aguilera") and such.
These ads usually have 5-6 lines of legal text squeezed into the bottom two inch of the screen. Unless you're watching on a 60" Plasma it's absolutely impossible to only decipher the letters of the text, much less actually read all those fun facts about "entering a binding contract", "recurring bills", "minimum age" etc.
What stops me from running my notebook with third-party RAM for 3 years and swapping the original RAM back in only on the day that I return the lappy for "upgrade"?
No, I think the real kicker is this:
The "value"? You mean the price? Hmm. Who sets the price? Oh, right, Fujitsu Siemens. So I suspect 3 years down the road you'll be offered an upgrade laptop that is complete crap, but at the same they'll offer you to upgrade to something worthwhile for "a small additional fee".
Well, I agree with your assertion ("people built workflows with what they have") but I think the workflow you describe below is not an example for how those features can be useful but rather a textbook example of how these features can lure you into shooting yourself into the foot by taking perceived "shortcuts" that turn into a big mess - sometimes only minutes later.
If you regularly need to install custom packages on remote hosts then the straightforward solution would be to setup a public package mirror. It isn't much work, you have to do it only once and it removes all these nasty dependency problems from your on-site workflow. Carrying around bare RPMs (or DEBs fwiw) on an USB-stick, unless those are completely self-contained, is a non-starter in first place.
Yum bandaids a problem for you here that you created yourself in first place. Or, to turn your initial assertion around: People build workflows with what they have and yum supports a broken workflow here that wouldn't have been feasible deb.
Furthermore, when working with a package manager you should never have to know that a file by the name 'libstdc++.so.5' even exists on your system. The moment that this information is exposed to the user the package manager has failed to do its job. It is one of its primary purposes to hide these nasty details from the user, after all.
Different story, same problem. Ever heard of CPAN? It's generally a bad idea to install perl- (/python-/ruby-, whatever) modules from a distro repository in order to satisfy a dependency for a file that is not *also* in the distro repository. This is a bit of common sense that most people learn the hard way sooner or later. Yum doesn't do you a favor by supporting this workflow.
Now you sound a bit like Darth Vader, advertising the dark side. ;-)
I'm not exactly sure what you mean by living "within" or "outside" the repository (disconnected operation, custom packages?) but reality is that the two examples you provided are, again, textbook examples for how people slowly screw up their linux boxes over time by mixing repository stuff with non-repository stuff and introducing cross-dependencies between the two.
The chain breaks as soon as you attempt to install a CPAN module via yum that is not in yum. Then you go and install it via CPAN, because you need it now. Later that same module finally *does* make it into the yum repos and it gets pulled onto your machine via some tertiary dependency during the installation of something completely different. Days later you not
Most work contracts that I have seen here in germany do contain a Non-Disclosure clause ("Rule #1: You don't talk about the fight club"). I don't know how enforcable they are in reality but I guess they're primarily meant as a hook to build a lawsuit around when necessary. The company is probably better off in court when it can at least say "We told you to keep our stuff secret" (without even further defining "stuff" in the initial contract) than when the employee can claim "You never told me that I'm supposed to shut up about the inner workings of our perpetual motion machine design".
I'm not a debian zealot but in defense of apt I have to say that all these features that you mentioned seem pretty much useless to me.
Useless as in: I have never needed anything like that in my 8 years on various linux distros (deb, rpm, gentoo), not even once.
The only feature that seems at least theoretically useful would be the last one. I could imagine using that when testing a package that I rolled myself, but in reality you just set up a local package mirror for that which you need anyways when you get serious into package building.
In summary I find overall performance of the tools *much* more important than such esoteric features. I curse every time I have to use emerge on a gentoo box ("Calculating dependencies" anyone?) and it's one of the secondary reasons why I'm slowly moving away from that distro.
I think you're confusing scales here.
The difference is: When a fuse pops in the head of a soldier then he may go on a killing rampage.
When a fuse pops in the head of a General (or heck, a president) and he controls a robot army then said robot army goes on a killing rampage. Without asking questions.
Yes, there will be safeguards and multiple levels of protection in the system - just like what we have for nukes today.
But even with these protections in place we've had "almost-nukes" in the past. Would you like to have "almost robot-war"'s?