3 ms·

It's awesome that NetBSD can be ported and run on so many wildly different platforms, but do they actually work? I can't seem to figure out if the releases are

It's awesome that NetBSD can be ported and run on so many wildly different platforms, but do they actually work? I can't seem to figure out if the releases are installed on actual hardware as part of the release process? Some of the tier II platforms are pretty exotic, and there cannot be that many working VAX or Cobalt Microservers machines around anymore.

nortonham 4y ago
I think for each tier II arch it can be installed but the extent to which they work varies.
johnklos 4y ago
If there's hardware out there, then people are running NetBSD on it. It comes in handy even when people aren't running it as their primary OS. For example, you can netboot NetBSD on your VAX to image disks, to communicate with modern servers and modern peripherals, et cetera, which would be a bit harder with legacy OSes. As it happens, I run NetBSD on a Cobalt which builds NetBSD mipsel pkgsrc packages: https://twitter.com/AnachronistJohn/status/1556386525889175552 https://twitter.com/AnachronistJohn/status/15563865258891755... I also run NetBSD on some VAXen, also to build pkgsrc packages: https://twitter.com/AnachronistJohn/status/1462475158791274503 https://twitter.com/AnachronistJohn/status/14624751587912745... NetBSD might not have the best public visibility, but for those of us who appreciate a clean, consistent OS that runs the same on whatever hardware we choose, it's wonderful. If you have an older machine you'd like to keep running, you may end up discovering that NetBSD is preferable to trying to keep some no longer supported Linux variant up and running. Even for modern hardware, it can be preferable - cleaner, smaller, without gratuitous changes from one version to the next...
- sillywalk 4y ago
  Out of curiosity, a) how long does it take to build all those packages? b) how are the cobalt and VAXen specced out?
  - johnklos 4y ago
    It takes a LONG time, depending on the machine(s) and architectures. pkgsrc has quarterly releases (2022Q1, 2022Q2, and so on). Alpha and UltraSPARC are fast and finish in a month or two, and can build any updates after the first run. SPARC (running on an UltraSPARC Sun Fire V100) and mips64eb (running on an EdgeRouter Lite) finish before the end of the quarter now and then, but I don't count on it. earm and earmv4 may get to the point where they can finish before the end of a quarter because it's trivial to add additional machines, but I haven't had the time or resources to do that yet. Also, there's an issue with distcc and earmv4 I haven't figured out yet. mipsel (Cobalt) and sh3el (Landisk) are not slowpokes, but are run as best effort. The Cobalt is a 250 MHz Cobalt RaQ2 with 256 megs of memory and a 500 gig SATA drive, and the SuperH machine is a 266 MHz SH4 with only 64 megs of memory and a 160 gig IDE disk. Both make use of distcc to help speed compiles. m68k is done by a small cluster of machines: a 1U Amiga 1200 with a Blizzard 1260 (50 MHz m68060), 256 megs of memory, and an SSD on a SATA-IDE, then an IDE-SCSI adapter, two Quadra 605 with 132 megs, two Quadra 610s with 260 megs, and two Quadra 800s with 264 megs. Two of those Macs aren't quite stable yet, but should be fully fixed for the next run. VAX is done by a VAXstation 4000/90 with 128 megs and a 4000/60 with 104 megs, both with fast, modern disks on SATA-IDE-SCSI adapters. Some staging and testing is done using a virtual VAX in simh, but as much actual work as possible is done on real hardware. None of mipsel, sh3el, m68k nor vax are expected to finish a quarter before the quarter is up, but with added hardware and improvements to methods for helping them, more and more packages will be done before the quarters are up. Also, many of a previous quarter's packages are still up to date in the next quarter, so reusing old packages helps lots. Everything is shared using a Raspberry Pi 4 with USB-3 hardware mirrored disk which is running as an NFS server and is also doing distcc for several of the architectures.
    - sillywalk 4y ago
      Wow, thanks for that detailed reply, I'd wondered about old disks. Also, it's impressive it just runs for that long. Also, also that seems like a small amount of RAM for compiling things these days (though I remember compiling a slackware kernel on a a 486 with 8mb of ram.). I'm assuming it's an older version of gcc
