On Sat, May 5, 2012 at 7:15 PM, Dimitry T <[email protected]> wrote:
> After a long reading I am still confused. On OpenBSD FAQ recommend to use > packages, most users speak the same, but some speak that it is safer to > compile programs from ports and then programs have better performance. Did > I get the better performance of the program on my hardware if i compile > that program on my hardware from ports? I try to compare md5 of package > compiled from ports with package downloaded from package server, and values > b b do not match. Surely I wrong somewhere, but I would like someone to > explain me packages vs ports > Oh, my. You've entered a world of exciting pain learning this stuff. Enjoy the adventure, and I do hope you have a "safe word" so you can step back if you've had enough. First: md5sums are unlikely to match unless the program is very simple and the build environment very tightly defined. Simple compilation options, such as "gcc -O2" or "gcc -O3" are likely to modify the contents in subtle and performance modifying ways. Slightly differnt libraries or source code with patches applied, or strings such as the building hosts hostname or date of the build are sometimes incorporated in the compiled object, or the "$Id$" from CVS, RCS, or Subversion source code management is sometimes included as well. That is why I like to use chroot cages for build environments: I can use a really well-definied encironment, and be sure I've identified all the dependencies, rather than working in a more fluid development environment that may have had local, critical components updated that are unlikely to be found in a production environment. The pre-compiled packages are usually much easier, and much safer, to work with because someone familiar with the standards has become familiar with the basic requirements. They've also often asembled and built the requirements that go with it, and submitted them as well, and they are reported to package management and can be relied on and updated somewhat automatically as issues are published and repaired upstream. And they often play better with others, not overlapping with or replaced by updates of base packages that happen to use the same files. (Perl. oh, dear lord, Perl, with modules moving into and out of the main tarball over time....) This takes work, because many tools do not have standard build architectures. Compare OpenBSD kernels, sendmail, Apache, Perl, PHP, and Maven to see just how wacky it can get. For enormous fun, take a look at how gcc is built, in order to build the compiler, build the compiler with the compiler, rebuild the compiler with the new compiler, etc. to make sure that what the compile builds with itself matches between builds and is predictable. But many people like to have the intimate familiarity with and tune things for their particular environment. For example, there are *gazilliohn* of Perl and PHP modules which are not in the main OS repositories for *any* OS because they proliferate and change so fast. And somebody has to *write* the packaged tools when updates occur. I do a ton of work with Subversion upsteam, and try to keep an eye on the Subversion/SSH authentication tools and features., If you can spare the time and contribute, publishing patches and reporting bugs for building and managing both OpenBSD and useful 3rd party software, please do!! I've been doing this for.... holy hopping pogo sticks, 24 years. (BSD 4.2 in my first job.). Last, you will also have the opportunity to *tune* your features. Kernels and daemons can often benefit in subtle performance from updates and compilatoin options, but you can also break things in subtle ways from untested options, so it's a real tradeoff. It's much valued work by good developers. I also had some open source and freeware license comments, but I'll just say "check the licenses on what you build locally". I still remember with loathing the weird "Dan J. Bernstein" licenses on daemontools and djbdns, where you couldn't publish modified source code or binaries built from it, only source and patch files.
