OpenBSD Journal

Review of OpenBSD on sparc64

Contributed by grey on from the more-press-rarely-hurts dept.

In a continuation of Tony Bourke's UltraSPARC series, he has given OpenBSD/sparc64 a whirl on his Ultra 5. He documents some of the features he likes, problems he came across with SQL ports, and showers a bit of praise for pf.

You can read the complete review presented at OSNews here:

http://www.osnews.com/story.php?news_id=6892&page=1

There are several misconceptions presented in Tony's article. Hopefully our undeadly readers will be able to provide a few helpful corrections or suggestions that might be useful in case he publishes errata.

(Comments are closed)


Comments
  1. By tns (217.128.54.190) on

    I am hoping for SMP support on sparc :) i have an ultra2 which is waiting to unleash its power with a good os :)

    Comments
    1. By r (202.3.72.67) on

      You know where netbsd is..

      Comments
      1. By Anonymous Coward (137.186.237.177) on

        Why was this modded down? Because it references NetBSD? If OpenBSD doesn’t support his hardware, but NetBSD does, how is this so wrong? OpenBSD and NetBSD are very closly related.

        Comments
        1. By tns (217.128.54.190) on

          You mean NetBSD support SMP on sparcs ? I looked at the website and didn't see that...

          Comments
  2. By Juanjo (81.203.204.89) on http://blackshell.usebox.net/

    I'm very surprised all the system this guy tests have inestability/reliability problems.

    In the OpenBSD case it's a port's problem, but is the rest of the base system enough stable?

    Comments
    1. By Adam (209.162.224.62) on

      But there is definately some 3rd party software that is poorly written and has issues on big endian or 64 bit systems, which gets annoying. Most major software is fine though, apache, postgresql, squid, python, zope, php, sendmail, etc.

    2. By Chris Cappuccio (198.175.14.5) on

      MySQL is written primarily in C++. He used OpenBSD 3.4 which has a buggy C++ compiler, GCC 2.95.3. To make matters worse, sparc64 had more bugs under this GCC version than i386. A test with -current would be much more useful. Lots has changed.....

  3. By Alan Post (207.66.36.189) aisa@cybermesa.com on

    My primary desktop is an ultra10 I picked up on the cheap. 333mhz, which is faster than the machine it replaced.

    I find that several apps don't run, mostly related them being written on a 32-bit machine. lame gives me headaches, for instance. The majority of apps work fine.

    For the most part, this is one of the nicest machines I have ever had. I like the "feel" of working on it. The sparc64 port is very well supported on obsd. I do get a system freeze every ~1 month, but you need to install a new kernel sometime ;).

    The fact that sizeof(int)!=sizeof(char*) makes it a good platform to test code on.

    Comments
    1. By Chris Cappuccio (198.175.14.5) on

      What does your dmesg look like? I have several sparc64 systems that stay up non-stop. I haven't encountered any issues where they will randomly crash (except for a bug that was in -current for a while!)

  4. By xerxes (193.178.166.7) on

    I have one mail server on OpenBSD 3.4 SPARC64, SUN ULTRA-1 and it works fine for me :)

  5. By obsdusr (24.73.230.118) on

    There are several misconceptions presented in Tony's article.
    What are these misconceptions ? thanks St.

    Comments
    1. By grey (64.139.7.172) on

      Well, since no one else responded here's a few:

      For starters, the note about Ultrasparc & it not being know to run OpenBSD is just silly, if not innaccurate (obviously, OpenBSD does run on some ultrasparcs I think this was maybe more of an issue of how he phrased things than anything else).

      Another minor quip with respect to his remark regarding CDROM .iso's - statements like that are just tired. Not to mention as he says himself you can use an official bootable .iso for install that's freely available for download. IMHO People need to stop getting hung up on file formats for distribution.

      Then we start getting into the innaccurate: "outside services turned on in OpenBSDby default are sendmail and sshd." Sendmail is not listening to outside interfaces by default on OpenBSD, it's just there for localhost. That said, in the MTA wars I'm definitely not a fan of sendmail, but hey I understand the desire to have the most compatible license possible (and well, it's the unix standard which is something else OpenBSD tends to go along with more often than not).

      Having issues starting X from a serial console, when ultimately he's using X to display apps on the sparc64's own display that he's running on a remote x86 linux box likely gives readers their own commentary to bring forward (or at least demand more of an explanation from the author as to how he was intending to use the serial console).

      Bringing up Fefe's already questionable benchmarks, and moreover trying to run them on an architecture they weren't designed for, nor by an OpenBSD developer just brings attention to an issue which is completely unrelated to the review at hand.

      The SQL problems on the other hand should be taken as legitimate criticism (fwiw's a developer has already commented that MySQL having problems on sparc64 isn't entirely surprising, but postgres having problems was a bit troubling and it's being looked into). That said, some ports (e.g. snort) are known to have some problems on sparc64 but at least resolutions are being worked towards in most cases. Not to discount his experiences in these cases - that's what the user saw, and that's worth reporting in a review, even if it's not favourable.

      I mean, all in all the misconceptions are pretty minor. The sendmail listening on the outside is probably the most aggregious, and the Fefe paragraph is simply out of place in the scope of reviewing the OS on the sparc64. Serial console X issues are more humourous in their own right.

      It's still nice to see this review for a few reasons: obviously, we like to see OpenBSD get press; and it's nice to see someone taking a look at a more exotic architecture (please spare me from another x86 review with Quake framerates). And despite some of the flaws he ran across, he still was left with a positive experience which I find is very encouraging. Notes about the quality of documentation and his appreciation for pf I'm sure are also nice to hear (if already widely acknowledged). Obviously I thought it was worthwhile enough to warrant posting here, so any criticisms I write here are comparitvely minor to my overall view of its value. Hope that answers some questions raised?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]