Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software BSD

FreeBSD SMPng Interview with Scott Long 76

Posted by CowboyNeal from the getting-to-know dept.
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."
This discussion has been archived. No new comments can be posted.

FreeBSD SMPng Interview with Scott Long More

FreeBSD SMPng Interview with Scott Long

Comments Filter:

  • BSD is starting to look as a viable alternative (Score:3, Funny)

    by Anonymous Coward on Saturday January 22, 2005 @12:52PM (#11441576)

    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

    • Re:BSD is starting to look as a viable alternative (Score:1, Interesting)

      by Anonymous Coward
      Hilarious read since I can clearly relate to it. I now see the light having to deal with continual issues with a major network vendor's Linux-based IDS. Over a course of about a year I've deal with issues such as telnet/ssh/https management interface hanging and the only work-around was to bounce the appliance and, separately, disable swap memory with "swapoff -a". Vendor couldn't fix it so they replaced it with a higher end model (same Linux OS). Then, it was the spontaneous reboots with the new model.
      • I've never had any stability problems with any operating system on typical loads, be it any BSD, Linux or Windows NT/2000/2003, that have not had a root cause directly related to hardware, drivers or noisy network links.

        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

    • 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?"

    • That's a cool story, but I almost got canned from a job because OpenBSD crapped out shoveling packets on hardware that even Windows ran fine on - all very common hardware, all-intel (mb/chipset, cpu, and nics) and as vanilla as can be. Sadly, I ended up with a PIX there for a while.

  • Sleep locking, spin locking (Score:4, Interesting)

    by Julian Morrison ( 5575 ) on Saturday January 22, 2005 @02:24PM (#11442270)
    This article discusses FreeBSD's preference for sleep locks as versus the spin locks in Linux.

    Anybody know why Linux went for the spin lock approach? What are the relative merits?

    • Re:Sleep locking, spin locking (Score:5, Informative)

      by Anonymous Coward on Saturday January 22, 2005 @03:07PM (#11442623)
      Linux uses spinlocks but only when it is certain that it will be released very quickly. It boils down to efficiency. That is because if a lock is held for a very short amount of time, it is more efficient to wait for it than to switch tasks. The Linux design is really to minimize lock hold times by doing as much work as possible without holding locks, and then checking to make sure that things are still right. This technique has allowed Linux to scale linearly up to hundreds of processors. In practice, Linux's SMP implementation has proved to be one of the best.

    • Anybody know why Linux went for the spin lock approach? What are the relative merits?

      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

  • There's been seven BSD articles on slashdot since the beginning of the year.

    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. ;)
  • It isn't even worth arguing whether or not this study is flawed. Until somebody at least claims to find that Firefox has more than a single-digit market share, any report that Firefox is "gaining ground" is just hype, and actually hurts the product.

  • 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.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close