eschaton 4y ago
You’d be surprised! I have a lot of vintage hardware, and run a NetBSD server primarily as a way to boot it up over the network in either its original operating system or to run NetBSD. For example, I have some Sun-3 and Sun-4 (pre-SPARCstation) systems on which I’ll run both NetBSD and SunOS, some VAX and HP hardware where I’ll use netbooted NetBSD to image internal or attached disks, etc.

nortonham 4y ago

I think for each tier II arch it can be installed but the extent to which they work varies.

johnklos 4y ago

If there's hardware out there, then people are running NetBSD on it. It comes in handy even when people aren't running it as their primary OS. For example, you can netboot NetBSD on your VAX to image disks, to communicate with modern servers and modern peripherals, et cetera, which would be a bit harder with legacy OSes. As it happens, I run NetBSD on a Cobalt which builds NetBSD mipsel pkgsrc packages: https://twitter.com/AnachronistJohn/status/1556386525889175552 https://twitter.com/AnachronistJohn/status/15563865258891755... I also run NetBSD on some VAXen, also to build pkgsrc packages: https://twitter.com/AnachronistJohn/status/1462475158791274503 https://twitter.com/AnachronistJohn/status/14624751587912745... NetBSD might not have the best public visibility, but for those of us who appreciate a clean, consistent OS that runs the same on whatever hardware we choose, it's wonderful. If you have an older machine you'd like to keep running, you may end up discovering that NetBSD is preferable to trying to keep some no longer supported Linux variant up and running. Even for modern hardware, it can be preferable - cleaner, smaller, without gratuitous changes from one version to the next...

sillywalk 4y ago
Out of curiosity, a) how long does it take to build all those packages? b) how are the cobalt and VAXen specced out?
- johnklos 4y ago
  It takes a LONG time, depending on the machine(s) and architectures. pkgsrc has quarterly releases (2022Q1, 2022Q2, and so on). Alpha and UltraSPARC are fast and finish in a month or two, and can build any updates after the first run. SPARC (running on an UltraSPARC Sun Fire V100) and mips64eb (running on an EdgeRouter Lite) finish before the end of the quarter now and then, but I don't count on it. earm and earmv4 may get to the point where they can finish before the end of a quarter because it's trivial to add additional machines, but I haven't had the time or resources to do that yet. Also, there's an issue with distcc and earmv4 I haven't figured out yet. mipsel (Cobalt) and sh3el (Landisk) are not slowpokes, but are run as best effort. The Cobalt is a 250 MHz Cobalt RaQ2 with 256 megs of memory and a 500 gig SATA drive, and the SuperH machine is a 266 MHz SH4 with only 64 megs of memory and a 160 gig IDE disk. Both make use of distcc to help speed compiles. m68k is done by a small cluster of machines: a 1U Amiga 1200 with a Blizzard 1260 (50 MHz m68060), 256 megs of memory, and an SSD on a SATA-IDE, then an IDE-SCSI adapter, two Quadra 605 with 132 megs, two Quadra 610s with 260 megs, and two Quadra 800s with 264 megs. Two of those Macs aren't quite stable yet, but should be fully fixed for the next run. VAX is done by a VAXstation 4000/90 with 128 megs and a 4000/60 with 104 megs, both with fast, modern disks on SATA-IDE-SCSI adapters. Some staging and testing is done using a virtual VAX in simh, but as much actual work as possible is done on real hardware. None of mipsel, sh3el, m68k nor vax are expected to finish a quarter before the quarter is up, but with added hardware and improvements to methods for helping them, more and more packages will be done before the quarters are up. Also, many of a previous quarter's packages are still up to date in the next quarter, so reusing old packages helps lots. Everything is shared using a Raspberry Pi 4 with USB-3 hardware mirrored disk which is running as an NFS server and is also doing distcc for several of the architectures.
  - sillywalk 4y ago
    Wow, thanks for that detailed reply, I'd wondered about old disks. Also, it's impressive it just runs for that long. Also, also that seems like a small amount of RAM for compiling things these days (though I remember compiling a slackware kernel on a a 486 with 8mb of ram.). I'm assuming it's an older version of gcc

eschaton 4y ago

You’d be surprised! I have a lot of vintage hardware, and run a NetBSD server primarily as a way to boot it up over the network in either its original operating system or to run NetBSD. For example, I have some Sun-3 and Sun-4 (pre-SPARCstation) systems on which I’ll run both NetBSD and SunOS, some VAX and HP hardware where I’ll use netbooted NetBSD to image internal or attached disks, etc.