[rc5] Security, Java, and Source
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
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: [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: [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
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
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5