OpenBSD Journal

s/80386//g

Contributed by merdely on from the 386-reasons-to-upgrade-to-a-486 dept.

So, what's the oldest x86 machine you have running a 4.1+ version of OpenBSD? Today, tom@ committed the removal of 80386 support.

It does make me wonder, is the $ARCH going to change to i486? :)

Details below...

tom@'s commit:

CVSROOT:	/cvs
Module name:	src
Changes by:	tom a t cvs openbsd org	2007/05/29 12:18:20

Modified files:
	sys/arch/i386/conf: GENERIC Makefile.i386 RAMDISK RAMDISKB 
	                    RAMDISKC RAMDISK_CD 
	sys/arch/i386/i386: cpu.c lock_machdep.c locore.s machdep.c 
	                    pmap.c 
	sys/arch/i386/include: endian.h lock.h pmap.h 

Log message:
Remove support for 80386 processors.  Apologies if you have one of
the rare 80386-bases system with enough memory, a 387 FPU, a useable
disk subsystem, and the patience to wait for it to unpack the
distribution .tgz files.

approval from art@ and many others (esp. nick@); ok deraadt@

followed quickly by the credit:
Thanks to nick@ for the quote!

Now to remove some broken compatibility layer code to increase productive activity. Oh. Wait.

(Comments are closed)


