' That's a bogus argument. Diversifying for the sense of being diverse is just a rephrasing of "Security Through Obscurity".'
You misunderstand the problem of "security through obscurity". The phrase "security through obscurity" does not mean to say that obscurity is useless - in fact, it is a very important part of computer defence. What it means is that obscurity should not be confused with security. They are orthogonal. If I have an obscure system on the other side of the firewall, it will take a hacker longer to figure his way around, thus giving me extra time to detect him. This shouldn't be done to _replace_ security, but is a definite complement to security.
" Thinking of it, it would be nice if compilers could generate (randomly) different - but working - binary code from the same sources."
Actually, you can through compiler switches.
However, this doesn't help any. It may mean that someone may need to write multiple versions of the same exploit, but the exploit will be there in all versions.
Even in the case you mention - cracking a machine - you still have only 1 machine cracked versus the whole bunch. At least afterwords you would have at least 1 known-good copy of the data.
Diversifying for the sake of diversifying is still useful. If person A finds a flaw in one of the two systems, the rest are still functioning. This requires an attacker to have exploits for all systems, not just one. The diversity itself is a barrier.
"The reason for this is that RISC processors are bogged down by doing the optimizations at runtime that Itanium doesn't have to care about."
Like what?
An HP research group actually showed that runtime optimizations can be dramatically more efficient than compile-time ones, since they have the data of how the application is actually being used. HP actually found that they got a performance boost by INTERPRETTING MACHINE CODE than just running it on the same hardware raw. Why? It could be altered to match the runtime characteristics, code that was often called together could be moved onto the same page of memory, thus increasing cache hits, etc. Note that all of the machine code was JITed back into machine code, but it was faster because it was based on real-world usage patterns.
Yes, compile-time optimizations are great, but that only encodes the static behavior. The dynamic behavior of an application can only be assessed at runtime. Some compilers can take dynamic performance data and recompile the original code to take advantage of it, but they are rare and don't have all of the features the HP research group showed.
Of course, I believe a lot of this is still in the research stage, but they have actually shown this to be the case.
What I'm saying is that the number of boundary conditions for _any_ real-life system are too many to be fully enumerated. Programmers often stop specifying at the logical level, but physical events (such as heat, temperature, radio interference, gravity, etc) actually affect their programs, too. These _usually_ do not come into play on a normal basis, but most people are COMPLETELY ignorant of them, and fail to program accordingly. For example, my grandmother has a WebTV that doesn't work properly if her new wireless phone is plugged in on the same side of the house.
Someone doing circuit layout or design for a cockpit control widget does not need to worry about reentry dynamics and airflow.
****
They may - or else they may design something that weighs too much or would require a cockpit that, although handles well in normal aircraft, does not take into account reentry dynamics and airflow.
The centralized idea will actually make the lists that people sell _MORE_ valuable, not less, since they can be assured that anyone who has signed up for the global opt-out will be ignored. This gives more consumer confidence in buying lists, and thus would raise, not lower, their prices.
Instead of trapping names, a nonprofit company could be set up which you had to send all broadcast emails through. This company would be the only one with the list, and simply use it to filter. All you had to do is make sure your broadcast list is pointed at one of these mailservers.
This would also make it easier for the people writing anti-spam software, to always allow email that originates from these mail servers.
Obviously, there would have to be a usage fee, but I don't see that as a problem.
Being part of a company that does email marketing and email marketing on behalf of other companies, I think the opt-out list idea is a great idea for the following reasons:
* If you _don't_ want email, I certainly don't want to send you any
* Just because you haven't specifically asked for the mailing in question, doesn't mean that you wouldn't be interested
I'm not talking about giant lists. The most we send to are about 5,000 people. Most of them are customers lists, but some of them are lists from trade shows we've attended, etc. I don't have any moral problem sending to such targetted lists, but if someone specifically asks not to be sent commercial email, I don't see why anyone would even _want_ to waste their time doing so.
Re:You probably won't like this...
on
.NET or CORBA?
·
· Score: 4, Insightful
Problems with SOAP:
1) It is NOT NOT NOT NOT NOT NOT NOT Object-oriented. In fact, they've stopped calling it the "Simple Object Access Protocol", and have just stuck with SOAP because it has NOTHING to do with object-oriented programming. You CANNOT pass references to remote SOAP objects as parameters and have it work seamlessly with the language.
2) It is not nearly as compatible as CORBA. If you look at all of the current implementations, many of them are almost mutually exclusive. CORBA used to be the same way - a very long time ago. However, these days it is pretty rare that IIOP isn't properly supported between ORBs. So, for ORB portability CORBA is the way to go.
3) CORBA is a complete architecture. SOAP is only the message-passing component, and a very poor one at that.
4) SOAP messages are about 4x the size of CORBA messages, and take a whole lot longer to parse. So if you currently are using CORBA and are filling up a T1 line, moving to SOAP will mean that you need to buy 3 more.
5) (a continuation of 3) CORBA has _language_ support for features such as transactions and security, so you don't have to implement bloody or vendor-specific hacks to implement such things. The CORBA PortableInterceptor interface is a wonderful, wonderful thing. The ability to seamlessly pass context information around without additional coding is quite amazing.
In fact, the SOAP standard itself starts off by listing things where the designers were too bothered to be "simple" to actually implement a complete architecture. From the SOAP 1.1 standard:
==clip==
A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include
These are standard features of CORBA. CORBA's Portable Object Adapter is just an amazing piece of technology.
Plus, if you've ever tried to write WSDL vs. a CORBA interface, you'll find that interfaces are much easier.
The only place where SOAP surpasses CORBA is if you are doing document-passing functions rather than parameter-passing functions. For example, if you were sending in a complete invoice (a lot of depth and loosely structured), you might use SOAP. However, for operations where the parameters are fairly structured, CORBA is clearly the winner.
SOAP is an interesting technology for document exchange, but it's role in enterprise computing is highly, highly, highly overrated, and CORBA is a wonderful jewel that so many people overlook out of fear. But really, it's not that complicated.
Don't speak of NASA as if it were a single person. Just because NASA knows two things doesn't mean that the person who knew that O-rings stop functioning below 32 degrees is the same person who knows that it was 32 degrees and that is the same person who knows the extent of the problem for O-rings at below-normal temperature.
There's no reason to think that the western standard of living has to go down for others to come up. Technology has exponentially increased the production capacity of the planet, and there are many areas that haven't even been explored. To think we are reaching capacity is extremely naive.
Most applications are medium-sized, and don't require more than the initial developer or two for anything until they get past the first release or two.
I've found that you can build systems much faster and cleaner when the initial development is done by a single person - it gives a clear, consistent set of design patterns that future programmers can use to extend the base system.
Especially when people want FTP to "just work". So many people complain when they have to check the "passive mode" box on their FTP client, saying it isn't user friendly.
I don't remember where I read this, but I think I remember seeing that the programming team for Deep Blue had the option of not doing what Deep Blue asked. This even happened in one of the games Deep Blue won in. Deep Blue made a blunder early on, but the programmer made a more sensible move instead.
Anyway, it seems that computer+human does better than human, not necessary computer by itself.
Who decides this? I agree we need to give small businesses tax cuts - because they are part of everyone. I myself work for a business of 15 people (and we are growing at a breakneck rate). I don't see why you say a company of X size shouldn't get tax cuts, though. The tax burden should be lightened, period. Creating more and more IRS rules about who gets what and under what conditions is counter-productive. Let's just give everyone a break.
Are there any others besides KDB? Are any of them free?
Of course, speed is only one issue in a database. in fact, just using a relational database makes a speed slowdown, but it is so that you can have a malleable, sensible environment.
Slashdot Mirror
You forgot the most important step in any high-tech venture:
5. ??????
6. Profit!
' That's a bogus argument. Diversifying for the sense of being diverse is just a rephrasing of "Security Through Obscurity".'
You misunderstand the problem of "security through obscurity". The phrase "security through obscurity" does not mean to say that obscurity is useless - in fact, it is a very important part of computer defence. What it means is that obscurity should not be confused with security. They are orthogonal. If I have an obscure system on the other side of the firewall, it will take a hacker longer to figure his way around, thus giving me extra time to detect him. This shouldn't be done to _replace_ security, but is a definite complement to security.
" Thinking of it, it would be nice if compilers could generate (randomly) different - but working - binary code from the same sources."
Actually, you can through compiler switches.
However, this doesn't help any. It may mean that someone may need to write multiple versions of the same exploit, but the exploit will be there in all versions.
Even in the case you mention - cracking a machine - you still have only 1 machine cracked versus the whole bunch. At least afterwords you would have at least 1 known-good copy of the data.
Diversifying for the sake of diversifying is still useful. If person A finds a flaw in one of the two systems, the rest are still functioning. This requires an attacker to have exploits for all systems, not just one. The diversity itself is a barrier.
"The reason for this is that RISC processors are bogged down by doing the optimizations at runtime that Itanium doesn't have to care about."
Like what?
An HP research group actually showed that runtime optimizations can be dramatically more efficient than compile-time ones, since they have the data of how the application is actually being used. HP actually found that they got a performance boost by INTERPRETTING MACHINE CODE than just running it on the same hardware raw. Why? It could be altered to match the runtime characteristics, code that was often called together could be moved onto the same page of memory, thus increasing cache hits, etc. Note that all of the machine code was JITed back into machine code, but it was faster because it was based on real-world usage patterns.
Yes, compile-time optimizations are great, but that only encodes the static behavior. The dynamic behavior of an application can only be assessed at runtime. Some compilers can take dynamic performance data and recompile the original code to take advantage of it, but they are rare and don't have all of the features the HP research group showed.
Of course, I believe a lot of this is still in the research stage, but they have actually shown this to be the case.
Don't worry, they're probably just using CVS like the rest of us.
You can relicense BSD work. That's what the license says. The only restriction is that the new license must retain the original copyright.
The most recent WS_FTP pro supports sftp as well. It's becoming more and more common.
What I'm saying is that the number of boundary conditions for _any_ real-life system are too many to be fully enumerated. Programmers often stop specifying at the logical level, but physical events (such as heat, temperature, radio interference, gravity, etc) actually affect their programs, too. These _usually_ do not come into play on a normal basis, but most people are COMPLETELY ignorant of them, and fail to program accordingly. For example, my grandmother has a WebTV that doesn't work properly if her new wireless phone is plugged in on the same side of the house.
What you say is true, however, there are too many issues to be able to specify.
Someone doing circuit layout or design for a cockpit control widget does not need to worry about reentry dynamics and airflow.
****
They may - or else they may design something that weighs too much or would require a cockpit that, although handles well in normal aircraft, does not take into account reentry dynamics and airflow.
The problem is that although it is good to try to create and code to black boxes, there is no such thing as a purely black box.
For example, processors are often considered black boxes, but as the CPUBurn program shows, they don't entirely work that way.
How come no Microsoft languages support closures?
I've found that to be one of the most useful programming features ever.
The centralized idea will actually make the lists that people sell _MORE_ valuable, not less, since they can be assured that anyone who has signed up for the global opt-out will be ignored. This gives more consumer confidence in buying lists, and thus would raise, not lower, their prices.
Instead of trapping names, a nonprofit company could be set up which you had to send all broadcast emails through. This company would be the only one with the list, and simply use it to filter. All you had to do is make sure your broadcast list is pointed at one of these mailservers.
This would also make it easier for the people writing anti-spam software, to always allow email that originates from these mail servers.
Obviously, there would have to be a usage fee, but I don't see that as a problem.
Being part of a company that does email marketing and email marketing on behalf of other companies, I think the opt-out list idea is a great idea for the following reasons:
* If you _don't_ want email, I certainly don't want to send you any
* Just because you haven't specifically asked for the mailing in question, doesn't mean that you wouldn't be interested
I'm not talking about giant lists. The most we send to are about 5,000 people. Most of them are customers lists, but some of them are lists from trade shows we've attended, etc. I don't have any moral problem sending to such targetted lists, but if someone specifically asks not to be sent commercial email, I don't see why anyone would even _want_ to waste their time doing so.
Problems with SOAP:
1) It is NOT NOT NOT NOT NOT NOT NOT Object-oriented. In fact, they've stopped calling it the "Simple Object Access Protocol", and have just stuck with SOAP because it has NOTHING to do with object-oriented programming. You CANNOT pass references to remote SOAP objects as parameters and have it work seamlessly with the language.
2) It is not nearly as compatible as CORBA. If you look at all of the current implementations, many of them are almost mutually exclusive. CORBA used to be the same way - a very long time ago. However, these days it is pretty rare that IIOP isn't properly supported between ORBs. So, for ORB portability CORBA is the way to go.
3) CORBA is a complete architecture. SOAP is only the message-passing component, and a very poor one at that.
4) SOAP messages are about 4x the size of CORBA messages, and take a whole lot longer to parse. So if you currently are using CORBA and are filling up a T1 line, moving to SOAP will mean that you need to buy 3 more.
5) (a continuation of 3) CORBA has _language_ support for features such as transactions and security, so you don't have to implement bloody or vendor-specific hacks to implement such things. The CORBA PortableInterceptor interface is a wonderful, wonderful thing. The ability to seamlessly pass context information around without additional coding is quite amazing.
In fact, the SOAP standard itself starts off by listing things where the designers were too bothered to be "simple" to actually implement a complete architecture. From the SOAP 1.1 standard:
==clip==
A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include
* Distributed garbage collection
* Boxcarring or batching of messages
* Objects-by-reference (which requires distributed garbage collection)
* Activation (which requires objects-by-reference)
==clip==
These are standard features of CORBA. CORBA's Portable Object Adapter is just an amazing piece of technology.
Plus, if you've ever tried to write WSDL vs. a CORBA interface, you'll find that interfaces are much easier.
The only place where SOAP surpasses CORBA is if you are doing document-passing functions rather than parameter-passing functions. For example, if you were sending in a complete invoice (a lot of depth and loosely structured), you might use SOAP. However, for operations where the parameters are fairly structured, CORBA is clearly the winner.
SOAP is an interesting technology for document exchange, but it's role in enterprise computing is highly, highly, highly overrated, and CORBA is a wonderful jewel that so many people overlook out of fear. But really, it's not that complicated.
Actually, reading the book made me wish for (defmacro)
Don't speak of NASA as if it were a single person. Just because NASA knows two things doesn't mean that the person who knew that O-rings stop functioning below 32 degrees is the same person who knows that it was 32 degrees and that is the same person who knows the extent of the problem for O-rings at below-normal temperature.
There's no reason to think that the western standard of living has to go down for others to come up. Technology has exponentially increased the production capacity of the planet, and there are many areas that haven't even been explored. To think we are reaching capacity is extremely naive.
Don't insult McDonald's Certified Food Specialists in that way.
Most applications are medium-sized, and don't require more than the initial developer or two for anything until they get past the first release or two.
I've found that you can build systems much faster and cleaner when the initial development is done by a single person - it gives a clear, consistent set of design patterns that future programmers can use to extend the base system.
Especially when people want FTP to "just work". So many people complain when they have to check the "passive mode" box on their FTP client, saying it isn't user friendly.
I don't remember where I read this, but I think I remember seeing that the programming team for Deep Blue had the option of not doing what Deep Blue asked. This even happened in one of the games Deep Blue won in. Deep Blue made a blunder early on, but the programmer made a more sensible move instead.
Anyway, it seems that computer+human does better than human, not necessary computer by itself.
Who decides this? I agree we need to give small businesses tax cuts - because they are part of everyone. I myself work for a business of 15 people (and we are growing at a breakneck rate). I don't see why you say a company of X size shouldn't get tax cuts, though. The tax burden should be lightened, period. Creating more and more IRS rules about who gets what and under what conditions is counter-productive. Let's just give everyone a break.
Are there any others besides KDB? Are any of them free?
Of course, speed is only one issue in a database. in fact, just using a relational database makes a speed slowdown, but it is so that you can have a malleable, sensible environment.