Am I the only one feeling a little bit disappointed with some of the software versions listed there?
I don't use NetBSD, so perhaps I'm not in "the loop", and please forgive me if so, but;
- GCC 5.5 is only one major version higher than the oldest supported version; 6 or 7 would have been a better choice while you're banging out a whole new operating system release, 6 is still fully supported, 8 was released early this year. I understand newer compilers can sometimes introduce regressions in the build process for something as large as an entire operating system, but surely they could have tested it and gotten those bugs fixed if any?
- Similarly for Clang/LLVM 3.8.1 (Really? The oldest version of Clang that you can get on a modern Linux distro? Really?).
- OpenSSL 1.0.2 is only supported for another 17 months, 1.0.2k (the version they're shipping) is 3 versions older than the current 1.0.2o, and 1.0.2p is going to be released any day now. There are at least 4 CVEs patched between 1.0.2k and 1.0.2o; I hope they're applying those patches on top of 1.0.2k manually.
The comparison to "oldest clang/gcc you can get in a linux distro" is not right, you can get a lot of different versions as packages. this refers to the base compiler which is used to build everything. GCC 8.1 is available as a package for example.
As for the base GCC versions, NetBSD is a little conservative when updating, but keep in mind that it's doing this on a lot of architectures and problems arise. a complete transition to GCC 5.x was held back somewhat by a tricky mipseb-softfloat bug, GCC 6.x (in -current) was held back by a VAX ICE. Newer GCC kills ARMv4-nonthumb support.
If that is OpenSSL 1.0.2k it probably should be updated, yeah.
Some of those architectures really need to be allowed to die. VAX was discontinued in 2000 and was on life support since 1992 when it was superseded by the Alpha.
If it were free it wouldn't matter, but as you say its held up progress on architectures people actually use.
The way netbsd does GCC updates gives a really wide margin for figuring out compiler issues:
- Copy existing compiler into gcc.old
- Add new compiler as "gcc"
- Switch architectures one by one
If one architecture is left behind it's not a big pressing issue, you have until the next GCC update. They're done once 2-3 years hopefully so the GCC VAX issue taking 6 months to resolve wasn't close to being a problem.
As for removing architecture support, as long as it builds without extreme intervention, the non-VAX crowd is going to leave it alone. The VAX code is mostly separate in its own directory so doesn't get in the way.
The people who care about VAX within NetBSD are very knowledgeable and it would be a shame to alienate them without a good reason. They've contributed a lot of non-VAX stuff too.
Like I said, NetBSD is obsolete. Only useful for old neckbeards who want to run old and already dead computers/machines and don't care how much they pay for that power eating hardware.
I didn't realize NetBSD was that far behind on some basic features like USB support.
"The Linux kernel mainline contains support for USB 3.0 since version 2.6.31, which was released in September 2009"[1]. "FreeBSD supports USB 3.0 since version 8.2, which was released in February 2011.".
So they're getting USB 3.0 almost 10 years after it was released for Linux.
Linux also had USB 3 draft support before there were even any consumer products on the market. Intel engineers wrote the XHCI driver for Linux, well before developer documentation was available publicly.
It was added to other operating systems as the hardware became more readily available, understandably it took some time. USB 3.0 is not simple to implement.
Playing armchair software architect here, I wish NetBSD and FreeBSD would join forces. The NetBSD developers could bring their portable architecture to FreeBSD's more featureful kernel and userland. What other value does NetBSD have over FreeBSD besides portability?
IIUC, macOS uses NetBSD's userland though it has FreeBSD bits in its XNU kernel, so there must be benefits to NetBSD beyond its portability that I am just not aware of. :)
Just based on history and culture, that sounds like a really awkward combination. It's trying to merge "run on every imaginable platform at all costs" with "fuck all the platforms and let's concentrate on building a rock solid operating system for the x86 because that's the only thing people use anyway."
The kernel? Or a full-blown OS like Debian GNU/Linux? Official ports, or also unofficial ports?
If you're going for official Debian GNU/Linux ports, then no. If you mean Fedora (say you really wanna run Fedora), then no.
NetBSD isn't just a kernel; it is a full-blown, portable OS. The base system is practically the same on every port. So if you're familiar with NetBSD, the idea is that you can always run that familiar OS on another computer.
The BSD organizations of today are more about researchers making an operating system for OS research as a field and less hacker idealists trying to bring a free OS to the people. Nearly all of the latter people go to Linux these days.
If researchers are working on NetBSD, wouldn't it be receiving more novel improvements? Everything in this changelog looks like stuff other OS's have done before. How is that research?
It isn't a zero sum game with a finite number of FOSS idealists. Linux's popularity grew rapidly in what were previously proprietary software users. It didn't take away that much from BSDs.
Linux and other FOSS software becoming popular makes using NetBSD a lot more convenient, not less. There's a top tier FOSS browser that will accept NetBSD related patches, several really good document editors, graphical tools. We can even take some driver code from Linux itself.
Also, isn't 3.0 fully backward compatible with 2.0? I imagine this would affect how critical people would classify support to be developed, if everything already works, just slower.
It's backwards compatible on the device side (you can plug a 3.0 device into a 2.0 port and work at lower speed). But I really doubt that you can use an xHCI controller through EHCI drivers.
> But I really doubt that you can use an xHCI controller through EHCI drivers.
Indeed, you can't. xHCI subsumes all USB operation and doesn't need companion controllers, but presents a _very_ different interface. That's different from the USB1/2 transition where USB2 was a separate controller that could take over the ports from a USB1 controller, giving them back if a USB1 device is attached.
Some boards/chipsets do that with EHCI and xHCI to support operating systems without xhci drivers, but that's getting rarer.
I'm fascinated this has worked so well in all operating systems I've used that I've never had reason to acquire this knowledge.
I'm simultaneously disappointed that this is not (as far as I can tell) widely known information. It sounds like the thing that may prevent you from going on goose chase if you ever need to debug it.
As soon as you write an USB controller driver, you'll stumble over that quickly. The EHCI and XHCI specs are freely available and describe this in detail. It's just that only few people need to write such drivers. :-)
As for it working so well, that's mostly on the EE side: they were _very_ careful to provide this hardware based routing with defaults that make sure that old OSes continue to work while new OSes (or new drivers for old OSes) can make use of the new controllers.
The USB 3.2 standard is backward compatible with USB 3.1/3.0 and USB 2.0. It defines the following transfer modes:
USB 3.2 Gen 1x1 - SuperSpeed, 5 Gbit/s (0.625 GB/s) data signaling rate over 1 lane using 8b/10b encoding, the same as USB 3.1 Gen 1 and USB 3.0.
USB 3.2 Gen 1x2 - SuperSpeed+, new 10 Gbit/s (1.25 GB/s) data rate over 2 lanes using 8b/10b encoding.
USB 3.2 Gen 2x1 - SuperSpeed+, 10 Gbit/s (1.25 GB/s) data rate over 1 lane using 128b/132b encoding, the same as USB 3.1 Gen 2.
USB 3.2 Gen 2x2 - SuperSpeed+, new 20 Gbit/s (2.5 GB/s) data rate over 2 lanes using 128b/132b encoding.
USB 3.2 is supported with the default Windows 10 USB drivers and in Linux Kernel 4.18.
A lot of NetBSD platforms predate USB3, so presumably not an effect. Keep in mind it runs on very old stuff like the Dreamcast and OMRON LUNA and very small stuff like tiny ARM boards and MIPS routers.
This release of NetBSD disables eagerfpu on vulnerable FPU’s.
Often overlooked while discussing performance impact of context switching; context switching also applies to the FPU. There are two modes in which the OS performs FPU context switching: lazy and eager.
“lazy” FPU context switching leaves the previous context on the FPU until a different context gives it a set of instructions. This saves an unload on the FPU, since not all time splices require the FPU, you may see some performance gains under some application workloads.
“Eager” FPU context switching unloads FPU context whenever a time splice is finished. On a new time splice, the FPU context is reloaded. While this constant reloading of context sounds more expensive, it is optimized in hardware and almost never noticeable on modern architectures.
By default eager FPU is enabled in Linux. You can test its’ impact by passing the eagerfpu=on or eagerfpu=off boot flags (Linux).
Kudos to the NetBSD team for enabling/disabling eager FPU based on FPU model instead. This approach makes more sense to me.
Lazy FPU state restoration almost never makes sense on modern CPUs (regardless of security issues) because the cost of an interrupt for state restoration is so high and because "FPU" registers are used for a lot more than just FP calculations these days.
NetBSD was my first BSD and OS development experience in my teens. I'm fairly entrenched in the FreeBSD camp for commercial reasons now after a very long run as a Linux user, but there is some nice security stuff in here and happy to see NetBSD chugging along! Congrats!
Classifying the BSDs into "performance", "security", and "portability" has as little meaning as classifying people into blondes, brunettes, and redheads. It's trite and superficial, and not really how they differ.
They differ in their development models, families of related operating systems (consider TrueOS, DragonFly, MirOS, et al.), ports and packages mechanisms, extent of kernel APIs, filesystems, and toolsets.
Just three out of many examples:
* NetBSD's and OpenBSD's "wscons" subsystem for kernel virtual terminals is significantly different to FreeBSD's "syscons"/"vt" subsystem.
* OpenBSD's packing list files for pkg are different to FreeBSD's manifest files for pkgng.
* On OpenBSD, /bin/sh is the Korn shell, which is also the superuser's standard interactive shell, and the base toolset contains things such as doas and rcctl. On FreeBSD, /bin/sh is the Almquist shell, the superuser's standard interactive shell is the C shell (and the "toor" user exists), things like sudo come from ports, and the command for manipulating rcconf files is sysrc. /bin/sh is the Almquist shell on NetBSD, and the PD Korn shell on MirOS.
> The “BSD” in our name is an obvious recognition of our heritage as a derivative of 4.4BSD and 386BSD.
> Our contributors communicate primarily via email and Internet-based chat systems; many of us have never met each other in person. We also use a remote source code management system called CVS which enables a large number of developers to do independent work on the same source tree easily. We believe that the Internet was an enabling technology that made NetBSD possible. The “Net” in our name was thus chosen as a tribute to the Internet.
Also, just as an aside, NetBSD was released in 1993, long before network security had anywhere near the attention it has today.
It has been my primary for ~16 years, and I’ve been running -current (tip of development branch) for nearly 10 years. Base system (which includes tmux[0]), X11 (which is optional, but maintained by NetBSD), dwm[1], Tcl[2] cURL[3], fossil[4] and Firefox and I’m usually on my way...
Perceived balance of Unix tradition, progressiveness and sane engineeering/community.
The base build system (build.sh)[0] which is essentially Makefiles is absolutely beautiful to work with, ditto for pkgsrc[1]. They’re “progressive” enough to include dtrace[2], work on neat security[3], and kernel models[4][5], but have eschewed modern Linux-isms like ip(1), systemd. Of BSD v Linux, my heart is definitely with the more traditional BSD. Of BSDs, I feel Net is capable enough, simpler than Free, but more feature full than Open. The other interesting BSD would be DragonFly - really interesting, but I’m happy enough w Net that I’m not going to swap it out, and don’t need more (different) systems in my life right now.
Additionally, it’s not windows, not MacOS, and not Linux. It’s difficult to escape those in day-to-day computing, so my daily driver (thinkpad laptop) is slightly different on purpose, the idea being that, to a degree, everything I do is necessarily very “conscious”. What I mean is that nothing works automatically because I’m part of a vast majority. Where I run into friction, I try to take note and keep this in mind with the rest of my relationship with the world, whether it’s developing software, or making assumptions about the way people use computers.
I often cite Neil Young to describe my “ditch”[0] computing.
I also run NetBSD (mostly on servers, but occasionally PCs as well). I can relate to this. Difference is good; it helps challenge assumptions. Running different operating systems is good for the same reason as testing websites on different browsers is, or having things tested by disabled people for accessibility, or visiting foreign countries and learning about different cultures.
One of my NetBSD machines is an UltraSPARC box. I've heard both NetBSD and OpenBSD devs say it's one of their favourite platforms, because being a big-endian 64 bit machine, it helps discover many false assumptions made in low level code.
This is another good point that I think can’t be overstated (running on big-endian or otherwise non-x86 arch). Support the unconventional and it supports you back. It’s a fun, positive feedback loop.
I love this approach and analogy. You're absolutely right: it's incredibly hard/impossible to _not_ make assumptions when you're part of the herd.
I'd like to think there can be enormous payoffs to this kind of careful thinking, but I suspect it pays out sporadically and sometimes not at all. Such is the fate of any outlier or pioneer.
Either way, traveling "in the ditch" means you get a lot of weird looks from people cruising by on the latest bandwagon. :-)
Can you go a bit more in detail why Net vs Free? I would LOVE to replace Linux (Fedora) with one of the BSD's. It's philosophy and everything basically suits me far more than anything else, but I need CUDA, I need Nvidia drivers, I like to play with ML, I need few more things like that which makes it a no go as far as I'm aware.
You probably have a herculean challenge ahead with the Nvidia / CUDA stuff. A couple years ago I got an R stack up and going on OpenBSD, and that took some deep dives to get all my packages working. It was rewarding and worked well, but it wasn’t something I’d do under deadline.
NVidia on the other hand seems like a far harder problem than needing to patch some C code here and there. NVidia make the drivers that they make. AMD has been more open source friendly these days, which is good if you want 3D graphics, but doesn’t solve the CUDA issue.
Forgive me if you've already heard this a lot, but Slackware is often described as being a very "BSD-like" Linux and might be another way to get some of the philosophy you're seeking.
I've been using Slackware as my main desktop OS for a few years now (on my main personal and work laptops, plus my primary desktop; most of my other machines run OpenBSD, with the notable exceptions of one running Haiku and one currently running 9front). So far I've been overwhelmingly happy with it.
Indeed, Slackware, Void, or Arch. Or since the parent poster seems to be somewhat into scientific computing, NixOS could also be interesting. NixOS is like having virtualenvs for everything.
I'm in creative, but do a lot of graphics and video programming and research for fun and profit, as well as programming for the fun of it! One of these days I'm going to try Qubes OS and try playing with different OS' at the same time!
I've got a lot of netbsd running machines. The one I use now is a Haswell CPU with nvidia graphics, and everything works well on it (even nvidia graphics!).
Not all machines are so good. I have a too new Dell XPS. It doesn't have graphical acceleration. But it was very cool to have the touchscreen working already (although with rough edges).
It's very easy to build and modify everything, it doesn't hide errors under a rug (syslog messages are legible, coredumps not disabled by default and so on), so I feel like I can tackle any problem I encounter on it.
Also, if you're the type that carries their long .xinitrc/.Xresources/.profile around, it's more comfortable than the friendly linuxes which require you to re-do everything but in dconf.
Wasn't NetBSD 8 supposed to have zfs? Last time I read something about it, it sounded like it was practically finished. But the release notes do not mention it at all.
I somewhat realize that availability of good pmax emulators is the reason. MIPS being far from dead platform is not that much relevant as the announcement explicitly singles out pmax and does not mention platforms like evbmips or sgimips.
it's probably a mistake that it got enabled there, I don't think the architecture has support for it. Even the edgerouter shouldn't, but don't quote me on it.
A podcast I recently heard - hosted by long-experienced Linux hands - reported that installing BSD was a nightmare. Some discussion of which distros avoid that nightmare might be helpful.
I started playing with OpenBSD 6.3 as a desktop (actually laptop) OS a couple of months ago. Installation was very straightforward. In my case I used the whole disk, no dual boot.
Here's a tribute/introduction written by Derek Sivers:
As for my own experience, I don't know if I'm ready to give up Debian as my primary desktop OS, but I really like OpenBSD on my coding-or-surfing-on-the-couch laptop.
On the server side, I also use both (as VPS) for personal projects.
I've just improvised my way through a netBSD install on an old thinkpad X60 with 1Gb ram and a mechanical hard drive, whole disk, defaults mostly. Seems generally quite similar to OpenBSD (which makes sense given OpenBSD is a fork from netBSD).
$PKG_PATH is set up but commented out in the .profile for root. I'm going for a light window manager and Seamonkey and a few bits and pieces to see how the land lies.
> (which makes sense given OpenBSD is a fork from netBSD)
... Over 20 years ago. Over almost the exact same time period NeXTSTEP became OSX. Any similarities are probably more coincidental or due to on-going borrowing from each other than to do with the fact that one is forked from the other.
Building packages can't start until the final release build of the base Operating System has been done, things like LibreOffice depend on a lot of other things. Maybe check again in a couple of days.
The one BSDish distro with an easy GUI installer and desktop friendly settings was TrueOS which is undergoing a metamorphosis at the moment.
For the most part you can just hit enter through the installer for any of them and have a working system. To set up a graphical environment you will need to do a little reading. I would generally say any of the BSDs are easier than Arch and Gentoo to set up but offer similar capabilities if you dig in. Slightly harder than Debian text installer, maybe 1:1 with slackware.
To set up a graphical environment you will need to do a little reading.
That was the gist of their complaint. I'm guessing that since these guys (one uses Arch) both worked their way through LF-Scratch last year, they're not up to more reading right now.
Installing NetBSD is not for the faint of heart, but installing Arch Linux is a lot harder, if that is helpful. I would say it is a little harder than Debian, unless you want to cover exotic scenarios like a diskless workstation.
It depends on whether 'installing' only means the installation or the installation and configuration of hardware. Because once you have installed Arch, configuration is probably easier on the average machine due to wider hardware support.
It's been a while since I installed NetBSD, but the last time, on-board sound wouldn't work without kernel driver patches. And hardware-accelerated OpenGL on a modern GPU was unsupported.
(That said, I used NetBSD as my desktop OS besides Slackware Linux from ~2001-~2005, and it is an exceptionally clean and nice Unix.)
This may be a little rusty, but from ~2002 to ~2008, I ran my modest home server on NetBSD.
Why did I choose it? Because at the time, I was still living with my parents and needed to get Internet access working via dial-on-demand ISDN-card. The only OS I found a tutorial for how to do that was NetBSD.
What were my impressions? Compared to, say, Debian, NetBSD takes more effort on the side of the user/sysadmin. But once something was in place, it stayed in place. I also liked the clear distinction between the base system and third-party software installed via pkgsrc (which ends up in /usr/pkg). These days, NetBSD has binary packages for the most mainstream architectures, so it less of a problem.
I liked the system - it was simple enough to get a realistic idea of what is going on under the hood, even for a Unix-newbie, but also powerful enough that it did not stop there. Also when a friend of mine got me a Sun SparcStation he had salvaged from his university's garbage pile, NetBSD was the only system I could get to boot on that machine.
Yeah I have, but that happened 1 or 2 decades ago so take it with a grain of salt.
NetBSD's strength is portability (or "ports" not to be confused with FreeBSD's ports collection). So any software written for it, is going to have portability in high regard. If you don't want to live in a monolithic world (example: the PC world went towards x86-32 in 90s, then shifted away to AMD64. ARM/ARM64 are market leader in embedded industry, though MIPS is also still being used) and if you believe in postmarket options (devices shipped with proprietary firmware/OS) though Linux is also strong in that regard. If you like RISC-V existence, software such as NetBSD helps its existence.
Yes, I had hardware on which of recent software basically only NetBSD ran on, or maybe a (broken/outdated) proprietary OS, or "Linux" (but some vague old port, or requiring patches, blahblah). It could be old/ancient hardware, proprietary firmware, obscure hardware. I ran NetBSD for example on Sharp Zaurus, various SGI MIPS (some of which Linux worked less good or not at all on), DEC Alpha (at least a DS10L), and various Sun hardware. The orig. Sharp Zaurus firmware for that specific Zaurus was in Japanese, and the OpenBSD port I couldn't get to work. So I experimented with a lot of alternative firmware, mostly based on Linux.
Back then the package management was slightly different than the other two popular BSDs. They work together a lot, but there's also fractures. For example, FreeBSD and NetBSD don't have unveil, but they do have PF these days. ZFS has been stable on FreeBSD for ages, yet on OpenBSD it isn't available and on NetBSD its only in -CURRENT. Another difference could be amount of binary packages available, or amount of packages/ports (terminology differs per *BSD).
Another choice could be that the BSD license is more attractive than the more strict Linux-related licenses such as GPLv2 or GPLv3.
So yeah, in short, strong focus points of the 3 major BSDs:
Popularity (amount of software, size of community): FreeBSD
Security: OpenBSD
Portability: NetBSD
DragonFly: I've never used this, ever. Can only speculate. I mean, I'm not sure the orig. focus still matters.
I used it in production along together with Linux at a startup as it was a fairly robust Xen guest circa 2008-11. I was having a ton of stability issues with CentOS and Fedora DomU on PV Xen with CentOS 5 as the dom0. For some reason NetBSD ran great as a DomU on the same Dom0 so I went with it. I liked how Postifx was the base MTA, and was able to configure a useful systems with pkgsrc pretty easy.
The strongest case today is probably for embedded use. build.sh is unlike any other OS build system, you can happily do development of a firmware on a Linux or OS X machine for instance and splat out results for a target device.
It's also one of the better choices for learning about OS development because of build.sh, small size, fairly clean codebase etc. And those skills are fairly transportable to Linux (which is a bit of a fire hose and probably not the easiest to start out on) or commercial operating systems like OS X or real time for a career path.
i have played with it on and off for years. when i was helping with an open source project i used it to test portability. what i really liked it about it was the simplicity. its like you can learn a lot about your own home by traveling somewhere else that is different.
i learned a lot about linking and linker flags by working with it since it didnt use the "standard way", it used something simpler.
This piece of shit is still alive? Wow
!
They've added USB 3.0 support very lately, 10 years behind. And a non-working UEFI which requires you to use the shell instead of sysinst.
NetBSD is a broken and dead shit. Don't use it. Better FreeBSD.
I don't use NetBSD, so perhaps I'm not in "the loop", and please forgive me if so, but;
- GCC 5.5 is only one major version higher than the oldest supported version; 6 or 7 would have been a better choice while you're banging out a whole new operating system release, 6 is still fully supported, 8 was released early this year. I understand newer compilers can sometimes introduce regressions in the build process for something as large as an entire operating system, but surely they could have tested it and gotten those bugs fixed if any?
- Similarly for Clang/LLVM 3.8.1 (Really? The oldest version of Clang that you can get on a modern Linux distro? Really?).
- OpenSSL 1.0.2 is only supported for another 17 months, 1.0.2k (the version they're shipping) is 3 versions older than the current 1.0.2o, and 1.0.2p is going to be released any day now. There are at least 4 CVEs patched between 1.0.2k and 1.0.2o; I hope they're applying those patches on top of 1.0.2k manually.
The comparison to "oldest clang/gcc you can get in a linux distro" is not right, you can get a lot of different versions as packages. this refers to the base compiler which is used to build everything. GCC 8.1 is available as a package for example.
As for the base GCC versions, NetBSD is a little conservative when updating, but keep in mind that it's doing this on a lot of architectures and problems arise. a complete transition to GCC 5.x was held back somewhat by a tricky mipseb-softfloat bug, GCC 6.x (in -current) was held back by a VAX ICE. Newer GCC kills ARMv4-nonthumb support.
If that is OpenSSL 1.0.2k it probably should be updated, yeah.
If it were free it wouldn't matter, but as you say its held up progress on architectures people actually use.
- Copy existing compiler into gcc.old
- Add new compiler as "gcc"
- Switch architectures one by one
If one architecture is left behind it's not a big pressing issue, you have until the next GCC update. They're done once 2-3 years hopefully so the GCC VAX issue taking 6 months to resolve wasn't close to being a problem.
As for removing architecture support, as long as it builds without extreme intervention, the non-VAX crowd is going to leave it alone. The VAX code is mostly separate in its own directory so doesn't get in the way.
The people who care about VAX within NetBSD are very knowledgeable and it would be a shame to alienate them without a good reason. They've contributed a lot of non-VAX stuff too.
"The Linux kernel mainline contains support for USB 3.0 since version 2.6.31, which was released in September 2009"[1]. "FreeBSD supports USB 3.0 since version 8.2, which was released in February 2011.".
So they're getting USB 3.0 almost 10 years after it was released for Linux.
1. https://en.wikipedia.org/wiki/USB_3.0
It was added to other operating systems as the hardware became more readily available, understandably it took some time. USB 3.0 is not simple to implement.
IIUC, macOS uses NetBSD's userland though it has FreeBSD bits in its XNU kernel, so there must be benefits to NetBSD beyond its portability that I am just not aware of. :)
Incidentally, hasn't Linux been ported (eventually) to more architectures than NetBSD has?
The kernel? Or a full-blown OS like Debian GNU/Linux? Official ports, or also unofficial ports?
If you're going for official Debian GNU/Linux ports, then no. If you mean Fedora (say you really wanna run Fedora), then no.
NetBSD isn't just a kernel; it is a full-blown, portable OS. The base system is practically the same on every port. So if you're familiar with NetBSD, the idea is that you can always run that familiar OS on another computer.
Linux and other FOSS software becoming popular makes using NetBSD a lot more convenient, not less. There's a top tier FOSS browser that will accept NetBSD related patches, several really good document editors, graphical tools. We can even take some driver code from Linux itself.
Indeed, you can't. xHCI subsumes all USB operation and doesn't need companion controllers, but presents a _very_ different interface. That's different from the USB1/2 transition where USB2 was a separate controller that could take over the ports from a USB1 controller, giving them back if a USB1 device is attached.
Some boards/chipsets do that with EHCI and xHCI to support operating systems without xhci drivers, but that's getting rarer.
I'm simultaneously disappointed that this is not (as far as I can tell) widely known information. It sounds like the thing that may prevent you from going on goose chase if you ever need to debug it.
As for it working so well, that's mostly on the EE side: they were _very_ careful to provide this hardware based routing with defaults that make sure that old OSes continue to work while new OSes (or new drivers for old OSes) can make use of the new controllers.
- USB-C power delivery
- USB-C alternate modes, such as DisplayPort and Thunderbolt 3
https://en.wikipedia.org/wiki/USB_3.0#USB_3.2
The USB 3.2 standard is backward compatible with USB 3.1/3.0 and USB 2.0. It defines the following transfer modes:
USB 3.2 Gen 1x1 - SuperSpeed, 5 Gbit/s (0.625 GB/s) data signaling rate over 1 lane using 8b/10b encoding, the same as USB 3.1 Gen 1 and USB 3.0. USB 3.2 Gen 1x2 - SuperSpeed+, new 10 Gbit/s (1.25 GB/s) data rate over 2 lanes using 8b/10b encoding. USB 3.2 Gen 2x1 - SuperSpeed+, 10 Gbit/s (1.25 GB/s) data rate over 1 lane using 128b/132b encoding, the same as USB 3.1 Gen 2. USB 3.2 Gen 2x2 - SuperSpeed+, new 20 Gbit/s (2.5 GB/s) data rate over 2 lanes using 128b/132b encoding.
USB 3.2 is supported with the default Windows 10 USB drivers and in Linux Kernel 4.18.
A domino effect perhaps, or the result of finding a niche?
Often overlooked while discussing performance impact of context switching; context switching also applies to the FPU. There are two modes in which the OS performs FPU context switching: lazy and eager.
“lazy” FPU context switching leaves the previous context on the FPU until a different context gives it a set of instructions. This saves an unload on the FPU, since not all time splices require the FPU, you may see some performance gains under some application workloads.
“Eager” FPU context switching unloads FPU context whenever a time splice is finished. On a new time splice, the FPU context is reloaded. While this constant reloading of context sounds more expensive, it is optimized in hardware and almost never noticeable on modern architectures.
By default eager FPU is enabled in Linux. You can test its’ impact by passing the eagerfpu=on or eagerfpu=off boot flags (Linux).
Kudos to the NetBSD team for enabling/disabling eager FPU based on FPU model instead. This approach makes more sense to me.
Actually this release enables eagerfpu on all Intel CPUs, because of CVE-2018-3665 (lazyfpu side channel attack).
From the respective home pages, FreeBSD targets high performance, OpenBSD security, but it is not so clear to me what is the focus of NetBSD.
They differ in their development models, families of related operating systems (consider TrueOS, DragonFly, MirOS, et al.), ports and packages mechanisms, extent of kernel APIs, filesystems, and toolsets.
Just three out of many examples:
* NetBSD's and OpenBSD's "wscons" subsystem for kernel virtual terminals is significantly different to FreeBSD's "syscons"/"vt" subsystem.
* OpenBSD's packing list files for pkg are different to FreeBSD's manifest files for pkgng.
* On OpenBSD, /bin/sh is the Korn shell, which is also the superuser's standard interactive shell, and the base toolset contains things such as doas and rcctl. On FreeBSD, /bin/sh is the Almquist shell, the superuser's standard interactive shell is the C shell (and the "toor" user exists), things like sudo come from ports, and the command for manipulating rcconf files is sysrc. /bin/sh is the Almquist shell on NetBSD, and the PD Korn shell on MirOS.
> Why the name?
> The “BSD” in our name is an obvious recognition of our heritage as a derivative of 4.4BSD and 386BSD.
> Our contributors communicate primarily via email and Internet-based chat systems; many of us have never met each other in person. We also use a remote source code management system called CVS which enables a large number of developers to do independent work on the same source tree easily. We believe that the Internet was an enabling technology that made NetBSD possible. The “Net” in our name was thus chosen as a tribute to the Internet.
Also, just as an aside, NetBSD was released in 1993, long before network security had anywhere near the attention it has today.
[0] https://www.netbsd.org/about/
[1] https://www.netbsd.org/about/#content_name
describing remote software development as if it was novelty
[0] https://en.m.wikipedia.org/wiki/Tmux
[1] https://en.wikipedia.org/wiki/Dwm
[2] https://en.wikipedia.org/wiki/Tcl
[3] https://en.wikipedia.org/wiki/CURL
[4] https://en.wikipedia.org/wiki/Fossil_(software)
The base build system (build.sh)[0] which is essentially Makefiles is absolutely beautiful to work with, ditto for pkgsrc[1]. They’re “progressive” enough to include dtrace[2], work on neat security[3], and kernel models[4][5], but have eschewed modern Linux-isms like ip(1), systemd. Of BSD v Linux, my heart is definitely with the more traditional BSD. Of BSDs, I feel Net is capable enough, simpler than Free, but more feature full than Open. The other interesting BSD would be DragonFly - really interesting, but I’m happy enough w Net that I’m not going to swap it out, and don’t need more (different) systems in my life right now.
[0] https://www.netbsd.org/docs/guide/en/chap-build.html
[1] https://en.wikipedia.org/wiki/Pkgsrc
[2] https://en.wikipedia.org/wiki/DTrace
[3] http://www.netbsd.org/support/security/
[4] https://en.wikipedia.org/wiki/Rump_kernel
[5] https://news.ycombinator.com/item?id=6562611
I often cite Neil Young to describe my “ditch”[0] computing.
[0] http://www.thrasherswheat.org/tnfy/ditch.htm
One of my NetBSD machines is an UltraSPARC box. I've heard both NetBSD and OpenBSD devs say it's one of their favourite platforms, because being a big-endian 64 bit machine, it helps discover many false assumptions made in low level code.
I'd like to think there can be enormous payoffs to this kind of careful thinking, but I suspect it pays out sporadically and sometimes not at all. Such is the fate of any outlier or pioneer.
Either way, traveling "in the ditch" means you get a lot of weird looks from people cruising by on the latest bandwagon. :-)
NVidia on the other hand seems like a far harder problem than needing to patch some C code here and there. NVidia make the drivers that they make. AMD has been more open source friendly these days, which is good if you want 3D graphics, but doesn’t solve the CUDA issue.
I've got a lot of netbsd running machines. The one I use now is a Haswell CPU with nvidia graphics, and everything works well on it (even nvidia graphics!).
Not all machines are so good. I have a too new Dell XPS. It doesn't have graphical acceleration. But it was very cool to have the touchscreen working already (although with rough edges).
It's very easy to build and modify everything, it doesn't hide errors under a rug (syslog messages are legible, coredumps not disabled by default and so on), so I feel like I can tackle any problem I encounter on it.
Also, if you're the type that carries their long .xinitrc/.Xresources/.profile around, it's more comfortable than the friendly linuxes which require you to re-do everything but in dconf.
Openbsd user here:-)
Right now I'm running mwm, emacs, Firefox, NetBeans, a couple of PDF viewers and lots of xterms.
Someone once said:
I just need a bootloader for emacs :-)
I assume this means an x86 machine, correct?
OpenJDK 8 will build for arm as well but it doesn't have a JIT.
On the server side we had it on some old machine with a weird architecture just as a jump host.
The great thing is pkgsrc for package management. I believe you can use it on OS X by now, which was done by the people who make SmartOS.
I can't vouch for how optimized it is; but zfs is definitely there. https://gyazo.com/0f6261cf415b85010fcaa92557d783b4
[Edit: landisk platform are various NAS boxes, so nothing of comparable obsolescence as pmax]
The EdgeRouter devices are MIPS and people are still using Loongson laptops.
Here's a tribute/introduction written by Derek Sivers:
https://sivers.org/openbsd
As for my own experience, I don't know if I'm ready to give up Debian as my primary desktop OS, but I really like OpenBSD on my coding-or-surfing-on-the-couch laptop.
On the server side, I also use both (as VPS) for personal projects.
$PKG_PATH is set up but commented out in the .profile for root. I'm going for a light window manager and Seamonkey and a few bits and pieces to see how the land lies.
... Over 20 years ago. Over almost the exact same time period NeXTSTEP became OSX. Any similarities are probably more coincidental or due to on-going borrowing from each other than to do with the fact that one is forked from the other.
For the most part you can just hit enter through the installer for any of them and have a working system. To set up a graphical environment you will need to do a little reading. I would generally say any of the BSDs are easier than Arch and Gentoo to set up but offer similar capabilities if you dig in. Slightly harder than Debian text installer, maybe 1:1 with slackware.
That was the gist of their complaint. I'm guessing that since these guys (one uses Arch) both worked their way through LF-Scratch last year, they're not up to more reading right now.
It's been a while since I installed NetBSD, but the last time, on-board sound wouldn't work without kernel driver patches. And hardware-accelerated OpenGL on a modern GPU was unsupported.
(That said, I used NetBSD as my desktop OS besides Slackware Linux from ~2001-~2005, and it is an exceptionally clean and nice Unix.)
I have only ever used NetBSD as a server system, so I have no idea what the hardware support on desktop systems is like.
1. Why did you choose it?
2. What are your impressions?
Why did I choose it? Because at the time, I was still living with my parents and needed to get Internet access working via dial-on-demand ISDN-card. The only OS I found a tutorial for how to do that was NetBSD.
What were my impressions? Compared to, say, Debian, NetBSD takes more effort on the side of the user/sysadmin. But once something was in place, it stayed in place. I also liked the clear distinction between the base system and third-party software installed via pkgsrc (which ends up in /usr/pkg). These days, NetBSD has binary packages for the most mainstream architectures, so it less of a problem.
I liked the system - it was simple enough to get a realistic idea of what is going on under the hood, even for a Unix-newbie, but also powerful enough that it did not stop there. Also when a friend of mine got me a Sun SparcStation he had salvaged from his university's garbage pile, NetBSD was the only system I could get to boot on that machine.
NetBSD's strength is portability (or "ports" not to be confused with FreeBSD's ports collection). So any software written for it, is going to have portability in high regard. If you don't want to live in a monolithic world (example: the PC world went towards x86-32 in 90s, then shifted away to AMD64. ARM/ARM64 are market leader in embedded industry, though MIPS is also still being used) and if you believe in postmarket options (devices shipped with proprietary firmware/OS) though Linux is also strong in that regard. If you like RISC-V existence, software such as NetBSD helps its existence.
Yes, I had hardware on which of recent software basically only NetBSD ran on, or maybe a (broken/outdated) proprietary OS, or "Linux" (but some vague old port, or requiring patches, blahblah). It could be old/ancient hardware, proprietary firmware, obscure hardware. I ran NetBSD for example on Sharp Zaurus, various SGI MIPS (some of which Linux worked less good or not at all on), DEC Alpha (at least a DS10L), and various Sun hardware. The orig. Sharp Zaurus firmware for that specific Zaurus was in Japanese, and the OpenBSD port I couldn't get to work. So I experimented with a lot of alternative firmware, mostly based on Linux.
Back then the package management was slightly different than the other two popular BSDs. They work together a lot, but there's also fractures. For example, FreeBSD and NetBSD don't have unveil, but they do have PF these days. ZFS has been stable on FreeBSD for ages, yet on OpenBSD it isn't available and on NetBSD its only in -CURRENT. Another difference could be amount of binary packages available, or amount of packages/ports (terminology differs per *BSD).
Another choice could be that the BSD license is more attractive than the more strict Linux-related licenses such as GPLv2 or GPLv3.
So yeah, in short, strong focus points of the 3 major BSDs:
Popularity (amount of software, size of community): FreeBSD Security: OpenBSD Portability: NetBSD DragonFly: I've never used this, ever. Can only speculate. I mean, I'm not sure the orig. focus still matters.
See also Wikipedia [1]
[1] https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_sy...
The strongest case today is probably for embedded use. build.sh is unlike any other OS build system, you can happily do development of a firmware on a Linux or OS X machine for instance and splat out results for a target device.
It's also one of the better choices for learning about OS development because of build.sh, small size, fairly clean codebase etc. And those skills are fairly transportable to Linux (which is a bit of a fire hose and probably not the easiest to start out on) or commercial operating systems like OS X or real time for a career path.
i learned a lot about linking and linker flags by working with it since it didnt use the "standard way", it used something simpler.
Is that still a thing? I've had netbsd on my weekend to-do list for years but just have never found enough time or motivation.
What's so great about netbsd?
http://netbsd.gw.com/cgi-bin/man-cgi?luactl+8+NetBSD-current http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current
They've added USB 3.0 support very lately, 10 years behind. And a non-working UEFI which requires you to use the shell instead of sysinst.
NetBSD is a broken and dead shit. Don't use it. Better FreeBSD.!
They've added USB 3.0 support very lately, 10 years behind. And a non-working UEFI which requires you to use the shell instead of sysinst.
NetBSD is a broken and dead shit. Don't use it. Better FreeBSD!
NetBSD is a broken and dead shit. Don't use it. Better FreeBSD.
They've added USB 3.0 support very lately, 10 years behind. And a non-working UEFI which requires you to use the shell instead of sysinst.
NetBSD is a broken and dead shit. Don't use it. Better FreeBSD.