Slashdot Mirror
OpenBSD Ports and Packages Explained
jpkunst writes "As reported on undeadly.org: an interesting interview with OpenBSD developer Marc Espie about the internals of and the philosophy behind the OpenBSD ports and packages system."
← Back to Stories (view on slashdot.org)
I'm in love with ports. It just makes things so damned easy.
I'd venture to say that without ports on FreeBSD, I'd never have learned so much.
I've always thought that with a little more polishing, it could be good enough for even my mom to use.
Pretty Pictures!
wtf are you on about ?
they are source code because they need to support 11 architectures and you might want different options to the pre-compiled binaries
nearly *all* the ports have binary packages for your particular source port, if you stick with GENERIC make options
you can even install them from ftp !
# ftp -a ftp.openbsd.org
ftp> cd pub/OpenBSD/$version/packages/$arch
ftp> get gcc-3.3.2.tgz "|pkg_add"
Personally I prefer OpenBSDs ports to FreeBSDs because OpenBSD will create the binary as a package so you can compile with your options once and install the package on different machines without re-compiling on each box
even better is that *some* of the optional parts also have pre-compiled packages
I was rather pleased to find the rc shell pre-compiled with readline support
# ftp -a ftp.openbsd.org
ftp> cd pub/OpenBSD/$version/packages/$arch
ftp> get rc-1.6-readline.tgz "|pkg_add"
how does that makes me a whacko ?
HIBT ?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
OpenBSD installs into a "fake root" (you need root privs for this), and makes a package based upon this.
A good reason for perl is that it *works*.
A second good reason is that it's already part of the OpenBSD base install.
A third good reason is that the old package system was in C, and was downright broken.
A fourth good reason is that the current perl system is over 200K of perl code. Try rewriting that in C, and see how big it gets.
Finally, maybe perl isn't that slow... I've rewritten all kind of C/shell code in perl, and it consistently is faster than the old C code. Why ? because I can use smarter algorithms, and better caching. The package system of OpenBSD is another example of the same. Dude, the perl version of pkg_add is about twice as fast as the old perl version.
As far as X font building goes, you can't really know if it's slow because perl is, or if it's slow because there's a large amount of stuff going on. Look at the sizes involved, look how much data is processed, realize that usually, everything gets compressed with gzip.
Now, you can think all you want that it's slow because perl is slow. Well, I've got at least two other reasons for it to be slow.
What you have is an opinion, and not really well informed. How about backing it with some actual facts ?
I think you've both missed the boat on this one. Development of a Linux kernel vs. the BSD system is different in exactly those regards which I've emphasized in italics.
Theo et. al. have complete control of the kernel all the way down to the user-land. In Linux, however, userland tools are GNU (hence the rage over Linux and GNU/Linux naming) and maintained closely, but separately. That means changes have to be rippled rather than made at once, atomically.
The effect is that it is more likely you will see a shipped distro with broken tools due to the constant changes, or that you can become inconsistent with kernel version and tool version. In the recent 2.4 -> 2.6 changeover there were several kernel/user tool packages that changed drastically, making it very difficult to maintain a system with both kernels.
Also, don't be fooled by the word "refactoring." A refactoring is a change of interface or architecture, and by definition breaks an interface contract - whether that is a public or private contract only influences the scope of the breakage. Theo talks a lot about making and rolling out comprehensive fixes quickly, and describes refactoring as doable "when necessary." The Linux quote, OTOH, describes constant refactoring as a nuisance and a hindrance to Linux stability.
I believe this is the point the OP may be trying to make with these two quotes.
Use the right tool for the job. If you think that it is slow, stop and think beyond, not only about speed. Perl, python, ruby and so on, they all help reduce complexity, costs and time needed to develop software.
;)
Computing power are getting bigger every day, and cheaper too, so the speed penalties are not that bad.
These languages all help you to express your algorithms easier than with C.
Try to write text processing programs with C, then try to write the same program using Perl, compare it. I bet youll find perl much easier to program on.
however, if it you really want to, you can write your own tools, using your language of choice