[petsc-dev] PETSc-3.4 PR open at https://github.com/Homebrew/homebrew-science/pull/343

[Barry Smith]

   I am not actually advocating not adhering to the gnu/linux installation "standards".

   Barry

   Oh, one final complaint (though I could find many more), why is it 2013 and yet they still haven't finalized 1) where to put debug versions of libraries and 2) fortran modules. Talk about open approaches moving extremely slowly.

   
On Oct 12, 2013, at 10:36 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>   They may be doing a decent job given the silly/archaic model they
>>   have to work on, but after all these years maybe there is a need to
>>   rethink the model. All these smart people wasting their time
>>   working on complicated packaging systems to get around the limits
>>   of the original model.
> 
> Managing dependencies is hard.  Linux distributions solve the problem
> almost completely for normal software and normal users.  "aptitude
> install octave" and you're on your way in seconds.  It will be
> transparently upgraded along with everything else when requested,
> security vulnerabilities in dependencies will be patched without needing
> to reinstall the world, you can remove it (and any automatically-
> installed packages) cleanly, you can link any collection of libraries
> into another library or executable, etc.
> 
> Scientific software developers tend to put a great deal of effort into
> making excuses for why they don't want to play in the ecosystem above.
> It doesn't help that companies like Apple have no interest in helping,
> and that companies like Cray and IBM are dedicated to breaking yet more
> conventions to ensure that everyone knows they are special.
> 
> But if you want to make installation and distribution easy for the user,
> especially if your software is "deep" in the stack, distribution
> packaging is hard to beat.
> 
>>    Yes, Apple messed up the framework model (doesn't handle
>>    documentation, not portable, doesn't handle versions well,
>>    unneeded option names) but that doesn't mean one should stick with
>>    a 40+ year old model just because it is the way it has been always
>>    done. How about designing a better model?
> 
> http://www.xkcd.com/927/
> 
>>  Linux/Gnu has done a great deal of harm to computing because it
>>  filled a partial vacuum by reinventing already 20 year old
>>  technology preventing decent exploration of more modern innovative
>>  approaches.  
> 
> The only way the GNU and Linux projects could have gotten started is by
> being compatible.  Plan 9 is the awesome, elegant environment you
> wanted.  At the end of the day, people settle for useful over elegant.
> 
>>  When a vacuum is filled with the same old stuff you can never know
>>  what huge innovations you may lose out on.
> 
> Fine, let's not force our users to adopt our innovative directory
> structure until we've established that it really and truly is better,
> enough better to justify breaking all the tools that depend on the other
> convention, and implemented a migration plan for everyone to move to the
> new system.
> 
> In something as fundamental as dependency management, one capable but
> mediocre system applied consistently has a better user experience than
> an eternally-fragmented and mutually-incompatible system, even if each
> member of the fragmented world is technically better than the mediocre
> system.
> 
> I am in favor of strict adherence to these packaging conventions unless
> we have a damn good reason not to, and any such reason must be something
> of significant consequence to the user that is practically unworkable
> without deviating from the convention.
> 
> By and large, our users want solvers that work well and are easy to call
> and easy to adapt/extend to their applications; they don't want to think
> about packaging.