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

[Barry Smith]

On Oct 12, 2013, at 7:01 PM, Aron Ahmadia <aron at ahmadia.net> wrote:

> Sorry, the homebrew folks are doing a decent job of working correctly
> in the open source OS X space.  There are a million package managers
> doing a reasonably good job in the GNU/Linux world.

   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.

    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? 

  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.  Just imagine if Jack had done an adequate (yet obviously very crappy) implementation of sparse iterative solvers in the style of Lapack in 1990, there would be no PETSc today and you would still be fucking around with 6 character function names, reverse communications and unusable, inextensible solvers. When a vacuum is filled with the same old stuff you can never know what huge innovations you may lose out on. 

   Barry


  
> 
> A
> 
> On Sat, Oct 12, 2013 at 8:00 PM, Aron Ahmadia <aron at ahmadia.net> wrote:
>>>  This whole prefix/include and prefix/lib seems rather silly and archaic; who uses it but the gnu/linux people ?  For example on MacOS the PETSc install location is /Library/Frameworks/PETSc.framework,  on Windows they must have some convention but it sure as hell doesn't use include and lib.
>>> 
>> 
>> Barry, your code runs on Supercomputers.  Last time I checked, there 3
>> Windows machines on the Top 500, and no OS X machines.  Even leaving
>> that model, the homebrew folks, who seem to be the only ones operating
>> correctly in the open source space, use a prefix installer.  Your
>> general audience is scientific software developers.  They equally
>> develop in Windows, OS X, and Linux.  But computational scientists
>> overwhelmingly use Linux-ish environments.
>> 
>>>   Why does the linux world (which is tiny) cling to this archaic model?
>>> 
>> 
>> Because the only way to build massive systems of interoperating
>> components is to establish archaic APIs and pray that you don't have
>> to break them.  This has gone poorly for every Linux distribution that
>> has tried.  See Jed's earlier comments about the Linux Standard Base:
>> http://www.linuxfoundation.org/collaborate/workgroups/lsb
>> 
>>>   Since the #include <petsc/petscvec.h> can handle the includes, it all comes down to the single -llibpetsc issue of working without requiring a -L flag. We could put the library in prefix/lib/petsc and then make a link back up to the prefix/lib directory.
>>> 
>> 
>> I see why this might be more aesthetic, but it's not the way things
>> are done, so you shouldn't do it.
>> 
>>>   We could also put put everything in prefix/petsc and then scatter the needed links in for the standard locations.
>>> 
>> 
>> No.  This is the package manager's job.
>> 
>>>   Has anyone in the gnu/linux world came out with viable replacements for the /include  /lib  mess they have now that allows all the parts of a library package to go together rather than being spewed in several directories?
>> 
>> This is why package managers exist.  If you play by the standard
>> prefix rules, they can deal with the joys of managing multiple
>> versions of your software.  If your software breaks these rules, you
>> don't motivate anybody to help get your software portably installed.
>> 
>> A