Slashdot Log In
OpenBSD 2.9 Released
Posted by
michael
on Fri Jun 01, 2001 09:29 AM
from the crispy-on-the-outside,-chewy-on-the-inside dept.
from the crispy-on-the-outside,-chewy-on-the-inside dept.
Well, the mirrors have had overnight to update, so I suppose we can announce that OpenBSD 2.9 is available. The release notes and changelog contain details of what has changed and improved. For our newer readers, OpenBSD is a BSD flavor that concentrates on security - they aim to be the most secure server operating system.
This discussion has been archived.
No new comments can be posted.
HOLD UNTIL WEB ANNOUNCEMENT OpenBSD 2.9 Released
|
Log In/Create an Account
| Top
| 110 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Re:*bsd performance ? (Score:4)
OpenBSD is all about being done corectly, and from that, comes it's security. SMP is extremely hard to do completely corectly, they have only so much man power, so they haven't bothered.
Re:UNIX Vs. UNIX: (Score:3)
>os's from. we had to toggle the instructions in >by hand on the front of the system t give the >thing enough smarts to talk to the paper tape >drive which
for crying out loud, if you're going to try to make these kind of comments, at the very least don't use those moronic microsoft characters . . .
besides, you're still claiming to be a newbie. Toggle switches indeed. And *paper* punched tape? An unreliable replacement for stone tablets.
hawk
Re:Anything to look-out for? (Score:3)
Sure they did. They write-back cached data writes to disk. They write-through cached metadata disk writes (and blocked other writes until metadata writes completed). That would leave your filesystem in a mostly consistent state, and not suck too hard in the event of a power failure. The other choices are ignore the possibility of filesystem damage from power failures (or panics), I think Linux's EXT2 did that, or maybe just did it by default, or to log metadata changes (XFS does that, and I heard EXT3 does too, but I'm not sure).
Softupdates carefully orders disk writes, and can if needed reconstruct the proper intermediate state for a metadata block. It has the performance of a totally async filesystem (i.e. somewhat higher then a logging system), but the stability of a logging system (i.e. better then the previous sync filesystem). It is also the major foundation for filesystem checkpoints and in-the-background fscks (possibly coming in FreeBSD 5.0).
The other change they made (dirperf) had to do with directory block placement, I think the old algo attempted to put them close to the datafiles, and with larger caches this is no longer a win, and has become a loss. I haven't read any papers on it or anything, so I don't know a whole lot about it.
OpenBSD is secure in part because they are conservative in adopting new features. Two years ago softupdates was pretty new, and leaving it out let FreeBSD, BSD/OS, Solaris, and NetBSD experience the teething pain (as a BSD/OS beta user at the time softupdates was rolled in, I felt some of the pain, but it wasn't too bad, never had any data loss from it, unlike soft-read-only which I think was killed).
Re:Anything to look-out for? (Score:3)
I doubt that number was. For some real benchmarks you can look at Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems [usenix.org] from the 2000 Usenix Procedings [usenix.org]. In addition to having useful info in and of itself it has references to other information. You can also try McKusic's home pages [mckusick.com] he may have newer info that, and does have some info about the experimental checkpointing.
I don't know about dirperf though. Never seen a paper on it.
Am I missing something? (Score:3)
I though Theo dumped ipf [slashdot.org], but from the release notes:
So, is all forgiven, or what?
Re:*bsd performance ? (Score:3)
I think that fully utilizing multi-processing might, indeed, pose debugging problems that haven't been addressed sufficiently for the OS kernel to use them. There are, however, alternatives.
E.g.: Run the OS on one CPU, and have it task user (non-superuser) jobs to whatever processor is less busy. Keep all jobs decending from one particular process on the same CPU (e.g., forking would not be allowed to spill-over from one CPU to the next). A few similar restrictions.
Now it is true that this would prevent the full capabilities of a multi-CPU processor from being used (on any one login stream). On the other hand, it would drastically simplify analysis. Most of the problems have already been thoroughly addressed. Etc. (If I said any more, I'd start showing how thoroughly ignorant I am, buy my guess is that the real reason for missing multi-pu support is that fixing the multi-processor issues requires a lot more time and effort than is available.)
Caution: Now approaching the (technological) singularity.
Re:Linux to BSD: Warnings (Score:3)
>help, not much. Even USENET isn't THAT helpful.
>You need need to get used to reading man pages...
>a LOT.
That's intentional. The idea is that all OpenBSD documentation should be available from the man pages instead of scattered over man pages, info pages, FAQs, and HOWTOs.
Opinions vary, to me that's a "feature", but I freely concede that some consider it a "bug".
Re:Am I missing something? (Score:5)
a few weeks ago. The CD burning factory needs more
than a couple of seconds to burn all those CDs.
At that time, the ipf thing hadn't started.
The release is the same as the CD contents.
Therefore, 2.9 has ipf.
Re:Anything to look-out for? (Score:3)
http://www.openbsd.org/29.html
...and also http://www.openbsd.org/
2.9 incorporates filesystem improvements that net a 60x performance increase.
Additionally, the new version of ipf that it contains fixes serious security holes with fragmented packets.
HTH.
IPF and OpenBSD 2.9 (Score:5)
IPF was removed from 2.9-CURRENT. This DOES NOT effect 2.9-RELEASE, from which CDs were mastered a month ago.
Linux to BSD: Warnings (Score:5)
There are no binary patches. If there is a security whole, you can patch the source tree and rebuild. Alternatively you can shut down the services. There are patches to OpenBSD, and applying them requires more knowledge.
Web support sucks. The FAQ, etc. provides some help, not much. Even USENET isn't THAT helpful. You need need to get used to reading man pages... a LOT.
Init: rc style. I think that that the rc system is infinitely more manageable and sane in a BSD environment than a SysV environment, but YMMV.
Community support. The mailling lists are key, but they are much less friendly. Advocacy isn't a priority. If there is a question answered somewhere in the documentation, you'll get told RTFM. If the docs aren't what you are looking for and need a different level of help (more/less tech than the man pages) you may or may not get it.
Apache and mod_ssl are built in. The ports collection is solid. It may not be huge, but I've found just about everything I want there. Keeping ports up with the snapshots is a nice way to get up to date userland code.
Kernel compilaton IS necessary for a server. If you put real iron on the box, or little iron, you'll need a custom kernel. The settings for OpenBSD are reasonable and will run all but the weakest machine. However, getting it to take advantage of more memory, etc., may require some tweaks.
I love OpenBSD, but it is NOT Linux. There is no community bent on global domination. Lots of "Open Source" projects are Linux specific... fortunately its just the crappy ones. However, you'll find annoying issues like cronolog not compiling, no PHP Cache, etc. There is no commercial support.
Unlike a Redhat, OpenBSD is not corporate, it's Theo's toy. As a result, they do what they want, not an attempt to appease customers. With a Redhat box, while some of your code is "scratching an itch," corporate coders can code what is needed.
Realize that the Linux comforts will be lacking.
If you are a sysadmin, check out OpenBSD. If you have a Linux box at home for playing with and think that you are l33t, stay away from OpenBSD with a 10' pole.
Alex
Re:Linux to BSD: Warnings (Score:5)
What Alex says is right on the nose (i.e. mod that comment up!). I too switched from Linux to OpenBSD at home almost 3 years ago, and have been using it for various projects at work for the past 2 years. This is what I've discovered:
In conclusion, I'd say trying OpenBSD is something every geek should do. But, admittedly, my loyalty to the OS (Theo) is waning, and I'm beginning to think FreeBSD might be a better choice.
Whatever the case, I'm sure Theo doesn't give a good god-damn...
Happy hacking,
The 'roid
Re:UNIX Vs. UNIX: (Score:5)
This is just not true and shows how very little you know about Operating Systems strengths and weaknesses. Like Slashdot noted, OpenBSD is designed for security. They actively seek and destroy anything that could be used to compromise the system and the OpenBSD group has been very sucessful with this. That's a strength. Linux runs Q3A and UT, and thousands of scientific applications, those are strengths. IRIX has a superb OpenGL implementation. MacOS X has one of the best GUI's around. FreeBSD is fast.
My point, the differences between Unixes are not in the source, but are much more obvious. Each development team has goals. Each goal shows through in the over all design of the OS and makes it so that each Unix does have a reason for existing in a world of generic Unixes.
Now, on the question of which is better...Well, actually, it depends on your goals.....everyones goals are different. Some people have political agenda's (GPL vs. BSD), some people have specific needs (absolute securty at any price, playing games, or graphics performance), and some people just don't care and get what is easiest for them to use. There is no "best" only what is best for you, cause not a SINGLE unix distrib has an all round strength (though I would argue that if Apple integrated X-Win into Aqua, the combination of default security, Java2, OpenGL, Quicktime, BSD core services, et al would bring it close to being the strongest for all round uses, but hey, thats MY bias)
Re:UNIX Vs. UNIX: (Score:3)
when i was a kid, we didn't have cd's to load our os's from. we had to toggle the instructions in by hand on the front of the system t give the thing enough smarts to talk to the paper tape drive which then loaded the code to talk to the tape system.....
we didn't have no fancy gui's. We had punch cards, and we liked it. Back in the good days, you actually had to know what you were doing in order to program the machine. We didn't have no "high level" languages like C. And we liked it that way, it kept the wimps off of our systems.
You should be happy that you only have to drive 2 hours to get to a store. When i was a kid, I had to walk.
kids... you think that you have it soooo hard....
Re:*bsd performance ? (Score:3)
The Lottery:
Re:Is an ISO available? (Score:3)
Here's how I believe it works.
The *source* is available for anyone to take, change, and otherwise use with the BSD liscence. You can do whatever the hack you want with it.
The *ISO* layout that is sold by the OpenBSD group is copyright to Theo - that means that you have to get his permission to distribute it. Now, that doesn't mean that you can't make your own ISO and distribute that, but you can't distribute the *official* release. In this case it would be the 2.9 release. I believe this distinction is made so that anyone who wants to get an ISO needs to buy the official one, or make their own.
What are the consiquences?
You know what this means.... (Score:4)