Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems Technology BSD

OpenBSD Ports and Packages Explained 28

Posted by Hemos from the always-good-to-learn-more dept.
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."
This discussion has been archived. No new comments can be posted.

OpenBSD Ports and Packages Explained More

OpenBSD Ports and Packages Explained

Comments Filter:

  • yay for ports! (Score:3, Insightful)

    by Leroy_Brown242 ( 683141 ) on Monday June 27, 2005 @08:20AM (#12919594) Homepage Journal
    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.
  • We recently transitioned some of our smaller servers from Debian to NetBSD. Indeed, the BSD packages and ports system is fantastic. It allowed us to get our new servers up and running in no time. Kudos to all who have perfected the BSD ports and packages system.

  • Another Newb (Score:5, Interesting)

    by mugnyte ( 203225 ) on Monday June 27, 2005 @01:05PM (#12922657) Journal

    Like some ./ readers, I got the OpenBSD image when 3.7 was released just this year. I dropped it onto an older box and have been exploring ever since. I used the packages for several items (like Gnome) but ports for others (Postgresql 8).

    I've been very happy with several concepts:

    - The dependency trees are spot-on and very automated. Correct versions and complete coverage.
    - The ability to undo or rollback a package is smooth (like when I took a 7.x Postgres package and pkg_delete'd it to try the port)
    - The published docs, man pages and organization of the system is superb. I picked up "Absolute OpenBSD" and "BSD Hacks" and have been toured confidently around the system by these and the man pages they point to.
    - The post-install notes are a great help.

    For me, it's a great "warm and fuzzy" to gather the documentation sources into a list and be able to dive down rabbit holes for long periods without feeling like a flea market is on my box. Cheers to the BSD folks, especially the package maintainers.

  • Why Perl? (Score:3, Interesting)

    by marcovje ( 205102 ) on Tuesday June 28, 2005 @04:12AM (#12929591)

    I hate having to have install Perl, Ruby and Python (m4?) for all kinds of trivial stuff. (or have it in the base systems as more and more systems do).

    First, these scripting languages are slow. People that don't agree, please compile X, and watch the font making in Perl. It eats more time than actually compiling X

    Second, every stupid package uses another one, so you end up with a bunch of them.

    Third, it requires more languages to learn to access the system. Moreover, the amount of languages that can interface to Perl modules is significantly lower than the amount that can interface to C (virtually all). This can also be seen in the article: the perl backend is unused, everybody works around in shellscript.

    The first two could be solved by e.g. limiting the tools to a perl subset that is compilable to C, and not use too many modules.

    The third is harder to solve. Best would be to code the package system in C, and have a C callable library. Or maybe using 2C kind of stuff.

    • Re:Why Perl? (Score:5, Insightful)

      by Anonymous Coward on Tuesday June 28, 2005 @05:04AM (#12929744)
      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 ?

    • Re:Why Perl? (Score:1, Insightful)

      by Anonymous Coward
      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 fi

      • "The right tool " mantra works both ways. Both from the developer perspective and from user perspective.

        The dependancies (install a few apps, and you have 100MB on various script languages, and extra modules) and speed are the trouble.

        I'm talking about slow from the viewpoint of a recent Athlon64. Even if it gets twice as fast in the two next years, it is still annoyingly slow.

        I have had the trouble to be forced to program in Perl, to fix some predecessors code. My conclusion was that while it was nice t
    • is just a cvs diff away. where are your diffs?

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (7) Well, it's an excellent idea, but it would make the compilers too hard to write.

Close