That's an impressive changelog. I'm excited about the new ARM SBC drivers and seemingly improved RPKI flow for OpenBGPd. I should try running a toy route server on an RPi4 with OpenBSD/OpenBGPd, or a full DFZ router.
OpenBSD is one of the last really good choices for an operating system, in my opinion. Redhat, the pretentious gnome developers, canonicals latest folly, proliferation of systemd cancer (homed being the latest abomination)... All these things take away from the user's freedom.
Just curious, did he really say "operation system" or was that a typo/auto correct thing in your post?
I ask because I had a coworker/friend years ago from Ukraine and that's what he called it. My other friend and I who worked with him could not get him to say operating system no matter how much we poked at him. Anyway, just like the article itself you brought back a flood of memories so just curious like I said.
I've played with OpenBSD on a VM a couple times and really liked it, but I'd like to use it on real hardware and try and force myself to use it as my main personal system at least for a while as an experiment.
I've often heard that Thinkpads make great OpenBSD laptops. Are there any models in particular the HN crowd would recommend? In terms of my hardware needs, I don't really care about graphics like you'd get with an Nvidia card, but I do need wi-fi since it'd be really hard to set up a wired connection to my router in my current apartment.
I've had great luck with T-series ThinkPads. I'm using a T520 as a daily driver at the moment and I've had no real issues with it. I installed it on an E series laptop a while ago and had issues with sound (this was a few versions ago, probably 6.3, and I was just playing around at the time so I never figured out what the problem was).
Mind you I use this mainly for work so my needs are simple, an editor, a browser, a compiler and the like. The default window manager cwm makes for a simple "desktop" for me and the only thing I use at the moment for work that's not from base is mariadb, vim and firefox (plus dependencies of course). So I don't have a lot of splashy graphics to load or anything like that and don't do video or image editing very often. But even if you do need more, the package repository has a huge selection of programs and in my experience they all just work when installed.
On the other hand I put Battle for Wesnoth on it and although that's not really a very graphics intense game it runs great on the laptop.
Just a slight correction, if you meant the "default" as in the window manager that starts on a freshly installed system: It's not cwm but fvwm. With that said, OpenBSD ships with cwm and it's trivial to switch between the two, but they are very different.
Oh, you're right, I'd forgotten that. I think it's so ingrained in me to copy my dotfiles to a new machine before I do much else that I don't usually ever see fvwm. I always add myself to doas, move some public keys around, install a few packages and then copy my dotfiles before I ever launch X for the first time.
And yes, they are very different. I remember using fvwm fondly on Slackware Linux back in the mid 90's. I had hours of fun trying to configure it to look like Windows 95 and populating menus, all in a plain text file, no gui config available! I think I read somewhere recently that fvwm is still Theo's preferred WM and that's why it's the default...
> I remember using fvwm fondly on Slackware Linux back in the mid 90's.
Same, well late 90s here, and yep that was my go-to on Slackware, mostly because it was quite usable out of the box. I eventually went to Blackbox, then Fluxbox, then Gnome about six months before Pat decided to stop shipping it. I went to Xfce from there and never looked back (I never liked KDE before Plasma, and 4.x is still the default in Slackware).
I think bluetooth might work with a few specific adapters, pretty sure there was a comment saying as much in the “Carmack helping OpenBSD” thread yesterday. So I guess that, if you’re willing to sacrifice a USB port or two, it could work.
My reservations are more about sleep (even Linux still struggles with that) and power management (ditto). If my daily driver were a tower desktop, I’d probably use OpenBSD.
I've been using OpenBSD in my X230 for over a year now and everything works out of the box. Sleep never fails, power management needs one extra daemon up, integrated WWAN module just works with ifconfig...
I have a desktop computer with Linux just because there is certain software I need for my work. But hardware support with OpenBSD and ThinkPads will for sure be a smoother experience compared to many Linux distros.
T450s worked flawlessly. Any of the Thinkpads that you see on eBay being retired by corporations and refurbished for $200-$500USD would be great candidates.
Yesterday, out of sheer coincidence, I thought, you know what "lets check out OpenBSD again". Went to the homepage, saw the last 6.6 release was 6 months ago, and thought Hmm thats kinda old. Trawled around on the mirror sites to download it, and found version 6.7 files were there - a full day early! Not even timezones could explain it. Release date: May 19. So I downloaded it.
I made my first router with OpenBSD back in 2001, for a job, it was great! But I got fired for it, because the boss didn't understand how to use a command line...
I really love the OpenBSD documentation myself though.
And how the whole system is made a way that they want you to understand what its doing. And a certain nostalgia over all the familiar components that still feel the same. Its like a time machine. I was transported to the year 2001 when I made that first router all over again, or earlier. It has that familiar smell to it. Like a grandma cooking with the same recipe for 25 years. Initial Version 1.1 = 18 October 1995
Now I'm going to investigate using OpenBSD as a GUI desktop, but I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms, keyloggers, etc. Can anyone speak on that ? Has OpenBSD been fixed itself, or is it still using the same flawed codebase. Are there plans to move to Wayland?
As far as I know, the difficulty on OpenBSD would be input. The Wayland world relies on evdev, so they either have to patch it to use their interfaces, or implement evdev.
On FreeBSD, we have a lot of devices supporting evdev :) Including the next generation HID stack: https://github.com/wulf7/iichid (currently external, but would be merged into the system eventually)
Also there's device discovery, for which we use https://github.com/FreeBSDDesktop/libudev-devd to pretend to be udev, but I suspect the OpenBSD people might not like solutions like that :D (Actually, does OpenBSD even have anything devd-like that provides hotplug notifications?)
Very helpful thank you. I believe you are correct on all fronts. Does anyone know if "their interfaces" prevent the Xorg/Xinput keylogger "bug" as is, even without EVdev or Udev? The man page seems like it does use Xinput, but it also mentions Xwayland https://man.openbsd.org/xinput.1
So I think that if Wayland does work, that interface would take care of the issue.
I am in the middle of something else or I would try and figure it out myself, but it would take a long time.
No, the "xorg keylogger" issue has nothing to do with the low level stuff (evdev is how the windowing system gets info from the kernel, udev is how the windowing system enumerates devices and gets hotplug notifications). The "xorg keylogger" issue is a fundamental property of the X11 protocol, it's between the server and clients — all clients get enormous amounts of access to all kinds of global state over the X11 socket.
> Went to the homepage, saw the last 6.6 release was 6 months ago, and thought Hmm thats kinda old.
OpenBSD has done a release every 6 months for ~23 years.
I really don't understand comments around here where they look at a repo and say "hmmm, no updates in a while, it must be bad". There is really crappy software that updates frequently. It isn't evidence of anything. Many people are capable of committing total garbage every week, and this would satisfy your check. OpenBSD with its 6 month release schedule does pretty well by comparison with a lot of other projects.
> but I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms
Pretty sure that X doesn't run as root on OpenBSD.
I didnt say it was bad... I said, I was surprised given there is a 6 month schedule, that I randomly decided to check exactly 1 day before said schedule, and yet it was still secretly available.
I don't think it runs as root either, I'm more concerned about xinput and keyloggers running as my normal user being able to snoop on even sudo/su prompts running as root in a GUI terminal window running as my user. You know about this right? https://theinvisiblethings.blogspot.com/2011/04/linux-securi... Wayland was supposed to prevent this, but I don't think its going well on OpenBSD. Does OpenBSD have a solution for this?
My X server under OBSD is currently running as the _x11 user.
>keyloggers
I haven't heard about anything like that for X. Wouldn't any attempts to sandbox the ttys mess things that used them up in various ways? X is at heart a terminal oriented system. What are you trying to accomplish here? Normally it turns out that it is fairly futile to attempt to isolate tasks running as the same user from one another under the Unix security model.
I can’t really speak to the security of the desktop components, but I just wanted to chime in and say that I tried the same thing recently. I use KDE, and the version that ships on OpenBSD is old. From what I get, if you want KDE you use FreeBSD, and if you want Gnome you use OpenBSD.
>I have concerns about Xenocara/X11/Xorg/Xfree86, (idk what to call it) being insecure: root perms, keyloggers, etc. Can anyone speak on that ? Has OpenBSD been fixed itself, or is it still using the same flawed codebase. Are there plans to move to Wayland?
No, of course not. At this point no implementation is secure enough to compete with Xenocara anyway. OpenBSD isn't shooting to be a Linux desktop OS, so if you want Wayland, Pulse, SystemD, and the like you'll simply just have to stick with the fast-moving experimental OS's where they test new, unproven things like those listed above.
I just upgraded. What is this 'dt'? The mail linked here says there should be a bt(5), but https://www.openbsd.org/67.html says dt(5). In either case neither exists on my new 6.7 system. Nor does btrace(5), which dt(4) references.
The phrasing is a little odd but only the driver dt(4) is part of the 6.7 release. The language bt(5) and userland tool btrace(8), whilst in tree, are not part of this release. The following mailing list posts give an introduction to these components.
This is the kernel part of the dynamic profiling/tracing framework created by Martin Pieuchot (mpi@), unfortunately the userland parts btrace(8) (and the bt(5) manual) were not linked to the build for the 6.7 release, so those manuals are not available online.
Besides mailing list postings, there isn't too much available for now. But btrace(8) & bt(5) together describe a utility and language that's supposed to be compatible with Linux bpftrace (but an entirely different implementation).
Does anyone know if IPsec IKEv2 daemon can send multiple certificates (chain)? I tried to setup IPsec VPN with Letsencrypt certificate, but ultimately failed, because OpenBSD only sent leaf certificate and Windows failed to recognize it without intermediate. It works for me with strongswan in Linux.
havent tried this - but is your iked(8) cert file the full chain or just the leaf?
if just leaf, maybe try with full?
also haven't tried, but looks like the built in acme-client(1) can be configured to save the full chain if you're using that for the cert issuing stuff (acme-client.conf(5))
Yes, I tried different variations and even tried to dig into sources, it seemed at that moment, that it only sends a single certificate. That was 2-3 years ago, I think, so may be that changed.
PS acme-client is awesome, I wish it was ported to all Linux distributions as a default acme client.
prgmr.com has updated it's openbsd installer version to 6.7.
We were a bit surprised to see "Fixed softraid(4) CRYPTO volumes on 4K-sector disks" in the release notes. We don't have any 4k logical sector drives but for some reason I thought that was reasonably common in consumer drives these days.
Probably opening Pandora‘s box here, but I‘ve been wondering for a long time: why do people still use BSD? If memory serves me right, the *BSDs descend from the original Berkeley Unix from the 70s - but why stick to that „line of descent“ rather than going with the newer, Linux, line?
The reasons however will not be the same for everyone.
There are more similarities than differences between the two, however one difference IMO is that BSD has a level of "quality control", especially over the userland, that Linux does not. I find that my own sensibilities as a user align better with the relatively small number of people doing "quality control" and development for BSD projects than with the enormous number of people who work on Linux -- for me, the number of Linux contributors is too many to keep track of and I find it difficult to understand what all of their sensibilities are.
Because it's stable, it works all the time, no systemd, no surprises, no bullshit.
Not that Linux (the kernel) is any worse, but userspace is developed separately and it's not as slick. We're also using openSuSE Leap, Debian and Ubuntu on the desktop. Probably going to ditch the last one in favour of Debian thanks to the snap ecosystem.
Why go for the unproven, when the old, reliable also is freely available :-) ?
I think part of the reason is non-technical.
Some companies won’t use Linux in their hardware because of its license.
Similarly, some developers prefer working on BSD-licensed over working on GPL-licensed software. Some may also like working on systems with fewer developers, so that they can have greater impact on the direction of development.
Also, there are still new things being invented for BSDs (and Illumos) that aren't available in Linux. E.g. FreeBSD has Jails and Illumos has Zones which provide a complete solution for "containers" which are put together from different components in Linux which overall may not be as secure as Illumos Zones. Another one is the PF firewall. In OpenBSD they introduced security features like pledge and unveil.
Another thing is ZFS:
- on Linux there are legal problems with shipping it out of the box;
- it's far more popular on FreeBSD and Illumos than on Linux, so it wouldn't surprise me if there are bugs that will show up on Linux, but not on the other two.
I'm posting this as someone who runs and enjoys both FreeBSD/OpenBSD: there are good reasons for running *BSD these days, but the ones you listed have lost a lot of their value.
Regarding the Illumos/FreeBSD "trifecta" of zones/jails, ZFS, and DTrace - I prefer LXC, I treat laptops/workstations like cattle and only run FreeBSD+ZFS where its needed, and I don't need DTrace.
I'm sorry you're being downvoted - it seems to be a question in good faith, there isn't a singular, obvious answer, and I think you'll get some good answers.
For me, I use it for things that I want to be simple or unencumbered from licensing. Any sort of storage server in my house gets FreeBSD almost automatically. OpenBSD, I keep around mainly as a learning experience - it's really a simple, well-documented operating system, and it works flawlessly on a number of different Thinkpads. There are also plenty of opportunities to participate in the development of the OS itself or its packages.
This was not meant derogatorily, to whoever downvoted me... I‘m honestly interested. Obviously there has to be some advantage, otherwise it would have died out by now. I just don‘t know what that advantage is, never having used it myself.
OpenBSD specifically has a very strong focus on security features - not just bolt-ons like containers and cgroups, but a code and development style which reduces the change of security-related bugs, and things like pledge(2) and unveil(2) which allow applications to reduce their privileges drastically through a far simpler interface than Linux's equivalents.
Alternatives always exist and should exist. Monocultures are bad! :P
The community has existed for ages and it's not dying out because.. why would it? People just want to work on it for various reasons.
From my perspective: it's easy to modify FreeBSD and contribute to upstream, the "monorepo" thing with keeping libc and the basic utilities developed together with the kernel is nice (no stupid "glibc devs don't want to make new syscall wrappers" situations lol), the kernel is less complex than Linux, and has made different (better) technical decisions in many cases (kqueue got pretty much everything right around 2000 while it took epoll and friends years to not suck; ALSA is.. baffling while FreeBSD's sound system is good; Capsicum is the right model for app self-sandboxing; "udev populates /dev by symlinking stuff from /sys" is nuts; jails are really hard to screw up, unlike the overly flexible linux namespaces; …)
The lines of descent are not etched as deep as you suggest.
> BSDs descend from the original Berkeley Unix from the 70s
But they continue to be worked on. To wit, this announcement.
> the newer, Linux, line
Linux did not pop into existence. It traces its heritage too all the way back to Unix, which traces its way to MULTICS, which traces...
"The success of UNIX lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas..." --- Dennis Ritchie and Ken Thompson
Sort of depends on how you look at it. A shitty, misconfigured install of MySQL on an OpenBSD box won't automatically become secure. And the default install is pretty spartan-- you're not likely to use an OpenBSD machine without installing outside software, which is not going to be developed by the OpenBSD guys. So you're only as secure as your weakest public-facing program.
I tend to look at OpenBSD as a sort of "security incubator" program, where good security ideas and practices have the chance to grow. I think that the biggest impact of OpenBSD tends to be felt in OTHER operating systems and on the internet at large.
One of the big areas where OpenBSD has pushed things forward, in my opinion, is defense-in-depth for software. They put a lot of effort into maintaining high coding standards and an emphasis on correctness. They've been active in the area of exploit prevention and detection-- they were the first to really do W^X, they've been using ProPolice by default since forever, they randomize memory addresses, etc. But they're also very active in exploit mitigation-- that is, if we start by assuming that a program IS going to have a security bug, how do we limit the damage? OpenBSD has invented or popularized techniques like privilege separation, their "pledge" and "reveal" systems, and various other forms of sandboxing.
There's also the crypt side-- their work on cleaning up OpenSSL to create LibreSSL has been an incredible service. OpenSSH has been adopted EVERYWHERE. Their work has done a LOT to reduce the amount of unencrypted traffic going across the internet generally.
> Sort of depends on how you look at it. A shitty, misconfigured install of MySQL on an OpenBSD box won't automatically become secure. And the default install is pretty spartan-- you're not likely to use an OpenBSD machine without installing outside software, which is not going to be developed by the OpenBSD guys
Depends on what you're doing with it -- but the base system ships with many things that you would want to use, and it's definitely concievable that you'd only run with OpenBSD software.
Web servers? OpenHTTPd.
Mail wervers? OpenSMTPd.
Proxies? Relayd
Firewalls? pf
Routing? Depends on what you need, but there's probably a daemon for that.
Arguably OpenBSD is a "modern hardened cloud OS"; they're pretty aggressive at pushing kernel and userland hardening (in combination, ex. adding pledge, then patching the base system and some ports to use it).
Disclaimer: Not an expert on the topic by any means, just my take as a someone running this release on a few boxes. Have less experience with the latter portion of your question, more with OpenBSD.
I think it's comparable in terms of features, and many of those features even originated or have canonical implementations that started under the umbrella of OpenBSD. Also some of the most sane defaults, and simple install process, of any OS I've ever used.
I think where OpenBSD really shines though is the documentation. Most issues I run into can be solved by reading the man pages included with the default install.
Also the video linked by q3k elsewhere in this thread is a great watch.
For a long time OpenBSD was focussed on security through correctness and code review, so that portion is not necessarily reflected in any of the grsecurity/pax type hardened linuxes.
But OpenBSD does have things like ASLR and kernel address randomization, advanced memory protection (W^X etc) and while it doesn't have ACLs or PAM it has pledge which is a great way of restricting system call access at the program level.
OpenBSD definitely has a longer track record with a lower rate of remote exploits in the default install.
Since they keep userspace stable, they generally have more stable programs running there as well.
For instance, systemd has has multiple remote exploits in a time window when the default OpenBSD base install has had zero.
Moving up the stack, OpenBSD often rewrites or simplifies important daemons (like httpd), and those tend to have closed or mitigated security holes before upstream exploits are discovered.
My impression is that Linux tries to give sysadmins tools to secure existing binaries with containers, secomp, syscall filters etc.
OpenBSD focuses on securing things at the source level. Hence all the compiler tricks to mitigate memory safety bugs, API for programmers to limit syscall exposure, privilege separation within individual programs, drive to avoid unnecessary complexity so the source is readable etc.
Presumably something like CoreOS which makes extensive use of containers and any security feature it can get its hands on.
If I personally put my own opinion on it, I don't like unnecessary use of containers because the model gives you a lot of outdated dependencies, and I'm not sure whether containing a vulnerability once it happens is that noteworthy.
Old skool "use good, secure code. update dependencies" and not focusing on containing a vulnerability produces a much safer system IMO.
The cloud part makes much more sense when combining it with the user land. I think that's also where OpenBSD (or *BSD in general) really shines, everything is very coherent. Regarding Linux, I'd probably see CentOS/RHEL as "modern hardened cloud OS" with all it's measures in place. But even as a complete BSD beginner, I find OpenBSD or FreeBSD easier to configure than CentOS, which IIRC requires a lot of manual whitelisting of capabilities for server daemons.
>don't know why FreeBSD/NetBSD/OpenBSD a) split their already limited free/volunteer resources
I don't know why people ride motorcycles, skateboards, or school buses when trains already exist. This is not one organization, these are different groups all trying to accomplish different goals.
>why anybody would run BSD over Linux.
We have our reasons. You have already quoted very valid reasons, the fact that you disregard them speaks more about yourself then the motivating factors of others. You have been given technical arguments, political arguments, and real-world examples of why others think that the BSD groups prefer their OS of choice.
You have already made up your mind that BSD is inferior.
i agree that linux distribution fragmentation is also "stupid". it's a free country/world, you can put your time into whatever you want. but if your goal is to deliver the best project with the best documentation/support/polish, you're absolutely right that 1,000 people working on 100 separate versions of "basically the same thing" is dumb
imagine how much success windows + mac would have if they were as scattered and opinionated as the linux community
While your comment is inflammatory and commits several rhetorical crimes, I will just reply with saying that there are many valid uses of BSD.
OpenBSD in particular is an attractive option for some servers, since it has builtin httpd, acme-client (for tls certs), smtpd and excellent documentation of how to get it all up and running with minimal, secure configuration.
While people have a tendency to believe that there is "only one True Way", and it is a popular argument that "X is most popular, therefore it is The True Way." – this is not in fact true for operating systems. Every system will have its drawbacks, and…
Regarding a): Everyone working on one thing does not optimise the quality of the outcome. A rich flora of operating systems encourages experimentation, trying out different compromises and learning from each other’s experience.
> OpenBSD in particular is an attractive option for some servers, since it has builtin httpd, acme-client (for tls certs), smtpd and excellent documentation of how to get it all up and running with minimal, secure configuration.
it is an attractive option that is less attractive than Linux because it is less popular and has less support
You’ve named three very different projects with very different goals and mostly separate developer sets. I can’t imagine a plausible scenario in which they would - or even could - join together, and it almost certainly would not make the resulting project move any faster than the separate ones do.
It's also worth pointing out that at least OpenBSD was forked out of NetBSD specifically because people couldn't/wouldn't work together. Maybe 26 year later the human factors are less (maybe), but now there are significant technical differences.
> You’ve named three very different projects with very different goals and mostly separate developer sets
that all accomplish the same thing, with worse polish + support than larger, more successful projects who don't spend time building on top of "slightly different variations" of the same thing
it's undeniable that linux has 10x the support of OpenBSD, and mac has 2x-5x the support for linux in terms of "actually getting stuff done", not tinkering with command files endlessly for no reason
even the "linux is good for infrastructure" excuse is starting to fade away as more and more things get abstracted away with k8s, docker, cloud-config, etc.
yes, by all means, they run linux. they don't (on average) run BSD. anything that runs BSD could in theory run linux and probably be ok overall. linux is not "worse" than BSD at any one thing and is better in terms of community support, performance, etc.
Right? Why would anyone ever do anything differently? Let's all just go back to the most popular platform, NT. After all, everything else is a waste of time. (/s)
I know right? just imagine if WSL2 was supporting Linux GUI apps running on Windows, we wouldn't be needed a Linux distro install in the first place, Oh wait.
If you're running Linux for application compatibility, I don't think you understand why people use Linux. (Although yes, if you want NT and only use Linux to run apps that don't work on raw NT, WSL1/2 are excellent)
At least for the desktop applications I'm developing, it is straight-forward to test them on Windows and Mac because they have the consistent underlying APIs that allow this.
Linux distros however are still moving targets and there's no common stack apart from the kernel which is predictable to test against. This is why its hard for some maintainers to reproduce an issue a user has due to possibly apt-get, rpm, install package or use snap, flatpak or appimage and the app starts to break.
Not a problem for CLI apps, but a problem for testing desktop apps on Linux. Perhaps you want your favourite app being fully supported and tested on your Linux distro of choice. If I know my app works and is tested on Linux distro A,B,C,etc I can confidently target a wider range of Linux users. At least that's how I increase my "Linux userbase".
The fragmentation on this however is another story.
Why provide that antique gcc? Better to not provide gcc at all, and an ability to install a recent GCC at user's discretion, than to provide a 12 year old gcc in the base system.
In OpenBSD, "base builds base". That is to say, one must be able to build the system using the compiler provided in the compXX.tgz set.
gcc moved to GPLv3 and OpenBSD doesn't ship GPLv3 code. For a long time, that's the reason why it was stuck on an ancient gcc.
OpenBSD moved to clang/llvm because it has a more acceptable licence. However, clang/llvm does not support all architectures OpenBSD supports, so that's why there's stil gcc.
Users can install a newer gcc (v8.3) from packages/ports.
Newer LLVM releases are licensed with APL2.0, and that doesn't sit well with OpenBSD:
Why not? This isn't the 90s anymore. Clang 8 is a very usable c compiler with excellent optimizations and excellent diagnostics. (OpenBSD doesn't use c++, so they don't need newer standards of that anyway.) And newer versions of both clang and gcc are available as packages.
Provide isn't the the right word. GCC is in the base system because some architectures haven't yet switched to clang, either because clang doesn't support the architecture, or because the work of switching the toolchain (which is not trivial) has not been done yet. The system must be able to build itself, so "better to not provide gcc at all" doesn't make sense.
In the cases where OpenBSD (and FreeBSD) don't yet use clang, they use the most recent GCC version that was still GPLv2 licensed. GPLv3 is not acceptable to OpenBSD in the base system.
More recent versions of GCC are provided in the ports system, for users to install. Those are not used by the base system. The system compilers are (mostly) for building the system. They don't even search in regular paths users might expect, like /usr/local. If users need a general purpose compiler, they can install one from ports.
The situation with clang is similar. OpenBSD uses the last version of clang/LLVM that was still BSD-licensed. Now LLVM uses the Apache license, which is not acceptable to OpenBSD in the base system. (However, FreeBSD is okay with it.)
How is the user supposed to navigate all the logistics and technical ramafications of ethical/political dev / package choices ?
Everything has alternative versions, its hard for me to keep track of who forked what and why.
Generally speaking they don't need to. If you are developing C code and need some particular compiler version, you just install a package (ie "pkg install gcc9") and make sure to set CC=gcc9, and that's it.
