[geeks] Browser licensing?

[Alois Hammer]

On Wed, 3 Sep 2008 22:02:37 -0400, "Joshua Boyd" <jdboyd at jdboyd.net>
said:
> 
> Wait, you are saying that JAVA and .NET mostly run single threaded code?
> That is surprising.

Mm-hmm.  http://java.sun.com/docs/books/tutorial/essential/concurrency/
lets us know that concurrency has been baked into Java since v5 (or 1.5,
if you prefer, and I do).  I've never yet been to a shop where the
developers aren't still running 1.4.2 or worse.  Go look at American
Power Conversion's PowerChute Business Edition (I'll wait).  They wrote
the agent, the server, and the client in Java, ship 1.3.x with it, don't
allow you to change to a newer JRE (yes, I managed to brute-force it
anyway with the dubious magic of Windows junctions), and make it start
(at least) two entirely separate JVMs every time your Windows machine
boots, plus at least one more for the console if you'd like to see what
your UPS is doing, or run a battery test or something.  This is not
atypical.  It *really* sucks on the one 2.4GHz/1GB Celeron Windows box
I'm still running, that has to be plugged directly into the SmartUPS
420's serial port, which refuses to speak to PowerChute Personal Edition
(not that it's loads better than PCBE).

If no one's coding to JRE 1.5 or better-- and I don't see anyone doing
it on a regular basis --it's hard to get threaded code.  The ongoing
split between "Generation-1" and "Generation-2" Java in Gentoo Linux
probably helps illustrate what's going on here.  Also, see below about
general incompetence.

As for .NET?  I'm still fighting to keep clear of it, so I have no idea
what the threading case is like.  I do know that there's a lot of legacy
.NET 1.0/1.1 code out there that will merrily refuse to run on the
2.0[SP1,SP2] runtime, and .NET 1.1 hasn't been supported for a long
time... sort of like MSJVM.  Microsoft, in fact, wrote a lot of that
legacy code.  Some of the XP PowerToys, for instance.  I think AMD's
Catalyst Control Center, which is only the official interface to their
core graphics drivers, was finally recoded to use .NET 2.0 a whole...
year ago?  Something like that.

I'm also very dubious about Microsoft's strategy of marketing further
.NET extensions as "3.0" or "3.5" and admitting that they're merely
extensions to 2.0, and require the 2.0 runtime to be installed.

> It is interesting that you blame Java or the JVM for that C&C system
> when Java can and does run on much smaller platforms quite acceptably,
> even today.

I'm guessing that you're talking about J2ME, which is a fairly tiny
subset of Java designed to do very little with very little, and doesn't
apply to this discussion.  And I don't know whether to blame Java for
the coders, or just note that most coders I've met who specialize in
Java are generally incompetent.  I have read a few articles blaming Java
for degrading the general level of coding skill in CS students, but I'm
well out of academia these days.  Since the result is the same, I don't
suppose it matters.

Also, I did upgrade the "workstations" to J2SE 1.5 over the objections
of the developers, which did improve performance a little, and spent a
long time tuning the Windows installations to the point that they
approached Linux 2.0 on the same box on a bad day.  IIRC, the first JVM
instantiated (the one driving the GUI) used 23MB, and each additional
used 21MB.  On a box with 128MB to start and Windows and the Intel GMCH
(i815 chipsets) using part of that, you can't really afford the 23MB for
the UI, much less another 21MB for every connection to an app server.

> And you still haven't explained why it is impossible for there to be a
> fast instantiating JIT VM.  Above you are comparing desktop (or perhaps
> server) application startup performance, not just VM startup
> performance.  

That's true; I haven't really explained why.  All I can do is leave it
at, "My long experience leads me to run screaming into the night when
people talk about putting things in VMs."  Or possibly, "If no one else
has managed it since 1967, why is Google going to be the first?"

And, yes, I'm concerned about startup performance.  If V8 manages to run
big JS apps really, really fast after the JIT or dynarec or whatever you
like is finished, that's good news for Google apps.  It's terrible news
for the little snippets of JS that make up a lot of the tiny web
applets, forms, UI frameworks and whatnot that I tend to encounter
*instead* of Google apps.  And, if you're using Firefox at all, do
remember that Firefox and some of the add-ons use JS for themselves.

Since you'd like me to talk about VM startup by itself: uncached JVM
(Sun J2SE 1.6u7) instantiation runs to about eight to nine seconds on
this Linux workstation with an Intel E8400 and 4GB of RAM.  (Sun, if
you're reading, this would be an excellent time to *stop* compiling
against libstdc++-v3.  I don't use it any more, and neither should you. 
Also, xcb support would be appreciated.)  Let's be overly generous and
assume that V8 would only take... oh, two seconds to instantiate.  Why
would I want to wait two extra seconds for a common JS applet to get
rolling when Firefox 3.01 executes it inside a fraction of a second
(with Greasemonkey, NoScript, and several other add-ons interfering with
the execution) and uses far less RAM to do it?

Straight-up, brutal honesty: with V8 and Gears(r) Inside(tm), Google
Chrome was obviously written to make Google's services look better
and/or run faster and, hey, let you browse most of the rest of the web
without having to start another browser.  It was *not* written to make
*everyone's* pages load faster and run faster.  That's the entire
purpose of WebKit's SquirrelFish, which Google explicitly note having
removed in their comic^wbrochure.