Outlook's numerous viruses are not caused by the program being written in C or C++. They are caused by Outlook's support for active content. The problem would still exist if Outlook were re-written in Java. I wonder if nobody in Joy's circle dares to correct him on this, or if he's been corrected and just didn't hear.
It only takes a few lines of code in Java to create a 'sandbox' and restrict any code you want to run in that sandbox. If MS had used Java they could have put their VBScript interpreter in side that sandbox. Only 6 or 7 lines of java code could have fixed all their problems.
It's not a memory leak if you're still "Using" all of the data, meaning that there is a valid reference to it. In C++ you can have allocated memory that is not referenced by any process, and thus cannot ever be deleted. Such a situation can't happen in java.
A referencing B which references A will defeat a Java's garbage collection.
No, it will not. Sun's garbage collection is not a reference counting system. It works by looking at what's connected to each Thread object. Typically a thread will have a instance of the Runnable interface, which is your class with all the member variables, vectors, etc which are all connected to their children, etc. The garbage collector does a search of that graph, and marks each node. If a node isn't marked in the end, it's deleted. if any node is not reachable by running code, it will be deleted no matter how many other zombie nodes also are connected to it. Your system would work in Python (but not the Java implementation of python), Visual Basic 6.0 or less and Perl (iirc) but not Java.
If you don't belive, write the java program yourself. Hell, here's an example.
class a{
b myb;
a(){
myb = new b(this);
}
}
class b{
a mya;
b(a inputA){
mya = inputA;
byte[] randomcrap = new byte[1024];//so we alocate a lot of ram.
}
}
class CircularTest{
public static void main(String args[]){
int i = 0;
while(true){
a loop = new a();
i++;
if(i%100 == 0){
System.out.print(" " + i);
System.gc(); }
}
}
}
Put that in a file named CircularTest.java, then type "javac CircularTest.java" then "java CircularTest", watch your memory usage not increase without bound.
That's fine if you're writing your little web application, but I'm not convinced it'll perform well when the day comes to render 3D in real-time, or implement a codec.
Why not? Array access is as fast as pointer arithmetic. Sure, those things are bounds checked in java making them a little slower, but linked lists for things like scene graphs and the like are just as fast. If you're using GL for 3d rendering, it should be plenty fast.
My last statement is this: C++ can be *as* safe as Java if say a programmer consistently uses STL. AS SAFE.
That's just not true. In java, I can take an piece of code and in a few lines of code Lock it down and prevent it from accessing the file system, with per-file granularity. I can prevent it from accessing the network, the GUI system or the printer, or anything else I might want to protect (all I have to do is add more permission types). There is absolutely no way to do this in C++. Once code is loaded into your memory space, it can do whatever it wants.
If outlook had been written in java, The VBscript and other 'high level' vulnerabilities that plagued it could have been avoided simply by locking the script interpreter into it's own little 'sandbox' where it couldn't have done any harm. Sure, people at M$ could have made their own sandbox for the interpreter, but obviously they weren't able to. The STL has nothing like this.
OO languages simply aren't suitable for all tasks, neither is C.
I seriously doubt there is a situation where C++ would work and C wouldn't. Sure, there are trivial situations where you wouldn't need more then one object, but C++ works anywhere C would.
No, but you could easily write an e-mail client in Java that interpreted scripts in the body or header fields of an incoming mail by default, and allowed those scripts to do things they shouldn't.
True, but with java you can prevent those mail scripts from doing anything they shouldn't do with about 5 or 6 lines of code (simply load the script interpreter into a ProtectionDomain without any rights to the filesystem, and call AccessControler.doPrivilaged() with it)
Exceptions in java are not "invisible" In fact, you have to check for declared thrown exceptions (but not 'runtime' exceptions). In the API declared thrown exceptions are caused by external problems (like a missing file, closed socket, etc) while Runtime exceptions are usually caused by programmer error (like null pointers), and can be avoided by poor programming.
If your python app is choaking on invalid input, it's because you can't program for shit, not because exceptions suck. If it was a C app, you'd simply segfault or something equally ridiculous. And you'd never know why. At least with the stack trace you can quickly pinpoint your problem and deal with it.
The human brain is definitely not faster at calculating vectors, or doing any kind of math, then a computer. Eventually, you might build neural pathways that do some of the work for you unconsciously, but it would still be an approximation.
If you know the current vector, and you know the vector you need, all you have to do is subtract. If you need to tell the server to give you some amount of torque to the gun, you can do that easily using classical physics. The operation won't take more then a few hundred CPU cycles.
I only said I wondered if he could be sued if he released the plans.
Well, of course he he didn't belive it
on
Build Your Own Segway
·
· Score: 2, Insightful
It's obviously not true. A bicycle is kept from tilting sideways by momentum, but it doesn't flip over because it is touching the ground in front or in back, far away from the center of gravity.
The amount of torque you would need to get the center of gravity on the other side of one of the wheels is huge, since there is a small angle between the center of gravity, the center of the wheels, and the direction you're going.
On the Segway, there is a 90 degree angle between those vectors, and you would need no force to 'unbalance' the segway. The reason the segway stays up is because the software controls the wheels and continually moves the center of gravity so that it stays balanced.
I'm more impressed with the arrogance of Camen, suggesting that entire cities are going to be redesigned because of his yuppie toy, than I am impressed with his courage.
Who's Camen? It was Steve Jobs who thought cities would be designed (not redesigned) for this thing.
All you'd have to do is connect the wheels to 'spires' coming out of the side of the vehicle, rather then to the center of the vehicle. Sort of like
"|\_/|" rather then "|-|" (we'll see if slashdot lets this past the lameness filter..
It would make the thing rather funky looking though, and most of the stability comes from the software, so you don't really need big wheels unless you want to go over big bumps.
I'm sure this guy is violating a couple patents:P. Hmm... Can you be sued for patent violation for non-commercial use? I wonder if he could be sued for releasing plans?
For example, how about getting RMX (Reverse MX lookups) working. A lot RBLs are error prone. A distributed RBL would either not really be distributed (i.e. a central 'committee' that decides who's on the list and lots of mirrors), or a disaster (i.e. anyone on the net can block people). I'm not saying it couldn't be done, just that it would take a Herculean effort to prop up a technology that a lot of people think causes more harm then good.
The ideal (in my mind) anti-Spam 'tool chain' would be RMX and Bayesian filtering along with per-user white listing for messages that are flagged by those systems. A per-domain blacklist of "sites vouch for Spam via RMX" could be created and done on a somewhat distributed system, rather then an IP based system.
Anyway, here's how I would design a distributed blacklist type system. First of all, it would be based on RMX rather then IP space. That way people who are forced to share IP space with spammers don't get screwed. Users of the system could flag mail as 'legitimate' or they could flag it as 'Spam' legit email is sent in only as a counter, and actual Spam is forwarded to a central system. Unlike Kazza or whatever, we wouldn't need to worry about getting shut down by the RIAA so some centralization is OK.
No one person would decide what to 'blacklist' rather, simple counts of spam/non-spam could be retrieved by users. People running mail servers could see the Spam that they supposedly sent and, erm, repent:P. Older entries would automatically loose 'weight' so that people who change their ways can send email again. People who send in bizarre reports would have those reports weighed lightly.
How do you prevent DDoS? Well, honestly I think the best solution would be to have users pay a small fee going towards hosting on something like Akami. That would be a lot simpler then trying to setup and manage the security of a distributed redistribution system.
We might also have an identity verification system to prevent spammers from faking thousands of accounts to fuck up the averages.
People always talk about seperating presentation from code, but isn't it a good idea to save your data seperate from your code? With a Relational Database, you have a nice sensible collection of data that's easy to understand in any programming language. This object stuff is complex and language dependant. Maybe code and data should stay seperate.
Geez, this just seems stupid. They want you to store all your data in RAM and save it to disk once a night via 'plain object serialization' If they really are using 'plain object serialization' in java then all data-access functions are going to lock, which means you won't be able to update anything during the serialization stage. And if you have a system crash, you lose all your data for the whole day.
If they had any sense then they would have everything saved to disk (like a journaled file system) and the 'serialize once a day' thing wouldn't be an issue.
And lets not forget the fact that object serialization is slow. I once tried to build a website using java collections and serialization, and it would take nearly half a second to save the whole sites data, with a 'database' of only a few thousand entries. I can't imagine long it would take to save the hundreds of megs of data autopr0n uses.
Maybe they've solved some of these problems, but it still sounds stupid. There are "real" OODBMs that let you keep your data in an OO system and let you keep that data on a hard drive, like a sane person.
If you get spam avertizing a mortgage or penis pills or whatever, all you have to do is sue the pharmacy or mortgage house. $1k is worth the money, you might be able to get a laywer on contingency or do it in your spare time.
Even if you lose, which is doubtfull (why would a judge alow a 3rd party to break the law for you) it's still a huge pain in the ass.
The advertizer may just flip on the spamemr anyway.
In Iowa, I can only get $50 per Spam. If I could get a thousand, I might actually go through the trouble figuring out who spammed me. If I get forged-header gobltygook then I can go ahead and sue the organization that spammer promotes. If only 0.001% of receivers purchase anything, 0.001% of them suing them will probably make them think twice, even if the suit doesn't win, it's still a huge burden.
Slashdot Mirror
Outlook's numerous viruses are not caused by the program being written in C or C++. They are caused by Outlook's support for active content. The problem would still exist if Outlook were re-written in Java. I wonder if nobody in Joy's circle dares to correct him on this, or if he's been corrected and just didn't hear.
It only takes a few lines of code in Java to create a 'sandbox' and restrict any code you want to run in that sandbox. If MS had used Java they could have put their VBScript interpreter in side that sandbox. Only 6 or 7 lines of java code could have fixed all their problems.
It's not a memory leak if you're still "Using" all of the data, meaning that there is a valid reference to it. In C++ you can have allocated memory that is not referenced by any process, and thus cannot ever be deleted. Such a situation can't happen in java.
//so we alocate a lot of ram.
A referencing B which references A will defeat a Java's garbage collection.
No, it will not. Sun's garbage collection is not a reference counting system. It works by looking at what's connected to each Thread object. Typically a thread will have a instance of the Runnable interface, which is your class with all the member variables, vectors, etc which are all connected to their children, etc. The garbage collector does a search of that graph, and marks each node. If a node isn't marked in the end, it's deleted. if any node is not reachable by running code, it will be deleted no matter how many other zombie nodes also are connected to it. Your system would work in Python (but not the Java implementation of python), Visual Basic 6.0 or less and Perl (iirc) but not Java.
If you don't belive, write the java program yourself. Hell, here's an example.
class a{
b myb;
a(){
myb = new b(this);
}
}
class b{
a mya;
b(a inputA){
mya = inputA;
byte[] randomcrap = new byte[1024];
}
}
class CircularTest{
public static void main(String args[]){
int i = 0;
while(true){
a loop = new a();
i++; if(i%100 == 0){
System.out.print(" " + i);
System.gc();
} } } }
Put that in a file named CircularTest.java, then type "javac CircularTest.java" then "java CircularTest", watch your memory usage not increase without bound.
That's fine if you're writing your little web application, but I'm not convinced it'll perform well when the day comes to render 3D in real-time, or implement a codec.
Why not? Array access is as fast as pointer arithmetic. Sure, those things are bounds checked in java making them a little slower, but linked lists for things like scene graphs and the like are just as fast. If you're using GL for 3d rendering, it should be plenty fast.
My last statement is this: C++ can be *as* safe as Java if say a programmer consistently uses STL. AS SAFE.
That's just not true. In java, I can take an piece of code and in a few lines of code Lock it down and prevent it from accessing the file system, with per-file granularity. I can prevent it from accessing the network, the GUI system or the printer, or anything else I might want to protect (all I have to do is add more permission types). There is absolutely no way to do this in C++. Once code is loaded into your memory space, it can do whatever it wants.
If outlook had been written in java, The VBscript and other 'high level' vulnerabilities that plagued it could have been avoided simply by locking the script interpreter into it's own little 'sandbox' where it couldn't have done any harm. Sure, people at M$ could have made their own sandbox for the interpreter, but obviously they weren't able to. The STL has nothing like this.
OO languages simply aren't suitable for all tasks, neither is C.
I seriously doubt there is a situation where C++ would work and C wouldn't. Sure, there are trivial situations where you wouldn't need more then one object, but C++ works anywhere C would.
No, but you could easily write an e-mail client in Java that interpreted scripts in the body or header fields of an incoming mail by default, and allowed those scripts to do things they shouldn't.
True, but with java you can prevent those mail scripts from doing anything they shouldn't do with about 5 or 6 lines of code (simply load the script interpreter into a ProtectionDomain without any rights to the filesystem, and call AccessControler.doPrivilaged() with it)
Exceptions in java are not "invisible" In fact, you have to check for declared thrown exceptions (but not 'runtime' exceptions). In the API declared thrown exceptions are caused by external problems (like a missing file, closed socket, etc) while Runtime exceptions are usually caused by programmer error (like null pointers), and can be avoided by poor programming.
If your python app is choaking on invalid input, it's because you can't program for shit, not because exceptions suck. If it was a C app, you'd simply segfault or something equally ridiculous. And you'd never know why. At least with the stack trace you can quickly pinpoint your problem and deal with it.
The human brain is definitely not faster at calculating vectors, or doing any kind of math, then a computer. Eventually, you might build neural pathways that do some of the work for you unconsciously, but it would still be an approximation.
If you know the current vector, and you know the vector you need, all you have to do is subtract. If you need to tell the server to give you some amount of torque to the gun, you can do that easily using classical physics. The operation won't take more then a few hundred CPU cycles.
I doubt the CD key thing is a big deal. All they need to do is change the algorithm before they release the code.
For a computer, calculating the delta of vector is exactly as difficult as calculating the actual vector.
That guy's name is Kamen
I only said I wondered if he could be sued if he released the plans.
It's obviously not true. A bicycle is kept from tilting sideways by momentum, but it doesn't flip over because it is touching the ground in front or in back, far away from the center of gravity.
The amount of torque you would need to get the center of gravity on the other side of one of the wheels is huge, since there is a small angle between the center of gravity, the center of the wheels, and the direction you're going.
On the Segway, there is a 90 degree angle between those vectors, and you would need no force to 'unbalance' the segway. The reason the segway stays up is because the software controls the wheels and continually moves the center of gravity so that it stays balanced.
I'm more impressed with the arrogance of Camen, suggesting that entire cities are going to be redesigned because of his yuppie toy, than I am impressed with his courage.
Who's Camen? It was Steve Jobs who thought cities would be designed (not redesigned) for this thing.
All you'd have to do is connect the wheels to 'spires' coming out of the side of the vehicle, rather then to the center of the vehicle. Sort of like "|\_/|" rather then "|-|" (we'll see if slashdot lets this past the lameness filter..
It would make the thing rather funky looking though, and most of the stability comes from the software, so you don't really need big wheels unless you want to go over big bumps.
I'm sure this guy is violating a couple patents :P. Hmm... Can you be sued for patent violation for non-commercial use? I wonder if he could be sued for releasing plans?
Clearly, my car needs to be recalled. When I run out of gas, it just stops.
This could be dangerous on the highway!
Wasn't @stake the security company that grew out of the l0pht? Or am I on crack?
For example, how about getting RMX (Reverse MX lookups) working. A lot RBLs are error prone. A distributed RBL would either not really be distributed (i.e. a central 'committee' that decides who's on the list and lots of mirrors), or a disaster (i.e. anyone on the net can block people). I'm not saying it couldn't be done, just that it would take a Herculean effort to prop up a technology that a lot of people think causes more harm then good.
:P. Older entries would automatically loose 'weight' so that people who change their ways can send email again. People who send in bizarre reports would have those reports weighed lightly.
The ideal (in my mind) anti-Spam 'tool chain' would be RMX and Bayesian filtering along with per-user white listing for messages that are flagged by those systems. A per-domain blacklist of "sites vouch for Spam via RMX" could be created and done on a somewhat distributed system, rather then an IP based system.
Anyway, here's how I would design a distributed blacklist type system. First of all, it would be based on RMX rather then IP space. That way people who are forced to share IP space with spammers don't get screwed. Users of the system could flag mail as 'legitimate' or they could flag it as 'Spam' legit email is sent in only as a counter, and actual Spam is forwarded to a central system. Unlike Kazza or whatever, we wouldn't need to worry about getting shut down by the RIAA so some centralization is OK.
No one person would decide what to 'blacklist' rather, simple counts of spam/non-spam could be retrieved by users. People running mail servers could see the Spam that they supposedly sent and, erm, repent
How do you prevent DDoS? Well, honestly I think the best solution would be to have users pay a small fee going towards hosting on something like Akami. That would be a lot simpler then trying to setup and manage the security of a distributed redistribution system.
We might also have an identity verification system to prevent spammers from faking thousands of accounts to fuck up the averages.
People always talk about seperating presentation from code, but isn't it a good idea to save your data seperate from your code? With a Relational Database, you have a nice sensible collection of data that's easy to understand in any programming language. This object stuff is complex and language dependant. Maybe code and data should stay seperate.
With C++ alocators you can create data structures right on the disk. You don't need to write your own persistence layer.
Geez, this just seems stupid. They want you to store all your data in RAM and save it to disk once a night via 'plain object serialization' If they really are using 'plain object serialization' in java then all data-access functions are going to lock, which means you won't be able to update anything during the serialization stage. And if you have a system crash, you lose all your data for the whole day.
If they had any sense then they would have everything saved to disk (like a journaled file system) and the 'serialize once a day' thing wouldn't be an issue.
And lets not forget the fact that object serialization is slow. I once tried to build a website using java collections and serialization, and it would take nearly half a second to save the whole sites data, with a 'database' of only a few thousand entries. I can't imagine long it would take to save the hundreds of megs of data autopr0n uses.
Maybe they've solved some of these problems, but it still sounds stupid. There are "real" OODBMs that let you keep your data in an OO system and let you keep that data on a hard drive, like a sane person.
You can do a lot of things to put someone out of business if you break the law. Company B could simply shoot all the management of company A.
If you get spam avertizing a mortgage or penis pills or whatever, all you have to do is sue the pharmacy or mortgage house. $1k is worth the money, you might be able to get a laywer on contingency or do it in your spare time.
Even if you lose, which is doubtfull (why would a judge alow a 3rd party to break the law for you) it's still a huge pain in the ass.
The advertizer may just flip on the spamemr anyway.
In Iowa, I can only get $50 per Spam. If I could get a thousand, I might actually go through the trouble figuring out who spammed me. If I get forged-header gobltygook then I can go ahead and sue the organization that spammer promotes. If only 0.001% of receivers purchase anything, 0.001% of them suing them will probably make them think twice, even if the suit doesn't win, it's still a huge burden.
Didn't NS write a large part of his new book with a quill? I seem to remember hearing something like that. hmm