gnome-vfs not in Rawhide?

[Paul A. Houle]

On Mon, 11 Apr 2005 17:23:23 +0200 (CEST), Nicolas Mailhot  
<nicolas.mailhot at laposte.net> wrote:

>
> App vendors usually test jvm to death with the OS version they have  
> during
> development, then the testing budget is exhausted, and jvms are
> "certified" with the following OS releases despite having only cursory  
> app
> vendor testing (because no one dares telling the truth to management  
> about
> the whole situation, not certifying them would be commercial suicide, and
> testing them properly would cost too much).
>
> Not surprisingly, the end result crashes.

	Yeah sure,  but once I get a system that works,  that doesn't wake me up  
at night because it went down at 2 am,  I'm inclined to sit on it.

> The jvms OS vendors ship might not be tuned perfectly but at least they
> work and distributions will fix them if they don't. App vendors support
> will tell you to use the unsecure underperforming entreprise linux  
> version
> that was already old when they tested against it. And that after paying
> $$$$ for gold support.

	Maybe,  maybe not.

	I've got a limited amount of faith in vendors.  My productivity as a  
developer was destroyed for about six months that I had to deal with race  
conditions or deadlock issues in the defective 2.4 kernel that shipped  
with RHEL 3.  We bought RHEL through a third-party vendor,  so support was  
useless,  and I doubt that we'd have done better if we'd talked directly  
to RH.  It probably would have taken a nearly-identical test machine and a  
few weeks of time from a full-time kernel developer to have fixed our  
problem,  probably a total cost of 10x our yearly registration cost.

	An upgrade to 2.6 solved the problem.

	I do have faith in the 2.6 kernel,  but I'm more interested in catching  
up with six months of lost time than I am in spending another few months  
screwing around with buggy software.

> If they don't have the resources to keep their jvm current with OS
> releases, they should be honnest and team with jvm/OS vendors (ie push  
> the
> fixes they need upstream during their testing phase, and rely on upstream
> not to break it afterwards). They do rely on kernel/libc vendor packages,
> and they're as impacting performance-wise.
>

	Yeah,  I wish that were all possible.

	But there's a lot of nonsense in this world.

	For years,  RH shipped a free 'java' runtime that was completely broken,   
wouldn't run any real java applications,  and ran toy applications with an  
order of magnitude worse performance than commercial java implementations.

	The skills and knowledge about code generation,  concurrency control,   
memory allocation and garbage collection in the open source world have  
been largely insufficient to make workable java implementations.

       (Yes,  the new gcc-java is a big step forward,  but it's still quite  
quirky,  and it's overall success depends on dumping AWT and Swing into  
the trashcan.)

	Sun's software strategy is unclear (how could they possibly make money  
off of Java?) and their relationship with Linux is problematic.  (A few  
years ago they laid off the developers of Solaris x86,  now they're coming  
on full-force with Solaris 10 as a competitor against Linux.)

	IBM has it's own Java runtime which is a derivative of Sun's -- at times  
they've put some good work in it.  God bless IBM,  but you can only count  
on them so far for support.

	The 2.6 kernel team is doing big things,  often really good things.  Will  
those things introduce subtle breakages involving Java threads?  Quite  
likely.  Is it really fair to Sun and IBM to expect their engineers to  
solve problems immediately because some kernel developer had a 'good' idea  
they wanted to try out?

	The kind of model you're talking about,  in a lot of ways,  might be  
easier when we're dealing with the kind of single-vendor hardware stack  
that you're likely to get from Apple or with SPARC/Solaris from Sun.