Hi mich...@orlitzky.com writes:
> * Bundling libraries are terrible for security. I should be able to > open a PNG in code that I myself wrote, without worrying about a > buffer overflow. My distro patches these holes immediately. Sage > doesn't, there's just not enough manpower. > > * It's wasted thousands of hours of developer time. Look at the > ChangeLog for a major release -- how many of the tickets are math? > How many are a result of trying to bootstrap the universe? > > * It doesn't work. At the boundary between stuff-we-build and stuff- > the-system-provides, things break. Sage uses the dvipng built > against my system's gd, but runs it against the one bundled with > sage. *crash* Guess I can't plot anything today. > > * Distributions won't touch it. Linux users should be our bread and > butter, but they can't install it. I should be able to tell people > "just type 'yum install sage'", but instead, I have to teach them > how to initiate a big bang the result of which, after millions of > seconds, might look like sage. Then they run into the aforementioned > problems anyway. And some more points: * If sage started to use what is available on the system, instead of duplicating effort, probably more linux distros would start packaging it. * Depending on things instead of bundling them is the standard practice. I'd even say that the "batteries included" policy is kind of arrogant. Sage can pull this off only because it is virtually the only software package doing it. If every software depending on git, or zlib or python shipped their own version, things would get unbearable pretty fast. In this sense sage is not being a good neighbour in the system. * System git and sage git share resources, like the main config file at ~/.gitconfig. What if it becomes incompatible between system and sage's git versions? The same goes for any other lib or standard tool sage uses. Embedding the tools within sage looks like shifting away the "different versions problem" from developer hands to the user. I realize sage might have kind of unique needs to patch specific software, and might have hard dependencies on specific versions of certain scientific libraries. But I believe this policy of bundling everything should not be the rule, but an exception. Even more so for stable standard stuff like git, zlib, etc. If sage finds a bug to a package, it should first try fixing it upstream, then try to work-around it, and as a last resort, bundle a patched version. That is the usual way open-source communities operate. An other issue is having a "batteries included" tarball around. That may be nice for some, I understand that, but it shouldn't be the only option. Also, I think sage gets the focus wrong on this issue. Sage should aim at making the code base as adaptable as possible to different environments, and software versions, instead of trying to carefully control the environment. In the long run that should ease sage's own development! for instance when upgrading bundled python. It is a matter of being aware of what is backwards compatible and what isn't when writing code. For instance, always use '--porcelain' versions of git commands, etc. As I said, it may not be possible to be that adaptable for some libs (so then bundle them!). But for a non-negligible amount of software sage depends on, I'm certain it is possible and mostly painless in the long run to be more adaptable. Autotools is a mature and portable piece of software which aims to do just that, to adapt the source tree to the particularities of the build environment before building. A proof that this can be achieved is that virtually every single open source software except sage manages to do it! Sage is an awesome piece of software, but is not that special to be different from everybody else in that respect. What seems kind of scary is the amount of work needed to do that, but it seems Felix has already walked a long way in that direction, isn't it? Abdó Roig. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
