Nicolas Letellier wrote:
Might be better to say they are what is going to become the NEXT release.
> If I want a *very* stable system (in production for example), I use
That may be what you do, but you are generally wrong if that is your goal.
The goal is that the BEST version of OpenBSD is -current.
This goal is usually met.
The people who usually experience trouble with -current often can't
run -release/-stable at all, so no big loss. IF there is a bug in
-current and you don't find it, it may very well exist in the next
-release. The sooner bugs are found, the happier everyone is.
*The name -stable refers to the API and functionality, not to the
robustness of the system.* If you create a binary today, it will always
run on the same version of -stable. If you are used to one way
something works, it will continue to work that way on -stable
If you are worried about your system's security or possibility of doing
something bad, run -current. Really.
The name -stable was really an unfortunate choice, giving people the idea
that anything other than the APIs and functionality of -current was
"unstable". Other projects have done a lot to reinforce this idea, but
the fact that other projects use the "I screw it, maybe you can fix it"
development model does not mean OpenBSD does.
Again, the most robust, best supported, most secure version of OpenBSD
is -current.
> On the other hand, packages and ports are
and in a few days, it will probably be 2.0.0.11. Don't fool yourself
into thinking that running the newest version means you are "secure". In
that case in particular, it just means you are running a version where
they reacted to a few more bugs. "Better than IE" is the Mozilla goal,
not "good". If you are doing things that expose yourself to Firefox
vulnerabilities, you probably aren't going to save yourself by running
the "lease insecure" version on a secure OS.
There are some apps where the lack of a -stable version is an issue, but
Firefox is not one that wins any sympathy with me.
> If I use openbsd, it's for security and stability. Or, I must do a
same reason you aren't. Because no one stepped up to do it.
Besides, the people best qualified to maintain a -stable are generally
working on -current, and thus, the next release. Given finite time and
finite people, that's where you want 'em. Otherwise, you end up with
crap for the next -release and more dependence on -stable and that's not
OpenBSD's goal.
> What method does recommend to have updated applications in -stable or
Let's say you plan on implementing a new machine today. Install -current.
Really. In May, upgrade to the 4.3, and sit there for six months. In
November, upgrade to 4.4. IF you are using some third party apps which have
"issues" mid-cycle, bump to a snapshot, and update the packages. If a system
bug is found that impacts you, bump to -stable. The -release/-stable spots
are "resting points" in the upgrade cycle.
But that new app should be set up and tested out on -current, not -release.
Try to use the base OpenBSD system for as much of the system as you can.
The fewer packages you have installed, the fewer special cases you will have
to deal with. The fewer cutesie-crap apps you put in your servers, the less
often you will have to take down your servers because of cutesie-crap bugs.
Nick.
| Jeff Garzik | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Christoph Hellwig | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Emmanuel Dreyfus | fixing send(2) semantics (kern/29750) |
| Christos Zoulas | Re: Melting down your network [Subject changed] |
| Juan RP | Changing the I/O scheduler on-the-fly |
| Emmanuel Dreyfus | Re: fixing send(2) semantics (kern/29750) |
