[rc5] Security, Java, and Source

Eric Gindrup gindrup at okway.okstate.edu
Fri Oct 10 12:50:52 EDT 1997


     To address your points in order...
     
     Sun and Microsoft don't have to fight it out.  MS isn't implementing 
     Java and that's what Sun is suing about.  That MS can't implement a 
     standard, even their own, isn't particularly surprising to me.
     
     Anyway, there are several things that would make this good:
     1. The sandbox model would make the multi-project ideas more palatable 
     to several users, myself included.  I don't like the idea of the 
     Bovine client running out somewhere, downloading a project module I 
     don't know anything about and running it.  I don't worry as much about 
     a Java Applet doing so.  As has been pointed out elsewhere, security 
     would probably drag a few more people into the effort.
     2. If MS continues to produce non-Java products, persons who actually 
     want to run Java applets will have to go to a browser that *does*.  
     Netscape is a likely candidate.  It would probably run Sun's and MS's 
     versions of Java, they're like that.  In any event, there are options 
     for how to run it available to most users: JDK? browser?
     3. Finally, MS is the only company in this discussion that reliably 
     fails to implement backward compatibility.  And although there are 
     several users running on MS OSs there are more clients that are not.
     
     The Apple propaganda states that OS8 runs Java out of the box.  I've 
     not used OS8, because we have compatibility problems with it, but I 
     expect that this is approximately true.  I note that Apple is not 
     being sued for failure to comply with licensing agreements concerning 
     Java.  Then you add OS/2 and Linux.  This, as usual, leaves only one 
     OS vendor failing to keep up.  And even on that vendor's platform 
     there are options on how to run the client.
     I also note that you seem to think that the client isn't going to grow 
     much.  I expect the modular architecture of the v3 clients to cause a 
     noticeable growth in executable size.  The one-disk requirement will 
     immediately fail if they can't make the next version almost exactly 
     the same size as this version.
     You ask how many cycles it takes to keep the Java compiler working.  
     That depends on the implementation.  Any implementation of a "cross-" 
     interpreter since some relatively interesting work by IBM about 5 
     years ago tends to cache the translated versions of code so that loop 
     contents are only interpreted once and the cached version is then used 
     for subsequent calls.  It is certainly the case that this invokes more 
     overhead than a purely native piece of code, BUT this code is only 
     supposed to contain functionality for the GUI and networking.  These 
     events are not on the cycle timescale.  This client would spend most 
     of its time running a preliminary version of the computation module 
     written entirely in Java that is dog-slow, but is better than waiting 
     for all the different versions to come out.  Later in the project, the 
     platform-tuned binaries could be made available and people who are 
     actually interested/trusting enough to do so could download the native 
     core.  Then the compiler would spend most of its time suspended 
     waiting for native methods to return.
     I also would prefer a greater variety of hidden clients.  Note, 
     however, that there hasn't been a profusion of such clients...  
     possibly because of the necessity of porting client changes to so many 
     different platforms.  The point of unifying the non-core portion of 
     the code is so that the developers could actually respond to client 
     improvement requests in something more closely approaching "Internet 
     time".
     
     I would tend to argue the opposite.  It's a testament to the 
     inefficiencies of maintaining so many different ports of the same code 
     that has kept us from surpassing 40% earlier.  Many users, notably the 
     large Mac contigent had to wait until sometimes several weeks after 
     the MS OS clients were released to ge the equivalently tuned Mac 
     release.  Similarly for important features like invisible clients and 
     so forth.  The Java option is to reduce the amount of developer time 
     wasted on reinventing the netowrk code and UI wheel for every target 
     platform, but to narrow their focus to the item that you're most 
     interested in: "I'd also want the majority of cycles devoted to key 
     cracking ..."  I agree.  I'd rather the developers have the time to 
     tune the hell out of the core code, instead of redeveloping the same 
     code over and over.
            -- Eric Gindrup ! gindrup at Okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: RE: Re[2]: [rc5] Security, Java, and Source  
Author:  <rc5 at llamas.net > at SMTP
Date:    1997/10/10 12:09


[Rants deleted, heavy snippage]
     
From:   "Eric Gindrup"<gindrup at okway.okstate.edu>[:] 
Sent:   Friday, October 10, 1997 10:04 AM
To:     <rc5 at llamas.net>
Subject:        Re[2]: [rc5] Security, Java, and Source 
     
     
    "all of the idiosyncracies on each target compiler/platform.  Java 
        would make all of this code *exactly* the same on every platform.  "
     
>I have a question about this assumption.  Yes Java's good for cross-platform 
development, but I don't trust Sun and Microsoft fighting it out to make it 
work.  I'm sure they'll throw in enough differences to make it a pain, althought
it would probably be easier than debugging straight C++.  But is it worth it? 
Are the current clients that screwed up?  I really don't think so.  Do they have
problems?  Probably, is the value-add worth the cost of recoding them from 
scratch?
     
     Second, GUI code is even more platform specific than the first 
     collection of items.  Although there are two GUI programming targets 
     in Java now, that number is much smaller than the number of platforms 
     with non-compatible GUI interfaces.  Finally, there have been several 
     complaints about the reliability of the connection process used by the 
     clients.  Java networking appears considerably more robust.
     
> This is where I have specific problems.  Assumping you code the client to run 
under Java, how many run-time libraries will be required on machines to make it 
work?  The JDK 1.1  is a whopping 12MB Binary assuming you install it.  Or will 
the client cracker run under Netscape/IE or HotJava to get compiled?  So far I 
am only aware of OS/2 and Linux being able to natively run Java Apps, everything
else will require additional libaries.  I'd like to keep the clients the way 
they are now, small enough to fit on a disk, and operate.  While it's tricky to 
fit EVERYTHING a linux machine needs on a disk, it's possible.  I'd like to know
where this leaves Win95/98/NT machines.  Since I don't run the Macintosh client,
I can't comment.  Popular to common belief, 98 doesn't have the facilities to 
natively run Java apps.  Regardless of what Bill wants.  I also don't trust MS 
apps to handle this with aplomb.  My next concern is the mention of the GUI, I'd
like to have clients without a GUI.  A hidden Java client would be a nice idea, 
but if the compiler is always running, how many cycles does it take to keep 
running? I'd rather have the core cracking routines running, and ignore the GUI 
entirely.  We use a number of Java apps internally, and some of them are 
complete and utter cpu hogs.  I have noticed that performance has increased, but
I'm still wary.  I'd also want the majority of cycles devoted to key cracking, 
not pushing pixels on the screen.
     
I've noticed that Java has the tendency to be more robust, but like any other 
programming language, if you don't know what your doing you can make a shitty 
network application.  While some people have had problems with the current 
client's networking functions, I haven't.  I've had more problems keeping the 
machines stable long enough to take advantage of them.  I don't think the 
current clients fundamental design problems, they have at most, a few kinks to 
be worked out.  It's a testament to how well they work, that so much of the 
keyspace has been done so far.  If the clients were as horrible as some people's
letters make them out to be, I'm sure we'd still be at 4%.
     
Flames to /WinNT/profiles/Admin
     
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
body.
     


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



More information about the rc5 mailing list