[SLL] faking Unix knowledge? pretend to know open source Unix?

[Jesse Keating]

On Wed, 2009-01-14 at 10:05 -0800, Chuck Wolber wrote:
> 
> Bad packaging is hardly a stinging indictment for Java as a whole.

Granted.  I've never attempted to program something in Java, there are
those who claim the /language/ is wonderful.  That's fine, I'll buy
that.  The cargo that goes along with needing to /run/ the language is
where I have a beef.  I've been burned here, far too often, and any
progress on fixing these issues is so far out that I don't have much
hope, at all.

>  I agree 
> that the DST thing was a big crap-storm, but it is not like we haven't 
> seen high profile crap storms before. Kaminsky DNS flaw, Debian Signing 
> Key, RH Signing key, etc... They all had different reasons behind them, 
> and none were intentionally caused. 

Except that with java, the explicit goal is to replace as much as
possible from the underlying OS.  This means that we'll constantly see
repeats of this problem, again and again.  Do you know how frequently
timezone information changes?  It's scary when you look at the world as
a whole how often some dictator in some crappot country decides that he
wants to be different and offsets by 10 minutes or something.  glibc
updates /constantly/ with new tzdata, so much so that it lives in it's
own package now, tzdata.  Looking at the changelog we have world changes
causing updates at: Oct 30, Oct 13, Oct 7, Sept 16, Aug 12, Jul 8,
etc...  If one wants to have accurate timezone information at a world
wide basis in a java application, that JRE needs to be patched, each and
every time.  Then multiply by how many different java applications you
have which each need some other version of JRE to run.  This is
just /one little/ part of the whole pile that java re-invents.

> 
> You would not be implying that Python has been all roses are you? Python 
> has its own platform specific quirks. Every interperter does, it is 
> impossible to avoid it when you are trying to provide a stable API that 
> applies to all platforms the interpreter runs on.

If only they would ever accomplish that goal.  I've yet to see a large
java application that doesn't care what java JRE
vendor/version/release/patch level it runs on, and breaks horribly when
you go off-spec, and the vendor just tells you tough, use what they
support or you're on your own.  It's even worse with embedded devices
that serve up a jar, you have to have /on your client/ the right
matching JRE to run that jar to be able to use the device.  We have to
keep around JRE crud on old installs just to be able to interface with
management consoles on machines because some idiot thought it would be
brilliant to make the management system Java, so that it would be stable
and always work in the future and across platforms.  Whoops.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists2.linuxjournal.com/pipermail/linux-list/attachments/20090114/c599300e/attachment.sig