Dear FreeSurfer developers, I would like to pick up on this elderly theme by wondering:
Would you be philosophically opposed against patches/pull requests which introduce dynamic linking for freesurfer build? Would anyone from the FreeSurfer team be interested to pursue such an effort? The idea is to try to reincarnate the effort of pulling functionality/binary-code which is now spread/duplicated across many distributed statically linked binaries, into a set of (internal) libraries. Benefits IMHO are numerous, starting from - smaller binary distribution - consistency (replacing one patched binary copy but leaving the other copies which linked statically unpatched) - ... Cheers, On Sun, 21 Feb 2016, Yaroslav Halchenko wrote: > On Sun, 21 Feb 2016, zkauf...@nmr.mgh.harvard.edu wrote: > > This topic gets brought up occasionally and their are valid arguments > > to both sides. One reason we have hesitated to use dynamic libs is the > > partly due to freesurfers long release cycle (all subjects that are > > part of a study need to be performed all on the same version). This > > long release cycle sometimes necessitates fixes to a particular binary > > in the stream, which users are then free to use. Although this is a > > less than ideal release strategy, it is the reality of the situation. > > And if we linked against dynamic libs than any time a binary was > > updated, ALL those libs, would need to be updated, > > which in turn would affect all binaries which link against them. > AFAIK it is exactly the other way around ;) Please correct me if I > am wrong. > With static inclusion of code, if the fix is in the code which is shared > among binaries, you will need to provide new copies for all those > effected binaries so they come with new copies of that code. Only if > the fix is within code specific to the binary -- only that binary > indeed. > In case if that 'fixed' code being a part of an internal dynamic library > [*], you would need to provide only a copy of that library, and binaries > linked against it can stay original since they just dynamically load > that code from the library and do not carry broken code. If it > is a fix to the code specific to the binary -- situation is just the > same as with static linking. > [*] under assumption that the fix doesn't entail changing API/ABI. In > case if those change -- indeed adjustment/rebuild of dependent binaries > would be necessary. BUT such situations come much less often than just > fixes of the code without changing data structures and function > interfaces. And in your case, even if that happens, it is just a matter > again of uploading all those affected binaries (as you would do with > static linking) + the dynamic library. And again, I think, even if a > binary uses some functionality of the library, but not a 'fixed' > function, it could as well stay without 'update' while linking to > the new dyn library. > That is the primary reason why Linux distributions rely on dynamic > libraries and reusing system-wide installed artifacts (e.g. java script > "libraries", Python modules, etc) as often as possible -- to fix a > vulnerability in the code of a core library/artifact requires just > upload of the fixed library/artifact without rebuilding all binaries (or > replacing all copies of artifacts) which could have potentially absorbed > that code via static "linking". Could you imagine the chaos if > libc was statically included in every binary and then security fix > was needed to propagate to all 30,000 packages? ;) > > I suppose only newly released binaries could be static, > > but their may be unintended consequences that Im not thinking of at the > > moment. > > Im open to conversing about this, and appreciate any constructive feedback > > on improving our release model. > Well -- I can't recommend anything new really, and just repeat my > whining: modularize just a bit (e.g. separate package for heavy data > pieces which rarely change + dynamic libraries, you already have that > bundle of externals you could deploy and reuse), and then you can > easily release not just "binary patches" but entire bugfix releases of > the codebase since they will probably be a fraction of the current size. > That is AFAIK how anything is released these days really ;) > NB. somewhat crazier scheme could be -- release binaries via git-annex, > with upgrades constituting "git pull; git annex get . " ;) It > would become especially efficient in case of dynamic internal > libraries, since fetching a bugfix release would be to fetch only > affected dynamic libraries and not all affected binaries linking against > them. > > But I would prefer to take the > > conversation offline as it gets overly technical rather quick. > ah (I was replying inline without reading all the way till the > end, sorry ;)), then this will be the last one then on this mailing list > in this series. Could there may be a freesurfer-devel mailing list to > discuss such topics? ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
