The whole point of HTML is that it's firewall friendlier? The whole point of firewalls is to control what kind of traffic you let through and what applications you expose. Tunnelling everything through HTTP just means you need an even cleverer firewall that can inspect each packet and decode the application layer stuff in it before passing it through. And HTTPS makes the problem even worse. Sigh.
The real costs in software development are not normally blue-sky research. In most cases the costs are those of development.
To compete with a product, a company would have to incur those development costs themselves, all the while catching up with the current state of play while the original company likewise kept advancing. And then to convince the marketplace to go with them rather than the established market leader. It's doubtful they could sell it much cheaper than the original; if they could - well, they have better processes, and that's how things improve in a competitive environment.
If software really needs patents, I'd be interested to hear from the pro-patent lot (assuming there are any on/.) examples of software in which really fundamental research needed the protection it would afford. I'm hard pressed to think of many things, except possibly in the fields of data compression and encryption where the value really is in the algorithm and not the implementation, (which is often trivial to implement once you know how).
Yes, Diffie-Hellman is based on discrete logs. I'm not an expert on quantum algorithms, but I believe that Shor had quantum algorithms for factoring *and* discrete logarithms.
>>Well, logistically it would be a nightmare. Also, it **statistically** detects eavesdropping
A good point:) Also, since you don't know which bits in advance will be detected correctly at the other end, I would imagine that you'd need some pretty heavy error correction if you chose to use that channel to send the message itself, rather than a usefully random one-time-pad.
It's true that one time pads are provably unbreakable, with the slight disadvantage that you need as much high quality random key material as message, and you can only use this material once, or you blow the whole thing. It's also true that if you could securely generate and distribute enough random material fast enough, you could use it as a one-time-pad. And you'd better be sure with whom you're communicating.
Unfortunately, the bandwidth available using current quantum key distribution techniques makes this difficult at present for most realistic applications, so no, current systems do not "generate a one-time pad on the fly". They still generate keys that are used to encrypt the data with traditional symmetric encryption which is then transmitted over a faster, normal communications channel. And why shouldn't they? With a large enough key, you can securely protect your data at far less cost.
It's quite a nice idea to use a quantum system in this way. But if you can securely exchange one-time-pad key material fast enough to exchange your message, why not simply exchange the message itself? The system detects eavesdropping, after all.
Which is the whole point. All the key exchange does is to exchange a key securely with *someone*. So the scheme is only as secure as your tradititional authentication method.
In any case, there are perfectly good ways of securely exchanging keys without Quantum cryptography right now, e.g. Diffie-Hellman. So the question is, why bother with all this stuff to exchange a key? In the absence of a working quantum computer to crack factorisations, the only thing it provides above other key exchange methods is a test to see if anyone is eavesdropping on the key exchange.
While this is an interesting research area that may have applications if a huge quantum computer were built, what possible commercial use can this have now?
The problem with Quantum key exchange is that it's unauthenticated. Since you don't know who's on the other end, you're vulnerable to a man-in-the-middle attach. Someone could be tapping into the line.
So you authenticate using standard public key techniques, making the whole shebang not much more secure than the (non-quantum) authentication mechanism you use. But vastly more expensive.
Yeah... and I've heard the same arguments advanced about why it's so great that xslt itself is also encoded in xml - so you can automatically transform it using more xslt technology. How recursive! How uber-geeky!
I suppose it's one way of getting around limitations in the abilities of xslt itself, at the expense of making what it does even more utterly opaque.
I used to interview for a small company. We were interested in people's technical abilities sure, but also very much in how well they could work in a team.
We used to set a design test which would take about half of the interview. Books and internet access were allowed - this wasn't a memory test. The next half of the interview was all about what would happen if the requirements suddenly changed. We'd work together and explore how we might change the design in different situations.
The worst candidate I ever interviewed could not seem to get it through his head that the whole point of the second half was to work with me on changing the design. He just kept saying "But you didn't tell me that right at the start - that's not how I designed the system" and I kept saying "I know - the whole point of this is to see how you deal with changing requirements working in a team.".
OK - now I'm confused. I did a bit a googling on Spinoza. It seems to me that he's arguing that creation *cannot* be fundamentally seperate to God - indeed that there is a "Unity of Substance".
http://www.philosophypages.com/hy/4h.htm
http://home.earthlink.net/~tneff/stapnd1.htm
Any thoughts?
It seems to me that "faith" is confused with "existence belief" far too much. Faith is not the irrational belief in the existence of a god, a deeper meaning in life, or little blue fairies. It's the *act* of choosing to take a position, even if you're fully aware of the ultimate lack of proof either way.
This may be a subtle distinction, but it's one that I don't think enough people make. Ultimately, most of us have some kind of faith, examined or not, whether it's in the existence, or non-existence, of god, or that tomorrow will be better, or that England will/won't win the next World Cup. Unanswerable questions that we take a position on.
Strangely, religious people seem to confuse this more than non-religious people, possibly because they don't critically examine their thinking enough (the Christian church hasn't historically encouraged that kind of thing, even though JC himself was quite into questioning established thought patterns).
It may also be because the theologies of established religions tend to become quite baroque. Try rationalising the unanswerable and see where you get after several centuries. So maintaining belief in the existence of all that baggage takes increasing amounts of Faith.
Maybe this indicates that religions have a natural lifecycle. What seems like a wonderful, intuitive and liberating idea in the context of one millenia, over time accumulates keepers of the truth, theologians and other people with an irrational desire to package the numinous and mysterious like a box of chocolates.
This may also explain why I know an increasing number of people who profess a belief in God, or at least, a Creator (which seems to me to be a more general word with less historical baggage) but do not, and will not follow the Christian Faith anymore.
Hmmmm.... speaking philosophically, I'm not sure that Spinoza's argument holds up. Disclaimer: I don't know his work, so I'm just going on the argument presented in the parent post.
"Therefore, there is an entity which contains both God and the Universe he created."
Why must God be contained in another entity? That doesn't logically follow from any of the prior statements, or any other absolute necessity I can see. Introducing contradictory statements into the argument only invalidates the argument, not the subject of it!
This may actually be a reflection of the naive (and at the time, perfectly scientific) belief that space and time were some kind of absolute given backdrop that "everything else" just happens in. So you couldn't conceive of an entity without also having somewhere for it to be.
As far as religion goes, I don't even know what I am in terms of belief. The closest I can get is agnostic, but not necessarily in a Christian sense. I can argue it one way, and in the paradoxical style I've come to understand is the hallmark of this universe, when I follow it all the way to its logical end, it no longer makes sense, and I have to switch sides... Repeat...
I don't think the parent was saying *all* bibles ever printed should have those stickers. Given his perfectly reasonable stance, I assume he was simply asking for parity. They have Bibles at school, don't they?
Descartes said the only thing we can be *absolutely* certain of is our own existence as a thinking entity. I think creationists need a big sticker putting on them. I just can't believe they're for real.
Encryption alone isn't enough - it would do nothing to stop replay attacks. You need entity authentication, which gives a guarantee that the other side is actually present.
The system would have to have some kind of challenge-response protocol, or something like that. I can't find anything specific online about what protocols Steam uses.
There are also questions about how user identity is derived. Is it simply given by the CD-Key? Does registering your CD-Key provide you with an ID that's bound to your machine in some way?
At my old school, we had an amazing teacher called Mr. Swinson. He taught woodwork and metalwork to 9 to 12 year olds.
On the electronics front, we built a robot that would follow a white line painted on the ground (by coupling two light sensitive cells to circuits that controlled the opposite motors), and a working (if a bit squealy) electronic organ.
Aside from electronics, he had children working with blow torches and lathes, constructing working steam engines that trundled along the floor from raw materials - pistons, cylinders, the boiler - everything. The only teacher to have to run extra classes after school due to demand, and not one accident worth mentioning in all that time.
He was a superb guy all round, and I've never forgotten how exciting his classes were.
It's impossible to debate the complex privacy issues raised by the various kinds of identity scheme when the Government has so far utterly failed to produce one single good idea for this highly expensive white elephant.
Four questions first:
* What is it for?
* How will it achieve these aims?
* Is it cost effective?
* How will we measure it's success or failure?
If we get some answers to these, we might be able to have an intelligent debate about the scheme, rather than knee-jerk reactions to imagined threats coming from both sides of the "debate".
And frankly, I am suspicious. As another post has pointed out, the Government can't, or won't, answer these basic questions. Would you run any other large scale IT project without answers to those questions?
Nope. The reality is that digital data is far more *accessible* than paper data, not more *persistent*.
Reckon on all your digital data being unreadable (through software obsolescence, mostly) in no more than 50 years time without some form of active intervention. We have paper that's survived for 100's of years easily with no special requirements.
Matt Palmer Digital Preservation Department UK National Archives.
Strangely enough, we at the UK National Archives have been involved with a project to rescue the old BBC Domesday Disk. It's coming along quite nicely, by both writing new software and extracting the old data, and with an emulator. We've even got some original working hardware now.
As another poster in this thread rightly points out, long term digital archiving requires cycles of storage migration. But while this is onerous, it's not the biggest challenge. The biggest challenge is the format that data is written in, and the lack of documentation for systems that have behaviour (dynamic rather than static data). You have to ask the question, who really owns your data - you or the software vendor who encodes it in a proprietary format...? We're seriously looking at open standards for all data formats, or open source formats where standards are not available. We hope that in the future it will become unmarketable for vendors to sell software whose data is unreadable without their software. Infrastructurally, as a society this is too important to be held in the hands of private companies.
Some people believe that emulation can solve these problems, but most people are going down the road of a slow continuous cycle of migration of data to other formats, for both preservation and presentation (which for digital records may involve different formats).
To support this the National Archives have recently set up a free for use file format registry, in which we hope to record all essential details of file formats, and the migration strategies to move between them. The data model is still being refined, and we're looking to develop format migration tools that use the data. It's at http://www.nationalarchives.gov.uk/pronom/
Matt Palmer Digital Preservation Department The UK National Archives
...the truth is that secure coding is a lot more complex than that.
There are common functions which can be insecure if used in particular ways. There are different kinds of buffer overflow attack - e.g stack and heap attacks. Sometimes the API you are correctly using is itself the problem in that context. Sometimes the particular kind of data you're dealing with requires different forms of validation.
So in the real world it's very useful to be able to examine insecure code and the resolution to the problem.
Fission works by splitting up big heavy atoms. Heavy atoms decay naturally, emitting neutrons. If you put a lot of them together, a self-sustaining chain reaction occurs, as a neutron released from one atom splitting smashes into another heavy atom, splitting that one as well, and giving out more neutrons. Heat and radiation is produced. The only way to damp down the reaction once it's started is to absorb some of the neutrons, with things like graphite - these are the control rods.
Fusion is kind of the opposite process. It works by fusing together very light atoms, like hydrogen together, to form elements like helium. When two light atoms fuse together, they also release some energy, the bigger single atom takes less energy to hold together than two individual atoms, so there's some energy left over. It doesn't tend to produce much radiation.
The problem with fusion is that to make two nuclei fuse together, they have to smash together hard. The only way we know for sure how to do this is to make things very, very hot. You don't need "control rods" with nuclear fusion - the problem isn't stopping the reaction once it's started, it's keeping it hot enough to get going in the first place, and then to keep it going.
One problem with fusion is actually that as fusion occurs, the heavier atoms produced actually "pollute" the mixture, cooling it down and stopping the reaction, so you have to have some way of removing the waste products. It's normally held together with big magnetic fields, because if the hot plasma touched the sides, not only would the sides melt, the reaction would stop because it would cool down. This tends to make nuclear fusion a much safer option, as you don't get runaway reactions, and there's less radiation anyway.
Cold fusion would be incredibly useful if real, as not having to deal with things at millions of degrees C would be rather easier...
Security is an optional extra in most software houses. Features and release dates drive most application development. And even if "security" is added to the product, it's usually done as an afterthought, to place a tick in a marketing box.
What's better: a secure system where even a badly written application can't compromise it, or a wide open system which relies on each application being secure? Do the risk analysis.
If we make the security of our systems dependant on every application being coded securely, we don't have security.
I was just in a meeting with a very well known, and large, media organisation that has pioneered the use of technology in many areas.
The BSA and FAST wanted to make an example of them, so they warned them to get their house in order. They duly instigated an expensive program to manage their software licensing. Along the way, they discovered that it was impossible to deploy their software remotely to their users, as they had been doing, entirely because of the difficulties in managing the licenses, and that some licenses wouldn't permit it at all - and they have a lot of software.
As a result, they now have a workforce which needs to be pretty mobile, who can't always have the software they need where they need it, even though the technology is perfectly capable of delivering. Talk about driving down ROI and driving up TCO.
But every cloud has a silver lining. As a result of managing their licenses better, they discovered that across the organisation as a whole, they had multiple licenses for the same software, and they also discovered that many licenses were no longer needed, so they could redeploy the software to the areas where it was needed. As a result, they have not had to buy *any more* software from the companies who made the original complaints for the last 6 months. In one month, they saved £200,000 alone.
Let's see how long big software companies keep supporting the BSA and FAST once they realise that their efforts are actually causing them to sell *less* software than before!
Slashdot Mirror
The whole point of HTML is that it's firewall friendlier? The whole point of firewalls is to control what kind of traffic you let through and what applications you expose. Tunnelling everything through HTTP just means you need an even cleverer firewall that can inspect each packet and decode the application layer stuff in it before passing it through. And HTTPS makes the problem even worse. Sigh.
The real costs in software development are not normally blue-sky research. In most cases the costs are those of development.
/.) examples of software in which really fundamental research needed the protection it would afford. I'm hard pressed to think of many things, except possibly in the fields of data compression and encryption where the value really is in the algorithm and not the implementation, (which is often trivial to implement once you know how).
To compete with a product, a company would have to incur those development costs themselves, all the while catching up with the current state of play while the original company likewise kept advancing. And then to convince the marketplace to go with them rather than the established market leader. It's doubtful they could sell it much cheaper than the original; if they could - well, they have better processes, and that's how things improve in a competitive environment.
If software really needs patents, I'd be interested to hear from the pro-patent lot (assuming there are any on
Yes, Diffie-Hellman is based on discrete logs. I'm not an expert on quantum algorithms, but I believe that Shor had quantum algorithms for factoring *and* discrete logarithms.
Here's a link to some papers on citeseer:
http://citeseer.ist.psu.edu/58960.html
>>Well, logistically it would be a nightmare. Also, it **statistically** detects eavesdropping
:) Also, since you don't know which bits in advance will be detected correctly at the other end, I would imagine that you'd need some pretty heavy error correction if you chose to use that channel to send the message itself, rather than a usefully random one-time-pad.
A good point
It's true that one time pads are provably unbreakable, with the slight disadvantage that you need as much high quality random key material as message, and you can only use this material once, or you blow the whole thing. It's also true that if you could securely generate and distribute enough random material fast enough, you could use it as a one-time-pad. And you'd better be sure with whom you're communicating.
Unfortunately, the bandwidth available using current quantum key distribution techniques makes this difficult at present for most realistic applications, so no, current systems do not "generate a one-time pad on the fly". They still generate keys that are used to encrypt the data with traditional symmetric encryption which is then transmitted over a faster, normal communications channel. And why shouldn't they? With a large enough key, you can securely protect your data at far less cost.
It's quite a nice idea to use a quantum system in this way. But if you can securely exchange one-time-pad key material fast enough to exchange your message, why not simply exchange the message itself? The system detects eavesdropping, after all.
Which is the whole point. All the key exchange does is to exchange a key securely with *someone*. So the scheme is only as secure as your tradititional authentication method.
In any case, there are perfectly good ways of securely exchanging keys without Quantum cryptography right now, e.g. Diffie-Hellman. So the question is, why bother with all this stuff to exchange a key? In the absence of a working quantum computer to crack factorisations, the only thing it provides above other key exchange methods is a test to see if anyone is eavesdropping on the key exchange.
While this is an interesting research area that may have applications if a huge quantum computer were built, what possible commercial use can this have now?
The problem with Quantum key exchange is that it's unauthenticated. Since you don't know who's on the other end, you're vulnerable to a man-in-the-middle attach. Someone could be tapping into the line.
So you authenticate using standard public key techniques, making the whole shebang not much more secure than the (non-quantum) authentication mechanism you use. But vastly more expensive.
Yeah... and I've heard the same arguments advanced about why it's so great that xslt itself is also encoded in xml - so you can automatically transform it using more xslt technology. How recursive! How uber-geeky!
I suppose it's one way of getting around limitations in the abilities of xslt itself, at the expense of making what it does even more utterly opaque.
I used to interview for a small company. We were interested in people's technical abilities sure, but also very much in how well they could work in a team.
We used to set a design test which would take about half of the interview. Books and internet access were allowed - this wasn't a memory test. The next half of the interview was all about what would happen if the requirements suddenly changed. We'd work together and explore how we might change the design in different situations.
The worst candidate I ever interviewed could not seem to get it through his head that the whole point of the second half was to work with me on changing the design. He just kept saying "But you didn't tell me that right at the start - that's not how I designed the system" and I kept saying "I know - the whole point of this is to see how you deal with changing requirements working in a team.".
He didn't get the job...
OK - now I'm confused. I did a bit a googling on Spinoza. It seems to me that he's arguing that creation *cannot* be fundamentally seperate to God - indeed that there is a "Unity of Substance". http://www.philosophypages.com/hy/4h.htm http://home.earthlink.net/~tneff/stapnd1.htm Any thoughts?
It seems to me that "faith" is confused with "existence belief" far too much. Faith is not the irrational belief in the existence of a god, a deeper meaning in life, or little blue fairies. It's the *act* of choosing to take a position, even if you're fully aware of the ultimate lack of proof either way. This may be a subtle distinction, but it's one that I don't think enough people make. Ultimately, most of us have some kind of faith, examined or not, whether it's in the existence, or non-existence, of god, or that tomorrow will be better, or that England will/won't win the next World Cup. Unanswerable questions that we take a position on. Strangely, religious people seem to confuse this more than non-religious people, possibly because they don't critically examine their thinking enough (the Christian church hasn't historically encouraged that kind of thing, even though JC himself was quite into questioning established thought patterns). It may also be because the theologies of established religions tend to become quite baroque. Try rationalising the unanswerable and see where you get after several centuries. So maintaining belief in the existence of all that baggage takes increasing amounts of Faith. Maybe this indicates that religions have a natural lifecycle. What seems like a wonderful, intuitive and liberating idea in the context of one millenia, over time accumulates keepers of the truth, theologians and other people with an irrational desire to package the numinous and mysterious like a box of chocolates. This may also explain why I know an increasing number of people who profess a belief in God, or at least, a Creator (which seems to me to be a more general word with less historical baggage) but do not, and will not follow the Christian Faith anymore.
Hmmmm.... speaking philosophically, I'm not sure that Spinoza's argument holds up. Disclaimer: I don't know his work, so I'm just going on the argument presented in the parent post.
"Therefore, there is an entity which contains both God and the Universe he created."
Why must God be contained in another entity? That doesn't logically follow from any of the prior statements, or any other absolute necessity I can see. Introducing contradictory statements into the argument only invalidates the argument, not the subject of it!
This may actually be a reflection of the naive (and at the time, perfectly scientific) belief that space and time were some kind of absolute given backdrop that "everything else" just happens in. So you couldn't conceive of an entity without also having somewhere for it to be.
As far as religion goes, I don't even know what I am in terms of belief. The closest I can get is agnostic, but not necessarily in a Christian sense. I can argue it one way, and in the paradoxical style I've come to understand is the hallmark of this universe, when I follow it all the way to its logical end, it no longer makes sense, and I have to switch sides... Repeat...
I don't think the parent was saying *all* bibles ever printed should have those stickers. Given his perfectly reasonable stance, I assume he was simply asking for parity. They have Bibles at school, don't they?
Descartes said the only thing we can be *absolutely* certain of is our own existence as a thinking entity. I think creationists need a big sticker putting on them. I just can't believe they're for real.
Encryption alone isn't enough - it would do nothing to stop replay attacks. You need entity authentication, which gives a guarantee that the other side is actually present.
The system would have to have some kind of challenge-response protocol, or something like that. I can't find anything specific online about what protocols Steam uses.
There are also questions about how user identity is derived. Is it simply given by the CD-Key? Does registering your CD-Key provide you with an ID that's bound to your machine in some way?
At my old school, we had an amazing teacher called Mr. Swinson. He taught woodwork and metalwork to 9 to 12 year olds.
On the electronics front, we built a robot that would follow a white line painted on the ground (by coupling two light sensitive cells to circuits that controlled the opposite motors), and a working (if a bit squealy) electronic organ.
Aside from electronics, he had children working with blow torches and lathes, constructing working steam engines that trundled along the floor from raw materials - pistons, cylinders, the boiler - everything. The only teacher to have to run extra classes after school due to demand, and not one accident worth mentioning in all that time.
He was a superb guy all round, and I've never forgotten how exciting his classes were.
Nice idea, except the scheme will bind biometric identifiers to your card, preventing multiple enrollments.
And do you really want you entitlement to health benefits, unemployment benefits and pensions to be bound to a fake id bound to your biometrics?
Change of fingerprints and iris, anyone?
It's impossible to debate the complex privacy issues raised by the various kinds of identity scheme when the Government has so far utterly failed to produce one single good idea for this highly expensive white elephant. Four questions first: * What is it for? * How will it achieve these aims? * Is it cost effective? * How will we measure it's success or failure? If we get some answers to these, we might be able to have an intelligent debate about the scheme, rather than knee-jerk reactions to imagined threats coming from both sides of the "debate". And frankly, I am suspicious. As another post has pointed out, the Government can't, or won't, answer these basic questions. Would you run any other large scale IT project without answers to those questions?
Nope. The reality is that digital data is far more *accessible* than paper data, not more *persistent*.
Reckon on all your digital data being unreadable (through software obsolescence, mostly) in no more than 50 years time without some form of active intervention. We have paper that's survived for 100's of years easily with no special requirements.
Matt Palmer
Digital Preservation Department
UK National Archives.
Strangely enough, we at the UK National Archives have been involved with a project to rescue the old BBC Domesday Disk. It's coming along quite nicely, by both writing new software and extracting the old data, and with an emulator. We've even got some original working hardware now.
As another poster in this thread rightly points out, long term digital archiving requires cycles of storage migration. But while this is onerous, it's not the biggest challenge. The biggest challenge is the format that data is written in, and the lack of documentation for systems that have behaviour (dynamic rather than static data). You have to ask the question, who really owns your data - you or the software vendor who encodes it in a proprietary format...? We're seriously looking at open standards for all data formats, or open source formats where standards are not available. We hope that in the future it will become unmarketable for vendors to sell software whose data is unreadable without their software. Infrastructurally, as a society this is too important to be held in the hands of private companies.
Some people believe that emulation can solve these problems, but most people are going down the road of a slow continuous cycle of migration of data to other formats, for both preservation and presentation (which for digital records may involve different formats).
To support this the National Archives have recently set up a free for use file format registry, in which we hope to record all essential details of file formats, and the migration strategies to move between them. The data model is still being refined, and we're looking to develop format migration tools that use the data. It's at http://www.nationalarchives.gov.uk/pronom/
Matt Palmer
Digital Preservation Department
The UK National Archives
...the truth is that secure coding is a lot more complex than that.
There are common functions which can be insecure if used in particular ways. There are different kinds of buffer overflow attack - e.g stack and heap attacks. Sometimes the API you are correctly using is itself the problem in that context. Sometimes the particular kind of data you're dealing with requires different forms of validation.
So in the real world it's very useful to be able to examine insecure code and the resolution to the problem.
Err... so you can learn how to protect code against these kinds of threat? Because you're interested in secure coding techniques?
Well - patents *are* totally different to copyright, and you're correct to point out that there is not really such a thing as "intellectual property".
Have a look at Lawrence Lessig's fine book "Free Culture" - a fantastic book, and available free (as in beer and in speech) online at:
http://www.free-culture.cc/freeculture.pdf
IANANP either, but here's what I know.
Fission works by splitting up big heavy atoms. Heavy atoms decay naturally, emitting neutrons. If you put a lot of them together, a self-sustaining chain reaction occurs, as a neutron released from one atom splitting smashes into another heavy atom, splitting that one as well, and giving out more neutrons. Heat and radiation is produced. The only way to damp down the reaction once it's started is to absorb some of the neutrons, with things like graphite - these are the control rods.
Fusion is kind of the opposite process. It works by fusing together very light atoms, like hydrogen together, to form elements like helium. When two light atoms fuse together, they also release some energy, the bigger single atom takes less energy to hold together than two individual atoms, so there's some energy left over. It doesn't tend to produce much radiation.
The problem with fusion is that to make two nuclei fuse together, they have to smash together hard. The only way we know for sure how to do this is to make things very, very hot. You don't need "control rods" with nuclear fusion - the problem isn't stopping the reaction once it's started, it's keeping it hot enough to get going in the first place, and then to keep it going.
One problem with fusion is actually that as fusion occurs, the heavier atoms produced actually "pollute" the mixture, cooling it down and stopping the reaction, so you have to have some way of removing the waste products. It's normally held together with big magnetic fields, because if the hot plasma touched the sides, not only would the sides melt, the reaction would stop because it would cool down. This tends to make nuclear fusion a much safer option, as you don't get runaway reactions, and there's less radiation anyway.
Cold fusion would be incredibly useful if real, as not having to deal with things at millions of degrees C would be rather easier...
Security is an optional extra in most software houses. Features and release dates drive most application development. And even if "security" is added to the product, it's usually done as an afterthought, to place a tick in a marketing box.
What's better: a secure system where even a badly written application can't compromise it, or a wide open system which relies on each application being secure? Do the risk analysis.
If we make the security of our systems dependant on every application being coded securely, we don't have security.
I was just in a meeting with a very well known, and large, media organisation that has pioneered the use of technology in many areas.
The BSA and FAST wanted to make an example of them, so they warned them to get their house in order. They duly instigated an expensive program to manage their software licensing. Along the way, they discovered that it was impossible to deploy their software remotely to their users, as they had been doing, entirely because of the difficulties in managing the licenses, and that some licenses wouldn't permit it at all - and they have a lot of software.
As a result, they now have a workforce which needs to be pretty mobile, who can't always have the software they need where they need it, even though the technology is perfectly capable of delivering. Talk about driving down ROI and driving up TCO.
But every cloud has a silver lining. As a result of managing their licenses better, they discovered that across the organisation as a whole, they had multiple licenses for the same software, and they also discovered that many licenses were no longer needed, so they could redeploy the software to the areas where it was needed. As a result, they have not had to buy *any more* software from the companies who made the original complaints for the last 6 months. In one month, they saved £200,000 alone.
Let's see how long big software companies keep supporting the BSA and FAST once they realise that their efforts are actually causing them to sell *less* software than before!