Comments
  1. Comments
    1. By Anonymous Coward (192.117.150.8) on

      > I doubt that we'll take another approach from the one taken by FreeBSD -- they just had the very same question posted today in freebsd-arch (coincidence? :)

      No. As always, this too is stolen from NetBSD.

      http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=36163

      Comments
      1. By Anonymous Coward (85.178.113.29) on

        > > I doubt that we'll take another approach from the one taken by FreeBSD -- they just had the very same question posted today in freebsd-arch (coincidence? :)
        >
        > No. As always, this too is stolen from NetBSD.
        >
        > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=36163


        Well OpenBSD is sometimes kinda SLOW to introduce usefull Changes.
        If you search for such stuff you`ll find "some" things wich have been commited, changed, asked looong ago by somebody else (like the Recent change to the httpd to not print the Version number (requested by "Sebastian Rother in 2006" and of course "rejected" back then because it`s "useless"...).

        But if you put this stuff aside OpenBSD is also offen ahead.
        Just sad that sometimes it isn`t. :-]

        Comments
        1. By art (66.38.248.100) on

          > Well OpenBSD is sometimes kinda SLOW to introduce usefull Changes.
          > If you search for such stuff you`ll find "some" things wich have been commited, changed, asked looong ago by somebody else (like the Recent change to the httpd to not print the Version number (requested by "Sebastian Rother in 2006" and of course "rejected" back then because it`s "useless"...).

          Because back then it was useless. Things changed.

          Welcome to reality. It's not static.

          Comments
          1. By Anonymous Coward (192.117.150.8) on

            > > Well OpenBSD is sometimes kinda SLOW to introduce usefull Changes.
            > > If you search for such stuff you`ll find "some" things wich have been commited, changed, asked looong ago by somebody else (like the Recent change to the httpd to not print the Version number (requested by "Sebastian Rother in 2006" and of course "rejected" back then because it`s "useless"...).
            >
            > Because back then it was useless. Things changed.
            >
            > Welcome to reality. It's not static.

            I find it hilarious that the pro-actively secure operating system has to retroactively introduce security features. To remind you, this also happened with the non-exec stack way back, and probably a bunch of other stuff.

            Comments
            1. By tedu (66.38.248.100) on

              > > > Well OpenBSD is sometimes kinda SLOW to introduce usefull Changes.
              > > > If you search for such stuff you`ll find "some" things wich have been commited, changed, asked looong ago by somebody else (like the Recent change to the httpd to not print the Version number (requested by "Sebastian Rother in 2006" and of course "rejected" back then because it`s "useless"...).
              > >
              > > Because back then it was useless. Things changed.
              > >
              > > Welcome to reality. It's not static.
              >
              > I find it hilarious that the pro-actively secure operating system has to retroactively introduce security features. To remind you, this also happened with the non-exec stack way back, and probably a bunch of other stuff.

              removing the version is not a security feature.

              Comments
              1. By Anonymous Coward (85.178.100.227) on

                > > > > Well OpenBSD is sometimes kinda SLOW to introduce usefull Changes.
                > > > > If you search for such stuff you`ll find "some" things wich have been commited, changed, asked looong ago by somebody else (like the Recent change to the httpd to not print the Version number (requested by "Sebastian Rother in 2006" and of course "rejected" back then because it`s "useless"...).
                > > >
                > > > Because back then it was useless. Things changed.
                > > >
                > > > Welcome to reality. It's not static.
                > >
                > > I find it hilarious that the pro-actively secure operating system has to retroactively introduce security features. To remind you, this also happened with the non-exec stack way back, and probably a bunch of other stuff.
                >
                > removing the version is not a security feature.

                But including the SetEnvIF Variables (like also mentioned by Sebastian Rother) IS something wich HELPS!

                1 SetEnvIf Request_Method . bad_http=y
                2 SetEnvIf Request_Method . bad_get=y
                3 SetEnvIf Request_Protocol HTTP\/1\.0$ !bad_http
                4 SetEnvIf Request_Protocol HTTP\/1\.1$ !bad_http
                5 SetEnvIf Request_Method GET !bad_get
                6 SetEnvIf bad_http y BadRequest=y
                7 SetEnvIf bad_get y BadRequest=y

                Feel free to add it for every support method and you`re happy dropping malformed Requests.

            2. By Anonymous Coward (66.38.248.100) on

              > I find it hilarious that the pro-actively secure operating system has to retroactively introduce security features. To remind you, this also happened with the non-exec stack way back, and probably a bunch of other stuff.

              Funny. I thought we were talking about the version number thing in Apache, not a security feature.

              What "security feature" were you talking about?

              Comments
              1. By Anonymous Coward (85.178.100.227) on

                > > I find it hilarious that the pro-actively secure operating system has to retroactively introduce security features. To remind you, this also happened with the non-exec stack way back, and probably a bunch of other stuff.
                >
                > Funny. I thought we were talking about the version number thing in Apache, not a security feature.
                >
                > What "security feature" were you talking about?

                Propably about the fucked up auto-sploiter t00ls wich simply flood you with CRAP because they think you`re vulnerable?!
                And fucked up logs can hide "real" attacks pretty well.

      2. By tedu (66.38.248.100) on

        > > I doubt that we'll take another approach from the one taken by FreeBSD -- they just had the very same question posted today in freebsd-arch (coincidence? :)
        >
        > No. As always, this too is stolen from NetBSD.
        >
        > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=36163

        hmmm, it looks like the diff is missing. maybe you can add one now though.

      3. By Anonymous Coward (203.65.245.11) on

        > > I doubt that we'll take another approach from the one taken by FreeBSD -- they just had the very same question posted today in freebsd-arch (coincidence? :)
        >
        > No. As always, this too is stolen from NetBSD.

        Ah, yes what would the online world be without whiners with an axe to grind, eh?

  2. By Mike Swanson (71.197.194.170) on

    Was it really so bad to have 386 support? I realize that few people might be using such machines, but is there really anything offending about it that makes it desirable to remove the support?

    for the record, the oldest (and only) machine I have with OpenBSD is a P3-era Celeron 1.4GHz ;)

    Comments
    1. By tedu (66.38.248.100) on

      > Was it really so bad to have 386 support? I realize that few people might be using such machines, but is there really anything offending about it that makes it desirable to remove the support?

      look at the diff. it adds branches and more code to critical parts of the kernel. parts that you want to be clean and straightforward.

      every time you add a new function that can be fast by using a 486 instruction, you have to write a special version for 386. then you have to use a function pointer instead of a function to do the right thing.

      Comments
      1. By Cabal (Cabal) on http://www.enginuity.org/

        > look at the diff. it adds branches and more code to critical parts of the kernel. parts that you want to be clean and straightforward.
        >
        > every time you add a new function that can be fast by using a 486 instruction, you have to write a special version for 386. then you have to use a function pointer instead of a function to do the right thing.

        Why stop there? The i586 or better has been the standard (in the x86 world) since 1994, that's 13+ years to upgrade/migrate. Let's get out all the kludge now.

        Comments
        1. By Daniel Ouellet (66.63.10.94) daniel@presscom.net on

          > > look at the diff. it adds branches and more code to critical parts of the kernel. parts that you want to be clean and straightforward.
          > >
          > > every time you add a new function that can be fast by using a 486 instruction, you have to write a special version for 386. then you have to use a function pointer instead of a function to do the right thing.
          >
          > Why stop there? The i586 or better has been the standard (in the x86 world) since 1994, that's 13+ years to upgrade/migrate. Let's get out all the kludge now.

          Because there is plenty of embedded and thin-client that use 486 still, even the lower end of the Soekris line does. Would be nice, but then you would exclude a good part of possible hardware still in use today. Would be nice may be, but I don't think it would be possible or wise I think, even if I wouldn't be oppose to it. YMMV

        2. By Darren Tucker (dtucker) on

          > Why stop there? The i586 or better has been the standard (in the x86 world)
          > since 1994, that's 13+ years to upgrade/migrate. Let's get out all the kludge now.
          

          For desktops and servers maybe (and possibly not until later; weren't some Cyrix 6x86 chips effectively fast 486s?), but some embedded systems sold even today use 486-class CPUs (eg Soekris net4501).

          Comments
          1. By Anonymous Coward (151.188.247.104) on

            > For desktops and servers maybe (and possibly not until later; weren't some Cyrix 6x86 chips effectively fast 486s?), but some embedded systems sold even today use 486-class CPUs (eg Soekris net4501).
            >

            Actually, the Cyrix 6x86 chips were 586-based, with a good amount of the Pentium Pro's instruction set added on. Their integer performance actually was on par with a P-Pro, but their FP performance was more like an Intel Pentium of the same clock speed. They were good chips that, admittedly, did run "a bit" hot. :-)

        3. By Anonymous Coward (66.39.179.5) on

          > Why stop there? The i586 or better has been the standard (in the x86 world) since 1994, that's 13+ years to upgrade/migrate. Let's get out all the kludge now.

          To answer the original question, the slowest system I run OpenBSD on today is probably a soekris 4501. And the second slowest is a 666MHz VIA box with on-chip AES and RNG. The rest are 2GHz and higher.

          The Soekris 45xx and other smaller systems are probably the biggest reasons to keep 80486 support today. And as a 486 can still be useful, I'm sure there are a handful of users still on actual 80486 systems! The disk I/O is painfully slow, sure, and ssh-keygen might make you want to slit your wrists, absolutely, but it's still a speed demon compared to a 386.

          For what it's worth, I ran OpenBSD on a 80386SX/16 back in the earliest days of the kernel's departure from netbsd, in late 1995 and 1996. I used it with PPP as my dialup router because it could run a serial port at 57600, or maybe 115200, and doing that got me better performance with the modem's compression. The sun 4/110 had a max serial speed of either 38400 or 19200.

          For the record, the sun 4/110 also worked better under openbsd than netbsd because Theo rewrote the sw (SCSI "weird") driver to use DMA some time in 1995. This is why I started using the first openbsd kernel ever released by theo on top of a netbsd/sparc distro, straight over ftp from zeus.theos.com in August or September of 1995.

          Theo didn't actually tell me about the kernel, and I'm not even sure if I knew it was for sparc. I'm not sure what bothered me to try it, I think I even found Theo's FTP site by accident. I was just trying to ftp into his machine when I saw it on IRC /whois from #hack. (Yeah, back in the day, Theo was on IRC) That's what you did back then, you ran an FTP server if you had something interesting to share. Who the hell does that now, besides Bob Beck?

          This sw with DMA brought my sun 4/110 from 110KB/sec to over 1MB/sec disk I/O, which was simply phenomenal. And I had some custom compile of X for netbsd/sparc from some dude at U of Michigan or Michigan State U or somewhere else in Michigan that had certain bugs fixed in the likes of xterm that are still present today in XF86 and X.Org. Bugs so old that I can't even tell what they were anymore because these little tiny things in X have been broken so long. Things like, when you paste a large bunch of text and xterm only displays part of it, it looks like the rest got cut off(yet, all of it was actually pasted.) And some other more subtle ones that i simply can't remember anymore. I think line wraps got preserved much more frequently when pasting between xterms in this custom X tree.

          Anyways, everybody was still getting over the depression back in those days of Sun switching SunOS from BSD to Sys V. (Sun switched just to shave off SMP development time.....) That's probably half of what motivated Theo to start NetBSD!! With piece of shit System V garbage everywhere, SunOS was rapidly turning into a festering pile of shit. The SunOS source tree was "available" at that time too, at least to various universities that had a significant investment in Sun hardware. It served as a sort of frustrating documentation to their weird hardware, much like OpenSolaris and Linux drivers do today. The world hasn't changed as much as computers have gotten faster!!!

        4. By tedu (66.38.248.100) on

          > > look at the diff. it adds branches and more code to critical parts of the kernel. parts that you want to be clean and straightforward.
          > >
          > > every time you add a new function that can be fast by using a 486 instruction, you have to write a special version for 386. then you have to use a function pointer instead of a function to do the right thing.
          >
          > Why stop there? The i586 or better has been the standard (in the x86 world) since 1994, that's 13+ years to upgrade/migrate. Let's get out all the kludge now.

          because 486 doesn't have as much kludge.
          because 486 systems still exist.

          if only people would just look at the diffs.

          Comments
          1. By Daniel Ouellet (66.63.10.94) daniel@presscom.net on

            > > > look at the diff. it adds branches and more code to critical parts of the kernel. parts that you want to be clean and straightforward.
            > > >
            > > > every time you add a new function that can be fast by using a 486 instruction, you have to write a special version for 386. then you have to use a function pointer instead of a function to do the right thing.
            > >
            > > Why stop there? The i586 or better has been the standard (in the x86 world) since 1994, that's 13+ years to upgrade/migrate. Let's get out all the kludge now.
            >
            > because 486 doesn't have as much kludge.
            > because 486 systems still exist.
            >
            > if only people would just look at the diffs.

            Shouldn't the changes added by art@ almost 5 weeks ago be look at as well to be remove. An example here:

            http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/include/lock.h.diff?r1=1.3&r2=1.4

            He did add codes specifically to make the difference between the 386 and 486 up. From his commit:

            "It uses a function pointer to choose between the 386 and 486 versions.
            The 386 version is not MP safe, but we're not expecting MP support
            for 386 cpus."

            I haven't look at else where he did add specific for this, but may be a good thing to remove now as well as it is most likley very fresh in his mind still.

            Comments
            1. By art (66.38.248.100) on

              That was already done in the original commit.

            2. By tedu (66.38.248.100) on

              > > if only people would just look at the diffs.
              >
              > Shouldn't the changes added by art@ almost 5 weeks ago be look at as well to be remove. An example here:

              the changes were removed.

              if only people would just look at the diffs.

        5. By Anonymous Coward (85.214.23.162) on

          > Why stop there? The i586 or better has been the standard (in the x86
          > world) since 1994

          Wrong. As told before, the Soekris boxen, for example, are 80486-based,
          and I also run an 80486 notebook with - admittedly - MirBSD.

      2. By Daniel Ouellet (66.63.10.94) daniel@presscom.net on

        > > Was it really so bad to have 386 support? I realize that few people might be using such machines, but is there really anything offending about it that makes it desirable to remove the support?
        >
        > look at the diff. it adds branches and more code to critical parts of the kernel. parts that you want to be clean and straightforward.
        >
        > every time you add a new function that can be fast by using a 486 instruction, you have to write a special version for 386. then you have to use a function pointer instead of a function to do the right thing.

        Plus you need to make space on the boot floppy no? (;> It's getting full.

    2. By art (66.38.248.100) on

      Removing code that's not used improves readability and performance. It's as simple as that.

    3. By Noryungi (Noryungi) on

      > for the record, the oldest (and only) machine I have with OpenBSD is a P3-era Celeron 1.4GHz ;) <

      Same here... The only machines I have that run OpenBSD are also Celeron or PIII. I used to have a Pentium I MMX, but this has been more or less retired now.

      At work, I have a few PIV and AMD64 that run OpenBSD, though. It just works great on small machines.

  3. By Anonymous Coward (206.13.125.181) on

    What did miod@ say?

    "Nooooooooo!"?

    Comments
    1. By Daniel Ouellet (66.63.10.94) daniel@presscom.net on

      > What did miod@ say?
      >
      > "Nooooooooo!"?


      May be Nick did joint in the no camp:

      http://marc.info/?l=openbsd-misc&m=116070927003070&w=2

      He will have to let go of some hardware with pain now. (;>

      Quote:
      <snip>
      "I've got a 80386/40MHz I power up from time to time when there is
      something to test. I did put OpenBSD on a 80386DX/25 with a 300M ESDI
      hard disk, but ESDI disks have bad sectors that aren't locked out before
      the OS sees them, and dealing with that during install was just a
      pain...so it never got 100% functional with the ESDI disk. That was
      painful, btw. It is hard to remember just how much faster a cheap IDE
      disk is now than those (once) wickedly fast ESDI drives...

      I've got an IBM 80386sx/16MHz machine that I can put 12M RAM in, if I
      can find an 80387sx, I'm going to try to get the slowest build times
      available, but I doubt it will ever be used as a production machine.
      I've got a 386sx that I can get up to 15M or 16M in, but it's 25MHz,
      that's not as exiting (and still needs the 387sx)."
      <snip>

    2. By Miod Vallat (miod) on

      > What did miod@ say?
      >
      > "Nooooooooo!"?

      Not at all.

      I am unfortunately short on spare time, so I did not work on that sun386i port I am brewing in many months.

      Comments
      1. By Motley Fool (MotleyFool) on

        > Not at all.
        >
        > I am unfortunately short on spare time, so I did not work on that sun386i port I am brewing in many months.

        I was wondering if you ever got the Sun386i system working. I've still been on the lookout for a Sun486i pre-production unit. If any place outside Sun ever had one it was most likely my daytime employer. Unfortunately it's either long ago been sent to the scrap pile or is sitting in some old SysAdmin's storage cabinet, waiting to be thrown out when he retires.

    3. By Anonymous Coward (203.15.102.65) on

      > What did miod@ say?
      >
      > "Nooooooooo!"?

      DO NOT WANT!

    4. By Anonymous Coward (85.214.23.162) on

      > What did miod@ say?

      I'd like to know that too, although I think, after departing
      from writing device drivers for OS/2, he's doing non-i386
      exclusively now...

  4. By Rudy (70.167.128.140) on

    My "newest" machine is a Soekris 4501 with a "486" in it, my oldest has a P-II 350 in it.
    The last time i was running anything on a 386 was probably back in 2000 ...

    Comments
    1. By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng

      > My "newest" machine is a Soekris 4501 with a "486" in it, my oldest has a P-II 350 in it.
      > The last time i was running anything on a 386 was probably back in 2000 ...

      Yeah, ckuethe says that the last dmesg they got from a 386 was in 2003. Just let it go.

  5. By Shane J Pearson (59.167.252.29) on

    I moved closer to the city recently and wanted to get my computer count down, so I decided to throw out some older machines.

    All the 386's, 486's and Pentiums to a 550MHz P3 got the chop. It broke my heart to throw out working machines and parts, especially the cute little 386sx/16 (really little mobo), but I knew for certain that they would be scavenged by others. I was glad to see an older gentleman going through my massive pile with an electric screwdriver. I hope nobody wasted any time trying to install Windows on the RS6000 workstation I previously chucked.

    So the oldest x86 machine I am running OpenBSD on is.... a 2.13GHz Sony VAIO.

    Comments
    1. By dingo (70.8.104.104) on

      > I moved closer to the city recently and wanted to get my computer count down, so I decided to throw out some older machines.
      >
      > I was glad to see an older gentleman going through my massive pile with an electric screwdriver. I hope nobody wasted any time trying to install Windows on the RS6000 workstation I previously chucked.

      I assure you, this was recycled for the metal. People make a living on scrapping here in Flint, MI.

  6. By Morsello (201.52.99.177) morsello@gmail.com on

    My oldest 4.1 machines are 366/400 MHz K6-II, on my lab.
    Iīm considering this the lower level performance and
    resource level to do my work.

    The i386/i486 PCs donīt have PCI buses, so you must use
    old 10 Mbits ISA network cards on it.
    Itīs almost impossible to use it on a decent home network,
    that must have 54 Mbits at least.
    10 MBits are not enough even for a cable network or a
    802.11B gateway.

    For desktops and simple firewalls on PCs, i586 or P1 seems
    to be a minimum to me.

    But for embedded-like network devices, like Soekris, its
    possible to have i486 with Mini-PCI and 100 Mbits networks.
    So on, i486 must be minimum compatibility level.

    But with this devices, you must build your own kernel, so
    on GENERIC you can drop the i486 support.

    My suggests are:
    - P2, P1 or i586 support on GENERIC
    - i486, i586, P1 support by source build.


    Comments
    1. By Motley Fool (MotleyFool) on

      > The i386/i486 PCs donīt have PCI buses, so you must use
      > old 10 Mbits ISA network cards on it.

      There were plenty of 486 systems built with PCI. They usually had PCI and ISA busses as PCI cards were sooooo expensive and rare back then.

      Comments
      1. By Morsello (201.52.99.177) on

        > There were plenty of 486 systems built with PCI. They usually had PCI and ISA busses as PCI cards were sooooo expensive and rare back then.

        Yes, I have few 486 boards with PCI also. Itīs very difficult to find and assemble more than 32M of memory.

    2. By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng

      > My suggests are:
      > - P2, P1 or i586 support on GENERIC
      > - i486, i586, P1 support by source build.

      Leaving aside everything else that's wrong with what you said.

      If it's in the source tree and has to be maintained what does building GENERIC without it buy you? Also this would break the model of having obsd "just work" on some of the very most popular platforms around. So it better be a -huge- payoff.
      >
      >
      >

      Comments
      1. By Anonymous Coward (201.52.99.177) on

        > Leaving aside everything else that's wrong with what you said.

        Iīve repeated many times: this was MY use of OpenBSD 4.1 on old hardware.
        And MY opinion on theme.

        > If it's in the source tree and has to be maintained what does building GENERIC without it buy you? Also this would break the model of having obsd "just work" on some of the very most popular platforms around. So it better be a -huge- payoff.

        I like the OpenBSD project and use it everyday by years now.

        But I donīt have to agree with every decision or current model taken
        by the core developers.

        Maintaining support to very old hardware on default install is one
        of then.

        Not having binary patches to the GENERIC kernel is another one.

        Comments
        1. By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng

          > > Leaving aside everything else that's wrong with what you said.
          >
          > Iīve repeated many times: this was MY use of OpenBSD 4.1 on old hardware.
          > And MY opinion on theme.
          >
          > > If it's in the source tree and has to be maintained what does building GENERIC without it buy you? Also this would break the model of having obsd "just work" on some of the very most popular platforms around. So it better be a -huge- payoff.
          >
          > I like the OpenBSD project and use it everyday by years now.
          >
          > But I donīt have to agree with every decision or current model taken
          > by the core developers.
          >
          > Maintaining support to very old hardware on default install is one
          > of then.
          >
          > Not having binary patches to the GENERIC kernel is another one.
          >
          Yes, my question was -why- do you disagree with this? It was clear that you don't. Actually on both points.

    3. By Andreas van Cranenburgh (82.93.92.62) on https://unstable.nl

      > My oldest 4.1 machines are 366/400 MHz K6-II, on my lab.

      I believe that would be a 586. I've had a few of those in the past. As a matter of fact I still run 586, but now the one on my VIA Epia (600 MHz).

    4. By RC (71.105.202.112) on

      > The i386/i486 PCs donīt have PCI buses, so you must use
      > old 10 Mbits ISA network cards on it.

      468 mobos often had a couple PCI slots.

      For 386s, ISA maxes-out at about 25Mbps, not 10. I have a 100Mbps ISA card that still works (3C505 IIRC). A few "overflow" errors in the syslog, but it works just fine.

      > Itīs almost impossible to use it on a decent home network,
      > that must have 54 Mbits at least.

      There's little reason for an internet gateway box to be faster than the line-speed of the modem.

      > 10 MBits are not enough even for a cable network or a
      > 802.11B gateway.

      802.11b is only 11Mbps max, which is close enough to 10Mbps that no one should notice.

      And where do you live that cable internet services commonly offer more than 10Mbps?. In any case, it's up to the user to decide what equipment is fast enough for their needs.

      > For desktops and simple firewalls on PCs, i586 or P1 seems
      > to be a minimum to me.

      My 20MHz 386 made an acceptable firewall/router... until about 2003 when it died. Now I'm using a 586, but underclocked to about 100MHz so the entire system uses ~10Ws, and with load averages below 0.20, it's much more than enough even for my purposes.

      Comments
      1. By Shane J Pearson (59.167.252.29) on

        > > Itīs almost impossible to use it on a decent home network,
        > > that must have 54 Mbits at least.
        >
        > There's little reason for an internet gateway box to be faster than the line-speed of the modem.
        >
        > > 10 MBits are not enough even for a cable network or a
        > > 802.11B gateway.
        >
        > 802.11b is only 11Mbps max, which is close enough to 10Mbps that no one should notice.
        >
        > And where do you live that cable internet services commonly offer more than 10Mbps?. In any case, it's up to the user to decide what equipment is fast enough for their needs.


        My ADSL2+ provider gives 24Mbit/s down, 2.5Mbit/s up (I realise this is not what people commonly refer to as "cable"). Given the distance from my exchange and the quality of the lines, I only connect at a line speed of 15Mbit/s and get 12+Mbit/s in real world downloads (plus 2.2Mbit/s up). A friend of mine with the same provider, gets 19Mbit/s in real world downloads.

        In some countries, I hear that 100Mbit/s to the home is available. Home Internet access speeds are starting to go beyond 10Mbit NICS.

  7. By Anonymous Coward (207.148.178.250) on

    I'm running a p200mmx as an internal packet filter/router between to networks with a couple of fxp pci cards and 64megs of ram (intel 439TX). It's running 3.8 still because it didn't appriciate the apm code in 3.9 / 4.0

    I can't wait to try a snapshot of 4.1 on it after the hackathon is over. Keep up the good work OpenBSD Team!

  8. By Chris (80.176.91.102) chriswareham@chriswareham.demon.co.uk on

    The oldest PC architecture machine I have is a 486. It's got NetBSD on it, although it ran OpenBSD 2.6 for a while. I don't use it anymore, but with its dual NE2000 network cards it used to serve as my firewall machine.

    It's a bit of a coincidence that 386 support has come up though, as I considered bidding on a Sun i386 Roadrunner that was for sale on eBay today. I didn't go for it in the end, but had I done then I would have been interested to see if I could get a BSD running on it. From what I could find out, it's a weird hybrid with features of a late model Sun3 workstation.

  9. By timethy (71.182.71.92) on

    All the people whining about 386 support have probably never set up a real 386 machine before ... make a FreeDOS disk if you want to play with something that old!

    My low-end OpenBSD machine is a P-II 200mhz dual proc.

  10. By TylerEss (12.147.197.133) on

    The last time I ran OpenBSD on a 386 was back in 2000, when I revolutionized our network by adding "adventure" to inetd.conf. The internet line was (much) faster than the 386's ability to gunzip and the install stalled repeatedly. A "custom" mirror with an unzipped distro did the trick.

    It's sad to see 386 support go, but less cruft in the kernel is a good thing. These days, if you really want to run OBSD on your 386, you're probably enough of a hacker to forward-port the 386 support.

    I'll wait a year to see the undeadly story bragging about installing 4.3 on a 386... :-)

  11. By Anonymous Coward (156.34.75.11) on

    My oldest OpenBSD machine is a 486dx33 ... but its main purpose it to be a monitor stand. My actually day-to-day desktop is a Pentium III 450 ... and honestly it is fast enough running OpenBSD that I have no particularly compelling reason to upgrade it -- all computers wait at the same speed.

  12. By Anonymous Coward (200.5.117.242) on

    For the record, my only OpenBSD machine is a 486/DX100 with 48MB of RAM and its main purpose is to run PF at home:

    cpu0: Intel 486DX (486-class)
    real mem = 49905664 (48736K)
    avail mem = 37015552 (36148K)

    JC

Latest Articles

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