IIRC in about 99 I got sick of Mandrake and RH RPM deps hell and found FreeBSD 3 CD in a Walnut creek book. Ports and BSD packages were a revelation, to say nothing of the documentation which still sets it apart from the haphazard Linux.
The comment about using a good SERVER mobo like supermicro is on point --- I managed many supermicro fbsd colo ack servers for almost 15 years and those boards worked well with it.
Currently I run FreeBSD on several home machines including old mac minis repurposed as media machines throughout the house.
They run kodi + linux brave and with that I can stream anything like live sports.
Also OpenBSD for one firewall and PFSense (FreeBSD) for another.
I completely agree.
Supermicro mobo's with server-grade components combined with aggressive cooling fans/heat sinks running FreeBSD in a AAA data center resulted in two prod servers having uptimes of over 3000+ days. This included dozens of app/jails/ports updates (pretty much everything other than the kernel).
I run some EVE Online services for friends. They have manual install steps for those of use not using containers. Took me half a day to get the stack going on FBSD and that was mostly me making typos and mistakes. So pleased I was able to dodge the “docker compose up” trap.
If you run bare-metal, and instructions to build a project say "you need to install libfoo-dev, libbar-dev, libbaz-dev", you're still sourcing it from your known supply chain, with its known lifecycles and processes. If there's a CVE in libbaz, you'll likely get the patch and news from the same mailing lists you got your kernel and Apache updates from.
Conversely, if you pull in a ready-made Docker container, it might be running an entire Alpine or Ubuntu distribution atop your preferred Debian or FreeBSD. Any process you had to keep those packages up to date and monitor vulnerabilities now has to be extended to cover additional distributions.
FreeBSD always has been, and always will be, my favorite OS.
It is so much more coherent and considered, as the post author points out. It is cohesive; whole.
That haphazard nature is probably part of the reason for its success, since it allowed for many alternative ways of doing things being experimented in parallel.
I prefer FreeBSD.
Compare this to RedHat: yes, a paid subscription is expensive, but RedHat backports security fixes into the original code, so open source package updates don’t break your application, and critical CVEs are still addressed.
Microsoft, for all its faults, provides remarkable stability by supporting backward compatibility to a sometimes ridiculous extent.
Is FreeBSD amazing, stable, and an I/O workhorse? Absolutely: just ask Netflix. But is it a good choice for general-purpose, application-focused (as opposed to infrastructure-focused) large deployments? Hm, no ?
Where are you getting 3 months from? It's usually 9 months and occasionally 12 months.
Also, major versions are supported for 4 years and unless you're messing with kernel APIs nothing should break. (Testing is always good! But going from 14.3 to 14.4 is not a matter of needing lots of extra development work.)
How much support do you plan on getting? The old releases don't really turn into pumpkins. Yes, every two or three major releases, they end up with a minor release that adds something to libc where binary packages from X.2 won't run on X.1 or X.0. But this isn't usually a huge deal for servers if you follow this plan:
Use FreeBSD as your stable base, but build your own binaries for your main service / language runtimes. If you build once and distribute binaries, keep your build machine / build root on the oldest minor revision you have in your fleet. When you install a new system, use an OS version that's in support and install any FreeBSD built binary packages then.
You do have to be prepared to review updates to confirm if they need you to take action (many to most won't if you are careful about what is enabled), backport fixes, build packages yourself, or upgrade in a hurry when necessary, but you don't often actually need to.
I don't think this strategy works for a desktop deployment; there's too many moving pieces. But it works well for a server. Most of my FreeBSD servers for work got installed and never needed an OS upgrade until they were replaced by better hardware. I did have an upgrade process, and I did use it sometimes: there were a couple kernel bugs that needed fixes, and sometimes new kernels would have much better performance so it was foolish to leave things as-is. And a couple bugs in the packages we installed; usually those didn't need an OS upgrade too, but sometimes it was easier to upgrade the handful of old servers rather than fight everything; choosing battles is important.
Or you can go like Netflix and just run as close to -CURRENT as you can.
The point is that for any system that has a publicly facing (internet) part you will have to keep up to date with known vulnerabilities as published in CVEs. Not doing so makes you a prime target to security breaches.
The FreeBSD maintainers do modify FreeBSD to address the latest known vulnerabilities.... but you will have to accept the new release every 3 months.
Aditionally, those releases do not only contain FreeBSD changes but also changes to all third party open source packages that are part of the distribution. Every package is maintained by different individuals or groups and often they make changes that change the way their software works, often these are "breaking" changes, i.e. you will have to update your application code for it to be compatible with that.
Sure, you have to be aware of them, but for something like this [1], if you don't use SO_REUSEPORT_LB, you don't have to take any further action.
The defect is likely in other FreeBSD releases that are no longer supported, but still, if you don't use SO_REUSEPORT_LB, you don't have to update.
If you do use the feature, then for unsupported releases, you could backport the fix, or update to a supported version. And you might mitigate by disabling the feature temporarily, depending on how much of a hit not using it is for your use case. Like I said, you have to be prepared for that.
You can also do partial updates, like take a new kernel, without touching the userland; or take the kernel and userland without taking any package/ports updates.
Some security advisories cover base userland or ports/packages... we can go through an example one of those and see what decision criteria would be for those, too.
[1] https://www.freebsd.org/security/advisories/FreeBSD-SA-25:09...
FWIW I switched from Debian to FreeBSD 25 years ago as my main OS.
Open source packages often include breaking changes, all but guaranteeing your application to fail. With (a paid version of) RedHat Linux, RedHat modifies the open source packages to remediate CVEs by modifying the original version.
The only Linux distro that actually lives up to that promise in my experience is Alpine.
Don't get me wrong: ports is pretty cool and jails are cool, but every time I've tried running FreeBSD on a laptop I end up spending a day chasing problems with drivers or getting things like brightness or volume controls working. Basically, FreeBSD on laptops (as of the last time I tried it about two years ago) feels like Linux on laptops about fifteen years ago. Linux on laptops nowadays generally works out of the box, at least with AMD stuff. I didn't have much issue getting NixOS working on my current laptop, but I am not sure that would be the case with FreeBSD, even still.
That said, FreeBSD on servers is pretty sweet. Very stable, and ports is pretty awesome. I ran FreeBSD on a server for about a year.
I would actually be interested in running it in some production environments but it seems like that is pitted against the common deploy scenarios that involve Docker and while there is work on bringing runc to FreeBSD it is alpha stage at best currently.
Still, if you just want an ssh server, a file server, a mail server, it is a great OS with sane defaults and a predictable upgrade schedule.
Jails and BHYVE vms are excellent -- but I use Docker every day and if I could use BSD as my docker host I would.
Good thing my docker servers are all built with terraform so I do not have to touch.
As I've aged, what I've come to value most in software stacks is composability. I do not know if [Free]BSD restores that, but Linux feels like it has grown more complicated and less composable. I'm using this term loosely, but I'm mostly thinking of how one reasons and cognates about the way the system work in this instance. I want to work in a world where each tool on the OS's bench has a single straightforward man page, not swiss army knives where the authors/maintainers just kept throwing more "it can do this too" in to attract community.
I'm not sure that that's the win that you think it is. Linux 10 to 20 years ago was pretty terrible, at least on desktops.
Everyone hates on systemd, but honestly I really think that the complaints are extremely overblown. I've been using systemd based distros since around ~2012, and while I've had many issues with Linux in that time, I can't really say that any of them were caused by systemd. systemd is easy to use, journalctl is nice for looking at logs, and honestly most of the complaints I see about it boil down to "well what if...", what-if's that simply hasn't happened yet.
FreeBSD is cool, but when I run it I do sometimes kind of miss systemd, simply because systemd is easy. I know there was some interest in launchd in the FreeBSD world but I don't know how far that actually got or if it got any traction, but I really wish it would.
From the BSDs, I think only OpenBSD has a really unique selling point with its focus on security. People ask "why pick FreeBSD rather than Linux" and most will not find compelling arguments in favour of FreeBSD there.
I used (and pushed) it everywhere I could and first encountered on Solaris before FBSD. Even had it on my Mac workstation almost 18 years ago (unsupported) -- aside I will never forgive that asshole Larry Ellison for killing OpenSolaris. NEVER.
Systemd is the worst PoS every written. RCs are effective and elegant. Systemd is reason enough to avoid Linux but I still hold my nose and use it because I have to.
Can you give that shot for me on Linux? Could you spin up a Ubuntu 14 VM and do a full system update to 24.04 without problems? Let me know how you go.
I once needed help with a userland utility and the handbook answered the question directly. More impressive was the conversation I had with a kernel developer, who also maintains the userland tools — not because they choose too but because the architecture dictates that the whole system is maintained as a whole.
Can you say the same for Linux? You literally cannot. Only Arch and RedHat (if you can get passed the paywall) have anything that comes close to the FreeBSD Handbook.
FreeBSD has a lot going for it. It just sits there and works forever. Linux can do the same, if you maintain it. You barely need to maintain a FreeBSD system outside of updating packages.
Most people who use containers a lot won’t find a home in FreeBSD, and that’s fine. I hope containers never come to the BSD family. Most public images are gross and massive security concerns.
But then, most people who use FreeBSD know you don’t need containers to run multiple software stacks on the same OS, regardless of needing multiple runtimes or library versions. This is a lost art because today you just go “docker compose up” and walk away because everything is taken care of for you… right? Guys? Everything is secure now, right?
The command you most likely used is freebsd-update[0]. There are other ways to update FreeBSD versions, but this is a well documented and commonly used one.
> I don’t recall having to reboot — might have needed to.
Updating across major versions requires a reboot. Nothing wrong with that, just clarifying is all.
> Most people who use containers a lot won’t find a home in FreeBSD, and that’s fine. I hope containers never come to the BSD family.
Strictly speaking, Linux containers are not needed in FreeBSD as jails provide similar functionality (better IMHO, but I am very biased towards FreeBSD). My preferred way to manage jails is with ezjail[1] FWIW.
> But then, most people who use FreeBSD know you don’t need containers to run multiple software stacks on the same OS, regardless of needing multiple runtimes or library versions.
I completely agree!
0 - https://docs.freebsd.org/en/books/handbook/cutting-edge/
If anything is mainstream, it’s BSD, because OS X is BSD.
There is 'different' as in 'alternative/edgy', and then there is 'different' as in 'won't implement/yagni' which becomes highly subjective.
If you could handle Linux in the late 90s you can handle it.
You might have just hit a bad hardware setup that’s outside the scope of support. It happens.
Which laptop?
Did you use the battery, touchpad, and the wifi?
I find most BSD users who say they use it on a laptop are just using a laptop-form-factor machine like a thinkpad that is plugged in, with a mouse not the touchpad, and connected via ethernet 99.9% of the time. There's nothing wrong with this, but it bears little resemblance to what I consider "using a laptop".
My experience with distros including Open- and FreeBSD on laptops has been universally negative. OpenBSD in particular is very slow compared to Linux on the same hardware, to say nothing of awful touchpad drivers and battery management.
The reason I like the BSD is that they are easily understood. Have you tried to troubleshoot ALSA? Or use libvirt? Linux has a lot of features, but most of them are not really useful to to general computer user. It felt like a B2B SaaS, lot of little stuff that you wonder why they are included in the design or why they're even here in the first place.
On one of them I use a creative bt-w2 bluetooth dongle for audio output, openbsd removed software bluetooth support due to security concerns. The latest wifi standards are not supported on these models, which doesn't bother me. It's not the size of your network, it's what you do with it! I don't mind not having the latest flashy hardware - been there, done that.
I have to pay attention when I purchase hardware, and am happy to do so, because openbsd aligns much better with my priorities. For me that includes simplicity, security, documentation and especially stability through time - I don't want to have to rearrange my working configs every two years cuz of haphazard changes to things like audio, systemd, wayland, binary blobs, etc.
OpenBSD at least booted far enough that I could shim the Wifi firmware in as needed. I probably picked the wrong Linux distribution to work with, since I've had okay luck with Debian and then Devuan on that machine's replacement (a L13)
FreeBSD has a few laptop developers, but most are doing server work. There is a project currently underway to help get more laptops back into support again: https://github.com/FreeBSDFoundation/proj-laptop
But back in the early 2000s I got access to a free Unix shell account that included Apache hosting and Perl, and if I'm not misremembering, it was running on FreeBSD and hosted by an ISP in the UK using the domain names portland.co.uk and port5.com.
That was formative for me: I learned all of Unix, Perl, and basic CGI web development on that server. I don't know who specifically was running that server, or whether they have any relation to the current owner of that domain. But if you're out there, thanks! Having access to FreeBSD was a huge help to a random high schooler in the U.S., who wouldn't have been able to afford a paid hosting account back then.
This is just such a bizarre view ... what do they think Linux really is? Maybe if you are on bleeding edge Arch as a hobbyist who follows the latest shiny windows managers or something like that. But those of us who run Linux in production do that on stable releases with proven tech that hasn't changed significantly in more than a decade. Or longer for some things.
The FreeBSD folks need a reality check. They are so out of touch with what Linux really is. It is hard to take these kind of articles seriously.
Pretty sure the firewall commands have changed at least once in that time, and the device layer and maybe the init system. I hear the preferred sound system is changing again in the last few years too.
yeah.
I reboot a lot. Mostly I want to know that should the system need to reboot for whatever reason, that it will all come back up again. I run a very lightly loaded site and I highly doubt anybody notices the minute (or so) loss of service caused by rebooting.
Pretty sure I don't feel bad about this.
In the modern era, a lightly (or at least stably) loaded system lasting for hundreds or even thousands of days without crashing or needing a reboot should be a baseline unremarkable expectation -- but that implies that you don't need security updates, which means the system needs to not be exposed to the internet.
On the other hand, every time you do a software update you put the system in a weird spot that is potentially subtly different from where it would be on a fresh reboot, unless you restart all of userspace (at which point you might as well just reboot).
And of course FreeBSD hasn't implemented kernel live patching -- but then, that isn't a "long uptime" solution anyway, the point of live patching is to keep the system running safely until your next maintenance window.
My recollection is that, usually, it crashed more often than that. The 50 days thing was IIRC only the time for it to be guaranteed to crash (due to some counter overflowing).
> In the modern era, a lightly (or at least stably) loaded system lasting for hundreds or even thousands of days without crashing or needing a reboot should be a baseline unremarkable expectation -- but that implies that you don't need security updates, which means the system needs to not be exposed to the internet.
Or that the part of the system which needs the security updates not be exposed to the Internet. Other than the TCP/IP stack, most of the kernel is not directly accessible from outside the system.
> On the other hand, every time you do a software update you put the system in a weird spot that is potentially subtly different from where it would be on a fresh reboot, unless you restart all of userspace (at which point you might as well just reboot).
You don't need a software update for that. Normal use of the system is enough to make it gradually diverge from its "clean" after-boot state. For instance, if you empty /tmp on boot, any temporary file is already a subtle difference from how it would be on a fresh reboot.
Personally, I consider having to reboot due to a security fix, or even a stability fix, to be a failure. It means that, while the system didn't fail (crash or be compromised), it was vulnerable to failure (crashing or being compromised). We should aim to do better than that.
Sure: People have smart TVs and tablets and stuff, which variously count as computing devices. And we've broadly reached saturation on pocket supercomputers adoption.
But while it was once common to walk into a store and find a wide array of computer-oriented furniture for sale, or visit a home and see a PC-like device semi-permanently set up in the den, it seems to be something that almost never happens anymore.
So, sure: Still-usable computers are cheap today. You've got computers wherever you want them, and so do I. But most people? They just use their phone these days.
(The point? Man, I don't have a point sometimes. Sometimes, it's just lamentations.)
I built the servers myself and then shipped to colo half way around the world.
I got over 1400 once and then I needed to add a new disk. They ran for almost 13 years with some disk replacements, CPU upgrades, and memory additions
Do you ever apply kernel patches? I also run FreeBSD and reboot for any kernel patches and never can get my uptimes to 1,000 days before that.
Do you just run versions that don't get security patches? Security support EOL dates generally means I need to upgrade before 1,000 days too. For example the current stable release gets security patches only from June 10, 2025 to June 30, 2026 giving just over 360 days of active support.
I get FreeBSD is stable and get days of uptime, and I could easily do the same if I didn't bother upgrading etc, it's just that I can't see how that's done without putting your machine at risk. Perhaps only for airgapped machines?
For my personal machines, I just run GENERIC kernels and that includes a lot, so I need to do a lot of updates. I also reboot every time I update the OS (even when it's an update that doesn't touch the kernel) so that I'm sure reboots will be fine... but I did setup my firewalls with carp and pfsync so I can reboot my firewall machines one at a time with minimal disruption.
For work machines, I use a crafted kernel config that only includes stuff we use, although so far I've usually had one config for all boxes, because it's simpler. If there's a security update for part of the kernel that we don't use, we don't need to update. Security update in a driver we don't have, no update; security update in tcp, probably update. Some security updates include mitigation steps to consider instead of or until updating... Sometimes those are reasonable too. Sometimes you do need to upgrade the whole fleet.
When there's an update that's useful but also has an effective mitigation, I would mitigate on all machines, run the update and reboot test on one or a few machines, and then typically install on the rest of the machines and if they reboot at some point, great, they don't need the mitigation anymore. If they are retired with 1000 days of uptime and a pending kernel update, that's fine too.
I would not update a machine just because support for the minor release it was on timed out. Only if there was an actual need. Including a security issue found in a later release that probably affects the older one or at least can't be ruled out. Yes, there's a risk of unpublished security issues in unsupported releases; but a supported release also has a risk of unpublished security issues too.
I get what you’re going for. But…
Please god no. Immutable images, servers are cattle not pets.
- ex Sun
Just. Run. Debian.
Also it’s OSS — contribute that support if you’re so passionate about it.
Firstly, FreeBSD already supports x86 Mac Minis. Servers? M-series Minis and Studios are very good servers. Lastly, FreeBSD has an Apple Silicon port which has stalled.
https://wiki.freebsd.org/AppleSilicon
I'll ignore your last point.
Impatience and lost skills is why it’s not a mainstream player.
And when running a Samba server, it's helpful that FreeBSD supports NFSv4 ACLs when sitting between ZFS and SMB clients; on Linux, Samba has to hack around the lack of NFSv4 ACL support by stashing them in xattrs.
You can arguably get even better ZFS and SMB integration with an Illumos distribution, but for me FreeBSD hits the sweet spot between being nice to use and having the programs I need in its package library.
If the product is python, thats what it is. there is no python-additonal-headers or python-dev or bundle-which-happens-to-be-python-but-how-would-you-know.
There is python, and there are meta-ports which explicitly 'call' the python port.
The most notable example being X11. Its sub-parts are all very rational. fonts are fonts. libs are libs. drm is drm. drivers are drivers.
(yes, there is the port/pkg confusion. thats a bit annoying.)
But I don't like Linux. I use it daily, but I don't like it. I wish FreeBSD held the position Linux does in the market today. That would be heaven.
No, the success Linux has had is because it ran on the machines people had at home, and was very easy to try out.
An instructive example would be my own path into Linux: I started with DJGPP, but got annoyed because it couldn't multi-task (if you started a compilation within an IDE like Emacs, you had to wait until it finished before you could interact with the IDE again). So I wanted a real Unix, or something close enough to it.
The best option I found was Slackware. Back then, it could install directly into the MS-DOS partition (within the C:\LINUX directory, through the magic of the UMSDOS filesystem), and boot directly from MS-DOS (through the LOADLIN bootloader). That is: like DJGPP, it could be treated like a normal MS-DOS program (with the only caveat being that you had to reboot to get back to MS-DOS). No need to dedicate a partition to it. No need to take over the MBR or bootloader. It even worked when the disk used Ontrack Disk Manager (for those too young to have heard of it, older BIOS didn't understand large disks, so newer HDDs came bundled with software like that to workaround the BIOS limitations; Linux transparently understood the special partition scheme used by Ontrack).
It worked with all the hardware I had, and worked better than MS-DOS; after a while, I noticed I was spending all my time booted into Linux, and only then I dedicated a whole partition to it (and later, the whole disk). Of course, since by then I had already gotten used to Linux, I stayed in the Linux world.
What I've read later (somewhere in a couple of HN comments) was that, beyond not having all these cool tricks (UMSDOS, LOADLIN, support for Ontrack partitions), FreeBSD was also picky with its hardware choices. I'm not sure that the hardware I had would have been fully supported, and even if it were, I'd have to dedicate a whole disk (or, at least, a whole partition) to it, and it would also take over the boot process (in a way which probably would be incompatible with Ontrack).
Many people and organizations adapted BSD to run on their hardware, but they had no obligation to upstream those drivers. Linux mandated upstreaming (if you wanted to distribute drivers to users).
Apparently many here are unaware of the history and story as to what stalled FreeBSD in a long lawsuit involving ATT. You need to read up on that. Copyleft had nothing to do with it.
Some users of FreeBSD prefer more freedoms than GPL offers. The contributors must not be put off by providing more freedoms.
Places I've worked have contributed changes to FreeBSD and Linux, mostly for the same reason ... regardless of any necessity from distributing code under license, it's nicer to keep your fork close to upstream and sending your changes upstream helps keep things close.
Personaly I think Intel's early investment in linux had a lot to do with it. They also sold a compiler and marketed to labs and such which bought chips. So linux compatibility meant a lot to decision makers.
AMD the underdog went more in on Linux compat than NVIDIA. Which may have been a business decsion.
I dunno, maybe the GPL effect was more a market share thing with developers than a copyleft thing.
Nota Bene: I do love copyleft and license all my own projects AGPL
> Anything that makes it easier to use GCC back ends without GCC front ends--or simply brings GCC a big step closer to a form that would make such usage easy--would endanger our leverage for causing new front ends to be free.
> I wish FreeBSD held the position Linux does in the market today. That would be heaven.
Well The BSD's were embattled with a lawsuit from AT&T at the time Linux came around, so it got a late start as it were, even if it's a lot older.
I have zero interest in tinkering with my operating system. I mostly want it to just get out of my way, which Linux does well 95% of the time.
FreeBSD has always required far less tweaking or maintenance than Linux, though.
What's so difficult?
"To enable the driver, add the module to /etc/rc.conf file, by executing the following command: ..."
https://docs.freebsd.org/en/books/handbook/x11/
I get that this isn't brain surgery. But come on
The Linux (Ubuntu, etc) install experience leads to a usable desktop. Heck, the installer disc boots to a usable desktop.
Also no unsophisticated users even know the name of their favorite DE. Or what a DE is.
Requiring a text login and a shell command, even one as simple as "pkg install KDE" is a big ask for a casual user these days. Also, that command line will probably fail. :)
I write these things as a very big fan of FreeBSD! I think not catering to casual users keeps FreeBSD in a better technical place overall, but Linux is obviously much more popular. This carries risks too.
I'm not saying Make Everything Easy. If there's real reasons not to have easy x11 onboarding, if FreeBSD really is intended to be an OS for experts (and I get that it may well be, for a variety of historical reasons), then fine
That does not mean they do not work, mind you - GNOME succeeds in dumbing things down that even 60 years old grandmas could use it (until they misclick and then are presented with 20 windows all put side to side). And KDE gives a lot of flexibility in tweaking it how you may want it (if we ignore Nate's donation widget). But it just is still waaaaaaay too complicated and convoluted to use. I am better off just describing my system in .yml files and then have ruby autogenerate any configuration value than struggle through annoying widgets to find some semi-random semi-new setting (or none such setting existing such as is the case in GNOME). I'd wish we could liberate these DEs from upstream developers and their dictatorship. I mean, we, can, e. g. patch out the code that shouldn't exist (like Nate's Robin Hood widget), but I mean on a global basis as-is. We as users should be in full control of EVERYTHING - every widget. Everything these widgets do, too. And everything they don't do right now but should do. Like in evince, I hate that I can't have tabs. That annoys me. I am aware that libpapers changes this, but boy ... just try to discuss this with GNOMEy devs. That's just a waste of time. I want to decide on everything here - upstream must not be able to cripple my system or influence it in no way I approve of.
No clue what he is babbling about. LFS/BLFS is active. FreeBSD doesn't have that. I am sorry but Linux is the better tinker-toy. I understand this upsets the BSD folks, but it is simply how it is. Granted, systemd and the corporatification took a huge toll into the Linux ecosystem but even now as it is in some ruins (KDE devs recently decreed that xorg will die and they will aid in the process of killing off xorg, by forcing everyone into wayland), it is still much more active as a tinker-toy. That's simply how it is.
I recall many years ago NetBSD on the mailing list pointed out that Linux now runs on more toasters than NetBSD. This is simply the power of tinkerification.
> Please keep FreeBSD the kind of place where thoughtful engineering is welcome without ego battles
K - for the three or four users worldwide.
> There’s also the practical side: keep the doors open with hardware vendors like Dell and HPE, so FreeBSD remains a first-class citizen.
Except that Linux supports more hardware. I am sorry FreeBSD people - there is reality. We can't offset and ignore it.
> My hope is simple: that you stay different. Not in the way that shouts for attention, but in the way that earns trust.
TempleOS also exists.
I think it is much more different than any of the BSDs.
> If someone wants hype or the latest shiny thing every month, they have Linux.
Right - and you don't have to go that route either. Imagine there is choice on Linux. I can run Linux without systemd - there is no problem with that. I don't need GNOME or KDE asking-for-donation begging devs killing xorg either. (Admittedly GTK and QT seem to be the only really surviving oldschool desktop GUIs and GTK is really unusuable nowadays.)
> the way the best of Unix always did, they should know they can find it here.
Yeah ok ... 500 out of 500 supercomputers running Linux ...
> And maybe, one day, someone will walk past a rack of servers, hear the steady, unhurried rhythm of a FreeBSD system still running
I used FreeBSD for a while until a certain event made me go back to Linux - my computer was shut off when I returned home. When I left, it was still turned on. It ran FreeBSD. This is of course episodical, but I never had that problem with Linux.
I think FreeBSD folks need to realise that Linux did some things better.
For some reason, every time FreeBSD is put in a positive light there is always a lot of Linux(-only) users who has to put FreeBSD down.
I don’t understand why. Would be interesting to understand this psychological phenomena.
Linux users aren't interested to see potential adopters go for BSD instead of joining their ranks.
On every forum, every discussion, there is at least one guy saying he runs that game on Linux, or that other OS is somehow inferior to Linux, or this problem would never happen on Linux...
It's all about marketing, if you will...
So what? Big whoop.