FreeBSD SMPng Interview with Scott Long 76
animus9 writes "There's an interesting interview with Scott Long over at the ONLamp.com. Scott explains the difference between the various locking methods, and the current status of SMP in FreeBSD 5. He also compares the new SMP implementation with that of FreeBSD 4.x, NetBSD, DragonFly, and Linux. Other items touched upon include scalability, the status of KSE & ULE, and much more."
Re:Waaaa? (Score:2, Insightful)
This phrase has often be used to describe the MS Windows - Gnu/Linux relationship.
It seems to mee some of the Linux zealots forgot there heritage.
Forgot that Linux is just a kernel without GNU.
Forgot that there could not have been there, where there are now, without the BSD licensed software.
Forgot what free software was all about.
I'll stick to my BSD's at least there is some real progress there without the a
Re:Waaaa? (Score:3, Insightful)
Which BSD is that? From what I have seen BSD is not lacking in attitudes.
meh (Score:3, Insightful)
However, the 2.6 kernel has been a mess from day one. I'm used to new versions being a bit buggy, but the kernel developers keep adding new bugs.
First, there was that memory leak with burners. Now more recently they've been moving to libata, and that prevents SATA and PATA drives from being used at the same time on my system because libata does not yet support PATA d
Re:meh (Score:3, Interesting)
2.6 then had some large changes (nptl, new SCSI subsystem without warning, etc.) and now at 2.6.10 seems to be at least sort-of stable, but there are
Re:meh (Score:4, Interesting)
# Minimum kernel version we support
# (Recent snapshots fails with 2.6.5 and earlier)
MIN_KERNEL_VERSION="2.6.5"
Headshot. If it hadn't changed, there'd be no reason that newer user-land nptl libraries wouldn't work with older kernels. Read up before you think you're fighting 'trolls'.
And there was no "new SCSI subsystem" in 2.5 or 2.6 period.
http://www.webservertalk.com/message841936.html [webservertalk.com]
Sorry, really bad wording on my part, based on some confusing Slash comments I read before. Hardly trolling, you'll notice.
Linux does not cater for incompetant people
No, I actually did check everything, and have been configuring and compiling Linux kernels with mostly success (except weird shit like this) for years. There's no magic to it, don't pretend to be a technical expect because you've never found a bug. Same goes for that "absolutely no idea when it comes to kernel coding" assumption: I am a coder and I do know when a warning is an error in disguise. By the looks of it the calling parameters of something internal changed (since this did not happen in 2.6.9) but not all drivers were updated, and nobody cared. If this is not the case, they should fix compile warnings: the BSDs do, because warnings left over in 'stable' branches signify lazy/careless developers (i.e. Linux contributors).
Nice AC posting by the way, if you're going to make insulting claims against someone, do it with your own name or risk not being taken seriously. If I wanted to troll, which I don't, I wouldn't do it under my own name. From this perspective we gather that you're the troll and I'm making honest observations. Have a really bad day, you deserve it.
Re:meh (Score:2)
While I'm here, I may as well point out something I excused before: you can't spell 'incompetent'. That's pretty pathetic for someone implying themself to be an insider in Linux development who can definitively prove everything I say is trolling bullshit - but already failed. Go back to installing Mandrake three times a day and reading kerneltrap + Slashdot to get the 'inside' development stories.
Re:Waaaa? (Score:1)
Re:Waaaa? (Score:1)
Don't fall for it..
--
Requiem for the FUD [slashdot.org]
BSD is starting to look as a viable alternative (Score:3, Funny)
I must say that reading this interview only reinforced my gut feeling that FreeBSD and other BSD variants start to look as a viable alternative to Solaris and Linux. This is consistent with the attitude in my company. To make a long story short, I received the email first thing in the morning from the IT department. Our network would be undergoing a major overhaul to correct the ad hoc growth it had experienced in the last year, and starting next week Internet access would be sporadic. There would also be a new firewall and security measures, replacing the old OpenBSD system I'd managed to get installed last Spring. Happy for the heads-up, I went to work right away to make sure Linux had no place on our network. This was not the first time that I had faced this threat.
One day about a year ago our network guy gets asked to draw up firewall plans for this subnet of servers we have. Our network guy was your typical GNU-slinger save that he had a cascade of flowing hair down the back of his head and not a beard hanging from his face. And yeah, you can guess what he thought those firewalls were gonna run. Fast forward two days. I'd caught wind of the plans and had charts, graphs, and comparisons written up detailing OpenBSD and Linux security. Since this GNU guy had a mullet and dressed like a slob, I got taken seriously. Not to mention my data, impenetrable by any hippy "logic." OpenBSD was the more secure, even to the beancounters and idtiot management. So thanks to me, our firewalls happily run OpenBSD and not Linux, which would have buffer-overflowed into no-man's land every other hour. The Open Source Mullet gives me a lot of dirty looks lately.
Since the Open Source Mullet had been canned, a new threat had arisen at my workplace: the Fat Perl Hacker had assumed most of the Open Source Mullet's system and network administration duties, and it was no mystery to anyone at my workplace that he had a hard-on for Linux tucked away under his enormous, cascading gut. Since he was a major suck-up and workaholic, he had a lot more credibility than the Open Source Mullet this would be a real challenge for once. Dealing with the Open Source Mullet had been cake.
That night, I went to work on my strategy. First, I would document the changes in Linux and OpenBSD since a year ago when we last went with a security plan. Linux was still at version 2.4, while OpenBSD had raced from version 2.8 to 3.1 a major revision! This was good so far, and I included the relevant diffs for each. I wondered what the Fat Perl Hacker was up to and pushed ahead with my preparations.
Tuesday morning, I went to talk with the VP of Operations, who had final say on the network project. I wouldn't leave anything to chance. But after chatting with him for a few minutes, I learned of a major monkey-wrench I hadn't expected: instead of a Unix firewall system, he was planning on installing a dedicated firewall box running Windows XP. Thankful for my fortuitous social engineering, I went back to my desk and began making over my strategy to deal with this new threat. Not only would I have to deal with Linux, I'd have to eschew the Windows option now.
Sitting in front of my iBook after work, I realized that taking on Windows XP in the same manner I was going to deal with Linux would be foolish if not wasteful. Obviously the Windows option was not about numbers, anecdotes, or experience. It was a bean-counting decision and all of the security statistics in the world wouldn't matter. Since I hadn't the foggiest about how our accountants viewed the whole operation and didn't have time to learn, I'd have implement a rapid-fire real-life assault on the Windows box, which was sitting on the VP's desk awaiting its place on the network. It was time to put on my Black Hat, and that night I stayed up until 02:00 researching Windows XP vulnerabilities. Linux would have to wait.
With just two days before the network changeover was to take place, I marched into work Wednesday morning knowing that what I did in the next few hours would decide the fate of our network security. To my surprise, just moments after I had sat down, the Fat Perl Hacker asked me to join him for a cigarette outside away from the ears and eyes of the office. 15 minutes later, I was fully aware of the precarious situation I was in.
Joining forces with the Fat Perl Hacker was something I had thought about but hadn't wanted to consider. It was a double-edged sword, and I wasn't about to kid myself. Although I am damn good, he had another full decade of experience over me and that included office politics. If we aided each other I ran the risk of pushing for Linux, even if inadvertently. And I certainly wasn't about to reveal my anti-Linux research to him. After doing some quick scheming, I agreed to help the Fat Perl Hacker dissuade the VP from using Windows XP but I had my own twist to what would follow after. Knowing my shortcomings, I decided to do the only thing that would give me an edge. And that was doing something that I knew better than anyone else at my office: playing dirty.
After a power-lunch of strategizing, the Fat Perl Hacker and I went to work on cracking the Windows XP box into oblivion. We then called back to the VP and told him to load the web administration page on the firewall box. A few minutes later he was standing in my cubicle smiling. I already had a print-out of the exploits we had used and handed them to him without a word. After looking it over for a minute, he shook his head and chewed his lip. He looked at the Fat Perl Hacker and me and told us to have something more secure ready by tomorrow morning before returning to his office. Now it was crunch time. The Fat Perl Hacker smiled at me in victory, and I smiled back at him in anticipation of putting my grand plot to work.
Now early Thursday morning, I revised my anti-Linux, pro-OpenBSD presentation into an airtight backup. I would use it as my last-ditch effort in case my primary plan failed. And that primary plan just happened to be underhanded, dirty, scandalous, unfair, and full of treason. After closing PowerPoint X I carefully downloaded and burned Slackware and OpenBSD 3.1 on the same brand of blanks the the Fat Perl Hacker used. I happened to know, thanks to some late-night "overtime" I put in the night before, that the Fat Perl Hacker was planning on presenting a burnt CD of Slackware as the solution to our firewall problem. Now if only I wasn't so scatter-brained and mislabeled burnt CDs so easily!
After a few brief hours of sleep, I waltzed into the VP's office, asking when we would have our meeting about the firewall. He asked me if 30 minutes was OK, to which I said was fine, and also asked that I go and ask the Fat Perl Hacker if that was good for him as well. Back in the cubicle farm, I told the Fat Perl Hacker that the VP wanted to talk to him about the meeting. I had about 45 seconds in his empty cubicle to find his Slackware CD, replace it with my mislabeled OpenBSD CD, and book it back to my cubicle to put on an innocent face. I just barely made it as I passed him on the way back to my seat. Wiping the sweat from my brow, I read my email for the next 28 minutes.
The moment of truth had finally arrived as I sat down in the conference room in front of a newly-purchased, bare Pentium4 PC. The Fat Perl Hacker joined me and the VP moments later and we got down to business. The VP smiled and said he knew we both probably had our own ideas about network security, and he wanted to hear them both. Playing the fool I volunteered to let the Fat Perl Hacker present his solution first. I tried vainly to suppress a smile as he slipped his CD from its sleeve. Holding it up, he said the magic words I had counted on him saying: This is all we'll ever need to keep the network secure.
A few beeps and whirs later from the PC and the Fat Perl Hacker was greeted by OpenBSD 3.1, ready to format and install on the hard drive. Not waiting a second for his jaw to unslacken, I jumped up, slapped the table, and exclaimed that I couldn't have picked better myself, shaking my own burnt CD in the air. What a coincidence! And things just got better from there. So much better, in fact, that I didn't even need to bust out my PowerPoint presentation. It turned out that Fiscal wanted an answer right then and there, I heard through the freshly-answered phone, and the VP didn't waste an instant telling them he was on his way. That is, before informing the Fat Perl Hacker that he was about to get assigned a bunch of new security modules to customize and that I'd have to do the firewall install and configuration. The L-word hadn't even been uttered during the meeting and I was homefree.
The weekend overtime didn't bother me at all. I got time-and-a-half for it and the firsthand opportunity to make sure OpenBSD would oversee the sanctity of our network. Things went so well that we didn't even have any network hiccups the next Monday morning. Despite the unexpected Windows XP push, the Fat Perl Hacker's Linux obsession, and a few variables left to chance, I had come through with flying colors and even impressed myself. The Fat Perl Hacker, however, never invited me to join him for a cigarette again.
As you can see, there is a good chance that I will finally get to the point when we have this new systems running FreeBSD and the firewall running OpenBSD, even though doing so only few years ago would be nearly impossible. I see great possibilities for our company here. Kudos to Berkeley and all of the BSD developers!
Re:BSD is starting to look as a viable alternative (Score:1, Interesting)
Re:BSD is starting to look as a viable alternative (Score:1)
You cannot differentiate between operating systems based upon stability as they are all roughly equal.
Disks pop, UPS fries, ram goes bad, server accidently gets connected via phone cord, but never do servers spontaneously crash on well supported hardware.
Jason
Re:BSD is starting to look as a viable alternative (Score:2, Funny)
Now try to visualize that story with FreeBSD's Scott Long [freebsd.org] (2nd on the left) and his Linux mullet-sporting namesake counterpart [jesusphreaks.com]. I don't know about you, but I think Linux has finally found its poster guy, he and Tux look so happy together in that photo, don't you think? Of course, they'll also need a new slogan to go with the new poster, so I propose "Linux: the bare essentials open source OS. Who do you want to get friendly with today?"
Re:BSD is starting to look as a viable alternative (Score:2)
Re:Why does SMP suck on FreeBSD? (Score:2, Troll)
DragonFly has made one major release and another is on the horizon (if you read th
Re:Bullshit (Score:2)
And no, Linux has never had a full package tree, because LINUX IS NOT AN OPERATING SYSTEM. It's a kernel. DISTRIBUTIONS have package trees, but they don't release at the same time new kernel versions do, so being able to install a distro from the latest kernel isn't always possible until the next release; this becomes important when your installation requires new drivers only found in the latest kernel.
FreeBSD's SMP is not substandard, by all rights it's one
Re:Bullshit (Score:3)
I am well aware of all the failures in FreeBSD 5. But it's SMP design is not sub-standard. There is no standard. Let's say there are 5 major free OS players that just about everyone can name: Linux, FreeBSD, DragonFly BSD, NetBSD and OpenBSD. Linux and FreeBSD have (different but conceptually familiar) mutex SMP models, and while Linux
Re:Bullshit (Score:2)
But I do it only when it's worth.
Anyway, regarding the SMP model, I think it would be wise to wait, in order to say which is the best approach. I don't think it can be inferred by the literature, and all the camps still have a lot of code to write.
And if I may suggest one thing, let's be more constructive in criticizing FreeBSD: it can have some regressions due to the new technology, but this hardly means anything regarding the validity of the desi
Sleep locking, spin locking (Score:4, Interesting)
Anybody know why Linux went for the spin lock approach? What are the relative merits?
Re:Sleep locking, spin locking (Score:5, Informative)
Re:Sleep locking, spin locking (Score:4, Informative)
Re:Sleep locking, spin locking (Score:2)
AIUI, the reason is that spinlocks are much faster for locking small pieces of code, when the locks aren't congested. While sleepinglocks are better when one or both of these isn't true.
So given that you want both of these to be not true anyway (so you can have more code running on more procs), using spinlocks isn't a problem.
The same idea is also shown where in *BSD you have a heirarchy of interupts, vs. the stop
Re:Requiem for the FUD (Score:1, Insightful)
> Unless that code is *running* on YOUR COMPUTER!
I don't think so. If the author of the software is ready to take the responsibility of what his software does, that's quite acceptable to me, since in case of a malicious behaviour of his software I can sue him.
Of course, having the source code is way better. But it's a desirable thing, not something absolutely necessary - let alone a "freedom".
Ex
Slashdot confirms: Apache is dying! (Score:2, Funny)
And apache? Nothing. Last year, just after Christmas, a bit about test mod_perl (and that's barely apache).
BSD is doing fine. Apache is dying.
Re:Slashdot confirms: Apache is dying! (Score:2)
No more of "gaining ground" hype please (Score:2, Offtopic)
Re:No more of "gaining ground" hype please (Score:2)
Re:No more of "gaining ground" hype please (Score:2)
Friends don't let Friends
Re:Nothing about XEN however.... (Score:2)
And if you follow the development you'll note it's a much better contender for making use of the platform anyway. NetBSD's simpler algorithms and amazingly good code work well where you have to minimize the raw overhead, which is useful for virtualization like Xen. FreeBSD's advantages are thinning out fast.
Re:Nothing about XEN however.... (Score:2)
And I was already aware of those 'problems', but if every time something like that came up the whole project was abandoned, do you think any of the projects would be where they are?
And it's not trolling to say FreeBSD is losing its lustre. That's actually entirely true. It's not dead yet, and it might recover, but in the mean time, there are much better alternatives to running FreeBSD 5. Net
Re:Nothing about XEN however.... (Score:2)
FreeBSD, otoh, stil lhas far and away the biggest installed base and the biggest ports collection. It is the most known of the BSDs, etc etc. I've been running a 5x server since 5.1, and it's been perfectly stable, and fast. There are a lot of very compelling features in ne
Re:SMP BSD (Score:2)
Linux drivers: "it compiles and works well-enough on the architecture I tried it in, it's going in the stab
Re:SMP BSD (Score:2)
Of course, on Linux 2.6 it's a good day where there *isn't* some horrible flaw.
Re:SMP BSD (Score:3, Interesting)
Shame isn't it? With Linux stealing the spotlight all the other more deserving projects are left lacking users.
Interrupt Threads (Score:2)
It is interesting to see how and when various operating system concepts get implemented. Interrupt threads are a pretty common technique in realtime systems, and have been around since the early 90's or so; they were the first driver technique that I learned.