OpenBSD Journal

How OpenBSD is made

Contributed by johan on from the stories-from-the-factory-floor dept.

Mitja Muženič submitted a nice story about the OpenBSD release cycle, here it is...

With every new release more and more new users are attracted to Puffy and invariably there are questions regarding the OpenBSD release cycle and process. Although this is already well documented in the FAQ, let's take a look at what it takes to bring a new release to life.

Please read on for the rest of Mitja's story:

The development cycle starts immediately after the last release (actually even a bit earlier, as we'll see). The main storage of all the development work is the project's central source code repository, CVS. The developers commit their work for safekeeping and distribution to the CVS repository and the resulting code is referred to as OpenBSD-current. It is here that all the development work is done, -current is the bleeding edge. It is also a moving target, with an average of 40 commits per day, and the changes committed can range from fairly trivial to very complex and widespread. Nevertheless, the development source tree is never intentionally broken; if a committed change breaks the compilation, it is immediately fixed or reverted to a working state. Why? The reason is simple: on majority of supported platforms the entire system gets through a mock release process every few days to make sure everything builds correctly. The results of these test builds are called snapshots and are an important part of the overall testing process. Snapshots are also a great way of following the development without getting your hands too dirty - by doing a simple binary upgrade from snapshot to snapshot you can get a preview of what the next release will contain and through bug reports help developers with their work.

OpenBSD has two releases per year, May and November 1st - the four months following a release are dedicated to development and the final two months in each cycle allow for the stabilization of the code and the actual build of the release. Typically the bulk of the major changes happen early in the release cycle, often during a hackathon, so there is enough time for the addition of new features and various improvements. Around mid-cycle the work turns towards less glamorous bug fixing, cleanup and general stabilization the code, until some 10 weeks before the release date the softlock goes in effect. This is a time for finishing touches on the soon-to-be-finalized code, the commits are carefully scrutinized and slowing down to a trickle until the full lock of the tree is reached - nothing more goes in. At that point, the code is frozen and the releases for all the architectures are built and verified. Finally, the release files are sent to the CD manufacturing plant a good month before the release. The source tree is at this point unlocked again and the developers eagerly start a new cycle of committing - by the time of the actual release, -current and the associated snapshots are already well ahead running at full steam.

As the release day approaches, the fanout FTP mirrors receive the full release builds and the CD sets arrive from the manufacturing plant to the main OpenBSD distributors. The CD sets are often early, so they are shipped ahead of the release date to those that have placed preorders - what better way to reward those who by preordering help cover the cost of making the CD sets?

At last, the release day comes with the traditional announcement on the mailing lists, unveiling of the new release's folder on the FTP mirrors and official publishing of the CD sets. It does not end here though - in CVS, a new branch named -stable is created and for the next 12 months all the security and reliability fixes from -current will be backported to the -stable version of the just released code.

At the moment of this writing we are nearing the OpenBSD 4.4 release date and the preorders are already open. So if you want to help funding this release and the work for future ones, place your preorder now (international, europe)!

(Comments are closed)


Comments
  1. By Chris (139.70.118.149) on

    Thanks for the write up. :)

  2. By dingo (207.75.146.125) dingo@1984.ws on

    are snapshots ever created with code that is not yet in cvs sometimes?

    Comments
    1. By Anonymous Coward (71.65.207.144) on

      > are snapshots ever created with code that is not yet in cvs sometimes?

      Yep, this happens often. In fact, this is one of the reasons why the recommended practice is to test snapshots rather than simply downloading -current source and building it yourself. Another being that its simply easier / faster to do a binary upgrade! :)

      Comments
      1. By Anonymous Coward (64.182.159.1) on

        > > are snapshots ever created with code that is not yet in cvs sometimes?
        >
        > Yep, this happens often. In fact, this is one of the reasons why the recommended practice is to test snapshots rather than simply downloading -current source and building it yourself. Another being that its simply easier / faster to do a binary upgrade! :)
        >
        >

        But doesn't that mean that in case Theos house burns down (wich I wont hope) those changes are lost because mirrors would not have the chance to mirror these because they are not in the CVS?

        Theos house has a huge power consumption and cables get older too.
        So what happens in a worst case scenario? :(

        Comments
        1. By henning (130.237.95.167) on

          > > > are snapshots ever created with code that is not yet in cvs sometimes?
          > >
          > > Yep, this happens often. In fact, this is one of the reasons why the recommended practice is to test snapshots rather than simply downloading -current source and building it yourself. Another being that its simply easier / faster to do a binary upgrade! :)
          > >
          > >
          >
          > But doesn't that mean that in case Theos house burns down (wich I wont hope) those changes are lost because mirrors would not have the chance to mirror these because they are not in the CVS?
          >
          > Theos house has a huge power consumption and cables get older too.
          > So what happens in a worst case scenario? :(

          hint: those changes come from somewhere, they don't magically appear on cvs out of nowhere.
          next hint: they have been mailed around before, usually.

        2. By Ray (167.206.66.94) ray@ on http://cyth.net/~ray/

          At that point we would be worrying about other things.

        3. By Anonymous Coward (70.75.19.130) on

          > > > are snapshots ever created with code that is not yet in cvs sometimes?
          > >
          > > Yep, this happens often. In fact, this is one of the reasons why the recommended practice is to test snapshots rather than simply downloading -current source and building it yourself. Another being that its simply easier / faster to do a binary upgrade! :)
          > >
          > >
          >
          > But doesn't that mean that in case Theos house burns down (wich I wont hope) those changes are lost because mirrors would not have the chance to mirror these because they are not in the CVS?
          >
          > Theos house has a huge power consumption and cables get older too.
          > So what happens in a worst case scenario? :(

          If Theo's house burns down, there are bigger concerns than losing a few diffs. Be realistic.

          And for those who care, we are in the process of upgrading things like the utility feeder. You're in good hands... Not everyone involved in the project is a software guy.

          --The P.Eng. who also volunteers his time

    2. By Anonymous Coward (74.62.155.33) on

      > are snapshots ever created with code that is not yet in cvs sometimes?

      Yes, I think they do -- apparently.

      So much for "Full disclosure", isn't it rather deceptive? people are assuming they're getting a binary snapshot of -CURRENT but they're actually guinea pigs for code which they are unaware they are running.

      Please make this "super secret" developer tree available, it most definately needs to be audited by the public... capeshe?

      Comments
      1. By Tobias Weingartner (68.151.168.15) on

        >
        > So much for "Full disclosure", isn't it rather deceptive? people are
        > assuming they're getting a binary snapshot of -CURRENT but they're
        > actually guinea pigs for code which they are unaware they are running.
        >
        > Please make this "super secret" developer tree available, it most
        > definately needs to be audited by the public... capeshe?

        Hahahahaha, you crack me up. Let's get this straight. I send out a
        diff that was asked for. Actually I worked on the code for well over
        a month. After I deem it ready, I send out the diff to tech@ and
        misc@. And I wait, and I wait.

        I get 3 (yes that is a THREE) tests. So, out of the outcry of well
        over a couple hundred people that all said they *NEEDED* a feature,
        only 3 bothered to test.

        A snapshot is a build of a current development tree, with or without
        other current changes/diffs. "A current development tree", not
        "a current cvs tree". There is a difference.

        Oh, and if you think you're getting access to *MY* private development
        tree, you've got to be bloody nuts. You don't even test the diffs
        when they are made available....

        -Toby.

        Comments
        1. By Anonymous Coward (85.25.152.185) on

          > >
          > > So much for "Full disclosure", isn't it rather deceptive? people are
          > > assuming they're getting a binary snapshot of -CURRENT but they're
          > > actually guinea pigs for code which they are unaware they are running.
          > >
          > > Please make this "super secret" developer tree available, it most
          > > definately needs to be audited by the public... capeshe?
          >
          > Hahahahaha, you crack me up. Let's get this straight. I send out a
          > diff that was asked for. Actually I worked on the code for well over
          > a month. After I deem it ready, I send out the diff to tech@ and
          > misc@. And I wait, and I wait.
          >
          > I get 3 (yes that is a THREE) tests. So, out of the outcry of well
          > over a couple hundred people that all said they *NEEDED* a feature,
          > only 3 bothered to test.
          >
          > A snapshot is a build of a current development tree, with or without
          > other current changes/diffs. "A current development tree", not
          > "a current cvs tree". There is a difference.
          >
          > Oh, and if you think you're getting access to *MY* private development
          > tree, you've got to be bloody nuts. You don't even test the diffs
          > when they are made available....
          >
          > -Toby.
          >
          >

          Maybe such things hsould get announced at undeadly too with a call for testers added.

          Comments
          1. By Anonymous Coward (124.179.45.28) on

            >
            > Maybe such things hsould get announced at undeadly too with a call for testers added.

            They're announced on mailing lists. If you really want a web interface, try marc.info

      2. By Otto Moerbeek (otto) on http://www.drijf.net

        We never made is a secret that snapshots sometimes contain uncommitted diffs. Sometimes this is needed to get wide test coverage. Often the diffs are published on e.g. tech@

        If you don't like this process that's fine, you can always run -stable or -current which have published source trees. But this helps OpenBSD less --compared to running snaps-- since bugs get caught later. In the end that will mean lower quality. The alternative of committing not widely tested diffs to -current is very unattractive too.

        Comments
        1. By Anonymous Coward (93.80.216.244) on

          > We never made is a secret that snapshots sometimes contain uncommitted diffs. Sometimes this is needed to get wide test coverage. Often the diffs are published on e.g. tech@
          >
          > If you don't like this process that's fine, you can always run -stable or -current which have published source trees. But this helps OpenBSD less --compared to running snaps-- since bugs get caught later. In the end that will mean lower quality. The alternative of committing not widely tested diffs to -current is very unattractive too.

          So for the good of the project, we are supposed to run blobs? OK, fine, but who decides what uncommitted code goes in, and that I'm supposed to run without knowing? (I hope questioning is OK.)

          Comments
          1. By Anonymous Coward (128.171.90.200) on

            > So for the good of the project, we are supposed to run blobs? OK, fine, but who decides what uncommitted code goes in, and that I'm supposed to run without knowing? (I hope questioning is OK.)

            What do you mean "run blobs" ?

            How is a precompiled binary release different from a precompiled binary snapshot in this regard ?

            Comments
            1. By Anonymous Coward (208.43.127.247) on

              > What do you mean "run blobs" ?

              It is an image built with parts unknown to the general public and which may be unavailable to the user (like a snapshot built with a diff that has not been sent to tech@, for example). Therefore it is a blob.

              > How is a precompiled binary release different from a precompiled binary snapshot in this regard ?

              The snapshot can have code and/or different functionalities than those in the tree.

              Comments
              1. By Anonymous Coward (128.171.90.200) on

                Binaries are always an unknown, if in doubt build from source.

                Comments
                1. By Anonymous Coward (166.70.207.2) on

                  > Binaries are always an unknown, if in doubt build from source.

                  You miss the point entirely. Even if binaries are always "an unknown" (as you said), at least there should be a PUBLICALLY AVAILABLE SOURCE TREE AS A REFERENCE. In this case, there is NONE. The project is assuringly having users run with code they DON'T KNOW ABOUT and CANNOT have access to.

                  Comments
                  1. By mk (193.128.72.68) on

                    > > Binaries are always an unknown, if in doubt build from source.
                    >
                    > You miss the point entirely. Even if binaries are always "an unknown" (as you said), at least there should be a PUBLICALLY AVAILABLE SOURCE TREE AS A REFERENCE. In this case, there is NONE. The project is assuringly having users run with code they DON'T KNOW ABOUT and CANNOT have access to.

                    We could just as well put up a cvs repository that people could build from themselves, but then they'd still need a build environment to bootstrap from, and this means we'd have to give you binaries. If you don't trust the software we give you, don't use it.

                    Comments
                    1. By Anonymous Coward (81.169.183.122) on

                      > We could just as well put up a cvs repository that people could build from themselves, but then they'd still need a build environment to bootstrap from, and this means we'd have to give you binaries. If you don't trust the software we give you, don't use it.

                      "We are talking about two different things here. One is trusting that a random image I fetch was built with pristine sources of a given project tree. The other, completely different, is the project itself stating and encouraging its users to run with something built out of sources unknown."

                      Comments
                      1. By Anonymous Coward (70.66.70.40) on

                        WOW look at you go. Different ip's and some random rant that nobody cares about but you...

          2. By Paul 'WEiRD' de Weerd (weerd) on http://www.weirdnet.nl/openbsd/

            > So for the good of the project, we are supposed to run blobs? OK, fine, but who decides what uncommitted code goes in, and that I'm supposed to run without knowing? (I hope questioning is OK.)

            I suppose the person building the snapshot decides what code goes in (seems quite obvious to me).

            But, just for my understanding, even if no uncommitted code goes in, how exactly do you know what you are running when using snapshots ? Are you telling us that you what(1) your entire system to find the last commit in the snap ?

            Asking questions is OK, but you'll have to make at least some sense.

            Comments
            1. By Anonymous Coward (85.25.151.22) on

              > I suppose the person building the snapshot decides what code goes in (seems quite obvious to me).

              So it is up to whoever types "make" to know what patches the OpenBSD snapshot is going to ship with? Come on, that is ridiculous!

              > But, just for my understanding, even if no uncommitted code goes in, how exactly do you know what you are running when using snapshots ? Are you telling us that you what(1) your entire system to find the last commit in the snap ?

              We are talking about two different things here. One is trusting that a random image I fetch was built with pristine sources of a given project tree. The other, completely different, is the project itself stating and encouraging its users to run with something built out of sources unknown.

              > Asking questions is OK, but you'll have to make at least some sense.

              That will be a pleasure. Now, if you could at least try to be polite in your answers, things will be even better.

              Comments
              1. By Damien Miller (djm) on http://www.mindrot.org/~djm/

                > > I suppose the person building the snapshot decides what code
                > goes in (seems quite obvious to me).
                >
                > So it is up to whoever types "make" to know what patches the OpenBSD
                > snapshot is going to ship with? Come on, that is ridiculous!

                Having a release manager decide on which patches to include is not ridiculous. Anyway, if you don't like it then don't use snapshots - nobody is forcing you to.

                Comments
                1. By Anonymous Coward (85.25.135.137) on

                  > Having a release manager decide on which patches to include is not ridiculous.

                  First it was "the guy that does the builds", now it is the "release manager". It is getting clear that it is all in the arbitrary hands of Theo. No big news there, but I just wanted to make sure. After all, there is always hope that this thing called "democracy" will one day bloom in our favorite operating system.

                  > Anyway, if you don't like it then don't use snapshots - nobody is forcing you to.

                  Of course, that is what I and any sensible OpenBSD user out there will do.
                  But that doesn't stop me from trying to understand and expose to the public the reasons behind the processes that implement OpenBSD.

                  I don't use a plethora of things out there. But still, I would say I understand (or at least I have a very strong suspicion about) how many of these things work, and why they were made that way.

                  Comments
                  1. By Anonymous Coward (128.171.90.200) on

                    So the "release manager" is not "the guy who does the builds" ?

                    What sort of "democracy" are you expecting ?

                    What sort of conspiracy do you believe OpenBSD to be ?

                    Comments
                    1. By Anonymous Coward (85.25.151.22) on

                      > So the "release manager" is not "the guy who does the builds" ?

                      Of course not. The release manager manages the release. The snapshot builder builds the snapshots.

                      > What sort of "democracy" are you expecting ?

                      One where the power is not in a single man's hands.

                      > What sort of conspiracy do you believe OpenBSD to be ?

                      It is not a conspiracy. It is a theocracy.

                      Comments
                      1. By Anonymous Coward (87.118.101.102) on

                        > > So the "release manager" is not "the guy who does the builds" ?
                        >
                        > Of course not. The release manager manages the release. The snapshot builder builds the snapshots.
                        >
                        > > What sort of "democracy" are you expecting ?
                        >
                        > One where the power is not in a single man's hands.
                        >
                        > > What sort of conspiracy do you believe OpenBSD to be ?
                        >
                        > It is not a conspiracy. It is a theocracy.

                        But that is not my point here. I'm not questioning the way the project is managed. Who am I, anyway?

                        What I am trying to do, however, is to understand why the processes that constitute OpenBSD are the way they are. And if that cannot be seemingly transparent to us the users, or at least explained in a rational way, then yes, it is a fucking conspiracy.

                        Comments
                        1. By mk (193.128.72.68) on

                          > What I am trying to do, however, is to understand why the processes that constitute OpenBSD are the way they are. And if that cannot be seemingly transparent to us the users, or at least explained in a rational way, then yes, it is a fucking conspiracy.

                          The process is the way it is because it's what works best for us.

                          Comments
                          1. By Anonymous Coward (91.65.228.176) on

                            > The process is the way it is because it's what works best for us.

                            If that isn't a quotation from "1984" put in a humorous way, then it has to be the most ridiculous argument I have ever heard in my life.

                        2. By goodb0fh (170.22.76.10) goodb0fh@gmail.com on

                          > What I am trying to do, however, is to understand why the processes that constitute OpenBSD are the way they are. And if that cannot be seemingly transparent to us the users, or at least explained in a rational way, then yes, it is a fucking conspiracy.

                          You seem constipated. Take a pill or something.

                          In case you are new, OpenBSD has always stated that it was built by developers for the developers.

              2. By Anonymous Coward (128.171.90.200) on

                If you follow the mailing lists you often know what will be included for testing. Of course the person building the snapshot is the only person who knows *exactly* what is in there, same for release, or any other binary.

                Comments
                1. By Anonymous Coward (85.25.151.22) on

                  > If you follow the mailing lists you often know what will be included for testing. Of course the person building the snapshot is the only person who knows *exactly* what is in there, same for release, or any other binary.

                  Yes, and it is precisely because of this obvious fact (whoever builds the snapshots is the only one knowing the patches that were applied) THAT OTHER PEOPLE SHOULD BE INFORMED. In particular, the users!

                  And if you have followed OpenBSD development for a while, you know it is a FALLACY to say that everything included in the snapshots has been previously exposed to the public.

                  Comments
                  1. By Anonymous Coward (2001:4830:123a:beef:21e:8cff:fe6f:7ae3) on

                    > > If you follow the mailing lists you often know what will be included for testing. Of course the person building the snapshot is the only person who knows *exactly* what is in there, same for release, or any other binary.
                    >
                    > Yes, and it is precisely because of this obvious fact (whoever builds the snapshots is the only one knowing the patches that were applied) THAT OTHER PEOPLE SHOULD BE INFORMED. In particular, the users!
                    >
                    > And if you have followed OpenBSD development for a while, you know it is a FALLACY to say that everything included in the snapshots has been previously exposed to the public.
                    >
                    >

                    It's true that not every patch is announced before it goes in to snapshots. And perhaps it's true that people should have access to these patches for whatever reasons. However, there is simply not enough man power to create a separate branch that would handle this. It's not done simply for practical reasons. And comments regarding conspiracies are absurd and childish. If you don't like the way it's handled now, build -CURRENT yourself. And boy, you ask for politeness while yourself constantly misuse caps.

                    Comments
                    1. By Anonymous Coward (89.55.21.154) on

                      > It's true that not every patch is announced before it goes in to snapshots. And perhaps it's true that people should have access to these patches for whatever reasons. However, there is simply not enough man power to create a separate branch that would handle this. It's not done simply for practical reasons.

                      There is absolutely no need to create a separate branch or anything. It is simply a matter of making sure the diffs are made public and listed somewhere. It shouldn't take the "release manager" more than 5 minutes to do so:

                      # patch -p0 < /some/diff
                      # echo "/some/diff in" >> diffs
                      (...)
                      # mail -s "diffs of today's snapshot" tech@openbsd.org < diffs

                      > And comments regarding conspiracies are absurd and childish.

                      I fully agree. That is why I did not make any conspiracy comments in the first place. The only two times I mentioned that word were:

                      1 => To build a hypothesis over a previous commented that contained such term.
                      2 => Now.

                      > If you don't like the way it's handled now, build -CURRENT yourself.

                      Quoting a previous post:

                      Of course, that is what I and any sensible OpenBSD user out there will do.
                      But that doesn't stop me from trying to understand and expose to the public the reasons behind the processes that implement OpenBSD.

                      I don't use a plethora of things out there. But still, I would say I understand (or at least I have a very strong suspicion about) how many of these things work, and why they were made that way.

                      > And boy, you ask for politeness while yourself constantly misuse caps.

                      I am deeply sorry. I was just trying to sound like your project leader.

                      Comments
                      1. By Miod Vallat (miod) on

                        > # patch -p0 < /some/diff
                        > # echo "/some/diff in" >> diffs
                        > (...)
                        > # mail -s "diffs of today's snapshot" tech@openbsd.org < diffs

                        I think we should do this. This would be even more confusing.

                        Keep in mind that the same source tree, NFS mounted, is used to
                        build snapshots for N platforms. It is almost constantly updated,
                        with cvs up and sometimes by putting not-yet-commited diffs in it.

                        Let's suppose a diff changing /usr/bin/foo is applied. Some platforms
                        will already have built /usr/bin/foo, they won't contain the changes
                        until the next snapshot. But some others have not built /usr/bin/foo
                        yet, and will thus have it earlier.

                        Not only does it take more than 5 minutes to check the progress of
                        each build when a diff is poured in the snapshot tree, but the
                        information would simply be unusable (``the first two amd64 snapshots
                        of today did not have this diff, the third one has, but your mirror
                        does not have it yet; meanwhile, all the macppc snapshots of the
                        day have this diff, and all the i386 snapshots too; but the sparc64
                        snapshots do not have it yet, wait for tomorrow, etc, etc'').

                        The way the snapshots are built is not intended to make the snapshots
                        builds 100% reproducable. Snapshots being a moving target, this would
                        be useless.

                        Comments
                        1. By Anonymous Coward (64.182.159.1) on

                          Wow. Finally a reply based on actual arguments, and that does not sound like the "imposition of a superior truth". The greeks would be proud of you.

                          > I think we should do this. This would be even more confusing.
                          >
                          > Keep in mind that the same source tree, NFS mounted, is used to
                          > build snapshots for N platforms. It is almost constantly updated,
                          > with cvs up and sometimes by putting not-yet-commited diffs in it.

                          On a first look, having a single source tree actually makes things easier. But I see your point (next paragraph).

                          > Let's suppose a diff changing /usr/bin/foo is applied. Some platforms
                          > will already have built /usr/bin/foo, they won't contain the changes
                          > until the next snapshot. But some others have not built /usr/bin/foo
                          > yet, and will thus have it earlier.

                          Yes, that is indeed a problem, and I had no idea things worked that way. But see below for suggestions.

                          > Not only does it take more than 5 minutes to check the progress of
                          > each build when a diff is poured in the snapshot tree, but the
                          > information would simply be unusable (``the first two amd64 snapshots
                          > of today did not have this diff, the third one has, but your mirror
                          > does not have it yet; meanwhile, all the macppc snapshots of the
                          > day have this diff, and all the i386 snapshots too; but the sparc64
                          > snapshots do not have it yet, wait for tomorrow, etc, etc'').

                          Now we disagree. Although not 100% accurate, the information itself could at least serve as an _indication_ of which diffs are expected to be in the snapshots and/or should be subjected to testing. Just having this list out (along with the diffs as well) would be lovely. (And it remains a 5 minutes task!)

                          > The way the snapshots are built is not intended to make the snapshots
                          > builds 100% reproducable. Snapshots being a moving target, this would
                          > be useless.

                          Indeed, but having a way to "reproduce" a snapshot was never the point. The point is allowing users to be more conscious of the development process, and participate more. Such an attitude as the one I proposed could even have an impact on the number (or quality) of test reports. Besides giving the users more clue what to look for when testing (resulting in superior quality reports), it is way more compelling than the current approach of "here, test this blackbox" (I was going to say "blob", but that seems to stir up inner beliefs, resulting in more emotional than rational behavior).

                      2. By Marc Espie (213.41.185.88) espie@openbsd.org on

                        You have absolutely no idea what you're talking about.

                        You do not realize how much work it is to constantly churn out new binary snapshots.

                        Every supplementary activity, even as trivial as running diff and posting the result, is going to take an hour more out of each day...

                        you want Theo to keep working on OpenBSD, don't you ?

                        Stop backsit driving, if you don't like the current process, you're free to take the OpenBSD src tree and run with it.

                        That's what non-whiners with real balls are supposed to do.

                        Comments
                        1. By Anonymous Coward (90.229.130.23) on

                          > You have absolutely no idea what you're talking about.

                          No, I know very well what I'm talking about.

                          > You do not realize how much work it is to constantly churn out new binary snapshots.

                          It is precisely due to the fact that it is a lot of work that "a lot of work" + 1 won't make a difference.

                          > Every supplementary activity, even as trivial as running diff and posting the result, is going to take an hour more out of each day...

                          Really?

                          > you want Theo to keep working on OpenBSD, don't you ?

                          Quite frankly, I think the project would be better off without him. But that is my personal opinion, and it is not the point here.

                          > Stop backsit driving, if you don't like the current process, you're free to take the OpenBSD src tree and run with it.

                          Quoting a previous post:

                          Of course, that is what I and any sensible OpenBSD user out there will do.
                          But that doesn't stop me from trying to understand and expose to the public the reasons behind the processes that implement OpenBSD.

                          I don't use a plethora of things out there. But still, I would say I understand (or at least I have a very strong suspicion about) how many of these things work, and why they were made that way.

                          Comments
                          1. By Marc Espie (213.41.185.88) espie@openbsd.org on


                            > Of course, that is what I and any sensible OpenBSD user out there will do.
                            > But that doesn't stop me from trying to understand and expose to the public the reasons behind the processes that implement OpenBSD.
                            >
                            > I don't use a plethora of things out there. But still, I would say I understand (or at least I have a very strong suspicion about) how many of these things work, and why they were made that way.

                            Who are you anyways ?

                            you'd better have very good reasons to stay anonymous.

                            I call Troll !

                            Comments
                            1. By Anonymous Coward (217.114.211.20) on

                              > Who are you anyways ?

                              Who cares?

                              > you'd better have very good reasons to stay anonymous.
                              >
                              > I call Troll !

                              Anonymous = troll? Interesting way of thinking. I was going to make a link between this and the recent laws being approved in Europe. But that, yes, would be trolling.

                              Comments
                              1. By Marc Espie (213.41.185.88) espie@openbsd.org on

                                > > Who are you anyways ?
                                >
                                > Who cares?
                                >
                                > > you'd better have very good reasons to stay anonymous.
                                > >
                                > > I call Troll !
                                >
                                > Anonymous = troll? Interesting way of thinking. I was going to make a link between this and the recent laws being approved in Europe. But that, yes, would be trolling.

                                When you stay hidden in a corner, and are disparaging the effort of a whole team of people who sign by their names, and try to explain to you why things are the way they are (I saw Toby, Miod, Brad, Otto and a few others trying to reason with you), yes, you are an anonymous, insulting Troll...

                                Comments
                                1. By Anonymous Coward (24.9.198.93) on

                                  > When you stay hidden in a corner, and are disparaging the effort of a whole team of people who sign by their names, and try to explain to you why things are the way they are (I saw Toby, Miod, Brad, Otto and a few others trying to reason with you), yes, you are an anonymous, insulting Troll...

                                  I am not "disparaging" anything. I am ASKING QUESTIONS. If they insult you, then the problem must be in your end. However, feel free to ignore me. I am just a user who was trying to understand things.

                                  And if you think "real names" confere legitimacy to arguments, you have serious problems, and there is no point in discussing any further.

                                  Comments
                                  1. By Marc Espie (213.41.185.88) espie@openbsd.org on

                                    > > When you stay hidden in a corner, and are disparaging the effort of a whole team of people who sign by their names, and try to explain to you why things are the way they are (I saw Toby, Miod, Brad, Otto and a few others trying to reason with you), yes, you are an anonymous, insulting Troll...
                                    >
                                    > I am not "disparaging" anything. I am ASKING QUESTIONS. If they insult you, then the problem must be in your end. However, feel free to ignore me. I am just a user who was trying to understand things.

                                    Maybe I'm lumping several anonymous cowards together. I don't actually give a fuck.

                                    No, you guy(s) are not asking questions, you stopped that a few messages ago. We told you why what you're asking for does not happen.

                                    You don't realize, but we've talked about this several times with Theo. There are a lot of reasons why the current process is done the way it is.

                                    Asking why things are the way they are is fine.

                                    Suggesting doing things another way would be `easy' is plain offensive and insulting to us. What you you think ? that we're stupid enough we didn't think of doing things the way we think. Wooohooo! Why do you think we reacted the way we did ? been there, done that.

                                    Toby is plain tired of not getting his diffs tested.

                                    And we spent hours discussing the release process, trying to improve it.

                                    You think you can do better ? go ahead...

                                    but just commenting from the sidelines like you do is plain lame... once you've stopped asking questions, and saying `oh, but doing so and so would be so much better, and so easy', you've crossed the line from innocent question to arrogant backsit driving.

                                    No wonder we react the way we do...

                                    Comments
                                    1. By Anonymous Coward (87.118.101.102) on

                                      > No, you guy(s) are not asking questions, you stopped that a few messages ago. We told you why what you're asking for does not happen.

                                      No, you did not. With the exception of Miod Vallat, all you guys did was to say we should all build from the source ourselves.

                                      > You don't realize, but we've talked about this several times with Theo. There are a lot of reasons why the current process is done the way it is.
                                      >
                                      > Asking why things are the way they are is fine.
                                      >
                                      > Suggesting doing things another way would be `easy' is plain offensive and insulting to us. What you you think ? that we're stupid enough we didn't think of doing things the way we think. Wooohooo! Why do you think we reacted the way we did ? been there, done that.
                                      >
                                      >
                                      > Toby is plain tired of not getting his diffs tested.
                                      >
                                      > And we spent hours discussing the release process, trying to improve it.
                                      >
                                      > You think you can do better ? go ahead...

                                      Let me try. You discussed and came to the conclusion that if users do not test the diffs when they are asked to, it is a good idea to force them to do so by having the diffs in the snapshots.

                                      That actually makes sense.

                                      What I (and I guess some other trolls too) don't get is why the users are not informed of these diffs and cannot have access to them.

                                      Yes, it could scare users away from the snapshots, but keeping it a blackbox will have the same effect.

                                      > but just commenting from the sidelines like you do is plain lame... once you've stopped asking questions, and saying `oh, but doing so and so would be so much better, and so easy', you've crossed the line from innocent question to arrogant backsit driving.

                                      All I did was to make a suggestion based on what Miod Vallat told me. Until you prove there are actually reasons for things to be the way they are, we have no reasons to be believe it was actually thought through. Or are the reasons supposed to remain hidden as well?

                                      Comments
                                      1. By Marc Espie (213.41.185.88) espie@openbsd.org on

                                        I already told you the only reason it is so:

                                        publishing the diffs in a clean way is yet another step in the process of building snapshots. It would take more time.

                                        Building snapshots is already an unfun activity, that takes a huge amount of time and effort out of Theo.

                                        he just doesn't have enough time to also publish diffs.

                                        Especially since, sometimes, he does restart builds halfway through.

                                        Comments
                                        1. By Anonymous Coward (89.248.169.108) on

                                          > I already told you the only reason it is so:
                                          >
                                          > publishing the diffs in a clean way is yet another step in the process of building snapshots. It would take more time.
                                          >
                                          > Building snapshots is already an unfun activity, that takes a huge amount of time and effort out of Theo.
                                          >
                                          > he just doesn't have enough time to also publish diffs.
                                          >
                                          > Especially since, sometimes, he does restart builds halfway through.

                                          OK, thanks.

                  2. By tedu (68.175.10.145) on

                    > > If you follow the mailing lists you often know what will be included for testing. Of course the person building the snapshot is the only person who knows *exactly* what is in there, same for release, or any other binary.
                    >
                    > Yes, and it is precisely because of this obvious fact (whoever builds the snapshots is the only one knowing the patches that were applied) THAT OTHER PEOPLE SHOULD BE INFORMED. In particular, the users!
                    >
                    > And if you have followed OpenBSD development for a while, you know it is a FALLACY to say that everything included in the snapshots has been previously exposed to the public.

                    And as the say in the business, RTFFAQ.

              3. By Marc Espie (213.41.185.88) espie@openbsd.org on


                > We are talking about two different things here. One is trusting that a random image I fetch was built with pristine sources of a given project tree. The other, completely different, is the project itself stating and encouraging its users to run with something built out of sources unknown.

                Source is not unknown. Engage your brain, and give us a vacation.

                It's all a question of trust. Even if you have the source, you still need to trust your compiler. Do you have the time to read 200M+ of source code ? neither do I...

                The `many eyeballs' meme of opensource is complete bullshit. Stuff can hide in obscure corners for years, nobody ever looks.

                Comments
                1. By Anonymous Coward (90.229.130.23) on

                  > Source is not unknown. Engage your brain, and give us a vacation.

                  The source is unknown, since the snapshots are *PURPOSEDLY* built with diffs the user cannot have access to or may not even know about.

                  And please spare me having to spell everything out for you. Try to think rationally FOR ONCE. It doesn't hurt, I swear.

                  > It's all a question of trust. Even if you have the source, you still need to trust your compiler. Do you have the time to read 200M+ of source code ? neither do I...

                  No, it is not a matter of trust. It is a matter of an allegedly "open" project hiding stuff from their users.

                  > The `many eyeballs' meme of opensource is complete bullshit. Stuff can hide in obscure corners for years, nobody ever looks.

                  That is a completely different case.

                  Comments
                  1. By Marc Espie (213.41.185.88) espie@openbsd.org on


                    > No, it is not a matter of trust. It is a matter of an allegedly "open" project hiding stuff from their users.

                    No, not really. You really don't get it. It's just a question of not stopping to give you a full rundown of intermediate source. If it works, and stays in snapshots, that stuff gets committed.

                    You never, ever get diffs that are succesful and stay uncommitted.

                    Try running a project as large as OpenBSD, try managing and getting diffs tested, try making it run on as many platforms.

                    Then we can talk.

                    Comments
                    1. By Anonymous Coward (217.114.211.20) on

                      > No, not really. You really don't get it. It's just a question of not stopping to give you a full rundown of intermediate source. If it works, and stays in snapshots, that stuff gets committed.

                      No, YOU don't get it. It is not a matter of "stopping to give users a full rundown of intermediate source", it is a question of AT LEAST MAKING IT POSSIBLE TO THE USER TO KNOW WHAT HE IS RUNNING WITH.

                      By the time the hidden diff which was in a previous snapshot gets committed, new unknown ones will already be hitting the current snapshot. Get it?

                      > Try running a project as large as OpenBSD, try managing and getting diffs tested, try making it run on as many platforms.
                      >
                      > Then we can talk.

                      No way. Mine is bigger.

                      Comments
                      1. By Marc Espie (213.41.185.88) espie@openbsd.org on

                        You are an idiot.

                        In case you don't realize it, I get bitten by hidden diffs in snapshots as well as the next person.

                        The only alternative is to take over from Theo. Build my own snapshots. This is really tiresome. I prefer the convenience of having binary snapshots for most architectures. The only case I don't run binary snapshots is when I run my own tests... which happens quite often in some areas of the tree.

                        And again, who are you ?

                        Why don't you post in your own name ?

                        Comments
                        1. By Anonymous Coward (24.9.198.93) on

                          > You are an idiot.
                          >
                          > In case you don't realize it, I get bitten by hidden diffs in snapshots as well as the next person.

                          So? Distributed pain makes pain a good thing?

                          > The only alternative is to take over from Theo. Build my own snapshots. This is really tiresome. I prefer the convenience of having binary snapshots for most architectures. The only case I don't run binary snapshots is when I run my own tests... which happens quite often in some areas of the tree.

                          Or... you could do like me and try to understand things! Maybe the current process is not only convenient, but actually makes sense?

                          > And again, who are you ?
                          >
                          > Why don't you post in your own name ?

                          Sorry, you will have to get that law approved first.


                2. By peter (62.75.160.180) on http://solarscale.de

                  > The `many eyeballs' meme of opensource is complete bullshit. Stuff can hide in obscure corners for years, nobody ever looks.

                  People may look at code but they

                  a) don't do it systemically, thus missing the obscure corners
                  b) don't understand what is written and shrug it off as right

                  Let me give you an example, imagine code that has an alias for an alias for an alias (all from different header files) while at the same time one must keep 6 or more variables in mind, this can severely challenge someones mind and in the end it may be shrugged off and one may think it's correct when it's not.

                  I think an editor that records areas of code looked at and reports it to the project may be a good idea (perhaps in vi). That way the project gets to see what parts of the kernel and userland noone looks at, or gets to
                  see the areas that everyone is looking at (perhaps a bug).

                  In the end I must say it doesn't bother me that snapshots are blobs other than the fact that people who run the blob have no idea there is a blob and may or may not cause it to catch fire.

                  -p

          3. By Anonymous Coward (72.65.236.246) on

            > So for the good of the project, we are supposed to run blobs? OK, fine, but who decides what uncommitted code goes in, and that I'm supposed to run without knowing? (I hope questioning is OK.)

            You are not "supposed" to run snapshots. Read the FAQ

             http://openbsd.org/faq/faq5.html#Flavors
            

            If you want a version of OpenBSD that has been carefully checked for consistency, that is well-documented, and whose source code has been conveniently made available, then you should run OpenBSD -release or OpenBSD -stable. The snapshots are works in progress--they are not the officially released versions OpenBSD.

            Comments
            1. By Anonymous Coward (208.75.91.19) on

              >
              > You are not "supposed" to run snapshots. Read the FAQ
              >
              > http://openbsd.org/faq/faq5.html#Flavors
              >
              >
              >
              > If you want a version of OpenBSD that has been carefully checked for consistency, that is well-documented, and whose source code has been conveniently made available, then you should run OpenBSD -release or OpenBSD -stable. The snapshots are works in progress--they are not the officially released versions OpenBSD.
              >

              Fine, but that is not what I want. I want to help testing without having to run something built on top of unknown hidden diffs.

              And before you (or someone else) replies with "but you cannot trust something you download from the internet, anyway":

              "We are talking about two different things here. One is trusting that a random image I fetch was built with pristine sources of a given project tree. The other, completely different, is the project itself stating and encouraging its users to run with something built out of sources unknown."

              Comments
              1. By Tobias Weingartner (129.128.4.7) on

                >
                > Fine, but that is not what I want. I want to help testing without having to run something built on top of unknown hidden diffs.

                No you don't. You've not contacted me at all for helping with any
                of the diffs that I need tested. Unless you actually contact me and
                test my diffs, I'm going to assume that what you want is completely
                irrelevant to my life and my goals.


                > And before you (or someone else) replies with "but you cannot trust something you download from the internet, anyway":

                This has nothing to do with trust, but putting your effort where your
                mouth is. I'm quite willing to give you plaintext diffs. :)


                > "We are talking about two different things here. One is trusting that a random image I fetch was built with pristine sources of a given project tree. The other, completely different, is the project itself stating and encouraging its users to run with something built out of sources unknown."

                Again, I've said it before. A snapshot is a snapshot of a *DEVELOPMENT*
                tree, not necessarily the *CVS* tree. If you want a "snapshot" of a
                CVS tree, check it out, and compile it. If that is too much for you,
                again put your effort where your mouth is.

                Comments
                1. By Anonymous Coward (64.233.244.45) on

                  > No you don't. You've not contacted me at all for helping with any
                  > of the diffs that I need tested. Unless you actually contact me and
                  > test my diffs, I'm going to assume that what you want is completely
                  > irrelevant to my life and my goals.

                  Well, I am glad that what I want is irrelevant to your life and your goals, because I don't look forward to having anything to do with you.

                  Of course I haven't contacted you about your diffs; I was running the snapshots. How should I contact you about something I am not even aware I am running?

                  > Again, I've said it before. A snapshot is a snapshot of a *DEVELOPMENT*
                  > tree, not necessarily the *CVS* tree. If you want a "snapshot" of a
                  > CVS tree, check it out, and compile it. If that is too much for you,
                  > again put your effort where your mouth is.

                  Wow. For the, I don't know, maybe 5th time or so: I am NOT asking for a CVS tree of the snapshots! I am asking for the developers to at least give the users an IDEA of the diffs they are running with.

                  Comments
                  1. By Anonymous Coward (128.171.90.200) on

                    If you follow the mailing lists, then you will have a fairly good idea what is in a snap for testing as developers tend to ask for testing either of the diff or they say that it will be available in the next snap.

                    Now admittedly they can include other stuff in there for testing also, but you are not looking to test that directly, if you hit a problem you report it, and compare against a stable version to see if it is in the snap.

                    Hopefully the developer who created the diff will spot what the problem is and fix it before it gets committed or does not commit it at all. If you want to fix the problem yourself, you need to check against a stable version first, check CVS, check for patches on the lists, and if you still can't find the problem you ask.

                    If you care about what is in the snap follow the mailing lists, otherwise do not run the snap.

                    Comments
                    1. By Anonymous Coward (204.8.156.142) on

                      > If you follow the mailing lists, then you will have a fairly good idea what is in a snap for testing as developers tend to ask for testing either of the diff or they say that it will be available in the next snap.

                      Yes, following the mailing lists helps a bit.

                      > Now admittedly they can include other stuff in there for testing also, but you are not looking to test that directly, if you hit a problem you report it, and compare against a stable version to see if it is in the snap.

                      How can I not be "looking to test it directly" if I am RUNNING with it?

                      > Hopefully the developer who created the diff will spot what the problem is and fix it before it gets committed or does not commit it at all. If you want to fix the problem yourself, you need to check against a stable version first, check CVS, check for patches on the lists, and if you still can't find the problem you ask.

                      Well, in order for the developer to spot the problem, I have to report it first. And don't you think I will be able to make a higher quality testing and/or report if I know what I am running with and what I am expected to test?

                      Comments
                      1. By tedu (68.175.10.145) on


                        > Well, in order for the developer to spot the problem, I have to report it first. And don't you think I will be able to make a higher quality testing and/or report if I know what I am running with and what I am expected to test?

                        Any bug report at all would be an improvement over all the jibber jabber about how awesome your bug reports could be, but it's just too damn hard for you to figure out if your computer works with the snapshot or not.

                        Comments
                        1. By Anonymous Coward (78.46.64.75) on

                          > Any bug report at all would be an improvement over all the jibber jabber about how awesome your bug reports could be, but it's just too damn hard for you to figure out if your computer works with the snapshot or not.

                          Silence would be an absolute improvement over your jibber jabber crap. Do you really believe that turning my box on and using it as a firewall will allow me to test a ports infrastructure diff or a SCSI diff I don't know about?

                          The ONLY way of making sure all diffs you put in a snapshot are going to get TESTED by unaware users is if you assume you have an INFINITE number of users and an INFINITE amount of time.

                          Hello?

                          Comments
                          1. By tedu (68.175.10.145) on

                            > > Any bug report at all would be an improvement over all the jibber jabber about how awesome your bug reports could be, but it's just too damn hard for you to figure out if your computer works with the snapshot or not.
                            >
                            > Silence would be an absolute improvement over your jibber jabber crap. Do you really believe that turning my box on and using it as a firewall will allow me to test a ports infrastructure diff or a SCSI diff I don't know about?

                            If you don't have SCSI in your firewall, knowing about the diff won't help you test it. If you do have SCSI in your firewall, booting a kernel is sufficient to test it. So, yes, I do believe that turning on your firewall box will allow you to test a SCSI diff.

                            Comments
                            1. By Anonymous Coward (24.58.74.255) on

                              > If you don't have SCSI in your firewall, knowing about the diff won't help you test it. If you do have SCSI in your firewall, booting a kernel is sufficient to test it. So, yes, I do believe that turning on your firewall box will allow you to test a SCSI diff.

                              If I know it is a SCSI diff, I can try get SCSI on it. Or a specific NIC. Or run a particular tool affected by a diff. Or pass a certain kind of traffic through the firewall. Or whatever.

                              There is simply no way you can prove it is best to have the user run shit he does not know about. You can do like Marc Espie, and resort to a "it is more work" argument, which is true indeed.

                              Comments
                              1. By anonymous pedro (201.53.48.138) on

                                dude, sorry for using a portuguese expression of biblical roots, but you are preaching in the desert. nothing is going to change, not even if sarah palin came here and said what we do in openbsd is against the bush doctrine. just go away.

                                Comments
                                1. By Anonymous Coward (72.94.35.161) on

                                  > dude, sorry for using a portuguese expression of biblical roots, but you are preaching in the desert. nothing is going to change, not even if sarah palin came here and said what we do in openbsd is against the bush doctrine. just go away.

                                  Don't worry, happy clown. I will leave you alone.

                      2. By Anonymous Coward (128.171.90.200) on

                        > How can I not be "looking to test it directly" if I am RUNNING with it?

                        You are not running all code paths, for example, if there is a patch for a SCSI driver and you are not using that driver then you are not looking to test it directly, if there is a patch for a SCSI driver and you are using the driver unawares that it was patched for testing and you hit the problem you were not testing it directly.

                        If you know development is going on for a driver you use, and are looking to test the work directly, most often you will know the work is in the snap or be patching current yourself.

                        It is largely in the developers interest to state that a change needs testing in a snap, otherwise it is fair to say that they are not expecting you to test directly, you should not notice the change and if you don't then it is fair to say it works.

                        You do submit dmesg's, right ?

                        > Well, in order for the developer to spot the problem, I have to report it first. And don't you think I will be able to make a higher quality testing and/or report if I know what I am running with and what I am expected to test?

                        Most bug reports are pretty poor, if you are capable of turning out a high quality bug report then knowing that the snap causes the problem, but the previous snap or release did not you can narrow it down to a problem in the snap. Bisecting or debugging until the problem is found is probably what is going to happen anyway.

                        Your objections seem largely philosophical rather than practical.

                  2. By Tobias Weingartner (68.151.168.15) on

                    >
                    > Well, I am glad that what I want is irrelevant to your life and your goals, because I don't look forward to having anything to do with you.

                    Thank you. :)


                    > Of course I haven't contacted you about your diffs; I was running the snapshots. How should I contact you about something I am not even aware I am running?

                    You seem to have a learning deficiency. If you want to test a snapshot
                    of some developers *DEVELOPMENT* kernel, feel free. Contact them about
                    what they may or may not have in it. If you want to test the tree,
                    free free to build your own snap. If you want to test my diffs, then
                    talk to me. Crying about it here is not going to get you what you
                    seek.


                    > Wow. For the, I don't know, maybe 5th time or so: I am NOT asking for a CVS tree of the snapshots! I am asking for the developers to at least give the users an IDEA of the diffs they are running with.

                    Then please contact the developer in question that gave you that snapshot.
                    If you want to know exactly what you're testing, run stuff you built
                    (and verified) yourself. If you want to test a specific diff, test
                    that specific diff (as sent on tech@ or misc@, etc) on your checkout
                    of the tree.

                    If you're willing to test a snapshot, wonderful. Sorry, you may not
                    know 100% of everything that is in it. You accept that "risk" by
                    testing the snap. If that is an issue for you, then go elsewhere.
                    But please don't whine and gripe about it here.


                    My last word on this. If you want to help, then put up or shut up.
                    If you don't, go away... get out of your Mom's basement, grow up,
                    and get a life. Who knows... someone might find you useful.

                    Comments
                    1. By Anonymous Coward (83.218.36.16) on

                      > Thank you. :)

                      My pleasure.

                      > You seem to have a learning deficiency. If you want to test a snapshot
                      > of some developers *DEVELOPMENT* kernel, feel free. Contact them about
                      > what they may or may not have in it. If you want to test the tree,
                      > free free to build your own snap. If you want to test my diffs, then
                      > talk to me. Crying about it here is not going to get you what you
                      > seek.

                      You seem to be missing your pills. Unless you expect to have more developers than users, proposing that every user should go ask the "release manager" (see previous posts; apparently the only guy that knows what is in the snapshot blackbox) is utter nonsense.

                      And users should NOT be encouraged to test developer A's or developer B's diffs. They should be encouraged to RUN THE OFFICIAL SNAPSHOTS, and TEST WHAT THE PROJECT WANTS TO BE TESTED.

                      > If you want to know exactly what you're testing, run stuff you built
                      > (and verified) yourself.

                      For the 6th time, that is NOT my point!

                      > If you're willing to test a snapshot, wonderful. Sorry, you may not
                      > know 100% of everything that is in it. You accept that "risk" by
                      > testing the snap. If that is an issue for you, then go elsewhere.
                      > But please don't whine and gripe about it here.

                      Why does stuff need to be hidden in the first place? Would it not be better if users knew what they are running with (NO NEED FOR A SOURCE TREE! JUST AN INDICATION!), so they could better test it?

                      These are the two questions that you all failed to answer, except Miod Vallat and Marc Espie.

                      > My last word on this. If you want to help, then put up or shut up.
                      > If you don't, go away... get out of your Mom's basement, grow up,
                      > and get a life. Who knows... someone might find you useful.

                      Sorry, I will stay in my mom's basement. This way I can offend people on the internet when I lack rational arguments to defend my ideas.

      3. By art (130.237.95.124) on


        > So much for "Full disclosure", isn't it rather deceptive? people are assuming they're getting a binary snapshot of -CURRENT but they're actually guinea pigs for code which they are unaware they are running.

        Full disclosure: I woke up this morning at 7.00. I went to the shower. In the shower I was thinking about how to reschedule processes between cpus. after 7 minutes of showering, I put on my clothes (black boxers, black socks, black pants, black t-shirt with a witty message). At 7:10 I went out the door. I lighted a cigarette and started thinking about how to deal with a few problems with posix locking. I walked down to the bus and caught a bus a 7:14. I turned off my brain at that time, put on my headphones (with noise cancellation) and started reading a book. At 7:34 I was at the end of the bus trip. I went down to my usual place and bought a ham and cheese sandwich. Then went to the coffee place and bought a double espresso. Around 7:40 I went down to the subway and caught a train two minutes later. While drinking coffee and reading the book, I got to the station where I go to the office. I threw out the coffee cup in a trash can.


        OMG! I DIDN'T TELL YOU THE TITLE OF THE BOOK! SO MUCH FOR FULL DISCLOSURE, ASSHOLE.

        Comments
        1. By Miod Vallat (miod) on

          Full Disclosure: his t-shirt sports a shadow of Darth Vador's hooded head, with ``who's your daddy?'' written next to it. I'll let you decide whether or not it's as witty as he thinks.

        2. By henning (130.237.95.150) on

          > OMG! I DIDN'T TELL YOU THE TITLE OF THE BOOK! SO MUCH FOR FULL DISCLOSURE, ASSHOLE.

          full disclosure: he didn't shave. and he didn't tell you.

          i sense a conspiracy!

          Comments
          1. By Miod Vallat (miod) on

            Full disclosure: Henning took his shoes off.

            Noone has complained about the smell yet, because we are too polite.

        3. By Anonymous Coward (128.171.90.200) on

          > OMG! I DIDN'T TELL YOU THE TITLE OF THE BOOK! SO MUCH FOR FULL DISCLOSURE, ASSHOLE.

          or where your "usual place" is

        4. By Anonymous Coward (76.103.60.14) on

          to deal with a few problems with posix locking. I walked down to the bus and caught a bus a 7:14. I turned off my brain at that time, put on my headphones (with noise cancellation) and started reading a book. At 7:34 I was at the end of the bus trip. I went down to my usual place and bought a ham and cheese sandwich. Then went to the coffee place and bought a double espresso. Around 7:40 I went down to the subway and caught a train two minutes later. While drinking coffee and reading the book, I got to the station where I go to the office. I threw out the coffee cup in a trash can.


          I wish I could take a train to work. Driving sucks.

    3. By Anonymous Coward (81.83.46.237) on

      What? You mean you are actually changing the code? I don't have time to read all your 40 commits a day? And you want me to follow tech@ too? What are you doing? How do I know what evil code and bugs you are introducing ... isn't that stuff patented? I just want my snapshots to be pure and stable, oh and I want support. Where's my 24/7 free phone number to 3th line tech support?

      If I wanted new stuff, I would use some other operating system instead. I want to file a complaint! I want to pre-order, hey why do I pay more? OH NOES SOMEONE USED THEO AND BLOB IN ONE SENTENCE!!! get him guys ...

      *sigh*, is this the eduOpenBSD journal or something (for small children)?
      For crying out loud people. Stop whining about everything and be reasonable! I thought release time was a period of happiness and joy (Christmas like).

      This is not to be seen as a reply to dingo. And no, sorry, I couldn't resist.

      Comments
      1. By Anonymous Coward (87.144.87.211) on

        > For crying out loud people. Stop whining about everything and be reasonable! I thought release time was a period of happiness and joy (Christmas like).

        Well, I use snapshots and it's like Christmas every ~2 weeks!

    4. By Anonymous Coward (24.217.226.249) on

      I find the patience in the OpenBSD community of developers and the project leader to be incredible.

      It just amazes me that Theo and OpenBSD have the reputation of being unfriendly when people come here or the lists looking for a fight.

      I'd like to thank the developers, Theo, maintainers, testers, Wim and anyone else who sincerely dedicate time to make this operating system better, especially if they have to put up with this bullshit.

      Now, I hope this thread can die so our valued resources can go about their business, enjoy life, and the fruits of their work without some moron wasting their time.

      Thank you

  3. By Anonymous Coward (64.70.54.16) on

    <nitpick>
    The releases are not scheduled on May 1st and November 1st. The official line is that they try to release twice a year, but the actual release date depends on when theo gets around to cutting a new version and he doesn't guarantee the actual date.
    </nitpick>

    Comments
    1. By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on

      > <nitpick>
      > The releases are not scheduled on May 1st and November 1st. The official line is that they try to release twice a year, but the actual release date depends on when theo gets around to cutting a new version and he doesn't guarantee the actual date.
      > </nitpick>

      This is not true.

    2. By mitja (89.212.42.176) on

      > <nitpick>
      > The releases are not scheduled on May 1st and November 1st. The official line is that they try to release twice a year, but the actual release date depends on when theo gets around to cutting a new version and he doesn't guarantee the actual date.
      > </nitpick>

      If you had bothered to read the article you would have realized that "cutting a new version" is a months long process involving several people, not something Theo does on a whim.

      Out of last 10 releases, only one was not released on 1st - that was 3.7 and it was released on May 19th, 2005 - all the others hit the May 1st/November 1st date exactly. So they don't only "try to release" - they deliver!

      Troll.

      Comments
      1. By Anonymous Coward (130.237.95.249) on


        > Troll.

        s/Troll/Douchebag/

        Fixed.

    3. By Marc Espie (213.41.185.88) espie@openbsd.org on

      > <nitpick>
      > The releases are not scheduled on May 1st and November 1st. The official line is that they try to release twice a year, but the actual release date depends on when theo gets around to cutting a new version and he doesn't guarantee the actual date.
      > </nitpick>

      Well, actually, the release is often finished sooner than May 1st and November 1st, for the most part.

      Of course, Theo won't guarantee the actual date, but show me an instance when it was late.

      (put up or shut up)

  4. By diw (diw) on

    It don't look like no kon-speer-uh-see to me.

    A read of http://openbsd.org/faq/faq5.html#Flavors suggests that only release, stable, current are considered 'flavours' of OpenBSD.
    Quote: "There are three "flavors" of OpenBSD".
    Each of them is labelled in bold in a list and has a reasonable description.

    There is a separate heading: Snapshots
    It ought to be clear it is something different from the other three - it has it's own section - and not considered a 'flavour'.
    Any salient features?
    "It is sometimes asked if there is any way to get a copy of exactly the code used to build a snapshot. The answer is no. First, there is no significant benefit to this. Second, the snapshots are built as desired, as time permits, and as resources become available. On fast platforms, several snapshots may be released in one day. On slower platforms, it may take a week or more to build a snapshot. Providing tags or markers in the source tree for each snapshot would be quite impractical. Third, snapshots often contain experimental code that isn't yet committed to the tree."

    So, everything is in fact trans-pare-unt.
    People are directed towards three flavours. Snapshots are discussed separately. Snapshots are described in enough detail to understand that source code is not part of the deal.

    That is what people do right?
    They choose what 'version' to use. They read the web page and pick one.
    How else would people choose.

    Best wishes.

    Comments
    1. By Anonymous Coward (219.90.253.102) on

      Yeah, developers shouldn't be concerned about the one or two vocal trolls when there are thousands of mostly silent content users.

  5. By Anonymous Coward (84.3.128.233) on

    I'd like to know that, why are the three main (i386, amd64, sparc64) ar
    ch packages are behind the present?
    output of ls -lart packages :
    drwxr-xr-x 2 1114 668 35328 Apr 19 04:47 m68k
    drwxr-xr-x 2 1114 668 104960 Jul 10 11:45 sparc
    drwxr-xr-x 2 1114 668 164864 Aug 14 08:35 i386
    drwxr-xr-x 2 1114 668 159232 Aug 16 20:47 sparc64
    drwxr-xr-x 2 1114 668 163840 Aug 23 10:13 amd64
    -r--r--r-- 1 1114 1114 67 Aug 26 04:06 index.txt
    drwxr-xr-x 2 1114 668 93184 Aug 29 03:19 arm
    drwxr-xr-x 14 1114 12187 512 Aug 29 03:19 .
    drwxr-xr-x 2 1114 668 145920 Sep 01 05:51 powerpc
    drwxr-xr-x 2 1114 1114 61440 Sep 05 06:34 sh
    drwxr-xr-x 2 1114 668 129024 Sep 05 06:34 hppa
    drwxr-xr-x 2 1114 668 100352 Sep 05 06:34 mips64
    drwxr-xr-x 2 1114 668 158720 Sep 05 06:34 alpha
    drwxr-xr-x 2 1114 668 53760 Sep 06 04:47 vax

    Largely the i386 packages are conspicuous.

    Thank you for your answer.

    Comments
    1. By Marc Espie (213.41.185.88) espie@openbsd.org on

      > I'd like to know that, why are the three main (i386, amd64, sparc64) ar
      > ch packages are behind the present?
      > output of ls -lart packages :
      > drwxr-xr-x 2 1114 668 35328 Apr 19 04:47 m68k
      > drwxr-xr-x 2 1114 668 104960 Jul 10 11:45 sparc
      > drwxr-xr-x 2 1114 668 164864 Aug 14 08:35 i386
      > drwxr-xr-x 2 1114 668 159232 Aug 16 20:47 sparc64
      > drwxr-xr-x 2 1114 668 163840 Aug 23 10:13 amd64
      > -r--r--r-- 1 1114 1114 67 Aug 26 04:06 index.txt
      > drwxr-xr-x 2 1114 668 93184 Aug 29 03:19 arm
      > drwxr-xr-x 14 1114 12187 512 Aug 29 03:19 .
      > drwxr-xr-x 2 1114 668 145920 Sep 01 05:51 powerpc
      > drwxr-xr-x 2 1114 1114 61440 Sep 05 06:34 sh
      > drwxr-xr-x 2 1114 668 129024 Sep 05 06:34 hppa
      > drwxr-xr-x 2 1114 668 100352 Sep 05 06:34 mips64
      > drwxr-xr-x 2 1114 668 158720 Sep 05 06:34 alpha
      > drwxr-xr-x 2 1114 668 53760 Sep 06 04:47 vax
      >
      > Largely the i386 packages are conspicuous.

      Yeah, good question. There are quite a few reasons for it. Most are related to the release process.

      For recent releases, we managed to have some margin. Namely, the 4.4 CDs were ready and sent to the CD plant before the official announcement.

      Second, the release process is usually staggered: source is validated, tested, frozen, and thawed first. Ports and x11 usually follow a few weeks later.

      Specifically, ports is dependent on source. And also, building ports takes a much longer time.

      Third, the CD release is usually finished, and src thawed before the full ports build is finished. At which point, package bulk builders effort are concentrated on building as much ftp packages for slow arches as is possible.

      The process is not perfect, we still lack packages on some architectures.

      There's also some package builder burn-out: the release time is very stressful, so the package builds do not resume all that soon after the release.

      There's also the possibility of error: it's better to first finish one thing before starting another thing.

      Also, the size of package snapshots is really big these days. Transfering them over the network, then letting the mirror sites distribute them takes a lot of time.

      There's one final specific issue for now: there was quite a few changes in libm recently, some of which require adjustment in some ports.

      I suspect the i386 snapshot actually finished first, and thus, naddy and others are holding up for a new snapshot, trying first to get most of the libm adjustments done...

      There are also some private gatherings of developers happening, with focus on specific parts of the system...

  6. By Anonymous Coward (219.90.253.102) on

    Any chance that the MD5 file could include the x sets in the future? I recently downloaded a few bad sets from a mirror and this caused much head scratching when libraries and fonts were missing.

  7. By Pieter (80.101.175.113) pieterverberne@xs4all.nl on http://www.xs4all.nl/~pjhv

    how do you current-using-guys keep uptodate? Just download a new snapshot once a week, burn it, boot it, and update your system?
    If this is the 'best' or easiest way, than I have to trow a lot af cds away just after updating to the new snapshot. (Yes, I could also collect snapshot cd's)

    Comments
    1. By James (jturner) on http://bsdgroup.org

      > how do you current-using-guys keep uptodate? Just download a new snapshot once a week, burn it, boot it, and update your system?
      > If this is the 'best' or easiest way, than I have to trow a lot af cds away just after updating to the new snapshot. (Yes, I could also collect snapshot cd's)

      Just boot bsd.rd and use ftp to update.

      Comments
      1. By Anonymous Coward (203.122.237.14) on

        > Just boot bsd.rd and use ftp to update.

        Me too. I like to download the snapshot first, and ftp install from my local server.

    2. By Jan J (85.231.168.253) on

      > how do you current-using-guys keep uptodate? Just download a
      > new snapshot once a week, burn it, boot it, and update your
      > system? If this is the 'best' or easiest way, than I have to
      > trow a lot af cds away just after updating to the new snapshot.
      > (Yes, I could also collect snapshot cd's)

      Download the .tgz balls to /home/4.4/i386. Reboot using bsd.rd.
      Choose "Install". In the disk setup exclude sd0d (which is /home)
      but newfs the other. Skip network setup (saves alot of questions)
      Choose that the install sets are on disk and point at sd0d. When
      install is finished reboot. Log in as root, update /etc/fstab to
      add /home and mount it. Run /home/doit.sh that adds my user. cd
      to /etc, "ln -s /home/rcs/etc RCS" and then "co -u sysctl.conf
      rc.conf.local ...". Reboot and login. Sometimes I "pkg_add $(cat
      pkg-add-list) and sometimes I just add them as needed.

      The downtime is somewhere around 30 minutes which I think is
      acceptable. The doit.sh script should have a better name and
      should also do the rcs parts.

      Comments
      1. By Pierre Riteau (82.251.206.215) on

        > > how do you current-using-guys keep uptodate? Just download a
        > > new snapshot once a week, burn it, boot it, and update your
        > > system? If this is the 'best' or easiest way, than I have to
        > > trow a lot af cds away just after updating to the new snapshot.
        > > (Yes, I could also collect snapshot cd's)
        >
        > Download the .tgz balls to /home/4.4/i386. Reboot using bsd.rd.
        > Choose "Install". In the disk setup exclude sd0d (which is /home)
        > but newfs the other. Skip network setup (saves alot of questions)
        > Choose that the install sets are on disk and point at sd0d. When
        > install is finished reboot. Log in as root, update /etc/fstab to
        > add /home and mount it. Run /home/doit.sh that adds my user. cd
        > to /etc, "ln -s /home/rcs/etc RCS" and then "co -u sysctl.conf
        > rc.conf.local ...". Reboot and login. Sometimes I "pkg_add $(cat
        > pkg-add-list) and sometimes I just add them as needed.
        >
        > The downtime is somewhere around 30 minutes which I think is
        > acceptable. The doit.sh script should have a better name and
        > should also do the rcs parts.

        Why do you use Install when you can use Upgrade + sysmerge, which is far easier?

        Comments
        1. By Jan J (85.231.168.253) on

          > Why do you use Install when you can use Upgrade + sysmerge,
          > which is far easier?

          To my knowledge there is no technical reason for "My Way" but my
          gut feeling tells me this is a less error prone way. People who
          know me would probably blame my pedantic tendencies. :-)

          Comments
          1. By mho (130.237.216.121) on


            > To my knowledge there is no technical reason for "My Way" but my
            > gut feeling tells me this is a less error prone way. People who
            > know me would probably blame my pedantic tendencies. :-)

            Those who know you think this is a big improvement over starting with
            cp /dev/null /sys/arch/i386/conf/MYCONF :-)

            - mho

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]