Slashdot Mirror
OpenBSD SMP In The Works
Cajal writes "Four students at the University of Waterloo are working to add SMP support to OpenBSD as part of the Spinlocks project. More information is available in a story
at the OpenBSD Journal's site. They expect to have an initial working MP kernel in January."
The last time I spoke to Theo in person, he wasn't too keen on SMP. That wasn't too long ago.
You've apparently never asked Theo about this. I have several times, going back years ago, and his reply has always been either "nobody wants it", or "SMP machines are too expensive and nobody has them". And OBTW, he wasn't interested in loaner or donated hardware to do the work on.
I guess somebody cares now....
The problem is, I don't know how much of OpenBSD's kernel really relies on the assumption that it'll only ever run on one CPU and it may take some time before OpenBSD becomes as stable and secure as it needs to be.
OpenBSD is designed for an "edge server" environment, where scalability isn't as important as security.
Because OpenBSD is about security, not the lastest and greatest features. Linux is about the latest and greatest features. Since the economy went south, most of the peopl working on any of the BSD's lost their jobs or were unable to continue working on the BSD's during corporate time. Where the BSD's have corporate backing and private backing, Linux is mostly private backing, i.e. people at home working on it. Again, things are changing, but everyone has their preferences. No one is going to simply give up OpenBSD to go to Linux, if they need SMP, that is the best route. But from OpenBSD's web page:
"Only one remote hole in the default install, in more than 7 years!"
So they all have their uses, Linux, FreeBSD, OpenBSD, and NetBSD. =) Live together, work together, don't kill each other.
They have ipv6. OpenBSD ships with ipv6 active and operating. They've been looking at/working on SMP for some time, but they (read: Theo) wants to make sure it meets the standards of the rest of the OS. SMP adds quite a few (theoretically at least) security problems to deal with, and they want to be sure those problems are fully addressed.
'Sensible' is a curse word.
Isn't it the OpenBSD folks who are telling people not to make ISOs because the codebase changes frequently enough?
No.
Perhaps you are confused by this.
Why would you purchase a set of discs to perform multiple installs when OpenBSD developers recommend against using a static copy?
They don't. OpenBSD releases come at regular 6 months intervals (3.2 was a month early). That's what you should be using. You can use the snapshots or even the current CVS if you feel brave.
Sure, I can understand buying copies to support OpenBSD. I buy Redhat for the same reason, it's more principle than the actual material in the box.
You are correct. There's a slight difference, though, OpenBSD is not trying to turn a profit, just cover the development costs.
-jfedor
Did anyone else notice that these four students are using PowerBooks (I assume running OS X). Check out this picture. You also have to love the reference to the cult movie Hackers.
7 production firewalls in varying degrees of importance. 6 of these guys have *never* gone down. The exception on one was one where squid had some compile issues and made the rest of the box unhappy (during implementation). This number includes one soekris box. 2 temporary firewalls where someone insists on using firewall-1 or Symantec on Solaris but doesn't have the Solaris hardware or the budget yet. One is a bridging firewall, so I don't know what they're going to do when they want to switch. To be honest, they'll probably end up keeping them. 3 Snort sensors. (2 have never crashed, uptime of over one year before massive power failure at the location). This includes 3 upgrades of snort. One crashed during some Gigabit experiments. A high volume syslog server/ftp logfile repository/mysql server. This one has been a bit flaky. Crashed twice in a one year period, 10 months between crashes. A web server that has a maximum uptime of 8 months. Could have gone longer but this location has a bad power situation. So total OpenBSD boxen for me is around 14.
You are aware that Microsoft uses BSD code in Windows? Microsoft actually likes the BSD liscense, since they can use BSD code. They dislike the GPL, for obvious reasons.
"Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
Sounds like you've got some issues, dude.
Your comment is amusing since as a UW CS student, I don't have a Windows account. In fact, last I checked as an upper year student I'm not allowed to have Windows account, unless it's required by a specific course (statistics courses sometimes require windows accounts for matlab, for example).
Introductory programming courses are taught on Macs and Windows boxes, but almost everybody I know participates (as time allows) in free software projects; hell, half of the people I know are Debian developers.
So why don't you stick to things you know (i.e., nothing) and take some of this shut the fuck up.
Which apparently you don't.
the versions of OpenBSD with SMP support will require a Windows XP activation key...
Or maybe they figured out a way to port OpenBSd to Windows. Or something. Waterloo?
I assume you're referring to the stories from several months ago about a proposed deal where UW's Computer and Electrical Engineering department would, as part of a larger research sponsorship deal with MS, agree to make C# the language used in a first year class for CompEng students. There was a huge outcry against this by most CS and CompEng students and profs. Also, note that the School of Computer Science, in the Faculty of Mathematics, had nothing to do with this deal.
It is my impression that there are many UW students who use or contribute to Open Source projects. Profs are more than willing to make an occasional joke in class at Microsoft's expense. And most CS students (I can't speak for CompEngers) don't touch any MS products for programming projects past first year, by far preferring to use the provided unix labs.
Do I think the CompEng department's decision regarding C# bad? Very much so. But as I understand it, this decision was made by a few key people who stretched their authority, when really they should have consulted with more people. In fact, Engineering profs have called UW administration on this decision, leading to a decision that before the MS deal can be finalized, it must be approved by "the Electrical and Computer Engineering Department Program Committee, Faculty of Engineering Admissions Committee, Faculty of Engineering Academic Committee, Faculty of Engineering Undergraduate Studies Committee, Year 1 Implementation Committee, Senate Undergraduate Council, UW Registrar's Office and the senate as required by UW policy and practice." This, in my opinion, effectively has killed the deal. See this article for more about this. [Note that the article implies that the proposed MS C# deal would have affected all first year programming classes. This is untrue: only first year CompEng classes would have been affected; CS students would have been fine.]
The very reason that this decision was such as big deal at UW is that it goes so very much against the prevalent attitude there. And the very large amount of negative feedback they got from UW students and profs in the CompEng and CS departments should ensure that something like this doesn't happen again at UW.
Atheism is a religion to the same extent that not collecting stamps is a hobby.
Dynamic web servering, of course. OpenBSD is also widely used as a VPN. Whilst some of the crypto cards work great a second proc. can only help. Also, firewalls for very large networks may benefit.
OpenBSD is basically a less-active branch of NetBSD from a couple years back
That is basically bullshit. IPv6, OpenSSH, pf, altq, ipsec and systrace all appeared in OpenBSD before NetBSD.
NetBSD was more focused on portability. They were aimed at the embeded market (which Wasabi systems is in business in) where there isn't SMP. When Theo forked OpenBSD off of NetBSD they still didn't have it and it still wasn't a priority. Now there is more interest in it, especially now that SMP hardware is becoming so cheap.
Anyway anything that is relatively (or entirely) cpu-bound and involves lots of processes or threads will be sped up significantly. Also one process doesn't tend to monopolize your processor so badly.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Because they only update that statement on their web site about twice a year.
(You're using a sliding reference window while they are looking at an absolute reference--you saw "nearly 6 years" was because they hadn't updated the site in a while. "more than 7 years" is because they did update it recently. Overall time passed from *editing* the main page is less than a year. But the statement is correct because they are looking at the 2nd to last remote hole to figure their time.)
I've long been an advocate of reducing the number of different and nearly equal (in functionality) ways to do the same thing
I feel much the same, in a lot of ways. So I've focused on NetBSD.
I have Sparc and Intel and various other pieces of hardware. With NetBSD I can run the same OS, built from the exact same source tree (kernal and userland, plus the packages) on it all. I've built a library of almost all the essential references for Unix, including a complete 'real' manual set from 4.3BSD (it's great to use the tutorials from the old days- I'm starting to appreciate 'ed' as a real editor after reading Kernighan's tutorials), the 'devil' BSD book (McKusick/Bostic/Karels/Quarterman), 'The Basic Kernel' 386BSD book (Jolitz and Jolitz), Bach and (of course) Tannenbaum. Throw in an assortment of O'Reilly books (the Vol 3 and 8 X11 books are especially good, along with 'Essential System Administration').. There's more than enough on my plate for me to study and learn from. I see Linux as generally growing away from it's UNIX roots, part of why as I came to like UNIX more and more I liked Linux less and less and gravitated to one of the BSDs.
The BSD forks were probably a good thing, as it's allowed the BSD systems to thrive and grow in several directions. Generally there's a synergy there in the way the code gets passed around between the different groups that would probably be more destructive if they were one group with all the infighting that would entail.
FreeBSD has had SMP for ages now, and until very recently it better scaled than linux's.
Really? The smp in FreeBSD doesn't scale anywhere unless you consider one giant global lock to be scaling to a locked up system.
The smp in FreeBSD right now is on par with linux 2.0, which was a long time ago.
I will metamod whoever gave this uninformed peice of shit +4 down. Please do the same.
Finally someone who is correct. I'm one of the students working on this. It is our computer engineering project. The plan is to have it somewhat working by January. We decided to this because we needed an idea for project and we thought it would be fun and allow us to learn a lot in the process. When the project is complete, we plan to release the code we have and if OpenBSD wants to use it he can, however, that wasn't necessarily the original intent.
Date: Tue, 10 Dec 2002 00:11:57 -0500 (EST)
From: Richy Kim
To: Will Ellis-Adams
Cc: smp@openbsd.org
Subject: Re: spinlocks
ay papi,
I can speak for most of the group that our intentions were never as lofty as they appear on deadly or slashdot.
This is a 4th year design project. It was an opportunity to couple our academics requirements and our personal interests. But the goal, first and foremost, is to graduate -- on time.
Getting our code merged back is a trifling priority, if even.
And unfortunately, as academic projects go, we're restricted in contributors outside our group.
But thanks for encouragement, we will keep in touch with the list as we progress.
-richy kim
Well, you could always donate a few bucks instead. More than that, if you buy a 3.2 CD (latest), then you get a CD with the full sources, and when 3.3 is released, all you'll need to do is update your source tree via CVS, then build it. The bandwidth used to update is rather slim.
But on the subject, the chances are slim to none that SMP will be stable and secure enough that it will be included in the next release, so you don't need to procrastinate this time. I haven't yet heard of major improvements fore 3.3 (except the altq & pf merge) so it will be mostly bug-fixes, and performance improvements.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant