[rc5] Security, Java, and Source

Marc Sissom msissom at dnaent.com
Fri Oct 10 11:48:58 EDT 1997


David M. Putzolu wrote:
> 
> Core in assembler. Use native methods to do this. Good performance.
> Networking in Java. GRAPHICAL USER INTERFACE (GUI) in Java.
> GUI code in C not portable. GUI code in Java portable.
> Repeat: GUI C code not portable. GUI Java code portable.
> Portable good! Not portable bad!  C GUI bad! Java GUI good!

Let me add:
C network code not really portable.
Almost, not quite, still hard time finding all little problems.
C can be made more portable, but must spend time finding out what
can use here cannot use there what will work on all. Must use only
what can work on all then lose feature/speed/reliability on all.

Java network code portable. Always, all time, no changes needed.
Spend time making core code faster/better not spend time making
net work.

> 
> Also:
> C not safe. Java safe.

A bit more lenient, and realistic:
C not safe, Java not safe either, but Java safer than C.

Besides, the java clients exist, why not release them?
Even if no one modifies the java client to run a native core,
there will be some folks that will run it, who would not be
running a client otherwise.

Remember, security has officially been denied as the reason
for concealing the v2 code. What is the reason for not releasing
the java clients? I guess you could skirt this by releasing a
v1 java client.

It can't be performance. To quote the homepage:

     Most importantly: tell your friends, recruit more CPUs!
     The more the better! 

My friend wants to run a java client. He's got his reasons.

--
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list