Slashdot Mirror


Should You Pre-Compile Binaries or Roll Your Own?

Jane Walker writes "The completion of pre-compiled packages and maximizing machine performance are two powerful incentives for Windows admins to use Linux and compile an OSS package." TechTarget has an article taking a look at some of the "why" behind rolling your own. What preferences have other Slashdot users developed, and why?

4 of 301 comments (clear)

  1. Gentoo? by corychristison · · Score: 5, Informative

    I feel that Gentoo Linux offers the best of both worlds, with their ebuilds. :-)

    1. Re:Gentoo? by EnigmaticSource · · Score: 5, Informative

      Well, as a Gentoo user, I'll tell you my personal reasons for using portage (speed isn't one of them).


      1.) Maintainability: I don't have to fiddle with 30+ binary dependencies when I upgrade a package, nor do I worry about having multiple library versions within the same major release


      2.) Simplicity: Well, it's not particularly simple (in fact, until 2006.1 it was a nightmare) to setup, but once everything is in line I simply don't have to worry about be various `gotchas` of any given package, it's all been abstracted away


      3.) USE Flags: An extension of the above, USE is like a homogeneous ./configure, no more silly --without-some-foo flags, or include paths that I forgot about 30 seconds after I installed a library. It's not so much about making things optional (at least in the real world) but more about keeping things simple (I specify all of my USE flags at install time, and simply add them to my list when new ones are created)


      4.) Lack of Binary Packages: As an old slackware user, I got used to not finding package `foo` as a .tbz and having to deal with RPMs that are/were broken and took more time to install properly than to compile. By using a source based distribution, if I have a one-off or patched library I don't have to worry about will feature X work or why Sodipodi crashes, because whatever version I have is (within reason) now the native version to the application


      Hope that helps

      --
      The Geek in Black
      I know my BCD's (when I'm Sober)
    2. Re:Gentoo? by RedWizzard · · Score: 5, Informative
      As for the first I think that compiling from source may well give you a speedup.
      Forget performance, it's a red herring. If you're considering looking at Gentoo for performance reasons you'll probably be disapointed. Increased performance is a minor side effect at best and more likely to be completely undetectable. Gentoo is about configurability and control, not performance.
      Next we have USE flags. These do strike me as an insanely useful thing. But I have one niggling little doubt: I suspect they only work for code that supports it. e.g. project foo has optional support for libbar. If the upstream/original code doesn't have a feature marked as optional I don't imagine the Gentoo people would rework it to strip it out.

      So the ability to remove things from the source must be neutered, right?

      You are right - generally USE flags rely on the upstream source having optional support for various features. So in theory it might be that very little can be removed from a given package. But in practice most OSS software is highly configurable at the source level, particularly if it is portable rather than Linux specific. The number of USE flags recognised by each package is highly variable. For example, mplayer recognises over 70 USE flags, while Firefox recognises 11.
      Finally the merging of configuration files in /etc seems useful. But I wonder if this is the correct approach. My distribution of choice, Debian, already does its utmost to preserve all configuration file changes automagically. I find it hard to understand what Gentoo does differently which makes it better.
      It puts control back into the hands of the user (which is basically the fundamental point of Gentoo). Consider a package that is adding a new config option. The Debian way will be to ignore that option, set a default for the option, and/or at best log a message that is easily missed (I don't know Debian so any inaccuracies are unintentional). Gentoo provides a complete default config that can be compared to the existing config. It allows the user to decide what changes should be made to the config. This is particularly important for packages which have extremely complex configurations (e.g. apache). There is often no way to automatically translate configuration between versions. The user really needs to look at it.
    3. Re:Gentoo? by V.+Mole · · Score: 5, Informative

      The Debian way will be to ignore that option, set a default for the option, and/or at best log a message that is easily missed (I don't know Debian so any inaccuracies are unintentional). Gentoo provides a complete default config that can be compared to the existing config.

      Nope, that's not the "Debian way" (at least as I, long-time Debian user/developer, see it). Debian provides a default config file (or files). When the package is upgraded, if the distributed config file is changed (new option, or new value for old option), then one of two things happens:

      1. If the user has NOT changed their local version, just upgrade to the new distributed default. The assumption is if they were happy with the old default, they'll be happy with the new ones. This covers the vast majority of cases.
      2. If the user has changed their local version, offer them the chance to look at the diff, and then either overwrite, don't overwrite, or shell it and deal with by hand. If they choose not to overwrite, then the distributed default is left alongside the real config file for later perusal/integration.
      While there are a few obscure corners in the implementation, and individual developers can make mistakes, it mostly works pretty well. The net effect sounds pretty much like your description of the Gentoo way: don't overwrite local changes, and give them something to diff against.