Linux and BSD are both similar opensource UNIX-likes but at the same time there very different in many aspects especially in ideology. while BSD and its forks/children are pretty different from each-other but in general BSD is an alternative to Linux and focusing on a more free license then the GNU's GPL that being the BSD license obviously while the GPL forced opensource for derivatives BSD is more doesn't give a fuck hence why it sees wide use in embedded and proprietary systems such as the PlayStation consoles (3 and up) but software wise the BSD and Linux are quite different while Linux primarily uses gnu-core-utils and glibc each BSD has their own set of tools and software for its coresys-utils and use their own c library and other differences between Linux and BSD include "package management", release cycles ,and init/rc systems but i believe there's a good middle ground between the two that being Slackware. taking the best of both world Linux's Software (gnu-core-utils and the Linux kernel) and combining them with BSD's style of doing things (rc-scripts "package management" release cycles/releases and file system layout) the main drawbacks to slackware is once again the package management or lack of and its long release cycles but besides that if your a fan of linux and bsd i reccomend giving it a swing you'll most likely learn a lot

I used slackware 14.0 on my AMD K6-2+ 550 Mhz system since slackware keeps support for 32bit processors which is really cool. Compiling audacity took about 12 hours. Slackware has some of the best desktop guis such as NsCDE and FVWM 95.

https://xteddy.org/xwinman/fvwm95.html
This websites has a bunch of screenshots of old linux guis you should checkout

also you forgot to mention it has an actual base system. a base system with a kernel is essential to any operating system but most linux distros seem to completely ignore that and ship incomplete installation images. in the end it all just means that you'll have to depend on the internet infrastructure and get online just to be able to actually use your computer.

s/kernel/compiler/
i meant compiler. don't know why i wrote kernel.

>>3
I think this is an important point which other distros don't care about at all. Most Linux distros are designed as always-online OSes that can't function without Internet and in the case of many rolling release distros even break if you don't connect them to the Internet for too long. In that regard even Windows is superior to most of those always-online distros, because you can hoard, share, and install .exe, .msi installers for programs you want to preserve, unlike with for instance Arch or Debian where everything is a hyper-specific package that only works on that exact system at that exact version. Slackware doesn't fix this fundamental issue with Linux, but it still attempts to make an offline-usable OS at all.

>>5
careful. you are about to argue yourself into loving flatpaks and docker images for package management.

always download source for packages. install from source. print out a hardcopy for offline restoration. and use plan9.

I'm too lazy to try to main slackware again, but I did have a great time because ignoring package management means the ideal way to use slackware is to just install everything.
There were a few things I needed that weren't distributed by slackware, but having all the dependencies already there made compiling everything no effort.

>>6
my desktop is on Bazzite now and that system basically does just go "flatpak is the one true way to install software" because the main install image is immutable
there are other workarounds (the second true way to install software is just use distrobox and be beholden to your sub-distro of choice's package management)

I do wonder just how long the support guarantees for flatpaks will actually last in practice. How far in the future could I expect a flatpak from today to keep working on later systems, I wonder...?

>>7
there are a few "immutable" linux distros that have popped up with flatpak as king. none of them have really gone anywhere because it is quite annoying to deal with. no package maintainer is going to bother flatpaking every single application someone might ever want. it's too hard to expect someone to do it themselves (vs source where the README says "type 'make' " ) at least yours seems to have considered this alternative.

in theory as long as flatpak as a thing remains the oldest flatpaks will remain runnable same as the day they were made. in practice? I have no idea. as a trend it doesn't seem to have any interest in dying any time soon, but i doubt it will have the longevity of java applications. I think in reality if you want stable programs you should do your own vm installs of those applications in minimal qemu images. those will almost certainly outlive flatpak and docker. but it is ugly to manage them, and probably overkill in practice?

docker is a bit nicer to use thanks to compose. once you actually clear the hurdle of getting it setup. still morally abhorrent tho.

ok i changed my mind bazzite is pretty good if you just want a system that works and you don't really care all that much about tinkering with every detail. and even if you do want to do more devy type shit you still can.
wouldn't use it for server stuff but for desktop, gaming, media center use cases it seems nice.

GNU'S
NOT
UNIX
*stallman scream*