Slashdot Mirror
A Look Inside the BBC's Network
the-dark-kangaroo writes "The BBC have provided the entire internet with a look inside their amazing network. It shows everyone the almighty web power they are with over 40 webservers and 12 firewalls and their 8Gbps intersite connections. All this seems to running some form of *NIX with perl underlying their powerful website delivery. Take a look at those load graphs!"
It shows everyone the almighty web power they are with over 40 webservers and 12 firewalls
Well, it's rather a lot, but "almighty?" What ever happened to British undertatement?
One man's -1 Flamebait is another man's +5 Funny.
This is not considered incorrect. "BBC" can be considered a collective noun, and as a Brit, I can say with some certainty that we would use the third person plural pronoun - i.e. "they" to refer to that company without naming it.
:P
In fact, this is commonplace for any company/body corporate/corporation...any group, surely? Consider: Microsoft are evil. They are bastards.
iqu
This isn't a fair question, support.bbc.co.uk is probably hosted on some cast-off machine on someones desk, not on the servers that they are talking about - of course it can be brought down by Slashdot.
Just try that on news.bbc.co.uk, Slashdot won't even make it break a sweat.
A latent existence
> Just remember, security by obscurity is bad! ;)
All security is by obscurity, that is a fundamental truth of any system whose state can be altered. You have to know how to get its state to change and if you know how then you can change its state.
The issue is how much knowledge do you need to be able to change the state of a part of the system, and how much effort do you have to put in to get that information. Also how likely are you to be caught attempting to learn how, and how much of the system can you break into with that information before you have to learn more information (essentially the value of that information).
Strong cryptographic authentication uses a mathematical formula to produce a *different* method of access for each key, and the key is a description of the method. Thus, cracking one key gives you access only to the systems that use the method that that key describes. For a weak cypher, it is relatively easy to determine the correct method to access a system.
Similarly for *all* communication with a computer. If you know what software is used, and you know how to get it to respond, then you have access. So, since you are *always* relying on attackers not knowing the method to access your systems, you must ensure there is a different method for each system to limit damage when the method is no longer obscure.
"Security Through Obscurity" refers to the technique where many system use the same method and depend on none of the other systems being cracked. This is risky: ie, chances of cracking are small, but cost of cracking is extremely expensive as all systems become vulnerable. Though chances are not so small as one may think as the value of the knowledge needed to access the systems is extremely high, and thus more effort tends to be dedicated to its discovery.
This is why open source software will tend to become more secure over time (provided that there is a sufficient interest in its security - ie popularity). While it is less costly to discover the information necessary to crack a system, it is also less costly for the organisations that use it to discover that information, thus the systems tend to be fixed. That also devalues the knowledge from the perspective of the cracker. How many organisations will send their disks to MS for analysis vs how many can do the analysis with reference to the source code.
All those little factors cause the initial risk of open source software to be much higher, but the risk of a mature and popular system to be lower. Compare with closed source, which for new and unpopular software the risk is low, and for mature and popular software, the risk is high.
The best opportunity (as the world begins to realise the value of security) for closed source producers is to be cheap to market, quick to help mature an open source competitor, and quick to help your customers migrate to the open source alternative, siphoning a lucrative support and development contract as you move onto new product as restart the cycle.