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

[Jesse Keating]

On Thu, 2009-01-15 at 16:20 -0800, Chuck Wolber wrote:
> This is an excellent point to make. What about when Python wants to do X 
> but there is no native facility for X? I would imagine that it then has to 
> implement that from scratch as best as possible, but I do know know enough 
> to say for sure. Perhaps this problem has never happened? I doubt it.

I'm not sure what you mean here.  Maybe something like regex parser?  I
don't think there is any one true parser, and perhaps python has it's
own, instead of using one somewhere in a c library.  I'm not sure
though.

> 
> From a business person's standpoint, if you wish to run the same code base 
> on Windows and *ix, development should be cheaper with reimplemented 
> facilities because those facilities are guaranteed to work the same way on 
> both platforms. In contrast, something like Python, that uses native 
> facilities, probably has to do a lot of internal massaging in certain 
> places to get facility X to behave the same way on Windows and *ix.

Ah, but it's the /interpreter/ and the runtime tool that uses the native
facilities, not the code itself.  In general, you use the same written
code to do things in Linux and Windows, the python application itself
takes care of poking at the native things for you.  The benefit here is
that when you update your host OS, your python applications get
"updated" as well.  EG a patched openssl fixes any of your python
applications that use ssl.  In fact, since python would use ssl shared
libraries, python itself wouldn't even have to be touched.  Can the same
be said for Java?  (maybe ssl is a bad example, but I think you get the
picture)

> To throw a bone to Python, I would presume that using native facilities 
> and massaging where necessary requires fewer lines of code than the 
> re-implementing the world approach. More lines of code == more bugs... 
> 
> But still, it can be maddening to have different behavior on different 
> platforms with the same code base. YMMV...
> 
> 
> > ... but I bet you must use the same vendor java and patch level on 
> > whatever platform you're on.  Also, I don't doubt that such things 
> > exist, I've just never experienced them, despite all the advertising to 
> > the contrary.
> 
> Vendor? Yes. Patch level? Not that I have ever personally seen although if 
> I relied on the timezone it would have been an issue. All of my code (so 
> far) is based on Zulu time...

I experienced software that broken from one Java 5 patch level to
another Java 5 patch level, because Sun had "fixed bugs" which seemed to
be their language for "we don't want to support this functionality
anymore".  So some apps were certainly stuck on a patch level.  Hope you
didn't need that fix!

> 
> 
> > Yes and no.  There are no illusions that you'll have to forward port 
> > python for new versions, or do porting work to move an app to a new 
> > platform.  There is no claim at all of WORA.
> 
> Agreed, same goes for Java. We're testing our Java 5 app against Java 6 
> right now. It works surprisingly well, but there are differences that may 
> force an update. So far, the differences appear to be minor.
> 
> 
> > The question has always been for me "which instance of Java was this 
> > WORA written for, and now I'll have to add /that/ version to my 
> > infrastructure to go along with the other 5+ versions floating out 
> > there."  Oh sure it'll run anywhere.... anywhere you have this exact 
> > copy of the JVM for me.
> 
> [...]
> 
> I think that is where the fundamental misunderstanding about WORA is. *IF* 
> the code was not written by a ham-handed developer and consideration was 
> given to stuff like the "slash" problem, the basic WORA contract is that 
> an app compiled against a given major JRE release will run on any platform 
> that the major JRE release will run on.
> 
> Within a given major release, patch level should generally be irrelevant 
> (your TZ example is a good counter example).
> 
> I have never heard anyone say that WORA means a Java 4 app will run just 
> fine on a Java 5 JRE right out of the box. The only way that could work is 
> if your Java 4 app was lucky enough to use the subset of functionality 
> that did not get changed in Java 5.

Agreed.

-- 
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/20090115/fd385edd/attachment.sig