Distro is synonymous with OS at this point. No one is using it as a derogatory term for OSes that aren't different enough to give them the denotation of "OS".
That said, you're going to have to come up with an argument stronger than "this was forked ages ago" to suggest Dragonfly and FreeBSD are different enough to warrant thought. Ubuntu forked before 2004 and you don't see anyone being called out for comparing it to Debian.
Possibly to the layman but the term "distro" (short for "distribution") deliberately exists to differentiate between different OS's and different distributions of the same OS but with a different software stack and default configurations.
While you do sometimes get differences between the Linuxes in terms of init daemons and slightly patched kernels etc, they are all generally GNU/Linux - ie generally share the same common Linux OS fundamentals (eg GNU coreutils). There will be exceptions to this rule (isn't there always?!) but we're talking about the common desktop / server platforms people automatically talk about when discussing "Linux".
However many of the BSDs are developed in insolation. While they may have a shared heritage, the kernels have matured into something quite different from one another. Often the core utilities and init daemons et al can vary noticeably as well.
So in essence, FreeBSD and Dragonfly are different but similar OSs, whereas Linux distributions are the same OS but differently configured. This is why we make the distinction between "distro" and "OS".
I've been experimenting with Debian/kFreeBSD lately, and one funny aspect it's had is making me realize that the kernel is not really all that important to the userland experience, at least for what I do. It still feels like Debian, even though they swapped out the Linux kernel for the FreeBSD kernel. That's one reason I think of Debian as an OS, rather than a Linux distro. Debian itself then has several distros, such as Debian/Linux and Debian/kFreeBSD.
I get your point, but aside the package manager and associated tools, most of what you've described are GNU packages / cross platform user land. ie stuff that even in the most limited sense was never Debian specific to begin with; but often was designed to run on most Unix-like platforms anyway. Because of this I've read some people describe kFreeBSD as GNU/kFreeBSD (ie GNU user land with the FreeBSD kernel) and I think that makes some sense if you're following the GNU/Linux naming convention (which I think makes sense in the context of this discussion because it also takes the Hurd kernel into account - GNU/Hurd). But this is one of those edge cases I was thinking of when I talked about exceptions to the rule in my grandparent post.
As for whether it's classified as a separate OS from Debian (Linux) or FreeBSD - there's definitely some room for interpretation so I'll hold off from passing my own personal judgement :)
Talking about rule exceptions, another good example would be Android. Largely the same kernel as GNU/Linux and some of the user land too but equally it's a very different platform to "desktop / server Linux"
One big difference is that Debian has invested a huge amount of work over the years cleaning up the software they package to make it easier to customize, maintain configuration across updates, etc. That's much broader than the percentage of GNU utilities in Debian's userland.
Debian aren't the only ones that do that however patching 3rd party software doesn't make it "Debian's user land".
Debian also runs a lot of software written by Redhat (eg systemd) but that doesn't make it a distribution of Redhat. Ubuntu ships a lot of in house software as well (eg Unity) but that doesn't mean ArchLinux with the Unity DE turns Arch into a distribution of Ubuntu.
What you're doing is akin to classifying groups of web browsers by the websites the user visits rather than by the rendering engines they're built on.
I find it more integrated in Debian than in most other distributions (even including the BSDs, once you get outside their base systems and into the wild west of ports). It's not just that they ship other software in the package manager, but that it's heavily customized to fit into the "Debian way" of doing things. This is partly emphasized by the lack of a distinction between "base" and "ports"; every package, from libc to your mailserver, is a Debian package, and is supposed to follow policy and work how users expect a Debian package to work.
It does vary package to package, but on average there's a fairly substantial amount of work that goes into "Debianizing" a package so it's integrated into the OS coherently, vs. the more lightweight build-scripts that you find with systems like Slackware or FreeBSD ports, that typically ship something closer to upstream. I would compare it more to maybe halfway towards how FreeBSD adapts third-party software into its base system. FreeBSD base is full of third-party patched stuff, too, like ZFS, LLVM, OpenSSH, and sendmail, which is periodically synced with upstream. But they put enough effort into customizing it and making it work together coherently, that I think it's fair to call the base FreeBSD install an "operating system".
I do think Debian as an OS may get less true with systemd, though. SystemD is really going all-in on the idea that there is a specifically Linux way of integrating an operating system, which is closely tied to the kernel, and Debian increasingly finds it difficult to avoid getting pulled in 100% to that path, since the amount of divergence you need to avoid doing things the "systemd way" is growing rapidly. In which case the end game is that there's a Linux/SystemD core OS, of which Debian is just one distribution. While until now Debian has aimed at being a "universal operating system" not tied to any specific kernel.
I don't agree with your feelings towards Debian simply because I've used plenty of platforms that have the same cohesive feel. But at the end of the day all you're talking about now is an emotional impression based on anecdote, which may feel relevant to yourself but ultimately has little impact to the discussion of distributions Vs distinct operating systems.
No, it's not. You can go from one GNU/Linux distro to another GNU/Linux distro and you're still gonna find a GNU userland and a Linux kernel. Base userland and kernel differ significantly between BSDs.
plus - native binaries can be copied between one and the other and run natively without any emulation layer provided the c library, kernel version, and other libraries are reasonably similar.
> If you use Linux with systemd or without is a significant difference, which is probably as big as switching between BSDs.
I did address the init daemon point. With Linux distros you're still using a common kernel upstream (ie Linux) which all Linux distro's share. That's not the case with the BSDs. You're also sharing the same GNU coreutils which 99% of Linux's share, BSD's often have their own. The kernel is really the key point here though.
> The name of my operating system is "Ubuntu", not "Linux".
Technically it's neither. "Ubuntu" is the distribution name. "Linux" is the kernel name. I don't much agree with Richard Stallman that "Linux the OS" should be named "GNU/Linux" but from a technical standpoint it is a more accurate OS name than either of the two suggestions you raised.
DFBSD has substantial kernel differences from FreeBSD (IIRC the original reason for the fork was that the author disagreed about how to implement multiprocessor scheduling and went off to do it his way), such that the diff between the FBSD tree and the DFBSD tree would be enormous at this point. Drivers sometimes make their way between the two, I believe, but it isn't just a copy-paste operation.
Ubuntu and Debian's kernels, on the other hand, are kept as itemized patchsets against the same kernel, and it would be hard (but probably not impossible) to find drivers that build+work on a Debian kernel and break on an Ubuntu kernel of similar age.
An OS is a kernel and userland developed together in its entirety. All the code shipped is maintained by a single responsible entity: an open source team or a company. External code is imported into the source tree and treated as if it is owned by the team. Any patches required for it
to integrate cleanly are the responsibility of the OS maintainers.
A distro is a Linux kernel and a collection of open source software, typically GNU, which fulfills the needs of the userland environment. The distro maintainers are responsible for packaging and distribution. They are not responsible for maintaining the kernel or any of the userland software unless it was internally developed such as a custom installer or various glue code, maintenance scripts, etc. They do not own the libc, the kernel, the shell, any drivers, responsibility for writing security patches, or bug fixes for any code they did not originally write, etc. The distro volunteers or employees of the company in charge of producing the distro may be involved in kernel or other open source softeare development, but it is not required.
This may be an unpopular statement, but a Linux distro is not an OS.
It is a collection of open source software that tries to be compatible with all of its components. Subject matter experts of all components are usually not involved in its creation. Instead they exist spread out across the entire Linux distro ecosystem.
Does Arch Linux have an expert in the virtual memory subsystem of the kernels they ship?
Does Gentoo have an expert in the kernel random code?
Does Debian have an expert in the glibc codebase?
Does Ubuntu have an expert in the bootloader?
Does Mint Linux have an expert in the BASH code they ship?
I can say with confidence that Suse and Redhat employ experts of many areas of the kernel, glibc, systemd, filesystems, and other components, but not everything.
Does FreeBSD/Dragonfly/OpenBSD have an expert or designated owner of the filesystems they ship? Bootloaders? Libc? Kernel timekeeping code? Random? Crypto? VFS? Network stack? NIC drivers? CPU schedulers? Shells and userland utilities?
Yes they do. They're OSes, entirely maintained in-project. Just like Windows, OSX, Solaris, etc.
OpenBSD is most aggressive here, but unmaintained code usually means nobody is using it and it will be removed. Everything has an owner and is constantly being looked after. In the BSD world it would not be common for a major component to exist long term without an SME joining the project and maintaining it or replacing it.
BSDs are OSes, and are mostly independent. You cannot easily port kernel code between them because they have diverged significantly.
Except it's not. If I hit a bug in the NFS code, who at Debian will help me? Nobody. The bug report is opened and the buck is passed upstream. Now they have to hope the upstream maintainers of the NFS code care to fix it. They might not be interested especially if the distro is shipping an older release they no longer wish to maintain.
If I hit a bug in the NFS code on FreeBSD, I open a bugzilla issue first, but get the attention of Rick Macklem. If I hit a bug in the posix shell, I contact Jamie Gritton. If I hit a bug in the VM subsystem, I want to talk to Konstantin Belousov. A weird timekeeping issue? Most likely our resident Time Lord, Poul-Henning Kamp. A C conformance issue? Presumably David Chisnall. Even our compilers have patches required for our codebases, so we have compiler maintainers. If I hit a bug I have a team of people to reach out to.
All of these people have a vested interest in bugfixes and maintaining the code within our supported releases. You do not have this luxury in the Linux world. At best you can hope you have a support contract with RedHat or someone who can pay a competent employee to figure out how to fix it if upstream refuses to get involved.
You are right about the kernel point however there's more to it than that.
Debian is a collection of software and configuration that's distributed for convenience. That's where the term "distro" originates. The OS would be better described as GNU/Linux (the GNU user land and Linux kernel) with "Debian" being the name for that particular set of user land defaults.
Likewise Hurd is often referred to as GNU/Hurd since it too uses the GNU user land. Debian, Arch, etc will then take the Hurd / Linux and GNU sources and add their own touches to it (package management, etc) but fundamentally Ubuntu and Arch are still the same platform at their core in a way that Ubuntu and FreeBSD is not.
I didn't agree with much of what the GP raised (particularly around issues of support), but one point he was correct about was how Debian, Arch, etc aren't the maintainers of the Linux kernel nor GNU coreutils. Sure they will contribute patches but essentially what they do is redistribute GNU/Linux with their preferred packages and configuration. Hence the term "Linux distribution".
So the TL;DR version is:
If you're running Debian you do have an OS installed. The OS might be referred to as GNU/Linux to express the GNU user land and Linux kernel. Debian is the name given to the distributed collection of programs and default configurations that's based on GNU/Linux.
Previous discussion about the filesystem vs. ZFS: https://news.ycombinator.com/item?id=8829194