Slashdot Mirror


OpenBSD AMD64 SMP in testing

agent dero writes "Naysayers beware, at the recent Calgary OpenBSD Hackathon, there has been some major improvements in OpenBSD's SMP support which was recently merged with -current. According to this recent article at undeadly.org the code is ready for testing, but the OpenBSD team could really use some permanent AMD64 SMP hardware for testing. Notable achievments include a kernel compile in around 80 seconds."

40 comments

  1. Re:really? by Anonymous Coward · · Score: 1, Funny

    Don't worry, it soon will be. A quad opteron will generate enough heat to permanently kill any operating system.

  2. Re:really? by some_other_nerd · · Score: 3, Interesting

    It's dead? What will happen when Joe 6.pkg uses Linux and all of us geeks need a new 'underdog' OS to use?

    Once Linux gains (some) popularity, the geeks will most likely move on to HURD, OpenBeOS, and *BSD.

  3. Interesting by Anonymous Coward · · Score: 2, Funny
    Notable achievments include a kernel compile in around 80 seconds.

    Imagine a distributed kernel compile with distcc. Or perhaps a beowulf cluster compile? Or is that only a Linux thing?

    1. Re:Interesting by noselasd · · Score: 4, Informative

      Well, you only need a 32way pSeries p690 to compile the linux kernel in 4.8 seconds. Nothing fancy like beowulf or distcc needed.

    2. Re:Interesting by justins · · Score: 4, Insightful

      A p690 is MUCH fancier than a beowulf cluster, and more technologically advanced in just about every way.

      --
      Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
    3. Re:Interesting by Brandybuck · · Score: 5, Informative

      Or is that only a Linux thing?

      No, distcc and clusters work with BSDs, and most other operating systems, too.

      --
      Don't blame me, I didn't vote for either of them!
    4. Re:Interesting by noselasd · · Score: 1

      Oh, you didn't see the sarkasm ;p

  4. Good for us by vijaya_chandra · · Score: 2, Interesting

    "Notable achievments include a kernel compile in around 80 seconds."

    Hope that such compile times on the developers' systems would result in kernels that wouldn't need a recompilation/replacement for years on systems in production

    1. Re:Good for us by agent+dero · · Score: 1

      "result in kernels that wouldn't need a recompilation/replacement for years on systems in production"

      Maybe this is just me, but what would ever cause you to need to rebuild your kernels once they were in place on an OpenBSD system?

      Nothing, once the kernel is _built_ to your needs on an OpenBSD machine, you _really_ don't need to recompile it, ever.

      --
      Error 407 - No creative sig found
    2. Re:Good for us by vijaya_chandra · · Score: 1

      I am sorrry but I wasn't specifically referring to openBSD which, to be honest, I have never even tried

      It certainly might not be the case with openBSD.
      Hope this doesn't sound like flamebait, but another OS, that is the favorite of many a /.ers here, that we use generally gets a kernel upgrade patch every next month. And this is not with the latest and greatest version. Not that I have any cribs about the OS but making sure that the update doesn't break any of your custom modules or something else working properly now and then upgrading the actual systems even if only 4-5 would be a real pain

    3. Re:Good for us by Shanep · · Score: 2, Interesting

      Nothing, once the kernel is _built_ to your needs on an OpenBSD machine, you _really_ don't need to recompile it, ever.

      Or, looking at it another way, if you are a user tracking -stable, so as to stay up-to-date with security and stability patches, you should be recompiling the OpenBSD kernel (and then some) a lot more often than never.

      --
      War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
    4. Re:Good for us by tigga · · Score: 2, Informative
      Nothing, once the kernel is _built_ to your needs on an OpenBSD machine, you _really_ don't need to recompile it, ever.


      Maybe from security point of view... And if that box performs just one function or two you don't need to touch it. But adding new devices and features may need it. And bugs lurk there as well.

  5. Re:BSD is one dead bitch by Anonymous Coward · · Score: 3, Informative

    Good news, everyone!
    Turns out that *BSD is stronger than ever!
    According to an Inernetnews article, Netcraft has confirmed that *BSD has "dramatically increased its market penetration over the last year."
    There has been a steady increase in *BSD developers over the past decade.
    You can read more about FreeBSD here

    If you would like to try out a BSD, you can download: FreeBSD, OpenBSD, or NetBSD
    Enjoy!

  6. Re:really? by YU+Nicks+NE+Way · · Score: 5, Funny

    No, no, no. *BSD isn't dead, it's just dying -- it's official, Netcraft has been confirming it for about ten years. And PC Week has already told us that Apple is dead -- they're closely tied because Apple uses a BSD user space on top of a Mach kernel.

    Posted on Mozilla on FreeBSD 5.2--a dead browser on a dead OS. Dead on.

  7. Re:BSD is one dead bitch by Anonymous Coward · · Score: 3, Informative

    You forgot:
    DragonflyBSD ekkoBSD PicoBSD

    Enjoy :)

  8. Re:really? by TheRaven64 · · Score: 1

    BSD - Proudly dying since 1978.

    --
    I am TheRaven on Soylent News
  9. Re: You forgot by Anonymous Coward · · Score: 0

    Of those, only DragonFly is positioned to become one of the major BSDs, it is to FreeBSD as OpenBSD was to NetBSD.

  10. Re:really? by YU+Nicks+NE+Way · · Score: 0, Troll

    It a Gnu acronym: BSD == BSD's still dying.

  11. 80 seconds, eh? by F2F · · Score: 4, Interesting
    Well, here in Plan 9-land we get our kernels compiled for 8 seconds (Theo himself admits our compilers are blazingly fast):
    plan9% time mk 'CONF=pccpu' > /dev/null
    3.44u 3.26s 8.85r mk CONF=pccpu
    plan9% ls -l 9pccpu
    --rwxrwxr-x M 106460 andrey andrey 1554980 Jun 27 13:23 9pccpu
    plan9%

    andrey
    1. Re:80 seconds, eh? by Nimrangul · · Score: 1
      And how big is your kernel? Does your compiler use stack protection? Perhaps your kernel is smaller and your compiler faster, though I don't think your hardware was faster.

      Theo would love the plan9 compiler, if it wasn't so poorly licensed.

      I don't really see any reason to have brought up the plan9 c compiler really, it's a dead issue until the owners actually open it up.

      --
      I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
  12. Re: You forgot by Nimrangul · · Score: 2
    I agree, Dillon looks to be making serious work and serious progress with DragonFly, whereas Micro, Mir, ekko and Pico all appear to be goalless, understaffed and the staff they have do not seem to be as talented as the likes of Dillon or de Raadt.

    The way I see it there are still going to be only three major BSDs though:

    FreeBSD, the way I see it at least, will eventually be an ix86/amd64 only system with everything Linux does in it as well. Definately good for cheapservers right now, headed more for the desktops and laptops.

    DragonFlyBSD, as ever as I see it, takes the servers. The direction they are heading in is likely to be some damned good SMP, something that would be great for a server.

    OpenBSD, still how I see it, will continue expanding into the trenches of ISP warfare. They're solid and perform well, they are soon going to be able to completely replace a Cisco and they are devoted to making the system as secure as possible.

    Now, what of NetBSD you say? I say that they are slowly loosing appeal, many of their supporters call Net equally as secure as Open, but it's not. The system runs on damned near everything, but why? Who is running a Dreamcast or Atari? Any significant platforms supported by Net can be ported to Open. I think that Net will eventually die out, gloomy as it is, the goal of being on every platform is hardly a thing to unite a project in my mind. Though, as I've said a few times as a chant against flamming, that is just my opinion.

    --
    I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
  13. Re: You forgot by chaos_echo · · Score: 2
    I agree, Dillon looks to be making serious work and serious progress with DragonFly, whereas Micro, Mir, ekko and Pico all appear to be goalless, understaffed and the staff they have do not seem to be as talented as the likes of Dillon or de Raadt.

    There aren't many people in any community who can claim to be as dedicated and talented at Matt Dillon or Theo de Raadt, and understaffing is a problem that I know the ekkoBSD and MirOS teams would like to solve.

    ... I think that Net will eventually die out, gloomy as it is, the goal of being on every platform is hardly a thing to unite a project in my mind. Though, as I've said a few times as a chant against flamming, that is just my opinion.

    That opinion isn't uncommon, but there are a notable number of people who appreciate NetBSD because of their attention to architectural and technical detail. I think NetBSD will last for a long time to come. As you disclaimed, this is all IMHO

  14. 1554980 bytes by DrSkwid · · Score: 1



    plan9% ls -l 9pccpu
    --rwxrwxr-x M 106460 andrey andrey 1554980 Jun 27 13:23 9pccpu

    1554980 bytes

    eee, I remember back in the days when it was less than that

    --rwxrwxr-x M 9 sys sys 1485859 Feb 17 20:23 9pccpu

    8s to compile, 15s to boot

    if only I was allowed to use it to make weapons of mass destruction I could rule the world !!

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:1554980 bytes by F2F · · Score: 1
      more bragging, now with history and remote filesystems (pity it only goes back to 2002 online, on BL's internal servers you could possibly trace it back to when the 386 port was done, sometime before OpenBSD even existed):
      plan9% history /n/sources/plan9/386/9pccpu
      Jun 18 22:15:51 MDT 2004 /n/sources/plan9/386/9pccpu 1466062 [jmk]
      Jun 18 22:15:51 MDT 2004 /n/sourcesdump/2004/0628/plan9/386/9pccpu 1466062 [jmk]
      May 26 08:58:13 MDT 2004 /n/sourcesdump/2004/0618/plan9/386/9pccpu 1464801 [jmk]
      Feb 17 13:23:06 MST 2004 /n/sourcesdump/2004/0526/plan9/386/9pccpu 1485859 [presotto]
      Nov 9 06:50:22 MST 2003 /n/sourcesdump/2004/0217/plan9/386/9pccpu 1471511 [rsc]
      Sep 26 11:47:07 MDT 2003 /n/sourcesdump/2003/1109/plan9/386/9pccpu 1490617 [rsc]
      Jun 23 04:33:55 MDT 2003 /n/sourcesdump/2003/0926/plan9/386/9pccpu 1474348 [rsc]
      May 17 13:49:27 MDT 2003 /n/sourcesdump/2003/0623/plan9/386/9pccpu 1463526 [rsc]
      Mar 28 15:08:57 MST 2003 /n/sourcesdump/2003/0517/plan9/386/9pccpu 1463207 [rsc]
      Feb 20 14:30:56 MST 2003 /n/sourcesdump/2003/0328/plan9/386/9pccpu 1455559 [rsc]
      Feb 17 20:15:06 MST 2003 /n/sourcesdump/2003/0220/plan9/386/9pccpu 1455620 [rsc]
      Dec 15 19:39:00 MST 2002 /n/sourcesdump/2003/0217/plan9/386/9pccpu 1448231 [rsc]
      Dec 13 00:32:50 MST 2002 /n/sourcesdump/2002/1215/plan9/386/9pccpu 1429714 [rsc]
      Sep 22 22:23:01 MDT 2002 /n/sourcesdump/2002/1212/plan9/386/9pccpu 1376389 [rsc]
      plan9%
    2. Re:1554980 bytes by Anonymous Coward · · Score: 0

      Now that is some serious anti-bloat!

    3. Re:1554980 bytes by Anonymous Coward · · Score: 0

      The Windows XP kernel isn't that much bigger than that:

      % ls -l ntoskrnl.exe
      -rwxrwx---+ 1 +Administrators +SYSTEM 1925760 Apr 24 2003 ntoskrnl.exe

      No idea how long it takes to compile, though, since there's no source. :( It takes at least 30 seconds to boot anyway, since it has to load all the GUI bloat.

    4. Re:1554980 bytes by DrSkwid · · Score: 1


      last time I looked, the NT kernel used external binaries to provide device drivers etc.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    5. Re:1554980 bytes by Anonymous Coward · · Score: 0

      I haven't used plan9 in years, so sorry if this is a stupid question: does it really statically links all the device drivers into the kernel, in 2004? Most systems have supported loadable kernel modules for ages -- I remember SunOS 4 supported them them more than a decade ago (though a lot of stuff was still statically linked into the kernel).

      The kernel size reported above is much more impressive in terms of compactness if it includes all the device drivers and so on, but if that is so, it suggests a rather outdated overall architecture, not to mention very limited device support if that's a generic kernel. In contrast, Linux, for example, is pretty modular these days (not as modular as the NT kernel, but pretty good), which allows it to offer broad hardware support without building a separate kernel for each hardware configuration. Virtually everyone agrees this is a good thing, as long as the system is able to properly load/unload modules as needed, without user intervention. (The NT kernel does a better job of it that than Linux, in my experience, but Linux isn't bad.)

      Another thing to remember is that the System V (as in SunOS 5) and NT kernels support paging of kernel code to some extent, so unused kernel pages needn't waste physical memory. If plan9 doesn't even offer a modular kernel, I tend to doubt it can do that either, which means: (a) it has to be smaller to keep up; (b) no matter how small it is, it will waste physical memory. That sort of design isn't something most kernel developers I know would be particularly proud of.

    6. Re:1554980 bytes by DrSkwid · · Score: 1

      yes, kernels are statiically linked

      modular drivers have been suggested, experimented with etc.

      but when a kernel takes 8 seconds to compile and 15 seconds to boot it doesn't seem so bad

      if you are feeling lucky

      mk 'CONF=customkernel' && cat 9customkernel > /dev/reboot

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    7. Re:1554980 bytes by Anonymous Coward · · Score: 0

      Certainly, I agree it doesn't seem bad for technical users who don't mind doing that sort of thing. I, for example, still typically use custom, statically-linked kernels on BSD systems (which means a different configuration file for each machine), even though they support kernel modules. Such kernels are also quite small, but the GENERIC kernel (which is what a non-technical user would use) is much larger, and most of the code is wasted.

      For a general-purpose system that users expect to be able to install and run, a statically-linked kernel won't go. Even if there's a good detect/build process during setup, hardware changes will pose a problem.

  15. Re:really? by Anonymous Coward · · Score: 0

    Geeks were never interested in linux to begin with, wannabe losers use linux. Geeks have always preferred BSD.

  16. Re: You forgot by Anonymous Coward · · Score: 0

    The problem is OpenBSD has everything NetBSD has, plus tons more, and the only thing it doesn't have is obscure ports nobody uses like acorn. The only people I know that use NetBSD do it because they got their feelings hurt by someone in the OpenBSD community telling them to read the docs, and went crying to NetBSD cause its the next closest thing to OpenBSD.

  17. Re: You forgot by Anonymous Coward · · Score: 0
    That's not true. The OpenBSD kernel always lags in terms of architectural improvements in NetBSD, e.g. UVM, UBC, SMP, etc. The overall OpenBSD system feels a bit shoddy too, and is by far the least reliable open-source OS I've used.

    In contrast to OpenBSD, NetBSD has been the most reliable open-source OS I've used, and is the only one that runs on every single one of my systems (which are all under-5-year-old Intel and AMD PCs -- nothing exotic) without any major problems. Linux is a close second, and FreeBSD a distant third.

    Based on the benchmark results here, I'm not surprised my OpenBSD experience was as bad as it was.